test-audit

测试审计

以可信度和有价值的反馈为优化目标，并控制在合理成本内。保留有意义的契约。将可疑的测试形态视为需要调查的线索，而不是删除判决。

1. 确定范围和权限

根据用户现有指示确定范围和模式：

• 审计： 检查、评审或提出建议，不进行编辑。
• 清理： 清理、删减、修复或实施审查结果的请求，授权在限定范围内编辑测试及测试支持代码。先检查，然后继续，无需再次征求已获授权的操作。
• 行动计划： 涉及仓库、monorepo 或子系统中的所有测试时，阅读 references/campaign.md。按照下列标准，采用其中的完整清单和分批顺序。行动计划决定完整性要求；审计还是清理仍决定编辑权限。

未指定任务的直接调用，默认进行审计。检查完整的请求范围。区分范围外、未审查和已审查但受阻的工作。如果尚未解决的重要决策不影响其他工作，则继续开展独立工作；只就受影响的边界征求意见。

除非另行授权，否则测试清理不得涉及产品行为、公共 API、依赖项、CI 门禁和覆盖率阈值。单独提出产品修复和生产代码简化建议。遵循现有的提交和发布授权。

完成标准：已明确模式、范围内的测试、排除项和编辑边界。

2. 了解项目并建立基线

先阅读适用的根目录和范围内指示，然后通过 /swarm 主动委派可分离的发现工作。默认情况下，并行启动三个只读子 Agent：

• 测试清单： 阅读清单文件、运行器配置、CI 定义和工程文档。梳理测试文件、共享支持代码、发现机制、路由和命令。
• 生产行为： 追踪测试所涉及的生产代码负责人、入口点、调用方和依赖契约。
• 测试价值： 检查断言、重叠测试和维护成本。提供修复、合并和删除候选项的证据。

为每个子 Agent 提供范围、适用指示和第 3 步标准。要求提供文件引用、证据和待解决问题。主 Agent 负责协调结果，汇总为一份清单和记录，并负责最终决策、编辑和验证。范围较窄或资源有限时，减少子 Agent 数量。如果无法委派或不允许委派，则遵循 /swarm 所披露的备用方案：按顺序工作并记录下来。

识别项目中实际存在的单元、组件、集成、契约、端到端、视觉、属性、架构和工具测试，包括与代码并置的测试及由 CI 执行的内嵌示例。记录共享夹具和跨包使用方。只有说明理由时才排除生成文件或供应商文件；在相关情况下，检查其生成器或所属测试。

尽可能记录起始修订版本和工作区状态。编辑前运行相关基线命令，使用与最终验证相同的环境和测试选择。区分产品故障、不稳定结果、基础设施故障、跳过的测试和未运行的测试。调查已有故障，同时保留有意义的覆盖率。如果无法运行测试，则继续进行静态检查和独立工作。

完成标准：已协调发现结果，请求范围已有清单和已发现的命令，并已记录基线结果或明确的执行限制。

3. 评估并记录决策

使用候选模式确定检查优先级。阅读每项测试的设置、断言、参数行、相关生产代码路径和重叠覆盖；必要时调查调用方、依赖契约、CI 路由和历史记录。按照 /principle-test-behavior-not-implementation 的要求应用测试质量标准，并通过以下问题进行判断。对每项测试，确定：

1. **契约：**它保护了哪种可观察行为、不变量或独立要求？
2. **回归：**什么可信的错误实现会导致它失败？它的断言能检测到这种失败吗？
3. **独立性：**预期结果能否与实现不一致，还是测试同时构造了两者？
4. **边界：**它是否测试了适合承载该契约的公共接口或稳定边界？哪些保持行为不变的实现变更不应影响其断言通过？
5. **独特贡献：**除了现存的其他测试，它还提供了哪些有用的故障检测、诊断或可执行文档？
6. **反馈与成本：**测试意图和失败是否清晰？它提供的有效反馈是否值得其执行和维护成本？

以需求、文档所述接口、缺陷历史、协议规则、示例和既有调用方预期作为证据。正式规范是有用的证据，但并非实现有效覆盖的前提。缺少文档或历史记录会带来不确定性。如果无法确定预期行为，则保留该测试，待进一步澄清，并标记为尚未解决。

优先选择能暴露故障且成本最低的稳定边界。让纯规则通过稳定接口贴近其实现；集成测试则用于覆盖隔离测试无法触及的接线、序列化、存储、生命周期和传输风险。关键工作流应在用户边界测试。每项契约应选择一个主要归属测试，同时保留其他层级的独特价值。只断言契约要求的属性；构造方式发生变化时，测试设置可以相应调整。

利用现有依赖接缝控制协作者。优先使用可行的真实实现或维护良好的伪对象，而非模拟对象。确认替身遵守测试所涉及的依赖契约，并指出针对模拟行为的集成或契约证据。测试中应执行正在验证的生产行为，而不是通过替身提供该行为。

如果快照、源码检查、精确文本、几何、调用顺序、慢速测试和模拟对象能独立保护有意设定的契约，例如无障碍交互、线格式、视觉基线、架构规则、包表面或迁移，则应予以保留。区分验证已发布的导出契约与机械复制当前导出列表。仅仅没有内部调用方，并不足以证明某个公共导出已过时。

编辑前，简要记录价值、决策和证据。只有证据和决策相同的用例才应归为一组；不同理由的参数行应拆分记录。将跳过或禁用的执行与价值分别记录。

测试或参数用例	契约 / 可信的故障	决策	价值与保留的证据	验证

使用以下决策：

• **保留（KEEP）：**以合理成本保留有用且独特的反馈。
• **修复（REPAIR）：**保留契约，同时修正断言、设置、确定性、清晰度、成本或测试边界。
• **整合（CONSOLIDATE）：**先将必要用例移入明确指定的保留套件，再删除重复内容。
• **删除（DELETE）：**只有在证据表明没有损失有意义的契约，或已有明确的保留测试保护该契约时，才删除没有合理贡献的测试。
• **尚未解决（UNRESOLVED）：**保留现有覆盖，并说明缺少的证据或待定的决策。

对于删除和整合，应指出具体保留的验证，并比较输入、负面用例、断言、集成路径和 CI 执行情况。或者，说明该测试为何没有保护任何有意义的契约。如果能查阅历史记录，应检查并如实记录；如果无法查阅，也应如实说明。名称重叠、设置相似、执行行相同、模式匹配或删除后测试套件仍为绿色，都不能证明测试存在冗余。 对于 REPAIR，指出测试缺陷、修复恢复的有效反馈，以及适合该修复的证据。现有断言可以保持不变。

完成条件：所有范围内的测试或不同的用例组都已作出决定并提供证据。在 audit 模式下，附上建议并进入 Step 6；在 cleanup 模式下，继续执行以下内容。

4. 按行为执行清理

按负责相关行为或子系统的部分对编辑分组。删除旧位置之前，先迁移独有用例。应选择表驱动用例或共享 fixture，以提高可读性并确保设置稳定，而不是单纯减少行数。

修复记录的测试缺陷。在保留断言和有意义场景的同时，从根本上修复不稳定性；重试不能替代此类修复。在异步端到端测试中，使用测试框架提供的有界等待，等待所需的可观察状态；某个操作返回并不能证明其后续工作已完成。

移除新近未使用的 fixture、导入、快照、辅助函数和设置。保留其他包仍在使用的支持内容。移动测试时，确保测试发现机制和现有 CI 路由仍然正确；不要为使结果变绿而放宽门禁或将测试隔离。

对于任何新增或重写的测试，回答 Step 3 中关于价值的问题。对于 bug 回归测试，在可行的情况下，证明修复前的行为会因预期原因失败，并在修复后成功。如果无法运行，则记录尚未验证的声明。

完成条件：每个获授权的决定都已执行或明确标记为受阻；每个独有用例都有归属；新近未使用的支持内容已移除，且不影响共享使用方。

5. 验证保留情况

验证期间保持文件稳定。在编辑输入文件之前，先完成或停止相关运行，同时保留无关进程和工作中的更改。

1. 先运行受影响范围最小的测试套件，然后运行相关的同级测试、跨包使用方测试以及仓库要求的门禁。使用从项目中查明的命令。
2. 确认移动的测试已被发现并执行，且有意义的参数用例仍有覆盖。若移除的源代码扫描或计划断言原本用于保护某个脚本或命令，则运行其所属的可执行程序或试运行。
3. 通过 /swarm 委派未参与提出受影响更改的子代理执行保留情况对比；必要时使用 Step 2 中的备用方案。将原始契约和用例与保留下来的断言进行比较。检查独有输入、错误、边界情况、安全性、无障碍性、顺序、交互、集成路径以及适用情况下的 CI 环境。将缺失的契约恢复到合适的归属处。
4. 根据记录的缺陷验证修复。对于高风险或含义不明确的断言，可使用有针对性的负向对照或小型临时变更，证明保留的测试能够捕获预期故障。应在隔离环境中操作，并仅还原此次检查所做的更改，保留用户编辑。常规清理无需进行穷举式变异测试。
5. 运行适用的格式检查和静态检查，并检查最终差异，确认没有意外扩大范围、遗留无用支持内容、削弱断言或更改配置。在完成删除批次之前，若项目提供现有的未使用文件、导出项和依赖检查，则运行这些检查。针对共享使用方和已发布契约核查检查结果；报告无法运行的检查，并将生产代码或公共 API 的移除作为单独事项提出。

协调基线和最终结果。准确报告命令、测试选择、结果和不可用的环境。缓存结果不能证明新编辑的测试已运行。具体风险已解决且必需的门禁已通过后，停止可选验证。

完成条件：每个受影响的契约都有保留下来的证据或已记录的未解决问题；每项必需检查都有结果或明确的执行阻碍。

6. 报告

说明结果属于只读审计、已完成清理还是部分工作。总结决策和有代表性的发现；对于全面审查的任务，请提供完整清单，不要在聊天中逐条列出所有保留项（KEEP）。包括：

• 范围与清单核对情况，包括排除项和未解决事项。
• 删除或合并的测试，以及目前由什么保护其契约。
• 修复的测试，以及值得说明的误报残留。
• 基线与最终验证、失败项、跳过或未执行的检查。
• 需要另行处理的产品缺陷或生产代码简化。

将审查覆盖范围与执行结果分开报告。测试数量和代码行数减少不能证明安全性。

只有当用户能够区分已完成的工作、未解决的决策和未经验证的主张时，才算完成。只有在审查了所有范围内的测试并处理了每项已授权决策后，才能声称清理已完成。存在未解决的决策时，清理工作即为部分完成；执行方面的限制应另行说明。

候选模式

搜索以下线索，然后先执行步骤 3，再作决定：

• 期望值由被测代码本身计算；断言将某项声明与其自身的副本进行比较。
• Mock 或夹具提供了生产路径本应产生的行为或结果。
• 断言持久化结果写入了生产代码从未写入的存储路径。
• 断言能力标志，而不是承诺的交付或确认。
• 执行过程没有断言，也没有有意义的成功／失败契约；请考虑“不抛出异常”等隐式断言。
• 源码扫描、快照、整对象比较、计数、私有调用或偶然的副本，只能检测改动，却无法指出被破坏的契约。
• 重复用例或测试层级没有带来独特价值。
• 测试了辅助函数，却漏掉了真实入口的连线逻辑。
• 负向测试因更早的无关校验而通过。
• 宽泛的断言无法区分预期结果与有实际意义的失败。
• 计时休眠、共享可变状态、测试顺序、未受控的时钟或随机性，以及资源泄漏。
• 仅供测试使用的导出项或钩子、过时的夹具、跳过的测试套件和已禁用的断言。
• 测试名称承诺的行为并未在输入和断言中实际体现。
• 设置或失败信息不透明、执行成本高，或维护频繁却几乎没有有用反馈。

来源

改编自 OpenClaw 测试审计及其审查工作流。在更新上游材料或署名之前，请阅读 UPSTREAM.md，了解源修订、许可证和本地改编内容。