| 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、标题、步骤、预期等基础字段。评审的直接对象 |
| 业务规则 | 键值对、表格或结构化描述 | 可选 | 额外补充的业务规则，例如：权限: 销售经理→发起按钮可见 |
| 评审侧重点 | 逗号分隔的关键词 | 可选 | 权限,边界值,异常场景,状态流转 |
| 团队规范 | 优先级/类型定义、命名规则、模板 | 可选 | 若不提供则采用通用规范 |
需求文档解析要求
评审启动时，需从需求文档中提取以下信息用于评审比对：
- 功能点清单：识别所有功能需求ID（如 FR-001、FR-002）及其描述
- 业务规则：提取字段校验规则、联动规则、状态流转规则、条件分支逻辑
- 异常场景：提取需求中定义的异常反馈机制（错误提示、降级策略、超时处理等）
- 非功能需求：提取性能指标、安全要求、可用性要求（如有）
- 字段定义：提取字段类型、校验规则、默认值、枚举值等
- 流程图/决策表：提取业务流程中的分支条件和状态转换节点
以上信息将用于与测试用例进行逐项比对，确保每个需求点均有对应测试覆盖。
用例字段最低要求
无论输入格式如何，单条用例必须至少包含：
- 用例ID/编号（唯一）
- 用例标题（简洁、包含动作和对象）
- 前置条件
- 测试步骤（明确、可操作）
- 预期结果（可验证、具体）
- 用例类型（如功能、UI、接口、异常）
- 优先级（P0/P1/P2/P3）
- 关联需求/模块标识/需求ID（建议必填）
格式校验（隐式前置步骤）
评审开始前自动执行格式校验，发现以下问题直接记入 “格式类问题清单” ，不纳入质量评分但必须修正：
- 必填字段为空
- 用例ID重复
- 优先级不在 { P0, P1, P2, P3 } 中
- 用例类型未在团队定义范围内
- 表格解析失败、列数不匹配
- 预期结果包含纯模糊词（如“成功”“正常”且无具体表现）
三、评审逻辑与自动化规则
可自动化检测的规则（Rule-based Lint）
以下检查可由脚本/工具自动完成，评审报告中会列出违规项：
- ID/编号 唯一性：重复则报高严重问题。
- 必填字段非空：标题、步骤、预期结果为空则报高严重。
- 优先级合规：超出取值范围报中严重。
- 关联需求缺失：
关联需求/模块标识/需求ID为空则提示低严重，降低可追溯性评分。
- 标题规范性：标题应以动词开头描述测试意图（如"验证""检查""测试"），或采用"对象+动作"结构（如"登录功能验证"），若标题过于简略或冗长报低严重。
- 预期结果模糊词检测：仅含"成功""正确""正常"等且无具体断言，报中严重。
- 步骤序列混乱：步骤编号不连续、存在跳号报低严重。
- 用例类型与预期内容匹配：例如用例类型为"异常"，预期却描述成功结果，报中严重。
- 需求覆盖率检测：将测试用例中的需求ID与需求文档中的功能点逐项比对，识别未覆盖的需求点，报高严重。
- 预期结果与需求描述一致性：检查测试用例的预期结果是否与需求文档中的业务规则、字段校验规则、异常反馈机制一致，不一致报高严重。
需求文档驱动的评审规则
基于需求文档进行以下深度检查：
| 检查项 | 检查方法 | 违规严重度 |
|---|
| 需求功能点覆盖 | 逐个检查需求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分
