分布式系統(tǒng)具有軟硬件平臺(tái)分布性、高穩(wěn)定性、高可用性、高可擴(kuò)展性、高可管理性、高并發(fā)性及數(shù)據(jù)一致性等多種特性。正是由于這些重要的特性，使得分布式系統(tǒng)的測(cè)試過(guò)程變得相對(duì)復(fù)雜和困難。本文主要從分布式系統(tǒng)測(cè)試的四個(gè)重要方面出發(fā)，探討分布式系統(tǒng)測(cè)試過(guò)程中存在的一些難點(diǎn)問(wèn)題并進(jìn)行適當(dāng)?shù)姆治觥?/p>

分布式系統(tǒng)測(cè)試環(huán)境

一般來(lái)說(shuō)，分布式系統(tǒng)是由一組服務(wù)器或者網(wǎng)絡(luò)設(shè)備組成（如圖1）。我們?cè)诓渴饻y(cè)試環(huán)境的時(shí)候，所涉及的系統(tǒng)架構(gòu)也會(huì)是比較復(fù)雜的，有以下幾個(gè)方面：

    網(wǎng)絡(luò)架構(gòu)。在圖1中，我們應(yīng)該如何在本地測(cè)試實(shí)驗(yàn)室環(huán)境中模擬分別位于北京和紐約的兩個(gè)數(shù)據(jù)中心呢？由于地理原因，北京和紐約之間網(wǎng)絡(luò)的RTT（Round Trip Time）至少不會(huì)低于某個(gè)值。所以，在正式進(jìn)行測(cè)試之前，我們需要構(gòu)建出測(cè)試所需要的網(wǎng)絡(luò)環(huán)境，模擬出這樣的固定網(wǎng)絡(luò)延時(shí)。
    硬件要求。例如，我們?cè)��?jīng)測(cè)試過(guò)一個(gè)分布式的文件系統(tǒng)，數(shù)據(jù)服務(wù)器要求運(yùn)行在裸盤(pán)設(shè)備上（數(shù)據(jù)的存儲(chǔ)格式、尋址方式自定義以提高查找速度），所以，在安裝操作系統(tǒng)時(shí)需要特別考慮這樣的需求。同時(shí)，在測(cè)試前，我們需要按照系統(tǒng)設(shè)計(jì)的要求采購(gòu)硬件設(shè)備。例如，硬盤(pán)的規(guī)格（SATA硬盤(pán)還是SAS硬盤(pán)）、內(nèi)存的規(guī)格等。
    配置復(fù)雜。分布式系統(tǒng)涉及的軟硬件平臺(tái)較多，整個(gè)系統(tǒng)中需要設(shè)置的參數(shù)項(xiàng)非常多，系統(tǒng)配置過(guò)程會(huì)相應(yīng)地變得復(fù)雜、困難和易錯(cuò)。例如，在圖1中，我們需要配置的系統(tǒng)配置文件至少有十多個(gè)。

如果條件允許的話，分布式系統(tǒng)的測(cè)試環(huán)境應(yīng)該由測(cè)試工程師自己來(lái)搭建。系統(tǒng)管理員、網(wǎng)絡(luò)管理員等都沒(méi)有辦法完全代替測(cè)試工程師來(lái)進(jìn)行這些工作，因?yàn)樗麄儾⒉磺宄�在�?shí)際的測(cè)試過(guò)程中，測(cè)試工程師對(duì)軟硬件環(huán)境的具體需求是什么，尤其是不同的測(cè)試用例對(duì)于環(huán)境的要求可能是不一樣的。

分布式系統(tǒng)功能測(cè)試

在測(cè)試執(zhí)行過(guò)程中，對(duì)測(cè)試結(jié)果的分析是一個(gè)需要進(jìn)行深入思考的重點(diǎn)問(wèn)題。分布式系統(tǒng)測(cè)試的重點(diǎn)在于對(duì)后端服務(wù)器集群的測(cè)試，而判定系統(tǒng)中是否存在Bug則是我們需要解決的重要問(wèn)題。那么應(yīng)該如何確定是否存在Bug呢？

對(duì)于測(cè)試結(jié)果的分析，我們通常觀察下面幾種情況。

    觀察前端應(yīng)用的返回結(jié)果。這里需要分兩種情況來(lái)考慮：第一，按照前端應(yīng)用業(yè)務(wù)功能點(diǎn)及流程進(jìn)行操作，觀察返回結(jié)果是否符合業(yè)務(wù)方的需求預(yù)期；第二，操作后端的服務(wù)器（通常是重啟、宕機(jī)、斷網(wǎng)等操作），觀察前端應(yīng)用的返回結(jié)果是否符合系統(tǒng)的設(shè)計(jì)需求。
    分析服務(wù)器日志。在功能測(cè)試過(guò)程中，當(dāng)我們?cè)趩��?dòng)服務(wù)器的時(shí)候，需要將日志級(jí)別定義為Debug級(jí)別（低級(jí)別）。這樣做的主要目的是為了能便于測(cè)試工程師來(lái)分析日志和定位問(wèn)題。為了能更好地定位問(wèn)題，常常需要在服務(wù)器程序代碼中進(jìn)行日志打樁，把程序中的一些重要數(shù)據(jù)通過(guò)日志的方式展現(xiàn)出來(lái)。通常情況下，我們需要對(duì)日志的格式進(jìn)行約定，在日志行中增加一些關(guān)鍵字來(lái)進(jìn)行分類(lèi)，這將便于測(cè)試工程師進(jìn)行日志分析，也有利于開(kāi)展分布式系統(tǒng)的自動(dòng)化測(cè)試。另外，值得注意的是，我們盡可能地將打樁代碼放在Debug代碼中，避免影響系統(tǒng)代碼，引入新問(wèn)題。
    分析操作系統(tǒng)的一些重要信息。我們測(cè)試的分布式系統(tǒng)絕大多數(shù)是基于Linux操作系統(tǒng)開(kāi)發(fā)的，在測(cè)試的過(guò)程中，除了詳細(xì)分析程序日志以外，還需要對(duì)操作系統(tǒng)的一些重要數(shù)據(jù)信息進(jìn)行分析，從而來(lái)診斷服務(wù)器程序是否存在異常。以Linux操作系統(tǒng)為例，我們常常會(huì)使用top命令、netstat命令及sar命令來(lái)查看操作系統(tǒng)的一些數(shù)據(jù)信息。例如，可以通過(guò)netstat命令檢查服務(wù)器程序是否正確地監(jiān)聽(tīng)了指定的端口等。
    借助其他分析工具。例如，如何判斷服務(wù)器程序是否產(chǎn)生了內(nèi)存泄漏？通常需要借助于內(nèi)存檢測(cè)工具來(lái)進(jìn)行分析。在Linux環(huán)境下，我們常用Valgrind來(lái)進(jìn)行內(nèi)存檢測(cè)。這是一款非常好用、功能強(qiáng)大的分析工具（官方網(wǎng)站：http://www.valgrind.org/），可以幫助測(cè)試或者開(kāi)發(fā)工程師快速發(fā)現(xiàn)很多隱藏的程序Bug，尤其是在內(nèi)存檢測(cè)方面（同時(shí)它還具有很多其他的功能，讀者可以自己查看官網(wǎng)中的使用手冊(cè)）。

分布式系統(tǒng)壓力測(cè)試與性能測(cè)試

對(duì)于分布式系統(tǒng)而言，壓力測(cè)試和性能測(cè)試非常重要。在進(jìn)行壓力測(cè)試和性能測(cè)試的時(shí)候，可能會(huì)碰到下面一些難點(diǎn)。

    數(shù)據(jù)準(zhǔn)備。如何準(zhǔn)備海量的測(cè)試數(shù)據(jù)并保證模擬數(shù)據(jù)的真實(shí)性？以一個(gè)分布式的文件系統(tǒng)為例，預(yù)先存入100GB的數(shù)據(jù)還是存入100TB的數(shù)據(jù)、存入的文件是大小基本一致差別不大還是各不相同甚至差異很大（例如，從幾十字節(jié)至幾十兆字節(jié)不等），這些因素對(duì)于分布式系統(tǒng)的性能影響是有很大差異的。另外，如果需要預(yù)先存入100TB的數(shù)據(jù)，若按每秒寫(xiě)入100MB數(shù)據(jù)來(lái)計(jì)算，寫(xiě)入100TB數(shù)據(jù)需要100×1024×1024/100=1048576秒=291.27小時(shí)=12天。我們是否能忍受這么長(zhǎng)時(shí)間的數(shù)據(jù)準(zhǔn)備工作？為了解決這樣的問(wèn)題，我們需要對(duì)系統(tǒng)架構(gòu)設(shè)計(jì)進(jìn)行深入分析，設(shè)計(jì)好測(cè)試場(chǎng)景，并提前進(jìn)行測(cè)試用例的設(shè)計(jì)，以盡早開(kāi)始準(zhǔn)備測(cè)試數(shù)據(jù)。
    性能或壓力測(cè)試工具。通常來(lái)說(shuō)，分布式系統(tǒng)的測(cè)試需要開(kāi)發(fā)一些測(cè)試工具來(lái)滿足性能測(cè)試的需求。如果可以的話，建議這樣的測(cè)試工具好由測(cè)試工程師自己來(lái)實(shí)現(xiàn)，因?yàn)闇y(cè)試工程師更清楚自己的測(cè)試需求。當(dāng)需要自己開(kāi)發(fā)測(cè)試工具的時(shí)候，有兩個(gè)關(guān)鍵問(wèn)題需要重點(diǎn)關(guān)注：第一，一些關(guān)鍵數(shù)據(jù)的收集方式與計(jì)算將成為性能測(cè)試工具的關(guān)鍵，例如，TPS（每秒請(qǐng)求數(shù)）、Throughput（吞吐量）計(jì)算的準(zhǔn)確性；第二，要保證性能測(cè)試工具的性能，如果工具本身的性能不好，將無(wú)法給予分布式系統(tǒng)足夠強(qiáng)大的壓力來(lái)進(jìn)行測(cè)試。另外，當(dāng)考慮到多并發(fā)（例如有10萬(wàn)客戶端同時(shí)并發(fā)連接）時(shí)，如果性能測(cè)試工具在一臺(tái)測(cè)試機(jī)器上只能運(yùn)行50個(gè)或者更少的話，那么需要的測(cè)試機(jī)器數(shù)量也將會(huì)很龐大（例如2000臺(tái)測(cè)試機(jī)），這個(gè)成本或許是許多公司不能承受的。因此，性能測(cè)試工具本身的性能必須要足夠好才能滿足需求、降低測(cè)試成本。

分布式系統(tǒng)自動(dòng)化測(cè)試

自動(dòng)化測(cè)試是測(cè)試行業(yè)發(fā)展的必然趨勢(shì)，對(duì)于分布式系統(tǒng)測(cè)試而言也不例外。在實(shí)施分布式系統(tǒng)自動(dòng)化測(cè)試的過(guò)程中，我們可能會(huì)碰到下面兩個(gè)難點(diǎn)問(wèn)題。

    涉及平臺(tái)多且硬件雜，測(cè)試流程控制困難。在實(shí)施自動(dòng)化測(cè)試的過(guò)程中，測(cè)試腳本需要控制的操作系統(tǒng)和應(yīng)用程序很多，而且存在跨平臺(tái)的特性，同時(shí)還有可能需要控制一些網(wǎng)絡(luò)設(shè)備。因此，選擇一個(gè)的自動(dòng)化測(cè)試框架成為了非常重要的工作之一。以我們的實(shí)踐經(jīng)驗(yàn)來(lái)看，STAF是一個(gè)不錯(cuò)的選擇（官方網(wǎng)站：http://staf.sourceforge.net/），它的平臺(tái)（Windows及Linux各版本）支持及開(kāi)發(fā)語(yǔ)言的支持都很全面。
    測(cè)試結(jié)果驗(yàn)證復(fù)雜。對(duì)于分布式系統(tǒng)的自動(dòng)化測(cè)試來(lái)說(shuō)，我們需要通過(guò)測(cè)試腳本來(lái)收集各種測(cè)試結(jié)果數(shù)據(jù)以驗(yàn)證測(cè)試結(jié)果的正確性。在實(shí)施自動(dòng)化測(cè)試的過(guò)程中，我們可以將測(cè)試結(jié)果數(shù)據(jù)收集部分模塊化，通過(guò)各子模塊來(lái)檢測(cè)各項(xiàng)數(shù)據(jù)是否正確。例如，我們會(huì)設(shè)計(jì)一個(gè)日志分析模塊，主要負(fù)責(zé)從服務(wù)器應(yīng)用程序的日志中收集相應(yīng)數(shù)據(jù)進(jìn)行對(duì)比驗(yàn)證（本文前面提到的在打樁日志中增加關(guān)鍵字部分顯得格外重要）。

隨著互聯(lián)網(wǎng)的發(fā)展，大型分布式系統(tǒng)也越來(lái)越多、越來(lái)越復(fù)雜、越來(lái)越重要。如何有效地保證大型分布式系統(tǒng)7×24小時(shí)全天候持續(xù)穩(wěn)定地運(yùn)行也成為了一個(gè)重要課題。本文希望通過(guò)對(duì)分布式系統(tǒng)測(cè)試過(guò)程中碰到的一些難點(diǎn)問(wèn)題的分析給予讀者一定的啟發(fā)。

作者簡(jiǎn)介：

帥丹文，測(cè)試技術(shù)專(zhuān)家，近十年測(cè)試與開(kāi)發(fā)工作經(jīng)驗(yàn)，目前負(fù)責(zé)淘寶基礎(chǔ)應(yīng)用測(cè)試團(tuán)隊(duì)，對(duì)測(cè)試架構(gòu)以及自動(dòng)化測(cè)試、接口測(cè)試、分布式系統(tǒng)測(cè)試有深入的研究。