test-case-review

测试用例审查（test-case-review）

回答"这些测试用例到底测得好不好"——事后、独立的审查（写时自审归 test-case-writing 阶段四）。

• 输入：已有用例文件（markmap + Schema，若无可先行抽取）、PRD / 需求模型、代码仓库
• 输出（落盘）：直接修订用例文件（修订后重新抽取 Schema）+ 审查记录（文件末尾附录）
• 审查记录内容：缺失 / 冗余 / 错误 / 高风险未覆盖，按 TC 编号列出

When to Use

• 审存量用例资产（祖传用例、他人编写）是否覆盖到位、能否执行
• 审 AI 产出的用例（覆盖 + 可执行性双线）
• 需要一份独立于编写者的审查结论（写时自审不能替代）

When NOT to Use

• 从零写用例 → test-case-writing
• 写用例过程中的自审 → test-case-writing 阶段四（4A/4B 两层审查）
• 端到端流水线中的审查环节 → 由 qa 调度本 skill，但单用户直接触发本 skill 同样适用
• 代码变更后的回归范围选择 → regression-testing

工作流

1. 建立可测点基准（分母）

覆盖审查需要一个合法分母，按优先级取：

1. 人工标注的可测点清单（存在时，最权威）
2. 需求模型 + 与用户共同确认的可测点清单（审查开始前列出，请用户补漏确认）
3. 仅有原始输入源 → 从 PRD/代码自行提炼可测点清单，**标注"未经确认"**并在交付时请用户复核

没有分母的覆盖率是给自己批改作业——基准缺失时如实说明，不编造覆盖率。

2. 覆盖审查（此时执行 ../core/coverage.md：核心 7 维逐项全检 + 横切可执行性）

• 核心七维度逐项：功能主流程 / 输入校验 / 逆向操作与生命周期 / 状态流转 / 数据一致性 / 文档隐含需求 / 代码审查发现（有代码时）；扩展维度（8–19）按 coverage.md「维度选取速查」按项目类型选取，不做机械全检（执行强度按消费方分流，见其文件头）
• 状态流转维度复核时加载 ../core/methods/state-machine.md：按其"状态集 × 事件集 × 转换边"清单逐边核对用例覆盖（每边至少一条 + 非法转换/并发竞态/逆向边三类必补），用例没按状态机组织时反向自行提取状态机再核对，防"看起来有覆盖"
• 二阶交叉（../core/testing-principles.md 第 3 节）：写入路径 × 校验规则、失败 × 重试、标识 × 重复——存量用例最常见的系统性缺口
• 对照基准逐点核记：已覆盖（TC 编号）/ 未覆盖 / 覆盖但断言错误 / 冗余（多条测同一点）/ 无效（测的不是本需求）

3. 可执行性审查（此时执行 ../core/executability.md 全部检查项）

逐条用例过八条硬标准，重点命中：

• 占位符数据（{xxx}、"某数据"）、虚构入口、模糊判定（"功能正常"）、异步无时限、断言超强度、前置不可得无 TODO、正文代码内部、缺导读四件套

4. 正确性审查（有 PRD/代码时）

• 用例预期结果与 PRD 规则 / 代码实现是否一致（静态裁决：代码为准，见 ../core/evidence.md）
• 优先级标注合理性（P0 逐条过自检：失败则核心不可用？）；风险等级对齐 ../core/risk-model.md（Critical 必有 P0）

5. 修订与落盘

• 直接在用例文件中修订：补缺失用例（追加 TC 编号）、删除冗余、改正错误断言、补可执行性要素（导读区/时限/入口路径/具体数据）；新增与改写的用例同样执行 ../core/case-format.md 格式硬约束（四段式/协作五段式、TC 编号、正文零代码内部）
• 修订后重新抽取 Schema（字段与转义规则见 ../core/schema-extraction.md），并用 ../core/scripts/validate_schema.py 复验通过后再落盘
• 文件末尾追加审查记录：

## 审查记录（test-case-review {日期}）
- 基准：{人工标注 / 需求模型确认 / 自行提炼（未经确认）}
- 审查前：XX 条用例，XX 个模块
- 审查后：XX 条用例，XX 个模块
- 缺失（已补）：TC-xx…（{场景}）
- 冗余（已删）：TC-xx…
- 错误（已改）：TC-xx…（{问题→修正}）
- 高风险未覆盖：{风险点 + 建议用例，无代码证据则标注}
- 可执行性修复：{占位符/时限/入口 等 XX 处}