AI测试用例评审的依据可以分成四层：需求与验收标准判断用例是否正确，测试设计规范与用例模板判断用例是否完整，历史缺陷与线上问题判断风险是否覆盖，评审规则与准入标准判断结论是否可追溯。本文按这四层给出取用来源、评审步骤、角色交付物和完成检查，帮助测试负责人把评审做成可复查的闭环。
要点总览（TL;DR）
- 评审依据分四层：需求与验收标准判断用例是否正确，测试设计规范与用例模板判断是否完整，历史缺陷与线上问题判断风险是否覆盖，评审规则与准入标准判断结论是否可追溯。
- 评审前先把四类依据的版本固定下来，与本轮用例清单绑定，并明确每类依据的责任人和取用方式。
- 评审按固定顺序推进：锁定范围与版本基线、需求覆盖核对、用例质量核对、风险核对、结论记录，每一步都有输入、输出和完成标志。
- 评审结论要写明通过、退回修改或待补充，并附理由、修改项、责任人和复评时间，归档后可按需求条目或用例编号追溯。
- 需求变更后先更新依据版本，再同步受影响用例；依据缺失时相关用例标为待补充并阻断进入下一环节。
评审前先固定四类依据
评审依据的作用是让每一条评审意见都能指回具体材料，而不是停留在“感觉覆盖不够”。四类依据分别回答不同问题，缺一类就会留下判断盲区：没有需求和验收标准，无法判断用例是否测对了业务规则；没有设计规范和模板，无法判断用例结构是否完整；没有历史缺陷，无法判断高风险路径是否被重点覆盖；没有评审规则，无法判断一条用例该通过还是退回。
评审开始前，应把四类依据的版本固定下来，并与本轮用例清单绑定。依据本身也要有责任人和取用方式，避免评审现场临时找材料。
| 依据类别 | 解决什么问题 | 典型来源 | 责任人 | 取用方式 |
|---|---|---|---|---|
| 需求文档与验收标准 | 用例是否覆盖真实业务规则和验收口径 | 需求条目、验收标准、业务规则说明、原型或接口约定 | 需求或产品角色 | 按需求编号逐条引用，标注版本与更新时间 |
| 测试设计规范与用例模板 | 前置条件、步骤、预期结果、测试数据是否完整可执行 | 团队测试设计规范、用例模板、命名与分级规则 | 测试负责人或测试架构角色 | 作为评审检查项，逐项对照模板字段 |
| 历史缺陷与线上问题记录 | 高风险模块和高频问题路径是否被用例覆盖 | 缺陷库、线上问题单、复盘记录、监控告警记录 | 缺陷或质量角色 | 按模块和问题类型汇总，形成风险清单 |
| 评审规则与准入标准 | 通过、退回修改、待补充的判定口径 | 团队评审制度、准入准出规则、评审记录模板 | 测试负责人 | 评审前确认判定标准，评审中统一引用 |
四类依据中，需求与验收标准是正确性来源，设计规范和模板是完整性来源，历史缺陷是风险来源，评审规则是追溯来源。取用时优先引用条目编号和版本，避免用“参考需求文档”这类无法核对的表述。
按依据逐项评审的操作步骤
依据确定后，评审按固定顺序推进：先锁定范围和基线，再做覆盖核对、质量核对、风险核对，最后记录结论。每一步都要有输入、动作、输出和完成标志，多人评审时才能保持同一口径。
第一步：确定评审范围与版本基线
输入是本轮需求条目、用例清单和版本计划。动作是把本轮要评审的用例逐条列出，标明所属需求、模块和版本，并确认需求与验收标准的版本号。输出是一份锁定版本的评审清单。完成标志是清单中的每条用例都能对应到需求条目，且没有未标明版本的依据。
第二步：需求覆盖核对
输入是需求条目、验收标准和用例清单。动作是逐条检查每个需求条目和验收标准是否至少有一条用例对应，重点看异常分支、边界条件和业务规则是否有对应用例。输出是覆盖对照表，标出未覆盖和覆盖不足的条目。完成标志是每个需求条目都有明确的覆盖结论，未覆盖项已列入待补充。
第三步：用例质量核对
输入是用例正文和用例模板。动作是检查前置条件是否可准备、操作步骤是否可执行、预期结果是否可观察、测试数据是否明确。输出是逐条用例的质量问题清单。完成标志是每条用例在模板字段上都有明确判断，问题项写清修改要求。
第四步：风险核对
输入是历史缺陷清单、线上问题记录和本轮用例分布。动作是识别高频缺陷模块和严重问题路径，检查这些位置的用例密度和场景深度是否足够。输出是高风险模块与用例覆盖的对照结果。完成标志是每个高风险模块都有对应用例，覆盖不足的位置已标注补充要求。
第五步：结论记录
输入是前四步的输出。动作是对每条用例给出通过、退回修改或待补充的结论，并写明理由和修改项。输出是评审记录和更新后的用例状态。完成标志是所有用例都有结论，退回和待补充项都有责任人和复评时间。
角色分工与各环节交付物
依据缺失往往不是没人知道要什么，而是没人负责提供。把角色、依据和交付物对应起来，评审前就能发现哪类材料还没到位。
| 角色 | 负责提供的依据 | 交付物 | 交付时点 |
|---|---|---|---|
| 需求或产品角色 | 需求条目、验收标准、业务规则说明 | 版本明确的需求与验收标准清单 | 评审前 |
| 测试设计者 | 用例正文、自检说明 | 按模板编写的用例及自检记录 | 评审前 |
| 评审人 | 评审规则与准入标准 | 逐条评审结论与修改意见 | 评审中 |
| 缺陷或质量角色 | 历史缺陷、线上问题、复盘记录 | 按模块整理的风险清单 | 评审前 |
| 记录与归档人 | 评审记录模板 | 评审结论、修改项、复评结果归档 | 评审后 |
测试设计者的自检说明应写明用例对应哪些需求条目、哪些高风险路径已覆盖、哪些场景暂未覆盖及原因。评审人依据自检说明和四类依据给出结论，减少重复沟通。记录与归档人负责把结论、修改项和复评结果放在同一处，便于后续追溯。
当团队在ONES中管理需求、用例和缺陷时，需求条目、测试用例与缺陷记录可以在同一工作项链路中关联，评审结论也能随用例状态留存。ONES Assistant可连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项和Wiki页面等工作上下文，帮助汇总需求条目、检索相关记录；涉及评审的判断仍由评审人确认，输出过程可追踪、结果可审计。
示例：一条支付用例的评审依据走查
以下为演示情景，用于说明依据如何支撑结论。假设某支付功能的需求条目写明：单笔支付金额上限为5000元，超过上限时提示“单笔金额超出限额”，且不得发起扣款。验收标准要求覆盖等于上限、超过上限和低于下限三种情况。
评审时先做覆盖核对：用例清单中有一条“支付金额超过5000元”的用例，但缺少等于上限和低于下限的用例。对照验收标准，覆盖不完整，结论应标为待补充。
再做质量核对：现有用例的前置条件写“用户已登录且有可用余额”，步骤写“输入金额6000元并提交”，预期结果写“支付失败”。预期结果没有写明具体提示文案，也没有说明是否校验未发起扣款，执行人无法判断结果是否正确。这一问题应退回修改，要求补充提示文案和扣款状态校验。
接着做风险核对：历史缺陷记录中曾出现“金额等于上限时被误判为超限”的问题，属于边界判断缺陷。本轮用例没有覆盖等于上限的场景，应在待补充项中明确增加该用例，并标注来源为历史缺陷。
最后写评审结论：该用例退回修改，理由为预期结果不可观察、边界场景缺失；修改项包括补充提示文案、增加等于上限和低于下限的用例、说明扣款状态校验方式；责任人为测试设计者，复评时间随下一轮评审安排。可迁移的判断规律是：每条结论都要能指回需求条目、模板字段或历史缺陷中的具体记录，理由和修改项分开写，便于复评时逐项确认。
评审完成检查与依据维护
评审是否完成，不能只看会议是否开完，而要检查结论是否全部落地、依据是否仍然有效。以下清单可逐项核对。
- 用例与需求条目的对应关系完整，每个需求条目和验收标准都有覆盖结论。
- 高风险模块有对应用例，风险清单中的每条记录都能找到覆盖位置或补充说明。
- 每条用例都有通过、退回修改或待补充的结论，退回和待补充项有责任人和复评时间。
- 评审记录、修改项和复评结果已归档，能够按需求条目或用例编号追溯。
- 评审所依据的需求、验收标准和缺陷清单版本已记录，后续变更可对照。
需求变更后，先更新需求与验收标准的版本，再识别受影响的用例，逐条调整覆盖关系和预期结果，并在评审记录中标注变更来源。依据缺失时，例如验收标准未明确或历史缺陷清单未提供，应将该部分用例标为待补充并阻断进入下一环节，待责任人补齐依据后再复评。依据维护的责任随角色分工固定下来，评审记录中保留每次依据版本的变化，才能让下一轮评审直接复用。
常见问题
团队规模较小、没有专职测试架构角色时，测试设计规范与用例模板这类依据由谁维护？
可以由测试负责人兼任，或由团队中经验较丰富的测试设计者牵头维护。关键是明确一个责任人，并在评审记录中写明规范与模板的版本。小团队不必追求规范文档的完备程度，先固定模板的必要字段（前置条件、步骤、预期结果、测试数据）和命名规则，随评审中反复出现的问题逐步补充。规范变更时同步通知评审人，避免同一批用例按不同口径判断。
历史缺陷记录不完整或线上问题没有系统归档，风险核对还能怎么做？
可以先用现有材料做替代：近几个版本的严重缺陷单、客户反馈记录、监控告警记录、复盘会议纪要，都能作为风险来源。把这些材料按模块和问题类型汇总成一份临时风险清单，并在评审记录中标注清单来源和覆盖范围，说明它不完整。同时把缺陷归档的缺口反馈给缺陷或质量角色，作为后续改进项。风险核对的目标是让高风险路径有对应用例，材料不完整时宁可标注待补充，也不要凭印象判断已覆盖。
评审中需求方临时变更验收标准，本轮评审结论是否要全部重做？
不必全部重做，但需要先判断影响范围。做法是：记录变更内容和新版本号，识别受影响的用例条目，只对这些条目重新做覆盖核对和结论判定，其余用例的结论保留并注明依据版本未变。如果变更涉及核心业务规则，导致原有覆盖关系失效，则把相关用例整体退回待补充。评审记录中要写明变更来源、影响条目和复评结果，便于后续追溯为什么某些结论在变更后仍然有效。
AI 辅助汇总需求条目、比对用例覆盖时，评审人应如何核查结果？
把 AI 输出当作初稿，逐条核对来源。要求输出中每条覆盖结论都能指回具体的需求条目编号和用例编号，评审人抽查关键条目，重点看异常分支、边界条件和历史缺陷对应的高风险路径是否被正确识别。涉及通过或退回的判定，由评审人依据四类依据确认，不直接采用 AI 结论。ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项和 Wiki 页面等工作上下文，帮助汇总需求条目、检索相关记录；其输出过程可追踪、结果可审计，便于评审人回溯核对。
评审通过后进入执行阶段才发现用例缺漏，应该走什么流程？
按补充评审处理，不直接在执行中临时改用例。做法是：把缺漏场景登记为待补充项，注明发现来源（执行记录、缺陷单或线上问题），由测试设计者补充用例后提交复评，复评只针对新增和修改的条目，结论记入原评审记录并标注复评轮次。如果缺漏涉及高风险路径，应同步评估已执行部分的结论是否仍然成立。这样处理能让评审记录保持完整，也便于后续统计哪类依据在评审时容易漏看。
