testcase-reviewer

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 以问答引导方式）完成：

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

---

四、测试用例评审报告（输出模板）

📊 总体评价

• 用例总数：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	原子性/可重复性/...	具体问题	具体修改方案

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

序号	用例标识	问题类型	问题描述	修改建议

---

📝 缺失场景补充建议

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

• 正常路径：_________________________________
• 备选/异常流：_________________________________
• 边界值/等价类：_________________________________
• 权限/角色组合：_________________________________
• 数据状态转换：_________________________________
• 并发/重复提交（幂等）：_________________________________

• 字段校验/注入：_________________________________

---

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

• 依赖检测：
  • 识别因数据、状态、环境导致的硬依赖，并给出解耦建议（如使用 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扣3分
• 标题不规范（无动词且非对象+动作结构、过长）扣2分
• 优先级明显错误扣3分
• 术语不统一扣2分

可维护性（10分）

• 原子性不足（一个用例验证多个功能点）扣4分
• 独立性不足（强制执行顺序）扣3分
• 步骤与测试数据高度耦合扣3分