❄️ 我的个人专栏：
《智能软件工程AI4SE》
《嵌入式面试总结》
《嵌入式处理器架构解析》
《嵌入式与虚拟化》
《嵌入式软件测试》
🌟 Simplicity is the ultimate sophistication
摘要：本文是「嵌入式软件覆盖率测试」系列第六篇，围绕单元、集成、系统三个层级构建嵌入式覆盖率测试的全景图。文章先说明为何需要分层视角，再分别梳理各层级的测试目标、核心覆盖率指标与落地要点，随后给出三层协同的缺口传递机制与分层门禁设计，最后总结常见误区与改进建议，帮助团队把覆盖率从“单点数字”变成贯穿研发流程的质量抓手。
一、为什么要建立“全景图”
在前五篇中，我们分别讨论了语句覆盖、分支覆盖、MC/DC、插桩原理以及覆盖率工具链的搭建。但在真实项目中，很多团队会遇到这样的困惑：单元测试覆盖率做到了 90%，为什么系统联调阶段仍然问题频发？或者反过来，系统测试用例写得很全，却说不清到底“覆盖”了什么。
根本原因在于：覆盖率不是一个单一维度的数字，而是分布在多个测试层级上的一组指标。不同层级关注的对象不同、可度量的粒度不同、能暴露的缺陷类型也不同。只有把单元、集成、系统三个层级的覆盖率放在同一张图上，才能回答“我们的测试到底覆盖了什么、还缺什么”。
本文要构建的这张“全景图”，核心回答三个问题：
- 分层：每个层级测什么、覆盖什么、用什么指标衡量；
- 贯通：三层覆盖率之间如何衔接，如何避免重复与遗漏；
- 落地：在嵌入式环境下，各层级分别用什么手段采集覆盖率，如何纳入流水线。
二、三层覆盖率测试全景图
先给出整体视图。下图展示了从代码到系统的分层结构，以及各层级对应的覆盖率关注点。
flowchart TD
A[嵌入式软件系统] –> B[单元层 Unit]
A –> C[集成层 Integration]
A –> D[系统层 System]
B –> B1[被测对象: 函数/模块]
B –> B2[覆盖率指标: 语句/分支/MC-DC]
B –> B3[手段: 宿主机或目标机插桩 + 单元测试框架]
C –> C1[被测对象: 模块间接口/任务/驱动]
C –> C2[覆盖率指标: 接口分支/调用对/状态迁移]
C –> C3[手段: 打桩模拟 + 目标机插桩 + 接口追踪]
D –> D1[被测对象: 完整系统/业务场景]
D –> D2[覆盖率指标: 需求覆盖/场景覆盖/代码回采]
D –> D3[手段: HIL/SIL + 需求追踪矩阵 + 代码覆盖率回采]
这张图的关键在于：越往下，度量越精确但视野越窄；越往上，视野越完整但度量越粗。三层不是替代关系，而是互补关系。
三、单元层覆盖率：把代码逻辑测透
3.1 测试目标
单元层聚焦单个函数或模块的内部逻辑，目标是验证每条语句、每个分支、每个条件组合都被执行到。它是覆盖率指标最“硬”的一层，也是唯一能稳定做到 MC/DC 级别度量的层级。
3.2 核心指标
| 语句覆盖率 | 可执行语句被执行的比例 | 通用基础指标 | ≥ 90% |
| 分支覆盖率 | 判定分支的真假路径覆盖比例 | 含大量 if/switch 的逻辑 | ≥ 85% |
| MC/DC | 每个条件独立影响判定结果 | 安全关键（汽车、航空、医疗） | 100% |
| 函数覆盖率 | 被调用过的函数比例 | 快速摸底 | ≥ 95% |
3.3 落地要点
- 优先在宿主机做单元测试：通过硬件抽象层（HAL）打桩，把与硬件强相关的代码隔离，可在 PC 上高速运行并采集 gcov/llvm-cov 数据。
- 目标机补充验证：对编译器优化、字节序、中断相关逻辑，需在目标机上复测，避免宿主机与目标机行为差异导致覆盖率失真。
- 关注“覆盖但未验证”：覆盖率只说明代码被执行，不说明断言有效。建议结合变异测试（Mutation Testing）评估用例的检出能力。
经验提示：单元层覆盖率的最大价值不是追求 100%，而是通过“未覆盖代码清单”反向发现死代码、异常分支缺失和需求遗漏。
四、集成层覆盖率：把接口和交互测通
4.1 测试目标
集成层关注模块之间的协作：函数调用关系、任务间通信、驱动与中间件的交互、中断与主循环的配合。这一层的覆盖率不再以“代码行”为核心，而是以接口路径和交互序列为核心。
4.2 核心指标
- 接口分支覆盖：模块间调用返回值的各分支是否都被处理，尤其是错误码路径。
- 调用对覆盖（Call Pair）：函数 A 调用 B 的各种上下文组合是否被覆盖。
- 状态迁移覆盖：状态机的状态与迁移边是否全部被触发。
- 任务/中断交互覆盖：并发场景下的关键交错是否被构造。
4.3 落地要点
- 用打桩构造边界：对下层模块打桩，注入超时、返回错误、数据异常等场景，把“难以触发的分支”变成可测分支。
- 保留代码级覆盖率作为回采：集成测试运行在目标机上时，仍可通过插桩回采代码覆盖率，用于判断集成用例是否真正走到了目标模块内部。
- 重点盯住错误路径：嵌入式系统的多数现场故障来自异常处理分支，集成层应显式设计“故障注入”用例。
/* 集成层打桩示例：模拟驱动返回错误，验证上层错误处理分支 */
int mock_sensor_read(int id, int *value) {
(void)id;
(void)value;
return -EIO; /* 强制返回错误，触发上层异常分支 */
}
void test_sensor_init_failure(void) {
stub_set(mock_sensor_read);
int ret = sensor_manager_init();
assert(ret == -EIO); /* 验证错误码透传 */
assert(sensor_manager_state() == SENSOR_STATE_FAULT);
}
五、系统层覆盖率：把需求和场景测全
5.1 测试目标
系统层面对完整产品，验证需求是否被实现、业务场景是否被走通。此时代码覆盖率往往难以直接度量（尤其是量产固件），因此更多采用需求覆盖率与场景覆盖率，并以代码覆盖率回采作为辅助证据。
5.2 核心指标
| 需求覆盖率 | 需求追踪矩阵（RTM）中已验证需求 / 总需求 | 回答“需求是否都测了” |
| 场景覆盖率 | 已执行场景 / 场景清单 | 回答“用户路径是否都走了” |
| 代码覆盖率回采 | 系统测试期间插桩采集 | 回答“测试是否真的跑到代码” |
| 接口/协议覆盖 | 已覆盖报文类型与异常码 | 回答“通信边界是否测全” |
5.3 落地要点
- 建立需求到用例的双向追踪：每条需求至少对应一条正向用例和一条异常用例，避免“只测 happy path”。
- HIL/SIL 结合：用硬件在环（HIL）覆盖真实时序与电气特性，用软件在环（SIL）批量回归，两者共享同一套场景脚本。
- 覆盖率回采要控制开销：系统层插桩会带来性能与存储开销，建议采用分区插桩或采样方式，仅对关键模块开启。
六、三层如何协同：从数字到闭环
三层覆盖率如果各自为战，很容易出现“单元 90%、系统 60%，但没人知道差在哪”的局面。建议按以下方式打通：
flowchart LR
U[单元覆盖率] –>|未覆盖分支清单| I[集成用例设计]
I –>|接口与异常路径| S[系统场景设计]
S –>|代码回采缺口| U
U –> G1{门禁: 分支≥85%}
I –> G2{门禁: 错误路径全覆盖}
S –> G3{门禁: 需求100%}
G1 –> R[发布评审]
G2 –> R
G3 –> R
七、常见误区与建议
- 误区一：只做单元覆盖率。单元覆盖率高不代表系统可靠，接口与并发问题只能在集成和系统层暴露。
- 误区二：把系统覆盖率等同于代码覆盖率。系统层应以需求和场景为主，代码覆盖率仅作回采证据。
- 误区三：为覆盖率而写用例。凑数的用例会拉高数字却降低缺陷检出率，应结合变异测试评估用例质量。
- 误区四：忽略插桩开销。目标机资源受限时，需评估插桩对时序和内存的影响，必要时采用分区或采样策略。
八、小结
嵌入式覆盖率测试的全景图可以概括为一句话：单元层把逻辑测透，集成层把交互测通，系统层把需求测全，三层通过缺口传递与分层门禁形成闭环。覆盖率的价值不在于某个漂亮的百分比，而在于它能持续指出“哪里还没测到”，并驱动测试设计不断补强。
下一篇将进入实战环节，介绍如何在 CI 流水线中自动采集三层覆盖率并生成可视化报告，敬请期待。
