test-audit

测试套件审计

步骤 1：明确范围

如果请求中已指定范围，请跳至步骤 2。否则询问：

你希望我审计：

1. 特定文件 — 提供测试文件的路径
2. 仅审计已更改的文件 — 我会审计与 main 相比的差异中的测试（新增或修改的测试）
3. 整个项目 — 我会扫描代码库中的所有测试文件

另外：是否有规范、问题或必需测试用例列表，供我对照检查？

等待答复。范围确定且已知是否存在规范后，即完成此步骤。

步骤 2：收集上下文

阅读项目的测试配置、软件包脚本和 CI 文件，找出测试框架、测试命令和测试文件。然后为范围内的每个测试文件收集：

• 被测代码 — 阅读相关代码；许多测试问题都源于生产代码
• 规范 — 用户的用例列表、PR 描述、关联问题、规范或计划文件
• 历史记录（差异审计）— 检查在只删除代码的提交中新增的测试

找到测试命令、范围内的测试文件列表，以及每个测试文件所测试的生产文件后，即完成此步骤。

步骤 3：应用审计标准

将 references/audit-criteria.md 的每个部分应用于范围内的每项测试。检查完每个部分与每个文件的对应情况后，即完成此步骤；包括会产生 设计 发现的部分（可测试性与设计信号），以及规范差距（与规范的可追溯性）。

步骤 4：衡量测试强度（可选）

如果该语言有变异测试工具，请提议在审计范围内运行该工具。运行前请阅读 references/mutation-testing.md：其中说明了前置条件、工具标志以及如何对存活的变异体分类。如果用户拒绝，或没有可用工具，则仅进行静态审计。

步骤 5：报告发现

除非某项标准另有规定，严重程度如下：

• 高 — 测试可能通过，但其声称验证的行为实际已损坏；或者必需的错误场景或安全场景没有测试
• 中 — 测试较弱、脆弱或具有误导性：会遗漏一些缺陷，或会因重构而失败
• 低 — 命名、结构、风格

针对每个问题：

### [HIGH | MEDIUM | LOW] [Test | Design] Issue Title

**File**: `path/to/test_file.ext`
**Test**: `test name`
**Lines**: X–Y

**Problem**: What's wrong

**Current**:
[code snippet]

**Fix**:
[corrected code]

**Why**: One-sentence rationale

对于 设计 发现，文件应指向生产文件，并在 修复 下给出生产代码修复方案，之后再附上短期测试修复方案。

步骤 6：总结

最后总结：

1. 关键问题 — 高级别发现
2. 质量问题 — 中级别发现
3. 风格问题 — 低级别发现
4. 设计发现 — 能让测试更简单的生产代码改动
5. 测试强度 — 若步骤 4 已运行：工具、范围、有价值的存活变异体（分数仅作参考）；否则写“仅静态审计”
6. 整体健康状况 — 一段话
7. 优先事项前 3–5 项 — 影响最大的改进
8. 建议测试列表 — 每个缺失用例写成一行“给定/当/则”格式，可直接粘贴到下一条发给 Agent 的提示词中