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

第一章集成测试概述：为什么我们需要它？

大家好，我是老周。做嵌入式这行快十五年了，带过不少项目，也踩过数不清的坑。今天咱们聊聊集成测试——这个听起来有点“中间层”的概念，其实恰恰是决定项目成败的关键一环。

很多人觉得，单元测试跑通了，系统测试再验证一下，中间这层集成测试是不是有点多余？我告诉你，真不是。我见过太多项目，单元测试绿油油一片，系统测试一跑就崩。问题出在哪？就出在模块之间的“接口”上。

核心观点：集成测试不是单元测试的“升级版”，也不是系统测试的“简化版”。它专门解决模块间交互的问题——数据传没传对、时序对不对、资源争不争抢。

说白了，集成测试就是把已经通过单元测试的模块，按照设计把它们组装起来，然后验证它们能不能协同工作。

举个例子。你写了一个温度采集模块，一个PID控制模块，还有一个PWM输出模块。单测时每个模块都正常。但把它们连起来呢？温度数据格式对不对？PID计算周期和采集周期匹配吗？PWM占空比更新会不会被中断打断？这些，就是集成测试要回答的问题。

我个人习惯把集成测试分成两类：

我的经验：在汽车电子项目中，我们通常采用“自底向上”的增量集成。先测底层驱动，再测中间件，最后测应用层。每层都稳了，再往上走。这样出问题，范围可控。

你想想看，单元测试只能保证单个函数或模块的行为正确。但模块之间的“契约”——接口协议、数据格式、时序约束——单测是覆盖不到的。

我曾经在一个BMS（电池管理系统）项目中吃过亏。单体电压采集模块和均衡控制模块各自单测都过了。结果联调时发现，均衡模块读到的电压值总是滞后两帧。为什么？因为采集模块用了DMA双缓冲，而均衡模块直接读寄存器，没等数据更新。这种问题，单测根本发现不了。

集成测试的价值，我总结了几点：

价值点	说明
接口验证	检查模块间的数据格式、协议、时序是否一致
资源冲突检测	发现共享资源（全局变量、外设、中断）的竞争问题
集成缺陷提前暴露	越早发现，修复成本越低。集成测试阶段发现的bug，比系统测试阶段少花5-10倍成本
为系统测试铺路	确保子系统稳定，系统测试才能聚焦在业务场景上

避坑指南：我曾经见过一个团队，集成测试只测“正常路径”，结果现场运行时，模块A发了一个异常长度的数据包，模块B直接死机。所以，集成测试一定要覆盖异常接口场景——数据超长、超时、重复发送、错误校验码等。

很多新手容易混淆这两个概念。我画个对比表，一目了然：

嗯，这里要注意一点：单元测试的桩函数，和集成测试的驱动桩，虽然都叫“桩”，但目的完全不同。单元测试的桩是为了隔离，集成测试的桩是为了模拟真实交互。这个区别，后面章节我会详细展开。

V模型是嵌入式开发最经典的流程模型。集成测试在V模型的右半边，对应左半边的“概要设计”。

我画了一张图，帮你理解这个对应关系：

从图上你能看到，集成测试在V模型的右臂，对应左臂的“概要设计”阶段。这意味着什么？意味着你在做概要设计时，就应该开始设计集成测试用例了。不是等代码写完了再想怎么测，而是设计时就规划好接口怎么验证。

我个人的做法是：在概要设计评审时，同步评审集成测试方案。接口定义、数据流图、时序图，这些文档一出来，我就开始写集成测试的桩函数框架。等代码写完，桩函数也差不多就绪了，直接开测。

经验之谈：V模型不是死板的瀑布流程。在实际项目中，我经常在详细设计阶段就启动部分集成测试——比如底层驱动和OS的集成。早测早发现问题，别等到所有模块都开发完再动手。

集成测试不是什么高深的技术，但它是一个“承上启下”的关键环节。没有它，单元测试和系统测试之间就存在一个“接口盲区”。

记住三个要点：

第一章 集成测试概述：为什么我们需要它？