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

第二个点是契约测试，这个知识点如果咱们测过微服务的话，在一些博客或者一些书上应该都看过。

什么叫消费者契约测试呢？刚才上面的那个图是Service T调用了Service X和Service Y。咱们下面的这个图与它正好相反，是两个Service 调用一个Service 。Service A和Service B调用了Service T。

也就是说，在微服务下，有些接口不是给用户来用的，是给其他服务来用的。这个时候我在测这个接口的时候，如果是常规性的测试，比如说这个接口有10个参数，那我要把这10个参数全部都进行组合，等价类、边界值、正交易......

这10个参数有可能组合出来好几百个测试用例，但是Service A和Service B逻辑都走完了，也不见得会有那么多种参数组合。

也就是说Service A和Service B使用Service T的时候，只使用它一部分的参数，没有那么多的参数组合，很多组合对业务来说是无效的。

在咱们传统软件上为什么几乎不提及这个事？因为传统软件接口少，这个Service T的接口可能只有10个，用刚才说的方式测也没有问题，顶多就是工作量大一些。现在微服务架构下，如果你还这样测的话，工作量就会大到难以完成。

那我们现在怎么做呢？因为接口变多了，所以我们就只看a和b完成正常业务逻辑的时候使用了哪些参数组合。换句话说，如果T提供了100种参数组合，完成A和B的业务流程只需要50个，那我们只需要测试这50个业务场景就可以了。

这个就叫做T对外提供的服务契约，我们针对服务契约对外提供的有效数据进行的测试就叫做针对于Service T的契约测试。

这样的测试用例集合就是Service T 可以对外提供的服务的契约。Server T的消费者只有 A和B，如果覆盖了A和B对T的所有调用，哪怕出现了其他调用场景，有异常，对系统影响也是有限的

又有一个问题就来了，既然不全测，只测有效的，怎么知道Service A和Service B平时是怎么调用它的呢？

技术比较好的朋友可能马上就能想到，在性能测试里面有一个很重要的概念叫线上流量回放，意思就是模拟线上的用户平时怎么对系统去进行压力的访问。比如说我们录制一下618、录制一下双十一，把录制的真实的压力情况进行回放。这种压力的情况更接近于真实用户对系统的压力，这样性能测试会更接近于真实的场景。

与它一样，我们是不是也可以采用这种录制的方式呢？就是在A和B之间，架设一个代理。我们很多朋友都用过抓包工具，我们知道抓包工具的原理就是代理。我们架设一个代理，把A和B对于T的调用录制下来，请求响应全部录制下来。

录制过之后，我们就可以使用这个录制的结果，这个就是Service T的契约，我只覆盖这些参数组合和这些场景，接口就完全够应付的了。这是咱们说的契约测试。