自动化用例只增不减，大家有给测试用例定"退役机制"吗？

背景

我做了 3 年测试开发，最近盘点自己维护的接口自动化套件（pytest，约 2000 条用例）时撞上一堵墙：套件从 2024 年初的 600 条涨到 2000 条，但同期线上事故数并没有同比下降多少；而每次大版本重构后，回归跑一遍要 40 分钟，其中至少 300 条用例在测的接口路径已经和线上实现完全不一致（只是没人删）。

我逐渐怀疑：用例数量的增长，可能和质量的提升是两件事，甚至经常是反着的。

常见分歧（我观察到的三种做法）

1. 只增不减派：每上一个需求就加用例，删一条都觉得"万一呢"。结果是套件越来越慢，flaky 比例水涨船高，大家开始习惯性 skip，最后套件形同虚设——我见过最夸张的是 CI 红了没人看，因为"那条用例上周也是红的"。
2. 定期大扫除派：每半年或每个大版本做一次用例盘点，按"最近 N 个月没抓到过 bug / 跑一次就挂 / 断言太弱"批量删。效果好，但属于运动式治理，不运动就回潮。
3. 数据驱动退役派：给每条用例打标（覆盖的场景类别、最近一次抓到 bug 的时间、历史 flaky 次数），用数据说话，超过阈值自动进"候选退役清单"，走评审后下线。工程成本最高，但我觉得是唯一能长期维持的做法。

我的倾向

我倾向第 3 种，但要配一个前置动作：给"用例"建和"代码"一样的生命周期规范——新增用例要有验收标准（它到底守护哪条业务规则），下线用例要有归档记录（为什么下线、被谁替代）。核心原则是：一条用例的价值 = 它过去抓到的 bug 的价值 − 它的维护成本。抓过 P0 的用例值得养，跑 100 次挂 80 次且没人看的用例该退役。

想听听大家

• 你们团队有没有明确的"用例退役"标准？阈值大概是什么（比如多少个月没抓到 bug 就进候选清单）？
• 删用例的评审一般谁来拍板？测试自己删、开发确认、还是 TL 拍？
• 有没有哪种场景你觉得"再烂的用例也不能删"？（比如合规审计、资金安全？）
• 你们怎么衡量"套件健康度"——只看通过率，还是看别的指标（比如"有效 bug 捕获率"）？

欢迎带具体数字来聊，空对空的"要定期清理"咱们就不必重复了。