1、背景

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

2、實踐成果

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

在這種技改需求訴求下，全量json對比組件很好地滿足了需要驗證大量的服務(wù)拆分前接口和服務(wù)拆分后的接口返回json值全量對比。以商家服務(wù)拆分技改為例，技改跨幾個迭代，需要回歸大量的接口（目前該技改測試的接口已過千，還在跨迭代測試中）。測試過程利用全量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());
        }
    }
    TrackingUtils.tracking();
    return diffs;
}

JSONCompareUtils組件改造后適應(yīng)于目前效能平臺適用的自動化平臺組件。

改造后的組件：

改造后的組件名：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 e
    return res

3.3 組件應(yīng)用

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

圖片

圖片

步驟2: 添加組件

圖片

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

圖片

3.4 實踐場景

3.4.1 實踐一

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

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

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

3.4.2 實踐二

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

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

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

3.4.3 實踐三

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

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

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

圖片

圖片

3.4.4 實踐四

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

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

Demo如下：

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

圖片

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

圖片

4、結(jié)論

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

1. 服務(wù)拆分技改類需求中需要對不同服務(wù)兩個或者多個接口返回response全量json結(jié)果對比的場景；
2. 拆分前和拆分后的代碼相同接口需要在相同配置不同染色環(huán)境下返回response全量json結(jié)果對比的場景；
3. 拆分前和拆分后的代碼相同接口返回response全量json需要先排序再對比結(jié)果的場景；
4. BC流量拆分前和拆分后的代碼不同接口路由但是同一個業(yè)務(wù)功能，返回response全量json需要在不同染色多次對比結(jié)果的場景。

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

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