📚 课程目录第1章集成测试概述

1. 集成测试概述

各位同学，咱们这门课叫《嵌入式软件集成测试桩函数设计与调用调试实战》。开篇第一章，我不打算直接扔概念，而是先聊聊——集成测试到底是什么，它跟单元测试有啥区别，以及为什么在嵌入式开发里，这步几乎决定了你的项目能不能按时交付。

我做了十几年嵌入式，见过太多团队在单元测试上花了大把时间，结果一联调就崩。说白了，单元测试保证的是“每个零件没问题”，集成测试保证的是“零件装在一起还能转”。后者往往才是真正的噩梦。

集成测试，就是把已经通过单元测试的模块，按照系统设计逐步组合起来，验证它们之间的接口、交互、数据传递是否符合预期。

举个例子。你写了一个温度采集模块和一个风扇控制模块。单测时各自跑得挺好。但把它们拼在一起，温度采集每 100ms 上报一次，风扇控制却按 500ms 周期查询——数据对不上，风扇该转时不转。这就是集成测试要抓的问题。

核心观点：集成测试关注的是模块间的“缝隙”，而不是模块内部。缝隙里藏着时序错乱、数据格式不匹配、资源竞争、状态机跑飞……这些在单测里几乎测不出来。

我个人习惯把集成测试分成几个层次：

你想想看，如果一上来就把几十个模块全怼在一起，出了问题你根本不知道从哪查。所以分层、分批、逐步集成，是嵌入式集成测试的铁律。

很多刚入行的工程师容易混淆这两个概念。我直接画个对比表，一目了然。

我记得有一次，团队里一个同事信誓旦旦说所有模块单测都过了。结果集成测试第一天，系统跑起来不到 3 分钟就死机。查了两天，发现是两个模块共用一个全局缓冲区，一个写一个读，没有互斥保护。单测时各自独立跑，根本不会触发竞争条件。这就是典型的集成测试才能暴露的问题。

避坑指南：千万不要以为单测覆盖率 100% 就万事大吉。我曾经在一个项目中吃过这个亏——单测覆盖率 95%，集成测试阶段依然发现了 40+ 个接口级缺陷。单测和集成测试是互补关系，不是替代关系。

嵌入式开发和纯软件有个巨大区别：硬件是活的。你的代码最终要跑在真实的 MCU、传感器、执行器上。硬件有延迟、有噪声、有资源限制，这些在 Host 侧的单测环境里根本模拟不出来。

我总结了几点，为什么嵌入式开发尤其离不开集成测试：

硬件依赖：很多模块直接操作寄存器、外设、中断。单测时可以用桩函数模拟，但真实硬件的行为和模拟器总有差异。集成测试是第一次让代码和真实硬件“对话”。
实时性约束：嵌入式系统对时序敏感。任务调度、中断响应、DMA 传输，这些在单测里几乎无法验证。只有把模块集成到真实调度框架下，才能发现是否超时、是否丢数据。
资源竞争：共享内存、全局变量、外设独占访问。单测时每个模块独占资源，集成后多个模块同时访问，死锁、数据污染就来了。
接口多样性：嵌入式模块间的接口五花八门——函数调用、消息队列、共享缓冲区、硬件信号线。每种接口的集成测试方法都不一样。

我的经验：在项目计划阶段，我通常建议把集成测试的时间至少留出总开发周期的 30%。别觉得多，等你真正开始联调就会发现，这个比例一点都不夸张。尤其是第一次做硬件联调，各种意想不到的问题会排队来找你。

下面这张图，是我自己总结的嵌入式集成测试在整个开发流程中的位置。你可以看到，它正好卡在单元测试和系统测试之间，起到承上启下的作用。

嗯，这里要注意一点。很多团队在集成测试阶段才引入桩函数，其实已经晚了。我建议在单元测试阶段就把桩函数的框架搭好，集成测试时直接复用或扩展。这样能省下大量重复造轮子的时间。

最后说一句掏心窝的话。嵌入式开发里，集成测试不是“可选项”，而是“必选项”。你可以在单元测试上偷懒，但集成测试绝对不能省。因为硬件不会撒谎，接口不会妥协。所有你在设计阶段忽略的细节，都会在集成测试阶段加倍奉还。