AI测试用例遗漏往往不是某一次生成“没写好”这么简单，而是需求输入、生成规则、评审把关和回归维护中某一处失效。要处理它，先把遗漏转成可核对的事实，再按环节验证原因，针对确认的原因补用例、补规则、补评审，最后用回放验证效果并固化预防机制。
要点总览（TL;DR）
- 先把“AI测试用例遗漏”拆成完全未生成、生成但未覆盖关键分支、生成后被误删或未同步三类症状，用缺陷倒查形成遗漏样本清单，记录需求条目、缺陷来源、模块分布和发生时间。
- 原因排查按输入、生成、评审、维护四个环节建立假设，每类假设配一条可核对的证据，把结论标注为已确认或待验证，避免把猜测当成定论。
- 补漏按已确认原因分别执行：输入缺失补齐需求与验收标准后重新生成；生成覆盖不足补充边界、异常、组合规则；评审失效增加覆盖点核对项；维护滞后做变更影响分析并标记失效用例。
- 批量修改或删除用例前先备份或保留版本，明确回退方式，先在小范围验证批量规则再全量执行。
- 用历史遗漏缺陷和已知缺陷做回放验证，观察遗漏缺陷数、覆盖点数量、评审拦截数，把有效规则写入常规生成与评审流程，并定期抽样复核。
先界定遗漏的范围与症状
发现遗漏后，第一步是停止笼统讨论“AI漏了”，把问题落到具体条目上。建议从缺陷库或测试记录中倒查：哪些已上线或已发现的缺陷，对应的测试用例本应存在却没有被执行或根本没有生成。以这批缺陷为起点，反向定位需求条目、模块和版本，形成一份遗漏样本清单。
症状需要分类，因为不同症状指向的原因不同：
- 完全未生成：对应需求条目在用例集中找不到任何相关用例，通常指向输入缺失或生成范围未覆盖。
- 生成但未覆盖关键分支：有用例，但边界值、异常流、权限组合或状态迁移没有对应条目，通常指向生成规则或提示约束不足。
- 生成后被误删或未同步：用例曾经存在，因需求变更、批量清理或版本切换而消失或失效，通常指向维护与变更同步环节。
清单中至少记录四项信息：需求条目编号、缺陷来源（线上问题、验收发现、回归发现）、模块分布、发生时间。时间维度能帮助判断遗漏是否集中在某次需求变更或某轮批量生成之后。模块分布则能看出是否集中在权限、支付、状态机等复杂逻辑区域。
同时要确定本次处置边界。只修复已发现的这几条遗漏，还是顺带排查同类风险？如果遗漏集中在同一模块或同一类需求，建议把边界扩大到该模块的同类需求；如果遗漏分散且原因各异，先处理已确认条目，把系统性排查放到验证阶段。边界写清楚，后续补漏才不会无限扩张或草草收尾。
按四个环节排查遗漏原因
原因排查的关键是“假设—证据”配对：每个猜测都要找到能证实或排除它的材料，避免把第一个看起来合理的解释当成结论。可以按输入、生成、评审、维护四个环节逐一验证。
| 环节 | 原因假设 | 验证证据 |
|---|---|---|
| 输入 | 需求描述、验收标准、历史缺陷未完整提供给生成过程 | 调出生成时使用的需求版本，比对验收标准字段是否为空、历史缺陷是否关联到该需求 |
| 生成 | 提示或规则未覆盖边界值、异常流、权限与状态组合 | 抽取同批次生成用例，统计边界与异常场景占比；对照遗漏缺陷的场景类型 |
| 评审 | 生成用例未经人工评审，或评审只核对数量未核对覆盖点 | 查看评审记录中的检查项与意见内容，确认是否有人对覆盖点逐条确认 |
| 维护 | 需求变更后用例未同步，回归集长期未刷新 | 比对需求变更记录与用例更新时间，找出变更后未动过的用例 |
输入环节的验证最直接：如果遗漏需求在生成时验收标准为空，或历史缺陷没有挂到需求上，那么生成过程缺少判断“什么算测到位”的依据，遗漏就有了合理解释。这类原因可以通过补齐字段后重新生成来验证，若新生成结果覆盖了原遗漏点，基本可以确认。
生成环节要看规则而非单条结果。抽取同一批次的多条用例，统计边界值、异常流、权限组合的出现比例。如果整批用例都偏向正常流程，说明规则层面缺少对异常场景的要求，而不是某一条偶然漏掉。此时应排除“输入完整但规则不足”与“输入本身缺失”两种情况，再决定补哪一头。
评审环节的证据在评审记录里。若评审意见只有“数量够”“格式没问题”，没有针对覆盖点的确认，那么评审实际上没有起到拦截作用。可以回看最近几轮评审，统计评审提出的覆盖类问题数量，数量长期为零通常说明评审卡点形同虚设。
维护环节的证据来自变更记录与用例更新时间的比对。需求在某个版本调整了状态流转或权限规则，而相关用例的最后更新时间早于该变更，这类用例即使存在也可能已经失效。把这类条目单独列出，与“从未生成”区分开，处置方式不同。
排查完成后，把每个原因标注为“已确认”或“待验证”。已确认指有直接证据支撑；待验证指证据不足但可能性较高，需要在补漏后通过回放观察。这个区分能防止在证据不足时大改规则，造成新的覆盖偏差。
按确认原因执行补漏处置
处置动作与原因一一对应，不做“全面重写用例”这类大范围操作。每类动作都明确责任人、完成标志和风险控制点。
输入缺失：补齐需求描述与验收标准字段，把相关历史缺陷关联到需求，然后针对该需求重新生成用例。重新生成时保留原有用例，新增结果与原用例并列比对，确认新增部分确实覆盖了遗漏点后再决定是否合并。责任人通常是需求负责人与测试负责人共同确认字段完整性。
生成覆盖不足：在生成规则或提示中补充边界值、异常流、权限与状态组合的要求，先对一小批需求试跑，抽样复核新增用例是否命中预期场景，确认有效后再扩大范围。完成标志是抽样中边界与异常场景占比达到团队约定水平，且原遗漏点被覆盖。
评审失效：在用例评审中增加覆盖点核对项，明确每条需求的关键分支、异常路径、权限组合是否都有对应用例，并指定核对责任人。评审记录中要能看到逐项确认的结果，而不只是通过与否。完成标志是下一轮评审中覆盖类意见有实际产出。
维护滞后：对发生变更的需求做用例影响分析，找出受影响的用例并标记为待更新或失效，避免它们继续留在回归集中造成“已覆盖”的假象。完成标志是变更需求对应的用例状态与当前需求版本一致。
批量修改或删除用例前，先备份或保留版本，明确回退方式。批量操作的风险在于一次误删可能同时抹掉有效用例，而遗漏问题恰恰需要靠现有用例做比对基线。建议先在副本或小范围上验证批量规则，确认结果符合预期后再全量执行；一旦发现覆盖点减少超出预期，立即回退并重新评估规则。
在团队使用 ONES 承载需求、用例与缺陷的情况下，遗漏样本清单可以围绕需求工作项、测试用例和缺陷记录建立关联，使“哪条需求、哪条用例、哪个缺陷”在同一处可查。ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等工作上下文，并基于相关项目数据回答问题、执行后续操作。补漏过程中，测试人员可以让助手协助定位相关需求与缺陷记录、汇总遗漏分布；在缺陷处置上，助手可创建缺陷、更新缺陷状态并通知项目负责人，实际可用性取决于团队在 ONES 中的配置与权限。这样补漏动作产生的记录留在同一套研发管理数据中，后续验证时可以直接回溯。
验证补漏效果并防止复发
补漏是否有效，不能靠“感觉这次生成得比较全”来判断。用一批已知答案的样本做回放是最直接的验证方式：选取历史遗漏缺陷和已知缺陷，检查新用例集能否覆盖这些缺陷对应的场景。回放通过的标准是每个样本都能找到至少一条可执行的用例，且用例描述能对应到缺陷的触发条件。
回放之外，设定观察期指标，用数据确认遗漏在收敛：
- 遗漏缺陷数：观察期内由测试遗漏导致的缺陷数量，与补漏前同期对比。
- 用例覆盖点数量：按需求统计关键分支、异常路径、权限组合的覆盖条目数，确认补漏后确实增加而非仅替换。
- 评审拦截数：评审中提出的覆盖类问题数量，数量上升通常说明评审卡点开始起作用。
观察期长度按迭代节奏确定，至少覆盖一个完整迭代，让变更、生成、评审、回归各环节都经历一次。指标不必追求全部向好，重点看遗漏缺陷数是否下降、评审拦截数是否从零起步。
验证通过后，把有效做法写入常规流程：补齐的需求字段作为生成前的检查项，补充的边界与异常规则纳入生成模板，覆盖点核对项固定进评审清单，变更影响分析作为需求变更后的固定动作。规则写入流程后仍需定期抽样复核生成质量，因为需求形态和业务复杂度会变化，长期不更新的规则会再次产生覆盖盲区。抽样频率可按迭代安排，每次抽取若干条新生成用例，核对覆盖点是否与当前需求一致，发现偏差及时调整规则。
复发预防的核心是让遗漏可被发现：遗漏样本清单持续维护，每次发现新遗漏都回填原因分类，定期统计哪类原因反复出现。反复出现的原因说明对应环节的规则没有真正落地，需要回到处置步骤重新加固，而不是重复补几条用例了事。
常见问题
遗漏样本很少，只有一两条，还需要走完整的四环节排查吗？
样本少时不必对四个环节逐一取证，但建议至少确认两件事：这条遗漏属于哪类症状，以及生成时对应的需求字段是否完整。如果需求描述和验收标准齐全、同批次用例也覆盖了类似场景，那么更可能是单条偶然遗漏，补上用例并在下一轮抽样中留意即可。如果需求字段本身缺失，或者同批次用例普遍缺少异常场景，即使只发现一条，也值得按生成或输入环节继续查，因为这类原因通常不会只影响一条需求。
补漏时重新生成用例，原有用例要保留还是直接替换？
建议保留原有用例，把新生成结果并列比对后再决定合并。原有用例是判断“补漏是否真的补上了”的基线，直接替换会失去对照，也无法确认新增部分是否覆盖了原遗漏点、是否引入了重复或冲突。确认新增用例命中遗漏场景、且与原用例没有实质重复后，再按团队规范合并或归档旧版本。若团队用例库支持版本记录，保留历史版本更便于后续回溯。
评审环节已经有人看用例，为什么还会漏？
有人评审和评审能拦住遗漏是两件事。常见情况是评审只核对了用例数量、格式或标题，没有逐条确认关键分支、异常路径和权限组合是否有对应用例。可以回看最近几轮评审记录：如果覆盖类意见长期为零，说明评审卡点没有真正起作用。处置方式是在评审清单中固定覆盖点核对项，并指定核对责任人，让评审记录里能看到逐项确认结果，而不只是通过与否的结论。
需求变更频繁时，用例维护总是滞后，有什么可操作的做法？
把用例影响分析固定为需求变更后的动作：需求状态流转、权限规则或字段调整后，找出受影响的用例，标记为待更新或失效，避免它们继续留在回归集中造成“已覆盖”的假象。完成标志是变更需求对应的用例状态与当前需求版本一致。若变更量大，可以按模块分批处理，优先处理核心链路和高频缺陷模块，其余模块在下一个迭代内补齐，避免一次性全量刷新导致用例质量下降。
回放验证要准备多少样本才算够？
没有统一数量标准，关键是样本要覆盖本次确认的各类原因。建议至少包含：本次发现的全部遗漏缺陷、同模块的历史已知缺陷、以及少量正常流程缺陷作为对照。回放通过的标准是每个样本都能找到至少一条可执行用例，且用例描述能对应到缺陷的触发条件。如果样本只覆盖单一场景类型，回放通过也不能说明其他环节的补漏有效，需要按原因分类分别取样。
