前言
本文将介绍如何利用代码的自动生成,对微服务API进行快速高效的测试,全文分成三部分:需求篇,设计篇和实现篇。需求篇将介绍项目背景,微服务API测试中的痛点,以及我们理想的解决方案。设计篇将介绍如何针对需求,设计可行的实现方案。实现篇将从代码着手,介绍具体的实现。小伙伴们可以自行点开感兴趣的部分。
背景
我们的微服务群提供了大量RESTful API供前端访问,如何对这些API进行测试成了让我们头疼的问题。首先,API的数量很多,对每个API开发测试代码费时费力。另外,微服务由不同团队开发,开发人员水平也参差不齐,不容易保证测试代码的质量和规范性。
针对上述问题,我们希望快速高效的进行API测试,同时保证成本可控以及测试代码的品质和规范性。这样的需求看似简单,却违反了项目管理中QCD三角原理(Quality,Cost,Delivery)。
说白了“多快好省”的事情本身就不科学。QCD三角中总有一部分要优先,一部分要舍弃。
解决方案
我们的解决办法是开发一个可以自动生成测试代码的工具,用于加速API测试并且保证测试代码质量。没有绕开QCD三角,相当于在前期提前投入成本开发工具(Cost),保证后期测试时的品质和时间(Quality,Delivery)。使用这个工具后,API测试变成了一种声明式测试(Declarative Testing),即只需要声明我们的测试输入和期待的结果即可,不需要编程实现。整体测试流程如下:
如何定义API规格
API规格不单只用于API测试,同时也应当应用于API的开发。我们决定采用OAS(OpenAPI Specification)来定义API,开发时也可以考虑利用OpenAPI Generator
生成部分代码。
OpenAPI规范(以前称为Swagger规范)是一种机器可读接口文件的规范,用于描述,生成,使用和可视化RESTful Web服务。它以前是Swagger框架的一部分,在2016年成为一个单独的项目,由Linux基金会的一个开源协作项目OpenAPI Initiative监督。
如何定义测试用例
关于用例的格式,我们最初想在配置文件甚至是在Excel中编写测试用例,在征询了开发人员的意见之后,决定采用Yaml格式的配置文件。因为用例主要还是开发人员来写,对我们工程师来说,Yaml比Excel更容易使用。
至于用例的内容,我们希望在Yaml中定义以下内容:
- 用例的名称和描述
- 预置数据
- 测试的ENDPOINT
- 请求头
- 请求Body
- 期待的响应头
- 期待的响应Body
- 期待的数据库快照
如何准备测试数据
测试数据分为三个部分:
- 执行测试前,事先预置在数据库中的数据
- 执行测试时,在HTTP请求中包含的数据和返回结果中的数据
- 执行测试后的期待数据库快照数据
对于预置数据,我们想用以下两种方式定义:
- CSV文件
- 含有Insert DML的SQL文件
我们只需把对应的数据文件路径配置到Yaml测试用例中,在测试执行前,就可以自动更新到测试用数据库。
对于请求和响应数据,我们希望以下列三种方式定义:
- 直接在Yaml文件中定义
- 将数据定义在JSON文件中,在Yaml中配置JSON的路径
- 将数据定义在模板文件中,在Yaml中配置模板的路径和参数
直接在Yaml文件中定义的做法最方便快捷,适合结构简单的数据,JSON文件适合用于定义结构相对复杂的数据,模板文件可以在多个测试用例中重用。另外,对于JSON格式的响应数据,我们希望在校验时,能够支持基于格式的校验,比如检查JSON中特定的字段格式是否为数字,字符串等,而忽略字段的具体内容。
对于测试后期待的快照数据,我们希望定义在CSV文件中,以便与数据库中的数据进行对比。
如何执行测试
我们希望可以在本地环境和CI环境都可以通过gradle test
命令生成测试代码,并执行测试。
将返回结果与Yaml中配置的期待的响应头、响应Body、数据库快照进行比对,判断测试是否通过。
总结
本篇介绍了项目背景,微服务API测试中的痛点,以及我们理想的解决方案。后续文章将继续介绍工具的设计和实现。
码字不易,如果对你有帮助,请点赞关注加分享,感谢!
近期评论