测试基础微服务间的测试策略

CKL的思考 · 2022年11月03日 · 最后由 CKL的思考回复于 2022年11月03日 · 4401 次阅读

在之前的两篇文章中，我们从宏观和微观的不同角度尝试去设计我们的测试策略，在很多团队中，如果着眼于从微观的单体微服务开展测试活动，技术和成本都存在问题。所以我们需要一些可以更快速落地的方法，来保障微服务之间的可用性和稳定性，今天，我们尝试来聊聊这个问题。

01

如上图的中间图例所示，微服务之间的通信，通常都是通过 Rest 或者 RPC 来调用的。不论是基于哪种协议，都需要事先定义好通信接口。对于微服务间的可用性和稳定性测试，往往都是基于接口（Api）来展开的。所以，首先我们要明确团队对于 Api 的管理机制是什么。目前主要存在以下几种管理方法：

无文档形态：没有事先定义接口，没有接口文档，测试熟悉接口需要自己抓包，研发之间的联调全靠吼。在这种情况下，就不要去纠结服务间的测试策略了，做好上一层的测试策略即可。

手动维护接口文档：简单的，就用 Word 写与，好一点的，引入 Eolinker 这类工具。这个阶段的 Api 管理最大的问题在于文档的有效性。文档描述和实际代码的差别可能会让你怀疑人生。

由插件自动生成：典型的就是引入 Swagger 框架，程序在定义接口的时候，自动生成 Api 文档，大家只需要关注 Swagger 页面即可。在这种情况下，可以适当开展接口自动化测试，并尝试引入其他的测试方法。

综上，如果你的团队还没做好接口管理的准备，那么不建议你花太多的时间在接口测试上，因为你会做得很痛苦。你可以在适当的时候提醒开发去更新接口文档，让文档看起来有用些，而不是形式化。在这两个层面上，建议你还是做好微服务的整体测试策略。如果你的团队处在第三种状态，才有可能去探讨更多的可能性。

02

当下流行的契约测试，可以从本质上解决接口有效性和稳定性的问题。但这个需要研发的配合，需要主管的推动，也需要团队的实践。契约精神并不那么好建立。在介绍契约测试之前，先介绍一种比较另类的玩法，难度不大，但非常有效，是笔者在自己的团队中实践出来的。

因为从本质上来说，我们是需要关注接口是否发生了变化。如果我们能及时感知接口的变化，那么就可以快速评估它的影响范围（主要是调用方）。基于这个原则，我们做了如上图所示的设计：

依赖接口测试平台，完成单接口的测试用例测试，当测试用例被成功执行 3 次后（这个次数是可配置的，主要用于判断接口是否稳定），会把这个接口的入参和返回结构存到一张表中，作为 “契约”；

同时，会把稳定的接口测试用例，放到定时任务中，去被定时执行（我们配置的是每天两次），在定时任务中，测试用例除了常规的检查点外还需要额外匹配对应的 “契约”；

如果结构（人参和出参）没有变化，则验证通过。如果发现结构发生了变化，则需要通知相关人员（可配置，主要是给测试，由测试确认并推动）

在经过确认后，如果确认是接口需要被变更，则更新契约信息，保证下次验证是最新的内容（页面点击，系统自动同步）

是不是很好玩？技术上实现难度也不大。

03

好了，现在我们来聊聊契约测试，顾名思义是基于契约或者使用契约来测试被测系统，其核心是契约，包括如何制定契约，如果更改契约以及如何使用契约等。首先定义契约必须有 API 的消费者（Consumer）和 API 的提供者（Provider）两端，其次契约还要包含这个 API 的 Request 和 Response 的定义细节，见下图：

业界最常用的三个契约测试框架是 Pact，Swagger 和 Spring Cloud Contract。其中 Pact 是一个支持多种语言的框架，包括 Java，JavaScript，Golang，#C 等多种语言开源免费框架，主要通过编写测试代码来动态生成契约，并主要用于消费者驱动契约类型的测试；而 Swagger 主要是通过手动编写契约来做提供者驱动契约类型的测试；最后 Spring Cloud Contract 主要用于基于 Spring 框架开发的 Web 系统，也是主要通过编写测试代码来动态生成契约来做消费者驱动契约类型的测试。并使用契约生成相应的测试用例和自动化测试。

以上，来源于刘冉老师的文章，原文见文末，在这里不展开介绍，笔者也还在团队尝试试行中。后续有机会再总结。

04

在设计微服务间的测试策略时，还有一个需要关注的点，就是测试环境的使用。由于微服务间的依赖问题，可能会存在版本依赖关系，特别是一些外部的依赖，我们希望会有一个稳定的版本（类似用户系统、邮件系统等基础依赖）。那么一般的做法，是先部署一套稳定的全量版本，然后通过路由配置来处理（具体的路由方式需要参考具体的微服务架构）。如下图所示