什么叫契约测试？

       第一、什么是契约测试？

         契约测试又称之为消费者驱动的契约测试(Consumer-Driven Contracts，简称CDC)，根据消费者驱动契约 ，我们可以将服务分为消费者端和生产者端，而消费者驱动的契约测试的核心思想在于是从消费者业务实现的角度出发，由消费者自己会定义需要的数据格式以及交互细节，并驱动生成一份契约文件。然后生产者根据契约文件来实现自己的逻辑，并在持续集成环境中持续验证。

       网上有一段很经典的总结如下：

两个角色：消费者（Consumer）和 生产者（Provider）
一个思想：需求驱动（消费者驱动）
契约文件：由Consumer端和Provider端共同定义的规范，包含API路径，输入，输出。通常由Consumber生成。
实现原理：Consumer 端提供一个类似“契约”的东西（如json 文件，约定好request和response）交给Provider 端，告诉Provider 有什么需求，然后Provider 根据这份“契约”去实现

第二、为啥需要契约测试？

        在系统工程中存在这样的理论：线性系统（即复杂性随规模线性增长的系统）的可靠性等于组成它的各个组件的可靠性之乘积。这容易理解，因为整个系统正常工作的条件是必须每个组件都同时正常工作。

        如上图所述，三个组件共同支撑的系统，如果每个组件的可靠性是90%，那么整个系统的可靠性就是 90%×90%×90%=72.9%，我们可以看到系统整体的可靠度是低于任一组件的可靠性的。如果一个系统由100个组件组成，每个组件即使能达到99%的可靠性，那么整个系统的可靠性也会降到36.6%左右。随着业务的复杂度越来越高，整个系统也变得越来越庞大和错综复杂，为了应对此类场景就出现了微服务，在微服务的架构下通常一个client会与多个service相互交互，如果某一个服务的接口发生变化将会影响整个系统的运行。那么在微服务模式下如果保证各个服务端与消费端之间以及服务与服务之间能够可靠的交互呢？这就回到了到我们要聊的契约测试的话题。另外我感觉下面这张图也很贴切：

在系统开发过程中很多时候就会出现这种问题，不同团队不同系统之间齐头并进最后发现一联调到处都是问题，像极了上面这个轨道铺设对接的场景。

第三、契约测试怎样做？

目前常见的有以下几种：

Pact 契约测试框架
         之前业内较为常见的做法是通过Pact（一个契约测试框架）进行契约测试：通过前端开发人员编写代码进行测试并生成Pact契约文件，后端通过Pact Brocker等服务管理契约以及调用等。

通过 EOLINKER API Studio 实现契约测试
           EOLINKER API Studio（https://www.eolinker.com） 提供了UI实现的 Mock API，配合API Studio 的测试用例与自动化测试，可以帮助研发团队更快速、更有效地实现契约测试。通过 Mock API，您可以事先编写好 API 的数据生成规则，由 API Studio 动态生成 API 的返回数据。开发人员通过访问 Mock API 的 URL 来获得所需要的数据，完成对接工作。在 API Studio中，同一个项目中的 Mock API 的地址前缀是相同的（如mock.eolinker.com/uasyd1/…），因此可以在代码中将 Mock API 的地址前缀作为全局变量，项目上线时仅需替换变量的值即可改变整个项目的 API 请求地址前缀。

后续会单独聊聊这2个实现方式。