今天和大家分享下我作為大數據測試工程師對ETL測試的一些認識。
一、ETL測試工程師的主要責任
對於一個ETL測試工程師而言，其關鍵的責任有三大類：
1. 源數據分析（包含：數據庫表、文本等類型數據分析）
2. 業務轉換邏輯實現（包含：code diff，目標表全量數據的邏輯實現驗證）
3. 將經過轉換的數據載入至目標表的各維度與指標數據與對標數據進行對標驗證其一致性
二、ETL測試場景和測試用例
1. 根據對應的映射文件驗證"源"與"目標數據倉庫"的表結構
2. 驗證"源"和"目標數據的類型、長度、格式一致或源長度不應大於目標數據類型長度"
3. 約束驗證目標表中的約束關系滿足我們的期望設計
4. 數據一致性問題
<1>. 要防止語義定義相同，但特定屬性的數據類型和長度不一致的問題
<2>. 完整性約束、主鍵不可以重復、異常數據處理方式等
5. 完整性問題
<1>. 要確保所有期望的數據都已經完整的加載到目標表中
<2>. 要比較源和目標數據的個數（即確保計數上的完整）
<3>. 檢查出現的任何不合格的記錄
<4>. 檢查目標表列中的數據沒出現被截斷的情況--針對的是竄列的情況。比如comments里的內容含有列分隔符，被分隔開了。
<5>. 對邊界值進行分析檢查
6. 要檢查比較目標數據倉庫和源數據的關鍵字段的唯一性和正確性問題[主鍵一致]
<1>. 數據要沒有拼寫錯誤或不准確的記錄。
<2>. 無超出業務許可范圍的數據記錄存在
<3>. 數值型驗證，驗證是否為數值類型
<4>. 日期型驗證，驗證是否為日期格式，並且在所有日期類型數據的格式應該統一
<5>. 精度驗證，小數點的精度要滿足期望的精度
<6>. 數據檢查：檢查數據的正確性，完整性
<7>. null檢查
<8>. 轉換驗證轉換邏輯的正確性
7. 拷貝驗證
<1>. 驗證目標表中業務要求所有惟一性指標均正確的實現（例如主鍵、惟一標識的鍵、或其他任一惟一表示的列）
<2>. 驗證從源數據多列合並而成的數據是正確的
<3>. 驗證僅僅根據客戶要求對源數據進行了多列合並至目標表中
8. 日期驗證是ETL開發過程中常用的數據，主要用於：
<1>. 了解數據創建的日期，分區日期和業務日期要分清楚。
<2>. 用於識別活動記錄
<3>. 根據業務需求透視表確定活動記錄
<4>. 便於基於時間插入、更新記錄
9. 數據完整性驗證在驗證源和目標表中的數據集的完整性時，我們需要用到交集運算，以確定目標數據的完整性
10. 數據清理對於不需要的列在載入至數據倉庫前應該進行刪除
11. 結果集驗證：
<1>. 通常使用的是全量數據驗證方法，應用層的目標表數據驗證時，則使用匯總層的表再left join各種維度表，拿到對應的維度的值后再與應用層的目標表進行join，
根據需求中同一個維度或指標的不同場景，進行case設計，從而在case執行時，體現在一個個查詢sql上的不同，找出sql查詢出的異常數據值，單條數據進行驗證后，
如果確認是測試查詢sql的問題，則需要修正測試sql，再繼續執行，如果確認是實現的結果不符合需求，則提bug給到對應的開發。
<2>. 但針對一些特殊的需求，我們不會去構造一個驗證集去對比結果集，因為代價太高了。當然如果有對標數據是另外一種情況。我們可以簡化為從幾個維度去驗證跑出來的結果集。
比如，總量維度，結果集的數據量是否符合某個數量級。 酒店維度，某些個指標是否包含了所有酒店數。數值維度，某指標的全量和是否符合預期。
三、ETL的bug類型
bug類型描述說明
1. 用戶接口bug
<1>. 主要涉及應用的GUI
<2>. 字體、樣式、顏色、對齊、拼寫錯誤、導航等等
2. 邊界值bug數據的邊界值范圍
3. 等價類划分bug有效和無效類
4. 輸出/輸出bug
<1>. 未接受的有效值
<2>. 無效的值被接受
5. 計算類bug
<1>. 數學計算錯誤
<2>. 最終輸出錯誤
6. 載入條件bug
<1>. 不運行多用戶操作
<2>. 不運行用戶載入期望的數據
7. 性能的bug。達不到業務要求時間。
ETL測試與數據庫測試的不同
1.驗證數據是否按照預期進行了移動主要驗證數據是否遵循了設計預定的數據模式規則或標准
2.驗證數據經過業務轉換后是否滿足預定的轉換邏輯以及驗證源和目標數據計算是否一致主要表的主、外鍵等約束是否正常
3.驗證ETL過程數據表的主外鍵關系是否保存驗證沒有冗余表，數據庫最佳化
4.驗證已載入的數據拷貝是否滿足預期驗證需要的是否缺少數據
————————————————
一、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).開發實現需求的設計文檔。