编译：TesterHome
原文标题：7 Benifits of Smoke Testing You Can't Do Without
作者：Chiradeep BasuMallick
以下为作者观点：
冒烟测试 (smoke testing) 是在开发的早期阶段评估基本的软件组件，以检查它们是否 "着火"（有问题），本文旨在介绍冒烟测试及其在程序开发过程中的作用。
冒烟测试是在开发的早期阶段对软件程序的基本和核心元素进行测试，以确定有没有会影响产品按时发布的 bug。
冒烟测试的核心是用来确定发布的软件是否可靠。冒烟测试允许质量保证（QA）团队继续进行额外的软件测试，包括在每个构建中执行的最小的测试集合，以验证软件的运行。
冒烟测试这个名称的来历，最初是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则就必须重新来过。
冒烟测试只需要确保被测试的构建没有大的 bug，并且关键的功能能够按照预期运行。可以说，它是对软件基本功能的快速而简洁的回归测试，它还能更简单地决定该构建是否有大的缺陷，避免后续不必要的资源和时间投入。
通过进行冒烟测试，人们可以在早期发现阻塞性错误，防止测试工程师闲置，或者可以进一步检查独立的可测试模块。
冒烟测试可以保证软件的关键功能按预期运行，它用于测试系统或产品的运行情况，被称为可接受性测试的一个类别。然而，健全测试（Sanity testing）是一种检测产品质量以确定其是否准备好进行进一步测试的方法，被称为回归测试的一个分支。
有时，冒烟测试和健全测试被误认为是一样的。然而，它们各自有不同的目标和考虑。
冒烟测试是为了确保程序的关键功能按预期运行，而健全测试是用来确定缺陷是否在构建后被修复。冒烟测试是为了测试系统或产品的稳定性。健全测试是通过测试来评估系统或产品的逻辑。
在冒烟测试过程中，软件构建可能是稳定的，也可能是不稳定的。在整个健全测试过程中，软件构建是相对可靠的。健全测试通常是手动进行的，没有任何自动化技术，相比之下，冒烟测试可以手动进行或使用自动化工具进行。
为了充分理解冒烟测试的意义，有必要了解它的不同类型。
自动测试：在这种情况下，该工具会做所有必要的测试。特别是项目的最后期限很紧时，它是非常有帮助的。当一个新的构建准备部署时，开发人员可以立即用自动化测试来检查它。这个过程可以使用工具自动化，而不是依赖人工测试人员。自动化冒烟测试可以减少人力和资金投入，提高公司的生产力。如果测试不成功，在进行必要的修正后立即重新部署构建。
手动测试：手动测试要求测试人员为每个生成的产品创建、构建、更新或修改测试案例。如果你选择手动选项，你将使用人工测试员来执行冒烟测试。测试人员必须为已经存在的功能或全新的功能创建测试脚本。关键功能测试的执行应该是在向 QA 分发构建之后，以发现严重的系统问题。如果测试成功，功能测试继续进一步进行。如果测试失败，则放弃构建，将其送回生产团队进行修改。
混合测试：混合测试是手动和自动测试的混合。在这种情况下，测试人员必须创建他们的测试用例，并可能使用工具来实现测试的自动化。由于它结合了手动检查和工具的使用，测试的性能得到了提高。混合测试技术结合了其他两种的最实用的元素，它需要在冒烟测试程序中使用一些测试自动化，同时利用一定量的人工来评估软件。由于混合测试结合了前两者的优点，这种测试方法比其他两种方法更有优势。
冒烟测试过程的 4 个步骤
为了进行冒烟测试，DevOps 工程师和产品团队必须：
它可能需要启动服务器，安装许可证，设置数据库表，或将文件复制到正确的地方。人们应该在构建完成后和测试开始前完成特定的设置任务。这些活动包括设置许可证，将数据存储在不同的地方，启动服务器，以及其他相关的事情。
选择用于分析的测试案例应该是每个人的最初步骤。人们应该能够从他们选择的测试案例中清楚地了解到产品的基本功能。同时，人们应该避免使用不太重要的测试功能。进行的测试越多，结果就越可靠，越实用。
冒烟测试应该始终使用一个脚本，通过使用单一的脚本，可以增加测试的通用性。下面的行动是编译其冒烟测试所需的文件。使用命令行，Perforce 的冒烟测试工具的用户会下载许多测试文件到本地磁盘。
将必要的文件下载到本地硬盘进行冒烟测试的命令行因软件的不同而不同。
如果有什么功能不正常，必须通知开发人员（同时附上脚本版本）。在这种情况下，最关键的是要记住坚持前面步骤中的规则。例如，人们可能要确保他们有替代人员，以防几个人工测试人员突然取消。
当人们到达这一点时，他们应该已经为处理这些情况做了必要的准备。当然，意外事件总是有可能发生的，积极参与监测程序并留意因此而出现的问题是至关重要的。
如果研究他们的冒烟测试的结果，那么确定最终的结果是成功的还是不成功的就会更简单。例如，如果是一家 SaaS 公司，其软件质量的标准就需要相对较高，就像之前的情况。如果 10% 的测试表明是不稳定的构建，他们很可能想把它退回修改。
然而，其他开发者可能会认为同样的百分比是一个构建的稳定门槛。换句话说，必须记住，在整个分析阶段，人们必须使期望值适应需求。在冒烟测试之后，需要进行清理。
当一个新的程序版本在 QA 或暂存环境中被创建并与已经部署的版本集成时，就会进行冒烟测试。它检查是否所有的关键功能都能正确运行。开发团队部署 QA 构建，测试人员在删除一部分构建后对构建执行测试用例。
这组测试用例的目的是为了揭示构建中的错误。如果这些测试成功，QA 团队就会转入功能测试。在任何失败的情况下，人们必须把系统交还给开发团队，如果通过了，就可以进入更多的阶段（比如被应用安全工程师测试）。
冒烟测试应该经常要做，以确保构建的稳定性，无论何时改变。一个构建包含了所有的数据集、档案、可用的模块和完成产品功能所需的技术组件。
在实际开发中，人们可以设置自动冒烟测试，以确保关键功能按预期运行。当一个新的构建准备部署时，开发人员可以立即用自动化测试来检查它。
每当一个新的软件构建准备发布时，预先录制的冒烟测试会与构建同步进行，而不是手动执行测试。一个冒烟测试套件应该包括适量的快速运行的测试，即使是完全自动化的，也是有效的和有目的的。
测试的数量应该在 20 到 50 之间，这是一个可以接受的范围。这个初步测试套件的目标可能会被太少或太多的覆盖率所击败。众多的自动化工具是现成的，多个工具供应商做出各种产品承诺。大多数著名的技术集中在基于浏览器的自动化，其中 Selenium 目前占据了浏览器自动化框架的首位。检查这些操作是否有错误，可以确定程序的任何问题。这些测试可能最多几天就能完成。
在对软件产品的初始发布进行这种测试时，人们应该确保他们覆盖系统的每一个区域。通过这样做，开发人员可以进行更多的冒烟测试，而不必等待整个应用程序达到稳定状态。
更快地排除新问题和回归问题的故障
如果在冒烟测试中发现任何问题，开发团队可以更早地开始调试和进行根本原因分析，而不是等待整个测试套件的结果。这是因为冒烟测试套件有很好的覆盖面，但深度较浅。当 QA 继续对具有一定可行性的构建进行回归测试，同时开发人员修复冒烟测试中发现的任何缺陷时，可以实现效率的提高。一旦开发人员修复了这些缺陷，接下来开发人员可以专注于纠正 QA 在回归测试中发现的任何缺陷。
提高测试效率
测试团队可以通过使用冒烟测试来节省精力。把精力浪费在一个几乎不能工作的充满 bug 的构建上是没有价值的。正因为如此，人们更愿意依靠冒烟测试来识别所有的不稳定性。开发人员可以及早消除它们，确保敏捷软件开发中每个新版本的基础是健全的、无缺陷的，而这个基础是建立在第一个版本之上的。换句话说，冒烟测试提高了核心代码的可靠性。它们也使新版本更容易集成，因为它们不太可能有重大问题。
及时发现大的 bug
冒烟测试最显著的好处之一是能够及早发现系统基本功能的问题。据统计，建立并运行一个有效的冒烟测试套件可以让他们发现并修复多达 80% 的缺陷。对于许多团队来说，冒烟测试可能只涵盖了全部测试用例的 20% 或更少，但他们仍然能够找到 80% 或更多的缺陷。仅仅因为这个原因，冒烟测试工作是值得的。
减少与集成有关的威胁
冒烟测试对涉及到向已有的软件程序添加新功能的集成是有益的，这是在利用 CI/CD 工具和方法学时经常发生的。新的构建被用来添加这些功能，而每一个都必须首先被测试。如果测试包括冒烟测试，你就可以确定完成的集成程序的每一部分都经过了测试。
节省时间和资源
冒烟测试通常需要 15 分钟到 2 小时，这取决于系统的复杂程度（最坏的情况）。冒烟测试的自动化可以减少所需的时间。如果团队能够使用冒烟测试快速有效地确定问题的原因，那么他们可以节约大量时间。
自动化的潜力
通过自动化，时间和资源都可以大大节省。在完成任务和工作流程方面，机器总是比人类更快。虽然依靠人类智慧和创造力的程序不能自动化，但冒烟测试可以由基于人工智能（AI）的系统完成，这可以大大缩短测试时间。
选择自动化有很多好处。确保每次自动化的程序都按照相同的标准执行，有几个好处。因此，开发人员可以摒弃人为错误的不可预测性。还有可能增加测试的频率。
冒烟测试是在软件产品开发测试用例时需要记住的关键概念之一。它不是深入到软件代码的细枝末节，而是寻找可能导致严重 bug 的基本问题。成功通过冒烟测试对于开发一个准备发布的软件应用程序是至关重要的。这就是为什么它必须在你的 DevOps 生命周期的持续集成/持续交付（CI/CD）流程中占据重要位置。
