淺談ETL測試（二）

　　今天繼續和大家分享下作為大資料測試工程師對ETL測試的一些認識。ETL測試認知續篇。

　　一、ETL測試類型

　　Production Validation Testing

　　---該類型的ETL測試是在資料遷移至生産系統時進行的。為了保證生産業務的正常營運，生産系統中的資料必須以正确的順序進行排序。在該ETL測試類型中要注意從資料層面進行自動化測試和管理能力的植入。

　　Source to Target Testing(Validation Testing)

　　---該類型的測試主要由源轉換的資料是否滿足預期的轉換目标。

　　Application Upgrades(更新測試)

　　---該類型的ETL測試是可以自動生成的，能節省大量的測試開發時間。主要檢查舊應用或存儲庫中提取的資料是否與新的應用或新的存儲庫中的資料完全相同。

　　Metadata testing(中繼資料測試)

　　---中繼資料測試包括資料類型檢查、資料長度和索引/限制檢查。

　　Data Completeness Testing(資料完整性測試)

　　---當把所有期望的資料從源加載到目标表時，就算完成了資料完整性測試。在資料完整性測試過程中，我們還可以進行一些簡單的轉換或無轉換的源與目标之間的計數、聚合和實際資料比較和驗證的測試。

　　Data Accuracy Testing(資料準确性測試)

　　---該類型測試驗證資料正确地完成加載和按預期目标進行轉換。

　　Data Transformation Testing(資料轉換測試)

　　---測試資料轉換是一個複雜的過程，并不是簡單地寫一個源SQL查詢并與目标表進行比較來實作的。可能需要為每個驗證case寫較複雜的SQL聯合查詢，來驗證轉換規則。

　　Data Quality Testing(資料品質測試)

　　---資料品質測試包含文法和基準測試。為了避免在業務過程中由于日期或唯一編号(例如訂單号)引起的錯誤，進行資料品質測試。

　　Incremental ETL Testing(增量ETL測試)

　　---該類型測試主要驗證舊資料和新資料的完整性，并添加新資料。增量測試驗證增量ETL過程中，插入和更新是否滿足預期的要求。

　　GUI/Navigation Testing

　　---該類型測試主要檢查生成的大資料報告的UI\導航方面是否正常。

　　文法測試：根據無效字元、字元模式、不正确大小寫、順序等出具髒資料測試結果

　　基準測試：基于資料模型檢查資料，例如

二手手機靓号購買

客戶ID資料品質測試，包含：數字檢查、日期檢查、精度檢查、資料檢查、零校驗等等

　　二、ETL測試的方法

　　1.資料量統計

　　源表和目标表資料量統計。全量的加工表跟對标資料表之間的名額/次元資料值的量級、條數等

　　2.轉換規則測試

　　<1>.資料格式的合法性。對于資料源中時間、數值、字元等資料的處理，是否符合資料倉庫規則，是否進行統一的轉換 ----收數的時候走統一的校驗邏輯。

　　<2>.值域的有效性。是否有超出維表或者業務值域的範圍。---目前價格等數值型的，統一使用(22,6)精度的規則。

　　<3>.空值的處理。是否捕獲字段空值，或者需要對空值進行替換為其他含義值的處理。

　　<4>.主鍵的有效性。主鍵是否唯一。

　　<5>.亂碼的檢查。特殊符号或者亂碼符号的處理規則。---在解析文本檔案時使用統一的分隔符，規則是字段值不會出現類似這樣的字元串，如使用分隔符：#￥%&*，保證其唯一性，否則在解析檔案入庫時會出現串列現象。

　　<6>.髒資料的處理。理論上收數層做完之後，不存在資料規格問題的髒資料。但是目前依據資料系統情況看，還無法完全避免。是以一些重要名額的計算邏輯需要考慮到可能會有髒資料的問題。

　　3.抽樣測試

　　通過抽樣，測試源表和目标表映射是否正确。

　　4.加載規則測試

　　一般加載方式有兩種：全量加載和增量加載

　　<1>.增量加載方式，為了避免收數時個别資料源問題導緻可能會斷更幾天的情況，我們通常使用滑塊視窗方式增量，當資料源問題恢複後自動補全了滑塊内缺失的部分。

　　對于增量抽取，捕捉變化的資料有如下幾種：

　　1).監控增量資料

　　因為項目在上線前一般都會試運作一段時間，是以在這段時間，就要每天做表中資料量的的監控。

　　對于日全量表的監控：隻要看源表和目标表資料量是否一緻就可以

　　對于增量資料量監控：看全量+增量的資料是否與源表資料量是否一緻。根據不同的業務規則，檢視是否正确。

　　然後通過多日監控，可以發現不管是增量還是全量，資料量基本都會處于一個值左右，幅度不會太大，如果出現特殊情況，就要去考慮檢查一下它的正确性了。這種通常要根據線上的業務監控來實作。

　　2).監控增量運作時間

　　通過監控增量的運作時長，可以發現性能問題和批量資料的運作是否成功。對于時間浮動比較大的增量表，可以第一時間發現問題并解決問題。

　　運作時間監控：對于業務性能要求高的情況。比較在意的是性能問題，以確定在規定的時間内，完成跑批。我們要通過監控增量運作時間，及時發現程式的性能問題。

　　<2>.全量加載方式

　　由于我們采取的是全量加載+增量加載(采用時間戳方式)，我這裡指的全量加載即資料倉庫中資料的初始化。

　　全量加載的測試方案相對要簡單些。

　　1).測試源和目标表的資料量的一緻性

　　2).運作1,2,3,4測試方法測試一般來說即可。

　　5.性能測試

　　確定資料在規定和預計的時間内被加載到資料倉庫中，以确認改進的性能和可擴充性。

　　6.測試用例

　　項目中的關鍵業務，複雜邏輯部分作為測試重點

　　基礎資料：可以為真實資料，也可以單純手工造資料。因為ETL資料量較大，并且表中字段數量比較多，各表關聯比較大，是以本人覺得還是用真實資料效率比較高。

　　測試用例的編寫：測試用例可以單獨設計，也可以采用排程的思想進行設計，采用排程方法進行設計時，能一次驗證多個用例，另外也友善回歸。

　　三、怎麼建立ETL測試用例

　　<1>.ETL測試的目的是確定在業務轉換完成後從源加載到目标表的資料是正确無誤的。

　　<2>.ETL測試同樣還涉及在源和目标表之間轉換時的各個階段的資料的驗證。

　　<3>.在從事ETL測試時，有三份文檔是ETL測試人員實時使用的：

　　1). ETL映射表：一個ETL映射表包含源和目标表的所有的資訊，包括每個列及其引用表等限制關系。ETL測試人員需要以此為依據來編寫測試SQL查詢語句，因為在ETL測試各階段可能需要編寫具有多個連接配接的大查詢來驗證資料。ETL映射表在為資料驗證編寫查詢時提供大量的有用的資訊。

　　2). 源、目标資料庫模式：該模式應該便于驗證映射表中的所有細節。

　　3). 開發實作需求的設計文檔。