偶发失败的常见根因
flaky（偶发失败）指用例在没有代码变更的情况下时过时不过，根因大致分四类：等待与同步不足、测试间状态污染、外部依赖不稳定、并发与时序竞争。治理思路是先定位类别再分类处置——换执行顺序能复现的多是状态污染，本地稳定 CI 偶发的多是同步不足。统一加重试只会掩盖根因，还抬高执行成本。
根因分类
| 根因 | 典型信号 | 治理方向 |
|---|---|---|
| 同步不足 | 本地稳定、CI 偶发 | 条件等待替代固定延迟 |
| 状态污染 | 换执行顺序可复现 | 用例隔离与自清理 |
| 外部依赖 | 第三方接口抖动 | 桩化或显式重试策略 |
| 并发竞争 | 高并行才出现 | 关键段串行化或加锁 |
基本信息
| 定义 | 无代码变更时同一用例结果不稳定 |
|---|---|
| 定位手段 | 单独重跑、换序执行、降并行、查看失败附件 |
| 重试定位 | 重试只能当临时止血，不能当治理手段 |
| 度量方式 | 按用例统计 flaky 率，进入质量看板跟踪 |
| 治理顺序 | 先隔离定位根因，再决定修复、桩化或移除 |
典型使用场景
- CI 巡检：对失败用例自动重跑并标记 flaky，输出清单。
- 发布前决策：区分真失败与 flaky，避免错误阻塞发布。
- 新用例评审：把「可能引入时序假设」的写法拦在合并前。
- 季度治理专项：按分类批量修复高频 flaky 用例。
- 并行度调整：高并行出现的竞争类问题按信号定向排查。
- 上报口径：flaky 率与失败分布纳入测试健康度周报。
Google 的 flaky 治理经验：先识别来源再分类处置，而不是统一加重试。
失败附件先看再改：截图、trace、日志与网络记录能把四类根因直接缩小到一类。
新引入的 flaky 优先当天处理：拖到积压后，定位成本随上下文丢失急剧上升。