测试用例评审的依据由四层材料构成：需求与设计基线、测试设计依据、质量规则、过程与历史依据。缺少任何一层，评审都容易变成对文字表述的主观讨论。本文按准备清单、四步比对流程、角色分工、比对示例和完成检查的顺序展开，帮助你把一次用例评审组织到可结束的状态。
要点总览（TL;DR）
- 测试用例评审依据分四层：需求与设计基线、测试设计依据、质量规则、过程与历史依据，每类都要有明确提供人。
- 比对顺序按“对齐需求与验收标准→检查设计方法覆盖→核对编写规范与检查表→确认可追溯与变更影响”推进，每步有输入、输出和完成标志。
- 评审中把提供材料与做出判断分开：产品角色澄清需求，测试负责人判断范围与方法，用例作者确认修改，主持人确保问题清单落地。
- 评审结束以五项检查为准：依据留痕、问题闭环到责任人、追溯关系建立、变更影响确认、结论明确。
- 有条件通过时写清复核人和复核条件，问题全部关闭后再转为通过。
评审前先备齐哪几类依据
评审依据的准备原则是：每类材料都能回答一个具体问题，并且能找到明确的提供人。需求基线回答“用例测的是不是该测的”，测试设计依据回答“方法是否充分”，质量规则回答“写法是否合规”，过程与历史依据回答“是否遗漏已知风险和变更影响”。四类材料在评审前汇总到同一处，评审时才能逐条比对而不是凭印象判断。
| 依据类别 | 具体材料 | 来源与提供人 | 在评审中的作用 | 缺失时的处理 |
|---|---|---|---|---|
| 需求与设计基线 | 需求文档、原型、接口说明、验收标准 | 产品经理或需求负责人提供，开发补充接口细节 | 核对用例覆盖的业务规则、输入输出和验收口径 | 需求条目缺失或表述模糊时，先记录为待澄清问题，相关用例暂缓给出通过结论 |
| 测试设计依据 | 测试策略、测试计划、用例设计方法说明、等价类与边界值分析结果 | 测试负责人提供策略与计划，用例作者提供设计方法说明 | 判断用例集是否覆盖主要风险，方法选择是否合理 | 策略或计划尚未成文时，由测试负责人现场说明范围与优先级，并记入评审记录 |
| 质量规则 | 用例编写规范、评审检查表、覆盖与可追溯要求 | 测试负责人或质量接口人维护 | 统一用例结构、步骤粒度、前置条件和预期结果的写法 | 规范缺失时，以团队既有模板为准，并在本次评审中沉淀检查项 |
| 过程与历史依据 | 缺陷记录、变更记录、历史评审意见、相关标准或行业规范 | 测试负责人汇总缺陷与变更，评审主持人整理历史意见 | 识别回归重点、变更影响范围和重复出现的问题 | 历史记录不全时，至少确认本次变更清单，其余作为后续补充项 |
准备阶段建议指定一人做依据汇总，把上述材料放到评审参与者都能访问的位置，并标注版本或日期。依据本身有多个版本时，以评审时确认的基线版本为准，避免会上对同一需求的不同稿子各说各话。
按什么顺序比对依据与用例
比对顺序遵循从“测什么”到“怎么测”再到“写得对不对”的逻辑。先确认覆盖对象，再检查设计方法，然后核对写法规范，最后确认追溯关系和变更影响。顺序颠倒会让评审陷入格式细节，遗漏覆盖缺口。
第一步：对齐需求与验收标准
输入是需求文档、原型、接口说明和验收标准，以及待评审用例清单。动作是逐条需求核对是否存在对应用例，检查预期结果是否与验收标准一致。输出是覆盖对照结果和缺口清单。完成标志是每条需求都有明确的覆盖结论：已覆盖、部分覆盖或未覆盖，未覆盖项有原因说明。
第二步：检查设计方法是否覆盖等价类、边界值、决策表等
输入是用例设计方法说明和第一步确认的覆盖范围。动作是检查关键输入是否划分了等价类，边界值是否取到上下边界及临界点，多条件组合的业务规则是否用决策表或类似方法展开。输出是方法适用性意见，指出哪些场景的方法使用不足。完成标志是主要业务规则和输入域都有对应的设计方法说明，方法缺口已记录。
第三步：核对编写规范与评审检查表
输入是用例编写规范和评审检查表。动作是逐条检查用例的标题、前置条件、操作步骤、预期结果、优先级和所属模块是否符合规范，步骤是否可独立执行，预期结果是否可观察。输出是格式与表述问题清单。完成标志是检查表各项均已勾选或标注不适用，问题定位到具体用例和具体条目。
第四步：确认可追溯关系与变更影响
输入是需求与用例的关联关系、变更记录和缺陷记录。动作是确认每条用例能追溯到需求或设计条目，本次变更涉及的用例已识别，历史缺陷对应的回归用例已纳入。输出是追溯缺口和变更影响清单。完成标志是追溯关系完整，变更影响范围有明确结论，需要补充或修改的用例已列入问题清单。
评审中谁提供依据、谁做判断
角色分工的关键是把“提供材料”和“做出判断”分开。提供人对自己材料的准确性负责，评审人对用例是否满足依据负责，主持人负责让结论和问题清单落地。
| 角色 | 提供的依据 | 在评审中的判断职责 | 产出的记录 |
|---|---|---|---|
| 测试负责人 | 测试策略、测试计划、用例编写规范、评审检查表 | 判断测试范围与优先级是否合理，方法使用是否充分 | 范围与方法类评审意见 |
| 用例作者 | 用例正文、设计方法说明、分析结果 | 解释设计意图，确认问题并承诺修改 | 修改说明与更新后的用例 |
| 需求或产品角色 | 需求文档、原型、验收标准 | 判断用例预期结果是否符合业务预期，澄清需求歧义 | 需求澄清结论 |
| 开发角色 | 接口说明、技术约束、变更记录 | 判断技术路径和异常场景是否被覆盖 | 技术相关补充意见 |
| 评审主持人 | 历史评审意见、问题清单模板 | 控制评审节奏，确认每条问题有责任人和处理时限 | 评审结论、问题清单、待办事项 |
评审结论通常分为通过、有条件通过和不通过三类。有条件通过意味着问题清单中的条目必须在约定时间内修改并复核，复核人一般由测试负责人或主持人指定。问题清单的归属应落到具体用例和具体责任人，避免只写“补充用例”这类无法验收的描述。
一个用例评审依据比对的示例
以下为演示情景，用于说明比对方式，不代表真实项目数据。
某订单模块新增“优惠券叠加使用”规则，需求文档规定：同一订单最多使用两张优惠券，且折扣类与满减类可以叠加，两张折扣类不可叠加。验收标准要求覆盖叠加成功、叠加失败提示和金额计算正确三种结果。用例作者提交了五条用例，评审按四步顺序比对。
第一步对齐需求时发现，五条用例覆盖了叠加成功和金额计算，但“两张折扣类不可叠加”的失败提示没有对应用例，记为覆盖缺口。第二步检查设计方法时发现，优惠券类型组合只测了折扣加满减，未用决策表展开全部组合，方法使用不足。第三步核对编写规范时发现，其中一条用例的预期结果写为“金额正确”，缺少具体计算口径，不符合可观察要求。第四步确认追溯关系时发现，本次变更涉及的旧用例未标注需要回归，变更影响未确认。
| 问题编号 | 关联依据 | 问题描述 | 修改责任人 | 处理要求 |
|---|---|---|---|---|
| R-01 | 需求文档与验收标准 | 缺少两张折扣类优惠券不可叠加的失败提示用例 | 用例作者 | 补充用例并关联对应需求条目 |
| R-02 | 用例设计方法说明 | 优惠券类型组合未用决策表完整展开 | 用例作者 | 补充组合分析并更新用例集 |
| R-03 | 用例编写规范 | 预期结果“金额正确”不可观察 | 用例作者 | 写明具体金额计算过程和预期数值 |
| R-04 | 变更记录 | 受影响的旧用例未标注回归范围 | 测试负责人 | 确认回归清单并更新测试计划 |
主持人当场确认四条问题的责任人和处理时限，评审结论记为有条件通过。复核时逐条核对问题状态，全部关闭后才转为通过。这个示例说明，依据比对的价值在于让每条问题都能指回一份材料，修改要求因此可以被验收。
当用例与需求、任务已经建立关联时，评审中的覆盖缺口和追溯缺口可以直接在关联关系上核对。ONES 支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；用例属性支持自定义，用例库中的属性可以筛选，便于按模块、优先级或变更范围取出待评审用例。评审产生的问题如果需要进入研发流程，未通过的用例可快速创建缺陷任务，在测试与研发团队间流转。是否把这些能力用于评审记录，取决于团队现有的评审流程和权限设置。
评审完成的检查项
评审是否可以结束，用以下五项逐条判断。每项都应有可查看的记录，而不是口头确认。
- 依据齐全并留痕：四类依据均已汇总，标注了版本或日期，缺失项有处理说明和责任人。
- 问题闭环到责任人和修改：问题清单中每条都有编号、关联依据、责任人、处理要求和时限，状态可追踪到关闭。
- 可追溯关系已建立：每条用例能对应到需求或设计条目，覆盖缺口已补充或有明确的不覆盖理由。
- 变更影响已确认：本次变更涉及的用例和回归范围有结论，相关测试计划已更新。
- 评审结论明确：结论为通过、有条件通过或不通过，有条件通过时写清复核人和复核条件。
五项全部满足时，评审可以结束并进入用例修改或执行阶段。若其中某项只能部分满足，应在评审记录中写明剩余事项和下次复核时间，避免评审结论悬空。
常见问题
需求文档本身写得模糊，用例评审还能进行吗？
可以推进，但相关用例不宜直接给出通过结论。做法是把模糊条目记录为待澄清问题，指定产品角色在约定时间内补充口径，受影响的用例标记为“有条件通过”或暂缓判断。评审记录中写明待澄清事项和复核时间，避免评审因个别需求条目悬空而整体停滞。
评审时发现用例覆盖不足，应该当场补写还是会后修改？
取决于缺口大小和评审节奏。单个边界值遗漏、预期结果表述不清这类小问题，可以当场确认修改要求并记入问题清单；涉及新业务规则、需要重新做等价类或决策表分析的大缺口，建议会后由用例作者补充，再安排一次简短复核。无论哪种方式，问题都要落到具体用例、责任人和时限，否则容易在会后被遗忘。
用例评审和需求评审的依据有什么不同？
需求评审主要依据业务目标、用户场景和验收标准，判断需求本身是否合理、完整、可实现；用例评审在此基础上增加测试设计依据和质量规则，判断用例是否覆盖了需求、设计方法是否充分、写法是否可执行。两者可以衔接：需求评审确认的验收标准，直接成为用例评审第一步的比对基准。
评审记录和问题清单放在哪里比较合适？
关键是让参与评审的人都能查看和更新，并且问题状态可追踪。常见做法是把评审结论和问题清单放在团队共用的文档或工作项中，每条问题关联对应用例和依据材料。如果用例已经与需求、任务建立关联，覆盖缺口和追溯缺口可以直接在关联关系上核对。ONES 支持测试用例与需求、任务关联，未通过的用例可快速创建缺陷任务，在测试与研发团队间流转；是否采用取决于团队现有流程和权限设置。
小团队没有成文的用例编写规范，评审依据怎么准备？
可以先用团队现有的用例模板作为临时质量规则，把本次评审中反复出现的写法问题整理成检查项，评审结束后沉淀为简版规范。测试策略和测试计划如果尚未成文，由测试负责人现场说明测试范围和优先级，并记入评审记录。规范是逐步积累的，首次评审的重点是让依据可比对、结论可追踪。
