答案。

问题历史:

烟雾测试（"烟测试"）作为一种快速检查系统在构建后是否可用的方法而产生。它的目标是确保关键功能正常工作，并且应用程序适合进行进一步更深入的检查。在手动测试中，烟雾测试通常在新版本产品部署后立即执行。

问题:

主要的难点在于时间有限，必须选择真正重要的检查。测试人员常常要么检查过多（浪费资源），要么遗漏关键内容，从而导致发布时出现“漏洞”。

解决方案:

正确组织烟雾测试的关键在于选择严格的最小场景集，覆盖最重要的用户流程。这些检查应该是明确、快速和可重复的。例如：

- 用户成功登录系统
- 执行主要功能的能力（例如，进行购买）
- 进行支付并收到确认

关键特点：

• 烟雾测试仅涵盖至关重要的功能
• 快速执行，这在频繁发布时至关重要
• 所有场景都根据预先批准的检查清单手动执行

诱导性问题。

可以认为烟雾测试是回归测试的完整替代方案吗？

不可以，烟雾测试仅关注关键功能的“工作-不工作”状态。要发现严重但未显现的bug，始终需要全面的回归测试。

如果至少一个烟雾测试未通过该怎么办？测试是否应该继续？

不，进一步的测试没有意义——团队会报告问题，发布会被阻止，直到bug被修复。

烟雾测试是否应包括边缘案例的检查？

不，烟雾测试不设计用于检查边缘案例。它们仅用于确认主要产品功能的可用性。

常见错误和反模式

• 执行多余的测试，这些测试对可用性并不关键
• 缺乏烟雾测试的文档（测试人员“记在心里”）
• 为了“报告性”而忽视明显的问题

生活中的例子

消极案例

根据包含不重要功能的详尽检查清单进行了烟雾测试。花了很多时间，因此发布延迟了半天。

优点：

• 发现了一些不明显的bug

缺点：

• 发布延迟
• 在不重要的检查上消耗了资源和时间

积极案例

烟雾测试仅专注于最关键的场景。快速发现了阻塞性bug并报告给团队——在修复之前发布被暂停。

优点：

• 对关键bug的快速反应
• 节省时间

缺点：

• 某些不显着的bug未被发现，但在后续的回归测试阶段被发现。