back
loading skill details...
对功能测试用例进行自动化、结构化、可量化的质量评审，覆盖完整性、准确性、 有效性、规范性、可维护性、可执行性六大核心维度，并深度检查原子性、独立性、 可重复性、可追溯性、设计方法运用等优秀特征。 输出详细评审报告、缺失场景补充、依赖分析与改进建议。
---
name: testcase-reviewer
description: >
对功能测试用例进行自动化、结构化、可量化的质量评审，覆盖完整性、准确性、
有效性、规范性、可维护性、可执行性六大核心维度，并深度检查原子性、独立性、
可重复性、可追溯性、设计方法运用等优秀特征。
输出详细评审报告、缺失场景补充、依赖分析与改进建议。
tags: [测试, 用例评审, QA, 质量门禁, 测试设计]
---
# 测试用例评审 SKILL（增强版）
## 一、技能描述
### 核心功能
本技能提供一套**可落地、可量化、可部分自动化**的功能测试用例评审方案，围绕以下六大质量维度展开，每个维度下细分具体检查点：
| 维度 | 权重 | 核心关注点 |
|:---|:---|:---|
| **完整性** | 30% | 功能点、业务规则、边界值、异常场景、字段校验、状态流转是否全覆盖 |
| **准确性** | 25% | 前置条件清晰、步骤可执行无歧义、预期结果可验证且能暴露缺陷 |
| **有效性** | 15% | 用例设计方法运用恰当，能发现目标缺陷；断言不仅包含“做什么”还包含“不做什么” |
| **可执行性** | 10% | 测试数据可构造、环境依赖明确、步骤无跳步、无不可重现操作 |
| **规范性** | 10% | ID/标题/优先级/类型/术语符合团队标准，可追溯性达标 |
| **可维护性** | 10% | 原子性、独立性、步骤与数据解耦、结构清晰、易于修改 |
**补充特性**（贯穿于上述维度中检查）：
- 可重复性
- 可追溯性
- 原子性
- 独立性
- 测试设计方法应用程度（等价类、边界值、判定表、状态转换、正交等）
### 适用场景
- ✅ 新功能用例初稿的快速自评
- ✅ 代码评审前的用例质量门禁
- ✅ AI 生成用例后的人工辅助复核
- ✅ 存量用例库的定期审计与优化
- ✅ 测试新人提交用例的导师式反馈
### 不适用场景
- ❌ 性能测试脚本、自动化代码评审
- ❌ 非功能需求（安全性、可移植性）的深度测试设计（可审查场景覆盖，但不评估测试手法）
---
## 二、输入规范
### ⚠️ 前置条件
**需求文档和测试用例均为必填项，缺少任一项评审不可启动。**
- **需求文档**：评审的基准参照，用于需求覆盖率分析、业务规则覆盖完整性检查、用例准确性验证。缺少需求文档将导致无法判断用例是否遗漏需求点、预期结果是否与需求一致，评审结果不可靠。
- **测试用例**：评审的直接对象。缺少测试用例则无评审内容。
若用户未提供需求文档或测试用例，**必须先要求用户补充**，不进入评审流程。
### 输入清单
| 输入项 | 格式要求 | 是否必填 | 说明 |
|:---|:---|:---|:---|
| **需求文档** | Markdown(.md) / Word(.docx) / PDF / 纯文本 / PRD链接 | ✅ **必填** | 需求描述、用户故事、功能列表、业务规则、字段逻辑、流程图等。作为评审基准，用于覆盖度分析、业务规则匹配、预期结果准确性校验 |
| **测试用例** | Excel(.xlsx) / Markdown 表格 / JSON 数组 / 纯文本列表 | ✅ **必填** | 必须包含ID、标题、步骤、预期等基础字段。评审的直接对象 |
| 业务规则 | 键值对、表格或结构化描述 | 可选 | 额外补充的业务规则，例如：`权限: 销售经理→发起按钮可见` |
| 评审侧重点 | 逗号分隔的关键词 | 可选 | `权限,边界值,异常场景,状态流转` |
| 团队规范 | 优先级/类型定义、命名规则、模板 | 可选 | 若不提供则采用通用规范 |
### 需求文档解析要求
评审启动时，需从需求文档中提取以下信息用于评审比对：
1. **功能点清单**：识别所有功能需求ID（如 FR-001、FR-002）及其描述
2. **业务规则**：提取字段校验规则、联动规则、状态流转规则、条件分支逻辑
3. **异常场景**：提取需求中定义的异常反馈机制（错误提示、降级策略、超时处理等）
4. **非功能需求**：提取性能指标、安全要求、可用性要求（如有）
5. **字段定义**：提取字段类型、校验规则、默认值、枚举值等
6. **流程图/决策表**：提取业务流程中的分支条件和状态转换节点
> 以上信息将用于与测试用例进行逐项比对，确保每个需求点均有对应测试覆盖。
### 用例字段最低要求
无论输入格式如何，单条用例必须至少包含：
- **用例ID/编号**（唯一）
- **用例标题**（简洁、包含动作和对象）
- **前置条件**
- **测试步骤**（明确、可操作）
- **预期结果**（可验证、具体）
- **用例类型**（如功能、UI、接口、异常）
- **优先级**（P0/P1/P2/P3）
- **关联需求/模块标识/需求ID**（建议必填）
### 格式校验（隐式前置步骤）
评审开始前自动执行格式校验，发现以下问题直接记入 **“格式类问题清单”** ，不纳入质量评分但必须修正：
- 必填字段为空
- 用例ID重复
- 优先级不在 { P0, P1, P2, P3 } 中
- 用例类型未在团队定义范围内
- 表格解析失败、列数不匹配
- 预期结果包含纯模糊词（如“成功”“正常”且无具体表现）
---
## 三、评审逻辑与自动化规则
### 可自动化检测的规则（Rule-based Lint）
以下检查可由脚本/工具自动完成，评审报告中会列出违规项：
1. **ID/编号 唯一性**：重复则报高严重问题。
2. **必填字段非空**：标题、步骤、预期结果为空则报高严重。
3. **优先级合规**：超出取值范围报中严重。
4. **关联需求缺失**：`关联需求/模块标识/需求ID`为空则提示低严重，降低可追溯性评分。
5. **标题规范性**：标题应以动词开头描述测试意图（如"验证""检查""测试"），或采用"对象+动作"结构（如"登录功能验证"），若标题过于简略或冗长报低严重。
6. **预期结果模糊词检测**：仅含"成功""正确""正常"等且无具体断言，报中严重。
7. **步骤序列混乱**：步骤编号不连续、存在跳号报低严重。
8. **用例类型与预期内容匹配**：例如用例类型为"异常"，预期却描述成功结果，报中严重。
9. **需求覆盖率检测**：将测试用例中的需求ID与需求文档中的功能点逐项比对，识别未覆盖的需求点，报高严重。
10. **预期结果与需求描述一致性**：检查测试用例的预期结果是否与需求文档中的业务规则、字段校验规则、异常反馈机制一致，不一致报高严重。
### 需求文档驱动的评审规则
基于需求文档进行以下深度检查：
| 检查项 | 检查方法 | 违规严重度 |
|:---|:---|:---|
| 需求功能点覆盖 | 逐个检查需求ID是否有对应测试用例 | 未覆盖报高严重 |
| 业务规则覆盖 | 逐条比对需求中的业务规则是否被用例验证 | 未覆盖报中严重 |
| 字段校验覆盖 | 比对需求中的字段定义（类型、约束、默认值）是否被用例验证 | 未覆盖报中严重 |
| 异常场景覆盖 | 比对需求中的异常反馈机制是否有对应异常测试用例 | 未覆盖报高严重 |
| 预期结果准确性 | 比对用例预期结果与需求中的具体描述（提示文案、UI表现、状态变更）是否一致 | 不一致报高严重 |
| 状态流转覆盖 | 比对需求中的状态流转图是否被用例完整覆盖 | 未覆盖报中严重 |
| 非功能需求覆盖 | 比对需求中的性能指标、安全要求是否有对应测试用例 | 未覆盖报低严重 |
### 需人工/AI 辅助判断的规则
以下检查需要结合业务知识或上下文分析，由评审者（或 AI 以问答引导方式）完成：
- 业务规则覆盖完整性（结合需求文档逐条比对）
- 边界值、等价类选取合理性
- 异常场景与真实错误处理逻辑匹配度
- 步骤是否可独立复现
- 预期结果是否具备缺陷发现能力
- 设计方法运用是否恰当
---
## 四、评审报告输出
### 输出路径
评审完成后，将评审报告输出为 Markdown 文件，保存到与当前 SKILL.md 同级目录下的 `report/` 目录中：
```
report/
```
### 文件命名规则
格式：`{项目/模块名称}测试用例评审报告.md`
示例：
- `工作流二期_任务分配规则测试用例评审报告.md`
- `用户管理模块测试用例评审报告.md`
- `订单管理测试用例评审报告.md`
### 报告结构模板
评审报告必须包含以下完整章节：
```markdown
# {项目/模块名称} 测试用例评审报告
**评审日期**: YYYY-MM-DD
**需求文档**: {需求文档路径或链接}
**测试用例**: {测试用例文件路径或链接}
**评审依据**: testcase-reviews 技能
---
## 一、总体评价
（总体评价、需求覆盖率、综合评分、六大维度得分表格）
## 二、需求追溯矩阵
（逐条比对需求ID与测试用例覆盖情况）
## 三、格式类问题清单
（自动检测的格式问题，不计入评分但必须修正）
## 四、高严重问题清单（必须修改）
（原子性、准确性、需求一致性等高严重问题）
## 五、中/低严重问题清单（建议修改）
（规范性、完整性等中低严重问题）
## 六、缺失场景补充建议
（按测试设计技术分类的缺失场景）
## 七、用例依赖与执行顺序分析
（依赖检测、场景流分组、解耦建议）
## 八、具体用例优化建议（逐条）
（针对问题用例的具体修改建议）
## 九、评审总结与行动项
（问题统计、通过条件、结论）
```
---
## 五、测试用例评审报告（详细内容模板）
### 📊 总体评价
- 用例总数：**X** 条
- 需求功能点总数：**X** 个（从需求文档提取）
- 需求覆盖率：**X%**（已覆盖功能点 / 需求功能点总数）
- 未覆盖需求点：**X** 个（列出具体需求ID）
- 综合评分：**XX/100** （等级：**A/B/C/D**）
- 等级定义：
- **A（≥90）**：优秀，可直接进入自动化或执行
- **B（75-89）**：良好，少量修改后通过
- **C（60-74）**：需重点修改并复审
- **D（<60）**：打回重写
#### 六大维度得分
| 维度 | 得分 | 满分 | 关键扣分项举例 |
|:---|:---|:---|:---|
| 完整性 | XX | 30 | 缺少小数边界、权限组合漏测、异常未覆盖 |
| 准确性 | XX | 25 | 步骤有歧义、预期不具体、数据未指明 |
| 有效性 | XX | 15 | 未应用设计方法，断言无反向验证 |
| 可执行性 | XX | 10 | 测试数据不可构造、环境未说明 |
| 规范性 | XX | 10 | 无需求ID、标题不规范、优先级滥用 |
| 可维护性 | XX | 10 | 用例强依赖、复合断言、步骤与数据紧耦合 |
> 注：原子性、独立性、可重复性、可追溯性等子特征已隐含在上述维度中，严重违规会在问题清单中体现。
### � 需求追溯矩阵
基于需求文档逐条比对测试用例覆盖情况：
| 需求ID | 需求描述 | 测试用例覆盖 | 覆盖度 | 备注 |
|:---|:---|:---|:---|:---|
| FR-001 | 需求描述 | TC_001, TC_002 | ✅ 完整 | — |
| FR-002 | 需求描述 | TC_003 | ⚠️ 部分 | 缺少XX场景 |
| FR-003 | 需求描述 | — | ❌ 未覆盖 | 需新增用例 |
> 需求追溯矩阵必须基于需求文档中的功能点逐条生成，确保每个需求ID均有覆盖状态标注。
### �🚨 本次评审侧重点
（若输入提供了`评审侧重点`，则显示）
> 本次评审特别侧重：**权限、边界值、异常场景**。相关问题严重度已自动升档。
---
### 🔴 高严重问题清单（必须修改）
| 序号 | 用例标识 | 问题类型 | 问题描述 | 修改建议 |
|:---|:---|:---|:---|:---|
| 1 | TC_XXX | 原子性/可重复性/... | 具体问题 | 具体修改方案 |
### 🟡 中/低严重问题清单（建议修改）
| 序号 | 用例标识 | 问题类型 | 问题描述 | 修改建议 |
|:---|:---|:---|:---|:---|
---
### 📝 缺失场景补充建议
按测试设计技术及质量特性分类梳理，评审者逐项确认：
- [ ] **正常路径**：_________________________________
- [ ] **备选/异常流**：_________________________________
- [ ] **边界值/等价类**：_________________________________
- [ ] **权限/角色组合**：_________________________________
- [ ] **数据状态转换**：_________________________________
- [ ] **并发/重复提交（幂等）**：_________________________________
- [ ] **超时与中断**：Session超时、API响应超时、操作中断（关闭/刷新）、断网处理
- [ ] **字段校验/注入**：_________________________________
- [ ] **兼容性**：浏览器兼容、分辨率适配、移动端适配
- [ ] **大数据量**：分页边界、列表性能、导出大数据
- [ ] **数据导入导出**：格式校验、空文件、超大文件、模板下载
- [ ] **数据安全/合规**：敏感信息脱敏、操作审计、权限越级、CSRF攻击
---
### 🔗 用例依赖与执行顺序分析
- **依赖检测**：
- 识别因数据、状态、环境导致的硬依赖，并给出解耦建议（如使用 setUp 数据工厂、预置数据）。
- 对于必须按流程执行的“场景流用例”，自动分组并标记执行顺序约束，不扣“独立性”分。
- **依赖清单**：
| 依赖类型 | 前置用例 | 后置用例 | 解耦建议 |
|:---|:---|:---|:---|
| 数据依赖 | TC_01 注册 | TC_02 登录 | 建议 TC_02 通过 API 直接插入用户 |
---
### ✏️ 具体用例优化建议（逐条）
**TC_001：用例标题**
- **问题**：预期结果仅写“提示成功”，未指明提示文案或后续页面状态。
- **建议**：明确为“顶部弹出绿色toast‘保存成功’，页面跳转至列表页，新记录出现在第一行”。
---
### ✅ 评审总结与行动项
- 格式问题：**X** 条（详见格式清单，不计入评分）
- 必须修改项（高严重）：**X** 条
- 建议修改项（中低严重）：**Y** 条
- 优先级调整建议：升级 **X** 条，降级 **Y** 条
- 缺失场景补充：**Z** 个类别需新增用例
- 依赖解耦动作：**W** 项
**通过条件**：高严重问题清零 且 综合评分 ≥ 75
---
## 六、附录：评分细则参考（部分示例）
### 完整性（30分）
- 每个已识别功能点缺覆盖扣5分
- 每个业务规则缺覆盖扣5分
- 每个等价类缺边界值扣2分
- 每个异常路径缺失扣5分
- 缺少重要字段校验扣3分
### 准确性（25分）
- 前置条件缺失或无法实现扣5分
- 测试步骤存在歧义或跳跃扣5分
- 预期结果无法验证或表述模糊扣5分
- 未提供具体测试数据扣3分
- 可重复性存疑扣2分（如依赖随机值、未说明清理动作）
### 有效性（15分）
- 明显未使用设计方法（如输入域只有正常值）扣8分
- 断言不包含反向验证（如只验证跳转，不验证按钮置灰）扣5分
- 用例无法暴露已知缺陷扣2分
### 可执行性（10分）
- 数据无法构造或未提供构造方法扣5分
- 环境依赖未说明扣3分
- 步骤无法独立复现扣2分
### 规范性（10分）
- 缺少关联需求ID扣2分
- 标题不规范（无动词且非对象+动作结构、过长）扣2分
- 优先级明显错误扣4分
- 术语不统一扣2分
### 可维护性（10分）
- 原子性不足（一个用例验证多个功能点）扣4分
- 独立性不足（强制执行顺序）扣3分
- 步骤与测试数据高度耦合扣3分
don't have the plugin yet? install it then click "run inline in claude" again.