阿里妹導(dǎo)讀：大數(shù)據(jù)已然是當(dāng)下的重要課題，大大小小的企業(yè)在重視大數(shù)據(jù)的同時(shí)，也漸漸重視大數(shù)據(jù)質(zhì)量的問題。阿里巴巴測試開發(fā)專家小郅，今天會分享他對數(shù)據(jù)測試的系統(tǒng)性思考。文章內(nèi)容架構(gòu)清晰，內(nèi)容較長，建議大家收藏閱讀哦~

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

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

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

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

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

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

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

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

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

• 數(shù)據(jù)要有 -> 數(shù)據(jù)及時(shí)性：數(shù)據(jù)要按約定時(shí)間產(chǎn)出。
• 數(shù)據(jù)要全 -> 數(shù)據(jù)完整性：數(shù)據(jù)不能少、不能缺。當(dāng)然，也不能多。
• 數(shù)據(jù)要準(zhǔn) -> 數(shù)據(jù)準(zhǔn)確性：數(shù)值要準(zhǔn)確。

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

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

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

• 是否被理解，意思是當(dāng)前我們對數(shù)據(jù)的定義是否是行業(yè)認(rèn)可的，是否存在團(tuán)隊(duì)與團(tuán)隊(duì)之間、用戶與開發(fā)者之間理解的不一致。
• 是否被需要，意思是當(dāng)前我們提供的數(shù)據(jù)，是否真的能夠滿足用戶需要，數(shù)據(jù)的真正效果有沒有達(dá)到。比如，我們給用戶提供的是它自己品牌的數(shù)據(jù)，但用戶可能更需要的是行業(yè)下的數(shù)據(jù)來做進(jìn)一步的市場規(guī)劃。

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

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

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

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

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

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

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

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

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

怎么樣能讓模型更好用呢？我在上面的基礎(chǔ)上進(jìn)行了簡單的修改。

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

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

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

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

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

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

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

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

除了功能性，還有需要測試重點(diǎn)考慮的特性么？我個(gè)人的經(jīng)驗(yàn)是，容災(zāi)性是需要考慮的。因?yàn)樽鳛檠邪l(fā)修復(fù)問題的兜底方法，容災(zāi)性的有無或好壞會嚴(yán)重影響到功能性。這也是我把他從質(zhì)量模型中獨(dú)立出來的一個(gè)考慮。測試在容災(zāi)的預(yù)案制定上應(yīng)該起到一定的 review 作用。

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

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

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

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

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

1）輸入數(shù)據(jù)的構(gòu)造

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

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

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

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

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

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

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

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

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

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

• 第一種方法是該值是否在常規(guī)范圍內(nèi)，舉個(gè)例子，比如人數(shù)占比，理論上都會在[0,1]之間，屬于對值進(jìn)行最基本的檢查；
• 第二種方法是該值是否在業(yè)務(wù)范圍內(nèi)，一般是對該值業(yè)務(wù)屬性了解后的一個(gè)判斷，比如如果我測試的是某產(chǎn)品搜索人數(shù)，如果觸發(fā)渠道唯一的話，理論上該產(chǎn)品的搜索人數(shù)>=該產(chǎn)品的購買人數(shù)，這種就是在了解值背后的業(yè)務(wù)之后的判斷；
• 第三種方法是該值的分布，如果對某個(gè)值的業(yè)務(wù)特性有明確的了解，通過觀察值分布也可以測試其準(zhǔn)確性。比如如果測試“購買人數(shù)中的會員占比”這個(gè)值，可以觀察其在數(shù)據(jù)中分布，認(rèn)知該比例應(yīng)該在0.3左右。 如果測試完分布，結(jié)果發(fā)現(xiàn)80%大致在0.2-0.4之間，那就符合認(rèn)知。如果結(jié)果發(fā)現(xiàn)80%在0.8-0.9之間，那就不符合認(rèn)知。

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

• 同一批次：比如開發(fā)線下提測了一批數(shù)據(jù)，這就是同一數(shù)據(jù)批次，在該批次下，可以比較 ds=20180901、ds=20180902、ds=20180903等不同日期的數(shù)據(jù)的波動。
• 不同批次：這種相對來說比較難找，因?yàn)閷τ跀?shù)據(jù)來說，很少有保留好幾個(gè)數(shù)據(jù)版本的情況，但有一個(gè)比較典型的案例，就是線上線下的數(shù)據(jù) diff。如果認(rèn)為線下的版本是 N，那可以認(rèn)為線上的版本就是 N-1。通過線上線下的數(shù)據(jù) diff，能將確定不會改變的數(shù)據(jù)進(jìn)行diff檢查。

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

• 一種是上下游比較，尤其是重要字段在上下游的加工過程中有沒有信息丟失；
• 一種是和除上下游外的其他數(shù)據(jù)進(jìn)行比較，比如和同一數(shù)據(jù)源下的兄弟表進(jìn)行比較，或者和不同數(shù)據(jù)源下的表進(jìn)行比較。同一數(shù)據(jù)源的例子，比如表 A 是某個(gè)一級類目的銷售數(shù)據(jù)，表 B 是該一級類目下二級類目的銷售數(shù)據(jù)，那么表 B 的數(shù)值相加=表 A 數(shù)據(jù)。不同數(shù)據(jù)源的例子，比如為了計(jì)算性能考慮，部分?jǐn)?shù)據(jù)會從行式數(shù)據(jù)庫同步到列式數(shù)據(jù)庫進(jìn)行計(jì)算，那行式數(shù)據(jù)庫中的數(shù)值應(yīng)該和列式數(shù)據(jù)庫中的數(shù)值應(yīng)該是相等的；
• 最后一種是和系統(tǒng)外的數(shù)據(jù)進(jìn)行比較，比如 BI 系統(tǒng)、其他業(yè)務(wù)后臺系統(tǒng)比較。這種方法用起來受限制較多，因?yàn)閺陌踩嵌瓤紤]，常規(guī)的 BI 系統(tǒng)或者其他業(yè)務(wù)后臺系統(tǒng)都不太可能將數(shù)據(jù)開放出來，所以該方法只作為一種可能的思路。

3）測試執(zhí)行時(shí)機(jī)

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

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

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

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

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

在不同測試時(shí)機(jī)上，雖然用到的測試 case 大部分都是可復(fù)用的，但是也會有些不同。

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

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

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

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

因此，測試時(shí)機(jī)對測試的影響可以概括成一張表。

4）CR

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

投影操作

• 字段順序、類型與表聲明一致
• 表中字段的業(yè)務(wù)含義是否是業(yè)務(wù)要求的含義
• 業(yè)務(wù)上是否要求數(shù)據(jù)去重
• 是否可能存在異常情況，如除數(shù)為0、Null、空的情況
• 是否對數(shù)據(jù)精度有明確要求。

關(guān)聯(lián)關(guān)系

• 關(guān)聯(lián)表使用 outer join 還是 join，要看數(shù)據(jù)做不做過濾
• 關(guān)聯(lián)關(guān)系 on 字句中，左右值類型是否一致
• 關(guān)聯(lián)關(guān)系如果是1：1，那么對方表的關(guān)聯(lián)鍵是否唯一。

過濾條件

• 有沒有分區(qū)過濾，是在 where 過濾還是在 on 過濾，分區(qū)用 max_pt 還是 ds
• 涉及字符串的等號注意大小寫及正確性
• 有沒有考慮到 Null、0、空等異常值的過濾
• 有沒有數(shù)據(jù)的限定來源

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

• 字段相等
• 在從 OLAP 導(dǎo)入 OLTP 之前，需不需要做預(yù)處理，比如 delete。
• 在主鍵相同時(shí)，主鍵相同的數(shù)據(jù)如何處理。

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

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

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

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

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

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

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

3）安全性評估方法：關(guān)于安全性評估，我暫時(shí)沒有經(jīng)驗(yàn)和案例，有的同學(xué)可以一起討論。

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

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

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

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

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

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

• 需求一：支持輸入數(shù)據(jù)的構(gòu)造、支持 CR。
• 需求二：支持輸出數(shù)據(jù)的功能性測試。
• 需求三：支持對其他測試方法的低耦合式接入。
• 需求四：支持測試執(zhí)行時(shí)機(jī)的靈活選擇。
• 需求五：支持測試case的快速編寫和重復(fù)利用。
• 需求六：支持對測試過程的串聯(lián)。
• 需求七：支持測試經(jīng)驗(yàn)的下沉和復(fù)用。

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

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

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

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

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

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

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

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

四、寫在最后

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

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的“做好大数据测试，我是认真的！”的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。