互聯網模式下的測試數據中心，小白也能高效構造數據

11月2日，雲效第三期Work Like Alibaba係列直播開啟，阿裏巴巴研發效能事業部雲效技術專家何衛龍，分享了《測試數據中心-互聯網模式下新型的數據準備引擎》，主要解決測試過程中數據準備困難，以及如何提升數據準備效率的思路和方法。

何衛龍：阿裏巴巴技術專家。一直從事軟件開發測試及係統架構設計工作，對測試工具平台的開發架構有一定的經驗。目前是雲效持續集成平台Amon、測試用例管理係統pivot和測試數據中心databank的技術負責人，主要負責平台的技術規劃和產品建設。在此期間，發表過技術專利多篇。

本次分享，分四個部分：

• 介紹雲效的項目開發測試流程：在此流程中，哪些階段會用到測試數據，以及數據準備的重要性。
  
• 傳統數據準備現狀：為什麼數據準備會這麼難，準備一次數據為什麼會這麼耗時，我們是否可以通過工具平台來改變現狀，讓我們的數據準備變的easy。
  
• 重點介紹測試數據中心：通過理念、產品架構以及核心功能點的介紹，讓大家了解產品以及使用方式，利用雲效平台來解決傳統數據準備的問題。
  
• 個人對未來測試數據中心的展望。
  

首先，我們看一下整個項目的流程。從創建需求開始，經過需求分析、設計，然後形成一個完整的項目，開發負責人拉取代碼分支，編寫代碼，在此過程中，開發會寫一些單元測試，來確保新開發的功能是ok的。然後會打包編譯、部署環境，開發同學自測之後，測試同學介入進行係統測試，其中包含功能、接口、UI自動化測試。係統測試以後，會進入項目集成測試，是把主幹分支合並到當前分支後部署環境測試，這個階段主要是自動化用例進行回歸，所以速度很快，如果自動化用例沒有維護好，那就另說，最後大功告成，我們就可以提測發布我們的項目了。整個流程梳理下來，我們看看哪些環節是需要用到測試數據的？ 

顯而易見，比如我們的單測集成階段，開發同學寫的單元測試，前置條件中，就會用到數據初始化，係統測試階段那就更不用說了，手工測試、接口自動化測試、UI自動化測試以及性能測試，都會使用到測試數據構造。如果測試數據準備不充分，或者有些數據很難準備，不僅會增加測試時間，導致項目延期，而且會影響測試結果的準確性，所以數據準備就變的尤為關鍵。

目前數據準備，一般都是由業務邏輯很熟悉的測試人員來操作的，新人或者剛上手個把月的測試，準備起來難度會很大，容易出錯。準備數據會用到大量的腳本，由於業務經常變動，為了適應變化，我們需要修改相應的腳本，腳本裏麵的邏輯就會變的很複雜，因此維護起來很困難。有些數據要通過手工和自動化工具聯合創建，流程長，錯誤率極高。

因此，我總結了三點傳統數據準備難的原因：

數據準備存在這麼多的問題，但是這些測試數據在整個測試過程中又十分重要，大部分數據由於項目結束，就被拋棄了，非常可惜。因此，我們能否有一個工具平台來做支撐，把數據準備的經驗和複雜的流程沉澱下來，轉化成可以操作的數據內容，讓一個普通測試，甚至開發人員都能自己構造數據。

基於數據準備存在的問題，雲效測試數據中心應運而生。雲效測試數據中心的理念可以用四個關鍵詞概括：低門檻、穩定性、透明化、靈活性。

讓一個測試小白都能自己造數據，他隻要知道自己想要什麼數據，然後在平台上麵搜索數據關鍵字，填寫必要入參，點擊執行，就可以構造出數據。

為接口、UI等自動化平台提供測試數據，減少自動化步驟，提升自動化的成功率。

以錄製UI自動化為例，我們錄製一個淘寶下訂單的功能，會包含如下步驟：賬號登錄、頁麵搜索、點擊進入、添加購物車、支付以及查詢訂單，對應的UI錄製會有20多步，鏈路比較長，出錯的幾率也比較大。

如果通過測試數據中心構造數據，可以省去像頁麵搜索、添加購物車等操作步驟，可以縮短到10步以內，隻需關注我們下單的流程。這樣自動化腳本會更加穩定而且易維護。

有了測試數據平台以後，我們製作的數據內容和執行情況都能一目了然，大家對相同功能的數據構造就可以重複使用，方便我們對數據的維護和管理。同時把之前線下的操作全都遷移到線上來，數據透明化和線上化，規範我們的整個流程。

由於數據構造需要傳入的參數是五花八門的，各種數據形式都有，沒有一種固定的方式，而且構造數據可能會在多套環境裏麵執行，因此，為了提升數據的複用性，我們支持在數據構造前選擇環境參數，方便用戶使用，同時支持用戶自定義參數。另外，對於比較複雜的數據構造，我們支持組合數據的形式，化複雜為簡單。

測試數據中心產品視圖

我們常用的測試數據中心功能有六塊：包括我的配置單、Sql助手、參數管理、我的收藏夾以及配置單列表、執行曆史。

配置單是測試數據中心構造數據的基本單元，一個配置單的創建可能需要sql助手幫我們產生sql語句，這樣解決用戶由於書寫不規範的sql導致的執行失敗問題，然後通過參數管理抽象出配置單所需要的參數，這樣一個配置單就構造好了。如果你覺得某個配置單自己會經常用到，可以在配置單列表頁麵，點擊添加收藏夾，就可以在我的收藏夾頁麵看到添加的配置單。每次配置單執行都會產生一條執行記錄，因此你可以在執行曆史頁麵查看配置單曆次的執行記錄。

配置單好了之後，我們看下是怎麼生成數據的？生成數據關鍵的一環是需要用到插件容器，每個配置單的執行都會調用插件容器，我們的插件容器，可以理解為一個agent，測試數據中心下發任務到agent，有agent來執行配置單，然後返回執行結果，我們的插件是可以分布式執行的，而且可以橫向擴展，因此支持大規模的任務執行，同時可以即插即用，非常方便。

目前測試數據中心支持的插件有：mysql、oracle、sql server，這三種是數據庫操作比較常用的。linux和windows的遠程命令執行，驅動腳本生成數據，同時我們支持使用MongoDB、redis的操作命令直接構建數據，dds是螞蟻分布式數據源服務，支持分庫分表操作，tddl是淘係的分庫分表，最後是常用的http服務。

雲效數據生成插件是可以組合使用的，靈活多變。後麵會把更多的插件集成進來，從而豐富我們的數據構造。測試數據中心的用戶分普通用戶和管理員，在權限管理裏麵進行設置，數據統計功能後麵會詳細介紹。

 

在對產品有一個大概了解後，那它是怎麼靈活支持數據準備的？

首先我介紹一下配置單的組成：由部門、產品線、配置單類型、執行插件和參數化配置5個部分組成。由於不同部門、產品線之間，所需要的測試數據不太一樣，從而對配置單進行區分，配置單類型分為單配置單和組合配置單，執行插件前麵介紹過了，參數化配置後麵會詳細介紹。

當配置單創建成功後，默認是草稿模式，創建者可能需要一定時間的調試，成功以後，可以把配置單發布出來，供用戶使用；分享的功能是為了幫助用戶快速精準的定位到自己想要的配置單。

在配置單的執行過程中，我們支持4種方式執行，定值、順序、隨機、百分比執行，這些執行的前提條件是配置單的執行次數為多次，以及你選擇的參數是個參數列表形式。

• 定值執行：是你選擇了什麼參數，就按照你選擇的參數值執行。
  
• 順序執行：是執行的時候按照參數列表的順序依次執行。比如，你的參數列表有4組參數，你執行5次，那麼它會依次執行裏麵的每一組參數，第一組參數會執行兩遍，這樣方便用戶遍曆執行。
  
• 隨機執行：是參數的選擇執行是隨機的，可以理解為一種隨機測試。
  
• 百分比執行：是可以對每一組參數進行百分比的權重設置，按權重執行。
  

最後，我們的配置單支持組合方式，可以關聯其他子配置單，然後對子配置單進行編排，編排的原則是前一個子配合單的輸出參數，可以作為後一個配置單的輸入參數使用，這種方式適用於一些比較複雜的數據構造流程。比如，需要先通過sql造數據，然後通過http，接著在緩存redis裏麵造數據，然後再通過http查詢等，或者是多個http接口的數據構造，前一個接口的輸出作為後一個接口的輸入參數，組合場景多種多樣，可以涵蓋絕大部分的數據構造場景了。

參數管理在測試數據中心也是一個比較重要的功能，主要是為了方便用戶在構造配置單的時候，進行參數化操作，而不是參數固定寫死的那種，這樣做的優勢在於用戶可以少寫配置單，把參數抽象出來，在執行前進行替換。

目前我們參數支持的形式有3類：數據源參數、組合參數、一般參數。

• 數據源參數的使用方式，是在選擇配置單插件容器的時候，可以進行數據源的選擇，我們支持的數據源有mysql、oracle、sql server、MongoDB、redis、DDS、tddl等，方便數據源選擇和維護，而且為了數據安全，我們對數據源密碼進行了加密處理。
  
• 組合參數的使用場景更加廣泛，幾乎可以適用於任一場景，設計理念在於用戶可以自定義參數，同時支持參數的批量拷貝功能，方便參數的添加和修改。目前用戶使用最多的場景是他們有多套環境，可以根據組合參數自由選擇參數執行，大大提升了配置單的複用性和維護性。
  
• 一般參數，主要是鍵值對的方式保存，他的使用場景是對同一個key進行順序執行，比如我的傳入參數名為項目id，我需要批量創造一批數據，那麼我就可以用一般參數來幫我構造。
  

測試數據中心的核心功能介紹的差不多了，平台有了，那麼平台上用戶的使用情況如何呢？接下來介紹一下數據統計功能。

數據統計我們分執行總次數、配置單數、用戶數、產品線數，4個維度進行統計。數據都是實時性的，可以按最近1個月、3個月、6個月、1年及全部數據進行查詢。每天的執行次數在頁麵上一目了然。總執行次數多少，成功和失敗多少，每天發布的配置單數有多少，以及每天使用平台的用戶，UV和PV是多少。通過分析這些數據知道運行情況，同時對每個頁麵進行打點，以及客戶回訪，方便我們對產品功能的優化，持續改進。

接下來，通過執行總次數、成功率高的配置單，以及用戶執行成功率3個維度，對top10的配置單和用戶進行排名，排名是為了激勵大家更好的使用配置單，提升配置單的成功率，從而提高我們創建配置單的能力。

比如，第一個小圖展示的是執行總數排名前10的配置單，可以看出哪些配置單是經常被使用到的，他的使用頻率及成功率等信息；第二個小圖是按照執行成功率排名前10的配置單展示的，說明那些人創建的配置單是質量比較高的；第三個小圖是執行成功率排名前10 的用戶，說明這些用戶對數據執行成功率是有追求的。（截圖來自測試數據中心功能，數據已處理。）

通過這些維度的統計，是為了讓用戶更好的使用測試數據中心，以及通過數據的顯示，讓用戶對使用過程做到心中有數。

1.數據智能化：既然我們是構造數據的，通過對數據的分析，以及用戶的喜好，智能推薦用戶想要的配置單。

2.行業化：目前測試數據中心也已經開始對外售賣，但是銀行、金融、新零售等行業，他們的數據準備過程比較複雜，比如銀行借記IC卡的預製作流程，第一頁麵錄製預製卡申請，第二調用ssh跑批命令，第三自動化錄製核心製卡任務預處理/跑批，第四手工操作製卡工具製卡，第五預製卡中心預製卡/待發卡入庫，第六櫃員領用憑證，第七身份核實，第八實時發個人卡主卡，第九存款，一共九個步驟，這是他們正常的一個數據準備過程，流程長，中間還需要線下處理，錯誤率會很高，這種行業化帶來的技術壁壘需要我們嚐試突破，建立相對標準的規範。

3.模型化：通過數據模型來消除業務上麵的差異，然後轉變成我們的插件，提供數據構造。

關注微信公眾號（ali_yunxiao），在對話框回複即可！

---

Work Like Alibaba更多直播：

11月03日15:00：玩轉《阿裏巴巴開發手冊》 P3C插件（）

11月09日20:00：智能運維——百萬級服務器自動化運維怎麼玩？（）