自动化脚本实现Json Schema验证
Posted 51Testing软件测试网
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了自动化脚本实现Json Schema验证相关的知识，希望对你有一定的参考价值。
出品|51Testing软件测试网
测试场景中，我们会先做一些SMOKE测试，以便先了解一下基本的测试是否通过，如在API测试中，先验证返回的Json文件一样，在没有具体到细节时，我们会先了解返回的Json文件是否符合正确的Json格式，以及某次字段数据类型、格式是不是和预先定义的相匹配。
今天就介绍一下Rest-Assured支持的Json schema-validator一次验证整个回应的Json文件。
测试框架: Java + Rest-Assured
语言: Java
IDE: Intellij IDEA
项目类型: Maven
https://api.data.gov.sg/v1/environment/air-temperature?date=2020-01-02
公共API开发文档：
https://data.gov.sg/dataset/realtime-weather-readings?resource_id=5dcf8aa5-cf6a-44e4-b359-1173eecfdf4c
为了能让跟着步骤操作的小伙伴们真正地运行起代码来，所以下面是有关配置的操作（注：如您已经熟悉这些配置，可以跳过）。
1. 创建一个新的Maven项目。
2. POM Dependency配置（这里介绍的清楚一些，有时就是因为配置没设好，脚本就是运行不起来）。
1. 创建测试脚本
如下图，这段测试脚本最后一段验证代码 就是对返回的Json文件进行的格式验证。
2. 下面详细讲解一下每段代码的含义
given()-可以看作是测试之前的准备，比如API的path、header、query parameter。
spec(reqSpec)-这里我把所有应该request API的信息写成一个变量，模块化之后方便应用于改变或添加不一样的参数，而应用于多种测试功能。
log().uri()-是打印出当前测试的request API完整的URL。
expect().contentType(ContentType.JSON). and().statusCode(200)-此处是期待当Request API得到回应后，内容是以JSON格式返回，响应代码是200。
when().get().then()...-就是真正地发出请求 （get）request API。
assertThat().body(JsonSchemaValidator.matchesJsonSchemaInClasspath("schema-drf7.json"))-对返回的JSON文件进行预定义的规则验证 (schema-drf7.json 验证规则文件，下个小节中介绍的Schema，不要忘了等下把这里改写好哦）。
1. 变量reqSpec是RequestSpecification类型。
这是Rest-Assured 内置的一个类，我们可以直接使用。
2. 在setup 方法里，我们给reqSpec 指定了Request API 的基本URI以及需要的参数。
.queryParam(), .basePath() 这两个 Rest-Assured 内置的方法，为的就是自由灵活添加 reqesut API 的参数。
3. 分解一下get() 请求
URI: https://api.data.gov.sg/v1/environment/
Path Parameter: air-temperature
Query Parameter: date=2021-03-08
测试中真正发出的 get() 请求完整路径：https://api.data.gov.sg/v1/environment/air-temperature?date=2021-03-08
注意：路径中连接符号?或&，当使用Rest-Assured内置类或参数时会自动识别添加。
4. 注释reqSpec（进一步讲解 reqSpec的用处，如果初学者不太明白，就按下面的代码写测试用例)。
下面的代码中注释了 reqSpec， 直接使用.baaseUri().basePath().queryParam().queryParam()在测试用例中，这样和使用reqSpec效果一样。
这种方法就是简单、方便、直观。麻烦的一点是测试用例多的时候，参数或有了新的变更，每个用例都必须要重复地改写。
这里强调一下我自己的观点：测试的目的是确保相关的功能被检验过且没有缺陷。至于你是用怎样的方法检验的，在技术上没必要钻牛角尖，你怎么写都可以，只要目的达到了。每一种写法都存在优缺点，千万不要因为技术让测试本源本末倒置了。
本示例中使用的 JSON schema 版本7。
1. 复制示例中用的 Request API 的get()路径，然后粘贴到你的浏览器并打开它。
此时你会得到开放数据返回的当天气温状况以JSON 格式。
2. 复制返回的JSON文件，打开Jsonschmea 生成器在浏览器中（https://extendsclass.com/json-schema-validator.html）。
粘贴复制的JSON文件到左边的文本框里，然后点击 Generate Schema From JSON按钮，右边的文本框里就会自动生成以draft-07的schme文件。
3. 复制生成的Schema 文件，新建一个.json文件在测试项目的src>test>resources>的路径下。
注意，这里的路径一定要用对。然后将复制的schema文件内容粘贴到新建的.json文件里，保存一下文件。
现在，我们的 schema 文件就准备好了。
注意，真实的环境下一定要用正确Json的文件生成 Schema文件，示例中因为我们不知道需求，就只有把结果当做需求规则了。
通过阅读公开的开发文档，我们只知道返回的日期格式规定如下表所示。但是有些数据我们并不知道返回是小数，或是整数？有哪些字段是必需的，为此我们不可能使用多个schmea文件，况且这里并没有规则什么时候返回小数，什么时候返回整数？
在生成的schema文档中，显示的是源数据（即生成schema时用的Json文件中的数据）。
如上述，实际测试中这些数据是会变更的。这时如果用这个生成的规则与返回的真实数据相对比就会出错。
不用担心：我们可以改写一些验证规则让这个schema 工作起来更有效。
1. 必需字段验证
如下图：required 的部份，这里就根据上面提到的公开文档中说明定义成是必需的。换句话说，就是在与真实返回的JSON对比时，这些信息是一定要出现的，否则就认为返回的数据不正确。定位是root根结点下 。
子节点 root /metadata 的必需项 :
2. 使用正则表达式验证不确定返回值
比如下图pattern定义root/items/items/readings/items/value字段的数据可以是小数，也可以是整数。
这里返回的JSON内容只要是其中任何一个值就不会出错，否则验证就通不过。
1. 运行在IDE
右键点击测试用例方法，在弹出的菜单列表中点击Run测试用例方法名。收割的时候到了，快看一下结果吧。
2. 运行MVN
在控制台的路径下中执行命令mvn test， 可以看到返回结果测试通过。
希望这篇文章对大家有所帮助，这也是我的愿望了。对于验证这一部分，希望大家灵活运用正则表达式来实现真实测试场景中的需求。想一下，上面提到的日期格式的规则应该怎样写呢？
欢迎小伙伴们留言分享你们的学习，大家共同进步。
点击阅读☞
点击阅读☞
点击阅读☞
点击阅读☞
点击阅读☞
以上是关于自动化脚本实现Json Schema验证的主要内容，如果未能解决你的问题，请参考以下文章