test-case-review v0.8.0A

Immutable. This exact content is served forever at /api/v1/blob/4f5b494354ffb68e.

---
name: test-case-review
slug: test-case-review
displayName: 测试用例评审
version: 0.8.0
description: Review existing test cases (legacy, others', AI) for coverage and executability: build a testable-points baseline, assess independently, revise in place with records. Not for: writing cases from scratch (test-case-writing), pipeline. 审查已有用例（存量/他人/AI 产出）的覆盖与可执行性：先建基准再独立评估，修订留审查记录。不用于：从零写用例、写时自审、流水线。
---

# 测试用例审查（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` 复验通过后再落盘
- 文件末尾追加审查记录：

```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 是事后、独立审查 |