1. 集成测试概述
1.1 集成测试定义
集成测试（Integration Testing）是在单元测试之后、系统测试之前执行的测试阶段，其核心目标是验证多个已独立验证的软件模块或组件之间的交互与协作是否正确。它关注的是模块间的接口、数据传递、调用时序、异常传播以及外部依赖的集成行为，而非单个模块的内部逻辑。
关键定义：集成测试 = 模块组合 + 接口验证 + 依赖协作 + 数据流正确性。
集成测试通常由开发团队或测试开发工程师（SDET）执行，测试对象为模块组合体（如服务层 + 数据访问层、微服务 A + 微服务 B）。测试环境需要包含被测模块及其真实或模拟的外部依赖（数据库、消息队列、第三方 API 等）。
1.2 集成测试与单元测试区别
理解集成测试与单元测试的差异是构建正确测试策略的前提。下表从多个维度进行对比：
| 对比维度 | 单元测试 | 集成测试 |
|---|---|---|
| 测试粒度 | 单个函数、方法、类 | 多个模块、组件、服务 |
| 测试目标 | 内部逻辑正确性、边界条件 | 接口契约、数据流、协作行为 |
| 依赖管理 | 完全隔离（Mock/Stub 所有外部依赖） | 部分真实 + 部分 Mock/Container |
| 执行速度 | 毫秒级（纯内存） | 秒级到分钟级（涉及 I/O 或网络） |
| 环境要求 | 仅需测试框架 | 需要数据库、消息队列、容器等基础设施 |
| 失败定位 | 精准定位到具体代码行 | 定位到模块间交互点，需进一步排查 |
| 维护成本 | 低（逻辑稳定） | 中高（依赖环境变化） |
| 典型框架 | JUnit, pytest, Jest | Spring Boot Test, Testcontainers, WireMock |
实践建议：单元测试保证“模块做对了”，集成测试保证“模块之间配合对了”。两者是互补关系，不可相互替代。推荐测试金字塔比例：单元测试 60% + 集成测试 30% + E2E 测试 10%。
1.3 集成测试在软件开发生命周期中的位置
集成测试位于单元测试之后、系统测试之前，是从白盒到黑盒的过渡桥梁。下图展示了集成测试在典型 SDLC 测试阶段中的位置与输入输出关系：
集成测试在 SDLC 中扮演质量门禁角色：
- 输入：已完成单元测试的模块、接口定义文档（API 契约）、集成测试计划。
- 执行：按照集成策略（大爆炸、自顶向下、自底向上、三明治）逐步组合模块并验证交互。
- 输出：集成测试报告、接口缺陷列表、模块间兼容性评估、回归测试用例。
- 下游影响：只有集成测试通过，模块组合才能进入系统测试环境，否则将产生大量阻塞性缺陷。
常见误区：不要将集成测试推迟到所有模块开发完成后才执行。推荐采用持续集成（CI）流水线，每次代码合并后自动触发集成测试，实现“尽早集成、频繁集成”。
1.4 集成测试的核心价值
集成测试在软件质量保障体系中具有不可替代的价值，主要体现在以下四个方面：
| 价值维度 | 具体说明 | 典型场景 |
|---|---|---|
| 接口契约验证 | 确保模块间的输入/输出格式、参数类型、异常码一致 | REST API 响应字段缺失、gRPC 序列化不兼容 |
| 数据流正确性 | 验证跨模块的数据传递、转换、持久化是否完整 | 订单服务写入数据库后，库存服务读取到脏数据 |
| 依赖行为模拟 | 通过 Mock/Stub/Container 模拟外部依赖的异常与边界 | 数据库连接超时、第三方 API 返回 500 |
| 回归防护 | 在代码变更后快速发现模块间协作被破坏 | 重构数据访问层后，业务服务查询结果异常 |
经验数据：根据行业统计，集成测试阶段发现的缺陷约占项目总缺陷的 30%-40%，且修复成本仅为系统测试阶段的 1/5 到 1/3。投入合理的集成测试资源可显著降低后期返工成本。