3. 集成测试策略：大爆炸、自顶向下、自底向上、三明治

集成测试策略，说白了就是决定「先拼哪块、怎么拼」的战术。我见过不少团队，单元测试写得漂漂亮亮，一到集成阶段就乱成一锅粥——要么等所有模块都写好才动手，要么集成完了发现根本跑不起来。今天咱们就把四种主流策略掰开揉碎，看看它们各自适合什么场景。

3.1 大爆炸集成（Big Bang Integration）

把所有模块一次性拼起来，然后通电测试。听起来很痛快，对吧？

做法：等所有单元都开发完，一次性连接所有模块，开始跑集成测试。

优点：

• 管理简单，适合小项目
• 不需要写桩代码，省前期功夫
• 能快速看到系统全貌

缺点：

• 定位问题极难——你根本不知道是A模块的锅还是B模块的锅
• 关键接口缺陷发现得晚
• 返工成本高

适用场景：模块数少于5个、团队规模小、或者原型验证阶段。大项目千万别碰。

3.2 自顶向下集成（Top-Down Integration）

从主控模块开始，一层层往下集成。主模块先写好，下层模块用桩（Stub）代替。

步骤：

1. 先测试顶层主控模块
2. 用桩代替下层模块，验证接口
3. 逐步替换桩为真实模块
4. 每替换一层，就跑一遍回归

优点：

• 早期就能验证系统架构和主流程
• 关键决策路径先得到验证
• 桩代码相对好写（只需模拟返回值）

缺点：

• 底层模块的交互细节容易被忽略
• 桩写多了，测试可能失真
• 底层模块的I/O、中断等真实行为难以模拟

3.3 自底向上集成（Bottom-Up Integration）

从最底层模块开始，逐层向上集成。底层模块先测，上层用驱动（Driver）模拟。

步骤：

1. 先测试底层驱动、硬件抽象层
2. 用Driver调用底层模块，验证功能
3. 逐层向上，替换Driver为真实模块
4. 每层集成后做回归

优点：

• 底层模块的I/O、中断、时序能充分验证
• 关键硬件接口先得到保障
• Driver比Stub更容易写（只需调用接口）

缺点：

• 系统整体架构验证得晚
• 顶层模块的交互问题最后才发现
• Driver写多了也费功夫

3.4 三明治集成（Sandwich Integration）

把自顶向下和自底向上结合起来。你想想看，为什么非要二选一？

做法：将系统分为三层——顶层（控制层）、中间层（业务逻辑层）、底层（硬件抽象层）。顶层用自顶向下，底层用自底向上，中间层作为「会师层」。

步骤：

1. 底层模块自底向上集成到中间层接口
2. 顶层模块自顶向下集成到中间层接口
3. 中间层作为枢纽，连接上下两部分
4. 最后做全系统联调

优点：

• 兼顾架构验证和硬件验证
• 并行度高——上下两部分可以同时进行
• 中间层接口成为天然测试边界

缺点：

• 对中间层的接口稳定性要求高
• 管理复杂度增加
• 如果中间层设计不合理，会变成瓶颈

3.5 策略选择决策树

怎么选？我一般按这几个问题来决策：

• 模块数 < 5？ → 大爆炸（但要承担风险）
• 架构是全新的？ → 自顶向下
• 硬件接口是主要风险？ → 自底向上
• 项目大、并行度高？ → 三明治
• 团队分散在不同模块？ → 三明治（上下分开做）

3.6 四种策略对比总表

策略	集成顺序	桩/驱动需求	问题定位难度	并行度	推荐场景
大爆炸	一次性	无	极高	低	小项目、原型
自顶向下	顶层→底层	Stub	中	中	新架构、主流程
自底向上	底层→顶层	Driver	中	中	硬件驱动、底层库
三明治	上下同时→中间会师	Stub+Driver	低	高	大型嵌入式项目

3.7 集成策略选择流程图

下面这张图帮你快速决策：

3.8 实战建议

最后，分享几条我自己的经验：

• 先做接口契约：不管选哪种策略，模块间的接口定义必须先稳定。我吃过亏——接口没定好就开始集成，结果一半时间在改接口。
• 桩和驱动别写太复杂：够用就行。Stub只需返回典型值和边界值，Driver只需调用接口并检查返回值。
• 自动化是关键：集成测试一定要自动化。手动集成一次两次还行，十次八次你就崩溃了。
• 持续集成：每天至少做一次集成构建。发现问题越早，修起来越便宜。