1. 课程导论与系统全景

各位同学好，我是老张。在嵌入式这一行摸爬滚打了十几年，从最早的8位单片机做到现在的多核SoC，踩过的坑比吃过的盐还多。今天咱们开始这门课，第一讲先聊聊全景——嵌入式测试到底难在哪？覆盖率分析能帮我们解决什么？故障定位为什么让人头秃？

说实话，我见过太多项目在测试阶段翻车了。有一次，一个车载ECU项目，功能测试全过了，结果路试的时候偶发死机。团队花了三周才定位到问题——一个中断优先级配置错误，触发概率不到千分之一。你说这种bug，靠传统测试能发现吗？

1.1 嵌入式测试的三大痛点

先说说我这些年总结的痛点。你想想看，嵌入式开发和纯软件不一样，硬件环境、实时性、资源限制，每个都是拦路虎。

痛点	具体表现	我踩过的坑
环境依赖强	测试必须依赖真实硬件或高保真仿真器，部署成本高	曾经一个项目等FPGA板子等了两个月，测试进度全卡住
实时性约束	时序敏感，插桩或打日志可能改变行为	我在某RTOS内核测试时，加了一行printf，任务调度就乱了
资源极度受限	RAM/Flash以KB计，跑不了大型测试框架	有个MCU只有4KB RAM，连个简单的断言库都塞不进去

说白了，嵌入式测试不是不想做，是很多时候“做不到”或者“做不起”。我记得2018年给一家工控企业做咨询，他们的测试用例跑一遍要8小时，而且只能在凌晨没人用设备的时候跑。这种效率，怎么可能做充分测试？

1.2 覆盖率分析的价值

覆盖率分析是什么？简单说，就是回答一个问题：“我的测试到底测了哪些代码？”

我个人习惯把覆盖率分成三个层次：

1. 基础层（语句/分支覆盖）——保证每行代码都执行过，每个if-else都走过
2. 进阶层（MC/DC覆盖）——验证每个条件独立影响结果，航空级标准
3. 系统层（函数调用/状态覆盖）——关注模块间交互和状态机跳转

覆盖率分析最大的价值在于——它能告诉你“哪里没测到”。有一次我接手一个遗留项目，功能测试通过率95%，但覆盖率分析一跑，发现有一个异常处理分支从来没执行过。后来模拟了那个异常场景，果然崩溃了。你想想看，如果没有覆盖率数据，这个bug可能永远发现不了。

1.3 故障定位的挑战

故障定位，说白了就是“找凶手”。嵌入式系统的故障定位为什么难？

• 复现难：很多bug是偶发的，跟温度、电压、时序都有关系
• 信息少：设备死机了，连日志都来不及打
• 干扰大：硬件噪声、外设干扰，可能根本不是软件问题

我记得有一次调试一个电机驱动板，现象是运行几分钟后随机停转。我用了示波器、逻辑分析仪、JTAG调试器，折腾了一周。最后发现是电源纹波过大，导致ADC采样偶尔跳变，触发了过流保护。这种问题，光靠看代码是看不出来的。

1.4 本课程的知识体系全景

这门课一共30章，我把它分成四个阶段。下面这张图可以帮你建立全局视角：

1.5 学习路线图

这门课的设计思路是“从工具到方法，从方法到系统”。我建议你按这个节奏来：

• 第1-8章：打好基础。理解覆盖率的概念，搭建好工具链。这部分我会带着你手写一个轻量级插桩工具。
• 第9-16章：深入覆盖率分析。从语句覆盖做到MC/DC，每个级别都有真实项目案例。
• 第17-24章：学习故障定位。我会分享几个“压箱底”的定位技巧，比如基于硬件断点的逆向追踪。
• 第25-30章：综合实战。把前面学的东西整合到一个完整的CI/CD流水线中。