阿裡妹導讀：大資料已然是當下的重要課題，大大小小的企業在重視大資料的同時，也漸漸重視大資料品質的問題。阿裡巴巴測試開發專家小郅，今天會分享他對資料測試的系統性思考。文章内容架構清晰，内容較長，建議大家收藏閱讀哦~
關于資料測試，已有不少同學寫過這方面的文章或者開發過工具。為了系統化，我的想法是從資料品質模型入手，分析資料測試的抓手，然後找出資料測試中需要什麼樣的工具來支撐。這裡我也不會過于強調我們做的平台，或與其他平台作比較，而是想把平台或者工具背後的思考過程總結和分享下。
一、資料品質模型的探尋
1.1. ISO 9126在資料品質上的移植
在講到資料測試前，需要先想一個問題，怎麼樣系統化地闡述資料品質？
我覺得系統化闡述的一個思路就是尋找當下有沒有适合資料品質的品質模型。以傳統的品質模型為例，ISO 9126是一種典型的軟體品質模型，無論是開發還是測試，無論是各端品質還是服務品質，品質上的大方向不會跳出9126的模型。作為網際網路行業，雖然現階段9126中的二級特性不可能完全落地，但作為一個指導性的品質模型，它會確定品質不會有方向性的大纰漏。那資料品質有沒有類似9126的模型可以參考呢？
從國外看，已知的 ISO 8000是現在資料品質方面的新興标準，但該标準一是太重，二是不免費提供，三是國内對該标準的綜述也少的可憐，是以并沒有太多細節可供參考。從國内來看，大家都會做到一些總結和落地，包括集團内部的ATA文章也不少，有共性也有不同，但系統性的闡述相對少一些。我的一個想法是，既然沒有現成的，那是否可以嘗試将9126移植到資料品質？
9126的一級特性可以分為以下幾個：功能性、易用性、可靠性、效率、維護性、可移植性。那這幾個大項對應到資料品質裡，會是什麼樣的呢？
1）功能性：軟體提供了使用者所需要的功能。二級特性包括：适合性、準确性、互用性、安全性。對資料而言，個人覺得最重要的應該屬于準确性和安全性。
a.對于準确率，如果一句話概括就是，首先資料要有，其次資料要全，最後資料要準。對應的，就可以看到該大項下對應的小項：
- 資料要有 -> 資料及時性：資料要按約定時間産出。
- 資料要全 -> 資料完整性：資料不能少、不能缺。當然，也不能多。
- 資料要準 -> 資料準确性：數值要準确。
這幾個二級特性，可能很多同學的文章中都寫過，也讨論過。這裡隻是從資料品質整體系統性上再将其闡述一遍。需要說明的一點是，很多文章中也寫到了資料一緻性這個特性。資料一緻性這個概念很廣，比如關系資料庫中的外鍵一緻性、CAP 理論中的強弱一緻性。個人認為，資料不一緻最終影響的還是資料的完整或者準确。如果業務上認為不一緻性可以接受，那也不是問題。是以我更傾向于将資料一緻性作為一種根因，而并不是品質模型的一個子項。
b.對于安全性，尤其是資料安全，命題也很大，這裡不再贅述。但需要提的一點是，資料安全涉及到隐私或者差分攻擊的預防，也可能是由業務同學考慮的範疇，是以在資料品質模型中不能忽視。
2）易用性：是指在指定條件下使用時，軟體産品被了解、學習、使用和吸引使用者的能力。對于資料來說，我認為資料的易用可以分為兩方面：是否被了解，是否被需要。它更多的是和日常溝通、産品需求及規劃相關。
- 是否被了解，意思是目前我們對資料的定義是否是行業認可的，是否存在團隊與團隊之間、使用者與開發者之間了解的不一緻。
- 是否被需要，意思是目前我們提供的資料，是否真的能夠滿足使用者需要，資料的真正效果有沒有達到。比如，我們給使用者提供的是它自己品牌的資料，但使用者可能更需要的是行業下的資料來做進一步的市場規劃。
3）可靠性：在指定條件下使用時，軟體産品維持規定的性能水準的能力。比如上遊資料無法定時給出，依賴關系的強弱配置不正确，可能影響的就是資料無法定時産出。可靠性是一種根因，最終影響的還是功能性。
4）效率：是指在規定條件下，相對于所用資源的數量，軟體産品是否在規定時間内可提供适當的性能的能力。比如計算傾斜或者計算資源不足導緻資料産不出來。效率也是一種根因，最終影響的還是功能性。
5）可維護性：是指是在修改或者新增需求時，目前的開發架構是否足夠靈活的支援，是開發階段主要考慮的。比如在數倉開發中，當新上遊到來時，如果從下到上全部采用煙囪式開發，那對新增的需求必定是不友好的。如果改為 Hub 或者集市模式，可能隻需要開發接入資料的 ETL 代碼，剩下的完全可以複用，就是提升可維護性的一種手段。
6）可移植性：是指軟體産品從一種環境遷移到另一種環境的能力，也是開發階段主要考慮的。服務或者網站的可移植性大家了解比較多，資料的可移植性是指什麼？我個人認為可移植性強調的更多是跨技術平台的移植，而不是子產品間的資料複用。在資料上可能就是資料直接從一個計算平台遷移到另一個計算平台，或者 SQL 代碼從一個計算平台遷移到另一個計算平台。在可移植性方面，我還沒有遇到導緻品質問題的有說服力的案例，如果大家有相關的例子可以溝通。
綜上，如果采用9126的思路，得到的資料品質模型的腦圖如下。
1.2. 對移植模型的優化
但是移植過來之後就完事兒了嗎？其實細想一下，裡面還是有很多的問題，讓它不是那麼好用。比較典型的問題就是：模型不正交。通俗來講就是感覺幾個特性之間有不同，但也有關系。兩個例子：
1）比如無論是可靠性、效率還是可維護性，最終影響的都是功能性，或者可以說是導緻功能性問題的部分根因。可以說，功能性是使用者最終看到的品質特性，而可靠性、效率、可維護性卻是研發看到的品質特性。
2）有些特性又有相同點，又有不同點。比如可靠性和效率，相同點在于，雖然問題産生原因不同，但最終都會導緻資料不産出。在不産出的情況下，臨時解法可能都會一樣，比如切前一天的資料。不同點在于，問題的根本解法有很大的不同，可靠性還是要靠強弱依賴關系檢查、架構優化等手段解決，而效率問題要靠資源擴容等手段解決。
怎麼樣能讓模型更好用呢？我在上面的基礎上進行了簡單的修改。
首先将品質特性分為使用者可見的品質特性和研發可見的品質特性。因為導緻使用者可見的品質特性出現問題的原因，很大程度上取決于研發可見的品質特性。
研發可見的品質特性又分為治标特性和治本特性。所謂治标特性是指兜底，例如，如果資料産出出了問題，那我們有沒有快速的兜底恢複方案，是應用降級、限流還是切換舊資料？所謂治本特性是指出問題的根本原因，包括可靠&可維護性、效率、安全。這裡把可靠和可維護性合并，是覺得兩個聯系緊密，都和研發的架構有關。把安全性從功能性移到這裡，是覺得安全性對于使用者來說可見性沒有那麼強，但一旦可見，後果非常嚴重，是需要在研發階段重點考慮的。通過可見性範圍将品質模型進行重構後，在模型正交上會顯得比之前相對好些。
二、資料測試方法論探尋
2.1．資料品質模型應用于研發過程
既然資料品質模型有了雛形，接下來需要思考的就是品質模型在研發過程中的落地，也就是由誰在什麼時間做什麼事情？首先，我們先把品質模型平鋪到研發周期中去，x 軸為研發周期，y 軸為品質模型，接下來要做的就是填空題，即每個研發階段在某個品質特性上該做什麼事情，這樣就得到了一個二維關系，如下圖所示。裡面的内容其實是我們根據自己産品線特性以及品質活動經驗總結出來的，但總體看下來，大緻和傳統品質是相似的。
填完内容之後，至于由誰來做就一目了然了。易用性的問題涉及到商業調研、使用者需求和産品規劃，更多的是 PD 主導的事情。其他幾個特性，也就是藍框中的特性都是開發測試階段需要考慮的特性。
2.2．資料品質模型中的測試抓手
那測試的抓手主要在哪兒？很明顯，如果從代表使用者的角度，那最直接的切入點就是功能性這個特性。一方面它是使用者可見的特性，測試從使用者的角度發現問題；另一方面所有研發可見的特性導緻的品質問題最終都會落到功能性上，可以用功能性做問題發現的最後兜底。
除了功能性，還有需要測試重點考慮的特性麼？我個人的經驗是，容災性是需要考慮的。因為作為研發修複問題的兜底方法，容災性的有無或好壞會嚴重影響到功能性。這也是我把他從品質模型中獨立出來的一個考慮。測試在容災的預案制定上應該起到一定的 review 作用。
至于其他幾個特性，效率也好，可靠&可維護性，安全性也好，要根據項目性質是日常還是大促，是功能新增還是功能優化，甚至測試團隊是建立還是有所積累有關。對于日常項目、功能新增、團隊建立等，在功能性&容災上的投入是最大的，而功能性測試又是兩者中最大的。随着功能性上的完善，會逐漸投入到效率、可靠&可維護性上。而在大促、功能優化、團隊積累時，在容災性、效率、可靠性&可維護性上的投入比功能性要更重。是以我認為資料測試公式應該是：
資料測試 = 基礎測試（功能性 + 容災性） + 選擇評估（效率 ||可靠&可維護性 || 安全性）
鑒于功能性測試在整個資料測試中的主體位置，2.3會詳細介紹功能性測試的方法。其他幾個特性的測試在2.4、2.5中簡單描述。
2.3．資料測試中的功能性測試方法
對于傳統功能測試或者接口測試來說，就是通過構造輸入，檢查輸出。對于資料測試來說也是如此，隻不過最終測試的對象由界面、接口傳回換成了資料。如果将資料測試活動分解來看，比較重要的活動有三個：輸入資料構造、輸出資料的測試方法、測試執行時機。接下來會分别對這三部分的測試方法進行描述。最後，CR 作為一種典型而又有效的檢查資料準确性方法，也會做簡單介紹。
1）輸入資料的構造
并不是所有項目都需要輸入資料的構造，像我所在的産品線“資料銀行”目前并不是通過輸入資料構造的方式進行測試的。什麼樣的産品線會适合輸入資料的構造呢？
我的觀點是，如果對線上異常資料十分敏感的業務，是需要做輸入資料的構造的。對輸入資料進行構造，實際上并不容易，首先需要測試根據要求生成一批資料，然後使用開發提供的業務代碼運作這批資料，最終産生輸出資料。如果業務代碼隻依賴一張表還好，但如果依賴多張表的話，那需要考慮到多張表的輸入資料的構造。
如果對線上異常資料并沒有那麼敏感的業務，或者上遊資料品質相對高的業務，其實不一定要在測試階段生成各種輸入的異常資料。開發可以提測某份快照資料來重點驗證資料處理邏輯的正确性，而因為對輸入的異常資料考慮欠佳導緻輸出資料異常的情況，還是可以采用線上持續監控的方式進行。這一點後面也會說。
2）輸出資料的測試方法
在輸出資料的測試方法上，根據功能性下的三個二級特性：及時性、完整性、準确性，對應有不同的測試方法。下面的腦圖是一個方法彙總。
及時性：相對來說測試方法較為簡單，需要做到的就是有沒有在規定的時間内産出資料，可以通過檢查全表條數或者檢查分區條數來判斷。
完整性：完整性重點評估的兩點是：資料不多，資料不少。
- 不多：一般是檢查全表資料、重要枚舉值資料有沒有重複或者資料主鍵是否唯一。
- 不少：一般是對全表資料或業務相關的重要字段（比如日期、枚舉值、品牌、類目等）進行檢查。如果資料規模是可以被知曉的，比如知道表中品牌有x條，那每次檢查x條即可。如果資料規模本身變動較大導緻不可被知曉（比如表中的品牌數會開通或關閉），常用的方法就是通過對比曆史資料，看整體波動是否正常。
準确性：準确性相比來說，是比較不容易測試的一種特性，為什麼？因為很難去找一個理性的參照物，來說明資料有多準，大部分都存在于認知中。正是是以，準确性測試也是在資料品質模型體系化過程中思維相對發散的一個例子。于是我在發散的思維中從自身、時間、空間的次元試圖總結下準确性的測試方法。雖然也總結出了一些方向性思路，但是每種思路還是要依賴于個人的發散性思維以及對業務的了解才能最終将其用好。
a.自身檢查：是指在不和其他資料比較的前提下，用自身資料來檢查準确的情況，屬于最基本的一種檢查。自身檢查的測試方法隻能将資料正确的機率提高，但受限于資訊量，提高程度有限。有三種比較典型的方法。
- 第一種方法是該值是否在正常範圍内，舉個例子，比如人數占比，理論上都會在[0,1]之間，屬于對值進行最基本的檢查；
- 第二種方法是該值是否在業務範圍内，一般是對該值業務屬性了解後的一個判斷，比如如果我測試的是某産品搜尋人數，如果觸發管道唯一的話，理論上該産品的搜尋人數>=該産品的購買人數，這種就是在了解值背後的業務之後的判斷；
- 第三種方法是該值的分布，如果對某個值的業務特性有明确的了解，通過觀察值分布也可以測試其準确性。比如如果測試“購買人數中的會員占比”這個值，可以觀察其在資料中分布，認知該比例應該在0.3左右。 如果測試完分布，結果發現80%大緻在0.2-0.4之間，那就符合認知。如果結果發現80%在0.8-0.9之間，那就不符合認知。
b.時間次元上的比較：如果把資料放到時間次元上比較，可以繼續提升資料準确的機率。有兩種方法：一種方法是在同一資料批次内觀察同一個資料不同時間的情況，一種方法是在不同資料批次内觀察同一資料的情況。
- 同一批次：比如開發線下提測了一批資料，這就是同一資料批次，在該批次下，可以比較 ds=20180901、ds=20180902、ds=20180903等不同日期的資料的波動。
- 不同批次：這種相對來說比較難找，因為對于資料來說，很少有保留好幾個資料版本的情況，但有一個比較典型的案例，就是線上線下的資料 diff。如果認為線下的版本是 N，那可以認為線上的版本就是 N-1。通過線上線下的資料 diff，能将确定不會改變的資料進行diff檢查。
c.空間次元上的比較：空間次元上的比較，是指固定了時間次元，将目前數值和其他資料進行比較，進一步輔助正确性。也有三種基本思路：
- 一種是上下遊比較，尤其是重要字段在上下遊的加工過程中有沒有資訊丢失；
- 一種是和除上下遊外的其他資料進行比較，比如和同一資料源下的兄弟表進行比較，或者和不同資料源下的表進行比較。同一資料源的例子，比如表 A 是某個一級類目的銷售資料，表 B 是該一級類目下二級類目的銷售資料，那麼表 B 的數值相加=表 A 資料。不同資料源的例子，比如為了計算性能考慮，部分資料會從行式資料庫同步到列式資料庫進行計算，那行式資料庫中的數值應該和列式資料庫中的數值應該是相等的；
- 最後一種是和系統外的資料進行比較，比如 BI 系統、其他業務背景系統比較。這種方法用起來受限制較多，因為從安全角度考慮，正常的 BI 系統或者其他業務背景系統都不太可能将資料開放出來，是以該方法隻作為一種可能的思路。
3）測試執行時機
關于測試執行時機方面，和傳統測試相同，有如下幾個測試時機：自測時、提測後、線上資料修改、線上資料新增。
無論是自測還是提測，關注的都是線下，而線下資料測試是有一定局限性的。如果不采用輸入資料構造的方法，那開發一般隻提測一部分資料，比如某天的資料，但也正是由于提測資料的片面性，即使提測資料沒問題也不能代表資料處理規則就完全沒有問題；如果采用輸入資料構造的方法，雖然能線上下發現更多的因為輸入資料異常導緻的輸出資料異常，但因為線上生産環境本身穩定性等治本問題，仍然不能代表後續線上就沒有問題。
正是因為線下資料的局限性，是以當線上資料修改或者線上資料新增時，仍需要持續進行測試。線上測試 case 有可能完全使用線下的 case，也有可能對線下 case 進行簡單修改後使用。
将測試時機獨立出來讨論的一個好處是，如果将一系列測試 case 組成任務的話，無論是線下還是線上，隻要有合适的觸發條件，就可以用合适的觸發方法運作這些測試case。觸發方法包括條件觸發和定時觸發。一般來講，線下使用的是條件觸發，即當開發完成需要自測或者提測後測試需要測試時，通過 API 或者界面觸發執行。
而線上則要區分使用場景：對于線上資料修改來說，這種操作并不是正常操作，是當需求出現問題或者修複 Bug 時才會出現的操作，是以一般情況下也需要用條件觸發。對于線上資料新增來說，一般是每天定期産出新資料。這種既可以采用條件觸發（即生成新資料後觸發測試），也可以采用定時觸發（即定時輪詢是否有新資料生成并測試）。條件觸發的好處是類似于持續內建中，持續測試的概念，隻要涉及資料改動就要觸發測試，但它并不能很好的關注及時性；而定時觸發的好處是可以及時關注及時性，但對于及時性要求不是很高的資料（比如有時候8點産出，有時候10點産出），那定時觸發就會導緻很多的誤報。
在不同測試時機上，雖然用到的測試 case 大部分都是可複用的，但是也會有些不同。
在自測時，主要是開發團隊進行測試。測試 case 更關注資料基礎品質的測試，比如完整性和準确性中的自身檢查。這部分 case 不需要太多發散性思維。
在提測後，主要是測試團隊進行測試。除了資料的基礎品質測試外，測試 case 更關注“快照”，即準确性中的空間次元和時間次元的不同批次的對比上，盡可能通過輔證的方式發現資料準确性中的問題。而在同一批次的時間次元方面，往往開發不會提測很多時間點的資料，是以一般情況來說，輔證難度會更大。
線上上資料修改時，基本上可以複用提測後使用的 case。
線上上資料新增時，除了資料的基礎品質測試外，絕大部分可以複用提測後使用的 case，但會弱化一部分具有探索性思路的 case 或者是運作時間過長的 case。比如測試值的分布 case 就不适合每天新增時測試，因為每天的資料分布可能有所不同，并不是穩态，加入這種 case 會造成誤報率的提升。再比如測試資料量過大的 case，尤其是上下遊對比測試，往往下遊資料量會很大，每天定時測試一方面會消耗太多時間和資源，另一方面也沒有必要，因為這種問題産生的原因往往是資料處理邏輯的問題，一般線下一次測試就可以發現。線上測試會添加時間次元中，同一資料批次中不同時間的波動性的對比。
是以，測試時機對測試的影響可以概括成一張表。
4）CR
雖然在測試方法一節中介紹了通過輸出資料發現問題的方法，但發現問題最直接有效的方法還是 CR，尤其是對類 SQL 資料庫的準确性問題來說。下面是 SQL CR 中經常用到的一些 CR 規則。
投影操作
- 字段順序、類型與表聲明一緻
- 表中字段的業務含義是否是業務要求的含義
- 業務上是否要求資料去重
- 是否可能存在異常情況，如除數為0、Null、空的情況
- 是否對資料精度有明确要求。
關聯關系
- 關聯表使用 outer join 還是 join，要看資料做不做過濾
- 關聯關系 on 字句中，左右值類型是否一緻
- 關聯關系如果是1：1，那麼對方表的關聯鍵是否唯一。
過濾條件
- 有沒有分區過濾，是在 where 過濾還是在 on 過濾，分區用 max_pt 還是 ds
- 涉及字元串的等号注意大小寫及正确性
- 有沒有考慮到 Null、0、空等異常值的過濾
- 有沒有資料的限定來源
資料同步任務測試
- 字段相等
- 在從 OLAP 導入 OLTP 之前，需不需要做預處理，比如 delete。
- 在主鍵相同時，主鍵相同的資料如何處理。
2.4. 資料測試中的容災性評估方法
容災性評估主要是當資料未産出或者資料出現大面積問題時，如何快速止損。比較典型的做法是做可用資料的快速切換，比如快速切換成前一天的資料或者上一個版本的資料。這種情況一般需要服務端配合來完成。
2.5. 資料測試中的其他特性的評估方法
剩下一些特性，開發同學可能會有更加詳細的文章闡述，這裡隻是從測試角度簡單描述。
1）效率評估方法：效率評估主要是目前資料的計算資源是否滿足目前産品的時間要求。需要分三種情況：一是使用者直接觸發的計算請求是否過大；二是使用者資料是否過多，進而造成計算量過大的情況；三是程式本身效率是否低下，性能過低，導緻資源消耗過大。第一種情況往往通過構造請求流量，進行壓測評估。後兩種一般會通過大盤的方式，找出哪張表運作時間最長，最影響效率，來逐漸進行優化。
2）可靠&可維護性評估方法：可靠&可維護性的評估，開發參與較多，測試相對參與較少。比較典型的幾個思路是：
- 可靠性上對任務的強弱依賴進行檢查。
- 可維護性上，盡可能将體系化的開發工作內建化或者平台化。比如，将資料的Access模式從煙囪型的模式轉為星型的集市模式，進而隻負責接入資料的 ETL，盡可能減少開發工作就是內建化的一種思路。平台化的思路就是将流程化的開發工作，通過平台的方式進行配置來完成，一方面提高開發效率，另一方面減少出錯成本，提升開發品質。
3）安全性評估方法：關于安全性評估，我暫時沒有經驗和案例，有的同學可以一起讨論。
三、依托資料測試方法論的測試工具建設
二中已經闡述了資料測試方法論，那在這樣一種方法論下，需要什麼樣的資料測試工具呢？接下來主要介紹下以類 SQL 資料庫為基礎的資料測試工具規劃思路。
從測試工具的功能上看，資料的功能性特性測試應該是最重的一個環節，它需要涵蓋輸入資料的構造、輸出資料的測試方法、測試執行時機的支援、CR 等功能。而容災、效率、可靠&可維護性、安全性等特性，相對測試人員來說，開發在這方面積累的更深，是以測試工具可以做到支援對其他特性的測試擴充，加入到工具中來。
從測試工具的效率上看，資料測試天生就是有自動化屬性的，因為測試人員不可能肉眼一條條對資料進行 check。是以對資料測試工具的效率讨論，理論上不集中在是否要自動化，而是在對資料測試方法流程的改進上。資料測試方法流程包括測試case的編寫和積累、測試 case 的無監督執行、測試結果的自動分析。将整個的資料測試工作通過一套工具進行串聯，同時也将已有的 case 進行快速複用，對資料測試效率的提高是很有幫助的。
從整個資料測試的發展來看，資料測試比傳統軟體測試所不同的是，它的模式性會更強，模式性強的原因是因為本身資料的開發使用語言都是相對模式化的，開發的模式化也意味着測試的模式化。對于一個有豐富經驗的資料測試人員來說，會更容易将經驗進行下沉，傳遞給其他測試人員，甚至開發人員。是以我的一個預測是，資料測試雖然發展比傳統軟體晚，但是在強模式性的背景下，它做到0測試人員介入，是相對容易實作的。是以在這個背景下，測試工具應該具備将經驗傳承進行彙總并傳承的能力，從剛開始的隻解放測試人員，逐漸發展到到解放研發流程。
是以總結下資料測試工具的需求有這麼幾個：
- 需求一：支援輸入資料的構造、支援 CR。
- 需求二：支援輸出資料的功能性測試。
- 需求三：支援對其他測試方法的低耦合式接入。
- 需求四：支援測試執行時機的靈活選擇。
- 需求五：支援測試case的快速編寫和重複利用。
- 需求六：支援對測試過程的串聯。
- 需求七：支援測試經驗的下沉和複用。
根據上述需求，一個典型的資料測試架構應該包含以下幾個部分。
測試時機觸發能力：支援需求四。資料測試架構應該包含API層，無論是條件觸發還是定時觸發，都會調用 API 完成任務的觸發。條件觸發根據資料庫不同，可以看是否可以和資料庫本身的消息系統做對接，即資料發生變動後，通知消息系統，消息系統調用API觸發整個測試任務；定時觸發可以采用 crontab 封裝一個 job，在 job 中調用 api 觸發。
測試過程串聯能力：支援需求六。測試過程能力是将整個的測試活動進行管理的能力。典型的測試活動管理能力包括以下幾部分：任務生成、任務拆分、任務執行、結果分析。當建立測試活動時，調用任務生成子產品去生成測試任務，支援對不同特性的測試。任務拆分的作用是在任務執行的時候，對異構任務進行拆分或者對同構任務進行并行化拆分。任務執行的作用是将任務實際送出到對應的資料源進行計算。結果分析的作用是對資料源的結果進行回流，并對結果進行分析。
測試經驗複用&積累能力：支援需求七。需求七理論上不僅僅是隻通過 AI 的方式進行測試經驗的推薦，而是也想把測試人員已有經驗進行總結下沉的過程。
功能性測試能力：支援需求二、需求五。如何支援測試 case 的快速編寫？我們的思路是當使用者通過功能測試方法進行測試的時候，會調用一個個的名額。名額實際上可以了解成一個函數，它是對功能性測試中一些典型 case 的抽象。當使用者調用某名額時，給出名額參數，系統就可以自動翻譯成類 sql。這樣不僅減少了使用者寫 sql 的時間，又能很快速地将 case 和作用對應起來，同時在進行測試經驗積累和複用的時候，就可以通過名額的概念進行。為什麼翻譯成類 sql 而不是真正的 sql 執行個體？是考慮到适配的問題。如何能在 ODPS 上和 ADS 上都能執行呢？通過将類 SQL 通過翻譯引擎轉化成實際的 SQL 就可以做到。
其他特性測試擴充能力：支援需求三。看圖可以知道，這部分采用元件擴充能力是最好的。為什麼？之前也說過，在容災、效率等特性的評估上，集團裡已經有很多很好的工具，同時開發在這方面也有很多積累，沒有必要另起爐竈去做這方面的事情。唯一需要的就是将其他特性的測試容納進任務中，和功能測試一起，作為一套完成的測試解決方案，友善後續追溯、沉澱和複用。
輸入資料構造&CR 能力：支援需求一。CR 能力方面，如果有類似 Intellij 上，自動提示或者警醒開發同學可能 SQL 在哪方面有問題，這種模式實際上是最好的。不過比較困難的是，SQL 可能能沉澱出來的通用代碼檢查規則會比較少，大部分還是需要根據對業務的了解來進行，是以如果測試工具能将業務上對 SQL review 的經驗儲存下來，并提示給使用者，在 CR 上也能起到一定的作用。在輸入資料構造方面，有其他同學在做類似的工具，我本身因為産品線的關系暫時沒有做過相關工作，是以在此隻是列舉出來，大家有興趣可以檢視相關文章。
品質大盤能力：品質大盤并不是推導出的需求。但是在以結果導向為主的今天，我們做的事情到底現在是什麼樣的情況，沒有品質大盤資料的支援，往往無法知道。是以品質大盤需要收集測試活動中的資料，包括任務執行成功率、Case 覆寫率、線上新增資料的監控覆寫率等，指導後續資料測試的提升工作。
四、寫在最後
寫這篇長文的過程中，重要的是通過對個人思路進行了一次系統梳理，将現在乃至之前的工作經驗都容納在了該方法中。目前已經完成了部分模型實踐和平台開發工作，希望接下來還是繼續深入落地資料測試的相關事項，将目前我們做的資料測試工具按思路完善起來。也期待與業界同仁共同交流，一起進步。
原文釋出時間為：2019-07-30
本文作者：小郅
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。