测试用例评审清单用于在需求澄清完成后、用例提交评审前启动自检，并在评审会与基线复核中逐项核对。清单覆盖评审前准备、单条用例内容、覆盖与设计方法、可执行性与可追溯性四个检查阶段，最后汇总为通过标准、证据与负责人对照表。覆盖缺失、预期结果不可判定、前置条件不完整、需求追溯断裂属于阻断项，未关闭的用例不得进入基线。
要点总览（TL;DR）
- 清单按“评审前准备—单条用例内容—覆盖与设计方法—可执行性与可追溯性”四个检查阶段组织，最后汇总为通过标准、证据与负责人对照表。
- 用例作者在提交评审前自检，评审人在评审会上逐项核对，测试负责人在基线前复核阻断项关闭与意见回填。
- 覆盖缺失、预期结果不可判定、前置条件不完整、需求追溯断裂属于阻断项，出现任一项即退回修改。
- 评审结论分为通过、有条件通过、退回三类；阻断项全部关闭并经复评、记录与版本快照归档、负责人签字后，用例集才进入基线。
谁在什么时点使用这份评审清单
这份清单面向四类角色：用例作者、评审人（测试、开发、产品）、测试负责人。作者用它做提交前自检，评审人用它逐项核对并记录意见，测试负责人用它判断用例能否进入基线。三类角色的检查深度不同，但使用同一套检查项和通过标准，避免自检与评审各说各话。
使用时点分三段。第一段在需求澄清完成后、用例提交评审前，由作者完成自检，自检不通过的用例不进入评审排期。第二段在评审会上，评审人按清单逐项核对，记录通过、不通过或需补充证据的条目。第三段在基线前，由测试负责人复核阻断项是否全部关闭、评审意见是否回填并二次确认。
清单的范围限定在用例设计内容与质量：单条用例是否写清楚、用例集是否覆盖需求、他人能否独立执行、关联字段是否完整。跨项目资产复用策略、测试脚本实现与自动化框架选型不在本清单内，这些内容需要单独的评审规则。范围边界写清楚，评审会才不会滑向工具选型和脚本细节的讨论。
| 角色 | 介入时点 | 主要动作 | 产出 |
|---|---|---|---|
| 用例作者 | 需求澄清后、提交评审前 | 按清单自检并修正 | 自检记录、待评审用例版本 |
| 评审人（测试、开发、产品） | 评审会上 | 逐项核对、记录意见 | 评审记录、问题条目 |
| 测试负责人 | 基线前复核 | 核对阻断项关闭与意见回填 | 评审结论、基线准入判断 |
评审前准备检查项
评审会空转最常见的原因是材料没就绪：需求还在改、用例范围没划、评审人没到齐。准备检查项在会议发起前完成，任一项不满足就推迟评审，而不是在会上补材料。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 需求版本已冻结 | 待评审用例对应的需求或用户故事有明确版本号，评审后发生的变更已单独标注并说明影响范围 | 需求版本记录、变更说明 | 产品负责人 |
| 用例集范围与优先级已划分 | 本次评审覆盖的模块、用例数量和优先级分布已列出；抽样评审时写明抽样规则与抽样比例 | 用例清单、抽样说明 | 用例作者 |
| 评审人角色到齐 | 测试、开发、产品三方至少各有一名评审人确认参加；缺席角色已指定代理人 | 评审通知与确认记录 | 测试负责人 |
| 评审记录载体已建立 | 评审记录有固定位置，能按用例编号记录意见、责任人和关闭状态 | 评审记录文档或工作项 | 测试负责人 |
| 作者自检已完成 | 作者已按单条用例内容检查项自检，遗留问题已标注并说明原因 | 自检记录 | 用例作者 |
单条用例内容检查项
单条用例检查是评审会的主要工作量。判断口径是：一名不了解该需求的测试人员读完这条用例，能否按步骤操作并得到与预期一致的结果。以下五项逐条核对，任一项不满足即记为不通过。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 标题唯一且描述单一验证点 | 标题能区分于同模块其他用例，一条用例只验证一个功能点或一个业务规则；标题中包含操作对象与场景 | 用例标题与编号清单 | 用例作者 |
| 前置条件与环境信息完整 | 写明账号角色与权限、初始数据状态、依赖的系统或服务、必要的配置项；缺少任一项会导致执行结果不同 | 用例前置条件字段 | 用例作者 |
| 操作步骤可复现，无隐含知识 | 步骤按执行顺序编号，每步有明确操作对象和输入；不出现“按常规操作”“参考某文档”这类需要额外询问才能执行的表述 | 用例步骤字段 | 用例作者 |
| 预期结果具体可判定 | 预期结果包含可观察的界面状态、数据值或系统行为，能明确判断通过或不通过；涉及数值时写明具体数值或范围 | 用例预期结果字段 | 用例作者、评审人 |
| 测试数据与依赖说明清楚 | 用例引用的测试数据有来源或构造方式；依赖其他用例执行结果时写明依赖关系 | 测试数据说明、依赖标注 | 用例作者 |
评审人核对时，对“预期结果具体可判定”这一项要格外严格。写成“页面显示正常”“提示成功”的预期结果无法判断通过与否，应要求作者补充具体的字段值、状态码或页面元素状态。这类问题在评审会上改比在执行阶段发现成本低得多。
覆盖与设计方法检查项
单条用例写清楚，不代表用例集覆盖充分。这一阶段从集合层面检查需求覆盖、设计方法运用和冗余情况，判断依据是追溯关系和设计记录，而不是评审人的印象。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 需求条目与用例双向追溯完整 | 每条需求至少关联一条用例；每条用例能回溯到需求条目或设计说明；无关联的用例需说明来源 | 需求—用例追溯矩阵 | 用例作者、测试负责人 |
| 设计方法选用与结果有记录 | 等价类划分、边界值分析、决策表等方法的使用情况有记录，说明选取了哪些输入域和边界；未使用的方法说明理由 | 用例设计说明 | 用例作者 |
| 异常流、边界与权限场景已覆盖 | 每个功能点至少包含正常流、异常流和边界场景；涉及角色的功能覆盖不同权限组合 | 用例分类统计、场景清单 | 用例作者、评审人 |
| 重复与冗余用例已识别并合并 | 同一验证点的重复用例已合并或标注保留理由；合并后用例编号有对应关系记录 | 用例变更记录 | 用例作者 |
覆盖检查的常见缺口是只覆盖正常流。评审时可以按功能点逐个确认：异常输入是否设计了对应用例、边界值是否取到了临界点两侧、多角色场景是否覆盖了权限差异。这些确认结果记入评审记录，作为覆盖结论的依据。
可执行性与可追溯性检查项
这一阶段回答两个问题：换一个人执行能否得到一致结果；用例与需求、缺陷、自动化入口的关联是否完整。前者靠交叉执行验证，后者靠字段核对。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 非作者可独立执行并得到一致结果 | 由未参与编写的测试人员按用例执行至少一条，执行结果与预期一致；执行中提出的疑问已回填到用例 | 交叉执行记录 | 评审人 |
| 用例编号与版本可追溯 | 每条用例有唯一编号，评审后的修改产生新版本记录，能查到修改人和修改内容 | 用例版本快照 | 用例作者 |
| 关联字段完整 | 用例与需求、相关缺陷、自动化标记的关联字段已填写；计划自动化的用例标注了自动化状态 | 用例关联字段、追溯矩阵 | 用例作者 |
| 评审意见已回填并二次确认 | 评审记录中的每条意见有处理结果（已修改、保留、转缺陷），修改后的用例经提出人确认 | 评审记录与确认记录 | 用例作者、评审人 |
当评审记录、用例版本和需求追溯分散在不同文档中时，意见回填和二次确认容易遗漏。ONES 支持在需求、测试用例与缺陷之间建立关联，评审意见可以作为工作项流转并保留处理状态，用例修改后形成新版本，测试负责人按关联关系核对阻断项是否关闭。这一流程适合评审条目较多、需要跨角色确认的团队；评审规模较小、参与人固定的团队用共享文档记录也能满足要求。
通过标准、证据与负责人对照
前四阶段的检查项汇总为一张对照表，供评审会逐项勾选。每项检查项的判定口径统一为：通过、不通过、需补充证据三种状态，不设“基本通过”这类模糊结论。
| 阶段 | 检查项 | 通过判定口径 | 证据形式 | 负责人 | 检查时点 |
|---|---|---|---|---|---|
| 评审前准备 | 需求版本冻结、范围划分、人员到齐、记录载体、作者自检 | 五项全部满足 | 需求版本记录、抽样说明、评审通知、自检记录 | 产品负责人、测试负责人、用例作者 | 评审发起前 |
| 单条用例内容 | 标题、前置条件、步骤、预期结果、测试数据 | 逐条核对，五项均满足 | 用例字段、评审记录 | 用例作者、评审人 | 评审会上 |
| 覆盖与设计方法 | 双向追溯、方法记录、异常与权限覆盖、冗余合并 | 四项均满足，缺口有说明 | 追溯矩阵、设计说明、用例分类统计 | 用例作者、测试负责人 | 评审会上 |
| 可执行性与可追溯性 | 交叉执行、版本追溯、关联字段、意见回填 | 四项均满足，意见全部关闭 | 交叉执行记录、版本快照、关联字段、确认记录 | 评审人、用例作者 | 评审会后至基线前 |
复核频次按项目节奏确定：迭代周期内提交评审的用例集，每次评审按全表核对；跨迭代的用例库更新，可按抽样规则复核阻断项和追溯字段。测试负责人对复核结果签字，作为基线准入的依据。
阻断项与完成条件
阻断项是评审结论为“退回”的直接依据，出现任一项即不得进入用例基线。阻断项清单如下：
- 覆盖缺失：需求条目没有对应用例，或功能点缺少异常流、边界场景。
- 预期结果不可判定：预期结果无法明确判断通过或不通过。
- 前置条件不完整：缺少账号权限、初始数据或环境配置，导致执行结果不确定。
- 追溯断裂：用例无法回溯到需求条目，或需求条目无任何用例关联。
阻断项的关闭条件是：问题条目已修改并形成新版本，提出人确认修改结果，评审记录中该条状态更新为已关闭。关闭后由测试负责人复评，复评只核对阻断项本身及受影响的关联字段，不重新展开全量评审。
评审结论分三类。通过：全部检查项满足，无阻断项，意见全部关闭。有条件通过：无阻断项，存在非阻断的改进意见，意见有明确责任人和完成时间，并在基线前完成。退回：存在任一阻断项，用例返回作者修改后重新提交评审。
用例进入基线的完成条件为：评审结论为通过或有条件通过；阻断项全部关闭并经复评；评审记录、用例版本快照和追溯矩阵归档；测试负责人确认签字。四项同时满足，用例集才进入基线，后续变更按版本管理流程处理。
常见问题
评审会上发现需求本身有歧义，用例检查还要继续吗？
建议暂停该需求相关用例的逐条核对，先把歧义点记录为待澄清问题，由产品负责人给出结论并更新需求版本。需求版本变化后，受影响的用例需要重新自检再提交评审。其余不受影响的需求可以继续按清单核对，避免整场评审因一个需求问题停摆。
抽样评审时，抽样比例怎么定才不至于漏掉阻断项？
抽样比例没有统一数值，可按风险确定：新增功能、核心业务流程、涉及权限与资金计算的用例优先全量评审；改动较小的模块可按模块和场景类型分层抽样，保证正常流、异常流、边界场景各有样本。抽样规则和比例要在评审前写入用例清单，评审记录中注明哪些用例未覆盖，便于基线前补查。
有条件通过的改进意见拖到基线前还没完成，怎么处理？
有条件通过的前提是意见有明确责任人和完成时间。到基线前仍未完成的意见，由测试负责人判断是否影响用例可执行性或覆盖结论：影响则升级为阻断项，用例退回修改；不影响则记录延期原因，明确后续版本处理时点。延期意见不能默认视为已关闭。
用例修改后，复评需要把整份清单重新过一遍吗？
不需要。复评只核对阻断项本身及受影响的关联字段，例如修改了前置条件就核对依赖的测试数据说明，修改了预期结果就核对对应的需求追溯关系。全量重评会拉长评审周期，也容易让评审人把注意力放在已通过的条目上。
评审记录用共享文档还是工作项管理，对清单执行有影响吗？
两种方式都能执行清单，差别在意见回填和二次确认的可追踪程度。评审条目少、参与人固定的团队用共享文档记录即可；评审条目多、需要跨角色确认关闭状态时，把评审意见作为工作项流转、与用例版本和需求关联，能减少遗漏。ONES 支持在需求、测试用例与缺陷之间建立关联，评审意见可保留处理状态，用例修改后形成新版本，测试负责人按关联关系核对阻断项是否关闭。
