阿里妹導讀：大資料已然是當下的重要課題，大大小小的企業在重視大資料的同時，也漸漸重視大資料質量的問題。阿里巴巴測試開發專家小郅，今天會分享他對資料測試的系統性思考。文章內容架構清晰，內容較長，建議大家收藏閱讀哦~

關於資料測試，已有不少同學寫過這方面的文章或者開發過工具。為了系統化，我的想法是從資料質量模型入手，分析資料測試的抓手，然後找出資料測試中需要什麼樣的工具來支撐。這裡我也不會過於強調我們做的平臺，或與其他平臺作比較，而是想把平臺或者工具背後的思考過程總結和分享下。

一、資料質量模型的探尋

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）可靠&可維護性評估方法：可靠&可維護性的評估，開發參與較多，測試相對參與較少。比較典型的幾個思路是：

• 可靠性上對任務的強弱依賴進行檢查。
• 可維護性上，儘可能將體系化的開發工作整合化或者平臺化。比如，將資料的接入模式從煙囪型的模式轉為星型的集市模式，從而只負責接入資料的 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 覆蓋率、線上新增資料的監控覆蓋率等，指導後續資料測試的提升工作。

四、寫在最後

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

本文作者：小郅

原文連結

本文來自雲棲社群合作伙伴“阿里技術”，如需轉載