测试用例评审要解决的问题，是用例能否支撑测试执行和缺陷发现。做法是先确定评审对象与准入条件，再按需求风险选择会议、书面或异步评审方式，明确作者、评审人、测试负责人、需求方四类角色的职责，用统一检查项判断用例是否通过，最后把意见回写用例并留存记录，形成可复查的闭环。
要点总览（TL;DR）
- 评审前先按需求风险与变更范围确定评审对象，并检查用例是否满足需求已澄清、设计方法已应用、字段完整、可执行四项准入条件。
- 评审按发起、独立审阅、汇总分歧、意见回写、复审关闭五步执行，每步都有明确输出物，完成标志是所有必须修改项复审通过。
- 作者、评审人、测试负责人、需求方四类角色职责分开：作者自检和修改，评审人按清单提问题，测试负责人组织和裁定，需求方确认业务与实现一致性。
- 检查项覆盖需求追溯、设计方法应用、步骤与预期结果可执行性、粒度与冗余、异常与边界场景，同一项目内保持清单稳定便于横向比较。
- 评审记录要包含对象、参与人、问题清单、分歧裁定和结论，有条件通过的待办需指定责任人和完成时间并到期核对。
评审前先定范围和准入条件
评审最常见的浪费，是把还没写完整的用例拉进会议室。评审前先做两件事：确定哪些用例需要评审，判断它们是否达到进入评审的条件。范围与准入定清楚，后续的评审方式、参与人和时间才有依据。
按需求风险与变更范围确定评审对象
不必所有用例都走同一套评审。可以按需求风险等级和变更范围划分：涉及核心交易、资金、权限、数据安全的需求，以及本次迭代新增或大改的需求，用例应纳入重点评审；界面文案调整、已有功能的轻微优化，用例可采用轻量评审或抽查。判断风险时可参考三个信号：需求失败的业务影响、实现逻辑的复杂程度、历史缺陷密度。风险高的需求，用例评审投入也应更高。
用例准入条件
进入评审的用例应满足以下条件，任一项不满足时先退回作者补充，不进入评审环节：
- 需求已澄清：需求文档、原型或接口说明已确认，待确认问题已有结论或明确标注。
- 设计方法已应用：作者已按需求特点选择等价类、边界值、判定表、场景法等设计方法，并说明覆盖思路。
- 字段完整：用例编号、所属需求、优先级、前置条件、操作步骤、预期结果、测试数据等字段填写完整。
- 可执行：步骤描述到他人可照做的程度，预期结果可观察、可判断。
评审方式的适用情形
| 评审方式 | 适用情形 | 主要成本 |
|---|---|---|
| 会议评审 | 高风险需求、跨模块复杂逻辑、需求方与开发需共同确认的场景 | 占用多人同步时间，需提前发材料 |
| 书面评审 | 常规需求、用例数量适中、问题以文字批注即可说清 | 意见往返周期较长，依赖评审人自觉 |
| 异步评审 | 分布式团队、评审人时间难对齐、需要留痕的批量用例 | 分歧收敛慢，需要明确截止时间 |
评审范围与准入判定可以整理成一张表，逐条记录对象、风险等级、评审方式和计划时间，作为发起评审的依据。
评审执行步骤：从发起到意见闭环
一次完整的用例评审包含发起、独立审阅、汇总分歧、意见回写、复审关闭五个步骤。每一步都有明确的输入、动作和输出，完成标志清晰，评审才不会停在“会开完了”的状态。
第一步：发起评审
输入是达到准入条件的用例集和需求资料。作者或测试负责人提交评审材料，并附评审说明：本次评审的范围、重点关注的模块、希望评审人确认的问题、评审截止时间。材料提前发出，给评审人留出独立阅读的时间。输出是评审任务和材料包。
第二步：评审人独立审阅并记录问题
评审人按检查清单逐条审阅，把问题记录到具体用例和具体字段上，写明问题类型和建议修改方向。问题描述要指向可修改的位置，例如“用例 TC-102 缺少密码错误次数超限的预期结果”，而不是“用例质量不高”。输出是问题清单。
第三步：会议或异步汇总分歧
会议评审由测试负责人主持，逐条过问题清单，重点讨论评审人与作者意见不一致的条目；异步评审则在约定时间内汇总各方意见，由测试负责人整理分歧点。输出是达成一致的问题结论和待裁定事项。
第四步：意见分类与回写用例
把意见分为三类处理：必须修改（影响覆盖或可执行性）、建议优化（表述、粒度、冗余）、无需修改（评审人理解偏差）。作者按分类逐条回写用例，必须修改项全部处理完毕，建议项说明采纳或不采纳的理由。输出是更新后的用例和意见处理记录。
第五步：复审与关闭
测试负责人对必须修改项逐条复审，确认修改到位后关闭评审；仍有争议的条目提交需求方或开发确认。输出是评审结论和关闭记录。完成标志是：所有必须修改项已处理并复审通过，评审记录已归档。
角色分工与各自交付物
评审涉及四类角色，职责边界清楚，才能避免“大家都看了一遍、没人对结果负责”。下表按角色列出主要职责和交付物。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 用例作者 | 评审前完成自检，确认准入条件；评审中解释设计思路；评审后按意见修改用例 | 自检记录、修改后的用例、意见处理说明 |
| 评审人 | 按检查清单独立审阅，提出具体问题并给出修改建议 | 问题清单（含用例编号、问题类型、建议） |
| 测试负责人 | 确定评审范围和方式，组织评审，裁定分歧，复审修改结果 | 评审计划、评审结论、复审记录 |
| 需求方/开发 | 确认用例对业务规则和实现逻辑的理解是否一致，澄清需求疑点 | 业务与实现一致性的确认意见 |
职责划分上有两个常见边界需要说清：测试负责人裁定的是评审流程和用例质量层面的分歧，业务规则本身的争议由需求方确认；评审人提出问题，修改责任在作者，评审人不直接改别人的用例，避免责任混淆。
用例评审检查项：判断用例是否通过
检查项的作用，是把“用例写得好不好”变成可以逐条勾选和判断的条目。评审人按清单审阅，测试负责人按清单复审，判断标准保持一致。
需求覆盖与追溯
- 每条需求都有对应用例，用例能追溯到需求编号或需求条目。
- 需求中的业务规则、约束条件在用例中有对应验证。
- 本次变更涉及的需求点已更新用例，旧用例没有残留过期逻辑。
用例设计方法应用
- 输入条件存在有效与无效区间时，是否使用等价类划分。
- 数值、长度、日期等有范围限制的字段，是否覆盖边界值及边界外取值。
- 多条件组合影响结果的逻辑，是否用判定表或因果图梳理。
- 有业务操作流程的场景，是否用场景法覆盖主流程与备选流程。
前置条件、步骤与预期结果的可执行性
- 前置条件写清了账号、数据、环境等必要准备。
- 步骤可被他人照做，没有“进行相应操作”这类模糊描述。
- 预期结果具体可观察，包含界面反馈、数据变化或状态变化。
- 测试数据明确，或说明了数据构造方式。
用例粒度与冗余
- 一条用例验证一个明确的测试点，步骤不过长。
- 重复或高度相似的用例已合并，没有为凑数量拆分。
- 用例优先级与需求风险匹配，高风险点有高优先级用例。
异常与边界场景覆盖
- 必填项为空、格式错误、超长输入等异常输入有对应用例。
- 网络中断、超时、重复提交等异常操作有覆盖。
- 权限不足、状态不允许等业务异常有验证。
检查清单可按项目情况增删条目，但同一项目内应保持稳定，便于横向比较不同批次用例的评审结果。
示例：一次需求变更下的用例评审
以下为演示情景，用来说明评审从发起到关闭的判断过程。
情景设定与评审对象
某系统对“登录密码错误锁定”规则做变更：连续输错 5 次锁定账号 30 分钟，原规则为 3 次锁定 10 分钟。该需求涉及账号安全，风险等级定为高，采用会议评审。作者提交了 12 条相关用例，包括正常登录、密码错误、锁定触发、锁定期间登录、锁定到期解锁等场景。
评审中发现的问题类型
- 覆盖缺失：没有覆盖“第 5 次错误触发锁定”的边界，只测了第 4 次和第 6 次。
- 预期结果不明确：锁定期间登录的用例只写“提示锁定”，未说明提示内容和是否计入错误次数。
- 规则理解不一致：开发指出锁定计时从首次错误开始计算，用例按最后一次错误计算，需求方确认以开发实现为准并补充说明。
- 冗余：两条用例仅测试数据不同，验证点相同，建议合并。
意见回写与复审结果
作者补充第 5 次错误的边界用例，明确锁定提示文案和错误次数计数规则，合并冗余用例，用例数调整为 11 条。测试负责人复审确认必须修改项全部处理，规则理解分歧已由需求方确认并写入用例备注，评审关闭。整个过程的问题、结论和参与人记录在评审记录中，供后续回归和规则再次变更时查阅。
评审记录与完成检查
评审记录既是过程留痕，也是判断评审是否真正完成的依据。记录不完整，后续复查就无法确认某条意见是否已处理。
评审记录字段
| 字段 | 内容说明 |
|---|---|
| 评审对象 | 用例集名称、所属需求、用例编号范围、版本 |
| 参与人 | 作者、评审人、测试负责人、需求方/开发及各自角色 |
| 评审方式与时间 | 会议、书面或异步，发起与完成时间 |
| 问题清单 | 问题所在用例、问题类型、严重程度、建议、处理结论 |
| 分歧与裁定 | 争议条目、各方意见、最终裁定人和结论 |
| 评审结论 | 通过、有条件通过（列出待办）、不通过 |
通过标准与阻断条件
评审通过的标准可以定为：需求覆盖无遗漏，必须修改项全部处理并复审通过，业务规则理解经需求方确认。出现以下情况时评审不通过或暂缓：关键需求点无用例覆盖、预期结果无法判断、业务规则存在未解决的分歧。阻断条件应在评审开始时说明，避免事后争议。
评审后的跟踪与复查
有条件通过的评审，待办事项要指定责任人和完成时间，到期逐条核对。需求再次变更时，先查历史评审记录，确认受影响的用例范围，再决定是否重新评审。评审记录与用例放在同一处管理，复查时可以直接从用例追溯到当时的评审结论。
当用例和评审记录分散在文档、表格和聊天工具中时，意见回写和状态跟踪容易断档。ONES 支持将用例作为工作项管理，评审意见记录在对应工作项上，评审状态和修改结果随工作项流转，评审记录与用例保持关联，便于测试负责人复审和后续复查。
常见问题
用例数量很多时，是否每一条都要评审？
可以按风险分级处理。核心交易、资金、权限、数据安全相关需求，以及本次迭代新增或大改的需求，用例纳入重点评审；界面文案调整、已有功能轻微优化，可采用抽查或轻量评审。抽查时建议优先覆盖高优先级用例和异常场景用例，并在评审记录中写明抽查范围和依据，便于后续追溯。
异步评审时意见迟迟收不齐怎么办？
发起评审时就要写明截止时间和逾期处理规则。常见做法是：截止时间前未反馈视为无意见，但需在评审说明中提前告知；关键评审人未反馈时，由测试负责人单独跟进或改为小范围会议确认。异步评审的分歧收敛依赖明确的责任人，测试负责人应在截止后一个工作日内汇总意见并给出结论。
评审中作者和评审人对某条用例意见不一致，由谁决定？
先区分分歧类型。属于用例质量、覆盖方式、粒度层面的分歧，由测试负责人裁定；属于业务规则本身理解不一致的，由需求方确认，开发补充实现说明。裁定结论要写入评审记录，涉及规则理解的还应写入用例备注，避免后续回归时再次产生同样争议。
需求变更后，原有已评审通过的用例需要重新评审吗？
取决于变更影响范围。先查历史评审记录，确认受影响的用例范围：变更涉及业务规则、输入条件或预期结果的，相关用例需要修改并重新评审；仅涉及界面文案等不影响验证逻辑的，可走轻量确认。重新评审时沿用原检查清单，重点核对变更点及受影响的边界和异常场景。
评审通过后，用例执行阶段发现遗漏，说明评审失败了吗？
评审的作用是降低遗漏概率，无法保证零遗漏。执行阶段发现遗漏时，建议记录遗漏类型和来源，作为下一轮评审检查清单的补充依据。如果同类遗漏反复出现，说明检查项或评审方式需要调整，例如加强边界值覆盖的核对，或对高风险需求增加评审人数量。
