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

于鑒桐，曹三省

（中國傳媒大學(xué)，北京 100024）

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

1 概述

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

業(yè)務(wù)運(yùn)營支撐系統(tǒng)（BOSS，Business Operation Support System）[3-4]融合了BSS（業(yè)務(wù)支撐系統(tǒng)，Business Support Systems）與 OSS（運(yùn)營支撐系統(tǒng)，Operation Support Systems），是一個(gè)綜合的業(yè)務(wù)運(yùn)營和管理平臺(tái)，它融合了傳統(tǒng)數(shù)據(jù)業(yè)務(wù)與增值業(yè)務(wù)，主要由網(wǎng)絡(luò)管理、系統(tǒng)管理、計(jì)費(fèi)、營業(yè)、賬務(wù)和客戶服務(wù)等部分組成，系統(tǒng)間通過統(tǒng)一的信息總線有機(jī)地整合在一起[5]。OSS包含用于運(yùn)行和監(jiān)控網(wǎng)絡(luò)的所有系統(tǒng)，如報(bào)告或計(jì)費(fèi)系統(tǒng)。它是整個(gè)運(yùn)營基礎(chǔ)結(jié)構(gòu)，是業(yè)務(wù)開展和運(yùn)營時(shí)所必須的支撐平臺(tái)，包括運(yùn)營網(wǎng)絡(luò)系統(tǒng)和客戶服務(wù)系統(tǒng)。BSS負(fù)責(zé)客戶支持，提供和滿足客戶需求。

本文所述的數(shù)字電視融合業(yè)務(wù)互聯(lián)網(wǎng)門戶是基于BOSS系統(tǒng)建立起來的一套廣電與通信融合的業(yè)務(wù)支撐平臺(tái)，用戶可利用Web服務(wù)進(jìn)行節(jié)目互動(dòng)參與，并且利用輕量級(jí)的支付模塊，實(shí)現(xiàn)充值付費(fèi)業(yè)務(wù)。普通Web門戶訪問流穩(wěn)定，不易出現(xiàn)波動(dòng)，而由于數(shù)字電視融合業(yè)務(wù)互聯(lián)網(wǎng)門戶的上述功能特點(diǎn)，預(yù)計(jì)會(huì)在每月月初或月末因辦理充值付費(fèi)業(yè)務(wù)人數(shù)較多出現(xiàn)突發(fā)的流量峰值。正因如此，數(shù)字電視融合業(yè)務(wù)互聯(lián)網(wǎng)門戶的壓力測(cè)試研究更為重要緊迫。

1.2 壓力測(cè)試方法概述

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

1）壓力測(cè)試工具有待改善

目前國內(nèi)現(xiàn)有的壓力測(cè)試工具收費(fèi)較高，測(cè)試人員難以接觸優(yōu)秀的測(cè)試工具，即使接觸到了也是一些試用版，易得、易用的測(cè)試工具較少。另外，這些測(cè)試工具界面簡單，需要開發(fā)更好的人機(jī)交互以方便操作以及自動(dòng)化執(zhí)行。

2）測(cè)試結(jié)果缺少分析

在一個(gè)項(xiàng)目中，開發(fā)團(tuán)隊(duì)與測(cè)試團(tuán)隊(duì)往往是分離的，測(cè)試人員不能充分了解程序的內(nèi)部結(jié)構(gòu)，尤其是BOSS系統(tǒng)較普通Web系統(tǒng)更為復(fù)雜，再加上與開發(fā)人員缺乏溝通，即使測(cè)試人員使用測(cè)試工具發(fā)現(xiàn)了性能參數(shù)所存在的問題，也難以分析測(cè)試結(jié)果以改善系統(tǒng)性能。

3）缺少專門的培訓(xùn)機(jī)會(huì)

雖然測(cè)試工作近幾年在國內(nèi)逐漸增多，但測(cè)試仍被認(rèn)為是一個(gè)項(xiàng)目的補(bǔ)充工作。測(cè)試人員多為自學(xué)，缺乏系統(tǒng)的培訓(xùn)自動(dòng)化測(cè)試工具的機(jī)會(huì)。社會(huì)上的不重視也嚴(yán)重影響測(cè)試人員的積極性，這一些也使得測(cè)試工作發(fā)展緩慢。

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

2 壓力測(cè)試方法及實(shí)例

2.1 WAST工具簡介

主流壓力測(cè)試工具有WAST，LoadRunner，Webload，QALoad等 。 WAST（Microsoft Web Application Stress Tool）是由微軟測(cè)試人員所開發(fā)，專門用來進(jìn)行實(shí)際網(wǎng)站壓力測(cè)試的一套工具[5]，它提供了一種簡便的方法模擬大量用戶訪問目標(biāo)網(wǎng)站，并在測(cè)試結(jié)束后提供詳細(xì)的性能參數(shù)文檔。

與其他測(cè)試工具相比，WAST具有以下主要特點(diǎn)：

1）WAST可以免費(fèi)下載使用，并且簡單易操作，人機(jī)界面友好。

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

3）可以設(shè)置隨機(jī)延遲（思考時(shí)間），以更接近真實(shí)環(huán)境的方式進(jìn)行測(cè)試。

4）支持帶寬調(diào)節(jié)以更真實(shí)地模擬顯示情形。

5）設(shè)置Page group以調(diào)整客戶組訪問的合理分配。

另外，WAST可以通過一臺(tái)或多臺(tái)客戶機(jī)模擬大量用戶訪問Web網(wǎng)站的活動(dòng)。WAST支持身份驗(yàn)證、加密、Cookies，也能夠模擬各種瀏覽器類型和Modem速度。使用WAST時(shí)，為了更加接近真實(shí)的情況進(jìn)行負(fù)載測(cè)試，通常推薦運(yùn)行WAST的測(cè)試機(jī)和Web服務(wù)器分開。

2.2 測(cè)試環(huán)境

由于項(xiàng)目工作需要，對(duì)一臺(tái)Web服務(wù)器上的系統(tǒng)進(jìn)行測(cè)試作為實(shí)例。這里給出兩臺(tái)機(jī)器的配置。一臺(tái)作為服務(wù)器，其基本配置為：Intelxeon（R）E335@2.00 GHz、4 Gbyte內(nèi)存，操作系統(tǒng)為Windows Server2003。

另一臺(tái)為測(cè)試客戶端，其基本配置為：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測(cè)試。

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

安裝WAST后，運(yùn)行該軟件。此處彈出窗口為4種錄制腳本方式：手動(dòng)錄制、記錄瀏覽器活動(dòng)、導(dǎo)入IIS日志、導(dǎo)入網(wǎng)站內(nèi)容文件。最常使用的方法為記錄瀏覽器活動(dòng)，這種方法簡便且易于生成較真實(shí)的錄制腳本。當(dāng)然在開始錄制之前，要清除IE的緩沖區(qū)以保證錄制腳本的準(zhǔn)確度。選擇IE瀏覽器工具的Internet選項(xiàng)，點(diǎn)擊常規(guī)標(biāo)簽中的刪除文件按鈕即可完成這一步。

點(diǎn)擊Record之后，出現(xiàn)界面選取需要記錄內(nèi)容的界面。其中包括請(qǐng)求之間的延遲以及用戶會(huì)話的內(nèi)容。一般用戶在訪問系統(tǒng)時(shí)，請(qǐng)求之間會(huì)產(chǎn)生延遲，即用戶的思考時(shí)間等，選擇該項(xiàng)可以模擬真實(shí)場景中用戶的操作，如果不選擇，將加大服務(wù)器測(cè)試的壓力，從而發(fā)現(xiàn)Web應(yīng)用程序的承受極限。這里測(cè)試人員可以根據(jù)自己的需要作出取舍。

選擇之后進(jìn)入第二步，點(diǎn)擊Finish，即可開始錄制腳本。系統(tǒng)會(huì)自動(dòng)彈出默認(rèn)瀏覽器窗口，如果要利用IE瀏覽器進(jìn)行錄制，需提前將IE瀏覽器設(shè)置為默認(rèn)瀏覽器。在瀏覽器的地址欄輸入需要測(cè)試的網(wǎng)址，模擬真實(shí)用戶進(jìn)行一些常規(guī)操作，包括點(diǎn)擊頁面、登陸、提交表單等操作。

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

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

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

如果服務(wù)器和客戶端選用的是同一臺(tái)機(jī)器，測(cè)試過程會(huì)對(duì)客戶端產(chǎn)生很大的壓力，從而影響最后的測(cè)試結(jié)果，因此不建議在一臺(tái)機(jī)器上做壓力測(cè)試。

點(diǎn)擊New Recorded Script前方的加號(hào)，開始進(jìn)行負(fù)載參數(shù)的設(shè)置，如圖3所示。由于服務(wù)器與客戶端是分開的，第一項(xiàng)Content Tree不需要進(jìn)行設(shè)置。點(diǎn)擊Setting，開始負(fù)載選項(xiàng)設(shè)置。其中一些重要參數(shù)說明如下：

1）Current Connections：通過這一選項(xiàng)來設(shè)置訪問服務(wù)器并發(fā)連接的數(shù)量。其關(guān)系如下：

總并發(fā)請(qǐng)求數(shù)=總的Socket數(shù)=Stress Level（threads）*Stress multiplier

2）Test Run Time：設(shè)置測(cè)試時(shí)間，選擇常規(guī)的10 min。有一些大型測(cè)試為測(cè)試服務(wù)器的穩(wěn)定性，會(huì)將測(cè)試時(shí)間定為一個(gè)月之久。

3）Request Delay：請(qǐng)求隨機(jī)延遲。由于已經(jīng)在錄制腳本時(shí)錄制了延遲時(shí)間，這一項(xiàng)就不做設(shè)置。

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

其余設(shè)置均保留缺省值。

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

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

Clients：設(shè)置不同客戶端。本文中測(cè)試只需一臺(tái)客戶機(jī)，如要添加其他客戶端輸入IP地址即可，但要保證添加的客戶端已安裝WAST軟件且能正常運(yùn)行。

Cookies：軟件自動(dòng)保存用戶設(shè)置的Cookies，不用測(cè)試人員設(shè)置。

2.4 壓力測(cè)試過程

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

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

測(cè)試完成之后，點(diǎn)擊view選單中的reports按鈕，可以查看系統(tǒng)自動(dòng)生成的測(cè)試報(bào)告。下面對(duì)幾個(gè)重要部分作具體分析。

首先通過圖7，可以查看本次測(cè)試的基本信息，包括測(cè)試名字、測(cè)試時(shí)長、測(cè)試客戶機(jī)數(shù)。另外，全部點(diǎn)擊數(shù)為17 767，每秒請(qǐng)求數(shù)為29.61。

在測(cè)試報(bào)告中最重要的部分就是Socket Errors（請(qǐng)求錯(cuò)誤，見圖8）和Result Codes（結(jié)果代碼，見圖9）。

在Socket Errors中，4個(gè)數(shù)值分別為：

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

2）Send表示客戶端不能正確發(fā)送數(shù)據(jù)到服務(wù)器的次數(shù)；

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

4）Timeouts表示超時(shí)的線程數(shù)目。

如果這4個(gè)數(shù)值都比較小，甚至為0，則說明服務(wù)器是經(jīng)得起考驗(yàn)的；如果數(shù)值居高不下，甚至接近設(shè)置的并發(fā)數(shù)，那么服務(wù)器就需要進(jìn)一步的檢查。這些數(shù)據(jù)也可以作為是否增加進(jìn)程數(shù)繼續(xù)測(cè)試的標(biāo)準(zhǔn)之一。

圖9為Result Codes部分，如果Code列表下的數(shù)值都為200，那么表示所有請(qǐng)求都經(jīng)服務(wù)器成功返回；如果數(shù)值出現(xiàn)400或400以上，如404，那么則需要在左側(cè)找到“Page Data”節(jié)點(diǎn)，查看具體的錯(cuò)誤項(xiàng)目。在這里，測(cè)試結(jié)果出現(xiàn)了404的錯(cuò)誤提示，查看“Page Data”節(jié)點(diǎn)，發(fā)現(xiàn)404錯(cuò)誤均出現(xiàn)在重復(fù)的check_outchain.php當(dāng)中，檢查此鏈接，發(fā)現(xiàn)此鏈接為某軟件生成的與本測(cè)試系統(tǒng)無關(guān)的錯(cuò)誤鏈接，導(dǎo)致腳本錯(cuò)誤。經(jīng)過檢查之后重新測(cè)試，就會(huì)得到更準(zhǔn)確的結(jié)果。

圖10為Page Summary部分，在這一部分可以查看每一個(gè)鏈接的點(diǎn)擊數(shù)。另外兩個(gè)參數(shù)分別為：

1）TTFB Avg：從第一個(gè)請(qǐng)求發(fā)出到測(cè)試工具接收到服務(wù)器應(yīng)答數(shù)據(jù)的第一個(gè)字節(jié)之間的平均時(shí)間。

2）TTLB Avg：從第一個(gè)請(qǐng)求發(fā)出到測(cè)試工具接收到服務(wù)器應(yīng)答數(shù)據(jù)的最后一個(gè)字節(jié)之間的平均時(shí)間。

在用戶訪問頁面時(shí)，并不是頁面可以打開、瀏覽器不會(huì)崩潰就是合格的指標(biāo)，如果用戶在頁面打開的過程中等待時(shí)間過長，這也是不合格的。在測(cè)試報(bào)告的Page Data中可以看到如圖11的數(shù)據(jù)表，由表中可以分析，此頁面的平均響應(yīng)時(shí)間為0.9 s，最快反應(yīng)時(shí)間為0.6 s，最長反應(yīng)時(shí)間為3.8 s，同樣在其他頁面數(shù)據(jù)記錄表中也可以看到它們的反應(yīng)時(shí)間。如果反應(yīng)時(shí)間均在5 s以內(nèi)，則測(cè)試結(jié)果還是可以接受的。

上述測(cè)試只是壓力測(cè)試的一小部分，通常為了發(fā)現(xiàn)系統(tǒng)所能承受的最大線程數(shù)，需要逐步增加或減少線程數(shù)，觀察測(cè)試結(jié)果中性能參數(shù)的變化。在性能參數(shù)出現(xiàn)大的問題的邊緣數(shù)處，要減小線程數(shù)的增幅，以細(xì)致觀察系統(tǒng)能夠承受的最大壓力。

本系統(tǒng)之后的測(cè)試以200進(jìn)程數(shù)為增量，當(dāng)進(jìn)程數(shù)由800增加到1 000的時(shí)候，與服務(wù)器的連接出現(xiàn)連接失敗的情況，則減小測(cè)試進(jìn)程增量，變?yōu)?00，由900進(jìn)程數(shù)開始測(cè)量，可以看到一直到進(jìn)程數(shù)增加到940時(shí)，再次出現(xiàn)訪問服務(wù)器連接失敗的情況，再改變進(jìn)程數(shù)增量，直到進(jìn)程數(shù)增加到935時(shí)，訪問服務(wù)器正常，當(dāng)進(jìn)程數(shù)增加為936時(shí)，出現(xiàn)連接服務(wù)器失敗的情況。并且在935進(jìn)程數(shù)時(shí)，頁面響應(yīng)時(shí)間最長平均訪問時(shí)間為5.8 s，其他頁面的平均訪問時(shí)間也在5 s以下，服務(wù)器端的CPU使用率也在30%～40%之間較為平穩(wěn)。因此可以判斷，此次Web壓力測(cè)試的結(jié)果為935進(jìn)程數(shù)。

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

4 總結(jié)

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

本文對(duì)BOSS系統(tǒng)架構(gòu)下數(shù)字電視融合業(yè)務(wù)互聯(lián)網(wǎng)門戶的壓力測(cè)試的重要性進(jìn)行了闡釋，并進(jìn)行了較為詳盡的壓力測(cè)試步驟以及結(jié)果分析。另外，在BOSS系統(tǒng)測(cè)試領(lǐng)域，除了壓力測(cè)試，還有BOSS系統(tǒng)測(cè)試框架的研究、用戶體驗(yàn)研究、對(duì)象模型研究等，這些都將是未來一段時(shí)間內(nèi)的研究重點(diǎn)。

：

[1]王簫笛.基于數(shù)字電視平臺(tái)BOSS系統(tǒng)的應(yīng)用[J].中國數(shù)字電視，2011（12）：52-54.

[2]曹三省，劉劍波，蔣青苗，等.互動(dòng)新媒體業(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]呂廷杰，楊寧，吳海軍，等.電信運(yùn)營支撐系統(tǒng)OSS——理論、策略與實(shí)踐[M].北京：人民郵電出版社，2003.

[5]周丹.IPTV業(yè)務(wù)運(yùn)營支撐系統(tǒng)（BOSS）的測(cè)試方法研究與實(shí)施[D].北京：北京郵電大學(xué)，2009.

[6]吳為根.基于Web的壓力測(cè)試[D].上海：復(fù)旦大學(xué)，2006.

[7]施衛(wèi)娟，竇如林.基于WAST的Web網(wǎng)站壓力測(cè)試[J].電腦知識(shí)與技術(shù)，2008，3（23）：888-890.