应用场景

　　测试场景中，我们会先做一些SMOKE测试，以便先了解一下基本的测试是否通过，如在API测试中，先验证返回的Json文件一样，在没有具体到细节时，我们会先了解返回的Json文件是否符合正确的Json格式，以及某次字段数据类型、格式是不是和预先定义的相匹配。

　　今天就介绍一下Rest-Assured支持的Json schema-validator一次验证整个回应的Json文件。

　　测试框架: Java + Rest-Assured

　　语言: Java

　　IDE: Intellij IDEA

　　项目类型: Maven

　　公共API 地址：

　　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

　　Rest-Assured 项目配置

　　为了能让跟着步骤操作的小伙伴们真正地运行起代码来，所以下面是有关配置的操作（注：如您已经熟悉这些配置，可以跳过）。

　　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，不要忘了等下把这里改写好哦）。

　　reqSpec 变量化

　　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 准备

　　本示例中使用的 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， 可以看到返回结果测试通过。

　　结语

　　希望这篇文章对大家有所帮助，这也是我的愿望了。对于验证这一部分，希望大家灵活运用正则表达式来实现真实测试场景中的需求。想一下，上面提到的日期格式的规则应该怎样写呢？

　　欢迎小伙伴们留言分享你们的学习，大家共同进步。

作者：胡军英   

来源：51Testing软件测试网原创