自动化实践 - 全量 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
3.2 JSONCompareUtils 组件改造
JSONCompareUtils 组件改造后适应于目前效能平台适用的自动化平台组件。
改造后的组件:
改造后的组件名:21471: [JSON] 全量比对-两 Json 传入:对比接口提取返回与入参的 json 异同。
修改点:改成对比两个接口提取返回,提取字段取名 json1、json2。
入参保留 propeties:返回多个时候的排序字段,没有默认空,不排序。
举例:"propeties": "$.data.order=order_no",$.data.order 为 list[Object],以 Object 中 order_no 排序后,再对 list 做对比。
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 结论
在实际测试过程中,技改的需占比也不小,几乎每个迭代每个域都会有技改类的需求。本文为例,举了几个例子涉及提效需求点:
服务拆分技改类需求中需要对不同服务两个或者多个接口返回 response 全量 json 结果对比的场景;
拆分前和拆分后的代码相同接口需要在相同配置不同染色环境下返回 response 全量 json 结果对比的场景;
拆分前和拆分后的代码相同接口返回 response 全量 json 需要先排序再对比结果的场景;
BC 流量拆分前和拆分后的代码不同接口路由但是同一个业务功能,返回 response 全量 json 需要在不同染色多次对比结果的场景;
以上场景均能通过自动化+全量 json 对比组件的方式去提效测试,且在后续回归中直接用自动化覆盖回归,尤其在商家服务拆分跨好几个迭代涉及上千个接口的大的技改类需求中,达到明显的提效效果。
公司目前提供了很多现有的平台和小工具,不同类型的技改需求可以利用平台+小工具模式去实践应用,适合的场景下合理地应用,可以达到事半功倍的效果。
*文/mango
本文属得物技术原创,更多精彩文章请看:得物技术官网
未经得物技术许可严禁转载,否则依法追究法律责任!
版权声明: 本文为 InfoQ 作者【得物技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/9146904175920b10d29eea56c】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论