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

1 前言

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

2 數(shù)據(jù)產(chǎn)品測試的現(xiàn)狀及痛點?

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

3 脫敏服務原理及使用?

3.1 脫敏原理?

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

3.2 適用場景及脫敏效果?

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

3.3 在實際業(yè)務線上面的數(shù)據(jù)脫敏效果?

伏羲頁面數(shù)據(jù)指標趨勢圖脫敏前后對比：脫敏前：脫敏后：4 脫敏服務演進之數(shù)倉造數(shù)服務?

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

4.1 什么樣的問題催生了數(shù)倉造數(shù)服務的誕生?

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

4.2 數(shù)倉造數(shù)服務

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

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

①規(guī)則內(nèi)單模型

②規(guī)則內(nèi)多個模型配置（模型間無關聯(lián)關系）

多模型查詢

① 規(guī)則內(nèi)查詢的多個模型間有字段的關聯(lián)關系

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

4.2.3 實際落地場景舉例?

以嚴選采購系統(tǒng)舉例，看下實際測試環(huán)境的mock數(shù)據(jù)回顯情況：首先看下數(shù)倉模型規(guī)則的配置情況（截圖數(shù)據(jù)均被脫敏）：規(guī)則中查詢的數(shù)據(jù)（所有查詢的字段均可在規(guī)則中修改，來支持測試環(huán)境的不同場景的造數(shù)要求），在采購系統(tǒng)測試環(huán)境的回顯情況看下圖（數(shù)據(jù)已脫敏）：4.2.4 帶來的收益?

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

5 總結?

之前應用測試的經(jīng)驗讓我深刻感受到越是復雜的業(yè)務系統(tǒng)、模塊越多，每個模塊耦合關系，整個流程的造數(shù)，QA無疑是最清楚整個流程鏈路的人，在整個項目中的角色就更不可或缺。同樣在數(shù)據(jù)測試中，仍然需要劃分好測試邊界，數(shù)據(jù)測試除了要關注數(shù)據(jù)層的測試（指標/模型/數(shù)倉表），更不可忽視的是數(shù)倉是整條業(yè)務鏈路中的一環(huán)，對接全域業(yè)務提供的查詢能力及造數(shù)能力亦是需要重點關注的地方。數(shù)據(jù)產(chǎn)品的數(shù)據(jù)來源是嚴選的業(yè)務鏈路，產(chǎn)出的數(shù)據(jù)也是要反哺業(yè)務鏈路，最終實現(xiàn)推動業(yè)務發(fā)展。本文由作者授權嚴選技術團隊發(fā)布