做了十几年测试经历过无数次重跑一下就好了。直到把数据摆出来才发现这个问题比所有人想象的都严重。一、重跑一下就好了——三个字的代价你一定听过这句话。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 的团队占比流水线复杂度变化202210%基准线202526%23%三年时间受 Flaky Test 困扰的团队比例涨了160%。为什么在恶化测试体量爆炸单元、集成、E2E 越写越多出问题的表面积越来越大流水线复杂度上升步骤多了、环境多了、非确定性行为的触发点也多了并行执行引入新故障模式多容器、多分片跑测试时序竞争和状态共享的问题在串行时代根本不存在外部依赖成倍增长每个 API 调用、云服务、第三方数据库都是一个新的不稳定因子说白了测试的问题空间增长速度超过了工具和实践的跟进速度。三、大厂的 Flaky Rate 长什么样这不是小公司才有的问题。看看公开数据的头部公司公司指标数值来源Google存在 Flaky 行为的测试占比16%Google Testing BlogGoogle单次执行的 Flaky 率1.5%Google Testing BlogGoogle绿→红转换中由 Flaky 导致的占比84%Google Testing BlogAtlassianJira 后端仓库失败中 Flaky 占比15%Atlassian EngineeringAtlassianJira 前端 master 构建失败中 Flaky 占比21%Atlassian EngineeringMicrosoft测试失败中 Flaky 占比13%Microsoft ResearchGitHub产生 Flaky 红构建的提交占比9%GitHub大型企业调研超过 5% 非确定性结果的组织占比24%LambdaTest 2026Google 那个 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()做断言UTC8 和 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-runRe-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 有时候会莫名其妙挂。如果你也不确定自己团队的状况可以这样算挑一个 30 天的窗口统计期间内出现过同代码同环境有时过有时不过的测试用例数量除以总测试用例数这就是你的 Flaky Rate拿这个数去对比上面的大厂基准线看看自己在什么水平。七、我想听听你们的情况这篇文章的核心目的不是给答案而是收集真实反馈。因为 Flaky Test 这个话题学术研究和工业实践之间有很大的 gap而 gap 里藏着真正有价值的一手经验。我想了解的问题你团队的 Flaky Rate 大概是多少不用精确一个体感数字就行你们有在做 Flaky Test 的系统性度量吗还是全靠重跑你遇到最多的 Flaky 根因是哪类异步等待环境差异数据依赖你们怎么治理 Flaky Test隔离重试修复删除有没有明确的 SLAFlaky Test 对团队的 CI/CD 信心影响有多大开发者看到红灯第一反应是什么有没有什么工具或方法论你觉得特别管用不管你是 5 人创业团队还是大厂的 QA你的一手数据都很有价值。评论区聊也可以私信交流。我会把收集到的反馈做一期汇总分析看看不同团队、不同规模、不同技术栈之间Flaky Test 的真实面貌到底长什么样。参考资料Bitrise Mobile Insights 2025覆盖 10M 构建数据Google Testing BlogFlaky Test 系列研究Atlassian Engineering Blog 2025Jira Flaky Test 治理Microsoft ResearchFlaky Test 分类与检测Luo et al.Apache 项目 Flaky Test 根因分析LambdaTest State of Testing Survey 2026ICST 2024/2025 多篇实证研究