集成测试概念与重要性概述
为什么一定要聊集成测试？
做DLP（数据防泄漏）接口的人，大多经历过类似的深夜：
单元测试全绿，一联调就崩。
发出去的请求接口返回了"OK"，但数据根本没过策略引擎。
日志里全是"Connection refused"，但网络通、端口对，谁都说不清问题在哪。
说白了，这些都不是单个模块的 bug。
是模块之间握手的方式出了问题。
这就是我们今天要聊的——集成测试。
我的定义：集成测试不是把单元测试跑一遍再拼起来，而是验证「接口契约」是否成立，数据在模块之间流转时有没有变形、丢失或卡死。
集成测试到底测什么？
我习惯把软件分层拆成三块来看：
| 测试层次 | 关注点 | 典型问题 |
|---|---|---|
| 单元测试 | 函数/类内部逻辑 | 边界值、分支覆盖、异常处理 |
| 集成测试 | 模块间接口与数据交互 | 参数传错、协议不匹配、时序依赖 |
| 系统测试 | 端到端业务流程 | 性能、安全、用户体验 |
举个例子。
DLP 接口里有个「文件内容解析」模块，单元测试可以覆盖它收到 PDF 后正常返回文本。
但集成测试要看的是：上游把文件流传过来时，Content-Type 写错了，解析器会不会直接抛异常？
接口返回的扫描结果，下游的策略引擎能不能正确识别 status code 里那个「0」代表「安全」？
这些问题，单元测试不会管，系统测试发现时已经太晚了。
集成测试在 DLP 接口落地中的「坑」
我曾经接手过一个 DLP 网关项目。
两侧团队分别测了三个月，成功率 99.9%。
一上线，每天凌晨接口超时。
查了一周才发现：策略引擎的 刷新逻辑是同步的，而接口模块的默认超时是 3 秒。
两边各自都正常，合在一起就卡死了。
这就是典型的「集成缺陷」—— 单模块逻辑对，组合起来失效。
⚠️ 集成测试的黄金原则：不要相信对方的「接口文档」，要相信真实的握手结果。文档可能写对了，但实现时被偷偷改了一处字段类型。
集成测试的典型落地流程
我自己在项目中摸索出的可操作步骤：
- 契约定义 — 接口签名、协议、状态码、异常返回必须双方签字确认。
- 桩模块准备 — 下游未就绪时，用 mock 服务模拟真实行为，包括异常响应。
- 数据流验证 — 构造典型数据（正常 + 边界 + 异常），跑通一个完整请求闭环。
- 反向验证 — 故意让一方报错，检查另一端能否正确处理和熔断。
- 并发与重试 — 模拟超时、重试、重复请求，验证幂等性和过期处理。
💡 一个小习惯：我每写一个集成测试用例，都会在注释里标注「该用例发现的典型问题」。下次维护时看一眼就知道这段接口有过什么血泪史。
一张图看懂集成测试在 DLP 落地中的位置
下面这张图展示了一个典型的 DLP 接口集成测试上下文：
集成测试的「三不」原则
我直接给团队定了三条硬规矩，也推荐给你：
- 不依赖真实环境 — 集成测试环境必须可控、可重复，否则定位问题比解决问题还耗时。
- 不跳过异常场景 — 别只跑 happy path。网络闪断、超时、重复消息才是集成的常态。
- 不把问题留给联调 — 联调是验证业务正确性，不是拿来找接口 bug 的。
我的经验：集成测试越早做，后期痛苦越少。我见过太多项目在集成阶段花了两倍于开发的时间去修复那些「单个模块看起来没错」的 bug。每次都说「这次先把功能搞完再补测试」，结果永远补不上。
总结：集成测试不是可选，是必须
你想想看，DLP 接口要对接邮件、文件、终端、网络多个数据源，每个源背后的协议、编码、超时策略都可能不一样。
没有集成测试，等于闭着眼进隧道，撞了墙才知道路径不对。
从今天开始，我们后面的章节会一步步拆解：如何在 DLP 接口的每个环节落地可执行的集成测试。