自动化脚本实现Json Schema验证

发表于:2021-4-06 09:48  作者:胡军英   来源:51Testing软件测试网原创

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试技术 自动化测试

  应用场景
  测试场景中,我们会先做一些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会员投稿,51Testing软件测试网及相关内容提供者拥有内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。

评 论

论坛新帖



建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海信义律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2021, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道