大資料測試總結
前言
隨著各個國家使用大資料應用程式或應用大資料技術場景的數量呈指數增長,相應的,對於測試大資料應用時所需的知識與大資料測試工程師的需求也在同步增加。醫療、能源、通訊、零售業、金融、體育等各行業都可以從其資料的採集、傳輸、儲存、分析等各個環節產生巨大的經濟價值,馬爸爸認為,未來的時代將不是IT時代,而是DT
的時代,即Data Technology資料科技。大資料測試或將成為未來的一個熱門的職業方向,以下就給大家揭開大資料測試的神祕面紗。
一、大資料測試簡介
1、什麼是大資料?
大資料
是一個大的資料集合,通過傳統的計算技術無法進行處理。這些資料集的測試需要使用各種工具、技術和框架進行處理。大資料涉及資料建立、儲存、檢索、分
2、大資料應用場景舉例?
電子商務:淘寶,京東和其他電子商務平臺每天都有數以百萬計的訪問者,會瀏覽其中的數十萬種商品。淘寶使用大資料來儲存有關商品,客戶和購買的資訊。包括圍繞商品的搜尋,新增入購物車的商品,購物車放棄及一起購買的其他商品等資料。所有這些資料都經過儲存和處理後,會生成針對客戶最有可能購買的商品建議。
社交媒體:社交媒體類應用會根據圖片、視訊、喜歡數、帖子內容,評論等生成大量資料。這些資料不僅儲存於大資料平臺中,還會對其進行處理和分析,以進而提供針對使用者更加精準的可能喜歡的內容推薦。資料不僅儲存在大資料平臺中,還經過處理和分析,以針對您可能感興趣的事物提供建議。例如,如果在抖音上檢視某商品的廣告並轉到淘寶,淘寶將會顯示相同的廣告。這是一個典型的大資料應用,因為抖音每天的日活使用者數已超4億,所以有大量的網站在上面做廣告。而傳統的資料庫是無法在同一時間記憶體儲和處理大量的資訊並用以向正確的使用者推送正確的廣告。
醫療衛生:大資料在抗疫大戰發揮了多項作用,比如監測人口和車輛流動、追蹤確診病例、預測疫情。在當前輸入型病例呈上升趨勢的情況下,大資料可繼續用於強化境外人員入境前的通報預警,入境時的查驗管控以及入境後協助社群防控工作,以及時有效的防範對境外疫情輸入的風險。大資料應用將那些與我國有通航業務的中外航空公司建立了乘客訂票資訊的連結,實現了所有空港的入境人員基本資訊即知、回國資訊預知以及入境落地資訊悉知,通過這樣的方式,第一時間向入境地的海關檢疫部門通報預警,實施重點的檢疫工作。
3、大資料測試的型別?
測試大資料應用程式更多的是驗證其資料處理,而不是測試軟體產品的個別功能。當涉及到大資料測試時,效能和功能測試是關鍵。處理可以是三種類型:批量、實時、互動。
在測試應用程式之前,有必要檢查資料的質量,並將其視為資料庫測試的一部分。它涉及檢查各種欄位,如一致性,準確性,有效性,資料完整性等。
4、大資料中的資料格式?
大資料的資料格式可以分為3
類,分別是:結構化資料、半結構化資料、非結構化資料
結構化資料:
-
資料具有高度組織性;
-
普遍儲存於任何關係型資料庫中(如MySQL,Oracle,SQL Server);
-
通過使用簡單的查詢操作就可以輕鬆的檢索使用;
半結構化資料:
-
半結構化資料的組織性不高;
-
半結構化資料不在關係型資料庫中儲存;
-
經過一系列處理後可以轉換為結構化格式儲存於關係型資料庫中;
-
半結構化資料包含標籤和其他型別的元資料,用以實現在資料格式體系中的層次結構和順序;
-
屬於同一型別的實體,可以具有不同屬性且順序也可以不同;
非結構化資料:
-
非結構化資料不具有任何預定義格式的結構;
-
不遵循任何結構化資料模型;
-
影象,視訊,文件等即使具有內部結構,但其本身還是非結構化資料;
-
這類資料一般在關係型資料庫中直接以二進位制形式儲存,所以存取操作極為不便;
-
我們在軟體應用場景中的80%的資料都是非結構化資料;
二、大資料測試型別
一般情況下,大資料專案的工作流中有多個過程域需要進行測試。大資料專案中的測試通常包含功能測試、資料庫測試、基礎架構測試和效能測試。在測試開始之前,制定嚴格清晰的測試策略有助於整體專案的成功。大資料專案不同於其他類別的專案,其本身包含的海量資料驗證本身對於測試工作而言就極具挑戰性,而測試過程中又要同時兼顧對大資料基礎架構自身的測試,大大加劇了測試的難度和深度。所以在制定大資料專案測試策略的時候,建議在測試中進行分段測試。不同的階段指定不同的測試主體,明確不同的測試目標,再應用不同的測試方法。基本的原則遵循基礎架構測試——資料庫測試——功能測試——效能測試的流程進行。
1、架構測試
Hadoop處理大量的資料,並且是非常耗費資源的。因此,架構測試對於確保大資料專案的成功至關重要。系統設計不當可能導致效能下降,系統不能滿足要求。至少,效能和故障轉移測試服務應該在Hadoop環境中完成。
2、部署方式測試
大資料具備scale-out的特點,能夠構建大規模,高效能的檔案系統叢集。針對不同應用和解決方案,檔案系統部署方式會有顯著不同;部署方式測試需要測試不同場景下的系統部署方式,包括自動安裝配置,叢集規模,硬體配置(伺服器,儲存,網路),自動負載均衡等,這部分測試不大可能進行自動化測試,需要根據應用場景來設計解決方案和具體部署,再進行手動測試。
3、資料庫測試
與大資料應用程式功能測試相比,資料庫測試工作的很大一部分將花在資料驗證上。資料庫測試將是大資料應用程式中測試的關鍵組成部分。它又分為三個主要組成部分:
-
資料分段驗證:這裡我們驗證從各種來源如IoT裝置,資料採集裝置,系統日誌等獲取的資料。我們還驗證推送到Hadoop、Spark或其他類似框架中的資料;
-
流程驗證:測試工程師還將測試通過大資料處理後獲得的資料是否準確。這其中包含會測試從MapReduce或類似過程生成的資料的準確性;
-
輸出驗證:在此階段中,測試工程師將驗證大資料的輸出是否正確儲存在於資料倉庫中,同時還需測試資料是否已在BI系統或任何其他目標系統的UI中正確顯示。
4、資料一致性測試
這裡的資料一致性是指檔案系統中的資料與從外部寫入前的資料保持一致,即寫入資料與讀出資料始終是一致的。資料一致性能夠表明檔案系統可保證資料的完整性,不會導致資料丟失或資料錯誤,這是檔案系統最基本的功能,測試可用diff,md5sum編寫指令碼自動化測試,LTP也提供了資料一致性的測試工具。
5、功能測試
與傳統軟體測試一樣,大資料應用程式的功能測試也是根據使用者需求來執行的。但是大資料應用程式的功能測試一般主要針對大資料應用程式中的前端部分。這裡所說的前端,是指與後端框架(Hadoop或其他)介面的,基於Web的應用程式。這類前端應用程式的測試可直接使用一般Web應用程式的功能測試方法進行測試,但需要特別注意介面測試,因為介面本身的正確性與安全性將是制約大資料應用程式整體表現的關鍵特性。
6、效能測試
效能是評估一個大資料分析系統的最為關鍵的維度,大資料系統性能主要包括吞吐量,任務完工時間,記憶體利用率等多個指標,可反應大資料分析平臺的處理能力,資源利用能力等效能。可通過hadoop效能監控器來監測執行狀態效能指標和瓶頸問題,效能測試採用自動化化方式進行,測試系統在不同負載情況下的效能。
7、容錯性測試
可從部分失效中自動恢復,而且不會驗證的影響整體效能,特別地,當故障發生時,大資料分析系統應該在進行恢復的同時繼續以可接受的方式進行操作,在發生錯誤時某種程度上可以繼續操作,需根據應用場景來設計解決方案和具體部署,然後手動測試。
8、可用性測試
高可用性已是大資料分析不可或缺的特性之一,從而保證資料應用業務的連續性。大資料高可用性對很多應用非常關鍵,需要嚴格進行測試和驗證,以手動測試為主。
9、擴充套件性測試
彈性擴充套件能力對於大資料時代的檔案系統尤其重要,檔案系統擴充套件性測試主要包括測試系統彈性擴充套件能力(擴充套件/回縮)及擴充套件系統帶來的效能影響,驗證是否具有線性擴充套件能力,以手動測試為主。
10、穩定性測試
大資料分析系統通常是不間斷長期執行,穩定性的重要性不言而喻,穩定測試主要驗證系統在長時間(7/30/180/365*24)允許下,系統是否仍然能夠正常執行,功能是否正常.穩定性測試通常採用自動化方式進行,LTP,10ZONE,POSTMARK,FIO等工具對測試系統產生負載,同時需要驗證功能。
11、壓力測試
大資料分析系統的負載能力是存在上限的,系統過載時,系統就可能存在效能下降,功能異常,拒絕訪問等問題。壓力測試是驗證系統造大壓力下,包括資料多客戶端,高OPS壓力,高IOPS/吞吐量壓力,系統是否仍然能夠正常執行,功能是否正常,系統資源消耗情況,從而為大資料運營提供依。
三、大資料測試步驟
大資料測試包括資料預處理驗證、Map Reduce驗證、結果驗證3部分。
1、資料預處理驗證
在進行大資料測試時,首先要預hadoop前驗證資料的準確性等。資料來源可能是關係資料庫、日誌系統、社交網路等等,所有應該確保資料能正確的載入到系統中,我們要驗證:
-
載入的資料和源資料是一致的;
-
確保正確的提取和載入資料至hdfs中;
2、Map Reduce驗證
在進行大資料測試時,第二個關鍵步驟是“Map Reduce”驗證。在本階段,我們主要驗證每一個處理節點的業務邏輯是否正確,並驗證在多個執行後,確保:
-
Map Reduce過程工作正常;
-
資料聚合、分離規則已經實現;
-
資料key-value關係已正確生成;
-
驗證經過map reduce後資料的準確性等特性;
3、結果驗證
在本階段主要驗證在經過大資料工具/框架處理後,生成的最終資料的成果。檢查轉換(Transformation)規則被正確應用檢查資料完整性和成功的資料載入到目標系統中。
四、大資料測試實施
1、測試流程
大資料測試與其他測試過程類似,也需要經歷不同的測試階段。其流程如下:
-
分析並評估業務需求;
-
編寫測試計劃;
-
設計測試用例,準備測試資料;
-
執行測試,迴歸測試;
-
分析測試結果,生成測試報告;
2、測試用例
以下列出大資料測試部分用例,如下:
測試場景 | 測試用例 |
Mapping Doc Validation(對映檔案驗證) | 驗證對映檔案是否提供了響應的ETL資訊,且每個對映文件的更新日誌有記錄 |
Validatioin(驗證) | 1. 根據對應的對映檔案驗證源與目的地資料倉庫的表結構;2. 驗證源和目標資料的型別一致;3. 驗證源和目標資料的長度一致;4. 驗證資料欄位型別和格式是指定的型別;5. 驗證源的資料型別長度不應小於目標資料型別長度;6. 針對對映表對資料表的列的名稱進行驗證。 |
約束驗證 | 驗證目標表中的約束關係滿足我們的期望設計。 |
資料一致性驗證 | 1. 防止語義定義相同,但特定屬性的資料型別和長度不一致的問題;2. 防止完整性約束濫用。 |
完整性驗證 | 1. 要確保所有期望的資料都已經完整的載入到目標表中;2. 要比較源和目標資料的個數(即確保計數上的完整);3. 檢查出現的任何不合格的記錄;4. 檢查目標表列中的資料沒出現被截斷的情況;5. 對邊界值進行分析檢查;6. 要檢查比較目標資料倉庫和源資料的關鍵欄位的唯一性。 |
正確性驗證 | 1. 資料要沒有拼寫錯誤或不準確的記錄;2. 無null、非惟一或超出範圍的資料記錄存在。 |
轉換 | 驗證轉換邏輯的正確性。 |
資料準確性 | 1. 數值型驗證,驗證是否為數值型別;2. 日期型驗證,驗證是否為日期格式,並且在所有日期型別資料的格式應該統一;3. 精度驗證,小數點的精度要滿足期望的精度;4. 資料檢查:檢查資料的正確性,完整性;5. null檢查。 |
拷貝驗證 | 1. 驗證目標表中業務要求所有惟一性指標均正確的實現(例如主鍵、惟一標識的鍵、或其他任一惟一表示的列);2. 驗證從源資料多列合併而成的資料是正確的;3. 驗證僅僅根據客戶要求對源資料進行了多列合併至目標表中。 |
資料完整性驗證 | 在驗證源和目標表中的資料集的完整性時,我們需要用到交集運算,以確定目標資料的完整性。 |
資料清理 | 對於不需要的列在載入至資料倉庫前應該進行刪除。 |
3、總結
1)資料可以從各種來源,以各種形式流入大資料系統,例如IOT裝置,終端掃描器,系統資料檔案,系統日誌,社交媒體等;
2) 為了更好的在Hadoop或類似框架中使用這些資料。大資料應用程式將對採集的這些資料集進行清理和驗證,以確保以後使用過程的正確;
3) 為了確保資料是否已正確匯入到Hadoop中,我們要測試資料的正確性和完整性;大資料應用程式將處理Hadoop中的資料並根據所需邏輯對其進行處理
4) Hadoop中可用的資料非常龐大,我們無法使用所有資料進行測試,所以我們選擇部分資料子整合為測試資料;
5) 針對測試資料,必須根據需求對其反覆執行相同的資料處理過程。然後對多次的處理結果進行比較,以確認大資料應用程式正在以正確的方式處理資料;
6)處理後的資料將儲存於資料倉庫中。我們需要將資料倉庫中的資料進行再次驗證,以確保其與應用程式處理後的資料保持保持一致性;
7) 一些組織使用SAP,Oracle等廠商的BI工具以可視格式分析和描述來自資料倉庫的資料,所以一旦資料以視覺化的視覺方式呈現後,必須要對其進行再次驗證;
8) 一些大資料系統還會通過Web服務將資料從資料倉庫傳輸到BI系統中。那麼在這種情況下,還必須對Web服務進行測試,這往往容易被忽略.