大資料是越來越多我們所聽到的詞彙，那麼如何做好大資料測試？

1，從資料質量模型入手，分析資料展現的規律

什麼是資料的質量模型？

傳統的質量模型有ISO9126，這個是一個典型的軟體質量模型，無論是開發還是測試，無論是每個終端的質量，還是服務端的質量，大的方向都不會跳出9126的模型；

當然，國外還有ISO8000是資料質量方面炒的比較熱的一個標準，但是缺點也顯而易見。1，不免費提供。2，標準太重。3，國內對這個的資料少的可憐。

那麼我們可以嘗試套用9126的標準移植到大資料質量？

先介紹下9126：

對比上面的質量模型，我們推演一下資料質量模型

我們透過上面的分析不難看出測試資料的相關case了

及時性：相對來說測試方法較為簡單，需要做到的就是有沒有在規定的時間內產出資料，可以透過檢查全表條數或者檢查分割槽條數來判斷。

完整性：完整性重點評估的兩點是：資料不多，資料不少。

不多：一般是檢查全表資料、重要列舉值資料有沒有重複或者資料主鍵是否唯一。

不少：一般是對全表資料或業務相關的重要欄位（比如日期、列舉值、品牌、類目等）進行檢查。如果資料規模是可以被知曉的，比如知道表中品牌有x條，那每次檢查x條即可。如果資料規模本身變動較大導致不可被知曉（比如表中的品牌數會開通或關閉），常用的方法就是透過對比歷史資料，看整體波動是否正常。

準確性：準確性相比來說，是比較不容易測試的一種特性，為什麼？因為很難去找一個理性的參照物，來說明資料有多準，大部分都存在於認知中。正是因此，準確性測試也是在資料質量模型體系化過程中思維相對發散的一個例子。於是我在發散的思維中從自身、時間、空間的維度試圖總結下準確性的測試方法。雖然也總結出了一些方向性思路，但是每種思路還是要依賴於個人的發散性思維以及對業務的理解才能最終將其用好。

a.自身檢查：是指在不和其他資料比較的前提下，用自身資料來檢查準確的情況，屬於最基本的一種檢查。自身檢查的測試方法只能將資料正確的機率提高，但受限於資訊量，提高程度有限。有三種比較典型的方法。

第一種方法是該值是否在常規範圍內，舉個例子，比如男女佔比，理論上都會在[0,1]之間，屬於對值進行最基本的檢查；

第二種方法是該值是否在業務範圍內，一般是對該值業務屬性瞭解後的一個判斷，比如如果我測試的是某產品搜尋人數，如果觸發渠道唯一的話，理論上該產品的搜尋人數>=該產品的購買人數，這種就是在瞭解值背後的業務之後的判斷；

第三種方法是該值的分佈，如果對某個值的業務特性有明確的瞭解，透過觀察值分佈也可以測試其準確性。比如如果測試“購買人數中的會員佔比”這個值，可以觀察其在資料中分佈，認知該比例應該在0.3左右。如果測試完分佈，結果發現80%大致在0.2-0.4之間，那就符合認知。如果結果發現80%在0.8-0.9之間，那就不符合認知。

b.時間維度上的比較：如果把資料放到時間維度上比較，可以繼續提升資料準確的機率。有兩種方法：一種方法是在同一資料批次內觀察同一個資料不同時間的情況，一種方法是在不同資料批次內觀察同一資料的情況。

同一批次：比如開發線下提測了一批資料，這就是同一資料批次，在該批次下，可以比較 date=20200324、date=20200323、date=20200322等不同日期的資料的波動。

不同批次：這種相對來說比較難找，因為對於資料來說，很少有保留好幾個資料版本的情況，但有一個比較典型的案例，就是線上線下的資料 diff。如果認為線下的版本是 N，那可以認為線上的版本就是 N-1。透過線上線下的資料 diff，能將確定不會改變的資料進行diff檢查。

c.空間維度上的比較：空間維度上的比較，是指固定了時間維度，將當前數值和其他資料進行比較，進一步輔助正確性。也有三種基本思路：

一種是上下游比較，尤其是重要欄位在上下游的加工過程中有沒有資訊丟失；

一種是和除上下游外的其他資料進行比較，比如和同一資料來源下的兄弟表進行比較，或者和不同資料來源下的表進行比較。同一資料來源的例子，比如表 A 是某個一級類目的銷售資料，表 B 是該一級類目下二級類目的銷售資料，那麼表 B 的數值相加=表 A 資料。不同資料來源的例子，比如為了計算效能考慮，部分資料會從行式資料庫同步到列式資料庫進行計算，那行式資料庫中的數值應該和列式資料庫中的數值應該是相等的；

最後一種是和系統外的資料進行比較，比如 BI 系統、其他業務後臺系統比較。這種方法用起來受限制較多，因為從安全形度考慮，常規的 BI 系統或者其他業務後臺系統都不太可能將資料開放出來，所以該方法只作為一種可能的思路。

3）測試執行時機

關於測試執行時機方面，和傳統測試相同，有如下幾個測試時機：自測時、提測後、線上資料修改、線上資料新增。

無論是自測還是提測，關注的都是線下，而線下資料測試是有一定侷限性的。如果不採用輸入資料構造的方法，那開發一般只提測一部分資料，比如某天的資料，但也正是由於提測資料的片面性，即使提測資料沒問題也不能代表資料處理規則就完全沒有問題；如果採用輸入資料構造的方法，雖然能線上下發現更多的因為輸入資料異常導致的輸出資料異常，但因為線上生產環境本身穩定性等治本問題，仍然不能代表後續線上就沒有問題。

正是因為線下資料的侷限性，所以當線上資料修改或者線上資料新增時，仍需要持續進行測試。線上測試 case 有可能完全使用線下的 case，也有可能對線下 case 進行簡單修改後使用。

將測試時機獨立出來討論的一個好處是，如果將一系列測試 case 組成任務的話，無論是線下還是線上，只要有合適的觸發條件，就可以用合適的觸發方法執行這些測試case。觸發方法包括條件觸發和定時觸發。一般來講，線下使用的是條件觸發，即當開發完成需要自測或者提測後測試需要測試時，透過 API 或者介面觸發執行。

而線上則要區分使用場景：對於線上資料修改來說，這種操作並不是常規操作，是當需求出現問題或者修復 Bug 時才會出現的操作，所以一般情況下也需要用條件觸發。對於線上資料新增來說，一般是每天定期產出新資料。這種既可以採用條件觸發（即生成新資料後觸發測試），也可以採用定時觸發（即定時輪詢是否有新資料生成並測試）。條件觸發的好處是類似於持續整合中，持續測試的概念，只要涉及資料改動就要觸發測試，但它並不能很好的關注及時性；而定時觸發的好處是可以及時關注及時性，但對於及時性要求不是很高的資料（比如有時候6點產出，有時候9點產出），那定時觸發就會導致很多的誤報。

在不同測試時機上，雖然用到的測試 case 大部分都是可複用的，但是也會有些不同。

在自測時，主要是開發團隊進行測試。測試 case 更關注資料基礎質量的測試，比如完整性和準確性中的自身檢查。這部分 case 不需要太多發散性思維。

在提測後，主要是測試團隊進行測試。除了資料的基礎質量測試外，測試 case 更關注“快照”，即準確性中的空間維度和時間維度的不同批次的對比上，儘可能透過輔證的方式發現資料準確性中的問題。而在同一批次的時間維度方面，往往開發不會提測很多時間點的資料，所以一般情況來說，輔證難度會更大。

線上上資料修改時，基本上可以複用提測後使用的 case。

線上上資料新增時，除了資料的基礎質量測試外，絕大部分可以複用提測後使用的 case，但會弱化一部分具有探索性思路的 case 或者是執行時間過長的 case。比如測試值的分佈 case 就不適合每天新增時測試，因為每天的資料分佈可能有所不同，並不是穩態，加入這種 case 會造成誤報率的提升。再比如測試資料量過大的 case，尤其是上下游對比測試，往往下游資料量會很大，每天定時測試一方面會消耗太多時間和資源，另一方面也沒有必要，因為這種問題產生的原因往往是資料處理邏輯的問題，一般線下一次測試就可以發現。線上測試會新增時間維度中，同一資料批次中不同時間的波動性的對比。

因此，測試時機對測試的影響可以概括成一張表。

4）CR

雖然在測試方法一節中介紹了透過輸出資料發現問題的方法，但發現問題最直接有效的方法還是 CR，尤其是對類 SQL 資料庫的準確性問題來說。下面是 SQL CR 中經常用到的一些 CR 規則。

投影操作

欄位順序、型別與表宣告一致

表中欄位的業務含義是否是業務要求的含義

業務上是否要求資料去重

是否可能存在異常情況，如除數為0、Null、空的情況

是否對資料精度有明確要求。

★ 關聯關係

關聯表使用 outer join 還是 join，或者inner join，要看資料做不做過濾

關聯關係 on 字句中，左右值型別是否一致

★ 過濾條件

涉及字串的等號注意大小寫及正確性

有沒有考慮到 Null、0、空等異常值的過濾

有沒有資料的限定來源

資料測試中的容災性評估方法

容災性評估主要是當資料未產出或者資料出現大面積問題時，如何快速止損。比較典型的做法是做可用資料的快速切換，比如快速切換成前一天的資料或者上一個版本的資料。這種情況一般需要服務端配合來完成。

1）效率評估方法：效率評估主要是當前資料的計算資源是否滿足當前產品的時間要求。需要分三種情況：一是使用者直接觸發的計算請求是否過大；二是使用者資料是否過多，從而造成計算量過大的情況；三是程式本身效率是否低下，效能過低，導致資源消耗過大。第一種情況往往透過構造請求流量，進行壓測評估。後兩種一般會透過大盤的方式，找出哪張表執行時間最長，最影響效率，來逐步進行最佳化,包括SQL查詢最佳化。

2）可靠&可維護性評估方法：可靠&可維護性的評估，開發參與較多，測試相對參與較少。比較典型的幾個思路是：

可靠性上對任務的強弱依賴進行檢查。

可維護性上，儘可能將體系化的開發工作整合化或者平臺化。比如，將資料的接入模式從煙囪型的模式轉為星型的集市模式，從而只負責接入資料的 ETL，儘可能減少開發工作就是整合化的一種思路。平臺化的思路就是將流程化的開發工作，透過平臺的方式進行配置來完成，一方面提高開發效率，另一方面減少出錯成本，提升開發質量

【編測編學】如何做好大資料測試

相關文章