4、软件集成测试：集成策略与接口测试
好，咱们今天聊聊集成测试。说实话，单元测试做得再好，也只是证明每个零件没问题。但零件装在一起，能不能转起来？这才是集成测试要回答的问题。
我在医疗器械项目里见过太多这样的案例：每个模块单独测都通过，一集成就崩。为什么？因为接口没对齐，数据格式不匹配，或者时序出了偏差。嗯，这恰恰是集成测试的价值所在。
4.1 集成策略：三种主流打法
集成策略说白了就是「怎么把模块拼起来」。我常用的有三种，各有各的脾气。
4.1.1 大爆炸集成
把所有模块一次性拼好，然后整体测试。听起来很痛快，对吧？
优点：简单粗暴，适合小项目。
缺点：出问题了你根本不知道是哪个模块的锅。我在一个监护仪项目里试过一次，结果定位 bug 花了三天——从那以后，超过 5 个模块的项目我再也不敢用大爆炸了。
4.1.2 自顶向下集成
从主控模块开始，一层层往下集成。上层模块用真实的，下层模块先用桩模块（stub）代替。
优点：能尽早验证系统的主流程和架构。
优点：桩模块写起来挺烦的。你想想看，下层模块可能有几十个接口，每个都得模拟。
我个人习惯在项目早期用自顶向下。为什么？因为可以先跑通核心业务逻辑，心里有底。比如呼吸机的参数设置流程，先验证界面到控制层的通路，底层传感器后面再补。
4.1.3 自底向上集成
从最底层模块开始，先测驱动层、硬件抽象层，再往上集成。上层模块用驱动器（driver）模拟。
优点：底层模块通常与硬件相关，先测能尽早暴露硬件适配问题。
优点：要等到最后才能看到完整的系统行为。
我在一个血糖仪项目里用过自底向上。底层传感器驱动先测，确保数据采集准确。然后一层层往上，最后才看到完整的用户界面。嗯，这样确实稳妥，但进度压力大的时候会有点焦虑——毕竟前面几周都看不到「成品」。
4.2 接口测试：集成测试的核心
集成测试测什么？说白了就是测接口。接口是模块之间的「握手」，握不好，整个系统就瘫了。
接口测试要覆盖的内容：
- 数据接口：参数类型、取值范围、边界值。比如一个函数要求输入 0-100 的整数，你传个 101 会怎样？传个负数呢？
- 控制接口：调用顺序、状态切换。我记得一个除颤仪项目，充电和放电两个模块的调用顺序搞反了，结果设备直接死机。
- 时序接口：超时、并发、同步。实时系统里，时序问题最隐蔽。我曾经遇到一个案例，两个线程同时写同一个缓冲区，数据全乱了。
- 错误处理接口：模块返回错误码时，调用方能不能正确处理？很多 bug 就出在「错误处理没处理」上。
4.3 集成测试用例设计
用例设计其实有套路。我总结了几种常用方法：
4.3.1 基于接口的用例设计
针对每个接口，设计正常值、边界值、异常值。比如：
- 正常值：参数在有效范围内
- 边界值：最小值、最大值、临界值
- 异常值：空指针、越界、类型不匹配
4.3.2 基于场景的用例设计
模拟真实使用场景。比如：
- 正常操作流程：开机→自检→设置参数→启动治疗→停止
- 异常操作流程：治疗中突然断电→恢复供电→系统应能安全恢复
- 并发场景：多个模块同时访问共享资源
4.3.3 基于数据流的用例设计
跟踪数据在模块间的流动路径。比如：
- 传感器采集数据→滤波处理→算法计算→显示输出
- 每个环节的数据格式、精度、延迟都要验证
| 用例编号 | 测试项 | 前置条件 | 输入 | 预期结果 | 实际结果 |
|---|---|---|---|---|---|
| IT-001 | 数据接口-边界值 | 模块A已初始化 | 参数值=0 | 模块B正确接收 | — |
| IT-002 | 时序接口-超时 | 模块B响应延迟>5s | 发送请求 | 模块A超时重试3次 | — |
| IT-003 | 错误处理-异常码 | 模块C返回错误码-1 | 调用模块C | 模块D记录日志并报警 | — |
4.4 集成测试的注意事项
最后说几个我踩过的坑：
- 别忽视桩模块和驱动器的质量。桩模块写得太简单，可能掩盖真实问题。我见过一个项目，桩模块永远返回成功，结果集成后才发现真实模块有延迟。
- 接口文档要实时更新。代码改了，文档没改，测试用例就废了。我习惯在代码 review 时顺带检查接口文档。
- 自动化测试要跟上。手动集成测试太慢，尤其是回归测试。我建议用 CI/CD 工具，每次代码提交都自动跑集成测试。
- 医疗器械的集成测试要留痕。测试用例、测试结果、问题跟踪，都得有记录。为什么？因为 FDA 审核时会查这些。
好了，集成测试就聊到这儿。下一章咱们讲系统测试，到时候再细聊。