答案。

Flaky 测试是指由于随机外部因素而在代码不变的情况下可能通过或失败的测试。它们削弱了对自动化测试的信任，并使 CI/CD 过程变得更加困难。

问题的历史： 随着大规模 E2E、集成和 UI 测试的出现，flaky 测试的问题开始显露，环境及依赖服务的稳定性无法保证。起初，这些故障常常被忽视，或者“手动重启”。

问题：

• Flaky 测试使得自动化测试变得不可靠。
• 开发者开始错过真正的故障，将其视为错误。
• 测试维护时间增加，需要手动分析不稳定的结果。

解决方案：

1. 单独记录 flaky 测试。 使用标签（例如 @FlakyTest）或将其归为单独类别。
2. 自动重试。 在测试失败的情况下，重复执行测试 X 次 — 如果不是每次都失败，就将其标记为不稳定测试。
3. 分析不稳定原因： 使用日志、状态快照、资源监控（例如，不稳定的网络、队列或 GC 运行）。
4. 逐步修复： 从测试环境着手，简化场景，模拟不稳定的依赖。

自动重试的示例代码：

import pytest
@pytest.mark.flaky(reruns=3, reruns_delay=2)
def test_random_fail():
    ... # 测试代码

关键特性：

• 重要的是将 flaky 测试与真正的失败区分开来
• 不应仅仅“重试一切” — 真实的缺陷不应被忽视
• 定期分析和记录测试状态，而不是沉默不语

陷阱问题。

Flaky 测试总是基础设施的问题吗？

不是，flaky 测试可能由业务逻辑错误、代码竞态、异步行为或时间处理不当引起。

仅仅重启失败的测试是否足够？

不是，重试只是掩盖问题。需要查找并解决根本原因。

是否应该删除所有不稳定的测试？

不是，要暂时隔离它们并修复原因，而不是简单地永远排除。

常见错误和反模式

• 忽视 flaky 测试，导致严重缺陷的遗漏。
• 大规模重试而不分析原因。
• 将重要测试标记为 flaky 而不采取修复措施。

实际案例

负面案例

在项目中，flaky 测试只是被标记并不再修改，认为这是一个“无法解决”的问题。

优点：

• 降低了假性的“红色”构建数量。

缺点：

• 真实的缺陷进入了生产；
• 不断需要人工检查结果。

正面案例

对每个不稳定的测试引入了自动重试和内部的不稳定记录。定期进行共同审查原因，并在缺陷积累时进行修复。

优点：

• 测试系统稳定性的逐步提高；
• 快速发现和修复新的 flaky 测试。

缺点：

• 需要定期的资源进行不稳定分析的工作。