测试用例评审清单围绕“用例能否被独立执行、能否被验证、能否被追溯”组织，通常包含五类信息：基本信息（用例编号、标题、关联需求与模块）、前置条件与环境、步骤与预期结果、数据与边界覆盖、评审结论与责任人。清单在用例初稿完成、提测前和需求变更后使用，每项都配可判断的通过标准、证据和负责人，并标出阻断项。
要点总览（TL;DR）
- 测试用例评审清单通常包含五类信息：基本信息、前置条件与环境、步骤与预期结果、数据与边界覆盖、评审结论与责任人。
- 清单在用例初稿完成、提测前和需求变更后使用，参与角色包括用例作者、测试评审人、开发评审人、产品评审人和记录人。
- 每项检查都要配可判断的通过标准、证据和负责人；步骤无法独立执行、预期结果不可判断、需求无法追溯属于阻断项。
- 评审关闭需同时满足：阻断项清零、每条不通过项有负责人和复评时点、评审记录已归档可检索。
- 需求变更后的增量评审只检查受影响用例，并在记录中注明本次评审范围。
谁在什么时点使用这份评审清单
评审清单的使用对象和时点需要在评审启动前明确，否则容易出现用例尚未成型就开会讨论、或者评审结束后无人对整改负责的情况。参与角色通常包括用例作者、测试评审人、开发评审人、产品评审人和记录人。用例作者负责提交初稿并说明设计思路，测试评审人关注步骤与预期结果的可执行性，开发评审人关注技术实现路径与异常场景，产品评审人关注需求与验收标准的覆盖，记录人负责逐项登记结论、证据和整改项。
评审时点建议分三个触发条件：用例初稿完成时做首次评审，提测前做覆盖与追溯复核，需求变更后对受影响用例做增量评审。评审启动的输入前提是需求文档或用户故事、验收标准、原型或接口说明已经具备；缺少验收标准时，用例的预期结果往往无法判断对错，此时应先补齐输入再评审。
评审形式按用例数量选择：单模块10至20条用例可采用1小时左右的会议评审，跨模块或高风险需求可拆成两轮，第一轮查内容质量，第二轮查覆盖与追溯。评审前2至3天把用例和清单发给参与人预读，会上只讨论标记出的疑点，能显著减少逐条朗读的时间。
| 角色 | 使用时点 | 需要先准备的输入 | 在清单中的职责 |
|---|---|---|---|
| 用例作者 | 初稿完成、需求变更后 | 需求或用户故事、验收标准、用例初稿 | 按准备检查项自检，提交评审 |
| 测试评审人 | 首次评审、提测前复核 | 用例初稿、历史缺陷记录 | 检查步骤、预期结果、数据与边界 |
| 开发评审人 | 首次评审 | 接口说明、技术设计 | 检查异常场景与技术可行性 |
| 产品评审人 | 首次评审、需求变更后 | 需求文档、验收标准、原型 | 确认需求覆盖与验收标准对应关系 |
| 记录人 | 每次评审 | 评审清单、用例编号清单 | 登记结论、证据、整改负责人与复评时点 |
评审前的准备检查项
准备检查的目的是在正式评审前筛掉明显不完整的用例，把会议时间留给有争议的设计问题。准备检查由用例作者在提交评审前完成自检，记录人抽查确认，未通过准备检查的用例不进入会议评审。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断标记 |
|---|---|---|---|---|
| 关联需求或验收标准 | 每条用例至少关联一个需求条目或验收标准编号，关联关系可在用例管理工具中查看 | 用例与需求的关联记录 | 用例作者 | 阻断 |
| 编号与标题唯一 | 编号在用例库内不重复，标题能概括“场景+动作+对象”，可通过编号或关键词检索到 | 用例库检索结果 | 用例作者 | 阻断 |
| 前置条件与测试数据来源 | 前置条件写明账号、权限、数据状态；测试数据写明来源（已有数据、造数脚本、手工构造） | 用例正文中的前置条件与数据字段 | 用例作者 | 阻断 |
| 场景类型覆盖 | 同一需求下正常、异常、边界三类场景均有对应用例，或未覆盖类型已记录原因 | 场景类型标注或覆盖说明 | 测试评审人 | 建议 |
| 状态与版本标注 | 用例状态（草稿、待评审、已评审）和适用版本已填写 | 用例属性字段 | 用例作者 | 建议 |
准备检查中“关联需求”和“编号唯一”列为阻断项，原因是这两项缺失会让后续的覆盖追溯和整改跟踪无法定位到具体用例。场景类型覆盖和状态标注列为建议项，可以在评审中补充，不阻塞会议进行。
用例内容质量的分项检查项
内容质量检查是清单的核心，逐条判断单条用例能否被第三方独立执行、执行结果能否被客观判断。以下检查项按单条用例逐项核对，任一项不通过即记录到评审记录表。
| 检查项 | 通过标准 | 不通过示例 | 阻断标记 |
|---|---|---|---|
| 步骤可独立执行 | 每一步写明动作和操作对象，未参与设计的测试人员按步骤能完成操作，无需口头补充 | “验证登录功能正常”——未说明输入什么账号、在哪个入口操作 | 阻断 |
| 预期结果可观察 | 预期结果描述页面元素、提示文案、数据状态或接口返回，能判断对错 | “页面显示正常”——无法判断“正常”指什么 | 阻断 |
| 测试数据具体 | 数据写到具体值或给出生成规则，如“手机号13800000000，未注册状态” | “输入合法手机号”——未给出具体值或规则 | 阻断 |
| 前置条件与环境完整 | 写明账号权限、依赖服务、浏览器或设备版本等环境信息 | 只写“已登录”，未说明账号角色与权限范围 | 阻断 |
| 异常与边界场景 | 同一功能点有异常输入、边界值的对应用例，或说明不适用的理由 | 只覆盖正常流程，无空值、超长、越权等场景 | 建议 |
| 用例间无重复冲突 | 相同场景不重复建用例；同一操作在不同用例中的预期结果一致 | 两条用例步骤相同但预期结果互相矛盾 | 建议 |
步骤和预期结果两项列为阻断项，因为缺失时用例无法执行，评审通过也没有意义。异常边界覆盖和重复冲突列为建议项，可以在复评前补充或合并，不阻塞单条用例进入执行队列。判断“步骤可独立执行”的一个实用方法，是让未参与设计的测试人员按用例操作一遍，遇到需要询问的地方即记为不通过。
覆盖与追溯检查项
覆盖与追溯从用例集合层面检查，回答“需求是否都有用例对应、高风险部分是否覆盖更严”的问题。这项检查在提测前复核时执行，由测试评审人和产品评审人共同确认。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断标记 |
|---|---|---|---|---|
| 需求与用例双向追溯 | 每条需求能查到对应用例，每条用例能回溯到需求条目；映射表无孤立项 | 需求—用例映射表或工具中的关联视图 | 测试评审人 | 阻断 |
| 验收标准逐条对应 | 验收标准中的每个条目至少有一条用例验证，逐条核对无遗漏 | 验收标准与用例对照表 | 产品评审人 | 阻断 |
| 高风险模块加严覆盖 | 涉及资金、权限、核心链路等高风险模块的用例包含异常与边界场景，覆盖密度高于普通模块 | 风险等级标注与用例分布统计 | 测试评审人 | 建议 |
| 未覆盖项记录 | 未覆盖的需求或场景写明原因（如本期不实现、依赖外部系统）和处理方式（延后、手工验证） | 未覆盖项清单 | 用例作者 | 建议 |
核对需求—用例映射时，可以按需求条目逐条检索关联用例，再反向抽查用例的需求字段是否为空。映射表中出现“有需求无用例”或“有用例无需求”的孤立项时，前者通常意味着覆盖缺口，后者可能是需求变更后未同步更新，两种情况都需要在评审记录中登记处理意见。未覆盖项即使有合理原因，也应留下书面记录，避免提测后被追问时无法说明。
评审结论、证据与负责人怎么记
评审结果需要落到可复核的记录上，否则“会上说通过了”无法支撑后续整改和复评。记录表按用例编号逐条登记，每条不通过项都要有证据、整改负责人和复评时点。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 用例编号 | 与用例库编号一致 | TC-LOGIN-012 |
| 检查项 | 引用清单中的检查项名称 | 预期结果可观察 |
| 结论 | 通过、有条件通过、退回修改三选一 | 退回修改 |
| 问题描述 | 写明具体缺什么、错在哪 | 预期结果写“登录成功”，未说明跳转页面与提示文案 |
| 证据 | 截图、用例链接或文档位置 | 用例链接及评审会截图 |
| 整改负责人 | 具体到人，不写团队名 | 用例作者张三 |
| 复评时点 | 日期或触发条件 | 提测前3个工作日 |
结论取值中，“有条件通过”适用于建议项未完成但阻断项已清零的情况，需在记录中写明遗留项和完成期限；“退回修改”适用于存在阻断项的情况，整改完成后重新提交评审。评审记录归档到团队约定的位置，例如测试文档库或项目管理工具中的评审工作项，保证后续复评和审计时能按用例编号检索到历史结论。
当团队在ONES中管理测试用例时，用例可与需求、任务关联，评审记录中的整改项可以作为工作项指派给负责人并跟踪状态，复评时按用例编号回到原记录核对。ONES TestCase支持自定义用例属性，团队可以把评审状态、评审结论作为属性字段维护，并通过用例库筛选快速找出待复评的用例；用例按模块树状组织，便于按模块分批评审。具体字段配置以实际使用版本为准。
阻断项与评审完成条件
阻断项指不整改就无法保证用例可执行或可追溯的问题，必须在评审关闭前清零；建议项指影响用例质量但不阻塞执行的问题，可以约定在复评或后续迭代中优化。区分原则是：问题导致用例无法执行、无法判断对错、无法回溯需求，即为阻断项；问题只影响表述、排版或覆盖密度，即为建议项。
| 类别 | 典型问题 | 处理要求 |
|---|---|---|
| 阻断项 | 预期结果缺失或不可判断；用例无法关联到需求；关键场景（核心链路、高风险模块）无用例；步骤缺少操作对象导致无法执行 | 整改完成并复评通过后才能关闭评审 |
| 建议项 | 标题表述不够精炼；异常场景覆盖偏少；用例间存在轻度重复；状态字段未及时更新 | 记录遗留项和完成期限，可在复评或下个迭代处理 |
评审关闭的判断条件建议写成三条同时满足：阻断项数量为零；每条不通过项都有负责人和复评时点；评审记录已归档并可由参与人检索。复评通过的条件是对原阻断项逐条核对整改结果，而不是重新通读全部用例。关闭方式可以采用记录人更新评审状态并由测试负责人确认，或在评审工作项上完成状态流转，具体形式按团队工具约定执行。
需求变更后触发的增量评审，只需对受影响用例执行内容质量与追溯检查，未受影响部分沿用上次结论，并在记录中注明本次评审范围，避免重复劳动。
常见问题
用例数量很少时，还需要走完整的评审清单吗？
可以按比例裁剪，但阻断项不能省。单模块只有几条用例时，准备检查可以由作者自检完成，会议评审改为书面评审：把用例和清单发给测试、产品评审人，限时回复意见，记录人汇总。步骤可独立执行、预期结果可观察、需求可追溯这几项阻断检查仍需逐条确认，因为它们决定用例能否被他人执行和复核。异常边界覆盖、标题表述等建议项可以合并到后续迭代处理。
评审会上意见不一致、无法当场判断通过与否时怎么处理？
把分歧登记为待定项，写明双方观点、需要补充的信息和裁决人，不强行在会上定结论。常见分歧集中在预期结果是否符合产品设计、异常场景是否属于本期范围，这类问题通常需要产品评审人或需求负责人确认。待定项在记录表中单独标记，约定回复时限；涉及阻断项的待定项未关闭前，评审状态保持未通过。复评时只核对待定项的处理结果，不重新通读全部用例。
需求变更后，旧用例的评审结论还有效吗？
未受变更影响的用例沿用上次结论，受影响用例需要重新执行内容质量与追溯检查。操作上先按需求—用例映射找出关联到变更需求的用例，再判断变更是否影响步骤、预期结果或测试数据：只改文案不影响判断逻辑的，可做书面确认；涉及流程、字段或验收标准变化的，按阻断项标准重新核对。增量评审的范围和结论要写进记录，便于后续追溯哪一版用例对应哪一版需求。
评审记录放在文档里还是放到测试管理工具里更合适？
取决于团队后续要靠记录做什么。如果主要用于留档和审计，文档库按项目、版本归档即可；如果整改项需要指派到人、跟踪状态并在复评时按用例编号回查，放在测试管理工具里更顺畅。以 ONES 为例，用例可与需求、任务关联，评审中的整改项可作为工作项指派给负责人并跟踪状态，团队也可以把评审状态、评审结论作为用例属性字段维护，通过用例库筛选找出待复评的用例。具体字段配置以实际使用版本为准。
阻断项整改完成后，复评需要全体评审人再参加一次吗？
通常不需要。复评由记录人和对应检查项的评审人核对整改结果即可，例如预期结果缺失由测试评审人确认，需求追溯缺口由产品评审人确认。复评时逐条对照原阻断项，确认整改后的内容满足通过标准，并在记录中更新结论和日期。只有整改引入了新的设计变更、影响其他用例时，才需要扩大复评范围。测试负责人负责最终确认评审关闭。
