【編測編學】如何作好大數據測試

大數據是愈來愈多咱們所聽到的詞彙，那麼如何作好大數據測試？
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=2020032四、date=2020032三、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，儘量減小開發工做就是集成化的一種思路。平臺化的思路就是將流程化的開發工做，經過平臺的方式進行配置來完成，一方面提升開發效率，另外一方面減小出錯成本，提高開發質量