软件测试之冒烟测试中易犯的三个误区–新梦想软件测试

何为冒烟测试/p>

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

简单点就是，发现BUG后开发人员fix bug后。测试人员针对该问题进行测试，冒烟测试的成功与否关系到下一步系统测试能否进行。与系统测试不同在于前者覆盖范围不够，只要保证修改部分及其关联的模块不出问题就可。

执行冒烟测试的前提。前面提到冒烟测试是与开发的合同协作，初步了解代码中进行了什么更改。开发需告知此修改对其他功能是否影响;更改对各组件的依存关系有何影响。

软件冒烟测试往往在敏捷开发团队中有着非常大的帮助，在目前这种快速开发迭代的节奏下，如果依旧采用常规的提测、测试、回归流程，显得过于死板和迟钝，产品中存在的问题不能以第一时间反馈给各角色，而冒烟测试则是集合了整个团队的力量共同助力产品的质量。这里所说的冒烟测试是穿插在整个项目流程的各个阶段，从而在项目周期中把控产品质量。

但是冒烟测试却在工作中，容易陷入误区。

误区一：软件开发员不知道冒烟测试

通常一提到冒烟测试，大家都习惯性的把关注点放在后面两个字:测试 ,开发的同学一听这个活动，很开心，这不是我们的活儿，应该是测试人员来完成的。真的是这样么/p>

其实在软件研发中，冒烟测试其实是微软首先提出来的一个概念，和微软一直提倡的每日build(构建版本)有很密切的联系。具体说，冒烟测试就是在每日build(构建版本)建立后，对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。

冒烟只是这类测试活动更形象化一些的叫法，直接叫做BVT(Build Verification Testing)更为贴切。

误区二：冒烟测试为一个测试阶段

有些团队在定制流程时会有一个阶段叫冒烟测试，但是就算不通过也会继续做后面其它部分的测试。

反过头来看当时微软提出来的这个概念，它的重点其实在于 daily build ，也就是说冒烟测试是随着每一次构建而走的，它应该是一个开关而不是一个研发流程中的测试阶段。

如果通过过，你可以继续后面的测试。如果不通过，直接返工等待下一次的构建。这才是冒烟测试应有的态度。

误区三：冒烟测试需要把此次需求的主流程都走一遍

冒烟测试主要是测试系统的主流程是否可用，如果这次的需求不涉及到太多主流程上面的更改，那真的有必要把这些案例都加入到冒烟测试中么/p>

最后，冒烟测试的最佳实践还是最好被自动化，在CI中每一个Build都自动的去执行主流程的测试，确保其是一个基本可用的版本。