冒烟测试

冒烟测试这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，先进行通电测试。如果冒烟，说明存在致命的故障，就没有必要做进一步的测试了。 如果没有冒烟，则该组件需要继续做进一步的测试。

微软公司把冒烟测试引入了软件领域，即在2000年出版的《微软项目求生法则》一书的第14章提出的一种测试，目的是对一个新编译需要正式测试的软件版本，确认软件的基本功能是正常的，然后才可以进行后续的测试工作。

微软提出冒烟测试，和他一直提倡的每日build（构建版本）有很密切的联系。具体说，冒烟测试就是在每日构建版本建立后，对系统的基本功能进行简单的测试，也用来检验持续集成是否成功。所以冒烟测试也被成为BVT(Build Verification Testing)

开展冒烟测试工作有助于尽早发现软件代码存在的问题，节约时间节省成本，提高软件代码的质量和开发效率。

冒烟测试，在软件生命周期中所占有的时间比例较低，同时具有注重通过性轻细节的特点，因此经常被开发、测试人员所忽视。事实上，冒烟测试是软件测试过程中一个不可或缺的节点，一个好的冒烟测试过程，对于软件测试效率的提升具有重要意义。

• 冒烟测试是对软件质量的总体检验。
  通过冒烟测试，能够快速确认软件是否具备测试准入条件，避免出现正式测试阶段全面开展后甚至到测试中后期才才发现阻塞型缺陷等严重影响测试进度浪费人力物力的情况。

• 冒烟测试是测试人员对测试流程的熟悉。
  通过冒烟测试，测试人员可以迅速熟悉测试总体流程，这一方面有助于测试人员准确制定测试时间计划，合理安排工作进度；另一方面也有助于测试人员提前做好相关设备、数据的准备，为正式测试的开展奠定基础。

冒烟测试/BVT，是在所有开发工程师都已经集成完自己的代码，并编译完成，生成当天的版本之后进行，在正式测试前，对产品或系统的一次简单的验证性测试。

• 主要目的是验证最新生成的软件版本功能的完整性，主要的软件特性的正确性，确保全流程没有严重、阻塞性的问题。

进行冒烟测试之前需要确定冒烟测试的用例集，对用例集要求覆盖软件的基本功能。这种版本包出包之后的验证方法通常称为软件版本包的门槛用例验证。
冒烟测试用例也称为准入用例，只有准入用例执行通过了，才可以进行新功能的测试。一般来说准入的用例不会太多，大概是全功能用例的十分之一，是测试用例中 P0 / level 0 的用例。

用例选取遵循以下原则

• 选取业务最重要功能的用例
  重要功能的用例是对软件功能实现具有重要影响的功能模块测试用例，例如：一个数据业务的增删改查功能、一个算法业务的输入输出结果校验等。

• 选取业务最主要流程的用例
  如果在主流程有重大缺陷甚至阻碍，使得业务不可用，那么对分支流程测的再多也无法帮助整体业务的质量。所以冒烟测试要重点关注主要的业务流程。

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

在持续集成中普遍需要自动化执行。BVT（Build Verification Test）是持续集成的最后一步，用来验证软件的最基本的功能或业务上最常用的功能，也是用于检验持续集成是否成功。

而且，BVT 的测试内容要根据软件版本的演化进行持续更新，增加新的基本特性的覆盖，去掉那些风险较低的测试项。

1. 冒烟测试由谁来执行？

• 开发：编码完成后，开发可根据冒烟用例进行自测。

• 产品：验收阶段，产品可根据冒烟用例对产品进行初步验收。

• 测试：根据冒烟用例进行测试验证。

2. 冒烟测试 v.s. 回归测试？

• 冒烟测试，是版本验证测试，主要确认新的版本是否存在致命性bug，冒烟测试最大的优点在于节约测试的时间成本，减少测试轮数。

• 回归测试，是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

朱少民老师的敏捷测试书籍和文章，例如《敏捷测试 - 以持续测试促进持续交付》

使用Gitlab持续集成进行每日构建，每天晚上对几个最重要场景进行自动化冒烟测试，用来检验最新版本的基本质量情况。测试结果会实时发到钉钉消息群通知开发人员。