dsh-qa-skills
Version:
DeepSeek Harness (dsh) plugin: 10 testing skills (requirement analysis, test strategy, case writing/review, E2E/API automation, exploratory, regression, bug analysis) + shared core knowledge base — a full QA pipeline as agent skills.
91 lines (64 loc) • 5.33 kB
Markdown
---
name: test-case-review
slug: test-case-review
displayName: 测试用例评审
version: 0.6.0
description: 审查已有测试用例（存量资产、他人编写、AI 产出）的覆盖与可执行性时使用——先建可测点基准，再独立评估覆盖、可执行性与正确性，直接修订用例文件并留审查记录。不用于：从零写用例（test-case-writing）、写时自审（其阶段四）、端到端流水线（qa）。
---
# 测试用例审查（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` 全部检查项）
- 核心七维度逐项：功能主流程 / 输入校验 / 逆向操作与生命周期 / 状态流转 / 数据一致性 / 文档隐含需求 / 代码审查发现（有代码时）
- **二阶交叉**（`../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 是事后、独立审查 |