淺談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).開發實現需求的設計文檔。

備註:我的個人公衆號已正式開通,致力於測試技術的分享,包含:大數據測試、功能測試,測試開發,API接口自動化、測試運維、UI自動化測試等,微信搜索公衆號:“無量測試之道”,或掃描下方二維碼:

添加關注,一起共同成長吧。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章