测试用例审查（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. 建立可测点基准（分母）
覆盖审查需要一个合法分母，按优先级取：
- 人工标注的可测点清单（存在时，最权威）
- 需求模型 + 与用户共同确认的可测点清单（审查开始前列出，请用户补漏确认）
- 仅有原始输入源 → 从 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复验通过后再落盘 - 文件末尾追加审查记录：
markdown## 审查记录（test-case-review {日期}） - 基准：{人工标注 / 需求模型确认 / 自行提炼（未经确认）} - 审查前：XX 条用例，XX 个模块 - 审查后：XX 条用例，XX 个模块 - 缺失（已补）：TC-xx…（{场景}） - 冗余（已删）：TC-xx… - 错误（已改）：TC-xx…（{问题→修正}） - 高风险未覆盖：{风险点 + 建议用例，无代码证据则标注} - 可执行性修复：{占位符/时限/入口 等 XX 处}
6. 交付
给用户：修订后文件路径 + 审查记录摘要 + 基准可信度声明（是否经确认）+ 遗留建议（如"建议补充代码模式审查"）。
Common Mistakes
| 错误 | 后果 | 正确做法 |
|---|---|---|
| 无基准直接评覆盖率 | 自批自改，数字无意义 | 先建可测点基准并声明可信度 |
| 只查覆盖不查可执行性 | 覆盖 100% 但执行者无法开工 | 覆盖 + 可执行性双线审查 |
| 只报问题不修订文件 | 审查报告与用例文件两张皮 | 直接修订 + 修订后重抽 Schema |
| 审查记录写成独立报告文件 | 产物分散，下游找不到 | 记录追加在用例文件末尾 |
| 修订用例引入占位符/代码内部 | 制造新的不可执行问题 | 修订同样执行 ../core/executability.md 标准 |
| 把写时自审的活抢过来 | 与 test-case-writing 职责重叠 | 本 skill 是事后、独立审查 |
