测试用例评审最容易出现两种低效：会上才发现材料不全、前置条件缺失，或者用例写得热闹却无法判断通过与否。这份清单按“评审前准备—单条用例内容检查—覆盖与追溯检查—评审结论与关闭”四段组织，每项给出检查内容、通过标准、证据和负责人，并标出必须清零才能放行的阻断项，可直接用于自检、评审会核对和关闭复核。
要点总览（TL;DR）
- 清单按评审前准备、单条用例内容检查、覆盖与追溯检查、评审结论与关闭四段组织，每项写明检查内容、通过标准、证据和负责人。
- 单条用例检查的核心口径是：换一位不熟悉该模块的测试人员，能否仅凭用例描述完成执行并得出明确结论。
- 需求覆盖缺口、前置条件缺失、预期结果不可判定、追溯断链、关键路径用例缺失属于阻断项，必须清零才能放行。
- 评审结论分为通过、有条件通过、退回修改三类；阻断项全部关闭且非阻断项有明确处理计划，评审才算完成。
- 评审记录与问题跟踪可借助 ONES TestCase 的用例属性筛选、需求关联与任务流转来承载，具体状态字段按团队约定配置。
谁在什么时点使用这份评审清单
这份清单服务于用例评审的三个时点，不同角色在各时点承担不同动作。用例作者在提交评审前完成自检，评审人和需求、开发代表在评审会中逐项核对，测试负责人在评审后做关闭复核。把角色和时点先对齐，可以避免“作者以为评审人会补、评审人以为作者已查”的空白。
| 角色 | 介入时点 | 主要动作 | 前置输入 |
|---|---|---|---|
| 用例作者 | 提交评审前 | 按S2、S3逐项自检，处理笔误与重复用例，留存自检记录 | 需求或用户故事、设计说明、接口约定 |
| 评审人（测试同事） | 评审会中 | 核对单条用例的可执行性与可判定性，记录问题 | 待评审用例集、自检记录 |
| 需求或开发代表 | 评审会中 | 确认需求理解一致、前置条件与接口约定准确 | 需求条目、原型、接口文档 |
| 测试负责人 | 评审会中及评审后 | 判定覆盖与追溯是否闭合，形成结论，复核阻断项关闭 | 覆盖与追溯检查结果、问题记录 |
前置输入至少包括：本次需求或用户故事、设计说明、接口约定，以及相关模块的历史缺陷记录。历史缺陷能提示高风险场景，帮助判断用例是否覆盖了曾经出问题的路径。清单不覆盖跨项目用例资产复用与用例库建设，也不涉及测试脚本实现细节，这些内容应在其他环节单独处理。
评审前准备阶段检查项
评审会前的准备检查针对组织与材料完备性，不判断用例内容质量。目标是把“补信息”的动作留在会前，让评审时间用于讨论设计是否充分。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 用例集范围与本次需求变更范围一致 | 用例集能对应到本次变更的每条需求或验收条件，无遗漏模块，无与本次无关的大批用例混入 | 需求变更清单与用例集范围对照记录 | 用例作者 |
| 用例编号、所属模块、优先级字段已填写 | 字段无空缺，编号唯一，模块归属与用例库结构一致 | 用例集字段完整性抽查结果 | 用例作者 |
| 评审材料随用例一并提供 | 需求条目、原型或接口文档可在评审时直接查阅，版本与用例编写依据一致 | 评审材料清单及版本号 | 用例作者 |
| 评审参与人与时间已确定并通知 | 测试、需求、开发代表均确认参加，时间避开关键发布节点 | 评审通知与参会确认记录 | 测试负责人 |
| 自检记录已留存，明显笔误与重复用例已处理 | 自检表已填写，重复用例已合并或标注，笔误已修正 | 自检记录 | 用例作者 |
准备阶段任何一项未通过，评审会应推迟而不是带着缺口开会。尤其是材料版本不一致时，评审人核对的前提已经失真，继续评审只会产生无效结论。
单条用例内容质量检查项
这一部分是清单主体，逐条判断用例是否可执行、可判定。判断口径统一为：换一个不熟悉该模块的测试人员，能否仅凭用例描述完成执行并得出明确结论。
| 检查项 | 通过标准 | 证据 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 标题唯一描述一个验证点 | 标题只含一个目标，出现“并且”“同时验证”等并列表述时已拆分 | 用例标题清单 | 用例作者 | 否 |
| 前置条件具体到可复现状态 | 写明所需数据、账号、环境与初始状态，他人可据此搭建出相同起点 | 用例前置条件字段 | 用例作者 | 是 |
| 操作步骤可被他人按序执行 | 步骤按顺序编号，无“进行相关操作”等隐含动作，每步指向明确界面或接口 | 用例步骤字段 | 用例作者 | 是 |
| 预期结果可观察、可判定 | 写明具体字段值、状态变化或提示文案，不含“正常显示”“符合预期”等无法判定的表述 | 用例预期结果字段 | 用例作者 | 是 |
| 测试数据与边界值、异常输入有对应覆盖 | 每条用例标注所用数据，边界值与异常输入在用例集中有对应用例承接 | 用例数据说明与用例集清单 | 用例作者 | 是（缺失时） |
| 优先级与风险等级匹配 | 关键路径用例已标注高优先级，优先级与需求风险、历史缺陷分布一致 | 优先级字段与风险标注 | 测试负责人 | 是（关键路径缺失时） |
评审会中逐条核对时，建议按模块分批过，先看阻断项再看措辞与格式。预期结果不可判定是最常见的退回原因：一条用例写了“提交成功”，评审人无法判断是看提示、看列表状态还是看数据库记录，这类问题应在会上直接标为阻断并退回补充。
覆盖度与需求追溯检查项
覆盖检查从用例集整体出发，回答“需求是否被完整验证”，不重复单条用例的字段检查。追溯检查回答“每条用例为什么存在、对应哪条需求”。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 每条需求或验收条件至少映射到一条用例 | 需求清单逐条有对应用例编号，无空白项 | 需求—用例映射表 | 测试负责人 |
| 正向、异常、边界三类场景均有覆盖 | 每类场景在用例集中有明确对应用例，异常与边界不依赖“经验补充” | 场景覆盖统计 | 测试负责人 |
| 需求变更后受影响用例已同步更新 | 变更条目对应的用例已修订，修订记录可查 | 变更记录与用例修订记录 | 用例作者 |
| 用例与需求条目之间的追溯关系可查 | 从需求可定位到用例，从用例可回溯到需求，关联关系在工具中可见 | 追溯关系截图或系统记录 | 测试负责人 |
| 重复或冲突用例已合并或标注处理结论 | 重复用例已合并，冲突用例写明取舍理由与最终保留版本 | 用例合并与处理记录 | 用例作者 |
覆盖缺口要形成清单，逐条写明缺失的需求条目、缺失场景类型和建议补充的用例数量。追溯断链同样要落到具体用例编号，便于作者按编号补齐，而不是笼统回复“已检查”。
评审结论、证据留存与关闭条件
评审结束必须形成明确结论，避免“大家看过了”这类无法追踪的状态。结论分为三类：通过、有条件通过、退回修改。通过表示阻断项为零且非阻断项已处理；有条件通过表示阻断项已清零，非阻断项有明确责任人和处理期限；退回修改表示存在未关闭的阻断项。
每条问题记录至少包含：问题描述、所在用例编号、问题类型（阻断或非阻断）、责任人、处理期限。修改完成后需复核的用例范围要在结论中写明，通常包括所有被标记问题的用例及其关联用例。评审记录与结论归档到固定位置，与本次需求条目放在一起，便于后续追溯。
关闭条件有两条：阻断项全部关闭并经指定验证人确认；非阻断项有明确处理计划，包括责任人和完成时间。两条同时满足，评审才进入关闭状态。只满足其一，评审保持“有条件通过”或“退回修改”，不得标记完成。
在工具承载上，ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，用例属性可自定义并支持筛选，便于按模块、优先级组织评审范围；评审中发现的问题可记录为任务并跟踪到关闭。评审结论的具体状态字段与归档方式，可按团队约定在系统中配置。
阻断项清单与完成条件
阻断项是放行的硬门槛，评审负责人据此做最终判断。以下五类问题必须清零：需求覆盖缺口、前置条件缺失、预期结果不可判定、追溯断链、关键路径用例缺失。措辞、格式、优先级微调属于非阻断项，可带计划放行。
| 类型 | 具体表现 | 关闭验证方式 | 验证人 |
|---|---|---|---|
| 需求覆盖缺口 | 某条需求或验收条件无对应用例，或异常、边界场景整体缺失 | 补充用例后核对映射表，确认无空白项 | 测试负责人 |
| 前置条件缺失 | 用例未写明数据、账号或环境要求，他人无法复现起点 | 按补充后的前置条件实际搭建一次环境 | 评审人 |
| 预期结果不可判定 | 预期结果只有“正常”“成功”等表述，无具体字段值或状态 | 核对修订后的预期结果是否可直接判定 | 评审人 |
| 追溯断链 | 用例无法回溯到需求条目，或需求条目找不到对应用例 | 在系统中核对关联关系完整 | 测试负责人 |
| 关键路径用例缺失 | 核心业务流程无高优先级用例承接 | 核对关键路径清单与用例优先级标注 | 测试负责人 |
存在未关闭阻断项时，处理路径是退回修改并重新排期评审，不进入“有条件通过”。重新评审可只针对修改范围进行，但阻断项清零的验证记录必须留存。非阻断项则写入处理计划，在约定时间内完成，由测试负责人在关闭复核时确认。
常见问题
评审会上发现用例集范围与需求变更范围不一致，应该继续评审还是推迟？
建议推迟评审，先补齐范围对照。范围不一致意味着评审人核对的前提已经失真，继续评审容易得出无效结论，还会消耗参会人的时间。处理方式是：用例作者按需求变更清单重新圈定用例集，补充遗漏模块、剔除与本次无关的用例，再重新确认评审时间。如果只是个别需求条目归属不清，可以在会上先澄清并记录，但涉及整块模块缺失时，退回修改更稳妥。
预期结果写成“页面正常显示”算不算阻断项？
算阻断项。预期结果需要可观察、可判定，写明具体字段值、状态变化或提示文案。“正常显示”没有给出判断依据，执行人无法确认是通过还是失败，后续缺陷也难以界定。修订时可以把预期结果拆成可核对的具体项，例如列表新增一行且状态字段为“待审核”、页面出现指定提示文案。修订后由评审人核对是否可直接判定，确认通过后关闭该阻断项。
阻断项已清零但非阻断项还没改完，评审能否标记为通过？
可以标记为“有条件通过”，不能直接标记为通过。有条件通过的条件是阻断项全部关闭并经指定验证人确认，同时每条非阻断项都有明确责任人和处理期限。测试负责人在关闭复核时逐条确认非阻断项是否按计划完成，全部完成后评审才进入关闭状态。如果非阻断项没有责任人或者没有期限，说明处理计划不成立，应退回补充计划后再放行。
需求变更后，已经评审通过的用例需要重新走一遍评审吗？
按变更影响范围决定，不必整批重评。受变更影响的需求条目对应的用例需要修订，修订后针对这部分用例做复核，核对前置条件、步骤和预期结果是否与变更后的需求一致，并更新需求与用例的追溯关系。未受影响的用例保留原评审结论。复核记录与变更记录放在一起归档，便于后续追溯时看清哪次变更触发了哪批用例的修订。
评审记录和问题跟踪放在哪里比较合适？
关键是让评审结论、问题记录和需求条目能互相对应。ONES TestCase 支持测试用例与需求、任务关联，用例属性可自定义并支持筛选，可以按模块、优先级圈定评审范围；评审中发现的问题可记录为任务并跟踪到关闭。评审结论的具体状态字段和归档位置，可以按团队约定在系统中配置。无论用哪种方式，都要保证从需求能定位到用例、从问题能定位到责任人和处理期限。
