大規模分布式系統的測試實踐

　　飛天測試的挑戰

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

　　挑戰一：平臺軟件的復雜性和互聯網發布節奏之間的矛盾。

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

　　挑戰二：通用平臺支持多種不同應用帶來測試用例數的爆炸。

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

　　挑戰三：對于大規模生產集群上的問題如何用小規模測試集群暴露。

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

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

　　分層測試和持續集成

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

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

　　飛天有獨立于模塊的集成測試團隊，集成測試主要負責兩塊。

　　一方面，通過持續集成的回歸測試集來保證系統中的各個模塊改動集成在一起能夠很好地工作，一旦發現無法短期修復的質量回退的話，模塊改動會被立刻關閉或回滾。為保證持續集成效果，不同層次的回歸測試集都被盡可能自動化，并且定義合適的回歸頻率，模塊改動在設計時也會考慮方便關閉或回滾。

　　另一方面，集成測試也進行平臺級別的系統測試，極盡所能地對飛天進行各種嚴刑拷打，考察底層模塊的功能、性能和系統容量，以及在極端或典型應用場景下系統的穩定性和服務可用性。

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

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

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

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

　　所幸，我們還有探索性測試，監控系統則成為我們探索方向的指引。

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

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

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

原文轉自：http://www.programmer.com.cn/15093/