冒烟测试(Smoking Tesing)

冒烟测试这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。

 

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

 

冒烟测试据说是微软起的名字，可以理解为该种测试耗时短，仅用一袋烟功夫足够了。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作，其执行者是版本编译人员。

 

在进行冒烟测试是必须与编写代码的开发人员协同工作，因为冒烟测试特别关注更改过的代码。因此，在进行测试时，必须了解一下内容：

1、代码中进行了什么更改。若要理解该更改，必须理解使用的技术；开发人员可以提供相关说明。

2、更改对功能有何影响。

3、更改对各组件的依存关系有何影响。

 

另外，在进行冒烟测试之前，应该侧重于代码中所有更改的代码进行检查，这样能够确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证，因为如果失败，测试就无法继续。

 

冒烟测试，它和回归测试的性质一样——只是一个测试活动，并不是一个测试阶段。也就是说，冒烟测试贯穿于软件开发的任何一个阶段。

在实际的软件测试工作中，Smoke Testing 在软件研发的不同阶段有所不同。大体可以分为三类：

1. 形成集成测试版本以前——Smoke Testing 是随着代码的不断开发必做的一项工作，目的是验证各个单元能够成功执行，并保证测试版本能够顺利集成。

2. 形成集成测试版本以后——在代码 check in 到 daily build 之前执行 Smoke Testing，以保证新的或者更改过的代码不破坏集成版本的完成性和稳定性。

3. 后期预测试 Bug 的修正——后期 daily build 相对稳定时，针对每个 Bug 所做的 Bug Fix 都要先在“干净的” build 中进行 Smoke Testing，测试通过的 Bug Fix 才能 check in 到新的 daily build 中。