变异测试

突变测试（Mutation Testing）通过人为引入代码缺陷来检验测试用例是否真正有效

本研究将变异测试迁移到数据分析语境，其中“变异体”是可辩护的分析选择变体（如更换分位数分割点、调整删失区间或重新定义队列边界），而非代码缺陷。

变异运行只是一种启发式，它会以可预期的方式退化：回退 src/ 可能破坏导入，变异失败可能源自被测断言之外；对 mock 或日志字符串断言的套件即使在行为改变时也常常保持绿色；flaky 测试让第三态充满噪声；大型 monorepo 需要受影响测试选择；合法重命名或重构测试的补丁会触发 churn 计数器。

本文提出的“变异态”是变异测试的一种轻量特例：不是注入随机变异，而是直接回退整个修复（src/ 回到基线），保留测试不变，构造一个已知存在 bug 的变异体。

与传统变异测试工具（如 PIT、mutmut）相比，本文的轻量变异方法计算成本极低（只运行一次套件），但只能验证“修复是否被测试约束”，不能全面评估测试套件的整体强度。

识别“结构上不可能失败的检查”的方法是问：如果我关心的那件事没有发生，这个检查还会通过吗？

变异得分（Mutation Score）是被杀死的变异体占注入总数的比例。

变异测试相比行覆盖率更严格，但计算开销更高，因为每个变异体都需要重新跑一遍测试。

在一份非正式报告中，20个针对 Laravel 控制器写的AI测试宣称覆盖了全部端点，但在95个注入变异体中只杀死了68个，27个变异体存活。

在100张工单测试集中，SupportOps-AI的升级错误率为18%，幻觉率为6%，死循环率为3%，完全失败/未解决率为4%。

变异测试中的变异分数衡量测试套件能杀死多少比例的变异体，是QTestBench测试质量分数的直接来源

变异测试（Mutation Testing）是一种测试充分性验证技术，最早可追溯至1970年代。

变异测试通过程序自动向源代码注入微小的语义变更（变异体，如将 > 改为 >=、+ 改为 -），运行测试套件并统计有多少变异体被'杀死'；存活的变异体说明测试套件存在覆盖盲区。

文中提出的'必须失败用例'与变异测试思路一脉相承，但省去了自动生成变异体的复杂性，属于其中最轻量、最低成本的形式。

变异测试的理论最早可追溯到1971年Richard Lipton的学生论文

作者维护了一个免费实验仓库，运行 `node run-lab.js weak` 会对故意写错的代码生成AI测试并全部通过，运行 `node run-lab.js verify-candidate` 则会失败并抓住全部4个预埋Bug。