你们的 Flaky Test 有多严重？

做了十几年测试，经历过无数次"重跑一下就好了"。直到把数据摆出来，才发现这个问题比所有人想象的都严重。

一、"重跑一下就好了"——三个字的代价

你一定听过这句话。

CI 一片红，你点开日志，是那个熟悉的用例——昨天挂了，今天早上过了，现在又挂了。你点了 Re-run，绿灯亮了，所有人继续干活。

没有人在意。

Google 的测试团队在意了。他们做了一件很硬核的事：统计了 CI 里所有"从绿变红"的 case，发现84% 的测试失败是由 Flaky Test 引起的。也就是说，你的 CI 里每报 10 个"失败"，8 个半是假的。

Atlassian 更直接：Jira 后端仓库15% 的构建失败是 Flaky Test，前端更夸张——21%。他们专门做了工具来治理，结果呢？一年还是浪费了超过15 万小时的开发者时间。

15 万小时。按一个人一年 2000 工时算，相当于 75 个人一年的工作量，全花在了跟 Flaky Test 搏斗上。

二、数据说话：这个问题在恶化，不是在好转

你以为框架越来越成熟、AI 越来越强，Flaky Test 应该越来越少？

Bitrise 做了一份覆盖1000 万+次构建（2022.1 到 2025.6）的分析报告，结论很扎心：

三年时间，受 Flaky Test 困扰的团队比例涨了160%。

为什么在恶化？

• 测试体量爆炸：单元、集成、E2E 越写越多，出问题的表面积越来越大
• 流水线复杂度上升：步骤多了、环境多了、非确定性行为的触发点也多了
• 并行执行引入新故障模式：多容器、多分片跑测试，时序竞争和状态共享的问题在串行时代根本不存在
• 外部依赖成倍增长：每个 API 调用、云服务、第三方数据库都是一个新的不稳定因子

说白了：测试的问题空间增长速度，超过了工具和实践的跟进速度。

三、大厂的 Flaky Rate 长什么样？

这不是小公司才有的问题。看看公开数据的头部公司：

Google 那个 1.5% 的单次执行率看着很低对吧？但别忘了分母——Google 每天跑数百万次测试。1.5% 乘以几百万，就是几万次假失败。而且 16% 的测试库存在 Flaky 行为，意味着你随便抽 7 个测试，就有 1 个会在某个时刻表现异常。

再看那个 84%：你的 CI 每次报红，你第一反应是"我代码出 Bug 了"。但有 84% 的概率，那只是 Flaky Test 在叫你去看它一眼。

这就是信任侵蚀的开始。

四、Flaky Test 的 6 大根因（附真实场景）

学术界有 Luo et al. 对 Apache 项目 201 个 Flaky 修复 commit 的经典分类，也有 2025 年 ICST 对 49 个开源 Web 项目 123 个 Flaky Test 的实证研究。结合工业界实践，根因基本跑不出这 6 类：

1. 异步等待问题（占比约 45%——第一大杀手）

测试代码用time.sleep(2)等一个元素出现。CI 负载一重，渲染要 2.3 秒，挂了。下次跑快了，又过了。

真实场景：E2E 测试等一个弹窗动画结束，本地机器 1.8 秒搞定，CI 上跑了 2.5 秒。测试团队加了time.sleep(3)，三个月后 CI 升级配置变慢了，3 秒也不够，又加到 5 秒。现在 suite 里到处都是sleep(5)，整个回归跑完要 40 分钟。

正确做法：用显式条件等待（waitForSelector、WebDriverWait），等状态变化而不是等时间流逝。

2. 并发与竞态条件（约 20%）

测试假设了线程执行顺序，但系统不保证这个顺序。通过了是运气，不通过才是真相。

真实场景：多线程服务测试里，主线程写了数据、子线程读数据。本地串行跑没问题，CI 开了 8 个 worker 并行跑，子线程偶尔抢在主线程前面读，读到空值就挂了。

注意：约 1/3 的并发类 Flaky，问题不在测试代码，而在生产代码的并发 bug。修测试只是在掩盖真实缺陷。

3. 测试顺序依赖（Python 项目的第一大根因）

测试 A 创建了一个用户，测试 B 依赖这个用户存在。如果 B 在 A 前面跑——挂了。本地顺序跑没事，CI 一并行就炸。

真实场景：一个 Python 项目跑了 1000+ 测试，发现 30% 的 Flaky 来自测试间共享了数据库状态。测试 C 删了某条记录，测试 D 期望那条记录存在。单独跑 D 没问题，C→D 跑就炸。

核心问题：每个测试应该是完全独立的——自己 setup、自己 teardown。不共享数据库记录、不共享 Session、不共享环境变量。

4. 环境与平台差异（约 28% of Python Flaky）

本地跑的过，CI 上跑不过。文件路径分隔符不同、时区不同、Node 版本不同、系统依赖缺失。

真实场景：一个 Node.js 项目，macOS 开发机上全过，Linux CI 上 3 个测试固定挂。排查了一周发现是时区问题——测试里用了Date.now()做断言，UTC+8 和 UTC 跑出来结果不同。

5. 外部服务依赖

测试调了一个第三方支付 API，对方短暂 503，测试挂了。应用代码没问题，但 CI 红了。

真实场景：回归测试里有 5 个用例依赖外部短信服务。每次短信服务限流或抖动，就挂一两个。测试团队一开始以为是偶发问题，加了 retry。半年后统计，这 5 个用例贡献了 40% 的"失败"记录。

6. UI 定位器脆弱

开发改了按钮文案从"提交"改成"发送请求"，测试按文案定位，挂了。

真实场景：前端重构了组件树，DOM 结构全变了。80 个 E2E 用例一夜之间全红，但后端一行代码没改。

五、真正的代价不是时间，是信任

时间成本已经够吓人了：Google 的数据显示，开发者2% 的编码时间花在 Flaky Test 调查上。50 人的团队，按人均年薪 12 万美元算，一年就是12 万美元纯浪费。企业级团队更夸张——LambdaTest 调研显示，QA 团队8% 的时间花在 Flaky Test 上。

但更大的代价是隐性的：信任侵蚀。

当 CI 里 84% 的"失败"是假警报，开发者的行为模式会变成：

• 看到红灯 → 不看日志 → 直接 Re-run
• Re-run 过了 → "果然不是我的问题" → 继续干活
• Re-run 还红 → 再 Re-run 一次 → 三次都红才去查

这就是"重试陷阱"。

真正的灾难在于：当团队习惯了无视红灯，那一次真正由 Bug 导致的失败也会被无视。

Google 自己的应对方式：测试最多重试 3 次，3 次都失败才报红。这不是因为重试是对的，而是因为到了 Google 这个规模，重试是"伤害最小"的妥协方案。

GitLab 的做法是隔离：Flaky Test 一旦确认，立即 quarantine（隔离），不阻塞主分支，异步修复。

Spotify 的 Master Guardian 策略：已知的 Flaky Test 在合并前直接跳过，不计入门禁结果。

这些大厂的共识是：Flaky Test 不能阻塞流水线，但也不能放任不管——必须可见、可追踪、有 SLA 地修复。

六、你团队的 Flaky Rate 是多少？

说到这儿，有几个问题我想做个调研。

做了这么多年测试，我在不同团队见过从 0.5% 到 30% 的 Flaky Rate。差异巨大，关键区别在于：团队是否在做度量。

大部分团队不做度量。他们不知道自己的 Flaky Rate 是多少，不知道哪些用例是高频 Flaky，不知道 Flaky 在吃掉多少 CI 资源。他们只知道"CI 有时候会莫名其妙挂"。

如果你也不确定自己团队的状况，可以这样算：

1. 挑一个 30 天的窗口
2. 统计期间内出现过"同代码同环境有时过有时不过"的测试用例数量
3. 除以总测试用例数
4. 这就是你的 Flaky Rate

拿这个数去对比上面的大厂基准线，看看自己在什么水平。

七、我想听听你们的情况

这篇文章的核心目的不是给答案，而是收集真实反馈。因为 Flaky Test 这个话题，学术研究和工业实践之间有很大的 gap，而 gap 里藏着真正有价值的一手经验。

我想了解的问题：

1. 你团队的 Flaky Rate 大概是多少？（不用精确，一个体感数字就行）
2. 你们有在做 Flaky Test 的系统性度量吗？还是全靠"重跑"？
3. 你遇到最多的 Flaky 根因是哪类？异步等待？环境差异？数据依赖？
4. 你们怎么治理 Flaky Test？隔离？重试？修复？删除？有没有明确的 SLA？
5. Flaky Test 对团队的 CI/CD 信心影响有多大？开发者看到红灯第一反应是什么？
6. 有没有什么工具或方法论你觉得特别管用？

不管你是 5 人创业团队还是大厂的 QA，你的一手数据都很有价值。评论区聊，也可以私信交流。

我会把收集到的反馈做一期汇总分析，看看不同团队、不同规模、不同技术栈之间，Flaky Test 的真实面貌到底长什么样。

参考资料：

• Bitrise Mobile Insights 2025（覆盖 10M+ 构建数据）
• Google Testing Blog（Flaky Test 系列研究）
• Atlassian Engineering Blog 2025（Jira Flaky Test 治理）
• Microsoft Research（Flaky Test 分类与检测）
• Luo et al.（Apache 项目 Flaky Test 根因分析）
• LambdaTest State of Testing Survey 2026
• ICST 2024/2025 多篇实证研究