需求变更提交后，测试用例往往需要同步修改并重新评审。这份检查清单按“变更覆盖—设计完整性—可执行性—可追溯与证据”四段组织，每项给出通过标准、证据和负责人，帮助测试负责人和用例作者判断评审能否通过。变更点遗漏、预期结果缺失等属于阻断项，未闭环前评审不能结束。
要点总览（TL;DR）
- 需求变更后先做变更覆盖核对：变更单中每个新增、修改、删除的影响点，都要指向用例或写明理由的“不需覆盖”结论。
- 单条用例按标题、前置条件、步骤、预期结果、异常与边界逐项检查，判断标准是评审人仅凭用例即可复现执行。
- 可执行性与可追溯检查聚焦需求与变更关联、优先级与执行顺序、数据环境账号就绪、历史缺陷回溯。
- 变更点遗漏、预期结果缺失或无法判定、关键场景无对应用例、遗留问题未指派负责人属于阻断项，清零前评审不能结束。
- 评审结论分通过、有条件通过、退回修改三级，每项检查都要有证据和责任人，结论与用例版本一并留痕。
谁在什么时点使用这份评审清单
这份清单在需求变更提交、用例修改完成待评审时启动。它检查的是用例设计及内容质量，包括变更点是否落到用例、单条用例写得是否完整、能否执行和追溯；测试脚本实现、自动化框架选型、跨项目用例资产复用不在本次评审范围内，需要时另行组织专项评审。
参与角色按职责分工，避免评审变成作者一个人的自检：
| 角色 | 主要职责 | 在评审中的动作 |
|---|---|---|
| 用例作者 | 完成用例修改与自检 | 按清单逐项自查，准备变更单、用例版本等证据，提交评审 |
| 测试负责人 | 组织评审、汇总结论 | 确认评审范围，汇总各检查项结果，给出通过、有条件通过或退回修改的结论 |
| 需求/产品代表 | 确认变更理解一致 | 核对变更点映射是否完整，对“不需覆盖”的结论给出确认 |
| 开发代表 | 确认实现影响面 | 补充变更对接口、数据、兼容性的影响，核对回归范围是否合理 |
时点上有一个容易忽略的细节：评审应在用例修改完成、但尚未进入执行排期之前进行。此时修改成本最低，变更理解的分歧也最容易暴露。若用例已排入执行计划再补评审，阻断项的处理往往要挤占执行时间。
第一阶段：变更覆盖检查项
需求变更后的评审，第一件事是确认变更点是否全部落到用例。这一阶段不评价单条用例写得好不好，只回答“该覆盖的是否都覆盖了”。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 变更点逐条映射 | 变更单中每个新增、修改、删除的影响点，都能指向至少一条用例，或有一份写明理由的“不需覆盖”结论 | 变更单与用例的关联记录、映射说明 | 用例作者，需求代表确认 |
| 新增影响已补用例 | 变更引入的新功能、新分支、新数据状态均有对应用例 | 新增用例清单及版本 | 用例作者 |
| 修改影响已修订旧用例 | 受影响的旧用例已更新步骤与预期结果，版本号有变化 | 用例修改记录、版本对比 | 用例作者 |
| 删除影响已处理 | 失效用例已标注失效或归档，未继续留在回归集中 | 用例状态记录 | 用例作者，测试负责人确认 |
| 回归范围与影响面一致 | 回归用例集覆盖变更影响面，未出现影响面内无用例、影响面外大量无关用例的情况 | 回归范围说明、影响面分析 | 测试负责人，开发代表确认 |
“不需覆盖”的结论需要写清理由，例如变更仅涉及日志文案、不影响可观测行为。理由由需求代表确认后留档，避免后续追溯时无法判断这是有意决策还是遗漏。
第二阶段：用例设计质量检查项
覆盖确认之后，逐条检查用例本身是否写完整。这一阶段的判断标准很直接：评审人仅凭用例内容即可复现执行，无需作者口头补充。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 标题 | 能唯一识别场景，包含对象、动作和关键条件，同类场景之间可区分 | 用例标题 | 用例作者 |
| 前置条件 | 写明环境、账号、数据准备和系统状态，他人按描述可复现初始状态 | 用例前置条件字段 | 用例作者 |
| 操作步骤 | 单步单动作，含必要输入数据；步骤顺序与真实操作一致 | 用例步骤字段 | 用例作者 |
| 预期结果 | 具体可判定，写明界面反馈、数据变化或状态流转，避免“正常显示”这类无法判断的表述 | 用例预期结果字段 | 用例作者，评审人确认 |
| 异常与边界覆盖 | 变更涉及的异常分支、边界值、空值与非法输入有对应用例或明确说明不覆盖的理由 | 用例清单、覆盖说明 | 用例作者，开发代表确认 |
预期结果是这一阶段最常见的退回原因。变更后的业务规则往往带来新的判定条件，若预期结果仍沿用变更前的描述，执行时就会出现“结果对不上但说不清谁错”的情况。评审时建议对照变更单逐条读预期结果，确认判定口径已经更新。
第三阶段：可执行性与可追溯检查项
用例写得完整，还要确认能被执行、能回溯来源。这一阶段检查关联关系和执行依赖，不重复上一阶段的设计要素检查。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 需求与变更关联 | 每条用例可追溯到需求条目或变更单，双向可查 | 用例与需求、变更单的关联记录 | 用例作者 |
| 优先级与执行顺序 | 用例标注优先级，存在先后依赖的用例写明执行顺序 | 用例优先级字段、顺序说明 | 测试负责人 |
| 测试数据就绪 | 用例引用的数据已准备或写明生成方式，数据状态与前置条件一致 | 数据准备清单 | 用例作者 |
| 环境与账号就绪 | 所需环境版本、账号权限已确认可用 | 环境确认记录 | 测试负责人 |
| 缺陷回溯 | 变更相关的历史缺陷已关联到对应用例，作为回归依据 | 缺陷与用例关联记录 | 用例作者 |
可追溯的价值在变更反复时体现得最明显：当同一需求第二次调整，团队可以顺着关联关系快速定位受影响的用例和此前的缺陷记录，而不必重新通读整个用例库。
评审记录、证据与负责人如何留痕
每项检查都要有证据和责任人，评审结论才能被复核。证据形式统一为四类：评审记录、用例版本、变更单链接、遗留问题清单。口头确认不算证据，需要落到上述任一载体中。
| 环节 | 责任人 | 留痕内容 |
|---|---|---|
| 作者自检 | 用例作者 | 按清单逐项自查的结果，附用例版本与变更单链接 |
| 评审确认 | 各评审人 | 对本人负责的检查项逐条确认，异议写入评审记录 |
| 结论汇总 | 测试负责人 | 汇总检查结果，给出结论并签字 |
| 遗留项登记 | 测试负责人指派 | 遗留问题清单，含负责人与期限 |
评审结论分三级：通过，表示全部检查项有证据且阻断项为零；有条件通过，表示仅存在非阻断项，遗留项已指派负责人和期限；退回修改，表示存在阻断项，需修改后重新评审。三级结论都要写入评审记录，并注明对应的用例版本，避免后续执行时用错版本。
阻断项与评审完成条件
阻断项是必须清零才能结束评审的问题。以下四类属于阻断项：变更点遗漏，即变更单中的影响点既无用例也无“不需覆盖”结论；预期结果缺失或无法判定；关键场景无对应用例，尤其是变更直接影响的正常主流程；遗留问题未指派负责人。出现任一项，评审结论只能是退回修改。
非阻断项包括描述措辞不统一、格式不规范、步骤表述可优化等，可在后续修订中处理，不阻塞评审通过，但需登记为遗留项。
| 判定维度 | 完成条件 |
|---|---|
| 阻断项 | 清单为空，或每项都有闭环记录（已修复并复核，或有明确的不覆盖结论） |
| 遗留项 | 每项有负责人和期限，登记在遗留问题清单中 |
| 评审结论 | 已记录结论级别、评审人、日期和对应用例版本 |
完成判定建议由测试负责人统一执行，而不是由作者自行宣布通过。这样阻断项的清零有独立确认，评审记录也具备可审计性。
把清单落到协作工具中的评审流程
清单条目多、参与角色多，靠线下表格传递容易丢失版本和责任人。把评审流程承载到工作项与文档状态上，可以让每个检查结果都有归属。以ONES为例，可以按下面的流程组织：
- 变更单作为评审输入，关联到受影响的用例工作项，形成“变更—用例”的对应关系。
- 用例作者完成修改后提交评审，用例工作项进入待评审状态，评审人按检查项逐条确认。
- 评审结论写入评审记录，与用例版本一并留存；有条件通过的遗留项转为待办工作项，指派负责人和期限。
- 阻断项清零后，用例工作项状态流转为可执行，进入回归执行排期。
这条流程的关键在于状态与证据同步：用例状态反映评审进度，关联关系和评审记录提供追溯依据，遗留项作为独立工作项跟踪到关闭。团队据此可以在变更频繁的阶段快速回答“哪些用例还没评审完、哪些遗留项还没关闭”。
常见问题
需求变更很小，比如只改了提示文案，还需要走完整评审吗？
可以简化，但“不需覆盖”的结论仍要留档。变更仅涉及日志文案、提示语等不影响可观测行为的内容时，由用例作者在变更单上写明不覆盖的理由，需求代表确认后记录即可，不必逐条走完整清单。判断依据是变更是否改变可观测行为、数据状态或业务规则：只要涉及其中任一项，就回到变更覆盖检查，按清单核对。
用例评审和有产品、开发参加的评审会是什么关系？
两者可以合并，也可以分开，取决于变更的影响面。影响面大、涉及接口或数据规则调整时，建议需求代表和开发代表参加评审，现场确认变更点映射和回归范围；影响面小、仅涉及用例表述修订时，由测试负责人和用例作者完成评审即可。无论哪种形式，检查项、通过标准、证据和结论记录保持一致，参与角色按实际需要裁剪。
评审时发现用例本身没问题，但需求描述有歧义，怎么处理？
把歧义作为遗留项登记，指派给需求代表澄清，并注明期限。在澄清之前，相关用例的预期结果无法判定，应按阻断项处理，评审结论为退回修改或有条件通过，不能默认按作者理解通过。澄清结论回填到变更单和用例后，再复核对应检查项。
有条件通过之后，遗留项由谁跟踪关闭？
由测试负责人指派负责人和期限，遗留项作为独立待办跟踪到关闭。关闭时需回填处理结果，并确认对应用例版本已更新。测试负责人在遗留项全部关闭后，把评审结论从有条件通过更新为通过，避免遗留项长期停留在“已通过”状态之外无人跟进。
同一需求第二次变更时，评审要重新走一遍清单吗？
要重新核对，但可以借助已有的关联关系缩小范围。顺着用例与需求、变更单的关联，以及历史缺陷记录，先定位受本次变更影响的用例，再按变更覆盖、设计质量、可执行性与可追溯的顺序核对受影响部分。未受影响的用例不必重复评审，但需在评审记录中说明本次核对的范围和依据。
