接手一个测试套件时，跑一次全量测试的结果是：38 个收集错误、107 个失败、耗时 747 秒。而且它默认会去连一个早已不可达的内网地址。
这种状态下的测试是没有价值的——没人会跑一个必然失败的套件，于是它慢慢变成"那个我们不敢动的目录"。
三步，顺序不能换
先让它跑完，再让它跑对，最后让它跑快。
先让它跑完：修掉收集错误。收集阶段的失败会吞掉整个文件的用例，收益最大。同时把外部依赖从硬编码地址改成可配置——这一步做完，套件至少能完整跑一遍，你才看得到全貌。
再让它跑对：逐个处理失败。绝大多数不是被测代码的错，是测试自己烂了——过期的 fixture、互相污染的全局状态、依赖时间与随机种子的断言、隐式的网络依赖。这些模式高度重复，所以顺手沉淀了一份 14 条的"陈旧测试根因清单"，后面同类失败照着查就行。
最后让它跑快：前两步做完，慢的原因通常已经浮出水面——最典型的是每个用例都新建一次重量级资源。改成会话级复用后，时间自然下来。
结果
7218 个用例全部通过、零失败，全量耗时从 747 秒降到 100 秒左右。之后再加守卫测试（文件行数上限、配置项使用情况）就很轻松——因为已经有一个可信的基线了。
测试套件的价值不在用例数量，在"它绿的时候你敢不敢发版"。