關于數(shù)據(jù)測試，已有不少同學寫過這方面的文章或者開發(fā)過工具。為了系統(tǒng)化，我的想法是從數(shù)據(jù)質(zhì)量模型入手，分析數(shù)據(jù)測試的抓手，然后找出數(shù)據(jù)測試中需要什么樣的工具來支撐。這里我也不會過于強調(diào)我們做的平臺，或與其他平臺作比較，而是想把平臺或者工具背后的思考過程總結(jié)和分享下。

一、數(shù)據(jù)質(zhì)量模型的探尋

1.1. ISO 9126 在數(shù)據(jù)質(zhì)量上的移植

在講到數(shù)據(jù)測試前，需要先想一個問題，怎么樣系統(tǒng)化地闡述數(shù)據(jù)質(zhì)量?

我覺得系統(tǒng)化闡述的一個思路就是尋找當下有沒有適合數(shù)據(jù)質(zhì)量的質(zhì)量模型。以傳統(tǒng)的質(zhì)量模型為例，ISO 9126 是一種典型的軟件質(zhì)量模型，無論是開發(fā)還是測試，無論是各端質(zhì)量還是服務質(zhì)量，質(zhì)量上的大方向不會跳出 9126 的模型。作為互聯(lián)網(wǎng)行業(yè)，雖然現(xiàn)階段 9126 中的二級特性不可能完全落地，但作為一個指導性的質(zhì)量模型，它會確保質(zhì)量不會有方向性的大紕漏。那數(shù)據(jù)質(zhì)量有沒有類似 9126 的模型可以參考呢?

從國外看，已知的 ISO 8000 是現(xiàn)在數(shù)據(jù)質(zhì)量方面的新興標準，但該標準一是太重，二是不免費提供，三是國內(nèi)對該標準的綜述也少的可憐，因此并沒有太多細節(jié)可供參考。從國內(nèi)來看，大家都會做到一些總結(jié)和落地，包括集團內(nèi)部的 ATA 文章也不少，有共性也有不同，但系統(tǒng)性的闡述相對少一些。我的一個想法是，既然沒有現(xiàn)成的，那是否可以嘗試將 9126 移植到數(shù)據(jù)質(zhì)量?

9126 的一級特性可以分為以下幾個：功能性、易用性、可靠性、效率、維護性、可移植性。那這幾個大項對應到數(shù)據(jù)質(zhì)量里，會是什么樣的呢?

1)功能性：軟件提供了用戶所需要的功能。二級特性包括：適合性、準確性、互用性、安全性。對數(shù)據(jù)而言，個人覺得最重要的應該屬于準確性和安全性。

a. 對于準確率，如果一句話概括就是，首先數(shù)據(jù)要有，其次數(shù)據(jù)要全，最后數(shù)據(jù)要準。對應的，就可以看到該大項下對應的小項：

數(shù)據(jù)要有 -> 數(shù)據(jù)及時性：數(shù)據(jù)要按約定時間產(chǎn)出。

數(shù)據(jù)要全 -> 數(shù)據(jù)完整性：數(shù)據(jù)不能少、不能缺。當然，也不能多。

數(shù)據(jù)要準 -> 數(shù)據(jù)準確性：數(shù)值要準確。

這幾個二級特性，可能很多同學的文章中都寫過，也討論過。這里只是從數(shù)據(jù)質(zhì)量整體系統(tǒng)性上再將其闡述一遍。需要說明的一點是，很多文章中也寫到了數(shù)據(jù)一致性這個特性。數(shù)據(jù)一致性這個概念很廣，比如關系數(shù)據(jù)庫中的外鍵一致性、CAP 理論中的強弱一致性。個人認為，數(shù)據(jù)不一致最終影響的還是數(shù)據(jù)的完整或者準確。如果業(yè)務上認為不一致性可以接受，那也不是問題。所以我更傾向于將數(shù)據(jù)一致性作為一種根因，而并不是質(zhì)量模型的一個子項。

b. 對于安全性，尤其是數(shù)據(jù)安全，命題也很大，這里不再贅述。但需要提的一點是，數(shù)據(jù)安全涉及到隱私或者差分攻擊的預防，也可能是由業(yè)務同學考慮的范疇，所以在數(shù)據(jù)質(zhì)量模型中不能忽視。

2)易用性：是指在指定條件下使用時，軟件產(chǎn)品被理解、學習、使用和吸引用戶的能力。對于數(shù)據(jù)來說，我認為數(shù)據(jù)的易用可以分為兩方面：是否被理解，是否被需要。它更多的是和日常溝通、產(chǎn)品需求及規(guī)劃相關。

是否被理解，意思是當前我們對數(shù)據(jù)的定義是否是行業(yè)認可的，是否存在團隊與團隊之間、用戶與開發(fā)者之間理解的不一致。

是否被需要，意思是當前我們提供的數(shù)據(jù)，是否真的能夠滿足用戶需要，數(shù)據(jù)的真正效果有沒有達到。比如，我們給用戶提供的是它自己品牌的數(shù)據(jù)，但用戶可能更需要的是行業(yè)下的數(shù)據(jù)來做進一步的市場規(guī)劃。

3)可靠性：在指定條件下使用時，軟件產(chǎn)品維持規(guī)定的性能水平的能力。比如上游數(shù)據(jù)無法定時給出，依賴關系的強弱配置不正確，可能影響的就是數(shù)據(jù)無法定時產(chǎn)出�？煽啃允且环N根因，最終影響的還是功能性。

4)效率：是指在規(guī)定條件下，相對于所用資源的數(shù)量，軟件產(chǎn)品是否在規(guī)定時間內(nèi)可提供適當?shù)男阅艿哪芰�。比如計算傾斜或者計算資源不足導致數(shù)據(jù)產(chǎn)不出來。效率也是一種根因，最終影響的還是功能性。

5)可維護性：是指是在修改或者新增需求時，當前的開發(fā)架構是否足夠靈活的支持，是開發(fā)階段主要考慮的。比如在數(shù)倉開發(fā)中，當新上游到來時，如果從下到上全部采用煙囪式開發(fā)，那對新增的需求必定是不友好的。如果改為 Hub 或者集市模式，可能只需要開發(fā)接入數(shù)據(jù)的 ETL 代碼，剩下的完全可以復用，就是提升可維護性的一種手段。

6)可移植性：是指軟件產(chǎn)品從一種環(huán)境遷移到另一種環(huán)境的能力，也是開發(fā)階段主要考慮的。服務或者網(wǎng)站的可移植性大家了解比較多，數(shù)據(jù)的可移植性是指什么?我個人認為可移植性強調(diào)的更多是跨技術平臺的移植，而不是模塊間的數(shù)據(jù)復用。在數(shù)據(jù)上可能就是數(shù)據(jù)直接從一個計算平臺遷移到另一個計算平臺，或者 SQL 代碼從一個計算平臺遷移到另一個計算平臺。在可移植性方面，我還沒有遇到導致質(zhì)量問題的有說服力的案例，如果大家有相關的例子可以溝通。

綜上，如果采用 9126 的思路，得到的數(shù)據(jù)質(zhì)量模型的腦圖如下。

 

 

1.2. 對移植模型的優(yōu)化

但是移植過來之后就完事兒了嗎?其實細想一下，里面還是有很多的問題，讓它不是那么好用。比較典型的問題就是：模型不正交。通俗來講就是感覺幾個特性之間有不同，但也有關系。兩個例子：

1)比如無論是可靠性、效率還是可維護性，最終影響的都是功能性，或者可以說是導致功能性問題的部分根因。可以說，功能性是用戶最終看到的質(zhì)量特性，而可靠性、效率、可維護性卻是研發(fā)看到的質(zhì)量特性。

2)有些特性又有相同點，又有不同點。比如可靠性和效率，相同點在于，雖然問題產(chǎn)生原因不同，但最終都會導致數(shù)據(jù)不產(chǎn)出。在不產(chǎn)出的情況下，臨時解法可能都會一樣，比如切前一天的數(shù)據(jù)。不同點在于，問題的根本解法有很大的不同，可靠性還是要靠強弱依賴關系檢查、架構優(yōu)化等手段解決，而效率問題要靠資源擴容等手段解決。

怎么樣能讓模型更好用呢?我在上面的基礎上進行了簡單的修改。

 

 

首先將質(zhì)量特性分為用戶可見的質(zhì)量特性和研發(fā)可見的質(zhì)量特性。因為導致用戶可見的質(zhì)量特性出現(xiàn)問題的原因，很大程度上取決于研發(fā)可見的質(zhì)量特性。

研發(fā)可見的質(zhì)量特性又分為治標特性和治本特性。所謂治標特性是指兜底，例如，如果數(shù)據(jù)產(chǎn)出出了問題，那我們有沒有快速的兜底恢復方案，是應用降級、限流還是切換舊數(shù)據(jù)?所謂治本特性是指出問題的根本原因，包括可靠 & 可維護性、效率、安全。這里把可靠和可維護性合并，是覺得兩個聯(lián)系緊密，都和研發(fā)的架構有關。把安全性從功能性移到這里，是覺得安全性對于用戶來說可見性沒有那么強，但一旦可見，后果非常嚴重，是需要在研發(fā)階段重點考慮的。通過可見性范圍將質(zhì)量模型進行重構后，在模型正交上會顯得比之前相對好些。

二、數(shù)據(jù)測試方法論探尋

2.1.數(shù)據(jù)質(zhì)量模型應用于研發(fā)過程

既然數(shù)據(jù)質(zhì)量模型有了雛形，接下來需要思考的就是質(zhì)量模型在研發(fā)過程中的落地，也就是由誰在什么時間做什么事情?首先，我們先把質(zhì)量模型平鋪到研發(fā)周期中去，x 軸為研發(fā)周期，y 軸為質(zhì)量模型，接下來要做的就是填空題，即每個研發(fā)階段在某個質(zhì)量特性上該做什么事情，這樣就得到了一個二維關系，如下圖所示。里面的內(nèi)容其實是我們根據(jù)自己產(chǎn)品線特性以及質(zhì)量活動經(jīng)驗總結(jié)出來的，但總體看下來，大致和傳統(tǒng)質(zhì)量是相似的。

 

 

填完內(nèi)容之后，至于由誰來做就一目了然了。易用性的問題涉及到商業(yè)調(diào)研、用戶需求和產(chǎn)品規(guī)劃，更多的是 PD 主導的事情。其他幾個特性，也就是藍框中的特性都是開發(fā)測試階段需要考慮的特性。

2.2.數(shù)據(jù)質(zhì)量模型中的測試抓手

那測試的抓手主要在哪兒?很明顯，如果從代表用戶的角度，那最直接的切入點就是功能性這個特性。一方面它是用戶可見的特性，測試從用戶的角度發(fā)現(xiàn)問題;另一方面所有研發(fā)可見的特性導致的質(zhì)量問題最終都會落到功能性上，可以用功能性做問題發(fā)現(xiàn)的最后兜底。

除了功能性，還有需要測試重點考慮的特性么?我個人的經(jīng)驗是，容災性是需要考慮的。因為作為研發(fā)修復問題的兜底方法，容災性的有無或好壞會嚴重影響到功能性。這也是我把他從質(zhì)量模型中獨立出來的一個考慮。測試在容災的預案制定上應該起到一定的 review 作用。

至于其他幾個特性，效率也好，可靠 & 可維護性，安全性也好，要根據(jù)項目性質(zhì)是日常還是大促，是功能新增還是功能優(yōu)化，甚至測試團隊是新建還是有所積累有關。對于日常項目、功能新增、團隊新建等，在功能性 & 容災上的投入是最大的，而功能性測試又是兩者中最大的。隨著功能性上的完善，會逐漸投入到效率、可靠 & 可維護性上。而在大促、功能優(yōu)化、團隊積累時，在容災性、效率、可靠性 & 可維護性上的投入比功能性要更重。所以我認為數(shù)據(jù)測試公式應該是：

數(shù)據(jù)測試 = 基礎測試(功能性 + 容災性) + 選擇評估(效率 ||可靠 & 可維護性 || 安全性)

鑒于功能性測試在整個數(shù)據(jù)測試中的主體位置，2.3 會詳細介紹功能性測試的方法。其他幾個特性的測試在 2.4、2.5 中簡單描述。

2.3.數(shù)據(jù)測試中的功能性測試方法

對于傳統(tǒng)功能測試或者接口測試來說，就是通過構造輸入，檢查輸出。對于數(shù)據(jù)測試來說也是如此，只不過最終測試的對象由界面、接口返回換成了數(shù)據(jù)。如果將數(shù)據(jù)測試活動分解來看，比較重要的活動有三個：輸入數(shù)據(jù)構造、輸出數(shù)據(jù)的測試方法、測試執(zhí)行時機。接下來會分別對這三部分的測試方法進行描述。最后，CR 作為一種典型而又有效的檢查數(shù)據(jù)準確性方法，也會做簡單介紹。

1)輸入數(shù)據(jù)的構造

并不是所有項目都需要輸入數(shù)據(jù)的構造，像我所在的產(chǎn)品線“數(shù)據(jù)銀行”目前并不是通過輸入數(shù)據(jù)構造的方式進行測試的。什么樣的產(chǎn)品線會適合輸入數(shù)據(jù)的構造呢?

我的觀點是，如果對線上異常數(shù)據(jù)十分敏感的業(yè)務，是需要做輸入數(shù)據(jù)的構造的。對輸入數(shù)據(jù)進行構造，實際上并不容易，首先需要測試根據(jù)要求生成一批數(shù)據(jù)，然后使用開發(fā)提供的業(yè)務代碼運行這批數(shù)據(jù)，最終產(chǎn)生輸出數(shù)據(jù)。如果業(yè)務代碼只依賴一張表還好，但如果依賴多張表的話，那需要考慮到多張表的輸入數(shù)據(jù)的構造。

如果對線上異常數(shù)據(jù)并沒有那么敏感的業(yè)務，或者上游數(shù)據(jù)質(zhì)量相對高的業(yè)務，其實不一定要在測試階段生成各種輸入的異常數(shù)據(jù)。開發(fā)可以提測某份快照數(shù)據(jù)來重點驗證數(shù)據(jù)處理邏輯的正確性，而因為對輸入的異常數(shù)據(jù)考慮欠佳導致輸出數(shù)據(jù)異常的情況，還是可以采用線上持續(xù)監(jiān)控的方式進行。這一點后面也會說。

2)輸出數(shù)據(jù)的測試方法

在輸出數(shù)據(jù)的測試方法上，根據(jù)功能性下的三個二級特性：及時性、完整性、準確性，對應有不同的測試方法。下面的腦圖是一個方法匯總。

 

 

及時性：相對來說測試方法較為簡單，需要做到的就是有沒有在規(guī)定的時間內(nèi)產(chǎn)出數(shù)據(jù)，可以通過檢查全表條數(shù)或者檢查分區(qū)條數(shù)來判斷。

完整性：完整性重點評估的兩點是：數(shù)據(jù)不多，數(shù)據(jù)不少。

不多：一般是檢查全表數(shù)據(jù)、重要枚舉值數(shù)據(jù)有沒有重復或者數(shù)據(jù)主鍵是否唯一。

不少：一般是對全表數(shù)據(jù)或業(yè)務相關的重要字段(比如日期、枚舉值、品牌、類目等)進行檢查。如果數(shù)據(jù)規(guī)模是可以被知曉的，比如知道表中品牌有 x 條，那每次檢查 x 條即可。如果數(shù)據(jù)規(guī)模本身變動較大導致不可被知曉(比如表中的品牌數(shù)會開通或關閉)，常用的方法就是通過對比歷史數(shù)據(jù)，看整體波動是否正常。

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

a. 自身檢查：是指在不和其他數(shù)據(jù)比較的前提下，用自身數(shù)據(jù)來檢查準確的情況，屬于最基本的一種檢查。自身檢查的測試方法只能將數(shù)據(jù)正確的概率提高，但受限于信息量，提高程度有限。有三種比較典型的方法。

第一種方法是該值是否在常規(guī)范圍內(nèi)，舉個例子，比如人數(shù)占比，理論上都會在 [0,1] 之間，屬于對值進行最基本的檢查;

第二種方法是該值是否在業(yè)務范圍內(nèi)，一般是對該值業(yè)務屬性了解后的一個判斷，比如如果我測試的是某產(chǎn)品搜索人數(shù)，如果觸發(fā)渠道唯一的話，理論上該產(chǎn)品的搜索人數(shù) >= 該產(chǎn)品的購買人數(shù)，這種就是在了解值背后的業(yè)務之后的判斷;

第三種方法是該值的分布，如果對某個值的業(yè)務特性有明確的了解，通過觀察值分布也可以測試其準確性。比如如果測試“購買人數(shù)中的會員占比”這個值，可以觀察其在數(shù)據(jù)中分布，認知該比例應該在 0.3 左右。如果測試完分布，結(jié)果發(fā)現(xiàn) 80% 大致在 0.2-0.4 之間，那就符合認知。如果結(jié)果發(fā)現(xiàn) 80% 在 0.8-0.9 之間，那就不符合認知。

b. 時間維度上的比較：如果把數(shù)據(jù)放到時間維度上比較，可以繼續(xù)提升數(shù)據(jù)準確的概率。有兩種方法：一種方法是在同一數(shù)據(jù)批次內(nèi)觀察同一個數(shù)據(jù)不同時間的情況，一種方法是在不同數(shù)據(jù)批次內(nèi)觀察同一數(shù)據(jù)的情況。

同一批次：比如開發(fā)線下提測了一批數(shù)據(jù)，這就是同一數(shù)據(jù)批次，在該批次下，可以比較 ds=20180901、ds=20180902、ds=20180903 等不同日期的數(shù)據(jù)的波動。

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

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

一種是上下游比較，尤其是重要字段在上下游的加工過程中有沒有信息丟失;

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

最后一種是和系統(tǒng)外的數(shù)據(jù)進行比較，比如 BI 系統(tǒng)、其他業(yè)務后臺系統(tǒng)比較。這種方法用起來受限制較多，因為從安全角度考慮，常規(guī)的 BI 系統(tǒng)或者其他業(yè)務后臺系統(tǒng)都不太可能將數(shù)據(jù)開放出來，所以該方法只作為一種可能的思路。

3)測試執(zhí)行時機

關于測試執(zhí)行時機方面，和傳統(tǒng)測試相同，有如下幾個測試時機：自測時、提測后、線上數(shù)據(jù)修改、線上數(shù)據(jù)新增。

無論是自測還是提測，關注的都是線下，而線下數(shù)據(jù)測試是有一定局限性的。如果不采用輸入數(shù)據(jù)構造的方法，那開發(fā)一般只提測一部分數(shù)據(jù)，比如某天的數(shù)據(jù)，但也正是由于提測數(shù)據(jù)的片面性，即使提測數(shù)據(jù)沒問題也不能代表數(shù)據(jù)處理規(guī)則就完全沒有問題;如果采用輸入數(shù)據(jù)構造的方法，雖然能在線下發(fā)現(xiàn)更多的因為輸入數(shù)據(jù)異常導致的輸出數(shù)據(jù)異常，但因為線上生產(chǎn)環(huán)境本身穩(wěn)定性等治本問題，仍然不能代表后續(xù)線上就沒有問題。

正是因為線下數(shù)據(jù)的局限性，所以當線上數(shù)據(jù)修改或者線上數(shù)據(jù)新增時，仍需要持續(xù)進行測試。線上測試 case 有可能完全使用線下的 case，也有可能對線下 case 進行簡單修改后使用。

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

而線上則要區(qū)分使用場景：對于線上數(shù)據(jù)修改來說，這種操作并不是常規(guī)操作，是當需求出現(xiàn)問題或者修復 Bug 時才會出現(xiàn)的操作，所以一般情況下也需要用條件觸發(fā)。對于線上數(shù)據(jù)新增來說，一般是每天定期產(chǎn)出新數(shù)據(jù)。這種既可以采用條件觸發(fā)(即生成新數(shù)據(jù)后觸發(fā)測試)，也可以采用定時觸發(fā)(即定時輪詢是否有新數(shù)據(jù)生成并測試)。條件觸發(fā)的好處是類似于持續(xù)集成中，持續(xù)測試的概念，只要涉及數(shù)據(jù)改動就要觸發(fā)測試，但它并不能很好的關注及時性;而定時觸發(fā)的好處是可以及時關注及時性，但對于及時性要求不是很高的數(shù)據(jù)(比如有時候 8 點產(chǎn)出，有時候 10 點產(chǎn)出)，那定時觸發(fā)就會導致很多的誤報。

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

在自測時，主要是開發(fā)團隊進行測試。測試 case 更關注數(shù)據(jù)基礎質(zhì)量的測試，比如完整性和準確性中的自身檢查。這部分 case 不需要太多發(fā)散性思維。

在提測后，主要是測試團隊進行測試。除了數(shù)據(jù)的基礎質(zhì)量測試外，測試 case 更關注“快照”，即準確性中的空間維度和時間維度的不同批次的對比上，盡可能通過輔證的方式發(fā)現(xiàn)數(shù)據(jù)準確性中的問題。而在同一批次的時間維度方面，往往開發(fā)不會提測很多時間點的數(shù)據(jù)，所以一般情況來說，輔證難度會更大。

在線上數(shù)據(jù)修改時，基本上可以復用提測后使用的 case。

在線上數(shù)據(jù)新增時，除了數(shù)據(jù)的基礎質(zhì)量測試外，絕大部分可以復用提測后使用的 case，但會弱化一部分具有探索性思路的 case 或者是運行時間過長的 case。比如測試值的分布 case 就不適合每天新增時測試，因為每天的數(shù)據(jù)分布可能有所不同，并不是穩(wěn)態(tài)，加入這種 case 會造成誤報率的提升。再比如測試數(shù)據(jù)量過大的 case，尤其是上下游對比測試，往往下游數(shù)據(jù)量會很大，每天定時測試一方面會消耗太多時間和資源，另一方面也沒有必要，因為這種問題產(chǎn)生的原因往往是數(shù)據(jù)處理邏輯的問題，一般線下一次測試就可以發(fā)現(xiàn)。線上測試會添加時間維度中，同一數(shù)據(jù)批次中不同時間的波動性的對比。

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

 

 

4)CR

雖然在測試方法一節(jié)中介紹了通過輸出數(shù)據(jù)發(fā)現(xiàn)問題的方法，但發(fā)現(xiàn)問題最直接有效的方法還是 CR，尤其是對類 SQL 數(shù)據(jù)庫的準確性問題來說。下面是 SQL CR 中經(jīng)常用到的一些 CR 規(guī)則。

★ 投影操作

字段順序、類型與表聲明一致

表中字段的業(yè)務含義是否是業(yè)務要求的含義

業(yè)務上是否要求數(shù)據(jù)去重

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

是否對數(shù)據(jù)精度有明確要求。

★ 關聯(lián)關系

關聯(lián)表使用 outer join 還是 join，要看數(shù)據(jù)做不做過濾

關聯(lián)關系 on 字句中，左右值類型是否一致

關聯(lián)關系如果是 1：1，那么對方表的關聯(lián)鍵是否唯一。

★ 過濾條件

有沒有分區(qū)過濾，是在 where 過濾還是在 on 過濾，分區(qū)用 max_pt 還是 ds

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

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

有沒有數(shù)據(jù)的限定來源

★ 數(shù)據(jù)同步任務測試

字段相等

在從 OLAP 導入 OLTP 之前，需不需要做預處理，比如 delete。

在主鍵相同時，主鍵相同的數(shù)據(jù)如何處理。

2.4. 數(shù)據(jù)測試中的容災性評估方法

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

2.5. 數(shù)據(jù)測試中的其他特性的評估方法

剩下一些特性，開發(fā)同學可能會有更加詳細的文章闡述，這里只是從測試角度簡單描述。

1)效率評估方法：效率評估主要是當前數(shù)據(jù)的計算資源是否滿足當前產(chǎn)品的時間要求。需要分三種情況：一是用戶直接觸發(fā)的計算請求是否過大;二是用戶數(shù)據(jù)是否過多，從而造成計算量過大的情況;三是程序本身效率是否低下，性能過低，導致資源消耗過大。第一種情況往往通過構造請求流量，進行壓測評估。后兩種一般會通過大盤的方式，找出哪張表運行時間最長，最影響效率，來逐步進行優(yōu)化。

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

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

可維護性上，盡可能將體系化的開發(fā)工作集成化或者平臺化。比如，將數(shù)據(jù)的接入模式從煙囪型的模式轉(zhuǎn)為星型的集市模式，從而只負責接入數(shù)據(jù)的 ETL，盡可能減少開發(fā)工作就是集成化的一種思路。平臺化的思路就是將流程化的開發(fā)工作，通過平臺的方式進行配置來完成，一方面提高開發(fā)效率，另一方面減少出錯成本，提升開發(fā)質(zhì)量。

3)安全性評估方法：關于安全性評估，我暫時沒有經(jīng)驗和案例，有的同學可以一起討論。

三、依托數(shù)據(jù)測試方法論的測試工具建設

二中已經(jīng)闡述了數(shù)據(jù)測試方法論，那在這樣一種方法論下，需要什么樣的數(shù)據(jù)測試工具呢?接下來主要介紹下以類 SQL 數(shù)據(jù)庫為基礎的數(shù)據(jù)測試工具規(guī)劃思路。

從測試工具的功能上看，數(shù)據(jù)的功能性特性測試應該是最重的一個環(huán)節(jié)，它需要涵蓋輸入數(shù)據(jù)的構造、輸出數(shù)據(jù)的測試方法、測試執(zhí)行時機的支持、CR 等功能。而容災、效率、可靠 & 可維護性、安全性等特性，相對測試人員來說，開發(fā)在這方面積累的更深，所以測試工具可以做到支持對其他特性的測試擴展，加入到工具中來。

從測試工具的效率上看，數(shù)據(jù)測試天生就是有自動化屬性的，因為測試人員不可能肉眼一條條對數(shù)據(jù)進行 check。所以對數(shù)據(jù)測試工具的效率討論，理論上不集中在是否要自動化，而是在對數(shù)據(jù)測試方法流程的改進上。數(shù)據(jù)測試方法流程包括測試 case 的編寫和積累、測試 case 的無監(jiān)督執(zhí)行、測試結(jié)果的自動分析。將整個的數(shù)據(jù)測試工作通過一套工具進行串聯(lián)，同時也將已有的 case 進行快速復用，對數(shù)據(jù)測試效率的提高是很有幫助的。

從整個數(shù)據(jù)測試的發(fā)展來看，數(shù)據(jù)測試比傳統(tǒng)軟件測試所不同的是，它的模式性會更強，模式性強的原因是因為本身數(shù)據(jù)的開發(fā)使用語言都是相對模式化的，開發(fā)的模式化也意味著測試的模式化。對于一個有豐富經(jīng)驗的數(shù)據(jù)測試人員來說，會更容易將經(jīng)驗進行下沉，傳遞給其他測試人員，甚至開發(fā)人員。所以我的一個預測是，數(shù)據(jù)測試雖然發(fā)展比傳統(tǒng)軟件晚，但是在強模式性的背景下，它做到 0 測試人員介入，是相對容易實現(xiàn)的。所以在這個背景下，測試工具應該具備將經(jīng)驗傳承進行匯總并傳承的能力，從剛開始的只解放測試人員，逐步發(fā)展到到解放研發(fā)流程。

所以總結(jié)下數(shù)據(jù)測試工具的需求有這么幾個：

需求一：支持輸入數(shù)據(jù)的構造、支持 CR。

需求二：支持輸出數(shù)據(jù)的功能性測試。

需求三：支持對其他測試方法的低耦合式接入。

需求四：支持測試執(zhí)行時機的靈活選擇。

需求五：支持測試 case 的快速編寫和重復利用。

需求六：支持對測試過程的串聯(lián)。

需求七：支持測試經(jīng)驗的下沉和復用。

根據(jù)上述需求，一個典型的數(shù)據(jù)測試框架應該包含以下幾個部分。

 

 

測試時機觸發(fā)能力：支持需求四。數(shù)據(jù)測試框架應該包含 API 層，無論是條件觸發(fā)還是定時觸發(fā)，都會調(diào)用 API 完成任務的觸發(fā)。條件觸發(fā)根據(jù)數(shù)據(jù)庫不同，可以看是否可以和數(shù)據(jù)庫本身的消息系統(tǒng)做對接，即數(shù)據(jù)發(fā)生變動后，通知消息系統(tǒng)，消息系統(tǒng)調(diào)用 API 觸發(fā)整個測試任務;定時觸發(fā)可以采用 crontab 封裝一個 job，在 job 中調(diào)用 api 觸發(fā)。

測試過程串聯(lián)能力：支持需求六。測試過程能力是將整個的測試活動進行管理的能力。典型的測試活動管理能力包括以下幾部分：任務生成、任務拆分、任務執(zhí)行、結(jié)果分析。當新建測試活動時，調(diào)用任務生成模塊去生成測試任務，支持對不同特性的測試。任務拆分的作用是在任務執(zhí)行的時候，對異構任務進行拆分或者對同構任務進行并行化拆分。任務執(zhí)行的作用是將任務實際提交到對應的數(shù)據(jù)源進行計算。結(jié)果分析的作用是對數(shù)據(jù)源的結(jié)果進行回流，并對結(jié)果進行分析。

測試經(jīng)驗復用 & 積累能力：支持需求七。需求七理論上不僅僅是只通過 AI 的方式進行測試經(jīng)驗的推薦，而是也想把測試人員已有經(jīng)驗進行總結(jié)下沉的過程。

功能性測試能力：支持需求二、需求五。如何支持測試 case 的快速編寫?我們的思路是當用戶通過功能測試方法進行測試的時候，會調(diào)用一個個的指標。指標實際上可以理解成一個函數(shù)，它是對功能性測試中一些典型 case 的抽象。當用戶調(diào)用某指標時，給出指標參數(shù)，系統(tǒng)就可以自動翻譯成類 sql。這樣不僅減少了用戶寫 sql 的時間，又能很快速地將 case 和作用對應起來，同時在進行測試經(jīng)驗積累和復用的時候，就可以通過指標的概念進行。為什么翻譯成類 sql 而不是真正的 sql 實例?是考慮到適配的問題。如何能在 ODPS 上和 ADS 上都能執(zhí)行呢?通過將類 SQL 通過翻譯引擎轉(zhuǎn)化成實際的 SQL 就可以做到。

其他特性測試擴展能力：支持需求三�？磮D可以知道，這部分采用組件擴展能力是最好的。為什么?之前也說過，在容災、效率等特性的評估上，集團里已經(jīng)有很多很好的工具，同時開發(fā)在這方面也有很多積累，沒有必要另起爐灶去做這方面的事情。唯一需要的就是將其他特性的測試容納進任務中，和功能測試一起，作為一套完成的測試解決方案，方便后續(xù)追溯、沉淀和復用。

輸入數(shù)據(jù)構造 &CR 能力：支持需求一。CR 能力方面，如果有類似 Intellij 上，自動提示或者警醒開發(fā)同學可能 SQL 在哪方面有問題，這種模式實際上是最好的。不過比較困難的是，SQL 可能能沉淀出來的通用代碼檢查規(guī)則會比較少，大部分還是需要根據(jù)對業(yè)務的理解來進行，所以如果測試工具能將業(yè)務上對 SQL review 的經(jīng)驗保存下來，并提示給用戶，在 CR 上也能起到一定的作用。在輸入數(shù)據(jù)構造方面，有其他同學在做類似的工具，我本身因為產(chǎn)品線的關系暫時沒有做過相關工作，所以在此只是列舉出來，大家有興趣可以查看相關文章。

質(zhì)量大盤能力：質(zhì)量大盤并不是推導出的需求。但是在以結(jié)果導向為主的今天，我們做的事情到底現(xiàn)在是什么樣的情況，沒有質(zhì)量大盤數(shù)據(jù)的支持，往往無法知道。所以質(zhì)量大盤需要收集測試活動中的數(shù)據(jù)，包括任務執(zhí)行成功率、Case 覆蓋率、線上新增數(shù)據(jù)的監(jiān)控覆蓋率等，指導后續(xù)數(shù)據(jù)測試的提升工作。

四、寫在最后

寫這篇長文的過程中，重要的是通過對個人思路進行了一次系統(tǒng)梳理，將現(xiàn)在乃至之前的工作經(jīng)驗都容納在了該方法中。目前已經(jīng)完成了部分模型實踐和平臺開發(fā)工作，希望接下來還是繼續(xù)深入落地數(shù)據(jù)測試的相關事項，將目前我們做的數(shù)據(jù)測試工具按思路完善起來。也期待與業(yè)界同仁共同交流，一起進步。

來源：阿里技術

作者：小郅

標簽： 數(shù)據(jù)測試 大數(shù)據(jù)測試

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。