「作好大數據測試，我是認真的！」

時間 2019-12-29

標籤作好數據測試認真简体版

原文原文鏈接

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

關於數據測試，已有很多同窗寫過這方面的文章或者開發過工具。爲了系統化，個人想法是從數據質量模型入手，分析數據測試的抓手，而後找出數據測試中須要什麼樣的工具來支撐。這裏我也不會過於強調咱們作的平臺，或與其餘平臺做比較，而是想把平臺或者工具背後的思考過程總結和分享下。數據庫

1、數據質量模型的探尋

1.1. ISO 9126在數據質量上的移植api

在講到數據測試前，須要先想一個問題，怎麼樣系統化地闡述數據質量？安全

我以爲系統化闡述的一個思路就是尋找當下有沒有適合數據質量的質量模型。以傳統的質量模型爲例，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、數據測試方法論探尋

2.1．數據質量模型應用於研發過程

既然數據質量模型有了雛形，接下來須要思考的就是質量模型在研發過程當中的落地，也就是由誰在什麼時間作什麼事情？首先，咱們先把質量模型平鋪到研發週期中去，x 軸爲研發週期，y 軸爲質量模型，接下來要作的就是填空題，即每一個研發階段在某個質量特性上該作什麼事情，這樣就獲得了一個二維關係，以下圖所示。裏面的內容實際上是咱們根據本身產品線特性以及質量活動經驗總結出來的，但整體看下來，大體和傳統質量是類似的。

填完內容以後，至於由誰來作就一目瞭然了。易用性的問題涉及到商業調研、用戶需求和產品規劃，更多的是 PD 主導的事情。其餘幾個特性，也就是藍框中的特性都是開發測試階段須要考慮的特性。

2.2．數據質量模型中的測試抓手

那測試的抓手主要在哪兒？很明顯，若是從表明用戶的角度，那最直接的切入點就是功能性這個特性。一方面它是用戶可見的特性，測試從用戶的角度發現問題；另外一方面全部研發可見的特性致使的質量問題最終都會落到功能性上，能夠用功能性作問題發現的最後兜底。

除了功能性，還有須要測試重點考慮的特性麼？我我的的經驗是，容災性是須要考慮的。由於做爲研發修復問題的兜底方法，容災性的有無或好壞會嚴重影響到功能性。這也是我把他從質量模型中獨立出來的一個考慮。測試在容災的預案制定上應該起到必定的 review 做用。

至於其餘幾個特性，效率也好，可靠&可維護性，安全性也好，要根據項目性質是平常仍是大促，是功能新增仍是功能優化，甚至測試團隊是新建仍是有所積累有關。對於平常項目、功能新增、團隊新建等，在功能性&容災上的投入是最大的，而功能性測試又是二者中最大的。隨着功能性上的完善，會逐漸投入到效率、可靠&可維護性上。而在大促、功能優化、團隊積累時，在容災性、效率、可靠性&可維護性上的投入比功能性要更重。因此我認爲數據測試公式應該是：

數據測試 = 基礎測試（功能性 + 容災性） + 選擇評估（效率 ||可靠&可維護性 || 安全性）

鑑於功能性測試在整個數據測試中的主體位置，2.3會詳細介紹功能性測試的方法。其餘幾個特性的測試在2.四、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=2018090一、ds=2018090二、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）安全性評估方法：關於安全性評估，我暫時沒有經驗和案例，有的同窗能夠一塊兒討論。

3、依託數據測試方法論的測試工具建設

二中已經闡述了數據測試方法論，那在這樣一種方法論下，須要什麼樣的數據測試工具呢？接下來主要介紹下以類 SQL 數據庫爲基礎的數據測試工具規劃思路。

從測試工具的功能上看，數據的功能性特性測試應該是最重的一個環節，它須要涵蓋輸入數據的構造、輸出數據的測試方法、測試執行時機的支持、CR 等功能。而容災、效率、可靠&可維護性、安全性等特性，相對測試人員來講，開發在這方面積累的更深，因此測試工具能夠作到支持對其餘特性的測試擴展，加入到工具中來。

從測試工具的效率上看，數據測試天生就是有自動化屬性的，由於測試人員不可能肉眼一條條對數據進行 check。因此對數據測試工具的效率討論，理論上不集中在是否要自動化，而是在對數據測試方法流程的改進上。數據測試方法流程包括測試case的編寫和積累、測試 case 的無監督執行、測試結果的自動分析。將整個的數據測試工做經過一套工具進行串聯，同時也將已有的 case 進行快速複用，對數據測試效率的提升是頗有幫助的。

從整個數據測試的發展來看，數據測試比傳統軟件測試所不一樣的是，它的模式性會更強，模式性強的緣由是由於自己數據的開發使用語言都是相對模式化的，開發的模式化也意味着測試的模式化。對於一個有豐富經驗的數據測試人員來講，會更容易將經驗進行下沉，傳遞給其餘測試人員，甚至開發人員。因此個人一個預測是，數據測試雖然發展比傳統軟件晚，可是在強模式性的背景下，它作到0測試人員介入，是相對容易實現的。因此在這個背景下，測試工具應該具有將經驗傳承進行彙總並傳承的能力，從剛開始的只解放測試人員，逐步發展到到解放研發流程。

因此總結下數據測試工具的需求有這麼幾個：

需求一：支持輸入數據的構造、支持 CR。
需求二：支持輸出數據的功能性測試。
需求三：支持對其餘測試方法的低耦合式接入。
需求四：支持測試執行時機的靈活選擇。
需求五：支持測試case的快速編寫和重複利用。
需求六：支持對測試過程的串聯。
需求七：支持測試經驗的下沉和複用。

根據上述需求，一個典型的數據測試框架應該包含如下幾個部分。

測試時機觸發能力：支持需求四。數據測試框架應該包含API層，不管是條件觸發仍是定時觸發，都會調用 API 完成任務的觸發。條件觸發根據數據庫不一樣，能夠看是否能夠和數據庫自己的消息系統作對接，即數據發生變更後，通知消息系統，消息系統調用API觸發整個測試任務；定時觸發能夠採用 crontab 封裝一個 job，在 job 中調用 api 觸發。

測試過程串聯能力：支持需求六。測試過程能力是將整個的測試活動進行管理的能力。典型的測試活動管理能力包括如下幾部分：任務生成、任務拆分、任務執行、結果分析。當新建測試活動時，調用任務生成模塊去生成測試任務，支持對不一樣特性的測試。任務拆分的做用是在任務執行的時候，對異構任務進行拆分或者對同構任務進行並行化拆分。任務執行的做用是將任務實際提交到對應的數據源進行計算。結果分析的做用是對數據源的結果進行迴流，並對結果進行分析。

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

功能性測試能力：支持需求2、需求五。如何支持測試 case 的快速編寫？咱們的思路是當用戶經過功能測試方法進行測試的時候，會調用一個個的指標。指標實際上能夠理解成一個函數，它是對功能性測試中一些典型 case 的抽象。當用戶調用某指標時，給出指標參數，系統就能夠自動翻譯成類 sql。這樣不只減小了用戶寫 sql 的時間，又能很快速地將 case 和做用對應起來，同時在進行測試經驗積累和複用的時候，就能夠經過指標的概念進行。爲何翻譯成類 sql 而不是真正的 sql 實例？是考慮到適配的問題。如何能在 ODPS 上和 ADS 上都能執行呢？經過將類 SQL 經過翻譯引擎轉化成實際的 SQL 就能夠作到。

其餘特性測試擴展能力：支持需求三。看圖能夠知道，這部分採用組件擴展能力是最好的。爲何？以前也說過，在容災、效率等特性的評估上，集團裏已經有不少很好的工具，同時開發在這方面也有不少積累，沒有必要另起爐竈去作這方面的事情。惟一須要的就是將其餘特性的測試容納進任務中，和功能測試一塊兒，做爲一套完成的測試解決方案，方便後續追溯、沉澱和複用。

輸入數據構造&CR 能力：支持需求一。CR 能力方面，若是有相似 Intellij 上，自動提示或者警醒開發同窗可能 SQL 在哪方面有問題，這種模式其實是最好的。不過比較困難的是，SQL 可能能沉澱出來的通用代碼檢查規則會比較少，大部分仍是須要根據對業務的理解來進行，因此若是測試工具能將業務上對 SQL review 的經驗保存下來，並提示給用戶，在 CR 上也能起到必定的做用。在輸入數據構造方面，有其餘同窗在作相似的工具，我自己由於產品線的關係暫時沒有作過相關工做，因此在此只是列舉出來，你們有興趣能夠查看相關文章。

質量大盤能力：質量大盤並非推導出的需求。可是在以結果導向爲主的今天，咱們作的事情到底如今是什麼樣的狀況，沒有質量大盤數據的支持，每每沒法知道。因此質量大盤須要收集測試活動中的數據，包括任務執行成功率、Case 覆蓋率、線上新增數據的監控覆蓋率等，指導後續數據測試的提高工做。