1 背景

隨著自動化測試左移實踐深入，越來越多不同類型的需求開始用自動化測試左移來實踐，在實踐的過程中也有了新的提效訴求，比如技改類的服務拆分項目或者BC流量拆分的項目，在實踐過程中，這類需求會期望不同染色環(huán)境在相同的配置條件下，拆分后的代碼和基準release代碼的接口響應response有全量對比結(jié)果才能更好達到需求驗證點。

2 實踐成果

在這種需要對接口返回response做全量json對比的背景下，商家域新的自動化平臺新增了json全量對比的組件。在多個技改項目，比如服務拆分和BC流量拆分項目中這種比較大，花費人日比較多的項目測試中，應用了json全量對比驗證。在實踐過程中，比如原來要先寫自動化，把響應結(jié)果挨個驗證，或者在不同染色請求跟拆分前代碼分別執(zhí)行再對比結(jié)果。

在這種技改需求訴求下，全量json對比組件很好地滿足了需要驗證大量的服務拆分前接口和服務拆分后的接口返回json值全量對比。以商家服務拆分技改為例，技改跨幾個迭代，需要回歸大量的接口（目前該技改測試的接口已過千，還在跨迭代測試中）。測試過程利用全量json對比組件，不光測試一輪極大提高了測試效率，在二輪還可以用自動化回歸提效。

3 實踐過程

3.1 源組件：JSONCompareUtils

本次全量json對比引用的源組件是JSONCompareUtils，是Artemis框架提供的。JSONCompareUtils提供基于萬行級Json的精確比對能力，這個能力基于一套嵌套降噪配置的遞歸算法實現(xiàn)。在配置合理的情況下，能快速進行較大Json串的比對。詳情如下：

引入方式：

方法名：JSONCompare

參數(shù)：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傳入：對比接口提取返回與入?yún)⒌膉son異同。

修改點：改成對比兩個接口提取返回，提取字段取名json1、json2。

入?yún)⒈Ａ魀ropeties：返回多個時候的排序字段，沒有默認空，不排序。

舉例："propeties": "$.data.order=order_no"，$.data.order為list[Object]，以O(shè)bject中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組件結(jié)果======================")logger.info(res)asserts.assertTrue(res["success"], msg="調(diào)用artemis-interface異常")asserts.assertEqual(str(res["data"]), "{}", msg="存在不一致比對數(shù)據(jù) :")except Exception as e:logger.info(f'執(zhí)行JSON比對失敗【{str(e)}】')raise ereturn res

3.3 組件應用

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

?

?

步驟2: 添加組件

?

步驟3:對比上面兩個接口的提取的返回值

?

3.4 實踐場景

3.4.1 實踐一

提取接口返回全量標準被參照對比的標準json1，再提取新代碼中期望跟標準json1對比的json2，添加全量json組件，對比json1和json2的值。

測試場景：服務拆分技改類需求中需要對不同服務兩個或者多個接口返回response全量json結(jié)果對比的場景；

提取被參照對比全量json1見圖一，對比全量json2見圖二，組件執(zhí)行結(jié)果見圖三：

圖一

圖二

圖三

3.4.2 實踐二

返回json多次設(shè)置、多次對比數(shù)據(jù)。

測試場景：BC流量拆分前和拆分后的代碼不同接口路由但是同一個業(yè)務功能，返回response全量json需要在不同染色多次對比結(jié)果的場景

json1、json2可進行多次設(shè)置、多次對比。

?

3.4.3 實踐三

全量json對比不同環(huán)境返回數(shù)據(jù)。

測試場景：拆分前和拆分后的代碼相同接口需要在相同配置不同染色環(huán)境下返回response全量json結(jié)果對比的場景。

服務拆分的接口，不同染色環(huán)境對比返回的結(jié)果：舉例如下：

?

?

3.4.4 實踐四

全量json對比list結(jié)果返回順序不一致的數(shù)據(jù)。

測試場景：拆分前和拆分后的代碼相同接口返回response全量json需要先排序再對比結(jié)果的場景

Demo如下：

服務拆分的接口，請求是一個list數(shù)組，每次調(diào)用返回的list里面的順序可能不一致，可利用組件的參數(shù)先排序再對比json返回結(jié)果，兩個接口返回的json如下：

?

可用組件的"propeties": "$.data=userId"（或者"propeties": "$.data=merchantId"）json里面的list先排序再對比，這樣就規(guī)避了list返回順序不一致的情況：

?

4 結(jié)論

在實際測試過程中，技改的需占比也不小，幾乎每個迭代每個域都會有技改類的需求。本文為例，舉了幾個例子涉及提效需求點：

1.服務拆分技改類需求中需要對不同服務兩個或者多個接口返回response全量json結(jié)果對比的場景；

2.拆分前和拆分后的代碼相同接口需要在相同配置不同染色環(huán)境下返回response全量json結(jié)果對比的場景；

3.拆分前和拆分后的代碼相同接口返回response全量json需要先排序再對比結(jié)果的場景；

4.BC流量拆分前和拆分后的代碼不同接口路由但是同一個業(yè)務功能，返回response全量json需要在不同染色多次對比結(jié)果的場景；

以上場景均能通過自動化+全量json對比組件的方式去提效測試，且在后續(xù)回歸中直接用自動化覆蓋回歸，尤其在商家服務拆分跨好幾個迭代涉及上千個接口的大的技改類需求中，達到明顯的提效效果。

公司目前提供了很多現(xiàn)有的平臺和小工具，不同類型的技改需求可以利用平臺+小工具模式去實踐應用，適合的場景下合理地應用，可以達到事半功倍的效果。

*文/mango

本文屬得物技術(shù)原創(chuàng)，更多精彩文章請看：得物技術(shù)官網(wǎng)

未經(jīng)得物技術(shù)許可嚴禁轉(zhuǎn)載，否則依法追究法律責任！