白盒覆盖准则与代码覆盖

• 各覆盖准则的定义
• 强弱关系
• 适用场景

白盒覆盖准则的强弱关系（由弱到强）：语句覆盖（每条语句至少执行一次）< 判定覆盖（每个判定的真假分支至少执行一次）< 条件覆盖（每个条件的真假至少执行一次）< 判定/条件覆盖（判定与条件都覆盖）< MC/DC（每个条件独立影响判定结果）< 路径覆盖（所有路径至少执行一次）。关系上：语句覆盖最强是"弱覆盖"，判定覆盖强于语句覆盖但弱于条件覆盖；条件覆盖不保证判定覆盖（两者不互相包含）；判定/条件覆盖强于两者；MC/DC 比判定/条件覆盖更强，要求条件的独立影响；路径覆盖最强但最贵。适用场景：一般功能单元用语句/判定覆盖（成本低）；安全关键（航空、医疗、核能）用 MC/DC（DO-178C 要求）；路径覆盖因路径爆炸仅用于小模块或关键算法。选择依据是"覆盖强度需求 × 成本"，安全关键用 MC/DC，普通用判定/分支覆盖。

覆盖准则的强弱本质是"对代码行为验证的充分性"与"成本"的权衡。理解各准则定义与包含关系（哪些覆盖能推导哪些）是白盒测试的基础。MC/DC 是安全关键的标准，因为其"条件独立影响结果"的特性最强；路径覆盖理论上最强但实际因爆炸难以实现。

• MC/DC 的定义与要求
• DO-178C 的强制原因
• 最小 MC/DC 用例集设计

MC/DC（Modified Condition/Decision Coverage，修正条件/判定覆盖）要求：判定中的每个条件都必须独立影响判定结果——即每个条件单独改变时，判定结果随之改变。DO-178C（航空适航标准）把 MC/DC 作为结构覆盖的强制要求，原因：安全关键系统（飞行控制）的缺陷可能导致灾难性后果，MC/DC 能验证"每个条件都对决策有不可替代的影响"，防止"死条件"（某条件实际不影响结果）导致的逻辑缺陷，检测布尔逻辑中的冗余与错误，提供最高级别的逻辑验证保证。为复合条件设计最小 MC/DC 用例集：对有 n 个条件的判定，最小用例数为 n+1 个；设计方法——对每个条件，构造一对用例，使"其他条件不变、仅该条件反转时判定结果反转"。例如条件 A && B：设计 (A=T,B=T)→T、(A=F,B=T)→F、(A=T,B=F)→F，共 3=n+1 个用例，覆盖 A 与 B 独立影响。设计重点是"每个条件都要有独立翻转证据"。

MC/DC 的强制价值在于"验证条件的独立性"，防止"看似参与判断实则无效"的条件掩盖缺陷，这对安全关键系统至关重要。最小用例数 n+1 是 MC/DC 的效率优势——用最少用例达到强覆盖。DO-178C 强制它，是安全至上的标准。

• 条件覆盖与判定覆盖的区别
• 条件覆盖不保证判定覆盖的原因
• 代码示例

条件覆盖要求每个条件的真假都至少执行一次，判定覆盖要求每个判定的真假分支都至少执行一次。两者不互相保证：条件覆盖不能保证判定覆盖，因为覆盖了所有条件的真假（如 A=T、A=F、B=T、B=F）但可能所有组合都使判定为同一结果。例如复合条件 if (A || B)：条件覆盖的用例可选 (A=T,B=T)、(A=F,B=F)，此时 A 和 B 都覆盖了真假，但两个用例判定都为真（A=T 时 T，A=F且B=F 时 F 其实为假——需调整）。取用例 (A=T, B=F) 和 (A=F, B=T)：条件覆盖满足（A 覆盖 T/F，B 覆盖 T/F），但两个用例判定都为真（因为 A||B 中 A=T 或 B=T 都为真），判定为假的分支从未执行，即判定覆盖未满足。这就是"条件覆盖无法保证判定覆盖"的典型反例。

条件覆盖只关注"每个条件的真假被覆盖"，而不关注"组合导致判定结果的分支被覆盖"。在复合条件中可能所有条件都覆盖了真假，但判定分支（尤其 false 分支）没被覆盖。理解这一差异，才能在复杂逻辑中避免"覆盖了条件却漏掉分支"的盲区。

• 环复杂度 V(G) 的计算
• 基本路径法
• 最小用例集设计

基本路径法（Basis Path Testing）通过环复杂度 V(G) 确定"独立路径的数目"，从而设计最小测试用例集。V(G) 的计算：V(G) = 边数 - 节点数 + 2（E-N+2），或 V(G) = 判定节点数 + 1（P+1），或 V(G) = 区域数。V(G) 等于"独立路径的最小数目"，即至少需要 V(G) 个用例才能覆盖所有独立路径。设计步骤：第一步，画出控制流图（节点=语句/判定，边=控制流）；第二步，计算 V(G)；第三步，找出 V(G) 条独立路径（每条路径至少含一条新边）；第四步，为每条独立路径设计一个用例。这样用 V(G) 个用例覆盖全部独立路径，是"最小用例集"的近似。V(G) 越高，逻辑越复杂，需要更多用例。基本路径法用"路径覆盖"的思路弥补了"语句/分支覆盖不充分"的不足，同时用 V(G) 控制用例数不爆炸。

环复杂度 V(G) 是"逻辑复杂度的度量"，也是"独立路径数"，决定了最小用例数。基本路径法用 V(G) 个用例覆盖所有独立路径，是"路径覆盖"的可行近似（因路径覆盖本身会爆炸）。V(G) 既指导用例设计，也用于评估模块复杂度（V(G)>10 建议重构）。

• 插桩原理（字节码/源码/执行时）
• 三类工具的插桩方式
• 增量覆盖率统计

白盒覆盖工具通过"插桩（instrumentation）"在代码中插入覆盖记录点，执行时记录哪些代码被覆盖。插桩原理分三种：字节码插桩（JaCoCo 在 Java 字节码层面插入探针，无需改源码，支持 on-the-fly 离线插桩）、源码插桩（Coverage.py 把 Python 源码替换为带计数的版本，每行语句前插入计数器）、运行时/执行追踪插桩（Istanbul 通过 V8 的 coverage 或 JS 执行钩子统计）。统计方法：执行测试后，工具从探针收集的"执行计数"汇总，计算行/分支/函数/语句覆盖率。增量覆盖率统计：指"只统计本次变更（new code）的覆盖"而非全量——通常通过对比基线版本与当前版本的代码 diff，识别变更行/函数，只计算这些变更代码的覆盖率（如 JaCoCo 结合 diff 工具、SonarQube 的增量覆盖），用于 CI 门禁中"新增代码必须有覆盖"的检查，避免整体覆盖率被历史代码稀释。增量统计让"新代码覆盖"成为发布质量门禁的核心指标。

插桩原理差异（字节码/源码/运行时）决定工具对语言、构建、性能的影响。增量覆盖率的意义在于"关注变更代码的覆盖"，而非被历史代码稀释的平均值。工程上"增量覆盖率门禁"比"全量覆盖率"更能反映本次改动是否被充分测试。

• MC/DC 用例设计方法
• 独立影响的条件构造
• 最小用例集

MC/DC 用例设计方法的核心是"为每个条件构造一对用例，使其他条件保持不变、仅该条件反转时，判定结果反转"，从而证明该条件独立影响判定。构造步骤：第一，对判定中的每个条件 C，写出"其余条件取值"使 C 能独立决定结果（即 C 是"关键条件"）；第二，构造两个用例，一个 C=T、一个 C=F，其余条件取值相同，且两用例的判定结果不同；第三，对每个条件都重复，得到 n 个条件的最小用例集。对 AND 逻辑（A && B）：其余条件取能"暴露"该条件影响的值——A 的独立影响用例为 (A=T,B=T) 与 (A=F,B=T)（B 固定为 T 让 A 决定结果）；B 的独立影响用例为 (A=T,B=T) 与 (A=T,B=F)。合并去重后最小用例数为 n+1（如 A&&B 为 3 个）。对 OR 逻辑（A || B）：A 的独立影响用例需 B=F（让 A 决定结果），B 需 A=F。正确构造"其余条件取值"是设计的关键。

MC/DC 构造的关键是"让目标条件成为关键条件"——即其余条件取值需使该条件能独立决定结果。AND/OR 逻辑的"其余条件取值"不同（AND 取 T 暴露、OR 取 F 暴露），这是设计要点。最小用例数 n+1 是 MC/DC 高效性的体现。

• 行覆盖与分支覆盖的差别
• 行覆盖的盲区
• 必须用分支/条件覆盖的场景

行覆盖率（line coverage）指"被执行的行数 / 总行数"，分支覆盖率（branch coverage）指"被执行的判定分支数 / 总判定分支数"。两者的差距在于：行覆盖只关心"语句是否执行"，不关心"判定的每个分支是否都执行"——一个 if 语句即使只执行了 true 分支，其行也被覆盖，但 false 分支（甚至 else 分支）可能从未执行，相应的缺陷（如错误处理代码）就在行覆盖下漏检。因此行覆盖率常高于分支覆盖率，且行覆盖高的代码可能分支覆盖很低。必须用分支/条件覆盖为目标的场景：安全关键软件（航空、医疗、核能、自动驾驶）——因为这类系统要求"所有决策分支都被验证"，只有行覆盖不足以证明逻辑正确性，DO-178C 等标准要求判定/条件/分支覆盖。一般业务软件可用行覆盖+分支覆盖结合，但涉及高危逻辑（支付、权限、安全）也应达到分支覆盖。判断标准是"缺陷后果严重程度 + 逻辑复杂度"。

行覆盖是"最弱的结构覆盖"，分支覆盖关注"决策分支"，是比行覆盖更强的验证。行覆盖的盲区是"未执行的分支"，安全关键软件必须用分支/条件覆盖（甚至 MC/DC）以保证决策逻辑都被验证。工程上"行覆盖看整体、分支覆盖保决策"。

• 覆盖率的粒度层级
• 各粒度的解读
• 门禁选择

覆盖率的收集粒度从细到粗包括：行覆盖（每行执行）、分支覆盖（每判定分支）、函数覆盖（每个函数被调用）、类覆盖（每个类被加载/使用）。解读：行覆盖反映"代码执行面"，分支覆盖反映"决策逻辑覆盖"，函数覆盖反映"接口调用覆盖"，类覆盖反映"组件使用覆盖"。行覆盖易虚高（一行含多个分支只算一次），分支覆盖更能反映逻辑验证充分性，函数/类覆盖反映整体模块使用情况。门禁选择：应按风险分层——一般业务代码用"行覆盖+分支覆盖"组合门禁（如行≥80%、分支≥70%）；安全关键/高危模块用更高分支覆盖甚至 MC/DC；提交门禁更关注"增量覆盖"（新增代码行/分支覆盖）而非全量；函数/类覆盖用于模块级/集成层次。门禁选择的原则是"按风险与代码层设置目标，避免单一覆盖率指标的门禁导致覆盖虚高"。

覆盖率粒度反映"验证的层次"，行/分支/函数/类各有侧重。门禁选择要"按风险分层、按代码层设目标"，尤其注重增量覆盖与分支覆盖，避免"只看行覆盖"造成的虚高门禁。正确解读各粒度覆盖率是合理设置门禁的前提。

• 覆盖率与缺陷密度的关系
• 覆盖率通胀
• 断言空洞

研究结论：覆盖率与缺陷密度呈"弱相关"而非强相关——覆盖率高的代码不一定缺陷少，因为覆盖率只反映"代码被执行"，不反映"断言是否验证了正确行为"。覆盖率通胀（coverage inflation）指覆盖率高但测试质量低，可能因为：测试路径执行了代码但没断言（断言空洞）、测试数据没有区分度（所有用例都走同路径）、覆盖了无关紧要的代码。断言空洞（assertion gap）指代码被执行了但缺少有效断言，导致即使执行了错误代码也不报错，覆盖率虚高。避免方法：保证"每个覆盖点都有有效断言"（断言既有输出结果也有状态/行为）；用"变异测试"验证断言的检测能力（变异未杀死说明断言弱）；关注"分支覆盖+增量覆盖"而非单纯行覆盖；把覆盖与"测试价值"关联，避免"为覆盖而写测试"；用覆盖率报告审查"未覆盖/弱覆盖"区域而非只追求数字。核心是"覆盖率是手段，缺陷检测才是目的"。

覆盖率与缺陷密度弱相关，说明"覆盖率不是质量保证"。覆盖率通胀与断言空洞是"数字好看但质量差"的根源，规避的关键是"断言有效性 + 变异测试验证 + 关注分支/增量覆盖"。工程上要"看覆盖用于发现盲区，而非作为目标的唯一标准"。

• 未覆盖分支的反向分析
• 从未覆盖反推缺失场景
• 可达未覆盖与死代码的区分

未覆盖分支的反向分析是"从覆盖率报告的未覆盖点反推测试缺口"：对每个未覆盖的分支/条件，分析其"逻辑条件"（什么样的输入会进入该分支），据此设计缺失的测试场景补测。例如报告显示 if (age > 65) 的 true 分支未覆盖，则反推"缺少超龄用户输入场景"，补测 age=66 等。区分可达未覆盖与死代码的方法：可达未覆盖（reachable uncovered）是"逻辑上可到达但测试未覆盖"的分支，应补用例；死代码（dead code）是"逻辑上永远不可达"的分支（如互斥条件、固定常量导致的分支），补测无意义，应分析并标记（甚至删除）。判断方法：静态分析分支的前置条件是否可能为真（用代码逻辑、常量、不变式判断），或用数据流/可达性分析；对不确定的死代码，可用"是否被任何合法输入触发"来验证。工程上"反向分析补测 + 死代码识别清理"双管齐下，既补足测试又消除无效代码。

反向分析把覆盖率报告从"结果数字"变成"测试指导"——从未覆盖分支反推缺失场景。区分可达与死代码是关键：可达未覆盖要补测，死代码补测无意义。这要求"分析未覆盖的逻辑条件 + 判断可达性"，把覆盖率转化为测试改进的输入。

• 覆盖率与用例价值
• 用例冗余评估
• 覆盖率低的解读

覆盖率与用例价值：覆盖率反映"代码被覆盖的广度"，但用例价值取决于"是否覆盖了有风险/有缺陷的代码并验证了正确行为"，而非单纯覆盖数量。用历史覆盖率数据评估用例是否冗余：若某用例与其他用例覆盖的代码完全重叠（可从覆盖率报告看"某用例单独覆盖了哪些行"），且该用例长时间未发现缺陷、未覆盖独特代码，则可能是冗余用例，可考虑删除或合并；反之，覆盖独特高风险代码的用例即使覆盖率贡献小也价值高。覆盖率低是否一定代表测试无效：不一定——覆盖率低可能与"代码体积大、含大量成熟/低风险代码"有关，若覆盖了高风险、易变更、缺陷密集的部分，覆盖率低但测试有效；反之覆盖率高但都是低价值重复用例，也不代表有效。判断测试有效性应结合"覆盖率分布的合理性（高风险区域覆盖）+ 缺陷发现情况 + 变异测试"，而非只看覆盖率绝对数字。

覆盖率是"广度"指标，用例价值是"风险覆盖+缺陷发现"的深度指标。用历史覆盖率评估冗余（看是否覆盖独特代码）与评估有效性（看是否覆盖高风险区域）是正确用法。覆盖率低的解读要结合"覆盖分布"而非绝对数字，避免"唯覆盖率论"。

• 简单循环的边界取值
• 嵌套循环的取值策略
• 串接循环的取值策略

循环测试的边界取值策略：简单循环（单层循环）——测 0 次、1 次、2 次、接近上限（上限-1）、等于上限、上限+1、以及任意合理次数（如 n），覆盖循环边界（是否进入、是否越界、是否死循环）。嵌套循环（多层循环）——若每层都测所有边界则组合爆炸，策略是"外层取最小值、内层全测边界；再外层取一次、内层全测；依次类推"，即只让一层循环做全面的边界测试，其他层取最小/典型值，控制复杂度。串接循环（多个循环串联）——若两个循环独立，分别用简单循环策略；若循环相关（第二循环依赖第一循环结果），则需考虑串联后的边界组合，通常取"第一循环边界值+第二循环边界值"的关键组合。循环测试的重点是"确认循环边界条件正确（0次、1次、上限、上限+1）与循环体正确性"，避免"多一次/少一次"的 off-by-one 缺陷。

循环测试的核心是"循环边界的 off-by-one 缺陷"与"循环层数组合的爆炸"。简单循环用边界值覆盖（0/1/2/上限/上限+1），嵌套循环用"层层集中测试"避免爆炸，串接循环关注循环间依赖。理解各循环类型的策略，能系统验证循环逻辑。

• CI 门禁的覆盖率阈值
• 覆盖率通胀的规避
• 门禁与质量

CI 门禁中覆盖率阈值的合理设置：没有放之四海的标准，应"按项目风险与阶段设定"——新项目/核心模块可设较高（如行覆盖≥80%、分支≥70%），一般业务模块可设中等（如行≥70%、分支≥60%），遗留代码/低风险模块可设较低或暂不设；更重要的是设置"增量覆盖门禁"（新增代码行/分支覆盖要达到阈值，如新增代码行覆盖≥80%），防止全量覆盖被历史代码稀释。阈值应"可达成且有意义"，过高导致为覆盖而写用例，过低形同虚设。避免覆盖率通胀（断言空洞）：覆盖率门禁之外，评估"断言有效性"——用变异测试验证断言能否"杀死"变异体（变异未被杀死说明断言弱）；审查"覆盖的高价值代码是否都有有效断言"；把"分支覆盖+增量覆盖"纳入门禁而非只求行覆盖；警示"覆盖率高但缺陷未减少"的异常。核心是"覆盖率门禁 + 断言有效性审查"双管齐下，防止"数字达标的空测试"。

CI 覆盖率门禁的合理阈值是"按风险分层、可达成、聚焦增量"的平衡。覆盖率通胀的根源是"断言空洞"，规避靠"变异测试验证断言 + 分支/增量覆盖门禁 + 有效断言审查"。门禁是手段，目的是"保证新增/关键代码被有效验证"。

• 覆盖率驱动的测试
• 补漏策略
• 优先级排序

覆盖率驱动的测试指"用覆盖率报告指导测试补漏与优先级"，而非仅用覆盖率作结果指标。开展方法：第一步，运行测试并生成覆盖率报告；第二步，分析未覆盖区域，按风险排序——高优先级补漏的是"高风险（涉及金额、安全、权限、核心流程）但未覆盖"的代码，以及"变更频繁、历史缺陷密集"的代码；低优先级是"低风险、成熟稳定"的未覆盖代码；第三步，针对高优先级未覆盖区域设计补充用例（用反向分析反推缺失场景）；第四步，对"死代码"（不可达）标记清理而非补测。优先级原则是"风险×变更频率×缺陷密度"决定补漏顺序，而非"覆盖率百分比"均摊补漏。覆盖率驱动测试的价值是"用覆盖率发现盲区，把有限测试资源投向高风险未覆盖区域"，让覆盖率成为"测试改进的雷达"而非"指标"。

覆盖率驱动的测试是把覆盖率当作"发现盲区的工具"，用"风险×变更×缺陷密度"确定补漏优先级。核心是"优先补高风险未覆盖区域，而非追求数字均摊"。这使覆盖率从"结果指标"变为"测试资源分配的指导"。

• 判定/条件覆盖的落地
• JaCoCo 分支覆盖口径
• 实际含义

判定/条件覆盖在单元测试框架中通常转化为"分支覆盖"（branch coverage）来统计。JaCoCo 的分支覆盖口径：JaCoCo 把每个"赋值/方法调用/分支"等视为分支点，统计"被覆盖的分支数 / 总分支数"，以"分支被覆盖"（如 true/false 都执行）来计算；JaCoCo 的分支覆盖本质上是"判定覆盖"（覆盖每个判定的分支），而非严格的"条件覆盖"（每个条件原子）。实际含义：JaCoCo 报告中的分支覆盖率反映"判定的每个分支是否都被执行"，用于评估决策逻辑覆盖；它不细分到条件的每个原子独立覆盖（那需要 MC/DC 级别）。落地时，单元测试用 JaCoCo 分支覆盖率衡量"判定的全面性"，发现"某分支未执行"即某决策路径未验证，需补充能触发该分支的用例。理解口径很重要：JaCoCo 的分支覆盖≈判定覆盖，若需更严的条件覆盖需用其他工具或分析。实际使用中结合"行覆盖+分支覆盖"报告，优先补足高分支未覆盖的判定。

JaCoCo 的分支覆盖口径是"判定/分支覆盖"，是"每个判定的分支是否都执行"，而非严格的"条件原子覆盖"。理解这一口径，才能正确解读 JaCoCo 报告（分支覆盖≈判定覆盖），并在此基础上决定是否需 MC/DC 级验证。落地时用分支覆盖补足判定分支，是单元测试的常规做法。

• 路径覆盖的困难
• 基本路径法
• V(G) 近似

路径覆盖难以达成的原因是：路径数随判定分支与循环组合指数增长甚至无限（循环次数不定导致路径无限），全路径覆盖在大多数程序中不可行，成本爆炸。因此用基本路径法近似：用环复杂度 V(G) 确定"独立路径数"，独立路径是"至少引入一条新语句/新边"的路径，V(G) 给出独立路径的最小数目，覆盖这 V(G) 条独立路径就近似覆盖了全部"基础路径"，从而把"路径覆盖"转化为"覆盖 V(G) 条独立路径"这一可行目标。设计步骤：画控制流图→算 V(G)→列独立路径→为每条路径设计用例。V(G) 近似覆盖的意义：它覆盖了所有"线性独立"的路径，虽非全部路径（循环内的组合路径仍可能漏），但已覆盖主要逻辑路径，避免了全路径爆炸。V(G) 越大，需要越多独立路径用例，也提示逻辑复杂度越高。

路径覆盖的困难是"指数/无限路径数"，基本路径法用 V(G) 把目标收敛为"覆盖独立路径"，是"路径覆盖的可行近似"。V(G) 既是独立路径数也是复杂度度量，用 V(G) 个用例覆盖独立路径，是工程上"近似路径覆盖"的标准做法。

• 遗留代码补测的挑战
• 优先级排序
• 覆盖率的作用

遗留代码补测面临的挑战是"代码量大、历史久、全量覆盖成本极高"，因此不应追求全量覆盖，而应"按风险与价值优先补测"。方法：依据"变更频率、缺陷密度、业务影响"对模块排序——高变更频率的模块（改动多、回归风险大）、高缺陷密度模块（历史缺陷多、易出错）、高业务影响模块（核心流程、金额、安全）优先补测；覆盖率在这里的作用是"发现盲区与监控进度"——先测出当前覆盖率，找出高风险模块的未覆盖区域，优先补充这些区域的用例，再逐步提升。用"变更频率×缺陷密度×业务影响"的加权评分决定补测顺序，而非"覆盖面平均"。对低风险、稳定、极少变更的遗留代码，可接受较低覆盖率。补测后用覆盖率报告确认"高风险模块覆盖提升"，建立"风险覆盖率"而非"全量覆盖率"的度量。

遗留代码补测的核心是"把有限资源投向风险最高的模块"，而非"全量覆盖"。排序依据是"变更频率×缺陷密度×业务影响"，覆盖率用于"定位高风险未覆盖盲区与监控补测进度"。这避免"为全量覆盖而铺开低价值补测"。

• 插桩的性能开销
• 采样与增量收集
• 平衡策略

覆盖率收集通过插桩在代码中插入探针，会带来执行性能开销：插桩点越多，探针计数与记录的开销越大，测试执行越慢（尤其热路径）。平衡策略：一是"插桩方式"——on-the-fly/离线插桩的选择、探针的轻量化（JaCoCo 用局部变量计数而非记日志）都能降低开销；二是"采样（sampling）"——对大规模测试不逐条记录，而是按采样间隔记录覆盖（如每 N 次执行记一次），牺牲精度换取低开销，适合性能敏感场景；三是"增量收集（incremental）"——只收集本次变更/新增代码的覆盖，而非全量，减少探针与数据分析量；四是"按需开启"——仅在有覆盖需求的测试阶段（如 CI 质量门禁）开启插桩，性能测试/日常开发不开启。平衡原则是"按场景选择开销与精度的折中"：精确覆盖（CI 门禁）用完整插桩，性能/大规模场景用采样或增量收集。核心是"覆盖率精度与执行性能的权衡"。

覆盖率收集的性能开销是"插桩探针"带来的，平衡靠"插桩方式、采样、增量收集、按需开启"四手段。工程上按场景选择：CI 门禁要精确覆盖（完整插桩），性能测试免插桩，大规模执行用采样/增量。理解开销来源与平衡手段，能避免"覆盖率收集拖慢测试"。

• 需求覆盖与代码覆盖的互补
• 需求追踪矩阵（RTM）
• 合并为发布依据

需求覆盖率与代码覆盖率互补：代码覆盖率反映"代码被执行了多少"，但无法反映"需求是否被测试"——代码覆盖率可能很高，但某个需求功能可能从没被测试（功能级漏测），或代码覆盖率低但需求已覆盖。需求覆盖率用需求追踪矩阵（RTM）补充：RTM 把"需求 ↔ 用例 ↔ 代码/缺陷"建立映射，逐条需求标记"是否有对应用例、用例是否执行、是否通过"，从而计算出需求覆盖率（已覆盖需求数/总需求数），暴露"无用例覆盖的需求"（功能级漏测）。合并为发布依据：把两类覆盖合并评估——需求覆盖率反映"功能是否都被测"，代码覆盖率反映"代码是否都被执行"，两者结合能发现"代码覆盖高但需求漏测"或"需求覆盖高但代码分支未测"的盲区；发布依据通常要求"需求覆盖达到目标（如关键需求100%覆盖）+ 代码覆盖达到目标（高风险模块分支覆盖达标）+ 缺陷状态"等综合指标，用"需求覆盖兜功能、代码覆盖兜逻辑、缺陷状态兜质量"综合判定发布风险。

代码覆盖率是"逻辑维度"，需求覆盖率是"功能维度"，两者正交互补。RTM 解决"功能级漏测"（代码覆盖发现不了），代码覆盖解决"逻辑分支漏测"（需求覆盖发现不了）。合并为发布依据时，用"需求覆盖+代码覆盖+缺陷状态"综合评估，避免单一阵线。