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());        }    }    
    TrackingUtils.tracking();    
    return diffs;}

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 json
import 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

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

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