在數據測試中，需要劃分好測試邊界，數據質量保障除了要關注數據層的測試（指標/模型/數倉表），更不可忽視的是數倉是整條業務鏈路中的一環，對接全域業務提供的查詢能力及造數能力亦是需要重點關注的地方。數據產品的數據來源是嚴選的業務鏈路，產出的數據也是要反哺業務鏈路，最終實現推動業務發展。以下從數據測試能力分層、數倉造數能力展開嚴選數據質量保障建設之路的介紹。

1 前言?

嚴選的數據產品，是依托于嚴選電商業務鏈路，通過離線和實時兩種數據處理方式提供分析型數據，并最終希望實現數據驅動業務發展。先來看下嚴選的數據產品的架構層級圖：從層級圖可以看出，數據產品應用是最上層的數據表現層。從數據產品層級圖，我們可以對比下，數據產品測試跟應用測試的流程區別到底在哪兒： 非數據產品的測試流程一般是： 數據產品的測試流程則為： 從以上鏈路可以看出，數據產品的測試鏈路更長，復雜度也多了一塊數據鏈路的測試。

2 數據產品測試的現狀及痛點 根據目前現狀，嚴選數據產品測試存在的一些明顯的痛點： 數據質量保障的測試不管從業務需求和產品定位上都應該是優先級更高的測試線路，要對數據質量本身提供更高的關注度。 數據指標正確性的人工核對的方式也讓QA很難更好的把控整體的數據質量，自動化的回歸能力也不具備。 因為數據敏感性的問題，數據產品相關的測試工作（如：接口測試）只能通過本地部署的一些測試框架來支持，一直沒有平臺化。 嚴選數倉一直沒有測試環境，目前所有數據產品項目的測試環境都是使用的生產數據，業務線測試環境中涉及的模型數據不能展示及查詢。?

3 脫敏服務原理及使用?

3.1 脫敏原理 從業務使用角度，我們希望脫敏服務能提供怎樣的能力： 采用SDK+獨立脫敏服務架構，具備多種靈活自定義脫敏方式； 支持黑白名單配置的定制化脫敏需求； 即插即用的輕量級開發。 基于以上幾個方面的原則，我們經過一段時間的調研，最終敲定了脫敏服務的架構：未接入脫敏服務：正常的業務流程是后端服務通過dqs從數倉模型中查詢數據，經過一定的聚合處理，返回給前端展示。接入脫敏服務：應用后端先通過dqs從數倉中查詢數據，此時應用中嵌入的sdk會通過openid或者ntess解析中拿到的uid和請求的url返回給脫敏服務，脫敏服務，根據是否uid在脫敏白名單中，來決定是不是繼續走脫敏服務。當命中uid白名單，服務會繼續判斷要對應用中的哪些返回（接口粒度）做脫敏，做何種具體規則的脫敏。也可以對接口中的字段粒度做是否脫敏的黑名單配置，靈活度很高。從配置文件詳細解讀脫敏服務流程： 識別要脫敏的賬號（白名單） 支持接口粒度的脫敏配置，支持正則（白名單） 識別需要脫敏的數據類型（int percent double long） 識別脫敏字段黑名單（黑名單） 脫敏字段的脫敏規則設定?

3.2 適用場景及脫敏效果 數據脫敏服務采用SDK+獨立脫敏服務架構，具備多種靈活自定義脫敏方式。目前已在伏羲&VIPAPP落地，且同時具有對PC端和app端脫敏的能力。數據敏感產品線已具備測試分層能力，并可支持前端開發使用外包人員。亦可支持，其他同類型的數據產品項目接入，可以靈活拔插。

3.3 在實際業務線上面的數據脫敏效果 伏羲頁面數據指標趨勢圖脫敏前后對比：脫敏前：脫敏后：

4 脫敏服務演進之數倉造數服務 脫敏服務，它是脫敏，但是我們希望它不僅僅是脫敏。它本質上是Mock能力的一部分，但是它從線上引流生產數據來做Mock的思想是可以指導我們在測試環境的造數能力上再上一個臺階。數據脫敏服務的持續演進，正式解決了上述問題，當前在嚴選已經提供了一站式生產數據引流下行及脫敏能力，結合數據工廠，MOCK中心對于各業務線數據相關場景提供了更豐富和貼近線上的造數能力。

4.1 什么樣的問題催生了數倉造數服務的誕生 嚴選數倉沒有對接全業務域的測試環境，測試環境的數據請求數倉的線上環境，由于測試環境和生產數據不一致的原因，無法從數倉查詢到數據返回，阻塞了進一步的測試環境的造數和測試流程。目前業務域獲取數倉數據的返回，一般有三種方式： 屏蔽掉數倉的接口，開發額外實現mock開關以及mock相關代碼，打開mock開關，在Apollo中配置相關測試數據進行測試，但是這種方式需要額外開發并會將部分測試代碼帶到線上。 使用測試環境和線上環境均存在的數據，比如skuid，記錄下來后續持續使用。但是會有測試覆蓋度的問題，且部分場景需要數據側及算法側的特殊配置。 通過數據開發同學配合,在數倉倉頡(數倉模型管理系統)建個測試模型，手工新建模型字段，按照數據格式造數據，然后去猛犸新建同步任務，將hive表同步到mysql，然后通過統一查詢服務(dqs)來查詢數據。 所以，我們希望按照脫敏服務線上引流然后修改數據的思路，針對當前業務某些鏈路上對數倉查詢的功能，確保測試環境請求數倉統一查詢服務（dqs）的每次查詢都有對應的報文信息返回。同時，數倉查詢落地到具體的業務鏈路，帶有業務特色之后，亦能支持特殊業務規則下數倉數據的查詢場景的造數及編排能力。

4.2 數倉造數服務 統一查詢服務（dqs）是整個數倉為全域業務提供數倉數據查詢的唯一出口。統一查詢服務提供http形式的查詢，可使用封裝的SDK包來調用；把離線、實時等不同數據源的集市數據抽象為模型維度和指標，對各業務提供統一的數據查詢服務。基本原理圖如下：業務域通過dqs查詢數倉數據的場景分為三大類： 全量查詢類，沒有具體查詢字段。 特定模型字段值的查詢（比如從模型dm_yx_sku_extend_info中查詢skuId=10008650的數據），此時需要測試環境和線上環境數據一致從數倉獲取數據（測試環境數據請求數倉線上環境）。 聯動依賴查詢下的場景，測試環境從數倉查詢后，需要通過查詢結果繼續反查測試環境數據進行后續操作。 基于這些查詢場景，我們對數倉造數服務需要提供的能力也就清楚了。第一，希望先解決測試環境請求線上，沒有數據返回的問題；第二，通過修改返回的數據讓線上環境查詢數據跟測試環境對應起來；第三，支持有關聯關系的多模型查詢數據的編排能力。

4.2.1 數倉造數服務原理 原理圖：方案思路：簡述：輸入基礎信息-->發送查詢模型請求-->脫敏線上模型數據--> Mock數據修改--> 生成規則鏈接替換dqs請求地址-->數據在測試環境回顯① 業務方在嚴選數據工廠--數倉規則入口，輸入需要查詢的模型標識、字段，數據條數。② 首先根據輸入的模型，select all查詢到模型對應的全部的數據（如非首次查詢，數倉造數服務首先緩存上次查詢及修改結果，直接返回，不走后續查詢鏈路）。③ 拉取線上模型數據后，進行數據脫敏后返回查詢的模型數據和報文信息。④返回的模型數據及報文展示在數據工廠的數倉規則中，均支持根據實際業務場景修改為測試環境的測試數據。⑤數據修改完成，將生成的規則鏈接在接入業務系統中apolloy中替換DQS的請求地址。⑥業務系統中對應該查詢模型的功能模塊，會展示mock規則中保存的數據。

4.2.2 適用場景 單模型查詢，數據返回

①規則內單模型

②規則內多個模型配置（模型間無關聯關系）

① 規則內查詢的多個模型間有字段的關聯關系

（以下截圖中，字段關聯關系不反應實際業務場景；僅表示支持多模型關聯查詢）

4.2.3 實際落地場景舉例 以嚴選采購系統舉例，看下實際測試環境的mock數據回顯情況：首先看下數倉模型規則的配置情況（截圖數據均被脫敏）：規則中查詢的數據（所有查詢的字段均可在規則中修改，來支持測試環境的不同場景的造數要求），在采購系統測試環境的回顯情況看下圖（數據已脫敏）：

4.2.4 帶來的收益?

目前數倉造數服務完成跟嚴選主站和供應鏈的部分應用聯調的接入，部分業務已經在線上穩定使用中。 人工造數時間節省目前秒級可以完成從數倉拉取任何模型任意數量的數據。也支持批量數據導入導出進行測試環境造數。按照之前在數倉構造測試模型-造數據-建同步任務的流程步驟，保守估計人力花費至少在一小時（不考慮部分模型的字段可能超過200+的情況），提效超過1000倍。 測試環境成本搭建節省目前數倉生產環境機器為330臺，每臺折舊3萬左右，為990萬。測試環境按照線上環境1/10比例縮減，每年機器上節約將近100萬，同時也節省了其他人力維護的成本。?

5 總結?

之前應用測試的經驗讓我深刻感受到越是復雜的業務系統、模塊越多，每個模塊耦合關系，整個流程的造數，QA無疑是最清楚整個流程鏈路的人，在整個項目中的角色就更不可或缺。同樣在數據測試中，仍然需要劃分好測試邊界，數據測試除了要關注數據層的測試（指標/模型/數倉表），更不可忽視的是數倉是整條業務鏈路中的一環，對接全域業務提供的查詢能力及造數能力亦是需要重點關注的地方。數據產品的數據來源是嚴選的業務鏈路，產出的數據也是要反哺業務鏈路，最終實現推動業務發展。