在软件开发过程中，一直有高内聚，低耦合这样的说法，各个功能模块之间的耦合还是存在的，因此一个功能的改动，还是会影响到其他功能模块。

　　因此在开发人员修复了先前测试中发现的bug后，想知道这个bug的修复是否会影响到其他功能模块，需要做的就是冒烟测试。

　　搞清楚冒烟测试的起源，冒烟测试的目的后，不难想到，冒烟测试是这样的一种测试，不要求覆盖面有多广，但至少要覆盖待测产品的绝大部分功能;不要求每个功能都测的很详细，但至少要被修复了的bug所属的功能和系统其他骨干功能都是可用的(即这个版本能拿去做系统功能测试了)。

　　而要做到覆盖骨干功能和bug所属功能，却不是简简单单在页面中点几下就行了的。任何一个项目或者产品，骨干功能都有它的使用场景。冒烟测试就是要这些骨干功能的使用场景都能跑通，如果没跑通，后续的系统测试就没必要了。

　　其实做冒烟测试之前，都已经做了一个简单的安装部署测试了(你不安装部署，哪里来东西测呢)。按小编自己的理解，其实这块也可以放入冒烟测试范畴的。想想看，安装部署是不是很类似电路板加电，让电路板开始工作呢?而后面的骨干使用场景测试，只是在这个基础上做的后续工作。如果安装部署后，待测产品跑到一半就down掉了，后面的骨干功能的使用场景还测个屁呀。

　　使用场景的是否能跑通的测试，不需要测一些异常的情况，基本功能覆盖到就行了。通常，冒烟测试是交给开发人员去做的。只有确认了功能可用后，交给测试人员去做才有意义。

　　后面需要冒烟上的优化做些什么呢，多的还是从自动化上去着手，版本构建自动化，自动化冒烟测试等等。

　　冒烟测试是什么?冒烟测试如何做?上面小编已经为大家做了详细的介绍，希望能够给大家带来帮助，如果大家正在学习软件测试知识或者是对软件测试知识比较感兴趣的话，都可以添加我们的官方qq群-858327674，不仅可以获得软件测试学习资料，并且群内还有专业的软件测试老师定期为大家解决学习所遇到的问题，想要学习的小伙伴，不要错过。