契约测试是一种横跨 API 与微服务的集成测试方法，目标是验证请求与响应是否符合约定。它建立在「契约」概念之上：服务端和客户端对某一种数据交换的格式与形态达成共识——客户端按特定格式发请求、服务端保持该格式不变、并以预定的格式返回，客户端也按此预期接收。一旦契约被违反，就说明在「功能形态」或「对既有契约的理解」上出了问题。在复杂系统里，比起翻遍整个代码库，直接验证契约（通常写在规范文件里）能更快定位潜在故障。
契约测试是现代 API 与微服务开发的利器——只验证「输出」就能测透整个系统。本文编译自 Nordic APIs（2023-03-23，作者 Kristopher Sandoval），讲清契约测试是什么、为何值得做，并给出「定义契约→建测试→执行→自动化→维护」的完整五步法，附 Pactflow/Joi/Postman 等工具。
契约测试是一种横跨 API 与微服务的集成测试方法，目标是验证请求与响应是否符合约定。它建立在「契约」概念之上：服务端和客户端对某一种数据交换的格式与形态达成共识——客户端按特定格式发请求、服务端保持该格式不变、并以预定的格式返回，客户端也按此预期接收。一旦契约被违反，就说明在「功能形态」或「对既有契约的理解」上出了问题。在复杂系统里，比起翻遍整个代码库，直接验证契约（通常写在规范文件里）能更快定位潜在故障。
微服务化让测试环境空前复杂：曾经的单体，如今是几十上百个服务协同，背后是分散又难懂的代码库。在这种系统里全量测试如同大海捞针，成本高、收益模糊。契约测试最快的验证方式就是「只测输出」——测契约。它让提供方以极低时间和成本，验证整个系统的最终数据流向，可作为更全面测试的起点；当然它不取代深度测试，出错时仍需更完整手段兜底。
契约测试有几个独到的好处：一是以低成本、高可管理性为更复杂的测试提供起点，只测系统输出就能验证整体，大幅压低复杂系统的测试成本；二是现代 API 空间里契约大多已被良好定义（OpenAPI 等开放规范），测试变得又快又简单，自动化也顺理成章——把规范文件一插，几分钟内就能对所有端点生成自动化测试；三是让服务端和消费端相互隔离，问题定位更精细，进一步降低整体复杂度。
最简单也最常见的方式是用开放规范生成契约文件，例如 OpenAPI 或 Protobuf。即便没有规范文件，也可以在测试用例里直接定义契约。无论哪种方式，契约都应包含：预期的请求/响应格式、可能出现的错误条件、数据交换方式，以及已知的故障转移状态；并且必须被所有与之交互的系统和团队认可。
契约定义好后，就要据此建测试。办法和定义 schema 一样多，但测试必须覆盖契约里定义的全部场景才算完整。像 Pactflow 或 Joi 这类方案可以直接从规范文件生成测试，省去手写成本。
测试要在系统内的不同服务上运行，覆盖所有已声明的契约。微服务是多种系统的集合，务必保证测试真正全面——漏掉一块拼图看似小事，但当整体契约依赖某个埋在深处的微服务时，这些遗漏会迅速累积。跑完要把结果和契约里的预期比对，任何实际与预期的偏差都要排查修复，因为它们代表着契约破裂，可能是 bug、误解或糟糕的设计。
契约测试很耗时，自动化让它从「好」变「真正强」。使用 Spring Cloud 或 Postman Collections 这类工具，可让测试长期持续运行，确保契约始终如约。自动化把开销和复杂度一举压下来。
契约及其测试方式必须持续维护。变更要被良好追踪；当 API 本身改动时，基于它的规范和契约也要同步更新。一旦测试自动化，这点更重要——误报和漏报都会毁掉自动化测试的价值。定义的契约、创建的测试、执行、自动化、维护，五步走完，开发者就拥有了一个持续运行、稳定可靠的测试环境。
五步里最易被自建团队忽略的是「①定义契约」与「⑤维护」。YesApi Pro 开放平台以 OpenAPI 为契约真源，自动生成在线文档与多语言 SDK，从源头避免「文档/实现两张皮」；网关层统一留存每一次请求/响应，相当于给线上做持续的「运行态契约校验」，比只在 CI 跑一次更稳。把契约验证左移到设计期，breaking change 在上线前就能被拦下。