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