在一般的项目里，我们往往需要进行多个版本的测试工作，但是在我们按照计划执行正式的系统集成测试前，我们需要作一些中间测试版，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。

　　这样的测试就叫做冒烟测试，它是一种自由测试。

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

　　冒烟测试的名称可以理解未该种测试耗时短，仅用一袋烟功夫足够了。它的作用就是保证系统的主流程和新模块的基本功能能用，保证希望集成测试能正常开展，优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。

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

　　下面我们介绍我们公司的冒烟测试流程。

　　第一步：确定冒烟测试用例

　　测试经理会和项目经理等相关人员从测试用例库中选定重要的测试用例，标记为冒烟测试用例。

　　第二步：执行冒烟测试

　　关于执行冒烟测试的人选，通常我们会让测试人员进行。具体流程如下：

　　由此可以看到冒烟测试失败的话，会导致测试进度延期，成本和进度风险很大，因此冒烟测试失败是一个很大的项目失误，所以一般的，在发布前，开发人员会内部执行一次冒烟测试，来保证提交的版本的质量。

　　下面介绍一下冒烟测试执行的注意点：

　　1、冒烟测试的时间：通常冒烟测试会在正式测试的半天到1天时间前提交。测试人员在1~2小时内完成冒烟测试，并给出测试结果。

　　2、发布测试版本邮件的内容。通常版本发布者需要发邮件给测试经理并抄送项目相关人员，内容需要包括：

　　* 此次新增的功能模块有哪些？

　　* 新增的功能模块由哪位开发人员负责（方便BUG的指派）？

　　* 修复的BUG有哪些？

　　第三步：报告冒烟测试

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

　　总结：从八二法则看冒烟测试，往往冒烟测试集合了项目中最重要的功能和模块，一旦出错，系统就陷于不能使用的境地，其严重性不言而喻，而提高每次测试版本的质量，也是成本控制的一种方式，将测试前移，从源头做起，节省成本，提高产品质量的出路，那先从我们的冒烟测试做起吧，个人感想，与同仁共勉。