自动化测试用例「退役标准」你们怎么定？聊聊删用例的勇气与代价

背景

做了 8 年测试开发，我越来越觉得一个尴尬的事实：我们天天教团队「测试代码也是代码，要 review、要重构、要删死代码」，但真正落到「删一条自动化用例」这件事上，绝大多数团队都卡住了。

我最近盘了一条 B 端 SaaS 的接口自动化套件（Python 3.11 + pytest，约 1200 条用例），发现：

• 其中 300+ 条用例的断言只有 assert resp.status_code == 200，业务字段一个没校验；
• 大概 80 条对应的接口在 2 个版本前就下线了，但用例一直「绿着」——因为 mock 还在，所以它测的是空气；
• 最近一次「认真跑全量回归」花了 47 分钟，其中约 15 分钟花在「环境初始化 + 造数」上，真正在断言业务行为的时间不到一半。

我们团队内部争论了两次，每次都没结论。今天抛出来，想听听大家是怎么定的。

常见分歧（我归纳的三种典型做法）

1）激进派：设「用例存活期」——连续 N 个季度没有发现任何真实缺陷、且断言强度低于阈值的，直接删。口号是「测试套件应该越跑越小，而不是越跑越大」。 2）保守派：用例只标记不删除（@deprecated / skip），理由是「删了万一线上炸了那个场景，谁负责？」实际结果是套件越滚越大，跑一轮 2 小时，没人敢动。 3）务实派：不按时间，按「缺陷发现率 + 断言强度」双维度评估。用例分 A/B/C 三档：A 档（抓过线上问题、断言覆盖核心业务字段）必须保留并加固；B 档（断言合理但从未抓过问题）保留但降频跑；C 档（断言只有 200、或对应接口已下线）进入退役候选。

我的倾向与理由

我偏向第 3 种，但会叠加两条硬约束：

• 删除前必须做「场景可达性确认」：把这条用例对应的业务路径列出来，确认没有其他用例覆盖同一路径的核心断言。不是「我觉得没人测这个了」，而是「我查过了，路径 X 的断言由用例 Y 覆盖」。
• 删除走「软删除 → 硬删除」两步：先标 deprecated，跑至少一个完整版本周期（我们是一个 sprint，约 2 周），期间如果没人提「这条删了会不会出事」，再物理删除。

踩过的坑：

• 最痛的是一次「删了 50 条用例」之后第 3 个月，线上一个边缘场景（多租户 + 特殊币种 + 特定状态机组合）炸了。复盘发现那条被删的用例断言确实很弱（只校验 200），但它覆盖的「特殊币种路径」恰好没有其他用例触碰。教训：弱断言不等于无用例价值，「这条没断言」和「这条对应的路径没人测」是两件事。
• 另一个坑是「僵尸 mock」：接口下线了但 mock server 还在，用例一直绿，团队误以为「这个功能还活着、还测着」。这类用例比「没写测试」更危险，因为它制造了虚假安全感。

想听大家在什么场景下怎么选？

1）接口已经下线、但 mock 还在、用例还在「绿着」——你们直接删，还是先确认没人依赖？ 2）断言只有 status_code == 200 的用例，你们是「加固到至少校验 3 个业务字段再保留」，还是「直接进退役候选」？ 3）有没有团队真的做过「用例大扫除」？规模多大、怎么说服 review 的人、删完之后回归时长降了多少？ 4）你们有没有遇到过「删了之后线上炸了」的情况？根因是什么、怎么补救的？

欢迎带着你们的数字来聊：套件规模、删除比例、删完后的回归时长变化、删完之后有没有出过事故。空对空的「我觉得应该删」我比较难参与，带数据的讨论才有价值。