测试套件的运行与维护成本
测试套件有两个必须同时关注的成本：运行时长决定反馈速度，维护成本决定可持续性。可观察的量包括全量运行时长、单个用例的失败率（随机失败比例）、以及为适配实现改动而修改测试所占的比例。目标是把主流程控制在十分钟量级，并通过定期修剪保持套件精简，而不是不断追加用例。
观察指标
| 运行时长 | 全量与关键子集的耗时，目标主流程十分钟级 |
|---|---|
| 随机失败比例 | 同一提交多次运行结果不一致的用例占比 |
| 维护改动占比 | 为适配实现细节而修改测试的比例 |
| 修剪机制 | 定期删除重复、失效与低价值用例 |
典型使用场景
- 反馈速度下降：统计各层耗时，找出拖慢整体的少数用例
- 随机失败治理：把反复失败又难以复现的用例单独列出，逐个定性
- 测试维护成本上升：实现改一处要改十几个测试，说明测试与实现耦合过紧
- 并行化改造：先分层再并行，按耗时把用例分配到不同分片
- 定期修剪：每季度清理重复与失效用例，控制套件规模
优化顺序
优化顺序
# 按收益从高到低处理
1. 先分层：单元测试秒级、集成测试分钟级、端到端按需触发
2. 再并行：把用例分片执行，缩短墙钟时间
3. 再缓存：复用依赖与构建产物，避免每次重装
4. 定期修剪：删除重复与长期失效的用例，控制规模
5. 最后才考虑加机器：前面几步通常收益更大常见问题与处理
| 问题 | 原因 | 处理方式 |
|---|---|---|
| 全量时长持续增长 | 用例只增不减 | 建立修剪机制，按季度清理 |
| 随机失败反复出现 | 共享状态、时间或网络依赖 | 隔离状态，固定时钟，替换外部依赖 |
| 实现改动导致大量测试修改 | 测试与实现细节耦合 | 改为按行为断言，避免断言内部结构 |
| 端到端覆盖过多 | 缺少分层设计 | 把业务规则校验下沉到单元与集成层 |
| 本地与流水线结果不一致 | 环境与依赖版本不同 | 统一依赖版本与环境配置 |
随机失败要单独归类处理：把「偶发失败仍可通过」当作常态，会让真实缺陷逐渐被忽略。对反复失败的用例，要么修复根因，要么明确标记并限期处理。
只加测试不删测试是套件膨胀的主要原因。修剪时先删重复覆盖与长期无效的用例，再评估低频用例是否可以改为按需触发。
落地检查清单
- 主流程测试时长在十分钟量级以内
- 随机失败用例有清单与处理期限
- 测试按行为断言，而非绑定实现细节
- 有定期修剪机制与责任人