1. 嵌入式测试全景概览

各位同学，咱们直接进入正题。嵌入式测试这个领域，说实话，比纯软件测试要「麻烦」得多。我做了十几年嵌入式测试，踩过的坑比代码行数还多。今天这一章，咱们先把全景图铺开，看看这个行业到底在干什么，难点在哪。

1.1 行业现状：为什么嵌入式测试越来越「卷」？

先看几个数字。根据 2023 年的行业报告，消费电子、汽车电子、工业控制三个领域占了嵌入式测试需求的 70% 以上。尤其是汽车，现在一辆车里有上百个 ECU（电子控制单元），每个都要做严格的测试。

为什么会这样？说白了，三个字：安全。你手机死机了可以重启，但刹车系统的 MCU 死机了，那就是人命关天的事。所以 ISO 26262（汽车功能安全标准）直接规定：ASIL-D 等级的系统，测试覆盖率必须达到 100%。

我前几年参与过一个车载项目，客户要求 MC/DC 覆盖率达到 100%。当时团队里有人觉得「差不多就行了」，结果评审时被第三方审计直接打回。嗯，从那以后我再也不敢在覆盖率上打折扣了。

领域	典型产品	安全等级	测试重点
消费电子	智能手表、路由器	低	功能、功耗、稳定性
汽车电子	ECU、ADAS 控制器	高（ASIL-B~D）	功能安全、实时性、故障注入
工业控制	PLC、伺服驱动器	中高	可靠性、确定性、长期稳定性
医疗设备	输液泵、监护仪	极高	精度、冗余、故障容错

1.2 测试金字塔模型：嵌入式版长什么样？

软件测试有个经典的金字塔模型——单元测试、集成测试、系统测试。但嵌入式领域，这个金字塔得「加层」。

你想想看，纯软件测试不需要管硬件，但嵌入式不行。你的代码最终要跑在特定的 MCU 上，要跟传感器、执行器打交道。所以嵌入式测试金字塔，我习惯把它分成五层：

1. 单元测试（UT）——测单个函数/模块，在 PC 上跑，用 Cmock/CUnit 等框架。
2. 集成测试（IT）——测模块间接口，可以在模拟器或开发板上跑。
3. 系统测试（ST）——测完整功能，必须在目标硬件上跑。
4. 硬件在环测试（HIL）——把真实 ECU 接入仿真环境，测边界条件。
5. 现场测试（Field Test）——在实际使用环境中跑，测长期稳定性。

这里有个关键点：越往下层，测试成本越低，发现问题越早。我在项目中见过太多人，跳过单元测试直接做系统测试，结果一个 bug 定位花了两周。你想想看，如果单元测试时就能发现，可能只需要两小时。

1.3 嵌入式测试的特殊挑战

好，现在咱们聊聊最核心的问题：嵌入式测试到底难在哪？我总结了三个关键词：资源受限、实时性要求、硬件依赖。

1.3.1 资源受限：内存只有 64KB，怎么跑测试？

你写个 Python 脚本，内存占用几百 MB 无所谓。但在嵌入式世界，MCU 的内存可能只有 64KB，Flash 只有 256KB。你连个完整的测试框架都塞不进去。

我遇到过最极端的情况：一个基于 Cortex-M0 的传感器节点，RAM 只有 16KB。我们想在上面跑单元测试，结果光是 printf 的缓冲区就占了 2KB。最后怎么办？只能用「桩函数 + 串口输出」的方式，把测试结果通过一个字节一个字节地吐出来。

1.3.2 实时性要求：错过 deadline，就是事故

嵌入式系统通常有严格的实时性要求。比如一个电机控制算法，必须在 100μs 内完成计算并输出 PWM 信号。如果你在测试时插入了额外的日志打印，或者测试框架本身占用了 CPU 时间，就会导致时序错乱。

我记得有一次，我们在测试一个 CAN 总线通信模块。测试代码里加了一行 printf，结果导致报文发送延迟了 50μs，整个通信链路都乱了。排查了两天才发现是测试代码本身的问题。

所以，嵌入式测试的一个核心原则是：测试行为不能改变被测系统的实时行为。这听起来简单，做起来很难。

实时性等级	典型场景	允许延迟	测试注意事项
硬实时	安全气囊、刹车控制	< 1ms	禁止任何侵入式测试
软实时	多媒体播放、人机交互	< 100ms	可接受少量延迟，但需记录
非实时	数据采集、日志记录	无严格限制	可做较全面的测试

1.3.3 硬件依赖：没有硬件，怎么测？

这是嵌入式测试最大的痛点。纯软件测试可以在任何一台 PC 上跑，但嵌入式测试往往需要特定的开发板、调试器、甚至专用测试设备（比如 CAN 分析仪、信号发生器）。

硬件依赖带来的问题有三个：

• 并行度低——硬件有限，测试只能排队跑。
• 环境不稳定——硬件可能损坏、连接可能松动。
• 难以自动化——很多硬件操作需要手动干预。

我个人的经验是：能模拟的尽量模拟，不能模拟的才上硬件。比如用 QEMU 模拟 Cortex-M 系列 MCU，可以跑大部分逻辑测试。只有涉及外设（如 ADC、PWM）的测试，才需要真实硬件。