Smoke Test (冒烟测试)

今天收到了做测试的第一项任务，Smoke Test。作为从来没有做过测试的人来说看到这个单词其实是一脸懵逼的。于是迅速恶补了一下基础知识。

Smoke Test被认为是最先由微软提出的概念，与微软一直提倡的每日构建（build）有密切联系。词语源自硬件行业，可以类比新电路板的基本功能检查（即新电路板焊好之后先进行通电检查，如果存在设计缺陷，电路板可能会因为短路而冒烟）。有的公司也称其为版本健康检查(Build Sanity Check)。

在软件行业，冒烟测试描述的是将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程，即用来确定更改后的代码会按照预期进行并且不会破坏整个版本的稳定性。冒烟测试可以经济有效地确定和修复软件缺陷。实施为：测试人员在正式测试之前先跑一下主流程，没问题了在进行其他测试工作。

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

冒烟测试的对象是每个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，执行者是版本的编译人员。不通过时需要重新编译，到成功为止。

准备

测试经理和项目经理等相关人员从测试用例库中选定重要的测试用例，标记为冒烟测试用例。或者单独编写。
1、主流程和主功能的确认
要求测试人员在测试开始前跟开发人员确认需求和重要的流程、功能，最好将功能点和流程以及预期结果和开发人员说明清楚。冒烟测试不要求测试结果像正式测试阶段那么准确，但是也需要列一个指标来衡量测试是否通过。）
2、预计时间
根据列出的功能点和开发人员代码质量的可信度，评估冒烟测试在不同环境下可能花费的最长和最短时间，列到测试计划中。
3、数据的准备
在测试前，透彻的了解主要功能对应表的存储结构，准备好需要的数据。冒烟测试开始后，不会因为这些工作浪费时间。

执行

测试人员严格按照前期的约定去校验主流程，全部校验完和开发人员报告情况，不能放过一个主要的测试功能点。

总结

通常测试组在执行完冒烟测试，会回复本次冒烟测试结果，接受本次版本或者拒绝本次版本。如果拒绝本次版本，需要附录失败的原因和详细缺陷的描述。

时间方面，冒烟测试如果延误，要分析这段时间会不会对正式测试的时间有影响，如果有较大的影响需要和开发人员及时沟通补救方法，比如提高开发人员修复BUG的效率，测试时间顺延等。

参考链接：
冒烟测试（smoke test）
冒烟测试-百度百科词条
软件测试中关于冒烟测试的经验小结
小谈冒烟测试