1. 集成测试基础：定义、目的与原则

各位同学，咱们正式开始这门课。第一讲，先把集成测试的底子打牢。

很多人一上来就问我：“集成测试到底测什么？跟单元测试有啥区别？” 嗯，这个问题问得好。我做了十几年嵌入式，见过太多项目在集成阶段翻车。说白了，集成测试就是检查你各个模块拼在一起后，能不能好好协作。

1.1 集成测试的定义

集成测试，也叫组装测试或联合测试。它是在单元测试之后，系统测试之前的一个关键环节。

官方定义是这样的：集成测试是将已通过单元测试的模块，按照设计策略逐步组装起来，验证模块间的接口、交互和协作是否符合设计要求的过程。

我个人习惯把它比作“拼乐高”。每个零件（模块）单独看都没问题，但拼在一起时，接口对不上、齿轮卡不住、供电不够用——这些就是集成测试要抓的问题。

1.2 集成测试的目的

为什么要做集成测试？我直接说几个真实场景：

• 接口错误：A模块发数据，B模块收不到。我在一个车载项目中遇到过，CAN总线报文ID定义不一致，两个ECU互相不理睬。
• 数据丢失或损坏：模块间传递的数据结构不匹配，或者字节序搞反了。
• 时序问题：A模块还没准备好，B模块就开始读数据。这种问题在实时系统中特别常见。
• 资源冲突：两个模块同时抢同一个外设、同一块内存。
• 全局数据影响：一个模块改了全局变量，另一个模块莫名其妙就崩了。

集成测试的目的，就是把这些“连接处”的问题提前暴露出来。你想想看，如果等到系统测试再发现，定位问题要花多少时间？我曾经有个项目，集成测试阶段漏了一个SPI时序问题，结果系统测试花了三周才定位到——那滋味，真不好受。

1.3 集成测试的原则

做集成测试，有几个原则我建议你刻在脑子里：

1. 尽早集成，持续集成。别等到所有模块都写完了再开始集成。我习惯每周至少做一次全量集成测试。
2. 接口优先。先保证接口通，再验证功能对。接口不通，后面全是白搭。
3. 增量集成。一次只加一个或少数几个模块，出了问题好定位。
4. 回归测试。每加入一个新模块，之前已经通过的集成测试用例要重新跑一遍。
5. 环境一致性。集成测试环境要尽量贴近目标硬件环境。别在开发板上跑得欢，一上真机就挂。

1.4 与单元测试、系统测试的区别

很多新手分不清这三者的界限。我画个表格，一目了然：

维度	单元测试	集成测试	系统测试
测试对象	单个函数/模块	模块间的接口与交互	完整系统
测试目标	内部逻辑正确性	接口与协作正确性	需求符合性
测试环境	开发环境/模拟器	目标硬件或等效硬件	真实目标环境
测试人员	开发工程师	开发+测试工程师	测试工程师
发现的问题	逻辑错误、边界条件	接口不匹配、数据损坏、时序问题	功能缺失、性能不达标、稳定性
测试粒度	细粒度（白盒）	中粒度（灰盒）	粗粒度（黑盒）

说白了：

• 单元测试：检查每个零件本身有没有瑕疵。
• 集成测试：检查零件拼在一起时，接口能不能对上。
• 系统测试：检查整台机器能不能满足用户需求。

举个例子。你写了一个温度传感器驱动（模块A）和一个LCD显示模块（模块B）。单元测试分别验证它们各自功能正常。集成测试要验证：A把温度数据通过I2C发给B，B能正确解析并显示。系统测试则要验证：整个设备在高温环境下，显示是否稳定、刷新率是否达标。

1.5 集成测试的知识体系

下面这张图，把集成测试在整个嵌入式测试体系中的位置和核心要素串起来了。我建议你保存下来，后面每学一章都可以回来对照看看。

这张图把集成测试的定位、核心要素和常见策略都串起来了。后面我们会逐一展开讲每种策略的优缺点和适用场景。

1.6 一个真实案例

最后，我分享一个亲身经历。有个智能家居项目，网关模块和Zigbee子设备模块分别由两个团队开发。单元测试各自都过了。集成测试时，我发现子设备上报数据时，网关偶尔会丢包。

排查过程是这样的：

• 先检查物理层：信号强度正常。
• 再查协议层：报文格式正确。
• 最后抓时序：发现子设备在网关处理上一帧数据的中途，连续发送了多帧数据，网关的接收缓冲区溢出了。

解决方案很简单：在网关侧增加一个接收队列，并实现流控机制。但如果没有集成测试，这个问题到系统测试阶段才会暴露，到时候定位难度会大得多。