數字電視融合業務互聯網門戶的壓力測試研究

于鑒桐，曹三省

（中國傳媒大學，北京 100024）

近年來，為了提高經營管理和服務水平，及適應新業務發展的需求，有線運營商開始采用先進的信息管理技術來提高自身競爭力，構建自己的運營支撐系統框架和模式，在此基礎上，BOSS系統應運而生[1]。同時由于數字電視融合業務互聯網門戶的獨特性，人們對BOSS系統性能的要求越來越高。系統常常是大量終端用戶同時訪問，無論是從人員、技術上，還是從時間、資源上，性能測試的挑戰也越來越大，從而無法預測多用戶并發時應用系統的運行情況。性能測試的難點就在于如何仿真和模擬成千上萬的真實用戶并發對服務器造成的壓力情況、如何監控和統計服務器端的性能變化、如何從千差萬別的測試數據中分析并獲取有效的測試結果。傳統的簡單的手工測試已經不能有效滿足壓力測試的需求，因此必須借助于自動化工具來完成[2]。

1 概述

1.1 數字電視融合業務互聯網門戶概述

業務運營支撐系統（BOSS，Business Operation Support System）[3-4]融合了BSS（業務支撐系統，Business Support Systems）與 OSS（運營支撐系統，Operation Support Systems），是一個綜合的業務運營和管理平臺，它融合了傳統數據業務與增值業務，主要由網絡管理、系統管理、計費、營業、賬務和客戶服務等部分組成，系統間通過統一的信息總線有機地整合在一起[5]。OSS包含用于運行和監控網絡的所有系統，如報告或計費系統。它是整個運營基礎結構，是業務開展和運營時所必須的支撐平臺，包括運營網絡系統和客戶服務系統。BSS負責客戶支持，提供和滿足客戶需求。

本文所述的數字電視融合業務互聯網門戶是基于BOSS系統建立起來的一套廣電與通信融合的業務支撐平臺，用戶可利用Web服務進行節目互動參與，并且利用輕量級的支付模塊，實現充值付費業務。普通Web門戶訪問流穩定，不易出現波動，而由于數字電視融合業務互聯網門戶的上述功能特點，預計會在每月月初或月末因辦理充值付費業務人數較多出現突發的流量峰值。正因如此，數字電視融合業務互聯網門戶的壓力測試研究更為重要緊迫。

1.2 壓力測試方法概述

壓力測試是性能測試中的一個重要方面。它是通過逐步增加訪問系統的線程數，觀察測試系統性能變化，確定系統所能承受的壓力。通過壓力測試往往能找到其他測試方法難以發現的錯誤，例如內存泄漏、并發與同步的問題。因此利用壓力測試可以有效地測服務器的運行狀態和響應時間等。國外的壓力測試技術經過十幾年的發展已突飛猛進，但是在國內實施壓力測試的時候，存在以下問題[6]：

1）壓力測試工具有待改善

目前國內現有的壓力測試工具收費較高，測試人員難以接觸優秀的測試工具，即使接觸到了也是一些試用版，易得、易用的測試工具較少。另外，這些測試工具界面簡單，需要開發更好的人機交互以方便操作以及自動化執行。

2）測試結果缺少分析

在一個項目中，開發團隊與測試團隊往往是分離的，測試人員不能充分了解程序的內部結構，尤其是BOSS系統較普通Web系統更為復雜，再加上與開發人員缺乏溝通，即使測試人員使用測試工具發現了性能參數所存在的問題，也難以分析測試結果以改善系統性能。

3）缺少專門的培訓機會

雖然測試工作近幾年在國內逐漸增多，但測試仍被認為是一個項目的補充工作。測試人員多為自學，缺乏系統的培訓自動化測試工具的機會。社會上的不重視也嚴重影響測試人員的積極性，這一些也使得測試工作發展緩慢。

在針對BOSS系統的測試方面，問題尤為突出。BOSS系統自身復雜，開發周期長，能夠給予測試的時間較短，因此BOSS系統的測試總是在較為緊急的情況下完成。另外，BOSS系統的客戶服務子系統所有的業務模塊都基于Web應用。測試人員通過Web頁面按照業務流程依次進行操作，測試業務模塊是否按照業務需求正確完成各種業務請求。整個過程都采用手工測試，測試人員往往需要在一個業務界面上進行多次重復地操作，測試工作量大[7]。基于上述實際情況，目前迫切需要一種適合BOSS系統測試的自動化測試工具，用以減少工作量，提高測試效率和效果。

2 壓力測試方法及實例

2.1 WAST工具簡介

主流壓力測試工具有WAST，LoadRunner，Webload，QALoad等 。 WAST（Microsoft Web Application Stress Tool）是由微軟測試人員所開發，專門用來進行實際網站壓力測試的一套工具[5]，它提供了一種簡便的方法模擬大量用戶訪問目標網站，并在測試結束后提供詳細的性能參數文檔。

與其他測試工具相比，WAST具有以下主要特點：

1）WAST可以免費下載使用，并且簡單易操作，人機界面友好。

2）有多種不同的方式建立測試腳本：手動、錄制瀏覽器操作步驟、直接錄入IIS的記錄文件、錄入網站的內容及錄入其他測試程序的指令等方式。

3）可以設置隨機延遲（思考時間），以更接近真實環境的方式進行測試。

4）支持帶寬調節以更真實地模擬顯示情形。

5）設置Page group以調整客戶組訪問的合理分配。

另外，WAST可以通過一臺或多臺客戶機模擬大量用戶訪問Web網站的活動。WAST支持身份驗證、加密、Cookies，也能夠模擬各種瀏覽器類型和Modem速度。使用WAST時，為了更加接近真實的情況進行負載測試，通常推薦運行WAST的測試機和Web服務器分開。

2.2 測試環境

由于項目工作需要，對一臺Web服務器上的系統進行測試作為實例。這里給出兩臺機器的配置。一臺作為服務器，其基本配置為：Intelxeon（R）E335@2.00 GHz、4 Gbyte內存，操作系統為Windows Server2003。

另一臺為測試客戶端，其基本配置為：Intel（R）Core（TM）i3-2310M CPU@2.10 GHz雙核處理器，操作系統為Windows7，內存2 Gbyte，瀏覽器為IE 8.0。校園網內網使用WAST測試。

2.3 測試條件及參數設置

安裝WAST后，運行該軟件。此處彈出窗口為4種錄制腳本方式：手動錄制、記錄瀏覽器活動、導入IIS日志、導入網站內容文件。最常使用的方法為記錄瀏覽器活動，這種方法簡便且易于生成較真實的錄制腳本。當然在開始錄制之前，要清除IE的緩沖區以保證錄制腳本的準確度。選擇IE瀏覽器工具的Internet選項，點擊常規標簽中的刪除文件按鈕即可完成這一步。

點擊Record之后，出現界面選取需要記錄內容的界面。其中包括請求之間的延遲以及用戶會話的內容。一般用戶在訪問系統時，請求之間會產生延遲，即用戶的思考時間等，選擇該項可以模擬真實場景中用戶的操作，如果不選擇，將加大服務器測試的壓力，從而發現Web應用程序的承受極限。這里測試人員可以根據自己的需要作出取舍。

選擇之后進入第二步，點擊Finish，即可開始錄制腳本。系統會自動彈出默認瀏覽器窗口，如果要利用IE瀏覽器進行錄制，需提前將IE瀏覽器設置為默認瀏覽器。在瀏覽器的地址欄輸入需要測試的網址，模擬真實用戶進行一些常規操作，包括點擊頁面、登陸、提交表單等操作。

操作完成后，關閉瀏覽器，返回查看WAST。點擊Stop Recording，WAST即停止錄制腳本文件（見圖1）。

在左邊欄點擊New Recorded Script，即可查看剛剛錄制的腳本文件。在腳本文件中刪除無用的鏈接，包括圖片鏈接、無效鏈接、空白、重復腳本、延遲數過大或過小的腳本等。

刪除后，在上方Server欄添加服務器的IP地址。若選擇本機作為服務器，IP地址即為Localhost（見圖2）。

如果服務器和客戶端選用的是同一臺機器，測試過程會對客戶端產生很大的壓力，從而影響最后的測試結果，因此不建議在一臺機器上做壓力測試。

點擊New Recorded Script前方的加號，開始進行負載參數的設置，如圖3所示。由于服務器與客戶端是分開的，第一項Content Tree不需要進行設置。點擊Setting，開始負載選項設置。其中一些重要參數說明如下：

1）Current Connections：通過這一選項來設置訪問服務器并發連接的數量。其關系如下：

總并發請求數=總的Socket數=Stress Level（threads）*Stress multiplier

2）Test Run Time：設置測試時間，選擇常規的10 min。有一些大型測試為測試服務器的穩定性，會將測試時間定為一個月之久。

3）Request Delay：請求隨機延遲。由于已經在錄制腳本時錄制了延遲時間，這一項就不做設置。

4）Suspend：WAS 允許設置 Warmup Time（熱身時間）和Cooldown Time。Warmup Time是為了給服務器數據庫、磁盤緩沖等一個準備時間。Warmup Time在正式測試時間之前執行，而Cooldown Time在測試時間之后執行。這兩段時間內WAST執行腳本，但并不記錄數據。一般將這兩段時間設置為30 s～1 min，本文將其都設置為30 s。

其余設置均保留缺省值。

Page Groups選項：用于設置用戶訪問Web應用流量的比例分布，不同頁面受到用戶的點擊頻率不同。如圖4所示，這里設置的用戶組比例為1∶2∶4∶5∶7。點擊腳本頁面在Group欄設置不同分組信息。

Users：WAST允許設置不同用戶，可以添加用戶名和密碼，方便訪問頁面。

Clients：設置不同客戶端。本文中測試只需一臺客戶機，如要添加其他客戶端輸入IP地址即可，但要保證添加的客戶端已安裝WAST軟件且能正常運行。

Cookies：軟件自動保存用戶設置的Cookies，不用測試人員設置。

2.4 壓力測試過程

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

3 測試結果及分析

測試完成之后，點擊view選單中的reports按鈕，可以查看系統自動生成的測試報告。下面對幾個重要部分作具體分析。

首先通過圖7，可以查看本次測試的基本信息，包括測試名字、測試時長、測試客戶機數。另外，全部點擊數為17 767，每秒請求數為29.61。

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

在Socket Errors中，4個數值分別為：

1）Connect表示客戶端不能與服務器取得連接的次數；

2）Send表示客戶端不能正確發送數據到服務器的次數；

3）Recv表示客戶端不能正確從服務器接收的次數；

4）Timeouts表示超時的線程數目。

如果這4個數值都比較小，甚至為0，則說明服務器是經得起考驗的；如果數值居高不下，甚至接近設置的并發數，那么服務器就需要進一步的檢查。這些數據也可以作為是否增加進程數繼續測試的標準之一。

圖9為Result Codes部分，如果Code列表下的數值都為200，那么表示所有請求都經服務器成功返回；如果數值出現400或400以上，如404，那么則需要在左側找到“Page Data”節點，查看具體的錯誤項目。在這里，測試結果出現了404的錯誤提示，查看“Page Data”節點，發現404錯誤均出現在重復的check_outchain.php當中，檢查此鏈接，發現此鏈接為某軟件生成的與本測試系統無關的錯誤鏈接，導致腳本錯誤。經過檢查之后重新測試，就會得到更準確的結果。

圖10為Page Summary部分，在這一部分可以查看每一個鏈接的點擊數。另外兩個參數分別為：

1）TTFB Avg：從第一個請求發出到測試工具接收到服務器應答數據的第一個字節之間的平均時間。

2）TTLB Avg：從第一個請求發出到測試工具接收到服務器應答數據的最后一個字節之間的平均時間。

在用戶訪問頁面時，并不是頁面可以打開、瀏覽器不會崩潰就是合格的指標，如果用戶在頁面打開的過程中等待時間過長，這也是不合格的。在測試報告的Page Data中可以看到如圖11的數據表，由表中可以分析，此頁面的平均響應時間為0.9 s，最快反應時間為0.6 s，最長反應時間為3.8 s，同樣在其他頁面數據記錄表中也可以看到它們的反應時間。如果反應時間均在5 s以內，則測試結果還是可以接受的。

上述測試只是壓力測試的一小部分，通常為了發現系統所能承受的最大線程數，需要逐步增加或減少線程數，觀察測試結果中性能參數的變化。在性能參數出現大的問題的邊緣數處，要減小線程數的增幅，以細致觀察系統能夠承受的最大壓力。

本系統之后的測試以200進程數為增量，當進程數由800增加到1 000的時候，與服務器的連接出現連接失敗的情況，則減小測試進程增量，變為100，由900進程數開始測量，可以看到一直到進程數增加到940時，再次出現訪問服務器連接失敗的情況，再改變進程數增量，直到進程數增加到935時，訪問服務器正常，當進程數增加為936時，出現連接服務器失敗的情況。并且在935進程數時，頁面響應時間最長平均訪問時間為5.8 s，其他頁面的平均訪問時間也在5 s以下，服務器端的CPU使用率也在30%～40%之間較為平穩。因此可以判斷，此次Web壓力測試的結果為935進程數。

對于一般的系統而言，服務器承載的進程訪問量在600～700之間，最高可達到800左右，當壓力測試過程中，設置進程數為1 000時，服務器基本處于崩潰狀態，且CPU使用率將高達100%峰值，而本系統服務器所能承載的進程訪問量已經超出這個范圍且各參數在可以接受的范圍內，具有較好的系統性能，即可以滿足用戶的正常以及超負荷使用。

4 總結

雖然使用WAST測試簡單，測試結果分析方便，但是它還是存在一些缺陷。其中一個很重要的方面就是，目前使用的測試工具都是黑盒測試，測試人員不能了解其中的算法流程，使用不同的測試工具得出的結果肯定也是不盡相同，測試工具自身的穩定性也無處得知。因此，壓力測試工具的改善還是很值得期待的。

本文對BOSS系統架構下數字電視融合業務互聯網門戶的壓力測試的重要性進行了闡釋，并進行了較為詳盡的壓力測試步驟以及結果分析。另外，在BOSS系統測試領域，除了壓力測試，還有BOSS系統測試框架的研究、用戶體驗研究、對象模型研究等，這些都將是未來一段時間內的研究重點。

：

[1]王簫笛.基于數字電視平臺BOSS系統的應用[J].中國數字電視，2011（12）：52-54.

[2]曹三省，劉劍波，蔣青苗，等.互動新媒體業務生成系統技術框架與關鍵策略[J].電視技術，2008，32（11）：61-63.

[3]鄒林輝.廣電BOSS架構與關鍵技術探討[J].電視技術，2010，34（7）：82-85.

[4]呂廷杰，楊寧，吳海軍，等.電信運營支撐系統OSS——理論、策略與實踐[M].北京：人民郵電出版社，2003.

[5]周丹.IPTV業務運營支撐系統（BOSS）的測試方法研究與實施[D].北京：北京郵電大學，2009.

[6]吳為根.基于Web的壓力測試[D].上海：復旦大學，2006.

[7]施衛娟，竇如林.基于WAST的Web網站壓力測試[J].電腦知識與技術，2008，3（23）：888-890.