于鑒桐,曹三省
(中國傳媒大學(xué),北京 100024)
近年來,為了提高經(jīng)營管理和服務(wù)水平,及適應(yīng)新業(yè)務(wù)發(fā)展的需求,有線運營商開始采用先進的信息管理技術(shù)來提高自身競爭力,構(gòu)建自己的運營支撐系統(tǒng)框架和模式,在此基礎(chǔ)上,BOSS系統(tǒng)應(yīng)運而生[1]。同時由于數(shù)字電視融合業(yè)務(wù)互聯(lián)網(wǎng)門戶的獨特性,人們對BOSS系統(tǒng)性能的要求越來越高。系統(tǒng)常常是大量終端用戶同時訪問,無論是從人員、技術(shù)上,還是從時間、資源上,性能測試的挑戰(zhàn)也越來越大,從而無法預(yù)測多用戶并發(fā)時應(yīng)用系統(tǒng)的運行情況。性能測試的難點就在于如何仿真和模擬成千上萬的真實用戶并發(fā)對服務(wù)器造成的壓力情況、如何監(jiān)控和統(tǒng)計服務(wù)器端的性能變化、如何從千差萬別的測試數(shù)據(jù)中分析并獲取有效的測試結(jié)果。傳統(tǒng)的簡單的手工測試已經(jīng)不能有效滿足壓力測試的需求,因此必須借助于自動化工具來完成[2]。
業(yè)務(wù)運營支撐系統(tǒng)(BOSS,Business Operation Support System)[3-4]融合了BSS(業(yè)務(wù)支撐系統(tǒng),Business Support Systems)與 OSS(運營支撐系統(tǒng),Operation Support Systems),是一個綜合的業(yè)務(wù)運營和管理平臺,它融合了傳統(tǒng)數(shù)據(jù)業(yè)務(wù)與增值業(yè)務(wù),主要由網(wǎng)絡(luò)管理、系統(tǒng)管理、計費、營業(yè)、賬務(wù)和客戶服務(wù)等部分組成,系統(tǒng)間通過統(tǒng)一的信息總線有機地整合在一起[5]。OSS包含用于運行和監(jiān)控網(wǎng)絡(luò)的所有系統(tǒng),如報告或計費系統(tǒng)。它是整個運營基礎(chǔ)結(jié)構(gòu),是業(yè)務(wù)開展和運營時所必須的支撐平臺,包括運營網(wǎng)絡(luò)系統(tǒng)和客戶服務(wù)系統(tǒng)。BSS負(fù)責(zé)客戶支持,提供和滿足客戶需求。
本文所述的數(shù)字電視融合業(yè)務(wù)互聯(lián)網(wǎng)門戶是基于BOSS系統(tǒng)建立起來的一套廣電與通信融合的業(yè)務(wù)支撐平臺,用戶可利用Web服務(wù)進行節(jié)目互動參與,并且利用輕量級的支付模塊,實現(xiàn)充值付費業(yè)務(wù)。普通Web門戶訪問流穩(wěn)定,不易出現(xiàn)波動,而由于數(shù)字電視融合業(yè)務(wù)互聯(lián)網(wǎng)門戶的上述功能特點,預(yù)計會在每月月初或月末因辦理充值付費業(yè)務(wù)人數(shù)較多出現(xiàn)突發(fā)的流量峰值。正因如此,數(shù)字電視融合業(yè)務(wù)互聯(lián)網(wǎng)門戶的壓力測試研究更為重要緊迫。
壓力測試是性能測試中的一個重要方面。它是通過逐步增加訪問系統(tǒng)的線程數(shù),觀察測試系統(tǒng)性能變化,確定系統(tǒng)所能承受的壓力。通過壓力測試往往能找到其他測試方法難以發(fā)現(xiàn)的錯誤,例如內(nèi)存泄漏、并發(fā)與同步的問題。因此利用壓力測試可以有效地測服務(wù)器的運行狀態(tài)和響應(yīng)時間等。國外的壓力測試技術(shù)經(jīng)過十幾年的發(fā)展已突飛猛進,但是在國內(nèi)實施壓力測試的時候,存在以下問題[6]:
1)壓力測試工具有待改善
目前國內(nèi)現(xiàn)有的壓力測試工具收費較高,測試人員難以接觸優(yōu)秀的測試工具,即使接觸到了也是一些試用版,易得、易用的測試工具較少。另外,這些測試工具界面簡單,需要開發(fā)更好的人機交互以方便操作以及自動化執(zhí)行。
2)測試結(jié)果缺少分析
在一個項目中,開發(fā)團隊與測試團隊往往是分離的,測試人員不能充分了解程序的內(nèi)部結(jié)構(gòu),尤其是BOSS系統(tǒng)較普通Web系統(tǒng)更為復(fù)雜,再加上與開發(fā)人員缺乏溝通,即使測試人員使用測試工具發(fā)現(xiàn)了性能參數(shù)所存在的問題,也難以分析測試結(jié)果以改善系統(tǒng)性能。
3)缺少專門的培訓(xùn)機會
雖然測試工作近幾年在國內(nèi)逐漸增多,但測試仍被認(rèn)為是一個項目的補充工作。測試人員多為自學(xué),缺乏系統(tǒng)的培訓(xùn)自動化測試工具的機會。社會上的不重視也嚴(yán)重影響測試人員的積極性,這一些也使得測試工作發(fā)展緩慢。
在針對BOSS系統(tǒng)的測試方面,問題尤為突出。BOSS系統(tǒng)自身復(fù)雜,開發(fā)周期長,能夠給予測試的時間較短,因此BOSS系統(tǒng)的測試總是在較為緊急的情況下完成。另外,BOSS系統(tǒng)的客戶服務(wù)子系統(tǒng)所有的業(yè)務(wù)模塊都基于Web應(yīng)用。測試人員通過Web頁面按照業(yè)務(wù)流程依次進行操作,測試業(yè)務(wù)模塊是否按照業(yè)務(wù)需求正確完成各種業(yè)務(wù)請求。整個過程都采用手工測試,測試人員往往需要在一個業(yè)務(wù)界面上進行多次重復(fù)地操作,測試工作量大[7]。基于上述實際情況,目前迫切需要一種適合BOSS系統(tǒng)測試的自動化測試工具,用以減少工作量,提高測試效率和效果。
主流壓力測試工具有WAST,LoadRunner,Webload,QALoad等 。 WAST(Microsoft Web Application Stress Tool)是由微軟測試人員所開發(fā),專門用來進行實際網(wǎng)站壓力測試的一套工具[5],它提供了一種簡便的方法模擬大量用戶訪問目標(biāo)網(wǎng)站,并在測試結(jié)束后提供詳細的性能參數(shù)文檔。
與其他測試工具相比,WAST具有以下主要特點:
1)WAST可以免費下載使用,并且簡單易操作,人機界面友好。
2)有多種不同的方式建立測試腳本:手動、錄制瀏覽器操作步驟、直接錄入IIS的記錄文件、錄入網(wǎng)站的內(nèi)容及錄入其他測試程序的指令等方式。
3)可以設(shè)置隨機延遲(思考時間),以更接近真實環(huán)境的方式進行測試。
4)支持帶寬調(diào)節(jié)以更真實地模擬顯示情形。
5)設(shè)置Page group以調(diào)整客戶組訪問的合理分配。
另外,WAST可以通過一臺或多臺客戶機模擬大量用戶訪問Web網(wǎng)站的活動。WAST支持身份驗證、加密、Cookies,也能夠模擬各種瀏覽器類型和Modem速度。使用WAST時,為了更加接近真實的情況進行負(fù)載測試,通常推薦運行WAST的測試機和Web服務(wù)器分開。
由于項目工作需要,對一臺Web服務(wù)器上的系統(tǒng)進行測試作為實例。這里給出兩臺機器的配置。一臺作為服務(wù)器,其基本配置為:Intelxeon(R)E335@2.00 GHz、4 Gbyte內(nèi)存,操作系統(tǒng)為Windows Server2003。
另一臺為測試客戶端,其基本配置為:Intel(R)Core(TM)i3-2310M CPU@2.10 GHz雙核處理器,操作系統(tǒng)為Windows7,內(nèi)存2 Gbyte,瀏覽器為IE 8.0。校園網(wǎng)內(nèi)網(wǎng)使用WAST測試。
安裝WAST后,運行該軟件。此處彈出窗口為4種錄制腳本方式:手動錄制、記錄瀏覽器活動、導(dǎo)入IIS日志、導(dǎo)入網(wǎng)站內(nèi)容文件。最常使用的方法為記錄瀏覽器活動,這種方法簡便且易于生成較真實的錄制腳本。當(dāng)然在開始錄制之前,要清除IE的緩沖區(qū)以保證錄制腳本的準(zhǔn)確度。選擇IE瀏覽器工具的Internet選項,點擊常規(guī)標(biāo)簽中的刪除文件按鈕即可完成這一步。
點擊Record之后,出現(xiàn)界面選取需要記錄內(nèi)容的界面。其中包括請求之間的延遲以及用戶會話的內(nèi)容。一般用戶在訪問系統(tǒng)時,請求之間會產(chǎn)生延遲,即用戶的思考時間等,選擇該項可以模擬真實場景中用戶的操作,如果不選擇,將加大服務(wù)器測試的壓力,從而發(fā)現(xiàn)Web應(yīng)用程序的承受極限。這里測試人員可以根據(jù)自己的需要作出取舍。
選擇之后進入第二步,點擊Finish,即可開始錄制腳本。系統(tǒng)會自動彈出默認(rèn)瀏覽器窗口,如果要利用IE瀏覽器進行錄制,需提前將IE瀏覽器設(shè)置為默認(rèn)瀏覽器。在瀏覽器的地址欄輸入需要測試的網(wǎng)址,模擬真實用戶進行一些常規(guī)操作,包括點擊頁面、登陸、提交表單等操作。
操作完成后,關(guān)閉瀏覽器,返回查看WAST。點擊Stop Recording,WAST即停止錄制腳本文件(見圖1)。

在左邊欄點擊New Recorded Script,即可查看剛剛錄制的腳本文件。在腳本文件中刪除無用的鏈接,包括圖片鏈接、無效鏈接、空白、重復(fù)腳本、延遲數(shù)過大或過小的腳本等。
刪除后,在上方Server欄添加服務(wù)器的IP地址。若選擇本機作為服務(wù)器,IP地址即為Localhost(見圖2)。
如果服務(wù)器和客戶端選用的是同一臺機器,測試過程會對客戶端產(chǎn)生很大的壓力,從而影響最后的測試結(jié)果,因此不建議在一臺機器上做壓力測試。
點擊New Recorded Script前方的加號,開始進行負(fù)載參數(shù)的設(shè)置,如圖3所示。由于服務(wù)器與客戶端是分開的,第一項Content Tree不需要進行設(shè)置。點擊Setting,開始負(fù)載選項設(shè)置。其中一些重要參數(shù)說明如下:
1)Current Connections:通過這一選項來設(shè)置訪問服務(wù)器并發(fā)連接的數(shù)量。其關(guān)系如下:

總并發(fā)請求數(shù)=總的Socket數(shù)=Stress Level(threads)*Stress multiplier
2)Test Run Time:設(shè)置測試時間,選擇常規(guī)的10 min。有一些大型測試為測試服務(wù)器的穩(wěn)定性,會將測試時間定為一個月之久。
3)Request Delay:請求隨機延遲。由于已經(jīng)在錄制腳本時錄制了延遲時間,這一項就不做設(shè)置。
4)Suspend:WAS 允許設(shè)置 Warmup Time(熱身時間)和Cooldown Time。Warmup Time是為了給服務(wù)器數(shù)據(jù)庫、磁盤緩沖等一個準(zhǔn)備時間。Warmup Time在正式測試時間之前執(zhí)行,而Cooldown Time在測試時間之后執(zhí)行。這兩段時間內(nèi)WAST執(zhí)行腳本,但并不記錄數(shù)據(jù)。一般將這兩段時間設(shè)置為30 s~1 min,本文將其都設(shè)置為30 s。
其余設(shè)置均保留缺省值。
Page Groups選項:用于設(shè)置用戶訪問Web應(yīng)用流量的比例分布,不同頁面受到用戶的點擊頻率不同。如圖4所示,這里設(shè)置的用戶組比例為1∶2∶4∶5∶7。點擊腳本頁面在Group欄設(shè)置不同分組信息。

Users:WAST允許設(shè)置不同用戶,可以添加用戶名和密碼,方便訪問頁面。
Clients:設(shè)置不同客戶端。本文中測試只需一臺客戶機,如要添加其他客戶端輸入IP地址即可,但要保證添加的客戶端已安裝WAST軟件且能正常運行。
Cookies:軟件自動保存用戶設(shè)置的Cookies,不用測試人員設(shè)置。
以上設(shè)置完成后,返回腳本頁面,點擊灰色三角按鈕即可開始運行測試。此時可在服務(wù)器端查看任務(wù)管理器中的性能,如圖5所示。CPU使用率是關(guān)注重點,一般要求在最大壓力情況下應(yīng)保證CPU使用率穩(wěn)定在70%左右,過高則系統(tǒng)性能不穩(wěn)定。在服務(wù)器端機器的運行中輸入netstat–an,可以查看客戶機向服務(wù)器發(fā)出的連接請求情況,如圖6所示。

測試完成之后,點擊view選單中的reports按鈕,可以查看系統(tǒng)自動生成的測試報告。下面對幾個重要部分作具體分析。
首先通過圖7,可以查看本次測試的基本信息,包括測試名字、測試時長、測試客戶機數(shù)。另外,全部點擊數(shù)為17 767,每秒請求數(shù)為29.61。

在測試報告中最重要的部分就是Socket Errors(請求錯誤,見圖8)和Result Codes(結(jié)果代碼,見圖9)。

在Socket Errors中,4個數(shù)值分別為:
1)Connect表示客戶端不能與服務(wù)器取得連接的次數(shù);
2)Send表示客戶端不能正確發(fā)送數(shù)據(jù)到服務(wù)器的次數(shù);
3)Recv表示客戶端不能正確從服務(wù)器接收的次數(shù);
4)Timeouts表示超時的線程數(shù)目。
如果這4個數(shù)值都比較小,甚至為0,則說明服務(wù)器是經(jīng)得起考驗的;如果數(shù)值居高不下,甚至接近設(shè)置的并發(fā)數(shù),那么服務(wù)器就需要進一步的檢查。這些數(shù)據(jù)也可以作為是否增加進程數(shù)繼續(xù)測試的標(biāo)準(zhǔn)之一。
圖9為Result Codes部分,如果Code列表下的數(shù)值都為200,那么表示所有請求都經(jīng)服務(wù)器成功返回;如果數(shù)值出現(xiàn)400或400以上,如404,那么則需要在左側(cè)找到“Page Data”節(jié)點,查看具體的錯誤項目。在這里,測試結(jié)果出現(xiàn)了404的錯誤提示,查看“Page Data”節(jié)點,發(fā)現(xiàn)404錯誤均出現(xiàn)在重復(fù)的check_outchain.php當(dāng)中,檢查此鏈接,發(fā)現(xiàn)此鏈接為某軟件生成的與本測試系統(tǒng)無關(guān)的錯誤鏈接,導(dǎo)致腳本錯誤。經(jīng)過檢查之后重新測試,就會得到更準(zhǔn)確的結(jié)果。
圖10為Page Summary部分,在這一部分可以查看每一個鏈接的點擊數(shù)。另外兩個參數(shù)分別為:
1)TTFB Avg:從第一個請求發(fā)出到測試工具接收到服務(wù)器應(yīng)答數(shù)據(jù)的第一個字節(jié)之間的平均時間。

2)TTLB Avg:從第一個請求發(fā)出到測試工具接收到服務(wù)器應(yīng)答數(shù)據(jù)的最后一個字節(jié)之間的平均時間。
在用戶訪問頁面時,并不是頁面可以打開、瀏覽器不會崩潰就是合格的指標(biāo),如果用戶在頁面打開的過程中等待時間過長,這也是不合格的。在測試報告的Page Data中可以看到如圖11的數(shù)據(jù)表,由表中可以分析,此頁面的平均響應(yīng)時間為0.9 s,最快反應(yīng)時間為0.6 s,最長反應(yīng)時間為3.8 s,同樣在其他頁面數(shù)據(jù)記錄表中也可以看到它們的反應(yīng)時間。如果反應(yīng)時間均在5 s以內(nèi),則測試結(jié)果還是可以接受的。

上述測試只是壓力測試的一小部分,通常為了發(fā)現(xiàn)系統(tǒng)所能承受的最大線程數(shù),需要逐步增加或減少線程數(shù),觀察測試結(jié)果中性能參數(shù)的變化。在性能參數(shù)出現(xiàn)大的問題的邊緣數(shù)處,要減小線程數(shù)的增幅,以細致觀察系統(tǒng)能夠承受的最大壓力。
本系統(tǒng)之后的測試以200進程數(shù)為增量,當(dāng)進程數(shù)由800增加到1 000的時候,與服務(wù)器的連接出現(xiàn)連接失敗的情況,則減小測試進程增量,變?yōu)?00,由900進程數(shù)開始測量,可以看到一直到進程數(shù)增加到940時,再次出現(xiàn)訪問服務(wù)器連接失敗的情況,再改變進程數(shù)增量,直到進程數(shù)增加到935時,訪問服務(wù)器正常,當(dāng)進程數(shù)增加為936時,出現(xiàn)連接服務(wù)器失敗的情況。并且在935進程數(shù)時,頁面響應(yīng)時間最長平均訪問時間為5.8 s,其他頁面的平均訪問時間也在5 s以下,服務(wù)器端的CPU使用率也在30%~40%之間較為平穩(wěn)。因此可以判斷,此次Web壓力測試的結(jié)果為935進程數(shù)。
對于一般的系統(tǒng)而言,服務(wù)器承載的進程訪問量在600~700之間,最高可達到800左右,當(dāng)壓力測試過程中,設(shè)置進程數(shù)為1 000時,服務(wù)器基本處于崩潰狀態(tài),且CPU使用率將高達100%峰值,而本系統(tǒng)服務(wù)器所能承載的進程訪問量已經(jīng)超出這個范圍且各參數(shù)在可以接受的范圍內(nèi),具有較好的系統(tǒng)性能,即可以滿足用戶的正常以及超負(fù)荷使用。
雖然使用WAST測試簡單,測試結(jié)果分析方便,但是它還是存在一些缺陷。其中一個很重要的方面就是,目前使用的測試工具都是黑盒測試,測試人員不能了解其中的算法流程,使用不同的測試工具得出的結(jié)果肯定也是不盡相同,測試工具自身的穩(wěn)定性也無處得知。因此,壓力測試工具的改善還是很值得期待的。
本文對BOSS系統(tǒng)架構(gòu)下數(shù)字電視融合業(yè)務(wù)互聯(lián)網(wǎng)門戶的壓力測試的重要性進行了闡釋,并進行了較為詳盡的壓力測試步驟以及結(jié)果分析。另外,在BOSS系統(tǒng)測試領(lǐng)域,除了壓力測試,還有BOSS系統(tǒng)測試框架的研究、用戶體驗研究、對象模型研究等,這些都將是未來一段時間內(nèi)的研究重點。
:
[1]王簫笛.基于數(shù)字電視平臺BOSS系統(tǒng)的應(yīng)用[J].中國數(shù)字電視,2011(12):52-54.
[2]曹三省,劉劍波,蔣青苗,等.互動新媒體業(yè)務(wù)生成系統(tǒng)技術(shù)框架與關(guān)鍵策略[J].電視技術(shù),2008,32(11):61-63.
[3]鄒林輝.廣電BOSS架構(gòu)與關(guān)鍵技術(shù)探討[J].電視技術(shù),2010,34(7):82-85.
[4]呂廷杰,楊寧,吳海軍,等.電信運營支撐系統(tǒng)OSS——理論、策略與實踐[M].北京:人民郵電出版社,2003.
[5]周丹.IPTV業(yè)務(wù)運營支撐系統(tǒng)(BOSS)的測試方法研究與實施[D].北京:北京郵電大學(xué),2009.
[6]吳為根.基于Web的壓力測試[D].上海:復(fù)旦大學(xué),2006.
[7]施衛(wèi)娟,竇如林.基于WAST的Web網(wǎng)站壓力測試[J].電腦知識與技術(shù),2008,3(23):888-890.