契约测试理论篇

随着 Web 系统的大规模发展，Web API 已经成为了一种广泛使用的技术，再加上微服务和云系统的普及，Web API 的数量呈几何增长。比如在一个大型 Web 系统中，各个子系统或者依赖系统之间一般都使用 Web API 来集成，从而导致开发不同子系统或者依赖服务的团队之间也存在不少问题。其中最大的四个问题是：

• 团队之间业务和技术集成沟通困难

• 团队之间业务和技术集成沟通困难

• 难以快速响应外部需求变化

• 开发流程责任链混乱

• Web API 部署到测试环境后才发现集成问题

这四个问题都属于集成和变更管理的问题，首先团队之间业务和技术集成沟通困难主要是指没有明确的集成沟通流程，那么团队之间在沟通集成业务和技术的时候则容易混乱不清，遇到各种困难。所以需要有一个规范和明确的沟通流程，从而避免有流程混乱所产生的困难。

其次对于难以快速响应外部需求变化，指如果系统的用户提出一个新需求或者需求更改的时候，很难快速的让所有后端开发团队们都明确的知道集成部分的更改细节和需求，从而快速的完成开发工作。

对于开发流程责任链混乱，指对一个子系统很多的应用系统，如果发现一个集成相关的问题，很难确定是哪个子系统的问题。需要有一种方法可以快速的确定应该由谁来修复这个集成问题。

最后 Web API 部署到测试环境后才发现集成问题，导致发现问题的时间延后，从而增加修复的成本。所以最好能在 Web API 的编码开发阶段就发现集成问题，从而可以快速反馈，节约修复成本。

在各种测试方法中，契约测试可以较好的解决上面四个问题。但是业界能真正实施契约测试的团队却很少，比如 Google&#x