什么是契约测试

契约测试契约测试用于验证分布式系统中服务之间的接口约定是否一致由消费方Consumer声明「我期望你这样响应」由提供方Provider验证「我的实现是否满足这些期望」。它关注的是双方对同一 API 契约的共同理解与端到端测试、单元测试互补而不是替代关系。1. 核心角色与产物角色说明消费者Consumer调用其他服务的客户端在测试中生成或记录对响应形状、状态码、关键头字段等的期望。提供者Provider实现 API 的服务在 CI 中针对已发布的契约做校验或 replay 请求到真实实现。契约Contract双方认可的请求/响应约定常以 JSON 或可执行测试套件形式存在如 Pact 交互记录、SCC 契约 DSL 产物。契约代理 / Broker可选集中存放、版本化契约并协调「谁能部署」的中间服务无 Broker 时可用 Git 仓库 约定目录代替。2. 典型工作流从开发到 CI下图概括消费者驱动契约常见闭环先由消费方定义期望契约作为中间产物提供方在独立流水线中验证。验证协作开发阶段通过失败消费者编写测试声明期望响应生成/更新契约文件契约入库或契约代理如 Broker提供者拉取契约契约校验可安全集成/发布修正 API 或协商契约说明假设团队使用契约代理Broker集中存放版本化契约若小团队仅共享文件可将「契约入库或契约代理」理解为 Git 仓库中的契约目录。3. 消费者与提供者的交互时序契约测试常配合Mock消费者在本地不连真实提供方而是按契约模拟响应提供方则在 CI 中针对同一契约做验证。提供者 CI契约产物Mock / 契约桩消费者开发者提供者 CI契约产物Mock / 契约桩消费者开发者alt[校验失败][校验通过]按契约配置期望运行消费者测试返回符合契约的响应生成或更新契约文件流水线获取契约对真实实现执行契约校验阻塞发布或通知协商允许发布4. 与其他测试的边界类型关注点契约测试是否覆盖单元测试单模块内部逻辑不替代契约侧重点是跨服务边界。集成 / E2E多服务真实链路、环境、浏览器等契约不跑全链路但能尽早发现接口形状/语义不匹配。契约测试接口约定一致性核心请求/响应结构、状态码、关键字段、错误体形状等。契约测试不擅长性能、安全渗透、业务正确性的全部细节需专项测试或 E2E/探索性测试补充。5. 常见协作模式模式谁主导适用场景消费者驱动主流消费者先写期望并产出契约微服务、前后端分离、内部 API 多消费方。提供者驱动提供者发布契约/文档消费者跟进OpenAPI/Protobuf 已作为事实标准、变更治理成熟时。双向校验两侧 CI 都跑Broker 做版本与依赖图多团队、多环境、需要「能否上线」门禁时。契约测试工具里Pact以消费者驱动为主Spring Cloud Contract常从提供者 DSL 生成桩与契约仍可在 CI 中与消费方对齐但工作流重心不同。6. 工具选型提示工具 / 路线特点备注Pact多语言消费者/提供者生态与社区大Broker 支持「依赖图 / can-i-deploy」学习曲线主要来自「交互模型」与 Broker 运维。Spring Cloud Contract与 Spring、WireMock、Maven/Gradle 集成紧以 JVM/Spring 栈为主。OpenAPI / JSON Schema CI用文档或 Schema 作为契约CI 做请求/响应校验不是同一套「交互录制」模型但可解决「形状一致」问题。选型时可综合语言栈、是否已有 API 文档、多团队是否需要集中契约与部署门禁、与现有 CI/CD 的集成成本。7. 实践要点先协商再固化契约变更应有可见记录PR、版本号、变更说明避免静默破坏消费方。契约粒度覆盖「会破坏集成」的约定即可可选字段、扩展字段策略在团队内明确例如「新增只增不减」与版本策略一致。失败可诊断校验失败应能定位到具体交互、路径或字段便于区分「实现 bug」「契约过时」「环境数据问题」。与 E2E 分工契约保证「接口对上」全链路业务行为仍建议用适量 E2E 或探索性测试补充。测试数据提供者校验时使用可控的 Provider State或等价机制避免依赖随机生产数据导致 flaky。8. 契约产物生命周期状态示意以下状态机描述契约文件在团队流程中的常见阶段具体工具命名可能不同如 Pact 的 publish / verification。用于与第 2 节流程图对照「验证」通过后才进入可部署/可集成态。本地生成契约提交至 Broker 或仓库提供者 CI 校验通过提供者 CI 校验失败修改消费者期望或协商 API新版本契约替代消费方全部迁移后下线DraftPublishedVerifiedFailedSupersededDeprecated假设存在「已发布但未验证」的中间态例如先上传契约再跑提供者流水线若团队要求「未验证不可合并」可将Published与首次验证合并为更严格的门禁。9. 破坏性变更时的协作流程当提供者需要删字段、改类型、改语义时建议显式走「兼容策略 版本」流程避免仅靠口头同步。下图强调消费者与契约同步更新与提供者实现的先后顺序可因组织规范而异但契约与实现必须最终一致。是否发现需改 API是否向后兼容?补充测试用例扩展契约可选字段等提供者实现并过契约校验发布发起变更评审列出受影响消费者约定新版本或新路径消费者更新契约与代码提供者实现新版本双方 CI 均通过分阶段发布与下线旧版10. 反模式与常见问题现象风险改进方向契约里锁死过多可选细节维护成本高、微小变更也失败只断言「集成所必需」的字段与类型其余用宽松匹配或示例级断言视工具能力。提供者校验从不失败可能未覆盖真实分支或状态增加 Provider State / 场景矩阵与业务用例对齐。无 Broker 时契约散落各仓库版本混乱、不知道谁依赖谁最小也要有目录约定 CI 拉取顺序或引入轻量 Broker。把契约测试当 E2E遗漏跨系统业务规则契约通过后仍保留关键路径 E2E。生产密钥进契约安全风险契约中仅形状与示例值敏感数据用占位符与独立安全测试。11. 分阶段落地建议试点选 1 条调用链、1 个消费者 1 个提供者跑通「生成契约 → CI 验证」闭环。标准化统一契约存放位置、命名、CI 阶段如contract-testjob、失败时的通知人。门禁在预发或生产前将「契约验证通过」作为合并或发布条件之一可与现有质量门禁并列。扩展多消费者时引入 Broker 或等价物可视化依赖与版本兼容矩阵。12. 何时值得引入服务数量多、发布频繁接口变更容易引发联调成本。消费者与提供者由不同团队维护需要可执行的接口约定作为协作界面。希望在不依赖完整测试环境的情况下尽早发现集成层面的不兼容。若团队规模很小、服务边界稳定且以单体为主契约测试的收益可能有限可优先把单元测试与关键路径 E2E 做扎实后再评估。