AI测试用例遗漏通常不是单点失误，而是输入、生成、评审、执行四段链路中某一环断了。先界定遗漏出现在哪个需求、哪个版本、哪类场景，再逐段验证原因，才能避免把“模型没生成”和“生成了但没登记”混为一谈。本文给出一套从症状界定到补测处置、再到回归验证的操作路径，并在需要留存需求、用例与缺陷流转记录时，说明ONES可以承接的管理动作。
要点总览（TL;DR）
- 先界定遗漏的症状与范围：区分“AI没生成”“评审没保留”“生成了但没登记”三类情况，再决定排查入口。
- 按输入、生成、评审、执行四段逐一验证原因假设，每段都要拿到判定证据，没有证据的假设保留为待验证项。
- 补测按资金、权限、数据一致性、异常恢复优先，以需求验收标准逐条对照补齐，已上线版本先评估风险再决定验证或灰度观察。
- 用同一批需求重新走生成与评审，比对覆盖矩阵确认补齐，并观察需求覆盖率、评审补充用例数、执行阶段未登记用例数三项指标。
- 把遗漏原因、处置动作和验证结果归档到用例库与评审规则，复发时按环节对应到具体责任角色。
遗漏出现在哪一段：先界定症状与影响范围
发现遗漏后，第一步是把它写成可观察的事实，而不是直接判断“AI不行”或“评审不认真”。同一个“漏了用例”的说法，可能对应完全不同的处理动作：需求点根本没有对应用例，边界值和异常路径缺失，评审后新增的场景没有补进用例库，或者执行阶段才发现有用例没登记。症状不同，后续排查的入口也不同。
界定范围时，建议围绕四个问题记录：涉及哪些需求和版本，影响哪些模块，遗漏用例是否已经被执行，是否已经产生线上缺陷或用户反馈。如果遗漏场景已经执行过且没有发现问题，风险等级与“该场景从未被验证”不同；如果已经产生线上缺陷，则需要把缺陷现象与缺失用例对应起来，作为后续补测的依据。
还需要区分两类遗漏。一类是AI草拟环节就没有产出对应场景，表现为生成结果中找不到该需求点或异常路径；另一类是AI已经生成，但人工评审没有保留、或者执行登记时没有关联到需求，导致在覆盖率统计上表现为遗漏。前者要查输入和生成约束，后者要查评审记录和用例登记流程。把这两类混在一起，容易在错误环节反复调整。
可以用一张范围界定表把信息固定下来，作为后续排查和复盘的基础：
| 需求/版本 | 模块 | 场景类型 | 发现时点 | 是否已执行 | 是否已产生缺陷 | 初步归类 |
|---|---|---|---|---|---|---|
| 示例：订单退款V2.3 | 退款审批 | 权限越权 | 评审后 | 否 | 否 | 生成缺失/评审未覆盖待验证 |
| 示例：登录V1.8 | 账号安全 | 异常锁定 | 执行阶段 | 是 | 是 | 未登记或未关联需求待验证 |
这张表的作用是防止排查时凭印象下结论。每一行在后续章节中都要能对应到具体的验证证据，而不是停留在“感觉漏了”的描述。
原因假设与排除证据：四段链路逐一验证
原因排查按“输入—生成—评审—执行”的顺序推进，每一段先提出假设，再给出验证动作和判定证据。假设只有在拿到证据后才能升级为已证实原因；没有证据的假设继续保留为待验证项，不直接写进改进结论。
输入段：生成上下文是否完整
常见假设是需求描述、验收标准或变更范围没有完整进入生成上下文。验证动作是调出当次生成所用的输入材料，逐条对照需求文档中的验收标准和本次变更点，看是否存在只给了需求标题、缺少异常条件说明、或者变更范围只覆盖主流程的情况。判定证据是输入材料与需求原文的差异清单：如果遗漏场景所需的约束条件在输入中就不存在，那么生成缺失可以归因到输入段。
生成段：输出是否被截断或过滤
第二类假设是模型已经考虑到相关场景，但输出被截断、合并去重时误删，或者模板约束过窄导致异常路径被过滤。验证动作包括回看原始生成结果是否完整、检查去重规则是否把语义相近但条件不同的用例合并、核对模板是否只允许主流程字段。判定证据是原始输出中能否找到对应场景的痕迹：如果原始结果里有、最终清单里没有，问题在生成后的处理环节；如果原始结果里也没有，再回到输入段确认上下文是否足够。
评审段：人工兜底是否覆盖高风险场景
第三类假设是评审只核对了格式、数量和主流程，没有针对高风险场景做逐项确认。验证动作是抽查评审记录，看评审意见是否涉及权限、资金、数据一致性、异常恢复等类别，是否存在“通过”但无具体核对项的情况。判定证据是评审清单与实际高风险场景的对照结果：如果评审环节没有对应的兜底检查项，那么即使生成结果中有相关用例，也可能在评审中被忽略或删减。
执行段：用例是否已生成但未登记
第四类假设是用例已经存在，但没有登记到用例库、没有关联需求，导致覆盖率统计显示遗漏。验证动作是在执行记录、测试任务和用例库中按需求编号和场景关键词检索，确认是否存在未关联的用例条目。判定证据是检索结果：能找到条目但关联缺失，属于登记和关联问题；完全找不到条目，才回到前三段继续排查。
把上述内容整理成对照表，可以让排查过程有据可查：
| 链路段 | 原因假设 | 验证动作 | 判定证据 | 排查顺序 |
|---|---|---|---|---|
| 输入 | 需求与验收标准未完整进入上下文 | 对照输入材料与需求原文 | 差异清单中存在缺失约束 | 1 |
| 生成 | 输出截断、去重误删、模板过窄 | 回看原始生成结果与处理规则 | 原始结果有、最终清单无 | 2 |
| 评审 | 评审只核格式数量，缺高风险兜底 | 抽查评审记录与检查项 | 评审清单缺对应场景类别 | 3 |
| 执行 | 用例已生成但未登记或未关联需求 | 按需求编号和关键词检索 | 存在条目但关联缺失 | 4 |
排查顺序建议从输入段开始，因为输入缺失会同时影响生成和评审的判断；执行段放在最后，用于区分“真遗漏”和“统计口径造成的遗漏”。每一段得出结论后，记录已证实原因和排除依据，避免后续处置时重复排查。
按定位结果处置：补齐遗漏用例并控制风险
定位完成后，处置分两条线并行：一条是补齐遗漏场景、控制当前版本风险；另一条是调整生成与评审规则，减少同类遗漏再次发生。两条线都要有明确的完成标志和停止点。
补测优先级按风险从高到低排列。资金相关场景（金额计算、退款、对账）、权限相关场景（越权访问、角色边界）、数据一致性场景（多端同步、状态流转）、异常恢复场景（超时、重试、回滚）应优先补齐。这些场景一旦遗漏，线上影响的扩散速度和修复成本都更高。优先级较低的展示类、文案类场景可以排在后面，但仍需登记，避免再次从统计中消失。
补齐方式以需求验收标准为基准逐条对照，而不是凭经验补充。具体做法是：把需求中的每个验收条件拆成可验证的场景，标注正常路径、边界值和异常路径，再与现有用例逐条比对，缺失的补入用例库并关联需求编号。对于已经上线的版本，先评估遗漏场景是否可能触发线上问题：如果涉及资金、权限或数据一致性，安排针对性的验证或灰度观察，明确观察窗口和停止条件；如果确认影响范围有限，记录评估结论后进入常规补测。
规则调整针对已证实的原因进行。输入段的问题，补充需求上下文材料，确保验收标准和变更范围随需求一起进入生成环节；生成段的问题，放宽过窄的模板约束，检查去重规则是否按条件区分；评审段的问题，增加高风险场景的人工兜底清单，把权限、资金、数据一致性、异常恢复列为必查项；执行段的问题，明确用例登记和需求关联的操作要求。批量修改用例库或评审规则前，先备份或保留版本，并约定回退条件，例如新规则导致用例数量异常波动或评审通过率明显下降时，回退到上一版本再排查。
在处置过程中，需求、用例、缺陷往往分散在不同记录里。ONES可以把需求工作项、测试用例和缺陷关联到同一需求下，补测用例登记后保留与需求的关联关系，缺陷记录也能回溯到对应版本和场景。这样在补测和灰度观察阶段，团队能按需求查看覆盖情况和缺陷状态，减少“补了但没记录”的情况。这里的作用是让处置动作留下可查的状态记录，具体流程仍按团队现有的测试管理规范执行。
验证恢复与防复发：用同一批需求回归确认
补测完成后，需要验证遗漏是否真正消除。验证方式是用同一批需求重新走一遍生成与评审流程，把新产出的用例与补测后的用例库做覆盖矩阵比对，确认此前缺失的场景类型已经补齐，且没有引入重复或冲突条目。比对结果应记录到验证记录中，包含需求编号、场景类型、补齐前后覆盖情况、验证人和验证时间。
观察指标用于判断恢复是否稳定。可以关注三项：需求覆盖率是否回到约定水平，评审阶段发现并补充的用例数是否趋于正常，执行阶段新增的未登记用例数是否下降。指标的变化趋势比单次数值更有参考价值；如果某一项持续异常，说明对应环节的规则还没有真正生效，需要回到原因排查表重新确认。
防复发检查点建议固定在四个位置：需求变更时同步更新生成上下文，避免验收标准滞后；每次生成后检查上下文完整性，确认变更范围没有被截断；评审时使用高风险场景兜底清单逐项确认；遗漏事件处理完后做复盘归档，把原因、处置动作和验证结果记录到用例库或评审规则中。复盘归档的价值在于让下一次排查有历史依据，而不是每次从零开始。
如果同类遗漏再次出现，升级路径应明确：由测试负责人确认是否属于规则失效，涉及生成约束的调整由用例维护人发起，涉及评审流程的调整由评审组织者发起，涉及需求上下文缺失的反馈给需求负责人。责任角色按团队现有分工确定，关键是每次复发都能对应到具体环节和具体动作，而不是停留在“加强注意”的层面。
验证记录与防复发检查清单可以合并维护，至少包含：本次遗漏的需求与场景、已证实原因、补测完成情况、覆盖矩阵比对结果、规则调整内容、回退条件、复盘结论和下次检查时间。这份记录既是本次处置的收尾，也是后续回归验证的输入。
常见问题
AI生成的用例看起来不少，为什么覆盖率统计还是显示遗漏？
常见原因是统计口径与用例登记方式不一致。用例可能已经生成并执行，但没有关联到需求编号，覆盖率按需求维度统计时就表现为缺失。排查时先按需求编号和场景关键词在执行记录、测试任务和用例库中检索，确认是否存在未关联的条目。能找到条目但关联缺失，属于登记和关联问题；完全找不到条目，再回到输入和生成环节排查。
补测应该先补哪些场景，哪些可以往后排？
按风险从高到低排。资金相关（金额计算、退款、对账）、权限相关（越权访问、角色边界）、数据一致性（多端同步、状态流转）、异常恢复（超时、重试、回滚）应优先补齐，这些场景一旦遗漏，线上影响扩散快、修复成本高。展示类、文案类场景可以排在后面，但仍需登记入库并关联需求，避免再次从统计中消失。
遗漏场景已经上线但还没出问题，需要立即回滚或热修吗？
先评估再决定，不必一律回滚。如果遗漏场景涉及资金、权限或数据一致性，安排针对性的验证或灰度观察，明确观察窗口和停止条件；如果确认影响范围有限，记录评估结论后进入常规补测。评估结论要写清判断依据，便于后续复盘时核对当时的风险判断是否合理。
调整生成模板或评审规则时，怎么控制操作风险？
批量修改用例库或评审规则前先备份或保留版本，并约定回退条件，例如新规则导致用例数量异常波动、评审通过率明显下降时，回退到上一版本再排查。规则调整应针对已证实的原因逐项进行，一次只改一类约束，便于观察改动与指标变化之间的对应关系。
同类遗漏反复出现，应该由谁牵头处理？
由测试负责人确认是否属于规则失效，再按环节分派：涉及生成约束的调整由用例维护人发起，涉及评审流程的调整由评审组织者发起，涉及需求上下文缺失的反馈给需求负责人。关键是每次复发都能对应到具体环节和具体动作，并把结论归档到用例库或评审规则中，让下一次排查有历史依据。
