(转) 软件测试中术语（Smoke Testing & Build Verification Testing）

原文链接

https://www.cnblogs.com/zzp28/articles/1742661.html

https://www.cnblogs.com/zzp28/articles/1742665.html

详细介绍一下 Smoke Testing（冒烟测试）

 

近来看到和听到几个关于 Smoke Testing 的说法，也曾几次被顾问客户问及 Smoke Testing，感觉大家似乎对 Smoke Testing 的概念都相当模糊。据说软件测试中的 Smoke Testing 最早源于微软，而在实践中，我曾就此询问过美国微软的几个开发人员，他们的说法也莫衷一是。根据我搜集的一些资料，结合微软的实际测试工作，现将  Smoke Testing 综合介绍一下。

【误区】

　　先说说大家对 Smoke Testing 理解中的问题。查了一下网上有关 Smoke Testing 的资料，发现所有关于这方面的信息不外乎来源于两个：

1. 翻译过来的定义——关于 Smoke Testing 的定义能查到不少，内容基本是一致的，但是定义很表观且陈旧，和当前国际上大软件企业中的 Smoke Testing 实践并不十分相符。
2. 以讹传讹的理解——比如：

• 完全沿用 Smoke Testing 的原始意义——这是在理解一些外来专用语上常犯的一种错误。
• 想当然地理解为“用抽烟的功夫就能完成的测试”——这貌似有道理，但却是最荒谬的，因为 Smoke Testing 并
  不见得比常规的测试花费更少的时间，而且在正式的软件测试工作环境里是没有人抽烟的。
• 笼统地把所有粗浅的测试都作为 Smoke Testing——这显然是因为对 Smoke Testing 定义中的“简单测试”或者
  “初级测试”等等单词断章取义的理解。
• 认为 Smoke Testing 就是 BVT——这是因为 Smoke Testing 定义的模糊与过时。

等等。

　　那么真正的 Smoke Testing 是什么意思呢？

【Smoke Testing 释义】

　　Smoke Testing 的概念最早源于制造业，用于测试管道。测试时，用鼓风机往管道里灌烟，看管壁外面是否有烟冒出来，以便检验管道是否有缝隙。这一测试显然比较初级，更深层一点的测试至少要进行渗油测试、带压测试等等。Smoke Testing 只是一种初级、直观的测试。

　　软件测试中的 Smoke Testing 实际上用的是其引申含义，而且是引申了不止一道的含义，在这里，Smoke Testing 其实是个俚语——就跟很多其他源于美国软件行业的名词一样。

　　以前我并不知道 Smoke Testing 有适当的中文翻译，最早听到“冒烟测试”这个词还是在我的顾问客户那里。据我的理解，这个翻译只是字面翻译，显然并不能代表 Smoke Testing 的真实含义，换句话说“冒烟测试”只是 Smoke Testing 的字译而非意译。

　　Smoke Testing 在软件测试中的意义，应该说取的是其原始概念中的目的而非手段。通过 Smoke Testing，在软件代码正式编译并交付测试之前，先尽量消除其“表面的”错误，减少后期测试的负担。因此可以说，Smoke Testing 是预测试。

【Smoke Testing 的执行】

　　按照现有定义的说法，Smoke Testing 的执行似乎是在每日构建（daily build）完成时进行的，从这一点来看似乎说的就是 BVT。因此国内有人更加引申一步理解，把研发后期所做的一些不全面的集成测试也认为是 Smoke Testing。

　　实际上 Smoke Testing 的执行是在代码评审（code review）之后、每日构建（daily build）之前完成的工作——关于这一点，如果大家认真查阅国外同行关于 Smoke Testing 的介绍是不难找到叙述的。

【软件研发不同阶段的 Smoke Testing】

　　在实际的软件测试工作中，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 中。

【Smoke Testing 与 BVT】

　　从 Smoke Testing 的定义上看，BVT 似乎可以看作是 Smoke Testing，但在实际当中 BVT 是与 Smoke Testing 完全独立的一个概念，这是基于以下几个方面：

• Smoke Testing 与 BVT 的执行阶段不一样。
• Smoke Testing 与 BVT 的内容不一样。
• Smoke Testing 与 BVT 结果对后续工作的影响不一样。

　　关于 BVT，我将另具文介绍。

详细介绍一下 BVT

 

BVT 在成熟的软件研发过程中是很普及的一项测试，也是不可或缺的一项测试。然而在实际中，尤其是国内一些软件企业的实际工作中，却因为配置管理的缺乏而根本没有 BVT，甚至很多人至今还不清楚 BVT 究竟是做什么。

【误区】

　　如果没有接触过具体的实践，单单看一些名词的定义，有时候会产生一些错误的理解。

• 很多人误认为软件集成以后所做的一系列测试就是 BVT。这可以说对 BVT 是毫无概念了。

• 更多人认为 BVT 就是 Smoke Testing（冒烟测试）。这是基于对 Smoke Testing 概念的片面理解，这一点我在《详细介绍一下 Smoke Testing（冒烟测试）》一文中已经有所解释，本文中会有更详细的叙述。

• 不少人认为 BVT 只是基于每日构建（daily build）的。其实，对于每一个版本、微版本，都要执行 BVT。

【BVT 释义】

　　BVT 的全称是 Build Verification Test。可以说这个全称就是 BVT 的定义了。

　　BVT 只验证 build 构建的成功与失败，不深入测试构建好的 build 的功能、性能等等。

【BVT 的执行】

　　在每日构建的环境里，每个 daily build 构建完成时都要执行 BVT。对于 daily build 以外的每个版本和微版本，构建完成时也要执行 BVT。

　　BVT  可以手动执行。版本的构建是相对稳定的过程，因此 BVT 基本上是软件测试中最早实现全面自动化的测试。现在绝大多数版本构建工具都附带 BVT 功能。

　　BVT 最基础的任务是进行文件版本的比对。伴随开发进程，软件功能越来越固化，BVT 有时会在不影响最基本功能的基础上加入一些成熟的自动化测试脚本。

【BVT 对后续测试工作的影响】

　　BVT 是集成测试的一道门槛，只有通过了 BVT 的 build 才可以进入后面的集成测试过程。

• BVT 结果成功的 build —— 表明该 build 构建成功，交付集成测试，但不一定被测试。

• BVT 结果失败的 build —— 表明该 build 构建失败，不交付集成测试；提交 BVT Bug，并按照 Bug 流程解决此 Bug。

• 未经 BVT 的 build —— 不得提交集成测试。

【BVT 不同于 Smoke Testing】

　　BVT 所做的测试内容很浅，这一特征似乎符合 Smoke Testing 的定义；但是 BVT 只验证 build 的构建情况，这一点与 Smoke Testing 截然不同，因此二者是完全不同的测试。另外：

• BVT 只在 build 构建完成时进行；Smoke Testing 是各个阶段都有的测试。
• 尽管 BVT 可以加入自动测试脚本并执行少量固定的自动化测试，但 Smoke Testing 与 build 的验证无关。
• BVT 的结果直接决定新构建的 build 是否交付后续测试；Smoke Testing 不影响其他日常测试工作