數(shù)字電視融合業(yè)務(wù)互聯(lián)網(wǎng)門戶的壓力測試研究

于鑒桐，曹三省

（中國傳媒大學(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]。

1 概述

1.1 數(shù)字電視融合業(yè)務(wù)互聯(lián)網(wǎng)門戶概述

業(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)門戶的壓力測試研究更為重要緊迫。

1.2 壓力測試方法概述

壓力測試是性能測試中的一個重要方面。它是通過逐步增加訪問系統(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)測試的自動化測試工具，用以減少工作量，提高測試效率和效果。

2 壓力測試方法及實例

2.1 WAST工具簡介

主流壓力測試工具有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ù)器分開。

2.2 測試環(huán)境

由于項目工作需要，對一臺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測試。

2.3 測試條件及參數(shù)設(shè)置

安裝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è)置。

2.4 壓力測試過程

以上設(shè)置完成后，返回腳本頁面，點擊灰色三角按鈕即可開始運行測試。此時可在服務(wù)器端查看任務(wù)管理器中的性能，如圖5所示。CPU使用率是關(guān)注重點，一般要求在最大壓力情況下應(yīng)保證CPU使用率穩(wěn)定在70%左右，過高則系統(tǒng)性能不穩(wěn)定。在服務(wù)器端機器的運行中輸入netstat–an，可以查看客戶機向服務(wù)器發(fā)出的連接請求情況，如圖6所示。

3 測試結(jié)果及分析

測試完成之后，點擊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ù)荷使用。

4 總結(jié)

雖然使用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.