测试用例评审 SKILL（增强版）

一、技能描述

核心功能

本技能提供一套可落地、可量化、可部分自动化的功能测试用例评审方案，围绕以下六大质量维度展开，每个维度下细分具体检查点：

补充特性（贯穿于上述维度中检查）：

• 可重复性
• 可追溯性
• 原子性
• 独立性
• 测试设计方法应用程度（等价类、边界值、判定表、状态转换、正交等）

适用场景

• ✅ 新功能用例初稿的快速自评
• ✅ 代码评审前的用例质量门禁
• ✅ AI 生成用例后的人工辅助复核
• ✅ 存量用例库的定期审计与优化
• ✅ 测试新人提交用例的导师式反馈

不适用场景

• ❌ 性能测试脚本、自动化代码评审
• ❌ 非功能需求（安全性、可移植性）的深度测试设计（可审查场景覆盖，但不评估测试手法）

二、输入规范

⚠️ 前置条件

需求文档和测试用例均为必填项，缺少任一项评审不可启动。

• 需求文档：评审的基准参照，用于需求覆盖率分析、业务规则覆盖完整性检查、用例准确性验证。缺少需求文档将导致无法判断用例是否遗漏需求点、预期结果是否与需求一致，评审结果不可靠。
• 测试用例：评审的直接对象。缺少测试用例则无评审内容。

若用户未提供需求文档或测试用例，必须先要求用户补充，不进入评审流程。

输入清单

需求文档解析要求

评审启动时，需从需求文档中提取以下信息用于评审比对：

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. 预期结果与需求描述一致性：检查测试用例的预期结果是否与需求文档中的业务规则、字段校验规则、异常反馈机制一致，不一致报高严重。

需求文档驱动的评审规则

基于需求文档进行以下深度检查：

需人工/AI 辅助判断的规则

以下检查需要结合业务知识或上下文分析，由评审者（或 AI 以问答引导方式）完成：

• 业务规则覆盖完整性（结合需求文档逐条比对）
• 边界值、等价类选取合理性
• 异常场景与真实错误处理逻辑匹配度
• 步骤是否可独立复现
• 预期结果是否具备缺陷发现能力
• 设计方法运用是否恰当

四、评审报告输出

输出路径

评审完成后，将评审报告输出为 Markdown 文件，保存到与当前 SKILL.md 同级目录下的 report/ 目录中：

report/

文件命名规则

格式：{项目/模块名称}测试用例评审报告.md

示例：

• 工作流二期_任务分配规则测试用例评审报告.md
• 用户管理模块测试用例评审报告.md
• 订单管理测试用例评审报告.md

报告结构模板

评审报告必须包含以下完整章节：

# {项目/模块名称} 测试用例评审报告

**评审日期**: 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（\x3C60）：打回重写

六大维度得分

注：原子性、独立性、可重复性、可追溯性等子特征已隐含在上述维度中，严重违规会在问题清单中体现。

� 需求追溯矩阵

基于需求文档逐条比对测试用例覆盖情况：

需求追溯矩阵必须基于需求文档中的功能点逐条生成，确保每个需求ID均有覆盖状态标注。

�🚨 本次评审侧重点

（若输入提供了评审侧重点，则显示）

本次评审特别侧重：权限、边界值、异常场景。相关问题严重度已自动升档。

🔴 高严重问题清单（必须修改）

🟡 中/低严重问题清单（建议修改）

📝 缺失场景补充建议

按测试设计技术及质量特性分类梳理，评审者逐项确认：

• 正常路径：_________________________________
• 备选/异常流：_________________________________
• 边界值/等价类：_________________________________
• 权限/角色组合：_________________________________
• 数据状态转换：_________________________________
• 并发/重复提交（幂等）：_________________________________
• 超时与中断：Session超时、API响应超时、操作中断（关闭/刷新）、断网处理
• 字段校验/注入：_________________________________
• 兼容性：浏览器兼容、分辨率适配、移动端适配
• 大数据量：分页边界、列表性能、导出大数据
• 数据导入导出：格式校验、空文件、超大文件、模板下载
• 数据安全/合规：敏感信息脱敏、操作审计、权限越级、CSRF攻击

🔗 用例依赖与执行顺序分析

• 依赖检测：
  • 识别因数据、状态、环境导致的硬依赖，并给出解耦建议（如使用 setUp 数据工厂、预置数据）。
  • 对于必须按流程执行的“场景流用例”，自动分组并标记执行顺序约束，不扣“独立性”分。
• 依赖清单：

✏️ 具体用例优化建议（逐条）

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分