测试覆盖缺口检查要回答的是：这个迭代里，哪些需求还没有被用例设计覆盖、哪些用例没有执行、哪些失败结果没有经过缺陷验证。把需求、用例、执行记录和缺陷按同一时间窗对齐，用统一口径算出覆盖率，再把未覆盖项按原因归类，检查结论才能落到具体条目和补齐动作上。本文给出一套可复算的指标定义、取数规则和计算步骤。
要点总览（TL;DR）
- 测试覆盖缺口检查把需求、用例、执行记录、缺陷按同一时间窗对齐，分别判定设计缺口、执行缺口、验证缺口三类问题。
- 四个可复算指标共用“应覆盖需求条目数”作分母：需求用例覆盖率、需求执行覆盖率、需求通过覆盖率、缺口密度；缺失数据单列“不可判定”，分母为零记“不适用”。
- 检查按锁定需求清单、关联用例、读取执行结果、核对缺陷验证、按原因归类排优先级五步执行，结论落到具体需求条目和补齐动作。
- 覆盖率是过程信号，不能作为缺陷漏出的因果保证；不可判定项超过分母10%时只输出缺口清单和定性说明，不发布覆盖率数字。
- 两期对比前须确认需求状态筛选、时间窗长度和缺失值处理规则一致，口径变更需在报告中注明。
检查目标：要回答哪些覆盖问题
覆盖缺口检查的评估对象是需求条目，以及每条需求关联的用例、执行记录和缺陷。检查的目标是把“覆盖缺口”拆成三类可分别判定的问题，避免用一个笼统的覆盖率数字掩盖不同环节的问题。
- 设计缺口：需求条目在时间窗内没有关联任何有效用例，或关联的用例已被废弃、与当前需求版本不匹配。判定对象是需求与用例的关联关系。
- 执行缺口：需求已有关联用例，但在时间窗内没有执行记录，或只执行了部分用例。判定对象是用例的执行状态。
- 验证缺口：用例执行结果为失败，但没有对应的缺陷记录，或缺陷未经过回归验证即关闭。判定对象是失败用例与缺陷的对应关系及缺陷状态。
三类缺口对应三个不同的补齐动作：设计缺口要补用例，执行缺口要安排执行，验证缺口要补缺陷单或补回归。检查报告按这三类分别列条目，比只报一个总覆盖率更能指导下一步工作。
需要说明本文的边界。检查只做覆盖判定，不涉及插桩实现、代码覆盖率工具的原理与配置；需求到设计、开发、发布的全链路追溯体系属于另一个主题，本文只在需求与测试工作项的关联层面取数。若团队已有代码覆盖率数据，它可以作为补充证据，但不替代本文的需求维度覆盖判定。
指标与范围：四个覆盖指标和统计口径
四个指标都以“应覆盖需求条目数”为统一分母，这样不同指标之间可以直接比较，也能看出缺口集中在设计、执行还是验证环节。时间窗建议与迭代周期一致，例如一个两周迭代取迭代开始日到检查日。
| 指标 | 公式 | 分子 | 分母 | 单位 | 缺失值处理 |
|---|---|---|---|---|---|
| 需求用例覆盖率 | 已关联有效用例的需求数 ÷ 应覆盖需求数 | 至少关联一条有效用例的需求条目数 | 时间窗内应覆盖需求条目数 | 百分比 | 关联关系缺失的需求记为“不可判定” |
| 需求执行覆盖率 | 已执行用例覆盖的需求数 ÷ 应覆盖需求数 | 至少一条关联用例有执行记录的需求条目数 | 同上 | 百分比 | 执行记录缺失记为“不可判定” |
| 需求通过覆盖率 | 用例全部通过的需求数 ÷ 应覆盖需求数 | 关联用例执行结果全部为通过的需求条目数 | 同上 | 百分比 | 存在未执行用例的需求不计入分子 |
| 缺口密度 | 缺口需求数 ÷ 应覆盖需求数 × 100 | 存在任一类型缺口的需求条目数 | 同上 | 条/百需求 | 不可判定项不计入缺口 |
分母的筛选条件是：需求状态在时间窗结束时处于“已评审通过”或“开发中/待测试”等已进入测试范围的状态，且计划在本迭代交付。草稿状态、已取消、明确延期的需求不计入分母。需求状态应取时间窗结束时的快照，避免检查过程中状态变化导致分子分母错位。
缺失数据的处理规则需要提前写死。需求与用例的关联字段为空、执行记录无法归属到具体用例、缺陷与失败用例无法对应，这些情况一律单列为“不可判定”，不计入分子，也不直接算作缺口。重复关联的处理是：同一需求关联多条用例只计一次需求；同一用例多次执行取时间窗内最后一次结果；同一失败用例关联多个缺陷时，只要有一个缺陷完成验证即视为验证通过。
分母为零时，指标记为“不适用”，不写 0%。分母为零通常意味着时间窗内没有进入测试范围的需求，此时覆盖率没有解释意义，报告中应说明原因，例如迭代尚未进入测试阶段或需求清单筛选条件有误。
数据口径与证据：从哪里取数、怎样保证可比
四类数据分别来自需求管理、用例库、测试执行记录和缺陷跟踪。要让不同批次、不同团队的结果可比，关键是固定关联字段和时间窗对齐方式，并保留可复核的导出记录。
| 数据类别 | 关键字段 | 来源 | 对齐规则 |
|---|---|---|---|
| 需求 | 需求编号、标题、状态、所属迭代、计划交付时间 | 需求管理工作项 | 取时间窗结束时的状态快照 |
| 用例 | 用例编号、关联需求编号、用例状态、版本 | 用例库 | 只统计有效状态用例，废弃用例排除 |
| 执行记录 | 用例编号、执行时间、执行结果、执行人 | 测试计划执行记录 | 取时间窗内最后一次执行结果 |
| 缺陷 | 缺陷编号、关联用例或需求、状态、关闭时间、验证结论 | 缺陷跟踪 | 验证结论以回归通过为准 |
时间窗对齐有两个细节。第一，需求清单按时间窗结束时的状态快照锁定，检查开始后新增或变更状态的需求不回溯修改本期分母，留到下一期统计。第二，执行记录和缺陷关闭时间必须落在同一时间窗内，窗口外补录的记录单独标注，不混入本期分子。这样两期数据对比时，差异来自实际覆盖变化，而不是取数时点不同。
证据留存包括三样东西：检查清单（锁定后的需求条目列表及每条的状态）、导出记录（用例关联表、执行记录表、缺陷表的导出文件及导出时间）、评审结论（检查结果经过测试负责人确认的结论和补齐责任人）。导出记录要带导出时间戳，便于后续复算时确认数据版本。当数据不可比时，例如关联字段大面积缺失、执行记录来自旧系统迁移、需求状态快照缺失，应在报告中标注“本期数据不可比”，只做定性说明，不与上期数字直接比较。
计算与评估步骤：从取数到缺口归类
整个检查按五步执行，每步都有明确输入和输出，前一步的输出是后一步的输入。流程中涉及需求与测试工作项的关联、执行记录和缺陷状态的流转，ONES 测试管理支持用例与产品需求、研发任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，可以作为承载这条检查链路的工具环境；具体指标仍需按本文口径自行计算。
第一步：锁定时间窗与需求清单
输入是迭代计划和需求状态。动作是确定时间窗起止日期，按状态条件筛选需求，导出需求编号、状态、所属迭代。输出是一份锁定后的应覆盖需求清单，作为分母。完成标志是清单条目数确定并经测试负责人确认。
第二步：关联用例并判定设计缺口
输入是需求清单和用例库导出。动作是按需求编号匹配有效用例，统计每条需求关联的用例数，关联数为零或仅有废弃用例的标记为设计缺口。输出是需求—用例关联表和设计缺口条目列表。完成标志是每条需求都有“已关联/设计缺口/不可判定”三种状态之一。
第三步：读取执行结果判定执行缺口
输入是关联表和执行记录导出。动作是取时间窗内每条用例的最后一次执行结果，按需求汇总执行情况，有执行记录的需求计入执行覆盖分子，无执行记录的标记为执行缺口。输出是需求执行状态表和执行缺口列表。完成标志是每条已关联需求都能对应到执行状态。
第四步：核对缺陷验证判定验证缺口
输入是失败用例清单和缺陷导出。动作是把执行结果为失败的用例与缺陷记录匹配，检查缺陷是否已创建、是否完成回归验证。失败但无缺陷、或缺陷未验证即关闭的，标记为验证缺口。输出是验证缺口列表。完成标志是每条失败用例都有明确的验证结论。
第五步：按原因归类并排出补齐优先级
输入是三类缺口列表。动作是按原因归类，例如需求变更未同步用例、用例未分配执行人、缺陷遗漏创建、回归未执行等，再按需求优先级和缺口类型排补齐顺序。输出是缺口归类汇总表和补齐任务清单，每条含需求编号、缺口类型、原因、责任人和计划完成时间。完成标志是补齐任务已分配到人。
算例：一个迭代的覆盖缺口检查
以下为一组假设数据，用于演示计算过程，不代表任何真实团队的实际水平。假设某迭代时间窗为两周，时间窗结束时处于应覆盖状态的需求共 40 条。
| 项目 | 数值 | 说明 |
|---|---|---|
| 应覆盖需求数 | 40 | 分母 |
| 已关联有效用例的需求数 | 34 | 其中 2 条仅有废弃用例，不计入 |
| 有执行记录的需求数 | 30 | 已关联需求中 4 条未执行 |
| 用例全部通过的需求数 | 24 | 6 条需求存在失败用例 |
| 失败用例数 | 9 | 分布在 6 条需求上 |
| 已创建并完成验证的缺陷数 | 7 | 对应 7 条失败用例 |
| 不可判定需求数 | 3 | 关联字段缺失，无法归属 |
逐项代入公式：
- 需求用例覆盖率 = 34 ÷ 40 = 85.0%
- 需求执行覆盖率 = 30 ÷ 40 = 75.0%
- 需求通过覆盖率 = 24 ÷ 40 = 60.0%
- 缺口需求数 = 设计缺口 6 条（40 − 34）+ 执行缺口 4 条 + 验证缺口 2 条（9 − 7）= 12 条，缺口密度 = 12 ÷ 40 × 100 = 30 条/百需求
按原因归类：设计缺口中 4 条是需求变更后未同步补充用例，2 条是用例仅有废弃版本；执行缺口 4 条均因未分配执行人；验证缺口 2 条是失败用例未创建缺陷。补齐优先级上，验证缺口涉及已发现的失败结果，应最先处理；设计缺口中的需求变更项需要与产品确认范围后再补用例；执行缺口按需求优先级安排执行人即可。
该算例的假设边界：需求状态快照完整、执行记录均落在时间窗内、缺陷与失败用例可一一对应。若实际数据中不可判定项占比明显高于本例的 3 条，结论需要按下一节的规则降级。
结果解读与限制：数字能说明什么、不能说明什么
覆盖率反映的是检查时点上需求在用例设计、执行和验证三个环节的覆盖状态，它是过程信号，不能作为缺陷漏出的因果保证。需求通过覆盖率高，说明已执行用例大多通过，但不代表未覆盖的需求没有风险，也不代表已通过用例的设计足够充分。把覆盖率直接当作版本质量结论，会掩盖用例设计本身的薄弱。
分母口径变化会显著改变结果。若把草稿需求也计入分母，覆盖率会被拉低；若只统计已关联用例的需求，覆盖率会虚高。因此两期对比前必须确认需求状态筛选条件、时间窗长度和不可判定项处理规则一致，口径变更要在报告中注明，不能直接比较。
不可判定项占比过高时，结论应降级。一个可操作的判断是：不可判定需求数超过分母的 10%，本期只输出缺口条目清单和定性说明，不发布覆盖率数字，也不与上期比较。此时优先修复的是关联字段的填写规范，而不是补用例。
检查结果的使用方式也影响数据质量。若覆盖率与个人考核直接挂钩，执行人倾向于快速标记通过或补录关联，指标会失真。更合适的用法是把结果落到具体需求条目和补齐动作上，跟踪缺口关闭情况，把覆盖率作为观察趋势的辅助指标。ONES 测试管理提供测试计划进度与通过率概览、质量统计报表和缺陷分布统计，可以在同一环境中查看执行进展和缺陷情况，为按本文口径复算提供数据基础；覆盖率的分母口径和缺口归类规则仍需团队自行约定并保持稳定。
常见问题
需求状态在检查期间发生变化，分母应该怎么处理？
分母取时间窗结束时的需求状态快照，检查开始后新增或变更状态的需求不回溯修改本期分母，留到下一期统计。这样两期数据对比时，差异来自实际覆盖变化，而不是取数时点不同。若快照本身缺失，应在报告中标注本期数据不可比，只做定性说明。
同一需求关联多条用例、同一用例多次执行，统计时怎么计数？
同一需求关联多条用例只计一次需求；同一用例多次执行取时间窗内最后一次结果；同一失败用例关联多个缺陷时，只要有一个缺陷完成回归验证即视为验证通过。这些规则需要在检查前写死，避免不同人复算时得出不同结果。
覆盖率算出来偏低，应该先补用例还是先补执行？
按缺口类型分派动作：设计缺口补用例，执行缺口安排执行人，验证缺口补缺陷单或补回归。优先级上，验证缺口涉及已发现的失败结果，通常最先处理；设计缺口中的需求变更项需要先与产品确认范围再补用例；执行缺口按需求优先级安排执行即可。ONES 测试管理支持未通过的用例快速创建缺陷任务，并在测试与研发团队间流转，可承接验证缺口的补齐动作。
团队刚开始做这项检查，数据关联字段大量缺失怎么办？
先把缺失项单列为“不可判定”，不计入分子也不直接算作缺口，同时统计不可判定占比。若超过分母的10%，本期只输出缺口条目清单和定性说明，不发布覆盖率数字，也不与上期比较。此时优先修复的是关联字段的填写规范，例如要求用例必须关联需求编号、执行记录必须归属到具体用例，再逐步恢复定量结论。
覆盖率能不能直接用于团队或个人考核？
不建议直接挂钩。覆盖率与个人考核绑定后，执行人倾向于快速标记通过或补录关联，指标会失真。更合适的用法是把结果落到具体需求条目和补齐动作上，跟踪缺口关闭情况，把覆盖率作为观察趋势的辅助指标。ONES 测试管理提供测试计划进度与通过率概览、质量统计报表和缺陷分布统计，可在同一环境查看执行进展和缺陷情况，为按统一口径复算提供数据基础。
