上面的文章我们讲了，所依赖的服务不稳定或无法调用和调用参数组合太多的情况下应该如何进行接口测试，本文继续为大家介绍如何接口测试的重要知识--如何收集契约。

我们一起看一下上面这个图，我们把A和B都录制下来。我们可以看到A调用和B调用都是可以区分出来的，分别录制成两个文件，

这个文件一般是使用JSON这种数据结构，数据结构比较清晰，很多测试工具也比较容易回放。

然后拿到最右边黄色的部分进行汇总，也就是我们说的契约，实际上就是录制时调用的一些参数和信息。把这些数据进行回放，不管是用测试工具还是用手工的方式进行回放，或者编写测试用例也行，完成对Service T的完整的测试。

这就是在微服务架构下，对于一些核心接口的一种重要手段，契约测试。这样会使我们的测试效率变得更高。
第二种方式，有很多朋友说，上面这种收集、录制也挺麻烦的，有没有一些日志可以查？从日志里能不能直接查到这些信息呢，其实是有的。

接触过微服务或者开发的朋友都知道，微服务整个系统架构里面有这样一个网关--API Gateway，也就是接口服务网关。

你也可以理解为小区的保安室，保安室里面有两个保安，专门来监控整个微服务架构下来往的接口的一些数据。把请求和响应的数据都写到日志里面，这个叫API Gateway 日志。

我们也可以通过解析API Gateway 日志拿到里面关于接口调用的信息，比如说下面的示例图，用户通过设备访问到网关，网关记录的同时将各个请求转发到各个相应的服务上面，不管什么类型，什么协议都可以拿到。

这个时候就可以解析API Gateway的Log，这个Log一定是有固定格式的，所以肯定是可以解析的。

但是这里有一个问题，这个API Gateway只给用户直接访问的接口做记录。我们看最右边的一层，Dubbo、HTTP、Hession、JSF，都是暴露在最外面的。

它后面肯定还有很多小接口、小服务，比如HTTP下面还有A接口，A又调用了B，B又调用了C，这里还有很多内部调用。

但是它只记录对外提供的，暴露在最外面的接口的信息，所以你要是测试的接口不是直接提供给用户来访问的，不是to C的接口，那么你是不好获取到它的日志的信息的。还得使用第一种的方式。

以上内容总结来说，如何收集契约？
    
方式一：在 Service T 前放置一个代理，所有进出 Service T 的 Request 和 Response 都会经过这个代理，并被记录成 JSON 文件，也就构成了 Service T 的契约。
这些Json数据，可以进一步约定录制格式，整理后
1. 可直接通过接口测试工具回放—HttpRunner
2. 可上传到接口测试平台直接回放
3. 可入库到接口测试平台或工具中做进一步修改
方式二：*利用 API Gateway
API Gateway用于记录所有 API 之间相互调用关系的日志
解析 API Gateway 日志 获得每个 Service 的契约