1. 课程导论：为什么可测试性设计是嵌入式架构的基石？
从一次惨痛的线上故障说起
几年前，我参与过一个智能电表项目。设备已经量产了十几万台，部署在全国好几个省份。某个深夜，运维突然报警——大批电表在凌晨两点同时重启，导致后台采集系统大面积掉线。
排查过程简直是一场噩梦。现场工程师反馈：电表确实重启了，但日志里只有一条「Watchdog Reset」记录。没有上下文，没有堆栈，没有触发前的状态快照。我远程连上去，发现设备已经恢复正常，就像什么都没发生过。
为什么会这样？说白了，我们当时根本没为「事后分析」留任何后路。代码里到处都是全局变量，模块之间互相调用，一个定时器回调改了另一个模块的内部状态。出了问题，你根本不知道从哪里查起。
那次故障持续了整整两周。最后我们不得不派人去现场，用 JTAG 挂住设备，等它复现。你想想看，十几万台设备，靠人工蹲守，这成本有多高？
什么是 DFT（Design for Testability）？
DFT 不是测试方法，而是设计方法。它要求你在写代码的时候，就为未来的测试、调试、故障定位预留好接口和观测点。
我个人的理解很简单：可测试性设计，就是让软件变得「可问、可控、可追溯」。
- 可问：运行时能随时读出关键变量的值，而不是只能看日志。
- 可控：能通过外部命令改变模块的行为，比如强制进入某个分支。
- 可追溯：出问题后，能回放故障发生前的关键事件序列。
举个例子。那次电表故障之后，我们在代码里加了一个「状态快照」模块。每次进入临界区之前，自动把关键变量、任务栈水位、外设寄存器全部 dump 到一块专用的 RAM 区域。下次再出问题，哪怕设备重启了，我们也能通过串口把快照读出来。
嵌入式软件为什么尤其需要 DFT？
做上层应用开发的同事可能不理解——他们出 bug 了，打个 log，重启一下，看堆栈，基本就能定位。但嵌入式软件不一样。
| 特点 | 带来的测试困境 |
|---|---|
| 资源受限 | 没有足够的 RAM 存详细日志，没有文件系统写 dump |
| 实时性要求 | 不能随便打断任务执行来插桩，否则时序就变了 |
| 硬件耦合 | 很多 bug 只在特定硬件条件下复现，比如电源波动、电磁干扰 |
| 现场不可达 | 设备部署在偏远地区、高压柜里、甚至卫星上，你没法连 JTAG |
我做过一个车载项目，客户要求「故障复现率必须达到 100%」。什么意思？就是任何偶发故障，必须能在实验室里稳定复现，否则不给验收。你想想看，没有 DFT，偶发故障就像鬼魂一样，你永远不知道它什么时候出现，也永远没法证明它不存在。
DFT 与分层架构、低耦合的关系
很多人以为 DFT 就是加几个测试点、插几行日志。其实不是。真正的 DFT 要从架构层面入手。
我习惯把嵌入式软件分成三层：
- 硬件抽象层（HAL）：封装所有硬件寄存器操作，提供统一的接口。
- 业务逻辑层：实现具体的功能，比如协议解析、算法计算。
- 测试支撑层：提供桩、模拟器、状态观测器、命令注入接口。
这三层之间，必须通过接口通信，而不是直接调用。为什么？因为只有接口才能被替换、被模拟、被拦截。
举个例子。你的业务逻辑里调用了 ADC_Read()，如果这个函数直接操作寄存器，那你在测试时就只能接真实硬件。但如果它调用的是 HAL 层的 HAL_ADC_Read()，而 HAL 层又允许你注册一个模拟函数——那你在单元测试时，就可以让 HAL_ADC_Read() 返回任意值，测试各种边界情况。
DFT 带来的长期收益
有人会问：加这么多接口、桩、观测点，代码量至少增加 20%，值得吗？
我算过一笔账。一个典型的嵌入式项目，开发周期大概 6 个月，其中调试和测试占了 3 个月。如果前期投入 2 周做 DFT 设计，调试阶段至少能省下 1 个月。而且，产品上市后的现场故障率，能降低 60% 以上。
说白了，DFT 不是成本，是投资。你前期多花一点心思，后期就能少熬几个通宵。
本章知识结构
下面这张图，概括了 DFT 在嵌入式架构中的核心位置和作用路径：
从这张图可以看出，DFT 不是孤立的技巧，它需要架构层面的支撑。而分层架构和低耦合设计，正是实现 DFT 的基础设施。没有接口隔离，你就没法替换底层实现；没有低耦合，你就没法单独测试一个模块。
避坑指南
我曾经犯过一个典型的错误。在一个传感器项目中，我觉得「先快速出功能，测试后面再补」。结果功能写完了，发现代码耦合得一塌糊涂——一个函数改了全局变量，另一个函数又依赖这个全局变量，根本没法单独测。最后只能重写，工期翻了一倍。
所以我的建议是：从项目第一天就把 DFT 写进架构设计文档里。哪怕你只花半天时间，把接口定义清楚，把模块边界画出来，后面都会省很多事。
嗯，这一章就到这里。记住：DFT 不是可选项，是嵌入式软件的生存之道。