当需要判断测试能否捕获生产代码变更时…

在不实际运行变异工具的前提下，通过源码与断言的映射，找出哪些调用方可见的生产行为被修改后现有测试仍会通过。

适用场景

解决思路

1. 从项目清单和文件类型中发现生产代码与测试文件；窄范围搜索未命中后，先广泛检查当前目录再询问路径。
2. 按请求类型决定动作：单组件或指定风险→盘点范围内每个高风险公开结果，除非要求验证否则不改生产代码；通用小组件审查→盘点不同结果并报告调用方可见缺口；显式幸存者验证→盘点所有请求结果，对每个不同高风险结果执行一个代表性可观察候选，分类为 Survived 或 Killed；显式穷尽审计→阅读 references/mutation-catalog.md 并分类所有有意义的候选；向现有套件添加测试→先分析，只为已验证幸存者或已证明无覆盖的结果添加测试；创建新套件→停止并改用 code-testing-agent。
3. 当请求指定了风险时，在读代码前把它转成一行公开结果允许清单；某结果不会仅因同一方法写入它而进入范围。对 money math，允许计算或返回的金额、费率、层级/边界选择、百分比基数/顺序、下限/上限和舍入；排除非货币状态谓词（含派生布尔）、身份和格式化。私有代码仅在追踪允许结果时纳入范围。
4. 不要把聚焦请求扩展成仓库审计、计划产物或仪表盘；熟悉框架直接使用源码与测试；仅当发现或断言语义不清晰时才调用 test-analysis-extensions。
5. 运行最窄的现有测试命令一次作为基线，从项目清单选择；Microsoft.Testing.Platform 可执行文件可能需要 dotnet run。确认测试确实执行：退出码 0 且只有构建输出不算通过。若这一次尝试无法运行套件，不要为咨询性审查排查运行器或尝试替代命令；继续静态分析并把所有候选标为 unverified。不要从缺失输出推断项目配置原因；仅当命令报告时才指出原因。
6. 缺失运行器输出只限制经验性变异存活声明，不使源码证明的事实变得不确定：无测试触达的公开结果仍是 No coverage，从原始实现推导出的精确期望值仍可操作。只陈述一次基线限制，然后直接给出静态源码/断言结论，不要对每一行都加保留。
7. 对咨询性审查（如“测试能捕获这个吗？”），基线之后停止执行。源码到断言的映射足以证明 No coverage 和 Candidate survivor (unverified)。仅当原始值不清晰时追踪或运行未修改代码一次。仅在显式验证、穷尽审计或添加测试关闭缺口时应用变异。
8. 任何聚焦变异预算只限制执行，不限制发现；保留清单中每个不同的未断言公开结果。
9. 对每个公开入口点映射：输入分区（分类器分支、复合条件、无效与最近有效守卫边界、默认情况）；每个独立观察（返回字段/变体、异常类型、无效输入接受、公开状态转换或外部副作用）；通过公开调用方观察到的私有辅助组合、常量/费率、舍入、重试、取消和错误传播。
10. 使用 public input/sequence -> expected outcome -> existing assertion -> gap 格式。一个被断言的返回字段不覆盖另一个；一个允许结果不覆盖其拒绝。
11. Money math：盘点 no-op 路径、每个费率/层级及精确边界、操作顺序、百分比基数或组合、下限/上限和舍入；通过公开结果追踪私有辅助。仅断言宽范围的测试不锁定任何精确金额。对每个可操作 money 行，通过完整调用链推导一个见证输入及其精确原始结果；不要在没有提供该金额的情况下建议泛泛的“断言精确金额”。
12. 有序守卫与重试：盘点 invalid below minimum | first valid | last allowed or retryable | first blocked | later blocked。对如 value >= limit 的上界守卫，使用 limit - 1、limit 和 limit + 1；最后一个见证暴露收窄为 value == limit。盘点每个接受和拒绝的错误类。当类型匹配是多态时，包含一个代表性派生接受类型，以暴露精确运行时类型收窄。在第一个被阻止值处的测试不保护最后允许或之后被阻止的值。
13. 授权：从调用方视角枚举每个相关身份/角色、资源类和动作。未测试的 false、forbidden 和 unchanged-role 结果是一等安全缺口。在拒绝结果仍未盘点时，不要分析允许路径的变体。检查每个公开表面：权限返回 API→每个不同角色/资源类和每个返回能力独立；动作分发 API→每个读/写/删除式动作分支，尤其是必须返回拒绝的路径；角色/状态转换→接受、拒绝、无效# 空和空输入，包括必须保持状态不变的结果。
14. 在部分覆盖辅助的另一个变体之前，把执行留给完全未测试的公开分支。若超过五个高风险行为未断言，执行前 3-5 个，其余保持为 No coverage 或 Candidate survivor (unverified)。
15. 执行永不替代台账。在变异或回答前，分类每个必需结果，包括每个无效输入、守卫边界、分类器分支、动作和拒绝。
16. 完整性检查点：在选择发现前，明确考虑每个独立模式/标志、<= 0 守卫的零和负数、每个接受异常类，以及匹配多态时一个代表性派生接受异常。对移除的守卫，追踪 fallthrough：若仍产生相同公开异常类型，则除非更细异常元数据是既定契约，否则视为等价。
17. 首先对每个现有断言输入或序列以固定参数重放每个精确变异。任何改变的返回、异常、状态或副作用都是 Likely killed；不需要专门单用途测试。绝不要把一个输入上的变异体与另一个输入上的原始比较。
18. 对幸存者，在执行或报告前选择见证并声明 witness -> original observation -> mutant observation。在最小测试中复用它。仅当追踪完整调用链后最后两者公开不同时才接纳；否则选择区分性见证或丢弃。
19. 排除：需要插入或重排语句而非更改或移除现有表达式、条件、常量、返回或副作用的编辑；无法编译的编辑，包括移除仍被引用的声明；溢出行为、异常消息/ParamName 元数据或当前契约、源码意图或测试未确立的其他语义；移除的守卫或短路 fallthrough 到相同结果、异常、状态和副作用；每个公开输入序列观察相同的私有表示变化，即使套件仍绿；提议测试对原始和变异体都通过的变异；在区分性输入上返回相同值的边界编辑，例如把 result < floor ? floor : result 改为 <= 在相等时等价，因为两分支都返回 floor；无有意义分支、计算或副作用的独立自动属性或平凡单行包装/谓词，除非用户指定；假设的未来影响、生成代码、仅日志/格式化更改、不可能值和重复语法变体。
20. 缺失直接断言不证明 No coverage：先通过公开调用方和共享分支追踪现有断言。缺失断言使可观察候选成为幸存者；不使惰性变异有意义。
21. 排序：(1) 安全拒绝、财务结果、错误和状态变化；(2) 完全未断言的公开结果；(3) 弱断言触达的边界或精确值；(4) 已断言行为的替代变体。
22. 在选择变异或裁决前完成盘点。一个被杀尝试、异常类型或 switch 分支不清除其兄弟。
23. 从完成的盘点选择裁决：Strong→核心分支和主要边界受保护，仅剩少量验证或默认情况变体；Mixed→存在有意义覆盖但至少一个重要结果分区未保护；Weak→重要结果广泛未保护。少量验证缺口不使原本广泛的套件变为 Mixed，除非验证是指定风险或缺口威胁安全、数据或其他契约关键行为。
24. 当盘点满足上述 Strong 标准时，先给出 Strong 并列出受保护边界和双重断言，再列次要缺口。不要以 Mixed、“仅核心路径”或风险密集仪表盘开头。
25. 当现有断言杀死剩余候选或不存在可信公开幸存者时停止。不要仅为填充报告或计算分数而变异每个操作符。
26. 结果分类：Likely killed→现有断言观察到改变的结果；Candidate survivor (unverified)→可观察变化似乎未断言，未执行；Survived→精确可观察变异已执行且测试仍绿；No coverage→无测试触达公开结果，报告缺失分支而不发明幸存者；Equivalent→无公开观察变化，从发现中省略。
27. 除显式验证、穷尽审计或请求添加测试外，不执行任何变异。不要为确认明显无覆盖而变异。对显式验证，对范围内每个不同高风险结果执行一个代表性候选；不要在另一个守卫、动作分支、错误类或拒绝仍未分类时在前一两个后停止。省略等价语法变体。
28. 仅对显式验证、穷尽审计或请求添加测试进入验证阶段：应用一个候选并确认 diff 恰好更改一个预期表达式；运行最窄覆盖测试（绿=Survived，红=Killed，仅对该编辑）；立即回滚并确认干净的源码/测试基线；绿运行后重新检查公开反事实——执行证明套件漏掉编辑，不证明编辑改变行为；丢弃惰性或不可观察变异体。
29. 绝不在工作区留下变异。报告前，把每个未断言高风险结果调和为 Survived、Candidate survivor (unverified)、No coverage 或省略的 Equivalent。当不存在可信公开缺口时停止；不要用内部细节填充报告或计算分数，除非用户要求穷尽审计。
30. 仅在请求时关闭缺口：只为已执行 Survived 变异或已证明 No coverage 行为添加聚焦测试；在添加已覆盖行为替代变体的测试前，覆盖请求范围内每个不同缺口；编辑前创建幸存者到测试清单，停止前把每个已验证幸存者映射到添加的测试并把每个添加的测试映射回已验证幸存者——仅最终套件通过不证明完整性；请求时保留生产代码和现有测试；优先一个行为聚焦测试杀死相关变异，而非每个语法变化一个测试；重新应用原始变异并证明新测试杀死它，然后恢复源码并干净运行窄套件；若夹具或仓库提供规范变异验证器，在添加测试后运行该精确命令并引用其成功结果——手工替代变异、宽泛绿套件或测试数增加不替代提供的 oracle；一旦每个请求幸存者映射到聚焦测试且规范验证器通过即停止，额外测试不是优势；当请求要求现有源码或测试文件保持不变时，把每个受保护文件与编辑前快照逐字节比较并报告该证据；添加测试前，证明其见证在相关分支、边界或舍入结果上与每个现有用例不同，以免名义上新测试重复现有覆盖。
31. 输出契约：按请求缩放响应。对聚焦或小分析返回：一行裁决 Strong/Mixed/Weak 及原因；对 Strong 套件，一句简短优势句，命名证明裁决的具体受保护边界、守卫或配对观察；每个可操作 Survived、Candidate survivor (unverified) 或 No coverage 结果一行紧凑表格（Risk | Public outcome | Change | Result/evidence | Smallest test）——添加行前，当请求指定风险时应用结果允许清单，然后应用可观察候选规则，省略未通过任一过滤的候选；包含每个高风险结果，每个不同公开结果一行，仅合并相关低风险变体；每个缺口需要区分性见证和具体最小测试；错误路径缺口必须命名无效输入和预期错误/结果；对 Mixed 或 Weak 套件，一句简短优势句命名重要被杀行为；当请求指定排除时，一句简短范围句命名有意跳过的生成、平凡或不相关代码。不要用散文重复表格或报告丢弃的变异体、工具时间线或进行中推理。对穷尽审计，添加 Killed / Survived / No coverage / Equivalent 计数并按风险分组发现；仅计数已执行或明确分类的候选。对测试添加，命名添加的测试、它们杀死的已验证变异和成功的最终命令。
32. 可靠性规则：通过的测试若未断言改变的结果，不杀死变异；覆盖是按行为分区——一个 switch/三元分支或复合输入不证明兄弟：allow 不证明 deny，read 不证明 write，null 不证明 empty 或 whitespace（当这些输入有不同调用方可见结果时）；一次杀死只清除运行的编辑和路径；通过公开方法触达的私有辅助仍在范围内；错误语义是语言特定的：Rust 中 ? 传播与 panic 是可观察行为，C# 中异常类型和输入守卫接受或拒绝值是可观察行为；对每个精确金额或边界结果与未修改实现或现有精确断言交叉检查，若无法检查则陈述行为关系而不发明数字；不要仅因变异存活就把发现标为高风险；绝不为现有套件已保护的行为推荐冗余测试。
33. 验证清单：范围与请求成比例；原始套件通过，或静态限制明确；范围内每个高风险公开结果已盘点；原始和变异体有不同调用方可见观察；每个标为 Survived 的结果已执行，未执行候选使用 Candidate survivor (unverified)；每个临时变异已回滚；发现排除平凡、生成和等价更改；建议仅针对已证明缺口；范围内每个公开入口点分支和每个接受异常类型已明确考虑；提供的规范变异验证器已运行并报告，未用临时代理替代。

适用边界 · 注意事项

• 不要用于套件组织、分类法、元数据或分发报告（test-tagging）。
• 不要用于 .NET 行与分支或 Cobertura 解释、算术、平台期、项目级覆盖缺口或覆盖支持的测试/CRAP 优先级（coverage-analysis；.NET 外使用原生覆盖工具）。
• 不要用于命名目标 CRAP（crap-score）、新套件（code-testing-agent）、断言/坏味审计或变异工具。