1、背景介紹

目前數(shù)倉測試，劃分成交易、增長、社區(qū)等多個模塊，不同的數(shù)倉測試域，都會有一名測試人員負責跟進，根據(jù)每個版本每個域資源實際投入情況，組內(nèi)會適當?shù)恼{(diào)整資源，以滿足日常迭代需要；單交易域這塊，版本迭代需求數(shù)，通常都要并行支持多個，且隨著公司業(yè)務(wù)的發(fā)展，從承接的需求復(fù)雜度，或驗證的指標量，都會有所提升，面對如此龐大的數(shù)據(jù)體量，在有限的時間/人力資源情況下，如何制定測試策略，保障數(shù)據(jù)質(zhì)量按時上線，對我們測試人員而言，無疑挑戰(zhàn)性是非常大的?；诖?，本篇主要介紹、梳理、總結(jié)了在數(shù)倉測試實踐過程中常用的一些方法，希望在以后相關(guān)的測試工作中，對大家有所幫助，可以避點坑；

2、業(yè)務(wù)范圍

數(shù)倉交易域，數(shù)據(jù)測試范圍涵蓋了訂單、履約、商家、商品、出價、庫存、用戶、寄存、財務(wù)、流量等多個模塊，通常每個模塊數(shù)倉這邊都有維護一張或者多種對應(yīng)的模型表。比如訂單（ 子訂單明細表），里面記錄訂單號，類型，狀態(tài)，支付時間等基礎(chǔ)信息；再比如履約（訂單履約表），里面維護了訂單號，商家，履約狀態(tài)，未履約原因，未履約責任方等信息；

數(shù)倉這邊，會在現(xiàn)有模型口徑的基礎(chǔ)上，進行日常迭代調(diào)整，同時根據(jù)prd需求不同，也會相應(yīng)的新增寬表、指標，以滿足業(yè)務(wù)需求；比如我們近期做核心指標寬表，需要基于商品spu維度，統(tǒng)計商品首次上架時間，動銷商品數(shù)、出價商品數(shù)、曝光/點擊uv等，需要匯總商品，訂單，出價，流量等多個模塊組合數(shù)據(jù)；

3、數(shù)據(jù)鏈路

在介入測試前，我們先簡單的梳理下，數(shù)倉數(shù)據(jù)鏈路層次，自下到上，大致分為ods(源數(shù)據(jù)層)->dwd（數(shù)據(jù)清洗層）->dws(輕度匯總層)->ads/dm(數(shù)據(jù)應(yīng)用層)，在生成最終結(jié)果表的過程中，也可能會使用到temp(臨時層)和dim(維表層)，用于指標加工計算；

一般而言，標準數(shù)倉分為 ODS,DWD,DIM,DWS,ADS 等，且每層分工不同,每層具體有哪些功能，下面有詳細的描述，大家可以了解下，有個整體的認知，已經(jīng)熟悉的同學這部分可以跳過；

ODS：存儲原始業(yè)務(wù)數(shù)據(jù),數(shù)據(jù)原封不動同步到到ODS,不做任何修改，并且備份，備份時可以壓縮；

DWD：數(shù)據(jù)清洗，脫敏，規(guī)范化，一般保持和ODS層一樣的數(shù)據(jù)粒度，并且提供一定的數(shù)據(jù)質(zhì)量保證。同時，為了提高數(shù)據(jù)明細層的易用性，該層會采用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關(guān)聯(lián),代表業(yè)務(wù)最小粒度層。任何數(shù)據(jù)的記錄都可以從這一層獲取，為后續(xù)的DWS做準備。另外，在該層也會做一部分的數(shù)據(jù)聚合，將相同主題的數(shù)據(jù)匯集到一張表中，提高數(shù)據(jù)的可用性；

DIM:    DWD同級別維度,比如時間維度、用戶維度、權(quán)限維度、省份維度等；

DWS：又稱數(shù)據(jù)集市或?qū)挶怼０凑諛I(yè)務(wù)劃分,比如訂單，用戶，商家，商品等，基于各個主題在加工和使用，進行輕度匯總,如統(tǒng)計各個主題7天，30天，90天的行為，用戶購買行為，商品動銷行為等，在DWD基礎(chǔ)上關(guān)聯(lián)DIM維度數(shù)據(jù)匯總，用于提供后續(xù)的業(yè)務(wù)查詢，OLAP分析等；

ADS：要是提供給數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù)，一般會存放在 ES、ClickHouse、Redis等系統(tǒng)中供線上系統(tǒng)使用，也可能會存在 Hive 或者 Druid 中供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用,一般在DWS基礎(chǔ)上生成指標,主題寬表,主要用于具體的業(yè)務(wù)服務(wù)

TEMP：每一層的計算都會有很多臨時表，專設(shè)一個temp層來存儲我們數(shù)據(jù)倉庫的臨時表

對于質(zhì)量把控來說，最核心的主要在于兩個部分，dws層和ads層，原因如下：

ods的源數(shù)據(jù)同步及dwd層的數(shù)據(jù)清洗，目前datawork已經(jīng)有相對完善的工作機制，可以保證數(shù)據(jù)質(zhì)量，測試幾乎可以不投入資源；

大部分數(shù)據(jù)加工、處理都是在dws層/ads層完成，而且相對于其他層級而言，日常改動、迭代更為頻繁，同時出現(xiàn)問題的風險也比較大；

4、數(shù)據(jù)測試

4.1 數(shù)據(jù)質(zhì)量保障流程

正常項目常規(guī)的流程，分析業(yè)務(wù)和需求->制定測試方案和測試計劃->設(shè)計測試用例和準備測試數(shù)據(jù)->測試執(zhí)行→生成測試報告→驗收上線，數(shù)倉需求類似但又有所區(qū)別，如在需求評審階段，我們更關(guān)注指標口徑對齊，在口徑明確的前提下，落到prd文檔，開發(fā)才可以依據(jù)進行開發(fā)，測試作為標準進行驗證。

從版本時間上，分別從移交測試前、冒煙/測試階段、預(yù)發(fā)階段、生產(chǎn)階段，每個階段關(guān)注的點不同，具體如下：

（1）移交測試前

指標口徑對齊，舉個非常簡單的例子，統(tǒng)計商家半年以內(nèi)全部品牌銷售數(shù)量，測試前，如下口徑點，都需要和產(chǎn)品/數(shù)分去溝通、明確；

• 口徑對齊后，需要根據(jù)平時測試積累的口徑，收集或開發(fā)對應(yīng)的指標口徑；
• Codeview ,在閱讀開發(fā)代碼的過程中，可以快速清楚口徑的處理過程，相當于自己也在腦中重構(gòu)了一次；

（2）冒煙/測試階段

• 不同的需求，數(shù)據(jù)驗證可能采取不同的驗證方案，具體的在后續(xù)‘數(shù)據(jù)測試方案’中會詳細描述；
• 數(shù)據(jù)完整性和準確性驗證；

（3）預(yù)發(fā)階段

• 回流需求，需要配合下游聯(lián)調(diào)測試，打通全流程；
• 在測試通過后，需要整理相關(guān)的測試文檔（含測試腳本，測試總結(jié)，結(jié)果，風險點等），供產(chǎn)品/數(shù)分/業(yè)務(wù)方驗收參考；

（4）生產(chǎn)階段階段

• 上線前做，需要做一輪Codeview，確保發(fā)布的是最新腳本，check調(diào)度任務(wù)依賴沒有遺漏，或者配錯情況；
• 對于生產(chǎn)上的指標，特別是優(yōu)先級比較高的，使用頻繁的，需要在datawork里，配置DQC告警監(jiān)控；
• 特殊情況下，比如口徑不明確，業(yè)務(wù)方在驗收過程中，也無法提供有效、合理的參考數(shù)據(jù)，需要和關(guān)聯(lián)方一起評估上線方案；比如商家自運行項目，需要統(tǒng)計每個商家營收情況，業(yè)務(wù)方無法提供生產(chǎn)上真實的商戶做驗證，或者最多只能提供的一兩個，也無法確?？趶綔蚀_，為了避免客訴，一般通過開通商戶白名單的方式，在數(shù)據(jù)穩(wěn)定運行一段時間后，再全量放開；

4.2 數(shù)據(jù)測試方案

• 數(shù)倉需求，一般分兩類，數(shù)分需求和回流需求，每類的測試方案都有所不同；

（1）數(shù)分需求

有數(shù)分介入，需明確業(yè)務(wù)口徑，對齊后，作為測試驗數(shù)參考，走DQC驗證；

如統(tǒng)計商家銷售成交明細，已提供了明確的業(yè)務(wù)/技術(shù)口徑，可以編寫DQC腳本，和對應(yīng)的數(shù)倉報表口徑進行比對；

（2）回流需求

沒有數(shù)分介入，產(chǎn)品往往只能給到業(yè)務(wù)口徑，具體的技術(shù)口徑一般情況下是提供不了的，這時就要依賴平時積累的測試口徑，需要自己寫sql比對，和數(shù)倉報表數(shù)據(jù)進行校驗；

以交易域需求為例，數(shù)分，研發(fā)，測試都有梳理沉淀具體的口徑文檔，在口徑不明確的情況下，可以借鑒：

4.3 數(shù)據(jù)測試類型

• 大數(shù)據(jù)測試，簡單的理解可以分兩種類型，黑盒測試和白盒測試

（1） 黑盒測試

開發(fā)移交后，我們根據(jù)表名，就可以開始初步的測試，類似冒煙，這個環(huán)節(jié)對業(yè)務(wù)的口徑不需要非常清楚就可以進行；

1. 檢查目標表的表結(jié)構(gòu)是否與設(shè)計文檔一致
2. 主鍵是否唯一
3. 字段非空非null判斷
4. 極值是否超出正常范圍，如年齡類字段歲數(shù)大于200
5. 枚舉值檢查數(shù)據(jù)是否合理分布
6. 對應(yīng)字段和字段內(nèi)容是否一致，防止數(shù)據(jù)落表存在亂序情況
7. 占比類型字段值是否大于100%
8. 金額類字段是否存在負數(shù)情況
9. 數(shù)據(jù)是否有效合理，比如同分區(qū)下，賣家近7天成交訂單量比近30天成交量還多的情況

• 唯一性

--主鍵，無重復(fù)記錄
SELECT  主鍵ID
        ,count(1)
FROM    表名
WHERE   pt = '${bizdate}'
GROUP BY 主鍵ID
HAVING  count(1) > 1
;

• 為空判斷

--空值判斷，無異?？罩禂?shù)據(jù)
SELECT  字段1,字段2 
FROM    表名
WHERE   pt = '${bizdate}'
and     (字段1='' OR  字段2='')
;

• 為null判斷

--空值判斷
SELECT  字段1,字段2 
FROM    表名
WHERE   pt = '${bizdate}'
and     ((字段1 IS NULL OR  字段2 IS NULL)
;

• 枚舉值判斷

--枚舉類型字段，比如只有0，1兩種狀態(tài)
SELECT  distinct(枚舉類型字段)
FROM    表名
WHERE   pt = '${bizdate}' 
；

• 占比值判斷

--占比值類型字段，比如轉(zhuǎn)化率字段，無大于1的異常數(shù)據(jù)
SELECT  轉(zhuǎn)化率字段
FROM    表名
WHERE   pt = '${bizdate}'
and    轉(zhuǎn)化率字段>1
;

• 負值判斷

--比如價格類型字段值，無負值情況
SELECT  價格
FROM    表名
WHERE   pt = '${bizdate}'
and    價格 <0
;

• 有效判斷

--比如同一商品近7天的銷售量是否存在大于商品近14天的銷售量的異常數(shù)據(jù)
SELECT  近7天的銷售量，近14天的銷售量
FROM    表名
WHERE   pt = '${bizdate}'
and    近7天的銷售量>近14天的銷售量
;

（2）白盒測試

需要對開發(fā)的代碼走讀，check指標處理邏輯。同時測試也需要準備驗證腳本，或者查找到可以作為驗證參考的數(shù)據(jù)，便于口徑核對，這個環(huán)節(jié)，對測試人員的指標口徑沉淀有一定的要求。在發(fā)現(xiàn)指標數(shù)據(jù)存在差異的情況，需要協(xié)助開發(fā)人員一起定位差異原因，時常需要在現(xiàn)有的口徑基礎(chǔ)上，在數(shù)倉空間往上翻多層，或者一個指標定義不夠清晰，需要自行去數(shù)分空間查找口徑定義。另外，在測試通過后，需要編寫相應(yīng)的DQC腳本，及時監(jiān)控生產(chǎn)數(shù)據(jù)質(zhì)量。這些對測試來說，需要有一定的sql功底；

• check字段長度，最大最小值，異常值，邊界值等
• 指標邏輯處理口徑，需要驗證關(guān)聯(lián)約束條件和where條件約束是否和prd一致，是否滿足業(yè)務(wù)需求
• 指標默認值設(shè)置是否合理；
• 涉及到占比類型字段時，開發(fā)腳本是否有考慮分母為0為null的情況；
• 計算單位是否統(tǒng)一；.常用的函數(shù)，特別是datediff、dateadd等時間函數(shù)，往往會導致時間范圍存在偏差，導致指標值對不上的情況；
• 數(shù)倉上線表任務(wù)調(diào)度check，主要關(guān)注是否缺少依賴；
• DQC腳本編寫，配置；

白盒測試階段，常見的開發(fā)問題匯總

• 字段未做默認處理，數(shù)值字段一般默認為0，字符串默認為‘’；

,nvl(spu_inv_num_7day,0)              as  近七天_在售商品數(shù)        -- 近七天_在售商品數(shù)
    ,spu_inv_num_30day                  as  近30天_在售商品數(shù)       -- 近30天_在售商品數(shù) 
    ,spu_cnt_30day                         as  近30天_動銷商品數(shù)       -- 近30天_動銷商品數(shù)

• 過濾條件遺漏

以下面為例，統(tǒng)計賣家任務(wù)發(fā)貨當天的訂單量，需加上id_del判斷，剔除無效數(shù)據(jù)。

SELECT  t1.賣家號
        ,TO_CHAR(t1.訂單時間,'yyyyMMdd') AS 訂單時間
        ,COUNT(t1.訂單號) OVER (PARTITION BY t1.賣家號,t1.任務(wù)號,TO_CHAR(t1.訂單時間,'yyyyMMdd') ) AS 賣家_任務(wù)_發(fā)貨當天的訂單 -- 賣家+任務(wù)+發(fā)貨當天的訂單                           
FROM    test1 t1 --過濾沒有刪除的訂單
WHERE   t1.is_del = 0
;

以下面為例，統(tǒng)計賣家歷史訂單量和gmv，因為數(shù)倉目前統(tǒng)計的是T+1的數(shù)據(jù)，所以需要過濾掉當天跨零點數(shù)據(jù)；

--改動前
SELECT  用戶號
        ,用戶信息
FROM    test
WHERE   pt = '${bizdate}'
；
  --需調(diào)整為：
SELECT  *
FROM    (
            SELECT  用戶號
                    ,用戶信息
                    ,ROW_NUMBER() OVER (PARTITION BY 用戶號 ORDER BY 用戶創(chuàng)建時間 DESC ) AS rn
            FROM    test
            WHERE   pt = '${bizdate}'
        ) 
WHERE   rn = 1
；

• 表關(guān)聯(lián)關(guān)系如果是1：1，關(guān)聯(lián)時，如果關(guān)聯(lián)健不唯一，那么關(guān)聯(lián)會產(chǎn)生笛卡爾，導致數(shù)據(jù)膨脹。

以下面為例，商家表同一個用戶號可能有多條數(shù)據(jù)，如果主表根據(jù)用戶號會導致結(jié)果數(shù)據(jù)膨脹；

--改動前
  NVL(在線出價商品缺貨數(shù),0) / 在線商品出價數(shù) 
  --調(diào)整后
  CASE WHEN 在線商品出價數(shù) IS NULL OR 在線商品出價數(shù) = 0 THEN 0  ELSE NVL(在線出價商品缺貨數(shù),0) / 在線商品出價數(shù) end

• 未考慮分母為0/空的情況

以下面為例，在線出價商品缺貨率=在線出價商品缺貨數(shù)/在線商品出價數(shù)，需要加上分母為0/空的情況，給到默認值0；

-- 近7天_實際支付金額GMV
sum(case when to_char(支付時間,'yyyymmdd') BETWEEN TO_CHAR(DATEADD(TO_DATE('${bizdate}','yyyyMMdd'), -7,'dd'),'yyyyMMdd') AND '${bizdate}' then coalesce(支付金額 ,0) end ) / 100     as 近7天_實際支付金額

• 函數(shù)規(guī)則使用有誤

如統(tǒng)計近7天_實際支付金額GMV指標，使用的是DATEADD函數(shù)，統(tǒng)計近7天數(shù)據(jù)，需往前推6天，對應(yīng)的前置條件應(yīng)調(diào)整為‘-6’

4.4 常用的測試方法

（1）DQC對比

• 通過現(xiàn)有的數(shù)據(jù)/口徑作為預(yù)期，通過一定的方式關(guān)聯(lián)，直接和開發(fā)新表/口徑做對比驗證即可，可以大大的減少測試時間，測試效率非常高；

適用場景：

• 遷移、重構(gòu)類需求，同一張表每個字段對應(yīng)的口徑差異不大，甚至是完全相同的，我們一般采取的方式是，根據(jù)主鍵進行關(guān)聯(lián)新老表，相同的指標值預(yù)期應(yīng)該一致，進行全量比對，如有差異數(shù)據(jù)記錄，需要逐條分析排查；

例：賣家履約數(shù)據(jù)遷移需求為例，根據(jù)賣家id+履約統(tǒng)計時間為組合維度，校驗遷移前后賣家履約率是否一致；

--全量個人商家履約數(shù)據(jù)明細驗證
SELECT  賣家id
        ,履約統(tǒng)計時間
        ,t1.履約率 AS 新邏輯履約率
        ,t2.履約率 AS 舊邏輯履約率
FROM    (
            SELECT  賣家id
                    ,履約統(tǒng)計時間
                    ,履約率
            FROM    test1
            WHERE   pt = '${bizdate}'
        ) t1
INNER JOIN  (
                SELECT  賣家id
                        ,履約統(tǒng)計時間
                        ,履約率
                FROM    test2
                WHERE   pt = '${bizdate}'
            ) t2
ON      t1.賣家id = t2.賣家id
AND     t1.履約統(tǒng)計時間 = t2.履約統(tǒng)計時間
WHERE   t1.履約率 <> t2.履約率
；

• 目前很多數(shù)倉迭代需求，往往都可以在數(shù)分報表平臺找到對應(yīng)的指標數(shù)據(jù)，驗證的時候可以直接復(fù)用具體的表具體的字段，或者沒有現(xiàn)成的，如果只要簡單的處理一下，也可以進行dqc驗證；

（2）多維度對比

• 為滿足業(yè)務(wù)需求，數(shù)倉這邊開發(fā)的報表，往往同一個指標，有多重維度計算，且每層計算對應(yīng)的值不一樣，這種情況下，可以先驗證一組維度數(shù)據(jù)準確性；然后基于測試通過的維度組指標作為參考組，可以快速的驗證其他維度；

適用場景：新增報表需要聚合多維度指標數(shù)據(jù)

例：賣家核心指標需求為例，需要統(tǒng)計在倉庫存數(shù)、出價賣家數(shù)、提交訂單量、履約訂單量、筆單價等100+個指標值，每個指標都要在不同統(tǒng)計維度下，如賣家類型+三級類目+品牌、賣家類型+一級類目+品牌、賣家類型+一級類目等情況下計算相應(yīng)的數(shù)據(jù)，同時又分為日，周，月維度報表，單一個出價賣家數(shù)指標就有3（時間維度）*9（統(tǒng)計維度）=27種情況，如果在加上指標個數(shù)100+的話，需要驗證的指標條數(shù)就多達2700條，顯然沒有這么多資源去驗證，用這種方法，可以大大的提升我們測試驗證時效；

（3）表間橫向數(shù)據(jù)對比

• 表間橫向?qū)Ρ瓤梢岳斫鉃閮蓮埍砘蚨鄰埍碇g，其中具有業(yè)務(wù)關(guān)聯(lián)或者業(yè)務(wù)含義一致的字段，可以用來做數(shù)據(jù)對比：

例：訂單費率遷移項目，費率遷移后，基于訂單維度，訂單側(cè)t1表、t2表、t3表這3張表的，每筆跨境訂單費率數(shù)據(jù)應(yīng)該保持全部一致，如存在差異數(shù)據(jù)，需要拉出明細，和開發(fā)，關(guān)聯(lián)方一一確認影響；

--統(tǒng)計表1的訂單費率DROP TABLE IF EXISTS du_temp.t1;CREATE TABLE IF NOT EXISTS du_temp.t1 ASSELECT  訂單號        ,訂單跨境費率FROM    t1WHERE   pt = '${bizdate}';
--統(tǒng)計表2的訂單費率DROP TABLE IF EXISTS du_temp.t2;CREATE TABLE IF NOT EXISTS du_temp.t2 ASSELECT  訂單號        ,訂單跨境費率FROM    t2WHERE   pt = '${bizdate}';
--統(tǒng)計表3的訂單費率DROP TABLE IF EXISTS du_temp.t3;CREATE TABLE IF NOT EXISTS du_temp.t3 ASSELECT  訂單號        ,訂單跨境費率FROM    t3WHERE   pt = '${bizdate}';
--全量差異掃描，異常訂單告警數(shù)據(jù)SELECT  t1.訂單號        ,t1.訂單跨境費率 AS t1_訂單跨境費率        ,t2.訂單跨境費率 AS t2_訂單跨境費率        ,t3.訂單跨境費率 AS t3_訂單跨境費率FROM    du_temp.t1 t1INNER JOIN du_temp.t2 t2ON      t1.訂單號 = t2.訂單號INNER JOIN du_temp.t3 t3ON      t1.訂單號 = t3.訂單號WHERE   t1_訂單跨境費率 != t2_訂單跨境費率OR      t1_訂單跨境費率 != t3_訂單跨境費率;

（4）表內(nèi)橫向數(shù)據(jù)對比

• 表內(nèi)橫向?qū)Ρ瓤梢岳斫鉃橥粡埍韮?nèi)，業(yè)務(wù)上相關(guān)聯(lián)的兩個或多個字段，他們存在一定的邏輯性關(guān)系，那么就可以用來做數(shù)據(jù)對比；

例1：同一個商品，正常來說，瀏覽量>=加入購物車>=生成訂單>=支付訂單>=完成交易，對于訂單部分，實際業(yè)務(wù)下單量肯定大于支付量，編寫sql如下：

select  提交訂單量,支付訂單量
FROM    test
WHERE   pt = '${bizdate}'
and 提交訂單量 < 支付訂單量;

例2:商家統(tǒng)計月內(nèi)，應(yīng)履約訂單量滿足以下條件，等于（實際履約量+超時未發(fā)貨量+虛假量+鑒定未通過量+其他賣家原因而關(guān)閉的訂單量）,這些字段都落履約表了，就可以直接對比，編寫sql如下

--統(tǒng)計差異商家履約數(shù)據(jù)
SELECT  商家id
        ,統(tǒng)計月份
        ,應(yīng)履約訂單量
        ,實際履約量 + 超時未發(fā)貨量 + 虛假量 + 鑒定未通過量 + 其他賣家原因而關(guān)閉的訂單量 AS 預(yù)計應(yīng)履約訂單量
FROM    test
WHERE   pt = '${bizdate}'
AND     統(tǒng)計月 IN ('202105','202106','202107')
AND     應(yīng)履約訂單量 <> 實際履約量 + 超時未發(fā)貨量 + 虛假量 + 鑒定未通過量 + 其他賣家原因而關(guān)閉的訂單量
;

（5）execl對比

• 如果需要測試的報表字段個數(shù)太多，或者指標處理邏輯比較復(fù)雜，通過sql不好處理，那么可以考慮常用的execl表格工具，在處理上面兩種情況下，見效非?？欤?/span>

例1：核心報表需求，多個迭代版本需要驗證的新指標數(shù)有1000+，如果按照以前的方法，驗證起來會非常吃力，需要編寫的測試腳本，驗證數(shù)據(jù)工作量都非常巨大，如果使用execl，對于口徑明確的情況下，只需要一、兩個簡單的select腳本，就可以將數(shù)據(jù)指標數(shù)據(jù)放到表格里，通過自動的if函數(shù)做個判斷就行，可以快速核對指標，且后續(xù)也方面開發(fā)對齊修復(fù)，數(shù)分驗收起來，也可以大大的縮短時間；

例2：財務(wù)補貼需求，新增兩個指標，平臺實收操作服務(wù)費和平臺實收技術(shù)服務(wù)費，看似非常簡單的一個需求，但實際處理起來，需要涉及到10多個原有的財務(wù)指標關(guān)聯(lián)計算，且指標之間又存在依賴關(guān)系，加上計算過程中涉及到乘除，在統(tǒng)計訂單數(shù)據(jù)較多的情況下，很容易因為精度問題，導致最終結(jié)果存在失真情況。如果按照prd需求進行口徑驗證，測試要編寫上千行代碼，光腳本就要花費1天（整個需求測試估時：1.5天），在和開發(fā)報表數(shù)據(jù)做對比，因為都存在上述的失真情況，差異數(shù)據(jù)排查起來，需要把計算邏輯一層一層的比對，驗證起來非常耗時；

但通過execl處理，只要將對應(yīng)的計算因子數(shù)據(jù)放到里面，通過工具本身自帶的函數(shù)，可以快速的得到預(yù)期結(jié)果；

5、生產(chǎn)數(shù)據(jù)質(zhì)量監(jiān)控

不同行業(yè)有不同的評估數(shù)據(jù)質(zhì)量的標準。一般來說，數(shù)據(jù)質(zhì)量可以從完整性、準確性、一致性和及時性共四個角度進行評估。

• 完整性是指數(shù)據(jù)的記錄和信息是否完整，是否存在數(shù)據(jù)缺失情況。數(shù)據(jù)缺失主要包括記錄的缺失和具體某個字段信息的缺失，兩者都會造成統(tǒng)計結(jié)果不準確。完整性是數(shù)據(jù)質(zhì)量最基礎(chǔ)的保障.
• 準確性是指數(shù)據(jù)中記錄的信息和數(shù)據(jù)是否準確、是否存在異?；蛘咤e誤的信息。例如，訂單中出現(xiàn)錯誤的買家信息等，這些數(shù)據(jù)都是問題數(shù)據(jù)。確保記錄的準確性也是保證數(shù)據(jù)質(zhì)量必不可少的一部分。
• 一致性通常體現(xiàn)在跨度很大的數(shù)據(jù)倉庫中。例如，某公司有很多業(yè)務(wù)數(shù)倉分支，對于同一份數(shù)據(jù)，在不同的數(shù)倉分支中必須保證一致性。例如，從在線業(yè)務(wù)庫加工到數(shù)據(jù)倉庫，再到各個數(shù)據(jù)應(yīng)用節(jié)點，用戶ID必須保持同一種類型，且長度也要保持一致。
• 及時性保障數(shù)據(jù)的及時產(chǎn)出才能體現(xiàn)數(shù)據(jù)的價值。例如，決策分析師通常希望當天就可以看到前一天的數(shù)據(jù)。若等待時間過長，數(shù)據(jù)失去了及時性的價值，數(shù)據(jù)分析工作將失去意義。

目前線上數(shù)據(jù)質(zhì)量監(jiān)控，數(shù)倉測試這邊大多是通過DQC（Data Quality Center）數(shù)據(jù)質(zhì)量中心配置進行，通過配置數(shù)據(jù)質(zhì)量校驗規(guī)則，自動在數(shù)據(jù)處理任務(wù)過程中進行數(shù)據(jù)質(zhì)量方面的監(jiān)控，根據(jù)離線任務(wù)的運行情況實時決策是否告警、何時告警、告警方式、告警給誰；具體的配置，使用方式，數(shù)據(jù)部門已經(jīng)有了非常詳細的操作文檔，我就不過多介紹，感興趣的可以直接拿來看看；

6、總結(jié)

數(shù)據(jù)校驗的方式有多種多樣，以上只是匯總了數(shù)倉測試過程中常用到的一些方法，實際應(yīng)用中，還需要結(jié)合具體的需求，方法選取得當，可以起到事半功倍的效果。個人覺得，數(shù)據(jù)類測試，非?？简炄说哪托模鎸Ψ彪s的指標，需要花費更多的時間，靜下心來，去不斷梳理、總結(jié)、沉淀，慢慢打磨形成一套可以作為自身驗證標準的方法論，也只有在不斷的熟悉本身業(yè)務(wù)的過程中，才能提升測試人員本身對數(shù)據(jù)敏感性，從而降低數(shù)據(jù)質(zhì)量風險；

目前除了dqc生產(chǎn)配置，可以自動監(jiān)控數(shù)據(jù)質(zhì)量運行情況，日常迭代數(shù)倉測試過程，大多數(shù)情況還是通過人工去核對數(shù)據(jù)，在后續(xù)工作里，希望可以結(jié)合公司現(xiàn)有的業(yè)務(wù)，探索出更多可以提效的數(shù)據(jù)驗證方法，測試比對工具，降低數(shù)據(jù)對比的成本，不斷的完善現(xiàn)有的數(shù)據(jù)測試體系，持續(xù)保障數(shù)倉質(zhì)量。