一、现象或背景：CI 跑用例慢到影响研发体验
我维护的 B 端 SaaS 接口测试套件（Java 17 + JUnit 5.10 + Testcontainers + PostgreSQL 15）有 1380 个用例，串行执行耗时 47 分钟。问题不仅是「慢」，更带来三个连锁反应：
- 研发等待反馈慢：平均等 20 分钟才能拿到第一个失败，35% 的 MR 在合并前没跑完回归；
- 没人敢并行化：团队有个「传说」：用例必须按文件名字母序跑，打乱顺序就会挂；
- 夜间回归资源挤占：套件超时会挤占下一个团队的环境窗口，导致互相投诉。
一句话：套件被「顺序」这个隐式假设锁死了，而没人说得清这个假设是否成立。
二、原理或根因：为什么「顺序」会变成依赖
通过随机打乱顺序跑，发现 15.5% 的用例会失败。进一步分析发现：
根因三类（占比约）
- 共享可变数据（60%）：用例 A 建了一个「已对账」的结算单，用例 B 直接按固定单号去查并断言状态。B 依赖了 A 的写操作，而不是自己准备数据。
- 静态 / 全局状态残留（25%）：测试工具类里有个
static Map<String,Token> sessionCache，登录用例往里塞 token，后续鉴权用例直接读，谁先跑谁受益。 - 数据库序列 / 主键假设（15%）：有 32 个用例硬编码断言「新建记录 id == 某起始值」，一旦前面有别的用例先插了数据，id 就偏了。
机制上讲，这三类本质都是测试用例没有做到「自包含」：它的通过与否，取决于「之前谁跑过」，而不是「它自己做了什么」。串行只是把这些依赖用时间顺序「掩盖」了，一旦乱序或并行，依赖链断裂，假失败就冒出来了。
三、具体做法：四步把顺序依赖拆干净，再并行
第 1 步：把「哪些用例依赖顺序」找出来
不靠猜，靠跑。用 JUnit 的 RandomOrder（@Randomize 或 surefire 的 -Djunit.jupiter.execution.order.random.seed）让顺序随机，跑 3 轮，取「随机挂、顺
0赞
0收藏
0评论
0浏览