📚 课程目录第1章嵌入式测试概述

一、嵌入式测试概述

先聊聊嵌入式系统的定义。说白了，嵌入式系统就是「专用于特定任务的计算机系统」。它不像你的台式机或笔记本那样通用，而是被「嵌入」到某个设备里，只干一件事。

我这些年接触过的嵌入式系统，从智能手环到汽车ECU，从路由器到医疗监护仪，本质上都是：CPU + 存储器 + 外设接口 + 专门软件，打包成一个完成特定功能的黑盒子。

嵌入式系统的三个核心特征：

举个例子。你家里的智能电饭煲，里面那颗芯片可能只有几KB的RAM，跑着精简过的RTOS。它不会去运行Office，也不会刷网页。它只做一件事：检测温度、控制加热、定时煮饭。这就是嵌入式。

做嵌入式测试和做纯软件测试，完全是两码事。我刚开始转做嵌入式测试时，就踩过不少坑。

第一个特点：软硬件耦合。 你测的不只是代码，而是代码跑在特定硬件上的表现。同样的代码，换一颗晶振、换一个批次的Flash芯片，行为可能就不一样了。我记得有一次，一个UART通信模块在开发板上跑得好好的，量产时却频繁丢包。查了两周，最后发现是PCB走线导致的信号串扰。

第二个特点：资源受限。 嵌入式设备的内存和CPU都很金贵。你在PC上跑个测试用例，malloc几MB内存无所谓。但在嵌入式设备上，一个内存泄漏就能让系统在运行72小时后死机。这种问题，靠常规的功能测试根本发现不了。

第三个特点：实时性。 很多嵌入式系统有严格的时间约束。比如汽车的安全气囊控制器，从碰撞传感器触发到气囊弹出，必须在几毫秒内完成。测试时不仅要验证功能正确，还要验证时序正确。

避坑指南： 我曾经犯过一个低级错误——在开发板上做完了所有测试，就以为产品没问题了。结果小批量试产时，有30%的设备在低温环境下启动失败。原因是开发板的电源芯片和量产用的不是同一型号，低温下启动时序有差异。从那以后，我坚持在最终量产硬件上做一轮完整的系统测试。

嵌入式开发流程，通常遵循V模型。我画了一张图，帮你直观理解测试在整个开发周期中的位置。

从这张图你能看到，测试不是编码完成后的「收尾工作」。它贯穿整个开发周期。每个开发阶段，都有对应的测试阶段。

需求分析阶段——测试人员就要介入，评审需求的可测试性。我见过太多需求写得模棱两可，比如「系统响应要快」。多快？1ms还是100ms？这种需求到了验收阶段根本没法测。
系统设计阶段——制定测试策略和测试计划。确定测什么、怎么测、用什么工具、资源怎么分配。
编码实现阶段——开发人员做单元测试。我个人习惯在提交代码前，先跑一遍单元测试用例，确保基本功能没问题。
集成测试阶段——把各个模块拼起来测。这里最容易出问题，因为模块间的接口约定往往有偏差。
系统测试阶段——在目标硬件上做全功能测试、性能测试、压力测试、可靠性测试。
验收测试阶段——交给客户或第三方做确认测试，验证是否满足需求规格。

我的经验： 很多团队把测试压缩到项目后期，结果就是「测试周期不够，产品带病上线」。我建议测试活动至少占整个项目周期的30%~40%。尤其是嵌入式产品，硬件改版成本高，问题发现得越晚，修复代价越大。

为了更清晰地理解测试范围，我把嵌入式测试分成四个层次。你想想看，这就像盖房子——先测砖头（单元），再测房间（模块集成），然后测整栋楼（系统），最后测住户体验（验收）。

测试层次	测试对象	典型工具/方法	常见问题
单元测试	单个函数、模块	CUnit、Unity、CMock	边界条件、分支覆盖、内存越界
集成测试	模块间接口、协议栈	打桩、模拟器、协议分析仪	接口不匹配、时序冲突、数据错位
系统测试	完整软硬件系统	自动化测试框架、HIL（硬件在环）	资源竞争、功耗异常、电磁干扰
验收测试	最终产品	场景测试、长时间运行、环境试验	需求遗漏、用户体验差、合规问题

嗯，这里要注意：这四个层次不是做完一个再做下一个。实际项目中，它们是并行或迭代进行的。比如我在做系统测试时发现了一个bug，定位到是某个模块的问题，就会回到单元测试层面，补充对应的测试用例，修复后再回归。

嵌入式测试不是简单的「点点点」。它要求你既懂硬件，又懂软件，还要有系统思维。这一章我们聊了：