写点什么

自动化实践 - 全量 Json 对比在技改需求提效实践

作者:得物技术
  • 2023-08-08
    上海
  • 本文字数:2996 字

    阅读完需:约 10 分钟

自动化实践-全量Json对比在技改需求提效实践

1 背景

随着自动化测试左移实践深入,越来越多不同类型的需求开始用自动化测试左移来实践,在实践的过程中也有了新的提效诉求,比如技改类的服务拆分项目或者 BC 流量拆分的项目,在实践过程中,这类需求会期望不同染色环境在相同的配置条件下,拆分后的代码和基准 release 代码的接口响应 response 有全量对比结果才能更好达到需求验证点。

2 实践成果

在这种需要对接口返回 response 做全量 json 对比的背景下,商家域新的自动化平台新增了 json 全量对比的组件。在多个技改项目,比如服务拆分和 BC 流量拆分项目中这种比较大,花费人日比较多的项目测试中,应用了 json 全量对比验证。在实践过程中,比如原来要先写自动化,把响应结果挨个验证,或者在不同染色请求跟拆分前代码分别执行再对比结果。


在这种技改需求诉求下,全量 json 对比组件很好地满足了需要验证大量的服务拆分前接口和服务拆分后的接口返回 json 值全量对比。以商家服务拆分技改为例,技改跨几个迭代,需要回归大量的接口(目前该技改测试的接口已过千,还在跨迭代测试中)。测试过程利用全量 json 对比组件,不光测试一轮极大提高了测试效率,在二轮还可以用自动化回归提效。

3 实践过程

3.1 源组件:JSONCompareUtils

本次全量 json 对比引用的源组件是 JSONCompareUtils,是 Artemis 框架提供的。JSONCompareUtils 提供基于万行级 Json 的精确比对能力,这个能力基于一套嵌套降噪配置的递归算法实现。在配置合理的情况下,能快速进行较大 Json 串的比对。详情如下:

引入方式:


方法名:JSONCompare

参数:JSON expect, JSON actual, Properties properties


public static Map<String, String> JSONCompare(JSON expect, JSON actual, Properties properties) {    Map<String, String> diffs = new HashMap<>();
if (null == expect && null == actual) { return diffs; } else if (expect instanceof JSONObject && actual instanceof JSONObject) { diffs.putAll(JSONObjectCompare((JSONObject) expect, (JSONObject) actual, "$", properties)); } else if (expect instanceof JSONArray && actual instanceof JSONArray) { diffs.putAll(JSONArrayCompare((JSONArray) expect, (JSONArray) actual, "$", properties)); } else { diffs.put("$", (expect + COMPARE_ARROW + actual) + "not the same instance type"); }
if (!org.springframework.util.CollectionUtils.isEmpty(diffs)) { for (Map.Entry<String, String> entry : diffs.entrySet()) { logger.info("[key]" + entry.getKey() + "," + "[value]" + entry.getValue()); }
复制代码

3.2 JSONCompareUtils 组件改造

JSONCompareUtils 组件改造后适应于目前效能平台适用的自动化平台组件。

改造后的组件:

改造后的组件名:21471: [JSON] 全量比对-两 Json 传入:对比接口提取返回与入参的 json 异同。

修改点:改成对比两个接口提取返回,提取字段取名 json1、json2。

入参保留 propeties:返回多个时候的排序字段,没有默认空,不排序。

举例:"propeties": "$.data.order=order_no",$.data.order 为 list[Object],以 Object 中 order_no 排序后,再对 list 做对比。

import jsonimport requests
def call(env_vars, g_vars, l_vars, sys_funcs, asserts, logger, **kwargs): param = sys_funcs.get_call_param() path = "http://******/artemis/component/interface-platform/compare/json" method = "POST" actual1 = l_vars.get("json1") actual2 = l_vars.get("json2")
headers = { "Content-Type":"application/json; charset=utf8", } body = { "expect" : json.dumps(actual1,ensure_ascii=False), "actual" : json.dumps(actual2,ensure_ascii=False), "properties" : str(param["propeties"]) } logger.info("Artemis请求body:" + str(body)) try: resq = requests.post( path, data = json.dumps(body), headers = headers, timeout=8 ) res = json.loads(resq.text) logger.info("======================artemis组件结果======================") logger.info(res) asserts.assertTrue(res["success"], msg="调用artemis-interface异常") asserts.assertEqual(str(res["data"]), "{}", msg="存在不一致比对数据 :") except Exception as e: logger.info(f'执行JSON比对失败【{str(e)}】') raise e return res
复制代码

3.3 组件应用

步骤 1: 提取接口返回 json1、json2


步骤 2: 添加组件

步骤 3:对比上面两个接口的提取的返回值

3.4 实践场景

3.4.1 实践一

提取接口返回全量标准被参照对比的标准 json1,再提取新代码中期望跟标准 json1 对比的 json2,添加全量 json 组件,对比 json1 和 json2 的值。

测试场景:服务拆分技改类需求中需要对不同服务两个或者多个接口返回 response 全量 json 结果对比的场景;

提取被参照对比全量 json1 见图一,对比全量 json2 见图二,组件执行结果见图三:

图一

图二

图三

3.4.2 实践二

返回 json 多次设置、多次对比数据。

测试场景:BC 流量拆分前和拆分后的代码不同接口路由但是同一个业务功能,返回 response 全量 json 需要在不同染色多次对比结果的场景

json1、json2 可进行多次设置、多次对比。

3.4.3 实践三

全量 json 对比不同环境返回数据。

测试场景:拆分前和拆分后的代码相同接口需要在相同配置不同染色环境下返回 response 全量 json 结果对比的场景。

服务拆分的接口,不同染色环境对比返回的结果:举例如下:


3.4.4 实践四

全量 json 对比 list 结果返回顺序不一致的数据。

测试场景:拆分前和拆分后的代码相同接口返回 response 全量 json 需要先排序再对比结果的场景

Demo 如下:

服务拆分的接口,请求是一个 list 数组,每次调用返回的 list 里面的顺序可能不一致,可利用组件的参数先排序再对比 json 返回结果,两个接口返回的 json 如下:

可用组件的"propeties": "$.data=userId"(或者"propeties": "$.data=merchantId")json 里面的 list 先排序再对比,这样就规避了 list 返回顺序不一致的情况:

4 结论

在实际测试过程中,技改的需占比也不小,几乎每个迭代每个域都会有技改类的需求。本文为例,举了几个例子涉及提效需求点:

  1. 服务拆分技改类需求中需要对不同服务两个或者多个接口返回 response 全量 json 结果对比的场景;

  2. 拆分前和拆分后的代码相同接口需要在相同配置不同染色环境下返回 response 全量 json 结果对比的场景;

  3. 拆分前和拆分后的代码相同接口返回 response 全量 json 需要先排序再对比结果的场景;

  4. BC 流量拆分前和拆分后的代码不同接口路由但是同一个业务功能,返回 response 全量 json 需要在不同染色多次对比结果的场景;


以上场景均能通过自动化+全量 json 对比组件的方式去提效测试,且在后续回归中直接用自动化覆盖回归,尤其在商家服务拆分跨好几个迭代涉及上千个接口的大的技改类需求中,达到明显的提效效果。


公司目前提供了很多现有的平台和小工具,不同类型的技改需求可以利用平台+小工具模式去实践应用,适合的场景下合理地应用,可以达到事半功倍的效果。


*文/mango


本文属得物技术原创,更多精彩文章请看:得物技术官网


未经得物技术许可严禁转载,否则依法追究法律责任!


发布于: 刚刚阅读数: 10
用户头像

得物技术

关注

得物APP技术部 2019-11-13 加入

关注微信公众号「得物技术」

评论

发布
暂无评论
自动化实践-全量Json对比在技改需求提效实践_json_得物技术_InfoQ写作社区