冒烟测试

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

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

冒烟测试是自由测试中的一种。

 

源

冒烟测试（smoke testing）,据说是 微软起的名字。在《 微软项目求生法则》一书第14章“构建过程”关于 冒烟测试，就是开发人员在个人版本的 软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。

冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新 电路板基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。

 

冒烟测试的对象是每一个新编译的需要正式测试的 软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。 冒烟测试的执行者是版本编译人员。

在一般 软件公司，软件在编写过程中，内部需要编译多个版本(Builds)，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能 确认测试，例如是否可以正确安装/ 卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收 确认测试，直到成功。

 

http://baike.baidu.com/view/120001.htm