test-value

测试价值

以与风险相称的成本，保护值得保留的结果。测试数量、覆盖率百分比和通过的运行结果都是证据，而不是产品判断的替代品。当 AI 同时编写实现和测试时，要检查它们是否基于同一个错误假设。

选择范围

保留用户现有的授权和操作边界。

• **审查现有测试：**在请求的范围内调查成本、误报和保护效果。审查请求仅允许只读操作；优化请求则允许进行范围内的更改。阅读 audit.md。
• **实现或提交前审查：**检查正在更改的行为及其相关测试。决定是新增、调整、复用还是删除测试。提交前审查本身并不授权提交或推送。
• **诊断故障：**确定失败的检查所保护的结果，然后区分产品回归、过时断言、环境故障或不稳定测试。对于范围明确的修复请求，应严格控制修复范围。

处理自动布局快照、共享矩阵、源码断言、异步等待、测试替身、基准测试或覆盖率缺口时，请阅读 decision-examples.md。

建立独立的正确性依据

依据用户需求、公开契约、兼容性承诺或真实故障，说明必须保持哪些条件成立。当前实现及其自身生成的输出，不能单独作为确立正确预期的依据。

对于新增或修改的测试，请在推理过程或简短的更改说明中回答以下三个问题：

1. 哪种具体错误会导致此测试失败？这会给用户或维护者造成什么损失？
2. 等价的重构或更好的有效结果是否也会导致测试失败？哪些限制才是真正的契约要求？
3. 哪个现有测试、类型检查或其他检查已经能捕获此错误？新增保护是否值得其执行和维护成本？

优先保护可观察的输出、状态、数据完整性和故障行为。私有函数测试、快照和静态检查也能保护真实边界；其形式本身并不能决定其价值。

做出最小且有效的测试决策

证据	决策
发现了值得覆盖的故障边界	在能暴露该问题且成本最低的层级添加回归测试；必要时保留真实集成路径
已有测试会因该错误而失败	复用或扩展该测试，而不是另建一套平行的测试夹具
测试固化了非契约性实现或自动生成的输出	断言结果属性、合理的容差或边界，同时保留明确约束
多项测试通过同一实现路径防范同一故障	合并或移除重复项，并明确保留哪项保护
多个入口重复使用同一套规则表	通过共享逻辑覆盖规则集，并验证各入口的集成；保留存在交互或采用独立实现的组合
高成本测试防范了独特风险	保留覆盖；改进测试夹具，或按风险选择执行范围
历史契约已明确终止，或某项功能已移除	检查是否仍有使用方后，再淘汰过时测试
保护措施的归属或正确预期尚不明确	保留测试，并指出缺少哪些证据，不要为了减少失败而猜测

目标不是每次编辑都添加测试。纯文案更改、机械式编辑以及已得到有效覆盖的更改，可能都不需要新增测试。用户授权移除产品限制时，也应相应更新测试；旧断言不能否决已获批准的产品更改。

应保留对数据丢失或损坏、权限与信任边界故障、承诺的兼容性、关键无障碍问题、资源泄漏以及恢复机制失效的有效防护。简化这些检查仍需证明保护措施依然有效。批量跳过、重试、放宽容差或刷新快照不得掩盖回归。对产品承诺或强制发布平台门槛的更改，必须在用户授权范围内。

检查测试的辨别能力

应根据风险使用相称的证据，而不是为每项测试都另建一套测试套件：

• Bug 修复： 在可行时，用回归测试重现原始故障，并验证修复后测试通过。若无法重现，应说明这一缺口。
• 放宽断言： 尝试有效的替代结果和原先的错误结果；前者应通过，后者应失败。对于影响重大的错误，临时注入故障会有所帮助；但突变分数本身并非目的。
• 合并或删除测试： 追踪实际调用路径，并确认保留的测试能检测到同一错误。名称相似、共用辅助函数或行覆盖重叠，都不能证明测试重复。
• 共享测试夹具： 重置可变状态，并在多次失败尝试之间保留隔离性和清理断言。改进不能依赖测试顺序或偶然的缓存命中。

应在临时副本或受控测试夹具中运行破坏性探测，并保留用户现有更改。环境不可用意味着存在验证缺口；模拟证据不能替代真实浏览器、操作系统或发行版软件包。

控制反馈成本

在选择覆盖风险所需的最小检查集之前，先阅读项目实际使用的测试命令、CI 选择规则和当前更改。受影响的行为决定是否需要集成、浏览器、平台或完整验证。

确认预期测试确实已执行，包括筛选、收集和跳过情况。命令成功但没有运行相关测试，不能证明行为通过。对于没有受影响测试的更改，零项测试可能是合理的，但应明确其原因，而不是根据成功的退出代码推断。

如果结果的修订版本标识、输入、环境和覆盖范围仍然适用，就复用这些结果，并说明复用了哪些结果。如果新更改、失败或未解决的风险使现有证据失效，就扩展或重复验证。为诊断问题，应缩小失败范围，而不是反复启动完整测试套件。

只有依据测量结果才能宣称提速。区分单个用例耗时、文件耗时、并行流水线的关键路径和总计算量。正确归因嵌套日志中的耗时：父测试套件的耗时不等于其最后一个子项的耗时。比较测量结果时，应控制运行时、平台、输入、缓存状态和竞争任务。

从使用中学习

当实际使用揭示了有价值的新测试原则，或发现本指南存在缺陷时，你可以在当前环境的权限和用户指示范围内直接完善此技能。这是可选的维护工作，并非每项任务的必需步骤；应适度进行，并优先完成原始任务。

修改技能之前，请确认：

• **证据：**依据观察到的结果、失败或有充分依据的反例，而不是看似合理的口号。一个决定性示例足以支持范围狭窄的修正；更广泛的主张则需要更广泛的依据。
• **决策价值：**说明 Agent 会因此作出什么不同的决定，以及现有指南为何尚未涵盖这一点。
• **适用性：**说明该原则适用的情况，以及有意义的例外或反例。项目特定约定应写入项目指南，而不是在此作为通用原则。

优先修订或整合现有原则，而不是追加规则。跨领域原则应放在此入口文档中，条件性示例应放在相关参考文档中。新增内容使用英文，省略私密事件细节和临时测量结果，并遵守授权与保护边界。某个经验教训并不授权扩大仓库更改范围、发布内容或同步到其他安装环境。

检查最终指南是否存在矛盾或不必要的要求；如果受到影响，也要检查链接和元数据。如果更改会影响行为，请用真实场景验证决策。如果无法访问技能或技能为只读，请提出确切的改进内容，并说明未予保存。

每当更新技能时，都要在最终回复中告知用户：链接到更改的文件，概述新增或修订的原则，并说明依据或原因。明确区分已保存的更改和提议。现有指南已能说明相关经验时，无需更新。

报告并停止

简要报告受保护的行为、测试更改及其理由、已执行或复用的证据、跳过项和有意作出的覆盖取舍。只有在测量结果可比较时，才报告耗时变化。常规开发无需额外的治理报告、评分系统或 CI 策略。

对于审计，应将已调查的候选项分别记为已更改、已保留或等待证据。当高价值候选项都已处理，且剩余候选项缺乏证据或成本高于收益时，本轮即可结束。目标既不是无止境地删除，也不是不断增加流程。应明确区分针对性验证、完整测试套件、视觉验证、平台验证和发布验收声明。