大規(guī)模分布式系統(tǒng)的測試實踐(共5頁)

1、 HYPERLINK /15093/ o Permanent Link to 大規(guī)模分布式系統(tǒng)的測試(csh)實踐 大規(guī)模分布式系統(tǒng)的測試(csh)實踐文 / 許咼兢，陳舟鋒，鄭剛飛天測試(csh)的挑戰(zhàn)飛天開放平臺基于一個核心系統(tǒng)，即飛天大規(guī)模分布式計算系統(tǒng)（簡稱飛天）。飛天期望把幾千臺PC構(gòu)成一臺“超級計算機(jī)”，為上層多種不同的開放服務(wù)和云應(yīng)用提供通用的分布式存儲、計算和任務(wù)調(diào)度等多重功能。由此可以看出，飛天具有平臺化、通用性和大規(guī)模的特性，于是，飛天測試的挑戰(zhàn)也由此而來。挑戰(zhàn)一：平臺軟件的復(fù)雜性和互聯(lián)網(wǎng)發(fā)布節(jié)奏之間的矛盾。飛天包含多個復(fù)雜的分布式模塊。模塊本身的復(fù)雜性乘以各模塊之間的協(xié)議

2、依賴，按照傳統(tǒng)軟件開發(fā)流程計算，發(fā)布一個質(zhì)量可靠的穩(wěn)定版本通常需要12年。這樣的發(fā)布節(jié)奏遠(yuǎn)遠(yuǎn)滿足不了上層開放服務(wù)和云應(yīng)用快速發(fā)展的需要。挑戰(zhàn)二：通用平臺支持多種不同應(yīng)用帶來測試用例數(shù)的爆炸。對于飛天，不同的應(yīng)用場景、不同的數(shù)據(jù)量、不同的請求壓力、不同的機(jī)器規(guī)模，有可能在代碼里面走的路徑完全不一樣，對系統(tǒng)的壓力點(diǎn)也各不相同。無論是試圖覆蓋所有應(yīng)用對飛天的所有用法，還是從設(shè)計出發(fā)遍歷模塊接口的各種組合，對測試用例設(shè)計而言都是不收斂的。那么，當(dāng)測試用例剪枝無門，是否還有其他捷徑？挑戰(zhàn)三：對于大規(guī)模生產(chǎn)集群上的問題如何用小規(guī)模測試集群暴露。在阿里各地的數(shù)據(jù)中心，飛天的生產(chǎn)集群是上千臺物理機(jī)組成的?？紤]

3、到成本，測試集群規(guī)模通常不超過生產(chǎn)集群的十分之一。統(tǒng)計數(shù)據(jù)顯示，100臺和1000臺的分布式環(huán)境的軟硬件故障率、壓力瓶頸點(diǎn)、數(shù)據(jù)量級、網(wǎng)絡(luò)性能都會有很大差異。常規(guī)測試方法很難在小集群上發(fā)現(xiàn)大規(guī)模的問題。下面，我們來談一下飛天測試實踐當(dāng)前是如何應(yīng)對這三種挑戰(zhàn)的。分層測試和持續(xù)集成目前，飛天底層模塊的發(fā)布節(jié)奏是半年一次，上層模塊的發(fā)布則更為頻繁，最短可以達(dá)到三周發(fā)布一次。這樣的發(fā)布節(jié)奏主要依靠分層測試和持續(xù)集成的機(jī)制。按測試層次來分，飛天測試可以分為單元測試、功能測試、系統(tǒng)測試、集成測試、E2E測試（端到端測試）。為了加速飛天新版本的質(zhì)量收斂，飛天團(tuán)隊幾乎每個成員都會參與到上述測試類型中無論是開發(fā)

4、同學(xué)，還是測試同學(xué)。一般來說，產(chǎn)品只會對外部接口進(jìn)行功能測試和系統(tǒng)測試，但由于飛天模塊本身就是分布式的，每個模塊都具有一個傳統(tǒng)軟件產(chǎn)品的復(fù)雜度，所以模塊團(tuán)隊除了負(fù)責(zé)單元測試，也會進(jìn)行功能測試和系統(tǒng)測試。模塊團(tuán)隊內(nèi)，開發(fā)同學(xué)(tng xu)除負(fù)責(zé)單元測試之外，還會承擔(dān)功能測試和局部特性的系統(tǒng)測試，測試同學(xué)通常更專注在測試設(shè)計和模塊級別的系統(tǒng)測試。飛天有獨(dú)立于模塊的集成(j chn)測試團(tuán)隊，集成測試主要負(fù)責(zé)兩塊。一方面，通過持續(xù)集成的回歸測試集來保證系統(tǒng)中的各個模塊改動集成在一起能夠很好地工作，一旦發(fā)現(xiàn)無法短期修復(fù)的質(zhì)量回退的話，模塊改動會被立刻關(guān)閉或回滾。為保證持續(xù)集成效果，不同(b tn)層

5、次的回歸測試集都被盡可能自動化，并且定義合適的回歸頻率，模塊改動在設(shè)計時也會考慮方便關(guān)閉或回滾。另一方面，集成測試也進(jìn)行平臺級別的系統(tǒng)測試，極盡所能地對飛天進(jìn)行各種嚴(yán)刑拷打，考察底層模塊的功能、性能和系統(tǒng)容量，以及在極端或典型應(yīng)用場景下系統(tǒng)的穩(wěn)定性和服務(wù)可用性。飛天新版本上線前，開放服務(wù)團(tuán)隊一般都會用集成測試通過的版本跑E2E測試。E2E測試的責(zé)任人需負(fù)責(zé)向應(yīng)用方了解具體需求，這個需求不僅是一個對接口功能的需求，還包含了數(shù)據(jù)量的需求、機(jī)器規(guī)模的需求、吞吐率的需求、延遲時間的需求以及業(yè)務(wù)量在一天或者一周內(nèi)的曲線等信息。E2E測試通常要構(gòu)造近乎完整的應(yīng)用場景，盡可能模擬/重現(xiàn)真實的數(shù)據(jù)情況和壓力特

6、征，并且要通過長時間的穩(wěn)定性測試。有些上層應(yīng)用還會常備試運(yùn)行環(huán)境（Staging Environment）來隨時做E2E測試的驗證。通常，我們只有在通過了最后的E2E測試之后才能上線給應(yīng)用生產(chǎn)集群。為保證測試本身的質(zhì)量，各層測試覆蓋有不同的衡量方法。單元測試用Coverage工具來檢驗行覆蓋和分支覆蓋；功能測試一般考察功能點(diǎn)覆蓋外，這些都是大家熟知的。此外，我們對系統(tǒng)測試、集成測試和E2E測試設(shè)計了一種特別的覆蓋Log Coverage。Log Coverage工具能夠通過測試運(yùn)行過程中飛天輸出的Log信息的多少來判斷測試是否有足夠的覆蓋率。通過拿到生產(chǎn)集群的Log與測試中的Log進(jìn)行比較，會

7、找到我們之前沒有測試到的地方。另外，通過對代碼中從未打印出的Error Log的檢查，我們也可以知道有多少異常邏輯我們沒有測試過?；诒O(jiān)控的探索性測試和灰盒測試如挑戰(zhàn)二所述，測試用例的爆炸一度讓我們非常糾結(jié)。我們發(fā)現(xiàn)無法通過黑盒測試的設(shè)計思路來窮舉所有的情況，即使能設(shè)計出足夠完整的測試用例，也沒有(mi yu)足夠機(jī)器、人手和時間來執(zhí)行這些測試。所幸，我們還有探索性測試，監(jiān)控(jin kn)系統(tǒng)則成為我們探索方向的指引。飛天有詳細(xì)的監(jiān)控系統(tǒng)，可以監(jiān)控整個集群的各種( zhn)參數(shù)，這些參數(shù)不僅是OS層面的參數(shù)，更多的是飛天模塊本身通過調(diào)用我們監(jiān)控系統(tǒng)的API來完成對自身某些指標(biāo)的統(tǒng)計。這些統(tǒng)計

8、不僅在線上系統(tǒng)能夠起到監(jiān)控報警的作用，也能給探索性測試提供依據(jù)。執(zhí)行測試的人員可以通過不斷改變測試的各項參數(shù)，結(jié)合這些指標(biāo)的變化進(jìn)行探索式的測試，一個壓力測試用例在執(zhí)行時可以變化出貼近應(yīng)用的各種極端場景。通常，通過指標(biāo)在某些壓力變化下或者隨著時間推移時的異常行為，測試人員會更容易找到一些深藏的Bug。另外，在平臺級別的系統(tǒng)測試時，通過對模塊內(nèi)部Error Log的監(jiān)控也能達(dá)到很好的效果。探索性測試固然重要，但僅有探索，如果測試人員本身不了解系統(tǒng)的一些內(nèi)部邏輯的話，就會出現(xiàn)兩種情況：第一種是只驗證設(shè)計好的場景，其他一些異常的情況，自己無法解釋，但本身又不是驗證標(biāo)準(zhǔn)，導(dǎo)致很多隱藏的問題最終在線上爆

9、發(fā)；第二種像一個無頭蒼蠅，漫無目的地進(jìn)行探索，浪費(fèi)了時間，卻達(dá)不到好的效果。在飛天測試中，我們要求測試人員必須從方案設(shè)計之初甚至是討論需求時就和開發(fā)的同學(xué)在一起討論，測試的同學(xué)需要比開發(fā)更加理解系統(tǒng)的設(shè)計原則。了解分布式系統(tǒng)的工作原理后，測試同學(xué)會明白如何去做一個有效的灰盒測試。比如，在某個關(guān)鍵點(diǎn)加請求壓力會事半功倍；在哪個時機(jī)去做測試結(jié)果斷言會更方便、徹底或完整；甚至知道對一個模塊進(jìn)程如何注入代碼，模擬重現(xiàn)機(jī)率很小的協(xié)議通信丟包的問題。有一個很典型的例子。早期，我們內(nèi)部開發(fā)一個基于表結(jié)構(gòu)的存儲引擎時，曾出現(xiàn)過這樣一件事情：測試程序在最終驗證一致性時，一直都是通過的，但業(yè)務(wù)方和我們一起做E2E

10、測試時，會有很低的概率發(fā)現(xiàn)數(shù)據(jù)讀出來是錯誤的。測試人員百思不得其解，最后發(fā)現(xiàn)，這份數(shù)據(jù)在寫入的時候，會先在三個地方進(jìn)行修改，但由于一些時序和鎖的問題，在改過了兩個地方之后就返回成功了，第三個地方是在內(nèi)存中，過一陣子就會被重新刷成正確的值。如果當(dāng)時測試的同學(xué)知道系統(tǒng)里面的這些設(shè)計，當(dāng)時就會設(shè)計寫入過程中，對數(shù)據(jù)一致性進(jìn)行實時檢測，就不會在代價更高的E2E測試中發(fā)現(xiàn)問題，解決的效率也會因此而提高。帶壓力(yl)和隨機(jī)故障模擬的長時間穩(wěn)定性測試文首提到大規(guī)模生產(chǎn)集群上的問題(wnt)，很難在小規(guī)模的測試集群上發(fā)現(xiàn)。究其原因，主要是兩方面導(dǎo)致的。大規(guī)模集群中原本小概率(gil)的單機(jī)故障會隨機(jī)器數(shù)增加

11、，導(dǎo)致集群整體的硬件故障率線性提升，甚至多種故障同時發(fā)生的概率也大大增加。機(jī)器數(shù)增多會導(dǎo)致對飛天模塊的壓力點(diǎn)發(fā)生轉(zhuǎn)移。以彈性計算（ECS）為例，在300臺變600臺時發(fā)現(xiàn)，原本擔(dān)心的文件系統(tǒng)Master還未成為QPS瓶頸，負(fù)責(zé)鎖文件協(xié)同的命名服務(wù)首先成為瓶頸。此外，各種故障的組合爆炸也讓完整的容錯測試在設(shè)計和執(zhí)行上的代價變得太大。為解決上述困難，在飛天測試實踐中，我們逐漸積累出一套帶背景壓力和隨機(jī)故障模擬的長時間穩(wěn)定性測試方案。背景壓力主要是針對各個底層模塊的讀寫壓力，通常會針對某類應(yīng)用場景來模擬?；诜侄沃拖到y(tǒng)仿真的方法，我們實現(xiàn)了一些輕量級的壓力工具，讓各模塊的Master機(jī)器和Sla

12、ve機(jī)器分別接受到大規(guī)模生產(chǎn)集群上的類似訪問壓力和連接規(guī)模。另外，還增加一些諸如CPU、Memory、Network的資源消耗器，以模擬生產(chǎn)環(huán)境業(yè)務(wù)繁忙導(dǎo)致機(jī)器資源緊張的場景。故障模擬上，一方面，盡可能豐富軟件手段模擬軟硬件故障，比如磁盤錯誤（包括壞盤、只讀等）、機(jī)器宕機(jī)、重啟、斷網(wǎng)、交換機(jī)重啟、主要模塊進(jìn)程重啟、假死等；另一方面，這些故障模擬操作都會按照預(yù)先設(shè)定比例進(jìn)行隨機(jī)組合。在這樣的背景壓力和隨機(jī)故障操作下，長時間（至少724小時）持續(xù)運(yùn)行上層應(yīng)用模擬程序/作業(yè)，同時通過在線監(jiān)控系統(tǒng)來檢查飛天是否正常。簡而言之，我們用背景壓力解決壓力點(diǎn)問題，用長時間跑解決小集群的故障小概率問題，用隨機(jī)故

13、障模擬和組合來解決容錯測試設(shè)計和執(zhí)行的代價問題。實踐證明，飛天很多重要的Bug都是通過這個測試被發(fā)現(xiàn)的。當(dāng)然，這類測試也有短處，就是問題調(diào)查需要較長的時間，要求測試人員對系統(tǒng)有較深的了解和診斷能力。結(jié)束語大規(guī)模分布式系統(tǒng)的測試是一項非常有挑戰(zhàn)的工作。盡管我們持續(xù)落實各層測試，積累實踐經(jīng)驗，創(chuàng)新測試方法，但由于測試條件的限制、生產(chǎn)環(huán)境的復(fù)雜，軟件問題仍然無法完全依賴測試消除。本文僅僅提到了飛天測試在Test in Lab方向的一些思考和實踐，完善的飛天質(zhì)量保證體系其實需要Test in Lab和Test in Production雙管齊下，這才是飛天測試樂此不疲的努力方向。作者許咼兢，阿里云飛天技術(shù)專家，負(fù)責(zé)飛天開放服務(wù)質(zhì)量保障，長期工作在測試(csh)工作第一線，目前專注于分布式大規(guī)模在線場景的測試。作者(zuzh)陳舟鋒，阿里云飛天技術(shù)專家，負(fù)責(zé)飛天基礎(chǔ)模塊集成測試。畢業(yè)于北京航空航天大學(xué)，畢業(yè)后一直從事軟件測試開發(fā)工作，曾就職于微軟亞洲工程院和搜索技術(shù)中心，在UI自動化測試(csh)和分布式系統(tǒng)測試上有濃厚興趣和較多積累。作者鄭剛，阿里云飛天高級