test-value-evidence

测试价值证据

除非测试能检测到相关错误行为，否则测试通过并不能证明多少问题。 评估已更改的契约及其直接相关的测试，而不是整个 代码库。发现并遵循代码库的说明、锁定的工具链、 测试命令、断言惯例和执行权限。此技能不授权在只读审查中修改文件、 执行不可信代码、触发工作流、发布内容或访问其他会话的检出内容。

输入与边界

发现请求涉及的差异／修订、生产入口、测试、夹具和可用的执行产物。如果无法确定更改范围，应报告缺失的范围，而不是评估整个工作区。未更改的现有测试也可能足够；仅涉及源代码的差异并不意味着没有测试。

一般性的现有测试套件盲点使用 test-gap-analysis，精选的逐项测试就绪度／质量评估使用 grade-tests，变异测试活动使用代码库现有的变异测试工具。不要启动第二套变异测试引擎，也不要要求每项更改都进行完整测试套件的变异测试。本技能自成一体：相邻技能只是可选的后续处理方向，并非必需依赖。

工作流

1. 将契约绑定到受测修订。 对于 PR，记录其合并基点和确切的头部 SHA。对于提交，记录选定的父提交和提交本身；如果是合并提交，明确指出父提交。对于未提交的工作，记录基准 SHA 和可复现的补丁标识（已保存的补丁／哈希，包括相关的未跟踪文件），不要虚构一个已提交的修订。相关源代码、测试、辅助程序、配置或包发生更改后，证据即失效，除非重新验证。

   对每项不同的行为更改，映射： 需求 -> 输入／序列 -> 预期的公开结果 -> 生产入口 -> 具名测试／数据用例 -> 区分性断言。 根据需求或受支持的 API／协议语义独立推导预期结果，而非依据实现或测试当前使用的值。检查构建／打包／配置行为、已删除／重命名的代码、已移除的测试，以及发布版本的使用方；不只检查源代码。仅在与更改的契约相关时，纳入正向、负向、边界、兼容性、取消、清理和多模块用例。

   对更改组件进行模拟、自我比较，或使用同一生产算法计算预期值，都不能提供独立的判定依据。

2. 选择有意义的反事实。

   更改	反事实	必需的观测结果
   Bug 修复	保留回归测试，并恢复实际的修复前缺陷。	测试针对该缺陷失败，应用修复后通过。
   新功能	禁用／移除或破坏该行为，同时保留构建所需的 API 形态和设置。	断言能检测到行为缺失／错误；启用该功能后测试通过。
   增强／仅测试覆盖	引入一种合理但错误的公开结果。	增强后的测试能检测到该错误；未修改的产品通过测试。
   保持行为的重构	比较重构前后的契约是否保留；可选地探测相关故障。	保持契约的测试在两个修订上都通过；重构前通过是预期结果。
   仅涉及文档／生成元数据	确认可执行契约是否发生变化。	只有在给出具体理由时，才能认定为不适用；生成内容或构建元数据也可能改变行为。

   对于修复，优先使用真实的修复前实现，并搭配相同的回归测试、设置、依赖项和输入。如果新 API 导致这种组合无法编译，则只在头部版本中恢复有缺陷的行为。称其为定向反事实，不要称为在基准版本上运行。记录其确切的补丁／哈希。绝不要更改断言来人为制造失败。 对于某项功能，缺少符号的编译器错误不能证明其行为。 应选择可构建的空操作、禁用注册、旧分支或错误输出。 只有当已执行的测试框架断言了该特定诊断或其缺失时， 编译器／分析器诊断才可算作有效行为。

   优先选择小而合理的故障：恢复旧边界、丢弃必需输出、跳过回调、忽略选项或返回错误值。 等效变更不算缺口。只有当崩溃、超时或异常是预期的契约信号，且诊断能将其归因于该故障，而非设置、发现、偶发问题或基础设施时，才予以计入。

3. 仅在获得授权时执行成对运行。 实现工作通常需要执行；只读／咨询审查通常需要检查。 仅有审查请求并不授权修改源代码或运行构建／测试。 绝不要使用特权凭据运行不可信代码。

   在已获授权的实现／验证环境中：

   • 使用自有的隔离检出目录或实验目录。保留用户的未提交文件以及其他会话／主检出目录中的内容。预先检查并发进程和共享输出／资源；不要终止无关进程。
   • 针对正确实现运行最小相关测试集。 确认指定的测试和数据用例确实执行并通过。
   • 仅在隔离实验中应用所选的缺陷行为。 重新构建并用相同的测试、断言、数据、依赖项及适用的运行时配置重新运行。记录指定的失败、断言、预期／实际观测、进程退出状态和诊断信息。
   • 恢复正确实现，重新构建并再次运行，以确认结果恢复为通过。验证受保护的源代码／测试文件字节，且只移除自有的临时资源；绝不要将反事实补丁交付到产品中。

   成对运行不得复用过期的构建／测试输出，也不得复用另一变体的有效缓存。使用单独的输出／缓存，或仅清理自有输出后重新构建；不要依赖 --no-build 或仅凭运行器返回成功退出状态。记录每次运行所选／已执行／通过／失败／跳过的数量。如果运行器不提供数量，请注明 unknown，不要编造。选择或执行数量为零、存在跳过项、缺少工具、身份验证问题、设置／构建问题、无关故障或无法归因的计时偶发问题，都会使验证证据无法确认。

   对于跨组件／验收行为，先明确生产者与消费者之间的契约：适用时包括所有权、生命周期、握手／无握手、退出语义、回退、兼容性、取消和多模块聚合。记录确切的待发布二进制文件／软件包／扩展以及发布分支。为每个变体重新构建／打包，隔离有效的软件包缓存，证明真实的待发布消费者加载了哪个变体，并运行具有代表性的组合命令。仅有单元测试模拟或源码兼容的编译，不能替代待发布布局验证。测试适用的正常、抑制、部分、旧版／不兼容、取消、非零退出、零结果、回退和多模块路径。明确说明发布／维护的责任归属；功能标志不会降低证据标准。

   在只读／咨询模式下，应追踪两个修订版本、设置／辅助程序、输入和断言，不作修改或执行，除非另行获得许可。将结论标记为 静态预测，绝不要称为已执行的证明。只有当现有产物的修订版本／补丁、加载的变体、选择项、数量和失败归因均匹配时，才可将其作为证据。绿色 CI 或作者的单方面说法都不能单独构成红绿验证证据。说明哪些内容无法访问或缺失。

4. 仅报告已取得的证据。 在交接内容或获授权的审查／描述中，加入简洁的 测试值证据 部分。注明基准／父级和头部 SHA，或已测试补丁的标识。每项变更契约占一行， 将保护同一契约的测试分组，并指出未评估的分组。

   契约／测试用例	反事实	无该行为时	正确实现	证据／缺口
   边界缺陷／指定用例	恢复旧比较逻辑；补丁标识	已执行：断言失败	已执行：通过	命令、退出状态、预期／实际结果、计数、产物
   新输出／指定用例	跳过输出写入	静态分析：预测会失败	未执行	源码／断言位置；缺少成对执行

   准确使用 已执行：检测到、已执行：仍存活、静态分析：预测会检测到、 静态分析：预测仍存活、未验证、等效 或 不适用。缺少红／绿测试 或测试选择不完整时，成对证明仍未验证。仅当非等效故障已实际执行时，才报告 已执行：仍存活；不要将等效修改计为缺口。重构的保留性测试通过是有效证据， 并非缺少红测缺陷。

   包含精确命令／退出状态、工具链／框架／配置、修订版本和反事实补丁标识、每次运行的计数，以及相关产物路径。区分当前执行的测试与经核实的现有产物。切勿将静态预测与实测变异计数／分数合并。最终 PR 头部的证据无法证明每个中间提交；应分别针对请求审查的提交及其父级进行评估。

   缺少证据不自动构成已证实的缺陷，也不自动意味着应创建行内审查评论。是否发布应遵循调用方现有的授权门槛；不要仅为存放报告而创建新的 GitHub 对象，也不要声称这些说明能够强制执行钩子、CI 或发布流程。

验证

• 证据明确指出具体变更、独立判定依据、测试／数据用例，以及有意义且可构建的反事实。
• 声称已证明的错误修复，须在实际旧缺陷下失败、在修复后通过；功能证明须能检测到行为缺失或错误，而非仅检测符号缺失。
• 执行类声明须有可归因的结果、命令／退出状态、计数，以及相匹配的产物／使用方来源；无法提供的细节应明确说明。
• 静态预测、仍存活、等效、保留性测试和证据缺失应分别表述。已有测试应计入证据，无需要求重复测试。
• 保留了范围、只读限制、干净的变体输出、并行安全性和自有资源清理要求。