測試結果分析

LoadRunner性能測試結果分析是個復雜的過程，通常可以從結果摘要、并發數、平均事務響應時間、每秒點擊數、業務成功率、系統資源、網頁細分圖、Web服務器資源、數據庫服務器資源等幾個方面分析，如圖1所示。性能測試結果分析的一個重要的原則是以性能測試的需求指標為導向。我們回顧一下本次性能測試的目的，正如所列的指標，本次測試的要求是驗證在30分鐘內完成2000次用戶登錄系統，然后進行考勤業務，最后退出，在業務操作過程中頁面的響應時間不超過3秒，并且服務器的CPU使用率、內存使用率分別不超過75%、70%，那么按照所示的流程，我們開始分析，看看本次測試是否達到了預期的性能指標，其中又有哪些性能隱患，該如何解決。

性能測試結果分析流程圖

結果摘要

LoadRunner進行場景測試結果收集后，首先顯示的該結果的一個摘要信息，如圖2所示。概要中列出了場景執行情況、“StatisticsSummary（統計信息摘要）”、“TransactionSummary（事務摘要）”以及“HTTPResponsesSummary（HTTP響應摘要）”等。以簡要的信息列出本次測試結果。

性能測試結果摘要圖

場景執行情況

該部分給出了本次測試場景的名稱、結果存放路徑及場景的持續時間，如圖3所示。從該圖我們知道，本次測試從15:58:40開始，到16:29:42結束，共歷時31分2秒。與我們場景執行計劃中設計的時間基本吻合。

場景執行情況描述圖

StatisticsSummary（統計信息摘要）

該部分給出了場景執行結束后并發數、總吞吐量、平均每秒吞吐量、總請求數、平均每秒請求數的統計值，如圖4所示。從該圖我們得知，本次測試運行的最大并發數為7，總吞吐量為842,037,409字節，平均每秒的吞吐量為451,979字節，總的請求數為211,974，平均每秒的請求為113.781，對于吞吐量，單位時間內吞吐量越大，說明服務器的處理能越好，而請求數僅表示客戶端向服務器發出的請求數，與吞吐量一般是成正比關系。

統計信息摘要圖

TransactionSummary（事務摘要）

該部分給出了場景執行結束后相關Action的平均響應時間、通過率等情況，如圖5所示。從該圖我們得到每個Action的平均響應時間與業務成功率。

注意：因為在場景的“Run-timeSettings”的“Miscellaneous”選項中將每一個Action當成了一個事務執行，故這里的事務其實就是腳本中的Action。

事務摘要圖

HTTPResponsesSummary（HTTP響應摘要）

該部分顯示在場景執行過程中，每次HTTP請求發出去的狀態，是成功還是失敗，都在這里體現，如圖6所示。從圖中可以看到，在本次測試過程中LoadRunner共模擬發出了211974次請求（與“統計信息摘要”中的“TotalHits”一致），其中“HTTP200”的是209811次，而“HTTP404”則有2163，說明在本次過程中，經過發出的請求大部分都能正確響應了，但還是有部分失敗了，但未影響測試結果，“HTTP200”表示請求被正確響應，而“HTTP404”表示文件或者目錄未能找到。有朋友可能會問，這里出現了404的錯誤，為什么結果還都通過了。出現這樣問題的原因是腳本有些頁面的請求內容并非關鍵點，比如可能請求先前的cookie信息，如果沒有就重新獲取，所以不會影響最終的測試結果。

HTTP響應摘要

常用的HTTP狀態代碼如下：

• 400無法解析此請求。
• 401.1未經授權：訪問由于憑據無效被拒絕。
• 401.2未經授權:訪問由于服務器配置傾向使用替代身份驗證方法而被拒絕。
• 401.3未經授權：訪問由于ACL對所請求資源的設置被拒絕。
• 401.4未經授權：Web服務器上安裝的篩選器授權失敗。
• 401.5未經授權：ISAPI/CGI應用程序授權失敗。
• 401.7未經授權：由于Web服務器上的URL授權策略而拒絕訪問。
• 403禁止訪問：訪問被拒絕。
• 403.1禁止訪問：執行訪問被拒絕。
• 403.2禁止訪問：讀取訪問被拒絕。
• 403.3禁止訪問：寫入訪問被拒絕。
• 403.4禁止訪問：需要使用SSL查看該資源。
• 403.5禁止訪問：需要使用SSL128查看該資源。
• 403.6禁止訪問：客戶端的IP地址被拒絕。
• 403.7禁止訪問：需要SSL客戶端證書。
• 403.8禁止訪問：客戶端的DNS名稱被拒絕。
• 403.9禁止訪問：太多客戶端試圖連接到Web服務器。
• 403.10禁止訪問：Web服務器配置為拒絕執行訪問。
• 403.11禁止訪問：密碼已更改。
• 403.12禁止訪問：服務器證書映射器拒絕了客戶端證書訪問。
• 403.13禁止訪問：客戶端證書已在Web服務器上吊銷。
• 403.14禁止訪問：在Web服務器上已拒絕目錄列表。
• 403.15禁止訪問：Web服務器已超過客戶端訪問許可證限制。
• 403.16禁止訪問：客戶端證書格式錯誤或未被Web服務器信任。
• 403.17禁止訪問：客戶端證書已經到期或者尚未生效。
• 403.18禁止訪問：無法在當前應用程序池中執行請求的URL。
• 403.19禁止訪問：無法在該應用程序池中為客戶端執行CGI。
• 403.20禁止訪問：Passport登錄失敗。
• 404找不到文件或目錄。
• 404.1文件或目錄未找到：網站無法在所請求的端口訪問。

需要注意的是404.1錯誤只會出現在具有多個IP地址的計算機上。如果在特定IP地址/端口組合上收到客戶端請求，而且沒有將IP地址配置為在該特定的端口上偵聽，則IIS返回404.1HTTP錯誤。例如，如果一臺計算機有兩個IP地址，而只將其中一個IP地址配置為在端口80上偵聽，則另一個IP地址從端口80收到的任何請求都將導致IIS返回404.1錯誤。只應在此服務級別設置該錯誤，因為只有當服務器上使用多個IP地址時才會將它返回給客戶端。

• 404.2文件或目錄無法找到：鎖定策略禁止該請求。
• 404.3文件或目錄無法找到：MIME映射策略禁止該請求。
• 405用于訪問該頁的HTTP動作未被許可。
• 406客戶端瀏覽器不接受所請求頁面的MIME類型。
• 407Web服務器需要初始的代理驗證。
• 410文件已刪除。
• 412客戶端設置的前提條件在Web服務器上評估時失敗。
• 414請求URL太大，因此在Web服務器上不接受該URL。
• 500服務器內部錯誤。
• 500.11服務器錯誤：Web服務器上的應用程序正在關閉。
• 500.12服務器錯誤：Web服務器上的應用程序正在重新啟動。
• 500.13服務器錯誤：Web服務器太忙。
• 500.14服務器錯誤：服務器上的無效應用程序配置。
• 500.15服務器錯誤：不允許直接請求GLOBAL.ASA。
• 500.16服務器錯誤：UNC授權憑據不正確。
• 500.17服務器錯誤：URL授權存儲無法找到。
• 500.18服務器錯誤：URL授權存儲無法打開。
• 500.19服務器錯誤：該文件的數據在配置數據庫中配置不正確。
• 500.20服務器錯誤：URL授權域無法找到。
• 500100內部服務器錯誤：ASP錯誤。
• 501標題值指定的配置沒有執行。
• 502Web服務器作為網關或代理服務器時收到無效的響應。

并發數分析

“RunningVusers（運行的并發數）”顯示了在場景執行過程中并發數的執行情況。它們顯示Vuser的狀態、完成腳本的Vuser的數量以及集合統計信息，將這些圖與事務圖結合使用可以確定Vuser的數量對事務響應時間產生的影響。圖7顯示了在OA系統考勤業務性能測試過程中Vusers運行情況，從圖中我們可以看到，Vusers的運行趨勢與我們場景執行計劃中的設置是一樣，表明在場景執行過程中，Vusers是按照我們預期的設置運行的，沒有Vuser出現運行錯誤，這樣從另一個側面說明我們的參數化設置是正確的，因為使用唯一數進行參數化設置，如果設置不正確，將會導致Vuser運行錯誤。在腳本中我們加入了這樣一段代碼：

if(atoi(lr_eval_string("{num}"))>0){

lr_output_message("登錄成功，繼續執行.");

}

else{

lr_error_message("登錄失敗，退出測試");

return-1;

}

上述代碼的意思是說，如果登錄失敗了，就退出腳本的迭代，那么什么原因可能會導致登錄失敗呢？就是我們前面參數化的設置，一旦Vuser分配不到正確的登錄賬號，就可能導致登錄失敗，從而引起Vuser停止運行。所以，從圖7的表現，可以認為參數化是沒有問題的。

運行的并發數圖

測試腳本中我們還使用了集合點，那么這里還可以看看集合點在場景執行過程中的表現，點擊左邊的“NewGraph”，出現圖8，展開“Vusers”前的加號，雙擊“Rendezvous”，出現集合點的圖形后，點擊【Close】，關閉添加新圖界面。

添加集合點統計圖

集合點的圖形如圖9所示，從圖中可以看到，所有用戶到達集合點后，立刻就釋放了。與之前設定的集合點策略設置“所有運行用戶到達后釋放“是一致的。假設這樣的一種情況，Running的Vusers有10個，集合點策略設置是“所有運行用戶到達后釋放”，而集合點圖形顯示的最大釋放Vusers是7個，那么就表示有些Vuser超時了，引起超時的原因可能是Vuser得到的響應超時了，可以結合平均事務響應時間再詳細分析原因。

集合點狀態圖

我們本次測試RunningVusers與集合點是一致，說明整個場景執行過程中，并發數用戶的執行正確，OA系統測試服務器能夠應付7個并發用戶的業務操作。

響應時間

在性能測試要求中我們知道，有一項指標是要求登錄、考勤業務操作的頁面響應時間不超過3秒，那么本次測試是否達到了這個要求呢？我們先來看“AverageTransactionResponseTime（平均事務響應時間圖）”（圖10），這張圖是平均事務響應時間與結果摘要中的“TransactionSummary”合成的。

平均事務響應時間圖

從圖形下部我們可以看到，登錄部分對應的Action是“submit_login”，考勤業務提交對應的Action是“submit_sign”，他們的“AverageTime（平均響應時間為）”分別是4.425秒與0.848秒，從這兩個數值來看，考勤業務的事務響應時間0.848秒小于預期的3秒，達到了要求，而登錄是4.425秒，大于預期的3秒，不符合要求。這樣的結果是不正確的，因為在統計的登錄業務的時候，我們沒有去除思考時間，所以，登錄功能的實際事務時間應該是4.425秒-3秒=1.425秒，小于預期的3秒，故登錄業務的事務響應時間也達到了我們的要求。在平時的性能測試活動中，統計結果的時候需要去掉思考時間，加上思考時間是為了真實的模擬用戶環境，統計結果中除去思考時間是為了更真實的反映服務器的處理能力，兩者并不矛盾。

看完了“AverageTime”，我們再看“90PercentTime”，這個時間從某種程度來說，更準確衡量了測試過程中各個事務的真實情況，表示90%的事務，服務器的響應都維持在某個值附近，“AverageTime”值對于平均事務響應時間變動趨勢很大的情況統計就不準確了，比如有三個時間：1秒、5秒、12秒，則平均時間為6秒，而另外一種情況：5秒、6秒、7秒，平均時間也為6秒，顯然第二種比第一種要穩定多了。所以，我們在查看平均事務響應時間的時候，先看整體曲線走勢，如果整體趨勢比較平滑，沒有忽上忽下的波動情況，取“AverageTime”與“90PercentTime”都可以，如果整體趨勢毫無規律，波動非常大，我們就不用“AverageTime”而使用“90PercentTime”可能更真實些。

從圖10可以看出，所有Action平均事務響應時間的趨勢都非常平滑，所以使用“AverageTime”與“90PercentTime”差別不是很大，用哪個都可以。這里是使用最常用的統計方法“90PercentTime”。登錄業務的“90PercentTime”是5.298秒-3秒（思考時間）=2.298秒，考勤業務的“90PercentTime”是1.469秒，沒有思考時間，那么就是實打實的啦。根據上面的計算，本次測試結果記錄如表1所示。

測試結果對照表一

每秒點擊數

HitsperSecond（每秒點擊數）”反映了客戶端每秒鐘向服務器端提交的請求數量，如果客戶端發出的請求數量越多，與之相對的“AverageThroughput(bytes/second)”也應該越大，并且發出的請求越多會對平均事務響應時間造成影響，所以在測試過程中往往將這三者結合起來分析。圖11顯示的是“HitsperSecond”與“AverageThroughput(bytes/second)”的復合圖，從圖中可以看出，兩種圖形的曲線都正常并且基本一致，說明服務器能及時的接受客戶端的請求，并能夠返回結果。如果“HitsperSecond”正常，而“AverageThroughput(bytes/second)”不正常，則表示服務器雖然能夠接受服務器的請求，但返回結果較慢，可能是程序處理緩慢。如果“HitsperSecond”不正常，則說明客戶端存在問題，那種問題一般是網絡引起的，或者錄制的腳本有問題，未能正確的模擬用戶的行為。具體問題具體分析，這里僅給出一些建議。

每秒點擊數與每秒吞吐量復合圖

對于本次測試來說，“HitsperSecond”與“AverageThroughput(bytes/second)”都是正常的，而且整體表現還是不錯的。

一般情況下，這兩種指標用于性能調優，比如給定了幾個條件，去檢測另外一個條件，用這兩個指標衡量，往往起到很好的效果。比如要比較某兩種硬件平臺的優劣，就可以使用相同的配置方法部署軟件系統，然后使用相同的腳本、場景設計、統計方法去分析，最終得出一個較優的配置。

業務成功率

“業務成功率”這個指標在很多系統中都提及到，比如電信的、金融的、企業資源管理的等等。舉個例子，我們樓下的建行，假如每天的業務類別是這樣的：20個開戶，5個銷戶，300個存款，500取款，100個匯款等，那么在做他們的營業系統測試時就需要考慮業務成功率了，一般不得低于98%。具體的業務成功率是什么意思呢？排除那些復雜的業務，比如異步處理的業務（移動的套卡開通就是異步的），業務成功率就是事務成功率，用戶一般把一個Aciton當做一筆業務，在LoadRunner場景執行中一筆交易稱為一個事務。所以，說業務成功率其實就是事務成功率、通過率的意思。在“TransactionSummary”中我們可以很明確的看到每個事務的執行狀態，如圖12所示。

事務狀態統計圖

從圖中可以看出，所有的Aciton都是綠色的，即表示為Passed，同時除了vuser_init與vuser_end兩個事務，其他的事務通過數為2163，也就表明在30分鐘的時間里，共完成了2163次登錄考勤業務操作。那么根據這些可以判斷本次測試登錄業務與考勤業務的成功率是100%，再次更新測試結果記錄表如表2所示。

測試結果對照表二

系統資源

系統資源圖顯示了在場景執行過程中被監控的機器系統資源使用情況，一般情況下監控機器的CPU、內存、網絡、磁盤等各個方面。本次測試監控的是測試服務器的CPU使用率與內存使用率，以及處理器隊列長度，具體的數據如圖13所示。

測試服務器系統資源監控結果圖

從圖中可以看出，CPU使用率、可用物理內存、CPU的隊列長度三個指標的曲線逗較為平滑，三者的平均值分別為：53.582%、83.456M、8.45，而測試服務器總的物理內存為384M，那么內存使用率為（384-83.456）/384=78.26%，根據本次性能測試要求的：CPU使用率不超過75%，物理內存使用率不超過70%這兩點來看，內存的使用率78.26%大于預期的70%，故內存使用率不達標。根據Windwos資源性能指標的解釋，一般情況下，如果“ProcessorQueueLength（處理器隊列長度）”一直超過二，則可能表示處理器堵塞，我們這里監控出來的數值是8.45，而且總體上保持平衡，那么由此推斷，測試服務器的CPU也可能是個瓶頸。同時在測試過程中，場景執行到23分半鐘的時候，報出了錯誤！未找到引用源。的錯誤，意思是說被監控的服務器當前無法再進行計數器數據的獲取了，所以，本次操作系統資源的監控只得到了場景執行的前23分半鐘的數據。這樣對本次測試結果有一定的影響。

獲得上述數據后，最新的測試結果記錄表如表3所示。

測試結果對照表三

從上表數據來看，本次測試總體上已經達到了預期的性能指標，但從其他的數據，比如CPU的隊列長度、內存使用率來看，被測服務器的硬件資源需要提升。

網頁細分圖

網頁細分圖可以評估頁面內容是否影響事務響應時間。使用網頁細分圖，可以分析網站上有問題的元素（例如下載很慢的圖像或打不開的鏈接）。

我們這里查看一下網頁細分圖中的“PageDownloadTimeBreakdown”，點擊錯誤！未找到引用源。左邊的“NewGraph”，出現圖14，展開“WebPageDiagnostics”前的加號，雙擊“PageDownloadTimeBreakdown”，待出現“PageDownloadTimeBreakdown”監控圖后，點擊【Close】按鈕關閉添加監控圖界面。

添加網頁細分圖

在監控圖列表中，我們看到圖15，從圖中我們看到，在所有的頁面中，登錄后的用個人面頁面“//192.168.0.52:8080/oa/oa.jsp”的下載時間最長。

網頁下載時間細分圖

圖16詳細列出了每個頁面所消耗的時間分布，圖中每一個指標含義見表4所示。該表由LoadRunner使用手冊提供。通過這些指標的數據，我們可以輕易的判斷是哪個頁面、哪個請求導致了響應時間變長，甚至響應失敗。

oa.jsp頁面下載時間分布圖

網頁下載時間細分指標說明

對于本次測試，從網頁細分圖來看，基本上每個頁面的加載時間都是預期范圍內，oa.jsp頁面因為集成了用戶的個人工作平臺，需要檢索很多的數據，并合成了很多圖片，所以相應的加載時間較長，這是正確的。

Web服務器資源

上述所有的監控圖形LoadRunner都可以提供，但對于某些測試監控圖來說，LoadRunner就沒有提供了，期望其新版支持這些功能，當然想監控Tomcat、Jboss或者其他的Web服務器可以SiteScope工具，這個工具配置較為復雜，根據個人需要吧。我這里監控Tomcat使用的是ManageEngineApplicationsManager8的試用版，測試結束后得出Tomcat的JVM使用率如圖17所示。

TomcatJVM使用率監視圖

從圖中我們可以明顯看出，Tomcat的JVM使用率不斷上升，配置Tomcat時共分配了100M左右的物理內存給其，測試初期使用的JVM相對來說較少，我們的測試場景是從15:58:40開始，到16:29:42結束，共歷時31分2秒。從圖中看到，從16:00到16:30這個時間內，也就是測試場景執行期間，JVM的使用率不斷上升，并沒有在請求達到均衡狀態后也呈現一種平衡狀態，所以，從這點可以推斷，如果測試場景繼續執行，或者加大并發數，最終必將導致Tomcat內存不夠用而報出“OutOfMemory”內存溢出的錯誤。在正常情況下，內存的使用應該與“HitperSecond”、“AverageThroughput(bytes/second)”等監控圖的圖形走勢是一致的。

從上述過程可以得出一個結論，出現圖17中的問題，可能有兩個原因：

1. Tomcat的內存分配不足
2. 程序代碼有錯誤，可能導致內存泄露

解決方法：

1. 為Tomcat分配更多的內存，如果是使用的catalina.sh或Catalina.bat啟動的Tomcat，則可在這兩個文件中添加“SETCATALINA_OPTS=-Xms300m–Xmx300m”，如果使用的winnt服務方式啟動的Tomcat，則可在“運行”中輸入“regedit”進入注冊表，然后在“HKEY_LOCAL_MACHINE-->SOFTWARE-->ApacheSoftwareFoundation-->ProcessRunner1.0-->Tomcat5-->Parameters”修改兩個屬性，一個是JvmMs，另外一個是JvmMx，如圖18所示。
2. 檢查程序代碼，使用一些內存泄露檢查工具進行清查。
   
    

   修改Tocat的JVM數據

數據庫服務器資源

數據庫服務器資源監控相對來說就復雜的多了，現在常用的數據有Mysql、SQLServer、Oracle、DB2等，LoadRunner提供對后面幾種數據庫的監控方法，但對Mysql沒有提供對應的監控方法。他不提供，咱們就自己找監控工具，我這里使用的是Spotlight，該工具監控數據庫的好處是配置連接簡單，不僅能監控數據庫，還能監控操作系統的資源，監控結果直觀明了。錯誤！未找到引用源。顯示了Mysql數據庫在場景執行過程中SQL語句的執行情況，從圖中可以看到，“Selects（查詢）”與“Inserts（插入）”兩種語句執行的趨勢在場景執行過程中是比較平滑，并且測試中沒有錯誤發現，也就說明在處理相關業務時Mysql的處理是正常的。假如這兩種SQL語句任何一個出現波動很大的情況，就可以推出在場景執行過程中存在頁面錯誤，因為這些語句不執行，就表明某些頁面未被加載或者某些功能未被使用。在本次測試中，OA系統的“oa.jsp”頁面有大量的“Selects（查詢）”語句，而考勤操作則是“Inserts（插入）”，所以，只要有一方出問題，必然表示測試過程中存在頁面打不開或者考勤不成功的錯誤。

通過前面的分析，在查看"錯誤！未找到引用源。"中的SQL語句執行狀態，本次測試在頁面訪問、功能執行方面是沒有問題的。

原文轉載自：螞蟻互聯