需求遗漏测试指需求已经进入开发或测试，却没有对应的测试用例或验证活动，缺陷直到发布后才暴露。判定时以需求条目为最小单位，逐条检查是否存在至少一条可执行验证；排查时把“测漏了”落到具体条目与用例的对应关系上，再区分需求未拆解、用例设计漏项、变更未同步、执行未覆盖四类原因，用证据逐项排除后补齐用例并建立复查机制。
要点总览（TL;DR）
- 需求遗漏测试的判定以需求条目为最小单位：每条需求至少对应一条可执行、可追溯的验证，否则记为遗漏候选。
- 遗漏原因按需求侧、设计侧、变更侧、执行侧四类假设排查，每类假设须有需求文档、用例评审记录、变更单或执行记录支撑后才能下结论。
- 处置按原因分流：需求含糊先补验收标准，设计漏项按需求条目补高风险与异常分支，变更未同步先冻结旧用例再更新，执行未覆盖补跑并留痕。
- 批量修改用例库前先备份并设停止点，四类原因并存时按批次推进，每批完成后小范围复查再进入下一批。
- 补齐后做需求与用例一一对照复查并抽样执行新增用例，在需求评审、用例评审、发布前三个时点设对照检查，把对照表纳入变更流程。
需求遗漏测试的表现与判定范围
“测漏了”是一个笼统的说法，落到诊断上需要先转成可观察的症状。常见表现有三类：需求已经通过验收，但在用例库中找不到任何与之对应的用例；有用例，但只覆盖主流程，异常分支和边界条件没有验证活动；需求发生变更后，旧用例仍在执行，新逻辑没有对应的验证。这三类表现指向不同的原因，判定时先记录症状，再进入原因排查。
判定口径建议统一为：以需求条目为最小单位，检查每条需求是否存在至少一条可执行、可追溯的验证。所谓可执行，指用例有明确的前置条件、操作步骤和预期结果；所谓可追溯，指用例与需求条目之间存在明确关联。一条需求对应多条用例是正常的，一条用例覆盖多条需求也可以接受，但每条需求都不能落空。按这个口径扫描一遍需求清单，输出的是“遗漏候选清单”，而不是最终结论——候选条目还需要在原因排查阶段确认属于哪一类遗漏。
需要划清的边界有两处。其一，本文讨论的是测试覆盖判定，即需求与验证活动之间的对应关系，不涉及插桩实现、覆盖率工具源码或代码级覆盖率统计，这些属于工程度量范畴。其二，本文不展开从需求到设计、开发、发布的全链路追溯体系建设，只聚焦“需求条目是否被验证”这一层。把范围收窄，排查才能在一到两个迭代内完成，而不是变成一次流程重构。
判定时还要注意一个容易混淆的情况：需求描述本身含糊，导致测试人员无法判断该验证什么。这类条目在扫描时会表现为“无用例”，但它的问题出在需求侧，处置方式与设计漏项完全不同。因此在输出遗漏候选清单时，建议同时标注该需求是否有明确的验收标准，为下一步的原因分流做准备。
遗漏原因假设与排除证据
遗漏候选清单出来后，不要直接下结论说“测试没写用例”。更稳妥的做法是先列出原因假设，再为每个假设找验证证据，证据不足的假设不能作为处置依据。按发生环节，可以把原因归为需求侧、设计侧、变更侧、执行侧四类，每类都有对应的证据来源。
| 原因假设 | 典型表现 | 验证证据 | 排除条件 |
|---|---|---|---|
| 需求侧：需求描述含糊、验收标准缺失 | 需求条目只有一句话描述，无验收条件；测试人员无法判断预期结果 | 需求文档原文、需求评审记录、验收标准字段 | 需求文档中有明确验收标准，且测试人员确认可据此设计用例 |
| 设计侧：用例设计漏项 | 有用例但只覆盖正向路径，等价类、边界值、异常分支缺失 | 用例评审记录、用例设计文档、需求条目与用例的对照结果 | 用例已覆盖该需求的主要分支与异常场景，遗漏属于低风险补充 |
| 变更侧：需求变更后未同步用例 | 变更单已生效，用例库中仍是对应旧逻辑的用例 | 变更单、变更评审记录、用例最后修改时间 | 变更单中明确标注“不影响测试”，或用例已在变更后更新 |
| 执行侧：用例存在但未执行或被跳过 | 用例库中有对应用例，测试计划中无执行记录或标记为跳过 | 测试计划执行记录、执行日志、跳过原因说明 | 执行记录完整，用例已执行且结果通过 |
排查时按证据强度排序，先查执行侧和变更侧，再查设计侧，最后回到需求侧。原因是执行记录和变更单通常是现成的客观数据，核对成本低；设计漏项需要逐条比对用例内容，工作量较大；需求含糊则需要回到需求文档和评审记录，涉及与产品人员的确认。先排除客观证据能覆盖的原因，可以避免在主观判断上耗费时间。
每类假设的排除都要留下记录。例如执行侧排查后确认用例确实执行过，就在遗漏候选清单中标注“已执行、结果通过”，该条目从遗漏候选中移除；如果确认用例被跳过，则记录跳过原因和跳过人，作为后续处置的输入。变更侧排查时，把变更单的生效时间与用例最后修改时间做比对，时间顺序能直接说明用例是否在变更后更新过。设计侧排查需要打开用例内容，逐条核对是否覆盖了需求中的每个可验证点，这一步建议由熟悉该模块的测试人员完成，避免只看用例标题就下判断。
需求侧的排查最容易被跳过，但它往往是批量遗漏的根源。如果多条遗漏候选都指向同一份需求文档，且这些条目普遍缺少验收标准，那么问题不在用例设计，而在需求进入测试前的准备不足。此时继续补用例，很可能是在错误理解上做批量返工。确认需求侧原因的证据是需求文档原文和评审记录：文档中是否有可验证的验收条件，评审时是否有人提出过标准不清的问题。
按原因分流的处置步骤
原因确认后，处置动作按原因分流，不同原因对应不同的补齐顺序。共同的前提是：批量修改用例库之前先做备份，并设定停止点——当补齐过程中发现新的原因类型或影响范围超出预期时，暂停批量操作，重新评估后再继续。
需求含糊导致的遗漏。先补充验收标准，再设计用例。具体做法是把遗漏候选对应的需求条目整理出来，与产品人员逐条确认预期结果、边界条件和异常处理方式，把确认结果写回需求文档的验收标准字段。验收标准明确后，再按标准设计用例。这一步的顺序不能颠倒：在需求理解未统一时批量补用例，补出来的用例可能仍然无法验证真实预期，等于把返工推迟到执行阶段。
设计漏项导致的遗漏。按需求条目逐条补用例，优先补高风险场景和异常分支。操作时以需求条目为索引，先检查该条目涉及的业务规则、输入边界和异常路径，再对照现有用例找缺口。高风险场景包括资金、权限、数据一致性等一旦出错影响较大的逻辑；异常分支包括输入非法、依赖服务不可用、并发操作等。补完后在新用例上标注来源需求条目，便于后续复查。
变更未同步导致的遗漏。先冻结旧用例版本，再按变更单更新。冻结的方式可以是将旧用例标记为“待更新”或移入历史版本，保留回退点；然后依据变更单逐条修改受影响的用例，修改时记录变更单编号。这样做的目的是在更新过程中保留可回退的状态，一旦发现变更理解有误，可以恢复到更新前的用例版本，避免新旧逻辑混在一起难以分辨。
执行未覆盖导致的遗漏。核对执行记录，确认用例是未执行还是被跳过。未执行的用例补入当前测试计划并执行，记录执行结果；被跳过的用例需要查明跳过原因，如果是环境或数据准备问题，补齐条件后重新执行，如果是判断为不必要而跳过，则要重新评估该判断是否成立。执行结果要留痕，作为覆盖恢复的证据。
处置顺序上，建议先处理变更侧和执行侧，这两类改动范围明确、见效快；再处理设计侧，按风险优先级分批补齐；最后处理需求侧，因为需求确认涉及跨角色沟通，周期较长。如果四类原因同时存在，不要一次性全量修改用例库，按批次推进，每批完成后做一次小范围复查，确认方向正确再进入下一批。
补齐后的验证与复发预防
补齐动作完成后，需要验证遗漏确实消除，而不是只确认“用例数量增加了”。验证分两步：第一步做需求条目与用例的一一对照复查，确认每条需求都能找到至少一条可执行验证，且用例内容与需求当前逻辑一致；第二步抽样执行新增用例，确认用例可运行、预期结果可判断。抽样应覆盖不同原因类型补出的用例，例如设计漏项补的异常分支用例、变更同步后更新的用例，各抽若干条实际执行一遍。
复查时点建议设三个：需求评审时，检查每条需求是否具备可验证的验收标准；用例评审时，检查用例是否覆盖需求的主要分支和异常场景；发布前，做一次需求与用例的对照检查，确认本迭代需求均有对应验证。三个时点分别对应遗漏发生的三个环节，越早发现，补齐成本越低。
复发预防的关键是把需求—用例对照表纳入变更流程。需求变更单生效时，触发关联用例的复查动作，由变更提出人或测试负责人确认受影响的用例范围并安排更新。对照表本身要随需求迭代维护，新增需求时同步登记对应用例，需求下线时同步处理关联用例，避免对照表逐渐失真。
责任与记录方面，每个复查时点明确一名负责人：需求评审时的验收标准检查由产品负责人确认，用例评审的覆盖检查由测试负责人确认，发布前的对照检查由测试负责人或质量负责人执行。检查结果以对照表或检查记录的形式留痕，记录检查时间、检查人、发现的问题和处置结果。留痕的目的不是增加文档负担，而是在下一次出现遗漏时能快速定位是哪一次检查失效。
在工具承载上，ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，用例库支持按属性筛选，便于按需求维度查找对应用例并做对照检查。用例支持从 Excel 批量导入和导出备份，批量补齐前可以先导出用例库留存回退点；用例模块支持树状结构组织，可按业务模块或需求域分层管理。需求变更触发用例复查的联动机制，资料中未提及，实际执行时仍需在变更流程中人工设置复查节点。将需求条目、用例和变更记录放在同一协作环境中，对照检查的记录和责任人可以直接挂在工作项上，减少跨工具核对的时间。
常见问题
需求已经验收通过，但事后发现没有对应用例，这种情况算需求遗漏测试吗？
算。判定口径是需求条目与验证活动的对应关系，与需求是否通过验收无关。需求已验收但用例库中找不到对应可执行验证，正是遗漏的典型表现之一。此时应先把它列入遗漏候选清单，再进入原因排查，确认属于需求未拆解、用例设计漏项、变更未同步还是执行未覆盖，而不是直接归因于测试人员。
一条用例覆盖多条需求，是否就不算遗漏？
可以接受，前提是每条需求都能通过这条用例得到可执行的验证。判定时以需求条目为索引逐条检查，而不是以用例数量衡量。如果一条用例覆盖多条需求，需要确认它对这些需求的预期结果都成立；若其中某条需求的特殊分支没有被验证，该需求仍应记为遗漏候选。
需求描述本身含糊、没有验收标准，测试人员应该先补用例还是先找产品确认？
先找产品确认，把预期结果、边界条件和异常处理方式写回验收标准，再设计用例。在需求理解未统一时批量补用例，补出来的用例可能仍无法验证真实预期，返工只是被推迟到执行阶段。如果多条遗漏候选都指向同一份缺少验收标准的需求文档，应优先处理需求侧原因，再进入用例补齐。
批量补齐用例时，怎样控制改动风险？
改动前先导出或备份用例库，保留可回退的版本；按原因分批推进，每批完成后做一次小范围对照复查，确认方向正确再进入下一批。补齐过程中如果发现新的原因类型或影响范围超出预期，暂停批量操作重新评估。变更未同步的场景还要先冻结旧用例版本，再按变更单更新，避免新旧逻辑混在一起。
在 ONES 中做需求与用例的对照检查，有哪些现成能力可以借助？
ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联；用例库支持按属性筛选，便于按需求维度查找对应用例；用例支持从 Excel 批量导入和导出备份，批量补齐前可先导出留存回退点；用例模块支持树状结构组织，可按业务模块或需求域分层管理。需求变更触发用例复查的联动机制，资料中未提及，实际执行时仍需在变更流程中人工设置复查节点。
补齐用例后，如何确认遗漏真的消除了？
分两步验证：先做需求条目与用例的一一对照复查，确认每条需求都能找到至少一条可执行验证，且用例内容与需求当前逻辑一致；再抽样执行新增用例，覆盖不同原因类型补出的用例，确认用例可运行、预期结果可判断。只确认用例数量增加，不足以说明遗漏已消除。
