集成测试基础概念：单元测试 vs 集成测试 vs 系统测试
做嵌入式开发这些年，我见过太多团队把测试想得太简单了。有人觉得「代码能跑就行」，有人把所有测试都扔给QA。结果呢？产品在客户现场死机，查了三天才发现是模块间接口没对齐。
今天咱们就把测试分层这件事彻底聊透。你想想看，一个嵌入式系统从代码到产品，中间要经历多少层验证？
测试金字塔：嵌入式版的「三层架构」
经典的测试金字塔长这样：底层是单元测试，中间是集成测试，顶层是系统测试。但在嵌入式领域，这个金字塔得稍微调整一下——因为多了硬件这个变量。
嵌入式测试金字塔核心原则：
- 底层：单元测试（函数/模块级，纯软件）
- 中层：集成测试（接口/协议/模块间交互）
- 顶层：系统测试（整机/场景/用户视角）
我习惯把集成测试叫做「胶水层」。为什么？因为它是把零散的单元粘成完整系统的关键步骤。很多Bug就藏在这些「胶水」里。
三种测试到底有什么区别？
咱们直接上对比表，这样最清楚。
| 维度 | 单元测试 | 集成测试 | 系统测试 |
|---|---|---|---|
| 测试对象 | 单个函数/模块 | 模块间接口/协议 | 完整系统 |
| 运行环境 | PC/模拟器 | 开发板+部分外设 | 目标硬件+真实外设 |
| 发现问题 | 逻辑错误、边界条件 | 接口不匹配、时序问题 | 功能缺失、性能瓶颈 |
| 执行速度 | 毫秒级 | 秒级 | 分钟~小时级 |
| 调试难度 | 低（可单步） | 中（需抓协议） | 高（问题难复现） |
| 自动化程度 | 高 | 中 | 低 |
我的经验：很多团队在单元测试上花了大功夫，集成测试却草草了事。结果呢？单元测试覆盖率90%，系统测试也过了，但产品一联网就死机。为什么？因为网络协议栈和业务模块之间的接口根本没测透。
嵌入式集成测试的特殊性
做互联网软件的同事经常不理解：为什么嵌入式集成测试这么麻烦？说白了，因为我们要跟硬件打交道。
我遇到过最典型的一个坑：某个传感器驱动模块单独测试全过，业务逻辑模块也全过。但两个模块一集成，数据就错位。查了两天才发现——驱动模块用的是大端字节序，业务模块默认小端。这种问题，单元测试根本发现不了。
嵌入式集成测试的三大挑战
- 硬件依赖：很多接口必须跑在真实硬件上，模拟器模拟不了时序
- 资源受限：MCU上跑不了完整的测试框架，内存不够
- 实时性要求：接口交互有严格的时间窗口，错过就丢数据
避坑指南：我曾经在一个项目中，为了省事把所有集成测试都放在系统测试阶段做。结果呢？每次改完代码要等2小时才能跑完一轮测试。后来老老实实把集成测试独立出来，半小时就能发现问题。记住——集成测试越早做，成本越低。
测试策略怎么选？
不是所有项目都适合「金字塔」模型。我根据项目类型给个参考：
| 项目类型 | 推荐策略 | 集成测试占比 |
|---|---|---|
| 安全关键系统（汽车/医疗） | 全层级覆盖，集成测试重点 | 40% |
| 消费电子（智能家居） | 单元测试打底，集成测试聚焦核心接口 | 30% |
| 原型验证（概念机） | 系统测试为主，集成测试只测关键路径 | 15% |
| 物联网终端（低功耗） | 集成测试重点在通信协议和电源管理 | 35% |
一个真实的案例
去年我做的一个车载T-Box项目，团队一开始只做单元测试和系统测试。结果系统测试阶段，每次跑完都要花3天定位问题。后来我强制要求加入集成测试层，专门测CAN总线协议栈和业务逻辑的接口。
改动之后，系统测试阶段的Bug数下降了60%。为什么？因为集成测试把接口问题提前暴露了。你想想看，在系统测试阶段发现一个CAN报文解析错误，你得抓总线日志、分析协议、定位代码，至少半天。但在集成测试阶段，写个测试用例模拟CAN帧，5分钟就能发现问题。
核心结论：
- 单元测试保证「每个零件没问题」
- 集成测试保证「零件能装到一起」
- 系统测试保证「装好的机器能干活」
- 嵌入式领域，集成测试是投入产出比最高的环节