這一年多來，阿里Blink測試體系如何從0走向成熟？

摘要： 引言 Apache Flink是面向數據流處理和批處理的分佈式開源計算框架，2016年阿里巴巴引入Flink框架，改造爲Blink。2017年，阿里整合了全部流計算產品，決定以Blink引擎爲基礎，打造一款全球領先的實時計算引擎。

引言

Apache Flink是面向數據流處理和批處理的分佈式開源計算框架，2016年阿里巴巴引入Flink框架，改造爲Blink。2017年，阿里整合了全部流計算產品，決定以Blink引擎爲基礎，打造一款全球領先的實時計算引擎。當年雙11，Blink支持了二十多個事業部／羣，同時運行了上千個實時計算job，每秒處理的日誌數峯值達到驚人的4.7億。所以Blink的可靠性和穩定性保障變得極其重要，搜索事業部的質量團隊爲此專門成立了Blink測試小組，經過一年多的努力，創建了從代碼質量到持續集成再到預發測試的全面的測試體系，幫助Blink的質量取得大幅提升。

Blink測試平臺介紹

Blink測試團隊爲Blink質量量身打造Blink測試平臺，內容以下圖所示：

Blink測試平臺包含了三個測試階段： 代碼質量校驗階段，主要進行靜態代碼掃描、單元測試和基於minicluster的測試；集成測試階段，主要是進行功能測試、性能測試和帶有破壞性的穩定性測試；而預發測試階段，主要是利用用戶的job進行仿真測試，並在版本發佈以前作最後的版本兼容性測試。

平臺選取部分測試集合歸入到precommit的驗證中，可儘早發現代碼中問題，而大規模的功能、性能、穩定性測試，一般做爲dailybuild的集合。另外，Blink測試平臺創建了較爲完善的質量度量體系，除去對代碼覆蓋率的統計及變化的分析，還可一鍵生成測試報告，並對不一樣版本的質量進行橫向對比。

代碼質量校驗階段

代碼質量校驗階段是整個Blink質量保障的基礎。主要包含單元測試，利用aone提供的"集團代碼規約掃描"工具對代碼進行規範掃描，單機運行的基於minicluster的集成測試，只有這三個階段都測試經過後才容許Blink代碼提交到項目git。

功能測試

Blink功能測試框架使用defender，該框架是由pytest[1]改造而來，很好地支持了BlinkSql測試的特性，並支持第三方插件的引入。在測試集羣中能夠端到端的對某一場景進行精準測試。具體流程以下圖所示，支持IDE和Jenkins兩種觸發模式，yarn_job、yarn_session和local三種case運行調度模式。執行結束後經過web頁面或郵件的形式對結果進行展現，並對運行結果進行持久化。具備以下優點：

一、case的統一調度與精細化管理：如今Blink在defender上有12個場景4000多個case，能夠天天定時進行dailyrun，若是某一類別的case出現問題可單獨執行，並可在頁面上顯示詳情。

二、case的三種運行模式知足了不一樣場景的測試需求：其中yarn_session模式對一個模塊中存在sqlCase的場景較爲適用，可大大減小與Yarn交互的時間。

三、case靈活配置：不只能夠支持系統配置，對每一個case集所需資源（slot，memory等）或集羣其餘配置的不一樣進行單獨配置。

四、一個case可同時支持批和流兩種運行類型。

五、client類型靈活擴展：可對現有數據存儲和服務進行集成和擴展。現已支持多類型data store讀寫服務，yarn_session的啓動，Blink job交互等。

性能測試

Blink做爲實時大數據處理引擎，其對單位時間內的數據處理能力和數據處理的實時性提出了很是嚴苛的要求。所以，性能測試是整個Blink測試中很是重要的一環，是衡量Blink新版本可否發佈的核心標準之一。

Blink的性能測試主要包含Operator性能測試、SQL性能測試和runtime性能測試：

Operator指構成SQL語義的一個原子操做，例如Sum，Aggregate等，是一個不能再分割的算子。Operator的性能測試主要用於監控單個算子在整個開發過程當中的性能變化，以保證局部處理的優化和提升。目前，Operator的測試分紅兩個部分：單個算子的性能測試和算子組合的性能測試。Operator測試以Daily Run的方式反饋性能的變化。

SQL性能測試主要用於監控版本開發過程當中單個SQL的性能變化。TPCH和TPCDS是業界SQL標準性能測試集，分別有22和103個測試用例。測試平臺將其引入到Blink性能測試中，以更全面地衡量Blink的性能變化。

Runtime性能測試主要爲了保障runtime層面性能不回退，主要包含端到端性能測試和模塊性能測試。端到端性能測試首先根據梳理出測試場景，關注各場景job在指定數據量下的job運行時間，模塊性能測試主要包含網絡層性能測試，調度層性能測試，failover性能測試等，更關注在特定場景下job的處理時間。

性能測試將來規劃是將E2E性能測試、模塊級別性能測試和參數調整總體聯動起來，使其可以更好協助開發定位性能問題root cause和查看參數調優效果。

穩定性測試

對於支持高併發、多節點，集羣物理環境複雜的分佈式系統來講，相似磁盤打滿、網絡延遲等物理節點的異常很難避免。Blink做爲一個高可用的分佈式系統，必然要作到在異常狀況下也能保證系統的穩定運行及數據的正常產出。「避免失敗的最好方法就是不斷地失敗」，所以，在Blink任務運行期間將可能發生的異常模擬出來，就可以驗證Blink的穩定性。

咱們把異常場景分爲兩類：一類是"黑猴子"，該類場景與運行環境相關，包括機器重啓、網絡異常、磁盤異常、cpu異常等，這部分異常主要用shell命令來模擬；另外一類異常是"白猴子"，此類場景與Blink job相關，包括rpc消息超時，task異常，heart beat消息超時等，主要經過byteman[2]軟件注入的方式來實現。在穩定性測試中，monkey做爲調度會隨機選取上述異常場景進行組合，以模擬線上可能出現的全部異常場景。

考慮到Blink支持任務failover的特性和穩定性測試的自動運行，咱們把穩定性測試設定爲一輪輪的迭代循環，每一輪迭代都包含釋放出monkey，提交任務，等待job恢復，校驗四個階段，校驗主要包含checkpoint，container及slot資源等是否符合預期，校驗失敗就報警，校驗成功後經過後進入下一輪迭代，以驗證任務在長時間運行下的任務穩定性。

穩定性測試架構分爲四層：組件層主要包含測試Blink job，monkeys和dumper；action層包含job啓動，狀態校驗，輸出校驗等；執行層包含service，monkey操做等，monkey操做時會根據ssh到具體機器，執行monkey操做；最上層是WebUI。詳情以下圖所示：

預發測試 

Blink預發測試階段主要經過克隆線上的真實任務和數據來進行復雜業務邏輯和大數據量的測試。所以，Blink 預發測試是對代碼質量校驗和集成測試的補充以及整個測試流程的完善，是Blink版本發佈的最後一道關卡。

Blink預發測試主要分爲兩個部分：仿真測試和兼容性測試。

仿真測試

仿真測試對Blink的功能、性能和穩定性等基礎測試指標進行進一步地衡量，並將開發中的版本與當前的線上版本進行橫向比較。所以，仿真測試可以儘早發現各類功能、性能退化和穩定性問題，從而提升上線版本的質量。

仿真測試主要分爲環境克隆，環境適配和測試運行三個階段：

環境克隆

環境克隆是實現整個仿真測試的基礎，包括線上任務的挑選、克隆和測試數據的採樣。

Blink的線上任務分散在多個不一樣的工程中，數量較多。雖然，每個線上任務都有其內在的業務邏輯，可是，不一樣的任務能夠根據其主要的處理邏輯進行歸類，例如，以Agg操做爲主的任務集合，以Sum操做爲主的任務集合等，所以，Blink仿真測試須要對線上任務進行甄別，挑選出其中最具備表明性的任務。

仿真測試的測試數據集是當前線上任務輸入數據的採樣，僅在數據規模上有差別，而且，能夠根據測試需求的不一樣進行動態地調節，從而實現對測試目標的精確衡量。

環境適配

環境適配是仿真測試過程當中的初始化階段，主要進行測試用例的修改，使其可以正常運行。該過程主要包括兩個步驟：更改測試數據輸入源和測試結果輸出地址和更新任務的資源配置。

測試運行

測試運行是仿真測試流程中的實際執行模塊，包括測試用例的運行和結果反饋兩個部分。

Blink仿真測試包括功能測試、性能測試和穩定性測試等模塊，不一樣的測試模塊具備不一樣的衡量標準和反饋方式。這些測試模塊的測試結果與代碼質量校驗和集成測試的結果一塊兒構成Blink測試的結果集。

性能測試和功能測試以仿真任務和採樣數據做爲輸入，對比和分析任務在不一樣執行引擎上的執行過程和產出。其中，性能測試重點考察執行過程當中不一樣執行引擎對資源的利用率、吞吐量等性能指標。功能測試則將執行的最終結果進行對比。須要特別指出的是，在功能測試中，線上版本的運行結果被假定爲真，即當線上版本的執行結果與開發版本的執行結果不一樣時，認爲開發版本的執行存在錯誤，須要修復開發中引入的錯誤。

穩定性測試重點關注仿真測試任務在線上克隆環境、大數據量和長時間運行條件下的穩定性。其以Blink開發版本做爲惟一的執行引擎，經過收集執行過程當中的資源利用狀況、吞吐量、failover等指標來進行度量。

兼容性測試

Blink兼容性測試主要用於發現Blink新、舊版本之間的兼容性問題，從而爲線上任務升級Blink執行引擎的版本提供依據。目前，兼容性測試主要分爲靜態檢查和動態運行兩個階段，其中，靜態檢查是整個兼容性測試的基礎。

靜態檢查

靜態檢查主要用於分析線上任務在不一樣執行引擎下生成執行計劃的不一樣，包括兩個方面的內容：

 ●  新的執行引擎生成執行計劃的正確性及生成執行計劃的時間長短。

 ●  新、舊版本的執行引擎生成的執行計劃是否兼容。

在靜態檢查中，若新的執行引擎不能正確地生成執行計劃，或者生成執行計劃的時間超出預期，均可以認爲靜態檢查失敗，Blink新版本中存在異常或者缺陷，須要查找緣由。當新版本可以正確地生成執行計劃時，若新、舊版本的執行引擎生成的執行計劃不兼容，那麼，須要將對比結果反饋給開發人員以判斷該執行計劃的更改是否符合預期；若執行計劃兼容或者執行計劃的更改符合預期，則能夠直接進行運行時測試。

動態運行測試

Blink動態運行測試利用仿真測試中的功能測試模塊來進行任務的運行，是升級Blink新版本以前的最後一輪測試。若任務可以正常啓動且測試結果符合預期，則認爲該任務能夠自動升級，反之，則須要人工介入進行手動升級。

展望

經過一年多的努力，Blink總體質量已經有很大幅度的提升，Blink的測試方法和工具也愈來愈成熟，Blink回饋社區之際，咱們會逐步將測試工具一塊兒輸出，回饋更多的社區開發測試者，與此同時，隨着Blink用戶羣的壯大，Blink業務開發者對於業務任務的質量保證須要日漸高漲，Blink測試團隊將來會提供更多質量保證和開發效率工具，進一步提高Blink開發者工程效率。

原文連接