隨著網(wǎng)絡技術的迅速發(fā)展，尤其是WEB及其應用程序的普及，各類基于WEB的應用程序以其方便、快速，易操作等特點不斷成為軟件開發(fā)的重點。與此同時，隨著需求量與應用領域的不斷擴大，對WEB應用軟件的正確性、有效性和對WEB服務器等方面都提出了越來越高的性能要求，對WEB應用程序進行有效的系統(tǒng)的測試也逐漸成為人們研究的重要課題。
目前可以見到各種WEB服務器平臺，然而根據(jù)Mereury的研究報告，98%的WEB服務器都沒能達到人們所期望的性能，平均只能發(fā)揮人們所期望性能的1/6左右。WEB性能測試能夠確定影響WEB服務器性能的關鍵因素，從而可以有針對性地進行分析和改進，避免WEB服務器研究和優(yōu)化過程中的盲目行為；同時，它也是選取不同的WEB服務器的重要參考。
隨著WEB應用程序使用越來越廣泛，針對其性能測試的要求也越來越多，然而由于WEB程序綜合了大量的新技術，諸如HTML、JAVA、Javascript、VBScript等，同時它還依賴很多其它的因素，比如Link、Database、Network等，使得WEB應用程序測試變得非常復雜。例如：WEB壓力測試是評價一個WEB應用程序的主要手段，它的測試就是一個代表性的方面。
WEB應用程序的測試有別于傳統(tǒng)軟件的測試，它有其自身的特點。下面我們進行比較深入的討論。
一個Web站點為了個人消費者、商業(yè)客戶、企業(yè)合作伙伴或者內(nèi)部用戶，都必須提供可靠、快速的性能，這是在評價一個Web應用是否滿足用戶需求和期望的關鍵指標。在這個競爭激烈的Internet 世界里，如果缺乏嚴格的過程，Web系統(tǒng)可能會在開發(fā)、發(fā)布和維護的過程中碰到一系列問題，甚至系統(tǒng)無法使用。而且如果一個企業(yè)的Web 應用沒有良好的性能，就意味著它會失去潛在的用戶。所以，必須對Web 應用進行負載測試，了解它在不同的負載下的響應情況。但是，由于Web應用的復雜性和不可預測性，使得負載測試難度較大。如果負載測試不夠準確，測試結果就是沒有任何用處的，甚至會產(chǎn)生誤導，使企業(yè)高估或者低估Web 應用的能力[1]。因此,負載測試的設計是至關重要的，只有在設計的負載真正地模擬了現(xiàn)實用戶的工作負載，并且模擬的用戶行為真正模擬了現(xiàn)實用戶的行為，負載測試的結果才是可靠的，從測試結果得出的結論也才會正確。
2 負載測試
負載測試在不同負載下測試客戶端或者服務器端的響應時間。負載測試也可以用來幫助測試人員計算在給定時間內(nèi)服務器可以處理的最大數(shù)量的事務數(shù)。此外，當C/ S 系統(tǒng)使用了工作負載均衡或者分布式體系結構，負載測試就應評估負載均衡或者分布式方法和設計是否一致[2]。
負載產(chǎn)生器模擬瀏覽器的行為，不斷地向Web 應用發(fā)送請求，然后在Web 應用發(fā)送一個應答之后，等待一段時間，接著發(fā)送新的請求。負載產(chǎn)生器可以模擬成千上萬個并發(fā)用戶來測試Web 應用的穩(wěn)定性。在負載測試中，每一個模擬瀏覽器稱為虛擬用戶，一個虛擬用戶就是腳本的一個實例。
對Web 應用進行準確的負載測試時，首先要準確、客觀地了解Web 應用的負載情況。Web 應用的負載情況是設計負載測試的前提和基礎。了解用戶的各種行為和動作是負載測試設計的關鍵，一個設計良好的負載測試要盡可能準確地模擬用戶的動作。Web 應用的日志文件和日志文件分析器是完成這個任務最重要的資源。
通過使用日志分析器對Web 應用日志文件的分析，鑒別和跟蹤與Web 應用通信量( traffic) 有關的用戶會話(user session) 變量集,其中主要包括的變量有：會話長度(以頁面數(shù)度量) 、會話持續(xù)時間(以分鐘和秒度量) 、會話期間訪問的頁面類型等等。頁面請求分布是用戶會話變量中需要特別關注的變量[4] 。這個變量顯示了每個頁面訪問的頻率,是設計測試場景的重要依據(jù)。除了這些主要變量外，那些會引起負載很小變化的其他變量也需要跟蹤。在確定了需要跟蹤的用戶會話變量之后，用日志分析器得到這些變量值的范圍和分布。
估計Web 應用的負載水平，主要是Web 應用的通信量如何增長、Web 應用的最高負載、Web 應用負載多長時間可以上升到最高負載、最高負載持續(xù)時間[4] 。一般情況下，最高負載的水平和通信量的水平大致成正比。如果一個Web 應用每個星期的用戶會話數(shù)為10 萬個，在高峰期每小時的用戶會話數(shù)為1500 個，那么可以預計如果每個星期的用戶會話數(shù)為20 萬個時,高峰期每小時的用戶會話數(shù)也將翻倍，即為3000個。
3 負載測試的設計
準確掌握了Web 應用的負載情況之后，就根據(jù)獲得的各項信息進行負載測試設計，準確模擬用戶的動作，其中主要包括用戶導航建模和用戶延遲建模。
3.1 用戶導航建模
用戶導航建模是對用戶在Web 應用上的動作進行建?！，F(xiàn)實中，用戶在一個Web 應用的行為可能包括一系列的動作。例如，一個在線書店的用戶登陸Web 應用之后，先瀏覽網(wǎng)頁查看有關信息，然后再搜索要購買的書，最后購買需要的書。從客戶端的角度看，是一個用戶執(zhí)行了所有這些動作。但是，在負載測試中，不可能和現(xiàn)實完全一致地模擬所有用戶的動作。負載測試的目的在于當用戶給服務器施加不同水平的負載時，根據(jù)考察服務器端的各項度量指標找出系統(tǒng)的瓶頸，提高整個系統(tǒng)的性能。所以，負載測試時虛擬測試者只要模擬與實際負載相同的負載水平，而不用將虛擬測試者和實際用戶一一對應，模擬每一個用戶的具體動作。設計負載測試時可以把用戶的一系列行為劃分為若干子行為，然后虛擬測試者以適當?shù)姆绞綀?zhí)行每一個子行為[5,6] 。例如，在上面的例子中，將用戶行為可以劃分為3個子行為——瀏覽信息、搜索圖書、購買圖書，然后用3 個不同的虛擬測試者以適當?shù)拇涡驁?zhí)行3個子行為。從服務器端看來，這3個虛擬測試者給服務器施加的負載和實際使用中一個真實用戶給服務器施加的負載是相同的。
在了解了用戶的行為模式后，還需要知道不同用戶所占的數(shù)量或者百分比。因為用戶的每一類動作給系統(tǒng)施加的負載都是不盡相同的，因此為了準確地模擬實際用戶的動作，必須確定各種用戶的數(shù)量或者百分比。各種以不同的百分比組合到一起的動作，應該滿足預期的頁面請求分布。例如，服務器施加很小的負載。而另一方面，購買圖書時要和數(shù)據(jù)庫通信，甚至要和其他子系統(tǒng)通信，這個動作對服務器施加的負載要比瀏覽信息大得多。因此，要根據(jù)掌握的Web應用負載情況，明確不同用戶的數(shù)量或者百分比，這樣才能準確地模擬實際用戶對服務器施加的負載。
3.2 用戶延遲建模
在進行負載測試的設計時，用戶的延遲的建模也是重要的一個方面。由于不同的用戶對Web應用的熟悉程度不同、閱讀速度和輸入速度不同，所以不同的用戶在完成相同的行為時延遲的時間也就不同，為了更加真實地模擬用戶的行為，必須對用戶延遲進行準確地建模[7]。在根據(jù)用戶導航建模錄制的腳本中，要考慮用戶延遲建模，對腳本進行修改。首先，可以根據(jù)用戶的延遲不同將用戶分為比重不同的若干組。例如，在一個用戶登陸頁面中，可以根據(jù)用戶對Web 應用的熟悉程度不同將用戶分為新用戶、返回用戶和有經(jīng)驗的用戶，它們所占比重分別是35%、55%和10%。以用戶延遲的不同對用戶進行分類，根據(jù)劃分的細致程度，模擬的用戶延遲的準確度就不同，劃分類別越多越細，模擬的用戶延遲就越準確。相反，如果劃分的類別很少，模擬的用戶延遲準確性就比較差。為了盡可能地和真實用戶的延遲相同，使用數(shù)學模型可以更好地實現(xiàn)。所以，在設計性能測試時為了很準確地模擬用戶延遲，需要認真地分析真實用戶的延遲情況，找到一種能夠和其很好吻合的數(shù)學模型，例如，常用的有均勻分布、正態(tài)分布和負指數(shù)分布。均勻分布模型就是從最大值和最小值之間隨機地選擇數(shù)據(jù)，正態(tài)分布是從最大值和最小值之間以不同的概率選取數(shù)據(jù),越靠近中間的數(shù)字選取的概率越大。
4 基于LoadRunner的負載/壓力測試實例
4.1 并發(fā)性能測試
基于客戶端應用的性能，測試的入口是單機客戶端。
并發(fā)性能測試的過程，即是一個負載測試和壓力測試的過程。它的基本原理是逐漸增加并發(fā)虛擬用戶數(shù)，直到系統(tǒng)的瓶頸，通過綜合分析監(jiān)控指標數(shù)據(jù)來確定系統(tǒng)性能。負載壓力測試有助于確認被測系統(tǒng)是否能夠支持性能需求，以及預期的負載增長，并找出系統(tǒng)出現(xiàn)異常的原因，從而對系統(tǒng)性能進行調(diào)優(yōu)。
并發(fā)用戶測試主要是對系統(tǒng)的核心功能和重要業(yè)務進行測試，要以真實的業(yè)務數(shù)據(jù)作為輸入，選擇有代表性和關鍵的業(yè)務操作來設計測試用例。
其目的是：在真實或者仿真環(huán)境下檢測系統(tǒng)性能，評估系統(tǒng)性能以及服務等級的滿足情況；預見系統(tǒng)負載壓力承受力，在應用實際部署之前，評估系統(tǒng)性能；幫助分析系統(tǒng)瓶頸、優(yōu)化系統(tǒng)自動化負載壓力測試實現(xiàn)機制。在多種服務器配置環(huán)境下測試，則配置成本，測試時間和人力資源必然會更多的消耗。但在很多情況下可以通過一種硬件配置下的壓力測試結果來預測不同配置下的Web應用程序的性能。
4.2 進入負載測試
由于條件的限制，本次實驗Web服務器和web客戶端同機。這就與網(wǎng)絡無關，即減少了網(wǎng)絡系統(tǒng)這個環(huán)境因素，直接與服務器連通。下面是錄制基本的用戶腳本。
(1)啟動VuGen(Visual User Generator虛擬用戶生成器)，其方法：“開始”→“程序”→“Loadrunner”→“Visual User Generator”。通過菜單“new”新建一個用戶腳本，選擇通信協(xié)議。這里用的是Web應用，所以選擇web(HTTP/HTML)協(xié)議。
(2)進入VuGen主窗口
(3)點擊Start Record按鈕,進入開始錄制窗口設置，
(4)在開始錄制錄制窗口中，URL設為http://127.0.0.1/xitong/default。Action序號可自定義，也可以用默認值如：Action4。點擊”OK”按鈕后,在web瀏覽器里打開網(wǎng)站首頁。
(5)在瀏覽登錄網(wǎng)頁的同時,VuGen自動生成腳本.用戶一般性登錄并瀏覽網(wǎng)頁中的信息。相應地腳本是在這樣的情況下自動錄制的，因此腳本也是一般性的登錄瀏覽。如下：
(6)優(yōu)化腳本如事務。LoadRunner有兩種和事務相關的概念： Action和Transaction。Action是用戶的一系列操作的組合；Transaction是用戶某一具體的動作，為了衡量服務器的性能而需要定義的。例如：在腳本中有一個數(shù)據(jù)查詢操作，為了衡量服務器執(zhí)行查詢操作的性能，就把這個操作定義為一個事務，這樣在運行測試腳本時，LoadRunner 運行到該事務的開始點時，LoadRunner 就會開始計時，直到運行到該事務的結束點，計時結束。這個事務的運行時間在結果中會有反映。Action通常會包含一系列功能相關的Transaction。事務有三種執(zhí)行結果：pass(通過)可執(zhí)行全部虛擬用戶腳本；fail(失敗)執(zhí)行過程中發(fā)生了錯誤；stop（停止）因到測試結束時間等而停止執(zhí)行腳本。
本文事務定義為登錄某個子網(wǎng)頁，考查登錄子網(wǎng)頁的系統(tǒng)響應情況。
錄制用戶進行系統(tǒng)登錄訪問的腳本.在controller中選擇腳本，設置虛擬用戶數(shù)量并運行，運行時，將以設置的虛擬用戶數(shù)(每次增加用戶)為并發(fā)數(shù)，并發(fā)進行網(wǎng)站訪問操作，初步預計最大的并發(fā)量為20個用戶。
測試過程中記錄的部分數(shù)據(jù)，事務登錄某個子網(wǎng)。列表綜合分析：
從圖6所得數(shù)據(jù)，容易看出：
平均響應時間較快、平穩(wěn)；訪問最大并發(fā)量為16；當增加至50時，系統(tǒng)登錄失敗。
5 結論
(1)被測小系統(tǒng)性能比較差。測試運行的環(huán)境未顯異常，測出的實際最大并發(fā)數(shù)量少于預期數(shù)量。因此，可初步確定被測系統(tǒng)是性能問題的關鍵。對于一個小系統(tǒng)，它的反應時間較快可能夠承受的最大并發(fā)用戶數(shù)比較小，并且還不能很好地持續(xù)工作。系統(tǒng)開發(fā)者應該進一步提高性能如：優(yōu)化代碼、核心功能模塊等，以支持更大并發(fā)用戶數(shù)。因為系統(tǒng)核心功能很大程序影響其性能。
(2)性能測試也能發(fā)現(xiàn)功能問題。系統(tǒng)有些功能和按鍵并不很完善，這也會影響性能的提升。性能測試和功能測試是緊密聯(lián)系在一起的，原因之一是很多性能問題是由軟件自身功能缺陷引起的。如果應用系統(tǒng)功能不完善或者代碼運行效率低下，通常會帶來一些性能問題。功能測試通常要先于性能測試或者同步進行，軟件功能完善可以保證性能測試進行得更加順利。
(3)盡最大努力無限接近正確值。做任何實驗所得結果都不能保證其百分之百的準確，同樣本論文的實驗也是如此。因為在不同的時間用戶的動作事務是極不相同的，運用不同的腳本或者場景，測試所得的結果往往是不一樣的。更何況，實驗結果與測試工具、方法和環(huán)境（操作系統(tǒng)，服務器，內(nèi)在及CPU等）也有關，而工具和測試環(huán)境本身就無法完美無缺。為取得無限接近正確值，本文多次反復實驗測試，摘錄一些平均穩(wěn)定結果數(shù)據(jù)，再進行列表比較，最后得出結論。
任何一種工具，相對而言也就很容易上手其它工具。
目前，國外對性能測試的研究己經(jīng)取得了許多成果，提出了一些模型、方法和策略，并相應開發(fā)了測試工具。國內(nèi)在Web性能測試方面的研究和開發(fā)才剛剛起步，沒有比較完善的測試模型和良好的測試工具。這對我們來說是個極大的挑戰(zhàn)，同時也是機遇。
