1. 飛天測試的挑戰

飛天開放平臺基于一個核心系統，即飛天大規模分布式計算系統(簡稱飛天)。飛天期望把幾千臺PC構成一臺“超級計算機”，給上層多種不同的開放服務和云應用提供通用的分布式存儲、計算和任務調度等多重功能。可以看出，飛天具有平臺化，通用性和大規模的特性，飛天測試的挑戰也由此而來。

挑戰一：平臺軟件的復雜性和互聯網發布節奏之間的矛盾。 飛天包含多個復雜的分布式模塊。模塊本身的復雜性乘上各模塊之間的協議依賴，按照傳統軟件開發流程計算，發布一個質量可靠的穩定版本通常需要1~2年。 這樣的發布節奏遠遠滿足不了上層開放服務和云應用快速發展的需要。

挑戰二： 通用平臺支持多種不同應用帶來測試用例數的爆炸。對于飛天，不同的應用場景，不同的數據量，不同的請求壓力，不同的機器規模，有可能在代碼里面走的路徑完全不一樣，對系統的壓力點也各不相同。無論是試圖覆蓋所有應用對飛天的所有用法，還是從設計出發遍歷模塊接口的各種組合，對測試用例設計而言都是不收斂的。那么，當測試用例剪枝無門，是否還有其他捷徑?

挑戰三：大規模生產集群上的問題如何用小規模測試集群暴露。 在阿里各地的數據中心，飛天的生產集群是上千臺物理機組成的。考慮到成本，測試集群規模通常不超過生產集群的十分之一。統計數據顯示，100臺和1000臺的分布式環境的軟硬件故障率，壓力瓶頸點，數據量級，網絡性能都會有很大差異。常規測試方法很難在小集群上發現大規模的問題

下面，我們來談一下飛天測試實踐當前是如何應對這三種挑戰的。

2. 分層測試和持續集成

目前，飛天底層模塊的發布節奏是半年一次，上層模塊的發布則更為頻繁，最短可以達到三周發布一次。這樣的發布節奏主要依靠分層測試和持續集成的機制。按測試層次來分，飛天測試可以分為單元測試，功能測試，系統測試，集成測試，E2E測試(端到端測試)。為了加速飛天新版本的質量收斂，飛天團隊幾乎每個成員都會參與到上述測試類型中，無論是開發同學，還是測試同學。

一般來說，產品只會對外部接口進行功能測試和系統測試，但是由于飛天模塊本身就是分布式的，每個模塊都具有了一個傳統軟件產品的復雜度。所以，模塊團隊除了負責單元測試，也會進行功能測試和系統測試。模塊團隊內，開發同學負責單元測試之外，還會承擔功能測試和局部特性的系統測試， 測試同學通常更專注在測試設計和模塊級別的系統測試。

飛天有獨立于模塊的集成測試團隊，集成測試主要負責兩塊。一方面，通過持續集成的回歸測試集來保證系統中的各個模塊改動集成在一起能夠很好的工作，一旦發現無法短期修復的質量回退，模塊改動會被立刻關閉或回滾。為保證持續集成效果，不同層次的回歸測試集都被盡可能自動化和并且定義合適的回歸頻率， 模塊改動在設計時也會考慮方便關閉或回滾。 另一方面，集成測試也進行平臺級別的系統測試，極盡所能對飛天進行各種嚴刑拷打，考察底層模塊的功能，性能和系統容量，以及在極端或典型應用場景下系統的穩定性和服務可用性。

飛天新版本上線前，開放服務團隊一般都會用集成測試通過的版本跑E2E測試。E2E測試的責任人需負責向應用方了解具體需求，這個需求不僅是一個對接口功能的需求，還包含了數據量的需求，機器規模的需求，吞吐率的需求，延遲時間的需求，以及業務量在一天或者一周內的曲線等等信息。E2E 測試通常要構造近乎完整的應用場景，盡可能模擬/重現真實的數據情況和壓力特征，并且要通過長時間的穩定性測試。有些上層應用還會常備試運行環境(Staging Environment)來隨時做E2E測試的驗證。通常，我們只有在通過了最后的E2E測試之后才能上線給應用生產集群。

為保證測試本身的質量，各層測試覆蓋有不同的衡量方法。單元測試用Coverage工具來檢驗行覆蓋和分支覆蓋;功能測試一般考察功能點覆蓋外，這些都是大家熟知的。此外，我們對系統測試，集成測試和E2E測試設計了一種特別的覆蓋- Log Coverage。Log Coverage工具能夠通過測試運行過程中飛天輸出的Log信息的多少來判斷測試是否有足夠的覆蓋率。通過拿到生產集群的Log與測試中的Log進行比較，會找到我們之前沒有測試到的地方。另外，通過對代碼中從未打印出的Error Log的檢查，我們也可以知道有多少異常邏輯我們沒有測試過。

3.基于監控的探索性測試和灰盒測試

如挑戰二所述，測試用例的爆炸一度讓我們非常糾結。我們發現無法通過黑盒測試的設計思路來窮舉所有的情況，即使能設計出足夠完整的測試用例，我們也沒有足夠機器，人手和時間來執行這些測試。

所幸，我們還有探索性測試，監控系統則成為我們探索方向的指引。飛天有詳細的監控系統可以監控整個集群的各種參數，這些參數不光是OS層面的參數，更多的是飛天模塊本身通過調用我們監控系統的API來完成對自身某些指標的統計。這些統計不光在線上系統能夠起到監控報警的作用，也能給探索性測試提供依據。執行測試的人員可以通過不斷改變測試的各項參數，結合這些指標的變化進行探索式的測試，一個壓力測試用例在執行時可以變化出貼近應用的各種極端場景。通常，通過指標在某些壓力變化下或者隨著時間推移時的異常行為，測試人員會更容易找到一些深藏的Bug。另外，在平臺級別的系統測試時，通過對模塊內部Error Log的監控也能達到很好的效果。

探索性測試固然重要，但是光有探索，如果測試人員本身不了解系統的一些內部邏輯，會出現兩種情況：第一種是，只驗證設計好的場景，其他一些異常的情況，自己無法解釋，但是本身又不是驗證標準，導致很多隱藏的問題最終在線上爆發;第二種是，像一個無頭蒼蠅，漫無目的的進行探索，浪費了時間，卻達不到好的效果。在飛天測試中，我們要求測試人員必須從方案設計之初甚至是討論需求的時候就和開發的同學在一起討論，測試的同學需要比開發更加理解系統的設計原則。

了解分布式系統的工作原理后，測試同學會明白如何去做一個有效的灰盒測試。比如，在某個關鍵點加請求壓力會事半功倍;在哪個時機去做測試結果斷言會更方便，徹底或完整;甚至知道對一個模塊進程如何注入代碼，模擬重現機率很小的協議通信丟包的問題。

有一個很典型的例子，早期，我們內部開發一個基于表結構的存儲引擎時，曾經出現過這樣一件事情：測試程序在最終驗證一致性時，一直都是通過的，但是業務方和我們一起做E2E測試的時候，會有很低的概率發現數據讀出來是錯誤的。測試人員百思不得其解，最后發現，這份數據在寫入的時候，會先在三個地方進行修改，但是由于一些時序和鎖的問題，在改過了兩個地方之后就返回成功了，第三個地方是在內存中，過一陣子就會被重新刷成正確的值。如果當時測試的同學知道系統里面這些設計，當時就會設計寫入過程中，對數據一致性進行實時檢測，就不會在代價更高的E2E測試中發現問題，解決的效率也會因此而提高。

4. 帶壓力和隨機故障模擬的長時間穩定性測試

文首提到大規模生產集群上的問題，很難在小規模的測試集群上發現。究其原因，我們發現主要是兩方面導致的：

1. 大規模集群中原本小概率的單機故障會隨機器數增加，導致集群整體的硬件故障率線性提升，甚至多種故障同時發生的概率也大大增加。

2. 機器數增多會導致對飛天模塊的壓力點發生轉移。以彈性計算(ECS)為例，在300臺變600臺時發現，原本擔心的文件系統master還未成為QPS瓶頸，負責鎖文件協同的命名服務首先成為瓶頸。

此外，各種故障的組合爆炸也讓完整的容錯測試在設計和執行上的代價變得太大。

為解決上述困難，在飛天測試實踐中，我們逐漸積累出一套帶背景壓力和隨機故障模擬的長時間穩定性測試方案。

背景壓力主要是針對各個底層模塊的讀寫壓力，通常會針對某類應用場景來模擬?；诜侄沃拖到y仿真的方法， 我們實現了一些輕量級的壓力工具，讓各模塊的master機器和slave機器分別接受到大規模生產集群上的類似訪問壓力和連接規模。另外，還增加一些諸如CPU，Memory，Network的資源消耗器，以模擬生產環境業務繁忙導致機器資源緊張場景。故障模擬上，一方面盡可能豐富軟件手段模擬軟硬件故障，比如磁盤錯誤(包括壞盤，只讀等)，機器宕機，重啟，斷網，交換機重啟，主要模塊進程重啟，假死等;另一方面，這些故障模擬操作都會按照預先設定比例進行隨機組合。在這樣的背景壓力和隨機故障操作下，長時間(至少7x24 小時)持續運行上層應用模擬程序/作業，同時通過在線監控系統來檢查飛天是否正常。

簡而言之，我們用背景壓力解決壓力點問題，用長時間跑解決小集群的故障小概率問題，用隨機故障模擬和組合來解決容錯測試設計和執行的代價問題。

實踐證明，飛天很多重要的bug都是通過這個測試被發現的。當然這類測試也有短處，就是問題調查需要較長的時間，要求測試人員對系統有較深的了解和診斷能力。

5. 結束語

大規模分布式系統的測試是一項非常有挑戰的工作。 盡管我們持續落實各層測試，積累實踐經驗，創新測試方法，但由于測試條件的限制，生產環境的復雜，軟件問題仍然無法完全依賴測試消除。本文僅僅提到了飛天測試在Test in lab方向的一些思考和實踐，完善的飛天質量保證體系其實需要Test in Lab和Test in Production雙管齊下，這是飛天測試樂此不疲的努力方向。