测试用例评审的依据可以分成四层：需求与设计基线、用例设计规范、质量检查项、评审机制依据。四类依据齐备，评审才能围绕同一版本的需求和同一套检查口径展开；缺少其中任何一层，评审容易变成对用例写法的个人偏好讨论。下面给出依据清单、五步核对流程、角色分工、登录场景示例和完成检查表，供测试负责人或用例设计者在组织评审前直接对照使用。
要点总览（TL;DR）
- 测试用例评审的依据分为四层：需求与设计基线、用例设计规范、质量检查项、评审机制依据，四层齐备才能围绕同一版本和同一口径核对。
- 评审按五步推进：锁定基线并建立需求—用例对应关系、用设计规范核对结构与粒度、用质量检查项核对可执行性与覆盖、记录问题并判定结论、留存评审记录。
- 需求或产品角色提供基线，测试设计者提交用例与自检记录，评审参与者按检查项核对，记录与判定角色汇总问题并跟踪关闭。
- 评审结论应明确为通过、修改后复审或不通过，问题分级并指派责任人；影响覆盖完整性或可执行性的问题需复审，表述规范类问题可由记录角色确认关闭。
- 依据缺失时先补基线或先定最小检查项再评审，避免在依据不清的情况下直接判定用例质量。
评审前先确认四类依据是否齐备
评审会开始前，主持人应先逐类确认依据是否到位。判断标准是每一类依据都有明确载体、明确版本，并且参与评审的人能在会前拿到。以下四层依据分别回答不同问题，缺哪一层，就在评审中补哪一层，不宜跳过。
| 依据类别 | 包含内容 | 用来核对什么 | 版本确认动作 |
|---|---|---|---|
| 需求与设计基线 | 需求文档、原型、验收标准、接口与数据规则 | 用例是否覆盖了正确的业务规则和验收口径 | 确认需求文档版本号或更新时间，与用例关联的需求条目一致；原型与接口文档标注同一迭代版本 |
| 用例设计规范 | 用例模板、粒度与命名规则、编号规则、覆盖类型要求 | 用例结构是否统一、粒度是否合适、是否覆盖规定的类型 | 确认规范为当前生效版本，模板字段与规范一致 |
| 质量检查项 | 可执行性、可追溯性、边界与异常覆盖、前置条件与测试数据 | 单条用例能否被他人直接执行，能否追溯到需求 | 确认检查项清单为本项目当前使用的版本，新增检查项已同步给评审参与者 |
| 评审机制依据 | 准入条件、角色分工、问题分级与关闭标准 | 什么情况下可以开评审、问题如何定级、什么算关闭 | 确认评审规则文档或团队约定为最新，角色名单与当前项目成员一致 |
版本确认的关键动作是“对齐同一快照”。需求侧以需求文档或需求条目的当前版本为准，用例侧以提交评审的用例集版本为准，两者建立对应关系后再开始核对。若需求在评审前发生变更，应先更新需求基线并标注受影响用例，再进入评审，避免用旧用例对照新需求得出错误结论。
按依据逐条核对用例的操作步骤
依据齐备后，评审按五步推进。每一步都有明确输入、动作、输出和完成标志，主持人可按步骤控制节奏，避免评审滑向逐条朗读用例。
第一步：锁定基线并建立需求与用例的对应关系
输入是需求文档、需求条目清单和待评审用例集。动作是确认需求版本，逐条把用例关联到需求条目，标记没有对应用例的需求条目和没有需求来源的用例。输出是一张需求—用例对应表。完成标志是每条需求都有对应用例或明确的“不适用”说明，每条用例都能找到需求来源。
第二步：用设计规范核对结构与粒度
输入是用例模板、命名与编号规则、覆盖类型要求。动作是抽查或全量检查用例的字段完整性、标题命名是否体现场景与预期、编号是否连续可查、粒度是否落在“一个可独立验证的场景”这一层级。输出是结构问题清单，例如字段缺失、标题含糊、多条场景挤在一条用例中。完成标志是结构问题已记录并归类，不在此步纠缠业务逻辑对错。
第三步：用质量检查项核对可执行性与覆盖
输入是质量检查项清单和对应表。动作是逐条核对：前置条件是否写清、测试数据是否具体、步骤是否可被未参与设计的人执行、预期结果是否可观察、边界值与异常场景是否覆盖。输出是逐条用例的检查结论。完成标志是每条用例都经过检查项核对，边界与异常覆盖情况有明确记录。
第四步：记录问题并判定结论
输入是前三步形成的问题清单和问题分级标准。动作是按严重程度给问题分级，例如影响覆盖完整性的问题、影响可执行性的问题、表述规范类问题；据此对用例集给出通过、修改后复审或不通过的结论，并指派修改责任人。输出是带分级和结论的评审记录。完成标志是每个问题都有级别、责任人和期望关闭时间，用例集有明确结论。
第五步：留存评审记录与结论
输入是评审记录、问题清单和结论。动作是把记录归档到团队约定的位置，关联到对应需求或用例集，供后续复审和追溯使用。输出是可检索的评审证据。完成标志是记录可被项目成员查到，复审时能据此判断问题是否关闭。
在评审记录与问题跟踪环节，ONES 支持测试用例与需求、任务关联，测试计划与迭代关联，用例属性可自定义并支持筛选，便于把需求—用例对应关系和评审问题放在同一处管理；具体配置方式需按实际使用版本确认。
角色分工与各角色交付物
评审要避免变成用例设计者的单向宣讲，关键是每个角色都有明确交付物和交接时点。下表给出常见分工，团队可按项目规模合并角色，但交付物不宜省略。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 需求或产品角色 | 提供需求基线、验收标准，确认业务规则与边界 | 当前版本需求文档、验收标准、待确认问题答复 | 评审前提供基线；评审中确认规则；评审后答复遗留问题 |
| 测试设计者 | 提交用例与自检记录，说明覆盖思路和取舍 | 待评审用例集、自检记录、需求—用例对应表 | 评审前提交；评审后按问题修改并提交复审 |
| 评审参与者（开发、测试负责人、相关模块负责人） | 按检查项核对用例，提出具体问题 | 逐条检查意见、问题清单 | 评审中给出；评审后补充书面意见 |
| 记录与判定角色 | 汇总问题、给出结论、跟踪关闭 | 评审记录、问题分级与结论、关闭状态 | 评审结束时给出结论；复审时确认关闭 |
交接时点的作用是防止依据迟到。需求基线若在评审当天才提供，参与者没有时间对照，评审质量会明显下降。较稳妥的做法是提前一个工作日发出依据材料和用例集，评审会上只处理已阅读后仍存在的分歧。
一个登录场景的评审示例
以下为演示情景，用于说明依据如何落到逐条核对，不代表任何真实项目数据。
背景：登录功能的需求条目包括“正确账号密码可登录”“连续输错密码达到阈值后锁定账号”“验证码错误时提示并允许重试”，验收标准要求锁定后给出明确提示且锁定期间正确密码也不可登录。
依据对照：需求条目对应正常登录、密码错误、账号锁定、验证码失效四组用例。设计规范要求每条用例包含前置条件、测试数据、操作步骤、预期结果和关联需求编号。
检查项核对结果：正常登录用例覆盖完整；密码错误用例只写了“提示错误”，未区分剩余尝试次数提示；账号锁定用例缺少锁定期间用正确密码尝试的步骤，与验收标准不一致；验证码失效用例未写清验证码有效期这一前置条件，测试数据也未给出。
问题分级与处理：账号锁定用例缺少关键验证步骤，定为影响覆盖完整性的问题，要求补充后复审；验证码失效用例前置条件缺失，定为影响可执行性的问题，要求补充测试数据；密码错误用例提示描述不完整，定为表述规范类问题，可随修改一并处理。
评审结论与后续动作：用例集判定为修改后复审。测试设计者按问题清单修改，记录角色在复审时逐条确认关闭，评审记录关联到对应需求条目留存。
评审完成检查与常见遗漏
判断一次用例评审是否完成，可以逐项核对以下检查表。全部满足再宣布结束，比凭会议结束时间判断更可靠。
- 需求与用例的基线版本一致，变更已标注受影响用例。
- 每条需求条目都有对应用例或明确的不适用说明。
- 质量检查项已逐条核对，边界与异常场景的覆盖情况有记录。
- 问题已分级、已指派责任人，并有期望关闭时间。
- 用例集有明确结论：通过、修改后复审或不通过。
- 评审记录与结论已留存，可被项目成员检索。
依据缺失时需要先补依据再评审。需求不清时，先由需求或产品角色补齐需求基线和验收标准，再安排评审；设计规范缺失时，先定一份最小检查项，至少覆盖可执行性、可追溯性、边界与异常、前置条件与测试数据四项，作为本次评审的临时口径，后续再完善规范。
常见遗漏集中在三处：只核对功能主路径，异常和边界场景没有逐条确认；前置条件与测试数据写得笼统，用例换人执行时无法复现；需求与用例的对应关系没有建立，覆盖是否完整只能凭印象判断。复审的触发条件是存在影响覆盖完整性或可执行性的问题；表述规范类问题可在修改后由记录角色确认关闭，不必再次组织全员评审。
常见问题
需求文档在评审前发生变更，用例评审应该怎么处理？
先更新需求基线，再进入评审。具体做法是确认变更后的需求版本，标注受影响的用例条目，由测试设计者补充或调整对应用例，然后重新建立需求—用例对应关系。若变更范围较小，可在原评审记录中追加变更说明和受影响用例清单；若变更涉及验收标准或核心业务规则，建议重新组织一次针对受影响用例的评审，避免用旧用例对照新需求得出错误结论。
团队没有成文的用例设计规范，评审还能开展吗？
可以开展，但需要先定一份最小检查项作为本次评审的临时口径。最小检查项至少覆盖四项：用例能否被未参与设计的人直接执行、每条用例能否追溯到需求条目、边界与异常场景是否覆盖、前置条件与测试数据是否写清。这份临时口径应在评审前发给参与者，并在评审记录中注明本次使用的检查项版本。评审结束后再逐步把临时口径沉淀为团队规范，后续评审按正式规范执行。
评审中发现的问题应该由谁跟踪关闭？
由记录与判定角色统一跟踪。评审结束时，每个问题都应有级别、责任人和期望关闭时间；修改完成后，由责任人提交修改说明，记录角色按问题清单逐条确认关闭。影响覆盖完整性或可执行性的问题需要复审，复审时核对修改是否真正解决了原问题；表述规范类问题可由记录角色直接确认关闭，不必再次组织全员评审。关闭状态应更新到评审记录中，便于后续追溯。
用例评审记录需要留存哪些内容，留存在哪里比较合适？
评审记录至少包含：本次评审对应的需求版本与用例集版本、需求—用例对应关系、逐条检查结论、问题清单及分级、用例集结论、责任人与期望关闭时间、复审结果。留存位置应便于项目成员检索，并与对应需求或用例集建立关联。ONES 支持测试用例与需求、任务关联，用例属性可自定义并支持筛选，可以把需求—用例对应关系和评审问题放在同一处管理；具体配置方式需按实际使用版本确认。
只评审功能主路径的用例，会漏掉哪些风险？
主要漏掉三类风险：一是异常与边界场景未覆盖，例如输入超长、并发操作、状态切换时的边界值；二是前置条件与测试数据不明确，用例换人执行时无法复现，执行结果不可信；三是需求与用例的对应关系没有建立，覆盖是否完整只能凭印象判断。评审时按质量检查项逐条核对，把边界与异常覆盖情况、前置条件和测试数据明确性作为独立检查项记录，可以减少这类遗漏。
