• 項目背景
• 項目特點
• 性能測試過程
  • 測試前期準備
  • 測試工具引入
  • 測試計劃
  • 測試設計與開發
  • 測試執行與管理
  • 測試分析
• 案例小結

項目背景

該案例是某通信企業Web業務系統的性能測試。該Web業務系統用于管理企業的備品和備件，包括對網絡設備的庫存管理、庫存流轉、備品備件的查詢統計等功能。其中庫存管理、備品備件查詢等功能主要是對數據庫的增、刪、改、查操作，庫存流轉則主要體現為工作流的實現。

該系統的主要用戶是通信企業的備品備件管理人員，通過該系統，管理人員能夠對現有的備品備件庫數據進行查詢、更新，也可以通過該系統提供的業務流程完成備品備件的出庫和入庫操作。

對系統的測試在系統上線時進行，主要目的是驗證系統的性能能否達到用戶要求。

項目特點

該項目基于J2EE實現，采用Tomcat作為應用服務器，架構上使用Struts+EJB+Herbinate，在業務上實現了多個流轉的流程。

該系統是一個典型的J2EE應用，從性能測試的角度來說，具有很強的代表性。從技術的角度來說，該系統使用了驗證碼方式防止對系統口令的暴力破解和可能的內部SPAM，由于現在越來越多的系統都采用驗證碼方式提高系統的安全性，因此在對本案例的描述中也特別給出了針對這種驗證碼的性能測試解決方案。

該系統的網絡環境和設備相對簡單，網絡環境是企業內部的千兆網絡，基本不可能對系統性能造成影響；設備方面，采用一臺UNIX服務器作為數據庫服務器，一臺UNIX服務器作為應用服務器。

該系統是一個以人機交互為主的系統，因此，對系統性能的體現主要通過響應時間來給出。

由于Web應用采用的協議單一（HTTP和HTTPS協議），因此特別適合用商業的性能測試工具（如LoadRunner）來輔助進行測試，本案例的描述中重點結合LoadRunner的使用，描述了在項目性能測試中用LoadRunner等工具進行測試的方法。

性能測試過程

本節描述性能測試的全過程，根據本書第5章的性能測試過程描述，按照PTGM模型分別對性能測試的各階段進行闡述。

測試前期準備

在了解該項目的基本狀況之后，首先開始測試前期準備工作。

1.系統基礎功能驗證

本案例中描述的性能測試安排在功能驗收測試之后，因此在性能測試中不需要額外安排基礎功能驗證。

2.組建測試團隊

根據該項目的具體情況，建立一個5人的團隊負責本次測試工作。由于該系統的設備環境和網絡環境相對簡單，因此沒有特別在團隊中包括系統工程師，團隊的5個成員中，1名是數據庫工程師，1名是性能測試設計和分析人員，3名是性能測試開發和實施人員。

在測試開始之前，根據對項目的了解，預計該系統的性能測試難點主要在測試設計和測試腳本實現階段，由于系統協議單一，架構相對比較簡單，且有合適的商業工具可以直接使用，因此在測試工具方面不需要投入太多的精力。

3.測試工具需求確認

考慮到系統測試的要求，確定的測試工具需求如下：

• 支持HTTP/HTTPS協議層上的測試。
• 能監控UNIX服務器的主要性能計數器值，如服務器的內存使用狀況、CPU使用狀況、磁盤I/O情況等。
• 能監控Windows服務器的主要性能計數器，如服務器的內存使用狀況、CPU使用狀況、磁盤I/O情況、進程的內存使用情況等。
• 支持對Oracle數據庫的主要性能計數器值進行監控。
• 支持對Tomcat應用服務器的JVM內存使用狀況進行監控。

4.測試工具需求確認

性能預備測試用于對系統建立直觀的認識，在正式開始測試之前體驗性地使用了本系統的主要功能，根據體驗，系統的所有操作均能在4秒之內完成，響應時間相對較長的是登錄過程。

測試工具引入

根據測試前期準備確定的測試工具需求，目前市面上的性能測試工具基本都能夠支持這些需求，唯一有困難的是“監控Tomcat應用服務器的JVM使用狀況”，基本上所有的商業工具都不支持該需求。

最終確定的測試工具包括兩個方面的內容：采用LoadRunner工具作為主要的性能測試工具；對Tomcat的JVM使用狀況的監控通過自行開發工具來實現。

測試計劃

測試計劃階段需要分析用戶活動，確定系統的性能目標。

1.性能測試領域分析

根據對項目背景的了解，本性能測試要解決的主要問題為：驗證系統是否達到了預期的性能指標。

這些內容對應于第2章中給出的能力驗證應用領域。進一步根據第2章的內容，本測試可用的性能測試方法包括PerformanceTesting和StressTesting方法。

2.用戶活動剖析與業務建模

本案例描述系統的建模主要通過用戶活動建模和業務建模來體現和進行。

根據對被測系統的使用用戶進行書面的問卷調查，在問卷基礎上進行分析，可以得到如表1所示的典型用戶活動分析列表。

表1

表1初步描述了用戶對各業務系統的使用情況，可以以此為基礎來進一步分析用戶場景，并據此設計相應的測試方案和用例，業務場景的分析與企業的實際業務模式相關。

在對用戶活動進行建模的過程中，還得到了以下數據：

1. 平均每天使用該系統的總用戶數約為600。
2. 平均每個用戶的loginsession時間為4小時（也就是說，平均每個用戶在8小時時間內有4小時處于“使用系統”的狀態）。
3. 平均每個用戶在loginsession的時間范圍內進行500個業務操作。

根據以上數據，可以用第1章給出的公式進行計算：

并發用戶數：600×4/8=300

吞吐量：300×500/（4×60×60）=10，單位是頁面瀏覽數/秒（PageView/sec）。

有了這些數據就可以進行測試場景的設計了。

在分析了用戶的行為之后，為了給測試腳本開發提供依據，還需要對每個業務的操作過程進行描述。在本案例中，以“庫存流轉―審批”為例，對業務操作進行描述。

從表1中可以看到，該系統的主要業務集中在庫存流轉流程相關的活動上，因為這些活動都圍繞流轉進行，在業務場景設計時必須考慮流程之間的交互性。

另外，“導入備件Excel文件”業務的發生頻率和實際使用的用戶數量都不大，但由于每次的導入操作均會導入大量的數據，導入過程中系統承受的壓力很大，因此在設計場景時有必要單獨考慮該場景。

3.確定性能目標

本性能測試的應用領域已被確定為能力驗證，在確定性能目標時，主要圍繞這個方面確定。

本項目是一個開發項目，從需求和設計中可以獲得關于該系統性能目標的描述。根據需求和設計文檔，該系統的性能約束在文檔中的表達如下：

1. 系統的頁面響應時間不超過10秒。
2. 需要評估導入備件Excel文件對系統性能的影響，如果該操作影響其他業務，需給出建議。
3. 系統能夠穩定運行。

在這些描述中，第（1）條是比較清晰的性能需求描述；第（2）條實際描述的并不是需求，而是希望在性能測試中安排對“導入”操作的性能表現的測試；第（3）條描述的是用戶的性能要求，但不夠明確。

經過多次溝通，最終確定的明確的性能需求如下：

系統在典型數據量情況下，頁面響應時間不超過10秒：典型數據量定義為當前系統的所有備件規模的靜態數據和半年的流轉數據。

1. 系統在典型數據量情況下，頁面響應時間不超過10秒：典型數據量定義為當前系統的所有備件規模的靜態數據和半年的流轉數據。
2. 系統能夠在高于實際系統運行壓力1倍的壓力情況下，持續穩定工作72小時：持續穩定工作定義為在系統運行期間，系統的可用資源不會出現持續性地減少，用戶響應速度沒有顯著變化。

除了這兩個直接從文檔中反映的系統性能需求，根據和用戶、項目經理等的溝通，另外確定的其他性能目標包括：

1. 評估典型規模的Excel備件文件導入時對系統性能的影響：評估內容包括兩個方面，一個方面是對典型規模的Excel文件（考慮到系統實際的備件數據規模，選擇一個20MB、包含50000條數據記錄的Excel文件）進行導入時的效率評估；另一方面是通過組合場景，判斷導入操作對其他操作的影響。
2. 在頁面響應時間要求10秒的情況下，找到系統能夠承受的最大用戶數量：該要求可以給用戶提供一個可擴展性的參考。

表2給出了分析整理后的性能需求描述。

表2

對能力驗證應用領域來說，本測試需要重點關注的是業務的響應時間、各服務器的資源使用狀況，結合性能測試需求，性能目標可以定義如下：

1. 在典型用戶數量要求的情況下，服務器CPU平均使用率不高于75%，內存使用率不高于75%。
2. 在穩定性測試的壓力情況下，服務器CPU平均使用率不高于95%，內存使用率不高于90%。

4.制定測試時間計劃

本案例采用商業性能測試工具LoadRunner進行測試，由于本案例涉及較多的流程交互等內容，因此重點集中在如何設計和實現合理的性能測試腳本，這需要消耗較多的時間和人力資源。

另外，測試結果的分析也需要安排足夠的時間進行。本案例的測試時間計劃安排如表3所示。

表3

測試設計與開發

測試設計與開發包括測試環境設計、測試場景設計、測試用例設計和測試輔助工具開發多個活動。對本案例而言，測試場景關注用戶以何種方式使用本系統，以場景來體現性能測試的目的和目標。

1.測試環境設計

本性能測試需要驗證系統在實際生產部署環境上的性能，因此，選擇盡可能接近實際生產環境的環境來進行測試。由于本測試的環境就是實際的生產環境，因此在環境設計上，沒有太多需要考慮的內容。

最終確定的測試環境如表4所示。

表2給出了用作測試的基礎數據量。基礎數據量的計算方法在前兩個案例中都有描述，在此不再重復。

表4

2.測試場景設計

結合表1的和表2可以很容易地為該案例給出需要的測試場景。

根據上面給出的數據，設定的總并發用戶數為300，按照業務模塊訪問用戶數比例給定VU分配比例，為了達到10PageView/sec的吞吐量，每個VU的操作之間間隔應該為300/10=30秒。

根據調查的結果，我們確定了幾個典型的測試場景，如表5所示。

表5-1

表5-2

3.測試用例設計

確定測試場景之后，原有的業務操作描述可以更進一步完善為可映射為腳本的測試用例描述。

在本案例中，可以將用戶業務操作形成更詳細的用例步驟。例如，“審批”業務可以描述如下：

用例編號：TC_XXXX_XX-1

用例條件：用戶已登錄，登錄用于具有審批的權限

用戶步驟和驗證方法：

1. 用戶單擊“庫存流轉”鏈接，進入庫存流轉頁面。
   【驗證】頁面出現“庫存流轉”提示字符串。
2. 用戶在頁面左側樹視圖上單擊“審批”鏈接，進入審批頁面。
   【驗證】頁面上出現“申請單列表”提示字符串。
3. 用戶在頁面給出的等待審批的申請單列表中選擇最上方的一個，單擊“審批”按鈕，進入審批頁面。
   【驗證】給出選中審批單信息，頁面上出現被選中審批單的編號。
4. 用戶輸入審批信息，單擊“通過”按鈕。
   【驗證】頁面上出現“審批通過”提示字符串

從該用例的描述可以看到，在每個操作步驟之后，都給出了相應的驗證手段。對性能測試來說，驗證手段同樣關鍵。性能測試工具（如LoadRunner等）在性能測試過程中為了VU的效率，一般只通過HTTP返回的HTTPCode判斷請求是否成功，對于典型的如HTTP500、HTTP404等錯誤，LoadRunner能夠判斷，但如果采用了自定義錯誤頁面，或是返回了表示異常狀態的頁面，LoadRunner便不能發現。

基于以上原因，通常需要在腳本中添加一些用于驗證返回頁面是否正確的代碼，最常用的方法是判斷頁面中是否存在特定的字符串。因此，在每個用例中都描述了每個步驟結果的驗證方法。

4.腳本和輔助工具的開發

本案例采用LoadRunner作為性能測試工具，下面通過該案例首先介紹LoadRunner在性能測試中的一般應用步驟，然后重點說明在性能測試過程中遇到的問題和解決方法，依次演示LoadRunner使用中的一些技巧和技術。

（1）LoadRunner的性能測試過程。

用LoadRunner工具輔助進行性能測試，一般包括錄制和調試腳本、設置場景、運行場景、收集結果并分析4個活動。

錄制和調試腳本活動使用LoadRunner的VirtualUserGenerator應用（下文中簡稱為VUGenerator）完成，運行該應用，選擇合適的錄制協議，打開被測應用的客戶端程序（對B/S應用，客戶端程序就是瀏覽器），按照預期即可進行錄制。LoadRunner錄制的腳本中體現的是客戶端和服務器之間的通信數據以及相互的交互關系。

腳本的錄制依據事先分析出的用戶活動和案例。按照測試用例設計中給出的具體操作描述，打開VUGenerator工具，輸入應用的起始URL，根據用例描述執行操作，錄制腳本。LoadRunner針對Web應用錄制的腳本默認分為vuser_init、Action和vuser_end3段，其中，vuser_init和vuser_end段只在腳本運行時執行一次，而Action段的執行次數由腳本或場景的RuntimeSetting控制。一般來說，在錄制腳本時，會把Login和Logout的步驟分別放在vuser_init和vuserend段中，而把針對業務的操作步驟放在Action段中。

VUGenerator同時提供了對腳本調試的良好支持。腳本錄制完成后，需要經過一個仔細的調試階段才能保證腳本確實準確無誤地反映了計劃中的測試意圖。調試過程中經常進行的操作是參數化、關聯和調試輸出。

設置場景活動由LoadRunner的Controller工具支持。運行Controller工具，根據測試設計中確定的典型測試場景（見表1），將不同的腳本按照場景中設計的比例分配到一個場景中。并且，測試場景中還需要根據設計的典型場景中的“性能計數器”項目，設置需要進行監控的性能計數器內容。圖1描述的是根據表5設計的“系統應用典型場景1”實施的場景。

圖1

場景設置涉及的細節內容較多，除了在該場景中分配執行各腳本的VU數量外，還需要根據測試設計添加需要增加的性能計數器（見圖2），最后，特別需要關注的是針對腳本的RuntimeSetting設置（見圖3），例如，表5給出的“典型場景1”中描述了需要每個腳本Action部分迭代100次，這就需要在Controller的設置中給出每個腳本的迭代次數設置。

圖2

圖3

運行場景活動相對簡單，單擊Run頁面中的StartScenario按鈕，Controller就會自動開始運行場景，并在ScenarioStatus中顯示運行時的信息。

收集結果并分析活動需要Analysis應用的支持，Analysis應用可以被獨立啟動，也可以從Controller程序中調用。從Controller程序中調用時，Analysis應用直接讀取本Controller當前場景運行時的信息。圖4給出了Analysis應用運行時的界面。

圖4

Analysis應用能夠根據用戶設定的性能計數器生成各種性能報表。不過，Analysis最多也只能起到輔助進行性能測試分析的作用，要對性能測試的結果進行分析，還要依靠測試分析者的經驗、技能和對系統的了解。

（2）錄制“登錄”腳本。

針對該應用錄制登錄腳本時，驗證碼是一個首要的困難。

驗證碼是在進行登錄或內容提交時，頁面上隨機出現的人工可識別但機器不可識別的驗證字符串（一般是采用背景、扭曲等方式產生的圖片），要求登錄或提交內容的同時輸入，如果驗證碼輸入錯誤，則不允許進行要求的操作。

本案例中的被測系統使用了驗證碼技術，其要求輸入驗證碼的頁面內容如圖5所示。

驗證碼可以有效防止采用機器猜測方法對口令的刺探，目前己經被許多Internet或Intranet應用接受為標準的實現方式。但對性能測試來說，驗證碼卻帶來了很大的問題。因為驗證碼具有阻止通過自動工具嘗試的特性，因此，對于本質上也是自動化工具的性能測試工具，驗證碼同樣具有相當的威力。

圖5

具體到本案例系統，在錄制腳本時，LoadRunner可以錄制用戶輸入的“用戶名”、“密碼”和“驗證碼”信息，但在回放時，由于要求的驗證碼與錄制時的驗證碼不可能相同，因此回放必然會失敗。

為使性能測試能夠順利進行，需要采用某種方法解決上述問題。在筆者的實際工作中，通常使用下面3種方法解決該問題。

第1種方法是最容易想到的方法——在被測系統中暫時屏蔽驗證功能，也就是說，為性能測試臨時修改應用，在應用中屏蔽驗證碼（也就是說，無論用戶輸入的是什么驗證碼，應用都認為其是正確的）。

這種方法最容易實現，對性能測試結果也不會有太大的影響。這種方式去掉了“驗證驗證碼正確性”這個環節，從理論上來說，測試得到的結果與存在“驗證驗證碼正確性”環節的應用系統存在細微的差異，不過考慮到此環節一般不會成為系統性能瓶頸，因此認為這種處理方式對性能測試結果沒有太大的影響。

這種方法對于處于未上線狀態或在受控的測試環境中運行的系統非常適用，但對于已經實際上線運行的系統來說，這種方法有一個明顯的問題：屏蔽驗證功能會對己經在線運行的業務造成非常大的安全性風險。

因此，我們建議在受控的測試環境中采用該方法，但對于已上線的系統來說，不推薦使用該方法。

第2種方法是在第1種方法的基礎上稍微進行一些改進。

第1種方法的主要問題是安全性問題，為了應對對在線系統安全性的威脅但在其中留一個“后門”——設定一個“萬，可以在修改程序時不取消驗證，能驗證碼”，只要用戶輸入該“萬能驗證碼”，應用就認為驗證通過，否則，還是按照原先的驗證方式進行驗證。

這種方式仍然存在安全性問題，但由于可以通過管理手段將“萬能驗證碼”控制在一個較小的范圍內，而且只在性能測試期間保留這個“后門，基本上可以看作是可靠的。

相對第1種方法來說，這種方法在安全性方面進行了改進，在能夠通過管理手段控制“萬能驗證碼”范圍的情況下，該方法不失為一種簡單易行且相對安全的方法。

第3種方法采用更進一步的方法來處理驗證碼的問題。

LoadRunner能夠調用外部的DLL或組件接口，考慮到這個特性可以根據“驗證碼驗證”的實現，寫一個獲取驗證碼的動態庫，在測試腳本中調用其接口即可。關于如何在LoadRunner中使用外部DLL，參見本書第11章的內容。

在使用以上驗證碼處理的方法時，特別要注意，如果針對的是己上線運行的實際系統，無論用哪種方法，測試完成后，都必須立刻將應用恢復，并對系統進行一次安全審計，以免在測試期間被他人入侵。

在本案例中，采用第2種方法來解決驗證碼帶來的問題。

以下是腳本中與登錄相關的部分代碼：

圖6-1

圖6-2

這段腳本中灰色背景的粗斜體內容就是修改系統實現后留下的“后門”，其中，5847是在代碼中控制的一個“萬能驗證碼”，主要用戶輸入該驗證碼，系統就認為驗證通過。

細心的讀者還會發現，這段代碼已經經過了關聯處理，其中粗斜體標識的內容就是關聯產生的參數內容。這段代碼的關聯是通過LoadRunner的“自動關聯”方式實現的，具體實現方法請見第11章。

解決了驗證碼和登錄時關聯的問題后，登錄腳本還需要處理的另一個問題就是針對輸入的用戶名和口令進行參數化處理，本案例中共使用了10組不同的用戶名和口令組合。對用戶名和口令實現參數化的具體步驟請見第11章。

（3）錄制“新建申請單”腳本。

錄制“新建申請單”腳本需要首先按照設計中該用例的操作步驟進行錄制，以下是按照“新建申請單”用例步驟進行錄制后生成的部分腳本代碼。

圖7

從腳本中可以看到，腳本中給出了申請的發起時間和到期時間，為了使腳本具有更好的適應性，我們決定將這兩個時間分別以“當前時間”和“當前時間的前4天”進行替代，這需要對腳本進行參數化操作。在VUGenerator中，選中需要參數化的內容（兩個時間），從右鍵菜單中選擇Replacewithaparameter命令，在出現的對話框中設定參數類型為Date/Time，設置時間格式為適合的格式，如圖8所示。

設置到期時間時，需要將參數在當前時間的基礎上再增加4天。圖9所示為設置到期時間的對話框，要注意其中設置的Offsetparameterby選項。

另外，為了便于直觀地識別數據是在哪次操作時插入的，在新建申請單時將“備注”的內容修改為“test-”+“當前時間”（當前時間精確到秒）。

圖8

圖9

參數化修改完成后的腳本代碼如下：

圖10

除了參數化之外，在腳本中還需要體現“驗證返回結果是否正確”，驗證返回結果是否正確通過LoadRunner提供的web_eg_find函數實現。該函數的原型是：

圖11

在腳本中加入該函數可以根據頁面是否存在指定的文本等來驗證系統處理的正確性。在用例設計時我們給出了“審批”業務的用例，其中包括的每個“驗證”點都可以用這種方式來處理。例如，對給出的“【驗證】頁面上出現‘申請單：列表’提示字符串”要求，可以在指定的發送請求的語句后添加下面的語句來驗證：

Web_reg_find（"Text=申請表：列表＂，LAST）；

該語句可以驗證返回的頁面上是否包含“申請表：列表”文本內容。

（4）錄制“審批”腳本。

“審批”涉及到“流程”的概念，測試場景中要求一部分用戶“新建”申請單，另一部分用戶對已有的申請單進行“審批”操作。錄制腳本時，假設錄制了對某一條己有的申請單的“審批”，在回放時，如果指定的申請單已經被處理，則腳本的處理就會出錯。

圖12給出了審批時能看到的待審批申請單列表，在性能測試過程中，每個VU看到的列表都會有所不同，為了使性能測試時每個VU都能夠順利執行（處理待審批的申請單），必須在腳本中約定申請單的處理規則。為簡單起見，我們約定的規則是“每個VU都只處理當前未被處理申請單列表中的第一條記錄”。

圖12

為了實現這個規則，必須對錄制后的腳本進行一些處理。未處理的錄制生成腳本的相關部分代碼如下：

圖13

/＊動作2——單擊指定的審批單記錄，給出審批單的詳細信息，允許用戶對其進行審批＊/

圖14

/＊動作3——填寫審批單后進行提交，提交為＂通過審批＂＊/

圖15

以上代碼中的數字“20051223004”表明了要處理的記錄的ID。動作2和動作3都使用了唯一標識審批單記錄的ID（數字20051223004）來對指定的審批單操作，那么，這個審批單的ID是從哪里得到的呢？

注意動作1，該動作返回當前所有可被處理的審批單列表，幾乎可以肯定，用于標識審批單ID的數字是作為該動作的響應返回給我們的。在VUGenerator中切換到TreeView視圖（單擊工具欄中的ViewTree按鈕），選擇ServerResponse選項卡，可以看到圖16所示的結果。

將圖16顯示的信息與圖15進行對比，圖15是瀏覽器呈現的頁面，而圖16給出的則是該頁面的對象信息和以文本方式顯示的HTML內容。

圖16左側樹型的3個radio:appids節點對應于圖15顯示的3條待處理審批單。而且，從右側顯示的HTML文本內容來看，這個Radio的value就是在后續腳本中需要使用到的用作ID的數值。

圖16

根據約定的規則，只要求每個VU處理第一條未審批的記錄，這樣問題就轉變成了一個典型的關聯問題―如何從動作1返回的HTML文本中獲取到第一條未審批記錄的value值。

本書的第11章詳細描述了相關的內容，對Web應用的性能測試腳本而言，主要的關聯函數是web_reg_save_param函數。該函數必須放在產生需要獲取關聯內容的語句之前（在本案例中，要放置在“動作1”的語句之前），其原型是：

圖17

其中，第一個參數是關聯操作獲取的內容保存的變量；最后一個參數是LAST；中間的參數描述了約束要獲取關聯內容的各種屬性。指定關聯屬性時，必須指定“左邊界”和“右邊界”，視情況還可指定其他屬性。對本案例來說，需要進行關聯的內容在返回的HTML文本中，文本內容為：

圖18

需要通過關聯操作獲取的內容是“20051223004"，可以選取左邊界為“value="”，右邊界為“＂”?？紤]到返回的HTML文本中能夠與選取的左邊界與右邊界匹配的內容較多，因此還需要通過ORD屬性指明具體的需要關聯的內容位置。

最終關聯處理完成后的腳本代碼片斷如下：

圖19

添加的web_reg_save_param語句表明，需要關聯的內容存在于下一個Request為“＂”返回的HTML內容的BODY中，該內容左邊界為“value=＂”，右邊界，在這個HTML內容的BODY中，我們想要通過關聯獲取的內容順序排在第4個出現符合約束條件的位置。

（5）錄制其他腳本

錄制其他腳本的過程相對比較簡單，主要的技術細節和難點都在上幾個腳本的錄制過程中進行了詳細描述，在此不再贅述。

測試執行與管理

在測試執行與管理之前的過程和活動中，己經明確規劃了本性能測試的環境、場景和腳本，在本過程中，只需要按照前面階段的要求，將測試場景和腳本進行部署，然后執行測試并記錄結果即可。

建立測試環境

建立測試環境只需要按照測試設計中設計的環境設計內容部署測試環境。部署測試環境的工作一般由團隊中的系統工程師完成，可以采用CheckList幫助進行測試環境的部署。

表6給出了一個CheckList的示例。

表6

部署測試腳本和測試場景

根據設定的性能測試場景，在LoadRunner工具中對其進行部署，部署過程請參考本書的第11章。

執行測試和記錄結果

本性能測試中使用LoadRunner作為性能測試工具，性能指標的數據主要通過LoadRunner的Monitor等獲得，因此主要通過LoadRunner來記錄數據。唯一例外的是針對Tomcat的服務器狀態監控，這部分通過Tomcat提供的StatusSeverlet進行監控，監控得到的數據保存在本地文件中，通過Excel進行處理并以圖表的方式呈現。

用LoadRunner執行測試非常簡單，只需要通過Controller的GUI界面就可以完成執行和監控工作。這部分的具體內容請參考本書的第11章。對Tomca秒獲取一次數據t使用的JVM進行監控通過Tomcat的statusservelet實現，每5，獲取的數據保存在文本文件中。

但在實際的性能測試過程中，由于一些設置等問題，有時候會遇到執行出錯的情況。典型的情況是腳本在單獨回放時沒有任何問題，但部署到場景中執行時卻出現一些奇怪的錯誤。

本案例的執行過程中就出現了這樣的情況。設定好測試場景并開始執行后，從Controller的界面上可以看到“HTTP404:CannotfindpageXXXX”的錯誤信息。剛看到這個問題時覺得特別奇怪，因為在回放的過程中沒有出現過這樣的錯誤，而且，從計數上看，通過的Transaction一共只有500個，除去200個vuser_init和vuser_end的Transaction，通過的只有300個，也就是說，每個腳本都只有第一次迭代的執行是正確的。

仔細檢查WebServer的日志，發現該日志中有多個訪問timeout.jsp的記錄，詢問開發人員得知，session超時后才會訪問這個頁面。首先排除了由于迭代之間的等待時間過長導致超時的可能，隨后經過仔細分析，覺得問題產生的原因可能與LoadRunner的設置有關。

HTTP協議本身是非面向連接的無狀態的協議，為了適應Web應用需要的交互特性，一般需要使用sessionid來標識一些會話中的各個request和response為了保留住sessionid，一般的做法是用hiddenfield、cookie或是在URL上附加sessionid來解決，我們懷疑本題的出現與sessionid的處理相關。

查看LR記錄的頁面訪問數據（見圖20），可以看到，在ClientRequest中附帶了JSESSIONID的信息，可見，該應用是用cookie解決sessionid的問題的。

圖20

接下來，可以大膽猜測，出現問題的原因可能是在兩次迭代之間LR清除了cookie，這就使在第一次迭代時應用操作成功，但在隨后的執行中由于不存在sessionid的標識，使后續的操作全部失敗。

檢查腳本RuntimeSetting的設置（見圖21），果然Simulateanewuseroneachiteration選項被選中。LoadRunner的Manual里對Simulateanewuseroneachiteration選項的解釋是：“選中該選項后，LoadRunner在每次迭代時清除當前的上下文。”iteration選項的解釋是：“選中該選項后，LoadRunner在每次迭代時清除當前的上下文。”

圖21

取消選中該選項，重新運行Controller中的場景，結果正常。

首先說一下session的起源。

HTTP協議本身是無狀態的，這與HTTP協議本來的目的是相符的，客戶端只需要簡單地向服務器請求下載某些文件，無論是客戶端還是服務器都記錄彼此過去的行為，每一次請求之間都是獨立的。

然而，對目前的大部分Web應用來說，“無狀態”導致許多應用都不得不花費大量的精力記錄用戶的操作步驟，人們很快發現，如果能夠提供一些按需生成的動態信息，會使Web變得更加有用，這種需求一方面迫使HTML逐步添加了表單、腳本、DOM等客戶端行為，另一方面在服務器端則出現了CGI規范以響應客戶端的動態請求，作為傳輸載體的HTTP協議也添加了文件上載、cookie這些特性。其中cookie的作用就是為了解決HTTP協議無狀態的缺陷所作出的努力。至于后來出現的session機制則是又一種在客戶端與服務器之間保持狀態的解決方案。下面用幾個例子來描述一下cookie和session機制之間的區別與聯系。假設在一個快餐廳有累計消費滿200元返50元的優惠，為了能夠準確地返給用戶正確的金額，可以有這樣幾種方案：

（1）該店的店員很厲害，能記住每位顧客的累計消費金額，只要顧客一走進快餐廳，店員就知道該怎么對待了。這種做法就是協議本身支持狀態。

（2）發給顧客一張卡片，上面記錄著消費的數量，一般還有一個有效期限。每次消費時，如果顧客出示這張卡片，則此次消費就會與以前或以后的消費聯系起來。這種做法就是在客戶端保持狀態。

（3）發給顧客一張會員卡，除了卡號之外什么信息也不記錄，每次消費時，如果顧客出示該卡片，店員則在店里的記錄本上找到該卡號對應的記錄并添加一些消費信息。這種做法就是在服務器端保持狀態。

由于HTTP協議是無狀態的，而出于種種考慮也不希望其成為有狀態的，因此，后面兩種方案就成為現實的選擇。具體來說，cookie機制采用的是在客戶端保持狀態的方案，而session機制采用的是在服務器端保持狀態的方案。同時也看到，由于采用服務器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要借助于cookie機制來達到保存標識的目的。

session機制是一種服務器端的機制，服務器使用一種類似于散列表的結構（也可能就是使用散列表）來保存信息。

當程序需要為某個客戶端的請求創建一個session時，服務器首先檢查這個客戶端的請求里是否已包含了一個session標識——sessionid，如果包含，則說明以前已經為此客戶端創建過session，服務器就按照sessionid把這個session檢索出來使用（如果檢索不到，可能會新建一個）；如果不包含，則為此客戶端創建一個session并且生成一個與此session相關聯的sessionid，sessionid的值應該是一個既不會重復，又不容易被找到規律以仿造的字符串，該sessionid將在本次響應中返回給客戶端保存。

保存sessionid的方式可以采用cookie，這樣在交互過程中，瀏覽器可以自動按照規則把這個標識發送給服務器。一般將cookie，設定為類似于SESSIONID的名稱，如weblogic對于Web應用程序生成的cookie，JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng！-145788764，該cookie的名字就是JSESSIONID。

測試分析

測試執行完成后，通過LoadRunner的Analysis模塊，可以對測試過程中得到的性能數據進行分析。

針對場景1、場景2、場景3的基礎性能分析

在進行性能分析時，首先可以檢查Analysis模塊提供的SummaryReport。下面以系統應用典型場景1為例進行分析。

圖22給出了該場景運行后的SummaryReport。

圖22

從圖22可以看出，整個測試過程中我們所關心的各業務（備件信息、查詢、申請表和登錄）的響應時間均超過了性能需求中定義的10秒，因此從總體來說，本系統沒有達到性能要求。

到此為止，已經得出了總體的結論，但是，性能測試結果的分析過程還遠遠沒有結束。因為我們的目的并不僅僅要得出“系統是否滿足預期的性能要求”這樣一個結論，還應該給出更加具有建設性的意見和建議。

例如，還需要考慮：性能是在什么時候開始變壞的？性能可能的瓶頸在哪里？

為此，我們首先關注性能測試過程中業務的執行成功比例。圖23給出了所有事務執行情況的柱狀圖。

圖23

從圖23可以看到，所有的事務執行都為成功，也就是說，測試結果基本可信。另外，從SummaryReport中的HTTP返回碼統計圖（見圖24）中可以看到，大部分的HTTP返回碼都是200和302，這說明應用在HTTP返回層面上是成功的，少部分的404返回碼通過對日志的檢查，可以確認是由于部分圖片文件缺失引起的，而這部分圖片文件的缺失是在開發過程中造成的，并不影響應用本身的正確性，也不影響應用性能測試結果的有效性。

圖24

確認測試結果的有效性之后，接下來對應用的性能表現進行初步的分析。

圖25給出了“申請單”業務的“RunningVuser-AverageTransactionResponseTime關聯曲線，從該關聯圖可以看出，應用系統的性能隨著RunningVusers數量的變化有一個明顯的變化趨勢。

圖25

具體的操作步驟如下：

1. 選中RunningVusers頁面，在圖形上單擊鼠標右鍵，選擇MergeGraph命令。
2. 從彈出的對話框中選擇AverageTransactionResponseTime，從Merge類型中選擇Correlate，單擊OK按鈕。
3. Analysis應用會打開一個新的頁面，該頁面顯示RunningVusers-AverageTransactionResponseTime曲線。

在圖25中，排除那些明顯的離散點，Vuser的數量從0至150增加時，各事務的性能表現基本保持穩定；當Vuser的數量從150至200增加時，事務的響應時間呈緩慢的線性增長狀態；當Vuser的數量超過200時，事務的響應時間急劇增加。

根據本書第1章中描述的性能下降曲線分析法可以知道，150個用戶為最佳狀態下的最大并發用戶數。從圖中可以看到，當Vuser增長到180時，基本上所有事務的響應時間都在10秒以內，因此，根據需求和性能下降曲線分析法，可以得出以下結論：

1. 在系統應用典型場景1條件下，被測系統在180個并發用戶訪問的情況下事務響應時間小于10秒。
2. Vuser為200是該系統性能表現的拐點。
3. “申請單”事務是性能相對最差的事務。

為了確定影響性能的主要因素，我們采用同樣的方法得到RunningVusers-UNIXResources關聯曲線。圖26給出了兩臺服務器的CPU使用狀況和RunningVusers的關聯曲線。

圖26

從圖26可以看到，當Vuser超過110時，應用服務器的CPU使用率就已經超過了預期的75%，而將應用服務器和數據庫服務器的CPU使用率進行對比發現，數據庫服務器的CPU使用率一直都很低。由此可見，應用服務器的CPU應該是系統性能的瓶頸之一。

同樣，兩臺服務器的內存使用狀況和RunningVusers的關聯曲線也可用于比較，在本案例中，經過比較發現，在整個性能測試過程中，兩臺服務器的內存使用都沒有超過可用內存的70%，由此可見，可用內存并不是性能瓶頸之一。

對應用服務器來說，在性能測試中，除了關注服務器的內存使用狀況外，一個更重要的需要關注的內容是JVM內存的使用狀況。

圖27給出了應用服務器的JVM內存使用情況。

圖27

從圖27可以看到，在整個測試過程中，應用服務器的JVM可用內存處于相對充裕的狀況，應該說JVM的可用內存不是性能瓶頸。但需要注意的是，JVM的內存使用呈現出鋸齒狀的波動，很可能在代碼中存在產生了過多的臨時對象等情況。

其他的場景可以采用類似的方法進行分析。分析表明，在測試方案中計劃的3個不同場景均存在同系統應用典型場景1類似的情況。

針對場景1、場景2、場景3的頁面分析

通過以上分析，可以基本解了應用的性能能力以及影響性能的系統瓶頸。在接下來的分析過程中，我們還希望了解到底哪個頁面在測試過程中的性能表現最差，表現差的具體原因是什么。

LoadRunner的Analysis應用提供了對頁面進行分解（breakdown）分析的輔助功能。下面以“申請單”事務為例，說明對頁面進行breakdown分析的方法和過程。

在AverageTransactionResponseTime頁面上單擊鼠標右鍵，從彈出的菜單中選擇ShowTransactionBreakDownTree命令，此時Analysis應用的左側會出現一個TransactionBreakdown樹型窗口，窗口中顯示所有事務的樹型列表（見圖28）。

圖28

在該列表上雙擊需要關注的事務，則可以打開一個新的WebBreakdown頁面（見圖29）。

圖29

從圖29可以看到，左側的Breakdown列表中列出了每個事務所包含的頁面請求動作，而對于每個頁面請求動作，用戶可以從DownloadTimeBreakdown、ComponentBreakdown（overtime）、DownloadTimeBreakdown（overtime）和TimetoFirstBufferBreakdown（overtime）4個不同的角度來對一個請求的響應進行分析。

從分析的角度來說，首先會關注每個請求響應所花費的時間，從而找出幾個最關鍵的請求（頁面），然后對其進行更詳細的分析。以本案例來說，考察“申請單”事務，//server:7001/bill/worklist.jsp?rd=0.5476723708419389請求的響應花費了最長的響應時間。圖30給出了其響應時間的曲線。

圖30

對這個具體的請求，可以首先從ComponentBreakdown（overtime）圖表上看返回頁面的每個組件所花費的具體時間。具體方法是選中ComponentBreakdown（overtime）單選按鈕。

圖31給出了進行ComponentBreakdown（overtime）分解后的曲線圖形。

圖31

結合圖30和圖31可以很清楚地看到，在性能測試執行到45分鐘左右時，返回頁面的幾個部件的響應時間都非常長，最為典型的是tool_del.gif、done_click_bg.gif等圖片文件。而從DownloadTimeBreakdown圖形中可以看到（見圖32），這些圖片都非常?。ㄐ∮?KB），而且這些圖片的平均downloadtime都很短，只在45分鐘附近才出現響應時間急劇增長的情況。

圖32

從這里基本可以斷定，引起這些圖片響應時間過長的問題應該在于系統的吞吐量受到了限制，由于我們關注的部件是靜態的圖片文件，也就是說，該問題主要是由于應用服務器在該時刻處理靜態文件時的吞吐量受到限制而引起的。

為了進一步驗證我們的結論，在TimetoFirstBufferBreakdown（overtime）的圖形中（見圖33）可以看到，在45分鐘左右，請求tool_del.gif文件的所有的時間消耗都是Servertime。

圖33

結合整個測試過程的RunningVusers、HitsperSecond以及Throughput的曲線（見圖34），可以看到，在45分鐘左右，RunningVusers保持在高水平上，但此時的吞吐量有一個明顯的變低的趨勢，說明此時應用服務器已經遇到了瓶頸，而且，該瓶頸表現在請求的靜態文件的響應時間顯著變長。

根據這些分析，基本可以得出以下結論和建議：

1. 在測試進行到45分鐘時，系統遇到了一個明顯的性能瓶頸，該瓶頸的表現是響應時間明顯變長。
2. 該性能瓶頸的產生主要是由應用服務器引起的，從應用服務器的表現來看，在該時刻對靜態文件的請求響應速度非常慢，而且服務器吞吐量明顯受到了制約。
   
    

   圖34

3. 應用服務器的瓶頸之一是服務器的CPU，但并發用戶數應該是一個引起吞吐量制約的因素。
4. 如果需要進一步確定系統的性能瓶頸，建議采用類似RBI的方法，首先純粹通過靜態文件檢查各種不同的并發條件下應用服務器的吞吐量限制，然后與場景的測試結果比較，檢查是否是由于應用服務器本身的吞吐量限制，從而決定進一步的調優策略。
5. 如果最終的問題定位在應用服務器對靜態文件的吞吐量上，可以考慮采用Apache+Tomcat的架構，用Apache處理靜態頁面文件和圖形文件，用Tomcat處理JSP文件。

最后要說明的是，根據我們對測試結果的分析，性能的主要瓶頸在于應用服務器，因此在本案例中基本沒有對數據庫服務器的性能指標進行關注和分析。

針對穩定性測試場景的性能分析

對應用系統的穩定性測試，重點在于通過壓力測試，檢查長時間運行條件下的應用系統運行狀況，以及各服務器的資源使用狀況。

測試設計中設計的運行時間是72小時，主要的測試關注點包括：

1. 服務器內存使用狀況。
2. 應用服務器JVM內存使用狀況。
3. 持續測試過程中的系統性能表現（響應時間）。
4. 數據庫服務器的主要性能指標。

實際測試過程中，由于對場景1～場景3的測試結果表明，系統根本無法支持預期的壓力測試的用戶訪問量，因此沒有對其進行穩定性測試。

針對數據導入場景的性能分析

數據導入場景測試除了關注系統的響應時間等性能表現外，還特別關注服務器的磁盤I/O是否達到磁盤處理能力的極限。

系統響應時間性能的分析與上面的分析過程一樣，對磁盤I/O的關注通過UNIX系統提供的iostat命令獲取相關數據并進行分析。

計算最大磁盤I/O數的公式在本書的第3章中進行了詳細的討論，在此不再贅述。在本案例中，沒有發現系統存在服務器磁盤I/O方面的瓶頸。

四、案例小結

該案例展示了一個完整的應用LoadRunner對Web應用進行性能測試的全過程，它遵循PTGM模型進行性能測試，并重點給出應用LoadRunner進行性能測試需要關注的重點內容，展示了使用LoadRunner進行性能測試結果分析的方法。

該案例系統是一個具有典型代表性的基于J2EE的Web應用系統，采用標準的HTTP協議，因此主要使用LoadRunner這個商業工具作為性能測試工具。本案例非常詳細地描述了LoadRunner在實際應用中需要注意的一些問題，介紹的一些技巧和技術都值得讀者仔細體會。

本案例還額外討論了性能測試時驗證碼的處理方法，并根據一次解決實際問題的方法介紹了session這個對Web系統非常重要的概念。在對驗證碼處理方法的討論中，給出了3種可能的解決方案，逐一討論了各種方案的優點和缺點，并給出了每種方案的適用場合和使用注意事項。

使用LoadRunner對性能測試結果進行輔助分析是使用LoadRunner進行性能測試時的重要內容，本案例通過有針對性地重點描述系統測試結果的分析過程（包括基礎分析和頁面響應分析），并結合性能下降曲線分析方法，演示了對性能測試結果的分析過程。本案例描述的分析過程當然不是唯一的分析方法和過程，但確實是具有代表性的分析方法，希望讀者能夠仔細體會。

當然，就本案例本身來說，并不是針對被測的Web系統的全部性能測試內容（在對本系統的實際性能測試中，我們還按照RBI的方法對其進行了吞吐量測試、并發測試等），而只是為了說明性能測試進行了有針對性的簡化的一個案例描述，因此，讀者在學習體會本案例的過程中，也應該更深入的思考——如果你是這個性能測試項目的負責人，還需要關注哪些方面？