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`） - 优先级标注...