什么是烟雾测试？
托马斯·汉密尔顿
什么是烟雾测试？
烟雾测试 是一个软件测试过程，用于确定部署的软件版本是否稳定。冒烟测试是 QA 团队进行进一步软件测试的确认。它由在每个版本上运行的一组最小测试组成，用于测试软件功能。冒烟测试也称为“版本验证测试”或“置信度测试”。
简单来说，冒烟测试是指验证重要功能是否正常运行，以及被测版本中是否存在任何致命缺陷。它是一种针对主要功能的快速小型回归测试。这有助于确定版本是否存在缺陷，从而避免进一步的测试浪费时间和资源。
竞品对比 冒烟测试与健全性测试
我们为什么要进行烟雾测试？
冒烟测试在软件开发中扮演着重要角色，因为它能确保系统在初始阶段的正确性。通过冒烟测试，我们可以节省测试工作量。只有在完成冒烟测试后，我们才能开始功能测试。
- 通过冒烟测试可以找出构建过程中所有可能导致问题出现的原因。
- 借助烟雾测试，大多数缺陷可以在初始阶段被发现。 软件开发.
- 通过烟雾测试，我们简化了主要缺陷的检测和纠正。
- 通过烟雾测试，QA 团队可以发现新代码可能出现的应用程序功能缺陷。
- 烟雾测试发现重大严重缺陷。
例如1： 日志窗口：单击提交按钮后，可以使用有效的用户名和密码移动到下一个窗口。
例如2： 用户无法从网页退出。
我们何时进行烟雾测试？
只有在合适的时机触发检查，这些好处才能真正体现出来。每当软件的新功能开发完成并与部署在测试/预发布环境中的现有版本集成时，都会进行冒烟测试。它确保所有关键功能都能正常工作。下图展示了在冒烟测试开始之前，版本是如何到达测试环境的。
在这种测试方法中，开发团队将构建版本部署到质量保证（QA）环境中。测试人员会选取一部分测试用例，针对构建版本的关键功能进行运行。这些测试用例旨在发现构建版本中存在的错误。如果这些测试通过，QA 团队将继续进行后续测试。 功能测试.
任何故障都表明需要将系统交回开发团队处理。每当构建发生变化时，我们都会进行冒烟测试以确保稳定性。
例如：: - 在登录窗口中添加了新的注册按钮，并使用新代码部署了版本。我们对新版本进行了冒烟测试。
冒烟测试用于验证构建版本是否符合后续正式测试的要求，旨在证明系统稳定性并满足相关要求。其主要目的是尽早发现重大问题。构建版本包含实现一项或多项产品功能所需的所有数据文件、库、可重用模块和工程组件。
如果我们不进行烟雾测试会发生什么？
如果在早期阶段不进行烟雾测试，后期阶段可能会发现缺陷，而这可能会造成高昂的代价。 缺陷 后期发现的问题可能会成为阻碍交付成果的绊脚石。
谁来做烟雾测试？
将构建版本发布到 QA 环境后，QA 工程师/QA 主管将执行冒烟测试。每当有新构建版本时，QA 团队都会确定应用程序中的主要功能以执行冒烟测试。QA 团队会检查正在测试的应用程序中是否存在问题。
如何进行烟雾测试？
冒烟测试通常是手动进行的，尽管也可以通过自动化来完成。不同组织的情况可能有所不同。
手动烟雾测试
冒烟测试旨在确保关键路径的运行符合预期，且不会影响系统功能。我们会选取高优先级功能测试用例进行测试，以发现系统中的关键缺陷。如果测试通过，则继续进行功能测试。如果测试失败，则构建版本将被拒绝并退回给开发团队进行修复。
QA团队再次使用新构建版本启动冒烟测试。冒烟测试在新构建版本上进行，并将结果与旧构建版本集成，以确保系统的正确性。在执行冒烟测试之前，QA团队应检查构建版本是否正确。
自动化冒烟测试
自动化测试 是用来 迭代测试不过，我们也可以使用一组自动化测试用例来运行冒烟测试。借助自动化测试，开发人员可以在新版本准备部署时立即检查构建过程。
每当部署新的软件版本时，无需手动重复测试，而是针对版本执行记录的冒烟测试用例。它可以验证主要功能是否仍然正常运行。如果测试失败，他们可以立即纠正版本并重新部署版本。这样，我们可以节省时间并确保 QA 环境的构建质量。
测试工程师使用自动化工具记录软件构建中执行的所有手动步骤。
烟雾测试周期
下图展示了冒烟测试的执行过程。构建版本部署到质量保证（QA）环境并通过冒烟测试后，我们将进行功能测试。如果冒烟测试失败，我们将暂停测试，直到构建版本中的问题得到修复。
设计冒烟测试用例的最佳实践
了解周期是一回事；保持ping 驱动其运行的可靠套件是另一个关键因素。一套烟雾检测套件只有保持紧凑、快速和可重复性，才能真正发挥作用。
- 首先绘制关键路径图： 列出使产品具备商业可用性的工作流程，例如登录、搜索、数据录入、支付和注销。如果其中任何一个环节出现问题，该版本对测试人员来说就毫无价值。
- 套房要浅而宽： 与其深入研究某个模块，不如对每个主要模块都进行一次测试。边界值、负面数据和错误信息措辞应该在功能测试中讨论，而不是在这里。
- 限制执行时间： 大多数球队将跑步时间控制在十到十五分钟之间，并将包厢使用时间限制在二十到三十分钟左右。 测试用例耗时一小时的跑步不再是通道，而是瓶颈。
- 每次构建都运行相同的用例： 一致性使您可以将失败归因于代码，而不是归因于测试选择的更改。
- 移除不稳定和依赖项过多的情况： 如果一个测试用例在没有任何代码更改的情况下通过或失败，就会破坏人们对测试门的信心。对于不稳定的第三方服务，应使用桩或模拟的方式进行测试。 测试自动化框架 允许。
- 记录一项明确的判决： 每个案例都需要一个单一的预期结果，以便可以毫无争议地接受或拒绝构建。
- 使用构建版本对套件进行版本控制： 将冒烟测试用例存储在与应用程序代码相同的存储库中，以便测试用例始终与被测版本匹配。
Rev每次发布新版本时都要查看套件：删除不再重要的功能案例，并添加新的关键工作流程。
CI/CD 流水线中的冒烟测试
这样设计的测试套件成本足够低，可以在每次提交时运行，这正是现代交付流程所需要的。 持续整合 例如服务器 Jenkins 编译代码，将其部署到预发布环境，然后触发冒烟测试套件作为第一个自动化阶段。如果测试通过（绿色），则将工件提升到功能测试和回归测试阶段；如果测试失败（红色），则流水线失败，并在几分钟内通知提交代码的开发人员。
两种常见的部署方式是：合并前测试，通过验证每个拉取请求来保护主分支；部署后测试，确认已部署的环境可访问且配置正确。实践持续部署的团队通常会在发布后立即对生产环境进行第三次精简版测试。
由于该流水线每天要多次执行测试套件，因此测试用例必须是非交互式的、可自动清理且相互独立的。任何需要等待人工决策或遗留测试数据的测试用例都会导致流水线运行停滞。
烟雾测试的优势
这里列出了烟雾测试的一些优点。
- 操作简便，运行速度快
- 关键错误和缺陷很容易在早期阶段被发现和纠正。
- 提高系统质量
- 降低风险
- 进展更容易评估。
- 节省测试精力和时间
- 最大限度地降低整合风险
⚠ 注意限制： 一次通过的冒烟测试只能说明构建版本可以进行测试。它对主要功能进行浅层测试，因此一些细微缺陷、极端情况和不常用的功能只有在进行功能测试和回归测试时才会被发现。切勿将冒烟测试结果为绿色视为构建版本完全没有缺陷的标志。
冒烟测试、健全性测试和回归测试
这三者都在代码更改后运行，因此经常被混淆。它们的作用范围、深度以及各自回答的问题都不相同。
在开发环境中对代码进行测试，以确保应用程序在发布到质量保证（QA）环境之前具备正确性，这被称为冒烟测试。该测试旨在验证正在开发的应用程序是否满足其基本功能需求。
健全性测试决定开发阶段的完成度，并决定软件产品是否通过进一步的测试阶段。
| BASIS | 烟雾测试 | 健全性测试 | 回归测试 |
|---|---|---|---|
| 适用范围 | 宽阔而浅 | 狭窄而深 | 宽阔而深 |
| 问题已解答 | 这个版本是否足够稳定，可以进行测试？ | 这个方法有效吗？ | 以前能用的东西有坏掉吗？ |
| 序列 | 首先，在每次构建过程中 | 烟雾测试通过 | 经过健全性测试 |
| 典型持续时间 | 10到15分钟 | 30到60分钟 | Hours 几天 |
| 自动化适配 | 很高 | 中等强度，通常需要人工操作 | 很高 |
实际上，它们是按顺序进行的：冒烟测试用于验收构建版本，健全性测试用于验证交付的变更，回归测试则在时间允许的情况下进行。
烟雾测试用例示例
下表记录了一个简短的烟雾测试套件，每行代表一条关键路径。
| 財產編號 | 测试场景 | 商品描述 | 测试步骤 | 预期结果 | 实际结果 | 状态 |
|---|---|---|---|---|---|---|
| 1 | 有效的登录凭据 | 测试 Web 应用程序的登录功能，以确保注册用户可以使用用户名和密码登录 | 1.启动应用程序 2.导航至登录页面 3.输入有效的用户名 4.输入有效密码 5.点击登录按钮 |
登录应该成功 | 不出所料 | 通过 |
| 2 | 添加项目功能 | 能够将商品添加到购物车 | 1.选择类别列表 2.将商品添加到购物车 |
商品应添加到购物车 | 商品未添加到购物车 | 失败 |
| 3 | 注销功能 | 检查注销功能 | 1. 选择退出按钮 | 用户应该能够退出。 | 用户无法退出 | 失败 |
