单元测试：固件质量的底座

借助测试脚手架（Test Harness）与桩/模拟（Stubs & Mocks）创建受控的虚拟环境，在宿主机上完成大部分与硬件无关的测试，是嵌入式测试金字塔的基础。这要求架构上把依赖硬件的代码隔离在硬件抽象层之后，以便对抽象进行模拟。

集成测试：把模块连接起来

• 自底向上集成：从最底层模块开始逐层向上验证。
• 自顶向下集成：从顶层控制逻辑开始，逐步接入下层实现。

系统与回归测试：最后关卡

系统测试通常在完全集成的硬件与固件上以黑盒方式开展；回归测试则用于确保新变更不破坏既有功能，自动化的回归套件在嵌入式团队中属于必需品而非可选项。

用 CI 与 HIL 实现自动化

使用 Jenkins 或 GitLab CI 搭建的流水线成为开发过程的心跳：每次提交自动触发构建并运行单元测试，把反馈环压缩到分钟级。但单元测试只验证隔离状态下的逻辑，真正的试金石是硬件在环（HIL）测试——把真实的嵌入式控制器连接到模拟整个外部世界的测试台，由测试台伪造传感器信号、按键、电机负载与网络流量。

可测试性设计（DFT）

• 硬件级：专用编程/调试接口、可访问的测试点、作为生命线的 UART、内置电压电流检测。
• 固件级：健壮的日志框架、命令行接口（CLI）、制造测试固件、故障注入钩子。

超越代码覆盖率

压力测试与浸泡测试用于暴露长时间运行下的资源泄漏与性能衰减；故障注入测试验证异常输入下的鲁棒性。需要清醒认识的是：代码覆盖率是必要条件而非充分条件，达到覆盖率目标并不等于系统可靠。