答案。

问题历史：

Smoke测试（烟雾测试）最初是作为一种快速的方法，用于确认系统在部署或代码更改后，最基本的功能是否正常。它们的理念是：“如果有一些关键功能损坏，就没有必要进行详细检查。”在自动化中，最初的Smoke测试都是作为小型手动脚本实现的，用于检查应用程序的启动、登录屏幕的显示和基本操作。

问题：

自动化Smoke测试的主要困难在于正确隔离最小的场景集、高效执行、尽量减少对不稳定组件（例如第三方服务）的依赖，以及对其“轻量性和透明性”的视觉和技术支持。如果不这样做，Smoke自动化要么变得过于复杂，要么经常出现误触发，需要大量维护。

解决方案：

• 最小化Smoke测试的数量：它们只应检查最关键的“入口点”（例如，授权、主模块启动、数据库可用性）。

• 将不稳定步骤和外部依赖移出Smoke场景，或者用“桩”稳定环境。

• 使用标记（@smoke、Suite('smoke')等）和CI/CD管道中的单独部分，以确保始终优先执行Smoke测试。

关键特点：

• Smoke场景应快速执行，并仅使用最稳定的基础设施部分。
• Smoke测试不应覆盖用户体验细节或复杂工作流程。
• Smoke自动化需要对依赖关系进行严格控制，并保留最少的支持代码。

诱导性问题。

可以在Smoke集合中添加边缘案例逻辑的场景吗？

不可以，Smoke集合仅用于验证主要系统的可行性和可用性，边缘案例在这里是多余的，它们会减慢执行并增加维护复杂性。

在Smoke测试中需要实现多级错误处理和恢复机制吗？

人们常常错误地认为Smoke需要复杂的恢复机制。实际上，如果Smoke测试失败，则这表明存在关键问题，需要修复，而不是在自动测试中“绕过”。

Smoke测试是否应依赖其他测试留下的数据？

不，Smoke测试不应依赖任何外部测试数据，更不应依赖其他测试的工件。这是其可靠性的关键原则之一。

常见错误和反模式

• Smoke测试过载：场景过多，变成回归检查。
• Smoke测试和常规测试之间的代码重复。
• 隐性依赖：测试使用了其他场景的“脏”数据/工件。

生活中的例子

负面案例

在Smoke场景中设置了30个不同的检查，其中一部分不仅测试系统启动，还测试复杂算法和边缘案例条件。Smoke启动的执行时间变为30分钟，某些检查由于后端不稳定而定期失败。

优点：

• 容易发现系统的瓶颈。
• 部署后测试覆盖率高。

缺点：

• Smoke的本质丢失：“绿色”构建只能在长时间等待和解决与系统推出无关的小问题后才能获得。
• 测试难以维护，难以识别实际的关键故障。

正面案例

在Smoke组中设置了严格的最低限度：登录、打开主页、请求数据库、基本API握手。Smoke框架独立于主要测试矩阵，并始终是CI/CD管道中的第一个。结果通过单独的聊天进行共享，始终可用于快速诊断。

优点：

• 快速（2-3分钟）获得系统可行性的结果。
• 由于测试的隔离和简单性，虚假警报最少。

缺点：

• 如果仅在Check运行中使用Smoke测试，可能会错过“非基础”的缺陷。