答案。

自动测试的稳定性是可靠的 CI/CD 和对自动化信任的重要方面。

问题的历史

最初，自动测试是手动运行的，不稳定性并没有造成很大困扰。随着测试数量的增加和集成到管道中，Flaky 测试（有时会无明显原因失败的测试）的出现成为了一个大问题。

问题

Flaky 测试导致：

• 误报和对测试的不信任
• 发布延迟（重启）
• 真实错误查找的难度

解决方案

有助于稳定性的方法：

• 使用“等待”（显式/隐式等待，sleep — 仅在没有其他选择时使用）
• 在测试开始前准备好测试环境
• 将长/复杂的自动测试拆解
• 固定测试数据，在测试后清理
• 分析日志：理解测试何时何因失败

使用等待的示例：

WebDriverWait(driver, 10).until(
    EC.presence_of_element_located((By.ID, "result"))
)

关键特点：

• 分析不稳定的原因
• 正确管理测试数据
• 使用合理的等待和正确初始化环境

诱导性问题。

大规模重试能解决 flaky 测试问题吗？

不，这只是暂时的“补救措施”。并没有消除原因——仅仅掩盖了现存的问题。

可以只在夜间运行自动测试，以避免因负载导致的故障吗？

夜间运行并不能消除不稳定性，只是降低了发生的可能性；问题依然存在，必须解决其根源。

所有的 flaky 测试都应该立即删除吗？

不。最好尝试找出原因并修复——只有在无法使其稳定或这是过时、不相关的测试时才删除。

常见错误和反模式

• 到处使用 sleep，而不是显式等待
• 缺乏清理程序（tearDown）
• 在“脏”环境中运行测试

生活中的例子

负面案例

团队对不断失败的测试进行了大规模重试。结果，“绿色”测试的列表增加了，但自动测试的质量没有提高——错误被漏过。

优点：

• CI/CD 经常显示“绿色”结果

缺点：

• 只有手动发现问题，生产中的错误增加

正面案例

团队找到了并描述了系统性的 flaky 原因：未清理的数据、UI 延迟、网络故障。修复了架构，增加了合理的等待，设置了环境——不稳定测试的数量大幅减少。

优点：

• 对自动化的信任
• 实际提升了发布的稳定性

缺点：

• 分析和重构测试及环境耗费了时间