貨拉拉大資料測試質效提升之路

作者簡介：

• 王文豔，來自貨拉拉/技術中心/質量保障部，測試專家，主要負責貨拉拉大資料領域的質量保障和效能建設工作。
• 竇婷，來自貨拉拉/技術中心/質量保障部，資深測試工程師，主要負責貨拉拉大資料領域的質量保障和效能建設工作。
• 董帥，來自貨拉拉/技術中心/質量保障部，高階測試工程師，主要負責貨拉拉大資料領域的質量保障和效能建設工作。

1. 背景與挑戰

隨著貨拉拉業務的高速發展，大資料在使用者行為分析、廣告定向投放、風險控制、使用者畫像、為公司管理層和運營團隊提供決策幫助等方面，得到了越來越廣泛的應用。
大資料的源資料來源於業務資料、埋點資料等，每天有百億級的資料互動，業務資料的複雜性和快速增長的資料量級，也對質量保障有了更高的要求。我們需要從高質量、高效率、高可用、高主動性 4 個方面來保證大資料的質量。對於大資料測試人員來說也是很大的挑戰，以下圖片從技能、資料特點、效率三個方面分析了傳統測試與資料測試區別，總結了貨拉拉資料測試的早期的問題及大資料測試的痛點。

1.1 技能方面

資料測試需要更高的技術要求。除了傳統的黑盒、白盒、灰盒測試能力，資料測試還需要掌握以下幾個方面的能力：

• 海量資料測試能力：資料測試需要掌握不同的資料庫的 SQL 技能來處理大量的資料，能夠有效地處理和分析這些資料，找出其中的問題。
• 資料倉儲分層測試能力：資料倉儲通常會分為多個層次，每個層次的資料都需要進行測試。測試人員需要理解每個層次的資料結構和業務邏輯的不同，才能進行有效的測試。
• 資料驗收標準的靈活制定能力：資料測試的驗收標準可能會根據業務需求和資料特性進行變化，測試人員需要能夠靈活地制定和調整這些標準。
• 資料洞察能力：資料測試不僅僅是找出資料中的錯誤，更重要的是要有透過資料洞察業務的能力。這就需要測試人員具有一定的資料分析和業務理解能力。 因此，資料測試人員不僅需要具備傳統的測試技能，還需要具備資料處理、資料分析和業務理解等多方面的能力。

1.2 資料方面

傳統測試主要關注業務邏輯，資料量少，結構單一。大資料測試面臨資料量大，結構複雜的挑戰，同時對資料質量要求更高。大資料的源資料來源於業務資料，所以資料質量極易受到業務問題的影響，導致線上資料質量出現問題。想從海量資料中發現問題，猶如大海撈針，在早期，我們的資料測試手段是有限的，沒有測試工具及平臺來支撐，導致我們存在以下難點。

• 資料問題發現難：海量的資料量使得人工逐條檢查幾乎不可能，結構化資料和非結構化資料，使得資料問題的發現變得更加困難，大資料的質量問題可能包括資料的準確性、完整性、一致性、時效性等多個方面，結合不同的業務場景，使得測試場景即多又複雜。多種原因使得資料問題發現難。
• 資料質量保障難：資料質量保障是確保資料的準確性、完整性、一致性、可靠性和及時性的重要過程。這個過程包括資料校驗、資料監控、資料治理和建立資料質量標準等關鍵步驟。為了實現資料質量保障，需要結合技術手段和管理手段，採用全面和系統的方法來進行。

1.3 效率方面

業務測試的標準是業務邏輯，對功能的測試結果是即時可見的。但資料測試的標準不僅是業務邏輯，還包括資料質量，資料質量的問題也會引發很大的問題。在早期，手工的資料測試、人員的緊缺、激增的資料業務需求，導致在測試效率方面存在很大的痛點。具體難點表現在如下：

• 測試用例管理難：同一表每次需求改動，由於業務資料的變化，還需重新計算結果，測試人員需要重新進行測試，由於缺少平臺的支撐，測試用例無法進行有效沉澱及統一管理，導致測試用例複用率低。
• 迴歸效率低：最開始是手工進行測試，需要手動進行測試迴歸，迴歸耗時長，隨著業務擴充套件，迴歸範圍擴大，手工迴歸耗時耗力，不能滿足專案需求，這些導致了整體的測試效率低。

2. 方案與目標

針對貨拉拉大資料測試保障的重點和難點，我們採用了以下幾種解決方案：

• 測試過程簡單化：用例模型、模版、業務場景靈活可配置，平臺自動生成對應指令碼，無需測試人員手工編寫，標準化用例編寫流程的同時，也降低用例編寫成本和門檻，提高測試效率。
• 資料測試自動化：支援根據場景靈活配置資料測試自動化用例和場景，同時可一鍵將測試用例轉為自動化用例，降低資料測試自動化編寫成本及迴歸測試成本，提高測試效率。
• 資料質量監控告警：建設定時線上巡檢監控及異常告警的能力，從被動跟著暴露的資料質量問題走，轉變為主動發現攔截問題。 為了達成上述目標，我們打造了大資料測試平臺，致力於資料測試過程中每個環節都可自動化，縮短測試周期，提高人效。做到僅需簡單的操作，0 資料測試經驗同學也能輕鬆上手，無需具備不同資料庫複雜 SQL 程式設計能力，降低資料測試技術門檻。同時還提供了用例沉澱的能力，做到根據配置生成測試用例-->執行-->智慧分析-->轉換監控-->沉澱自動化的良性鏈路閉環。

3. 能力建設

3.1 平臺架構介紹

大資料測試平臺基於 Spring Boot 構建，並依賴於混合引擎進行資料計算。它提供了一系列強大的功能，包括資料質量模型構建、資料質量模型執行、資料質量任務管理、異常資料發現儲存以及告警功能等。此外，該平臺還提供了資料質量模型資源隔離和許可權隔離等特性，確保了資料的安全性和私密性。該平臺具備高併發、高效能和高可用的大資料質量管理能力，能夠有效地滿足使用者在大資料測試和管理方面的需求。

大資料測試平臺的架構設計精細且全面，主要包括應用層、服務層、資料層和儲存層。

• 應用層：是平臺的入口，主要提供了模板管理、用例管理、協議管理和定時任務管理等功能。這些功能為使用者提供了便捷的操作介面，使得資料測試過程更加高效和簡便。
• 服務層：提供了平臺的基礎能力，包括規則計算、資料規則定義和結果分析等基本能力。這些能力為資料測試提供了強大的支援，確保了測試的準確性和有效性。
• 資料層：包含了大資料測試的來源資料和平臺的後設資料。大資料測試來源資料主要包括資料倉儲的資料和業務資料等，這些資料是資料測試的基礎和來源。
• 儲存層：支援多種資料型別的儲存，包括 mysql、hive、doris、phoenix、hbase 等。這些資料儲存方式為資料的儲存和管理提供了多樣化的選擇，滿足了不同使用者的需求。

3.2 平臺核心能力

大資料測試平臺主要涵蓋四大核心功能：測試管理、規則執行、結果分析以及監控告警。在大資料測試流程中，我們有能力在平臺上生成測試用例並沉澱這些測試用例，測試用例的生成是基於平臺上配置的測試執行規則，這主要涉及到規則的定義。隨後，我們會根據配置的測試規則進行計算。對於這些計算結果，我們將進行深度分析。此外，我們還可以設定任務定時執行，一旦執行失敗或者結果未達到預期，平臺將及時進行通知。接下來，我們將詳細闡述這四大核心功能的特性和優勢。

3.2.1 測試管理能力

大資料測試平臺的測試管理能力主要由兩大模組構成：用例模板模組和用例管理模組。

• 用例模板模組：負責管理和維護常用的用例模板，它支援管理用例模板，允許使用者根據實際需求靈活自定義用例模板。這大大提高了用例模板的適用性和靈活性。用例模版支援單表模型、多表模型和自定義模型等多種模型，平臺還預設了多種用例模版如空值檢查、空白檢查、數字檢查、列舉檢查等常見檢查的資料質量校驗模板，簡化了資料質量模型的定義。
• 用例管理模組：包含了根據模板生成測試用例、儲存和管理測試用例的功能。用例管理模組可以根據模板自動生成各種測試用例，從而節省了編寫測試用例的時間。更進一步，它還可以將測試用例轉化為自動化測試用例。 模版配置如 “欄位空值率” 模版：

select 
[count( case when {{emptyFields}} is null or {{emptyFields}} ='' then 1 end )/count(1) as {{emptyFields}}_rate $,;emptyFields$]
from {{tableName}} 
where 1=1 and [{{partField}} = date_sub(current_date(),1) $and;partField$] ;

根據模版生成測試用例核心程式碼【程式碼已簡化，只保留核心邏輯】：

//解析模版，轉化成規則配置類
MonitorRuleTemple monitorRuleTemple = covertFromModule(config,MonitorAgreement.class);

//獲取規則配置中的sql語句
String sql =monitorRuleTemple.getSql();

/*處理sql語句中帶[]符號的部分，[]部分為迴圈部分，[表示式 $連線符號;迴圈變數$]
如下的表示式，
[{{partField}} = date_sub(current_date(),1) $and;partField$]
若partField的實際引數值為2個欄位：dt、city_id時，根據如上表示式，生成的結果為："dt ='2024-06-15' and city_id=1000"
*/
if(Objects.nonNull(sql)){
    sql =sqlProcess(sql,paramsMap);
    monitorRuleTemple.setSql(sql);
}

/*
處理sql語句中，除了[]之外的{{param}}引數。這裡會根據實際引數替換表示式中的值，
如下表示式：{{param}},若param的值為：city_id時，則會將sql語句中所有的{{param}}都替換為city_id欄位。
*/
ruleProcess(monitorRuleTemple,paramsMap);

return monitorRuleTemple;

3.2.2 規則執行能力

規則執行是大資料測試平臺的核心能力，主要由規則配置、規則計算兩個功能組成。

• 規則配置：是大資料測試過程的關鍵步驟，這裡我們將根據業務的需求，將測試 SQL 程式碼及校驗規則配置成待執行的配置，這個過程可以被抽象為規則配置。
• 規則計算：是對配置規則的執行和計算。我們的平臺支援混合引擎能力，可以針對不同的資料來源進行執行。目前已經支援的資料來源包括 MYSQL、Hive、Doris、Phoniex 等資料庫、以及 Curl，實現了跨庫資料對比。 混合引擎執行核心程式碼如下【程式碼已簡化，只保留核心邏輯】：

//貨運規則配置中指令碼中資料來源的型別
DataSourceType sourceType = DataSourceType.findByTypeByte(dataSourceType);
//根據資料來源的型別，獲取不同的資料來源客戶端執行方法
switch (sourceType) {
    case INTERFACE_CURL:
        queryTask = curlClient;
        break;
    case INTERFACE_HTTP:
        queryTask = httpClient;
        break;
    case HIVE:
        queryTask = idpClient;
        break;
    case MYSQL:
        queryTask = mySqlClient;
        break;
    case HBASE:
        queryTask = hbaseClient;
        break;
    case PHOENIX:
        queryTask = phoenixClient;
        break;
    default:
        queryTask = null;
}
return queryTask;

3.2.3 結果分析能力

在大資料測試執行結果出來之後，我們就需要對其進行深入分析。在協議配置中，我們支援結果預設，且支援多種規則比較的型別如大於、大於等於、小於、小於等於、等於、不等於、同環比、範圍比較等。除此之外，規則配置中還支援原始指標和轉換指標，對於 SQL 的執行結果，我們可以對執行結果進行表示式再計算之後再進行規則比較。
規則比較核心程式碼【程式碼已簡化，只保留核心邏輯】

//這裡舉其中一種比較規則的實現方式：範圍的比較的實現方式
//首先檢查輸入的資料的型別，僅支援數值型別
RuleCheckTypeStrategy.checkNotSupportNonNumeric(ruleResultContext.getActualResult(), this);

//獲取預期的範圍
Double expectRange = Double.valueOf(ruleResultContext.getExpectRange());

//計算實際值的差值的範圍
Double acutalRangeBoundary = RuleCheckTypeStrategy.computeThresholds(ruleResultContext.getActualResult(), this);

//若實際值的範圍在預期範圍內，則規則比較透過，否則不透過
boolean flag = true;
flag = compareRange(expectRange,acutalRangeBoundary);
return flag

執行結果展示

3.2.4 監控告警能力

大資料測試平臺還提供了定時排程、告警通知的能力，任務中支援定時執行的配置，定時配置是使用 corn 表示式方式，可以靈活支援使用者的定時執行的需求。平臺還提供了告警通知能力，任務配置中可以配置失敗告警通知人或通知群，在配置的規則每天定時執行的結果出現問題時，我們可以及時收到告警通知。這些功能可以滿足大資料測試的監控告警的需求。

4. 平臺實踐與成果

隨著貨拉拉大資料測試質量平臺能力已經具備，接下來我們將從三個階段介紹如何使用平臺能力賦能貨拉拉大資料質量全流程測試

4.1 平臺實踐

4.1.1 功能測試階段

大資料測試時，我們會根據業務需求轉換成規則配置，然後對規則做分析和預置，使用模版功能可以一鍵生成用例，並且支援一鍵執行用例。

• 配置資料模版並生成測試用例：我們根據資料需求選擇不同的資料模版。根據選擇的用例模版規則自動生成測試 SQL，一鍵生成測試用例。這些用例可以執行驗證、執行冒煙用例或進行資料產品驗收。
• 智慧分析測試和資料探查：我們還會測試表關聯的下游表，對下游表的關聯欄位進行精準的分析驗證，進一步進行資料探查以發現可能出現的 bug。智慧分析和資料探查工具為資料的高質量輸出提供了保障。
• 結果分析判斷和用例沉澱：透過配置中預置的預期結果，能夠快速智慧地判定用例執行結果。此外，還可以將測試用例沉澱成自動化用例，以進一步覆蓋開發提測和測試迴歸場景下的資料質量。

4.1.2 自動化迴歸階段

功能測試完成之後，我們可將一些用例一鍵沉澱成自動化用例，可用於需求的自動化迴歸測試。

• 自動化用例沉澱：篩選可複用的測試用例一鍵沉澱為自動化用例，加入到迴歸測試庫中，需求改動之後，選沉澱的自動化用例進行迴歸測試，提高迴歸效率，持久保障資料質量。
• 自動化資料測試場景：自動化測試可應用於大資料平臺資料流轉、業務系統資料遷移、資料應用系統和迴歸測試等場景中，複用自動化測試用例及多工並行執行自動化用例，極大縮短了測試時間，在這些資料場景測試中，測試時間可縮短約 70%。

4.1.3 線上監控階段

無論實時或離線的大資料平臺任務和庫表資料，都需新增監控任務以便及時發現並解決問題。大資料測試平臺已提供了一套完整的線上質量監控功能，實現全天候的資料質量保障。
我們已針對以下型別新增了監控告警：

監控型別	描述
資料指標監控	對欄位級的監控，監控規則如：資料掉底、同環比、列舉值、資料範圍、欄位關係等
橫向資料監控	大資料的產品和公司其他職能部門的同類產品指標的橫向對比，如大資料和業務資料的實時橫向對比等
豎向資料監控	大資料不同產品間的同類指標的對比，如實時資料和離線資料的對比，不同產品間履約類指標的對比等
業務邏輯異動監控	不同業務資料反映了該業務正常運營的情況，業務資料的異動同時也代表該業務有可能出現問題，如畫像人群名稱的監控，交易金額倒掛的監控等
資料應用鏈路監控	監控資料應用全流程的資料準確性、及時性、一致性

隨著監控內容的豐富，線上質量得到了更好的保障。在配置監控告警時，我們可以設定不同的警告級別，並根據級別以不同方式通知負責人，如電話、簡訊、飛書等。
飛書告警示例：

4.2 成果展示

4.2.1 全流程提效

• 全流程提效：從用例一鍵生成一鍵執行到用例一鍵轉成自動化再到線上資料質量巡檢能力的實現和應用，使我們的資料測試周期從 5 天降低到 1.5 天，每個需求的額外工時也從 22 小時降低到 3.58 小時，也讓我們有更豐富的手段和方法為 HLL 的資料質量保駕護航。
• 多場景應用：適用於大資料平臺資料流轉的測試場景、業務系統資料遷移的測試場景、資料標準落標的測試場景、監管報送類系統的測試場景、資料應用系統的測試場景、迴歸測試場景等，截止到當前，已支援 200+ 需求，1000+ 的執行次數，為我們節省 800+ 人日。

4.2.2 質量提升

• 質量資料：透過大資料測試平臺，總計發現 300+ 問題，其中監控告警感知異常變動 1000+ 次，幫助資料測試發現 30+ 問題，及時發現因上游任務變更、業務異動、線上資源緊張等原因導致的異常，避免對線上造成更深的影響。
• 業務覆蓋：3000+ 的自動化和監控用例，100% 覆蓋核心表，資料應用鏈路 100% 覆蓋，及時發現核心表的線上資料異動，以及資料應用的線上業務異常。

5. 未來展望

隨著智慧化的發展，未來我們希望大資料的測試能夠更智慧更高效，達到智慧化一體化。

• 智慧建模：資料測試場景建模 - 根據不同業務場景靈活進行資料測試場景建模：自適應訂單、使用者、司機、風控、營銷、賬單模型等。
• 智慧診斷：利用大模型智慧預測任務改動的影響範圍和風險點，進行精準測試。
• 智慧測試: 根據診斷結果，利用大模型的能力智慧生成用例、自動化提及線上監控。