冒烟测试总结

“冒烟测试”源自硬件行业，对一个硬件或者硬件组件改动后，直接给设备加电，看看设备会不会冒烟，没冒烟，就表示待测组件是通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

搞清楚冒烟测试的起源和目的后，不难想到，冒烟测试其实是这样一种测试：不要求覆盖面有多广，但至少要保证覆盖待测产品的绝大部分功能；不要求每个功能都测的很详细，但至少要保证被修复了的bug所属的功能和系统其他骨干功能都是可用的（即这个版本能拿去做系统功能测试了）。而要做到覆盖骨干功能和bug所属功能，却不是简简单单在页面中点几下就行了的。任何一个项目或者产品，骨干功能都有它的使用场景。冒烟测试就是要保证这些骨干功能的使用场景都能跑通，如果没跑通，后续的系统测试就没必要了。在进行冒烟测试的时候，不需要测试异常情况，只需要保证基本功能覆盖。通常，冒烟测试是交给开发人员去做的。只有确认了功能可用后，交给测试人员去做才有意义。

总结：
冒烟测试：由开发人员要做的覆盖大多数主干功能和bug所属功能的测试

冒烟测试(smoke test)在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。

更详细解答：

接口测试总结

测试知识扫盲