变异测试------过去做不起，现在 agent 做得起
前言
最近看 Matt 和 UncleBob 的谈话，提到了变异测试，其对于很多项目很有借鉴意义。
你的项目行覆盖率 90%，CI 全绿，谁也不能说测试没做。但你心里隐约知道：覆盖率高不等于测得好，断言写得稀烂的测试同样能把覆盖率刷上去。"我的测试到底能不能抓住真实的代码改动？"这个问题有一个理论上的标准答案（变异测试），却几乎没人真的在日常项目里做。CodingAgent 时代下，这里已经变了。
机制
变异测试（mutation testing）的原理很直接：工具自动往生产代码里注入大量微小改动（变异），每个变异跑一遍测试套件，测试挂了，说明变异被"击杀"，测试有效；测试全绿，说明变异"存活"，暴露一个测试缺口。变异得分 = 击杀占比。
Java 生态的标配工具是 PITest。例如它会生成：边界条件 < 改成 <=、条件取反、返回值改成 null、删除一个 unlock 调用。
它比行覆盖率严格在哪？覆盖率只看"执行过"，变异得分看"验证过"。一个典型例子（来自我的开源并发库）：'锁忘了释放'这类 bug，测试只调用一次方法，行覆盖率 100% 也发现不了------不 unlock 照样执行到那一行、照样正常返回。parallel-in-scope 的 VariableLinkedBlockingQueueTest 为此给每个锁相关方法写了一个专门的探测测试：把方法里的 unlock/fullyUnlock 调用变异掉之后，另一个线程调用同锁的方法必须还能完成，否则变异存活。一共 16 个这样的测试。没有变异测试逼问，没人会想到写它们。
怎么做
过去做不起的原因是人力成本高。一轮变异测试产生几百个存活变异，每一个都要人工判断"是测试缺口还是等价变异（变异后行为不变，任何测试都杀不掉）"，然后人工补测试，再重跑一轮验证。几百个变异两轮下来，一两天就没了------所以它长期停留在论文和极少数核心库里。
agent 恰好把这两步自动化了。parallel-in-scope 的一次 agent 会话就是以变异得分为反馈信号循环：跑一轮 PITest → 读存活变异报告 → 逐个判断是缺口还是等价 → 对缺口自动补测试 → 重跑验证。最终 168 个测试补到 274 个，变异得分从 56.5% 提到 73.8%。
为什么 agent 能改变这件事的经济学？因为变异得分是一个机器可判定的成功标准。agent 的工作方式是"改一版 → 跑一个自动信号 → 看结果 → 再改"，依赖编译错误、测试失败这类不需要人来评判的反馈自我修正------而变异得分正好是这样一个信号：一个数字，判定全自动。人从"逐个分析几百个变异"退到"review agent 补出来的测试"。成本结构整个变了：原来逐个分析、补测试、重跑验证全包在人工身上，现在人工只剩最后一道 review，中间不管跑多少轮，都是机器和 agent 的时间。
具体做法：
- 构建里接入变异测试工具（Java 用 PITest，其他语言各有对应物），先跑一轮拿基线得分；
- 把存活变异报告和"提升变异得分"作为目标交给 agent，明确要求：先区分缺口和等价变异，只对缺口补测试；
- 控制范围：只对核心模块开启，demo 类、生成的代码排除在统计外；
- 得分稳定后降频：放到里程碑或夜间 CI，不进日常改动循环。
注意边界
- 等价变异永远杀不掉。 比如我遇到过一个 clear 方法，循环条件取反后旧节点照样不可达，可观测行为完全一致。剩余存活变异里相当比例是这类，所以不要追求 100% 得分------那是个不存在的目标，硬追只会让 agent 造出一堆断言内部实现的脆测试。
- agent 判等价变异也会错。 缺口还是等价没有机器可判的标准，agent 靠读代码推断，可能把真实缺口误判成等价直接丢弃------变异存活被归因掉，得分信号发现不了。对 agent 标记为等价的变异，review 时抽查几个：能讲清行为为何不变的才放行。
- 运行成本高。 parallel-in-scope 全量 1176 个变异，一轮约 14 分钟。它适合当阶段性的质量闸门，不适合挂在每次保存都触发的反馈环里。
- flaky 测试会污染击杀判定。 flaky（不稳定）测试指同一份代码这次跑会挂、下次跑又绿了的测试（并发时序、超时等待是常见来源）。而击杀判定规则是"套件里任何一个测试挂了就算击杀"，工具分不清挂是因为变异被抓住、还是碰巧赶上一次偶发失败。变异没破坏行为却被记成假击杀，得分虚高；一轮变异测试要把套件完整跑上千次，偶发失败几乎必然出现，并发测试尤其重灾区。先让测试套件在重复运行下稳定，再谈变异得分。
- 配置有坑。 并发测试的合法等待时间长，工具默认超时会把慢测试误判成超时击杀，需要调大单变异超时和覆盖阶段超时；PITest 的增量缓存（withHistory）按类复用旧结果，修改测试后返回陈旧数据，宁可关掉跑全量。
一句话总结
变异测试把"测试写得好不好"变成一个机器可判定的数字；过去人力迈不过"逐个分析存活变异、逐个补测试"这两道坎，agent 恰好把这两步全包了------工具十几年前就能跑，缺的是一个不知疲倦的分析员。