干货时间：聊聊DevOps下的技术系列之契约测试

摘要：本期和你们简单聊聊在服务交互场景下使用服务契约的重要性，以及契约管理的必要性，最后简单介绍了下契约测试。

一、服务交互带来的问题

在上一篇文章中，咱们系统的列举了DevOps各个流程中经常使用的测试技术。

接着上一篇的图，咱们简单画下一个系统应用的内部服务的调用关系：交付一个大的系统可能涉及到多家ISV进行集成，每家ISV本身又存在前端、网关、后端等多个微服务，且各自ISV或者服务均存在本身的SE、开发和测试人员，都有本身相对独立的版本演进，服务之间存在调用关系。

思考一下，这会带来哪些问题呢？

• 经过接口文档或者表格管理接口内容，服务交互双方、多方频繁对接交互调用的接口信息，频繁刷新，剪不断、理还乱，让人崩溃。
• 服务依赖致使必须等待底层服务先开发完成才能联调对接和集成测试，效率低下；
• 此时若是发现被调用服务接口不知足要求、接口缺失、接口没法联调等问题时，须要从新等待版本联调，形成资源和时间上的浪费；
• 服务都在不停的向前演进，调用服务与被调用服务的版本会随着外部需求增长、Bug修改、代码重构等等因素而致使接口发生变动，接口调用服务每每没法及时获取接口变化而致使总体业务受损。

二、服务契约--服务交互问题的一种解决方案

如何解决服务间纷纷复杂的联调问题呢？本章节咱们来聊一聊契约与契约测试。

顾明思义，契约就是一份由双方或多方共同订立的、具备强制听从性的信用文书。契约测试全称消费者驱动契约测试(Consumer Driven Contracts Testing)，最先见于2011年。“消费者驱动契约测试”名称中清楚描述了“契约”、“谁提供契约”的问题。

通常来讲，是消费者(Consumer)把本身对输入和输出的数据结构、性能已经并发性等指望以约定的格式告诉服务提供者(Provider)，服务提供者签署赞成，这就造成了一份服务契约，服务提供者对全部消费者的契约取并集进行服务能力开发，造成本身服务的对外承诺或者schema。

模型以下：消费端服务 A、B、C 调用访问服务提供端服务A，消费端服务 A、C服务提供端服务B。服务提供端会根据消费端指望分别生成1份契约文件，以知足消费端的诉求。

服务之间经过契约交互会带来哪些好处呢？

1）、使用契约，接口调用双方的对接、问题定界等都有“法律依据”，问题不会扯不清、道不明、来回甩锅。

2）、使用契约，就肯定了交付双方的接口形式和入口与出口指望，消费端和服务提供端能够并行开发服务，而且在开发过程当中就利用契约进行预集成测试，不须要等待联调再来集成测试，大幅下降联调沟通成本。

3）、由于契约的存在，能够总体看到服务消费端的原有接口使用状况，让接口的变更有迹可循，即便变更也能够确保变更的安全性和准确性。

4）、消费端也能经过契约的变化获知服务端的API变化状况

三、契约交互的问题

在第二章节咱们看到契约的基本流程。在正常的契约测试流程中，契约由消费者提供，服务者听从，根据消费者的提供的契约完成服务测试。可是，你们思考下这种模式存在什么样的问题？咱们思考下一下的问题：

• 双方的契约有了，可是口头协议空口无凭，契约如何存储，以及如何才能防篡改？
• 邮件交互、会议纪要难以维护？
• 在敏感市场，消费者提供的契约是否符合正常诉求与合规？
• 在多ISV服务商、多部门协做的应用系统，消费者频繁刷新契约要求怎么办？
• 正常须要刷新契约怎么处理、契约怎么会退或者回溯？
• 消费端驱动，会不会形成消费端权力过大，话语权太重，倒逼服务提供端，最终也会致使整个系统不三不四？

从上面的几个问题能够看出，因为契约很重要，那么设计和管控契约也就显得更加剧要。

四、契约设计与契约管理的必要性

交互的问题并不像想象的那边简单，为了解决契约设计和管控的问题，咱们新增一个设计管控和契约管理的环节。

设计管控环节相似于议会这种机沟通和决策机构，用于调停和审视契约的合理性、合规性和更改的必要性，且对于多消费者的契约作合并处理。

契约管理环节，解决契约存储、访问认证和不可篡改性、可追溯性和可回退等问题。这样就避免了前面所说的问题，固然牺牲了必定了灵活性，可是在大型系统中，这样行为是值得的。

咱们看下，消费者的契约的生成和下载过程就变成以下流程：

同时，若是服务端要主动变动契约，也要获得消费端和审视委员会的经过，审核经过合入后，消费者和服务提供者从契约管理平台下载契约使用。流程变得以下：

五、契约测试

前面的章节，咱们花了较多篇幅介绍了契约的生成和契约在服务交互过程当中的做用以及重要性，那么对契约的测试也很重要。下面咱们简单聊聊如何对契约进行测试。

契约测试不是组件测试，契约测试和核心也是经过API来进行。每一个消费者只会关注本身的指望是否获得知足，因此只须要根据本身提供的、已审核经过的契约文件进行测试。而服务提供端则须要知足全部消费者的诉求，须要拿全部消费者的契约作测试，全部契约须要测试经过。以下所示：

因为实际开发中，契约签定以后，Consumer和Provider是同步开发，因此Consumer和Provider也是分别测试。通常的契约测试过程以下：

Consumer服务的测试环境，须要使用契约进行Mock Provider服务进行构建：

Provider服务的测试环境，则须要根据和Consumer签署的契约文件生成的契约测试用例进行测试，经过测试契约用例验证本身提供的接口是否知足消费者须要，接口是否有变动。一旦接口发生变动，契约测试用例会执行失败。

前面所述，契约是消费者(Consumer)把本身对输入和输出的数据结构、性能已经并发性等指望以约定的格式告诉服务提供者(Provider)，服务提供者签署赞成后造成的，那边契约测试的主要内容也即是这几个方面：

支持契约测试的工具备Pact、Pacto、Janus、CloudTest，Swagger也能知足部分要求。通常来讲，业界使用Pact工具的较多，简单说下Pact工具的过程，具体Pact用法请参照官网：

Consumer测试：

Provider测试：

咱们也补充下Pact工具的优缺点

六、微服务下的服务契约样例

契约通常是一个yaml文件或者json文件的格式，咱们以CSE微服务的契约为展现样例：

结语：本期和你们简单聊聊在服务交互场景下使用服务契约的重要性，已经契约管理的必要性，最后简单介绍了下契约测试。契约测试工具用法的指导文档较多，本篇没有作展开。DevOps下，契约测试也是须要集成到流水线中，欢迎下来继续交流。

本文分享自华为云社区《聊聊DevOps下的测试技术（2）聊聊契约与契约测试 》，原文做者：柳哥说 。

 

点击关注，第一时间了解华为云新鲜技术~