測試結果分析
LoadRunner性能測試結果分析是個複雜的過程，通常可以從結果摘要、併發數、平均事務響應時間、每秒點擊數、業務成功率、系統資源、網頁細分圖、Web服務器資源、數據庫服務器資源等幾個方面分析，如圖1- 1所示。性能測試結果分析的一個重要的原則是以性能測試的需求指標爲導向。我們回顧一下本次性能測試的目的，正如所列的指標，本次測試的要求是驗證在30分鐘內完成2000次用戶登錄系統，然後進行考勤業務，最後退出，在業務操作過程中頁面的響應時間不超過3秒，並且服務器的CPU使用率、內存使用率分別不超過75%、70%，那麼按照所示的流程，我們開始分析，看看本次測試是否達到了預期的性能指標，其中又有哪些性能隱患，該如何解決。
圖1- 1性能測試結果分析流程圖
結果摘要
LoadRunner進行場景測試結果收集後，首先顯示的該結果的一個摘要信息，如圖1- 2所示。概要中列出了場景執行情況、“Statistics Summary（統計信息摘要）”、“Transaction Summary（事務摘要）”以及“HTTP Responses Summary（HTTP響應摘要）”等。以簡要的信息列出本次測試結果。
圖1- 2性能測試結果摘要圖
場景執行情況
該部分給出了本次測試場景的名稱、結果存放路徑及場景的持續時間，如圖5- 3所示。從該圖我們知道，本次測試從15:58:40開始，到16:29:42結束，共歷時31分2秒。與我們場景執行計劃中設計的時間基本吻合。
圖1- 3場景執行情況描述圖
Statistics Summary（統計信息摘要）
該部分給出了場景執行結束後併發數、總吞吐量、平均每秒吞吐量、總請求數、平均每秒請求數的統計值，如圖5- 4所示。從該圖我們得知，本次測試運行的最大併發數爲7，總吞吐量爲842,037,409字節，平均每秒的吞吐量爲451,979字節，總的請求數爲211,974，平均每秒的請求爲113.781；
對於吞吐量，單位時間內吞吐量越大，說明服務器的處理能越好，而請求數僅表示客戶端向服務器發出的請求數，與吞吐量一般是成正比關係。
圖1- 4統計信息摘要圖
Transaction Summary（事務摘要）
該部分給出了場景執行結束後相關Action的平均響應時間、通過率等情況，如圖1- 5所示。從該圖我們得到每個Action的平均響應時間與業務成功率。
注意：
因爲在場景的“Run-time Settings”的“Miscellaneous”選項中將每一個Action當成了一個事務執行，故這裏的事務其實就是腳本中的Action。
圖1- 5事務摘要圖
HTTP Responses Summary（HTTP響應摘要）
該部分顯示在場景執行過程中，每次HTTP請求發出去的狀態，是成功還是失敗，都在這裏體現，如圖1- 6所示。從圖中可以看到，在本次測試過程中LoadRunner共模擬發出了211974次請求（與“統計信息摘要”中的“Total Hits”一致），其中“HTTP 200”的是209811次，而“HTTP 404”則有2163，說明在本次過程中，經過發出的請求大部分都能正確響應了，但還是有部分失敗了，但未影響測試結果，“HTTP 200”表示請求被正確響應，而“HTTP 404”表示文件或者目錄未能找到。
有朋友可能會問，這裏出現了404的錯誤，爲什麼結果還都通過了。出現這樣問題的原因是腳本有些頁面的請求內容並非關鍵點，比如可能請求先前的cookie信息，如果沒有就重新獲取，所以不會影響最終的測試結果。
圖1- 6 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 禁止訪問：需要使用 SSL 128 查看該資源。
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.1 HTTP錯誤。例如，如果一臺計算機有兩個IP地址，而只將其中一個IP地址配置爲在端口80上偵聽，則另一個IP地址從端口80收到的任何請求都將導致IIS返回404.1錯誤。只應在此服務級別設置該錯誤，因爲只有當服務器上使用多個IP地址時纔會將它返回給客戶端。
404.2 文件或目錄無法找到：鎖定策略禁止該請求。
404.3 文件或目錄無法找到：MIME 映射策略禁止該請求。
405 用於訪問該頁的 HTTP 動作未被許可。
406 客戶端瀏覽器不接受所請求頁面的 MIME 類型。
407 Web 服務器需要初始的代理驗證。
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 授權域無法找到。
500 100 內部服務器錯誤：ASP 錯誤。
501 標題值指定的配置沒有執行。
502 Web 服務器作爲網關或代理服務器時收到無效的響應。
併發數分析
“Running Vusers（運行的併發數）”顯示了在場景執行過程中併發數的執行情況。它們顯示Vuser的狀態、完成腳本的Vuser的數量以及集合統計信息，將這些圖與事務圖結合使用可以確定Vuser的數量對事務響應時間產生的影響。圖1- 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停止運行。所以，從圖1- 7的表現，可以認爲參數化是沒有問題的。
圖1- 7運行的併發數圖
測試腳本中我們還使用了集合點，那麼這裏還可以看看集合點在場景執行過程中的表現，點擊左邊的“New Graph”，出現圖1- 8，展開“Vusers”前的加號，雙擊“Rendezvous”，出現集合點的圖形後，點擊【Close】，關閉添加新圖界面。
圖1- 8添加集合點統計圖
集合點的圖形如圖1- 9所示，從圖中可以看到，所有用戶到達集合點後，立刻就釋放了。與之前設定的集合點策略設置“所有運行用戶到達後釋放“是一致的。
假設這樣的一種情況，Running的Vusers有10個，集合點策略設置是“所有運行用戶到達後釋放”，而集合點圖形顯示的最大釋放Vusers是7個，那麼就表示有些Vuser超時了，引起超時的原因可能是Vuser得到的響應超時了，可以結合平均事務響應時間再詳細分析原因。
圖1- 9集合點狀態圖
我們本次測試Running Vusers與集合點是一致，說明整個場景執行過程中，併發數用戶的執行正確，OA系統測試服務器能夠應付7個併發用戶的業務操作。
響應時間
在性能測試要求中我們知道，有一項指標是要求登錄、考勤業務操作的頁面響應時間不超過3秒，那麼本次測試是否達到了這個要求呢？我們先來看“Average Transaction Response Time（平均事務響應時間圖）”（圖1- 10），這張圖是平均事務響應時間與結果摘要中的“Transaction Summary”合成的。
圖1- 10平均事務響應時間圖
從圖形下部我們可以看到，登錄部分對應的Action是“submit_login”，考勤業務提交對應的Action是“submit_sign”，他們的“Average Time（平均響應時間爲）”分別是4.425秒與0.848秒，從這兩個數值來看，考勤業務的事務響應時間0.848秒小於預期的3秒，達到了要求，而登錄是4.425秒，大於預期的3秒，不符合要求。這樣的結果是不正確的，因爲在統計的登錄業務的時候，我們沒有去除思考時間，所以，登錄功能的實際事務時間應該是4.425秒-3秒=1.425秒，小於預期的3秒，故登錄業務的事務響應時間也達到了我們的要求。
在平時的性能測試活動中，統計結果的時候需要去掉思考時間，加上思考時間是爲了真實的模擬用戶環境，統計結果中除去思考時間是爲了更真實的反映服務器的處理能力，兩者並不矛盾。
看完了“Average Time”，我們再看“90 Percent Time”，這個時間從某種程度來說，更準確衡量了測試過程中各個事務的真實情況，表示90%的事務，服務器的響應都維持在某個值附近，“Average Time”值對於平均事務響應時間變動趨勢很大的情況統計就不準確了，比如有三個時間：1秒、5秒、12秒，則平均時間爲6秒，而另外一種情況：5秒、6秒、7秒，平均時間也爲6秒，顯然第二種比第一種要穩定多了。所以，我們在查看平均事務響應時間的時候，先看整體曲線走勢，如果整體趨勢比較平滑，沒有忽上忽下的波動情況，取“Average Time”與“90 Percent Time”都可以，如果整體趨勢毫無規律，波動非常大，我們就不用“Average Time”而使用“90 Percent Time”可能更真實些。
從圖1- 10可以看出，所有Action平均事務響應時間的趨勢都非常平滑，所以使用“Average Time”與“90 Percent Time”差別不是很大，用哪個都可以。這裏是使用最常用的統計方法“90 Percent Time”。登錄業務的“90 Percent Time”是5.298秒-3秒（思考時間）=2.298秒，考勤業務的“90 Percent Time”是1.469秒，沒有思考時間，那麼就是實打實的啦。根據上面的計算，本次測試結果記錄如表1所示。
測試項 | 目標值 | 實際值 | 是否通過 |
登錄業務響應時間 | <=3秒 | 2.298秒 | Y |
考勤業務響應時間 | <=3秒 | 1.469秒 | Y |
登錄業務成功率 | 100% | ||
考勤業務成功率 | 100% | ||
登錄業務總數 | 30分鐘完成2000 | ||
考勤業務總數 | 30分鐘完成2000 | ||
CPU使用率 | <75% | ||
內存使用率 | <70% |
表1測試結果對照表一
每秒點擊數
“Hits per Second（每秒點擊數）”反映了客戶端每秒鐘向服務器端提交的請求數量，如果客戶端發出的請求數量越多，與之相對的“Average Throughput (bytes/second)”也應該越大，並且發出的請求越多會對平均事務響應時間造成影響，所以在測試過程中往往將這三者結合起來分析。圖1- 11顯示的是“Hits per Second”與“Average Throughput(bytes/second)”的複合圖，從圖中可以看出，兩種圖形的曲線都正常並且基本一致，說明服務器能及時的接受客戶端的請求，並能夠返回結果。如果“Hits per Second”正常，而“Average Throughput (bytes/second)”不正常，則表示服務器雖然能夠接受服務器的請求，但返回結果較慢，可能是程序處理緩慢。如果“Hits per Second”不正常，則說明客戶端存在問題，那種問題一般是網絡引起的，或者錄製的腳本有問題，未能正確的模擬用戶的行爲。具體問題具體分析，這裏僅給出一些建議。
圖1- 11每秒點擊數與每秒吞吐量複合圖
對於本次測試來說，“Hits per Second”與“Average Throughput (bytes/second)”都是正常的，而且整體表現還是不錯的。
一般情況下，這兩種指標用於性能調優，比如給定了幾個條件，去檢測另外一個條件，用這兩個指標衡量，往往起到很好的效果。比如要比較某兩種硬件平臺的優劣，就可以使用相同的配置方法部署軟件系統，然後使用相同的腳本、場景設計、統計方法去分析，最終得出一個較優的配置。
業務成功率
“業務成功率”這個指標在很多系統中都提及到，比如電信的、金融的、企業資源管理的等等。舉個例子，我們樓下的建行，假如每天的業務類別是這樣的：20個開戶，5個銷戶，300個存款，500取款，100個匯款等，那麼在做他們的營業系統測試時就需要考慮業務成功率了，一般不得低於98%。具體的業務成功率是什麼意思呢？排除那些複雜的業務，比如異步處理的業務（移動的套卡開通就是異步的），業務成功率就是事務成功率，用戶一般把一個Aciton當做一筆業務，在LoadRunner場景執行中一筆交易稱爲一個事務。所以，說業務成功率其實就是事務成功率、通過率的意思。在“Transaction Summary”中我們可以很明確的看到每個事務的執行狀態，如圖1- 12所示。
圖1- 12事務狀態統計圖
從圖中可以看出，所有的Aciton都是綠色的，即表示爲Passed，同時除了vuser_init與vuser_end兩個事務，其他的事務通過數爲2163，也就表明在30分鐘的時間裏，共完成了2163次登錄考勤業務操作。那麼根據這些可以判斷本次測試登錄業務與考勤業務的成功率是100%，再次更新測試結果記錄表如表2所示。
測試項 | 目標值 | 實際值 | 是否通過 |
登錄業務響應時間 | <=3秒 | 2.298秒 | Y |
考勤業務響應時間 | <=3秒 | 1.469秒 | Y |
登錄業務成功率 | 100% | 100% | Y |
考勤業務成功率 | 100% | 100% | Y |
登錄業務總數 | 30分鐘完成2000 | 2163 | Y |
考勤業務總數 | 30分鐘完成2000 | 2163 | Y |
CPU使用率 | <75% | ||
內存使用率 | <70% |
表2測試結果對照表二
系統資源
系統資源圖顯示了在場景執行過程中被監控的機器系統資源使用情況，一般情況下監控機器的CPU、內存、網絡、磁盤等各個方面。本次測試監控的是測試服務器的CPU使用率與內存使用率，以及處理器隊列長度，具體的數據如圖1- 13所示。
圖1- 13測試服務器系統資源監控結果圖
從圖中可以看出，CPU使用率、可用物理內存、CPU的隊列長度三個指標的曲線逗較爲平滑，三者的平均值分別爲：53.582%、83.456M、8.45，而測試服務器總的物理內存爲384M，那麼內存使用率爲（384-83.456）/384=78.26%，根據本次性能測試要求的：CPU使用率不超過75%，物理內存使用率不超過70%這兩點來看，內存的使用率78.26%大於預期的70%，故內存使用率不達標。根據Windwos資源性能指標的解釋，一般情況下，如果“Processor Queue Length（處理器隊列長度）”一直超過二，則可能表示處理器堵塞，我們這裏監控出來的數值是8.45，而且總體上保持平衡，那麼由此推斷，測試服務器的CPU也可能是個瓶頸。同時在測試過程中，場景執行到23分半鐘的時候，報出了錯誤！未找到引用源。的錯誤，意思是說被監控的服務器當前無法再進行計數器數據的獲取了，所以，本次操作系統資源的監控只得到了場景執行的前23分半鐘的數據。這樣對本次測試結果有一定的影響。
獲得上述數據後，最新的測試結果記錄表如表3所示。
測試項 | 目標值 | 實際值 | 是否通過 |
登錄業務響應時間 | <=3秒 | 2.298秒 | Y |
考勤業務響應時間 | <=3秒 | 1.469秒 | Y |
登錄業務成功率 | 100% | 100% | Y |
考勤業務成功率 | 100% | 100% | Y |
登錄業務總數 | 30分鐘完成2000 | 2163 | Y |
考勤業務總數 | 30分鐘完成2000 | 2163 | Y |
CPU使用率 | <75% | 53.582% | Y |
內存使用率 | <70% | 78.26% | N |
表3測試結果對照表三
從上表數據來看，本次測試總體上已經達到了預期的性能指標，但從其他的數據，比如CPU的隊列長度、內存使用率來看，被測服務器的硬件資源需要提升。
網頁細分圖
網頁細分圖可以評估頁面內容是否影響事務響應時間。使用網頁細分圖，可以分析網站上有問題的元素（例如下載很慢的圖像或打不開的鏈接）。
我們這裏查看一下網頁細分圖中的“Page Download Time Breakdown”。左邊的“New Graph”，出現圖1- 14，展開“Web Page Diagnostics”前的加號，雙擊“Page Download Time Breakdown”，待出現“Page Download Time Breakdown”監控圖後，點擊【Close】按鈕關閉添加監控圖界面。
圖1- 14添加網頁細分圖
在監控圖列表中，我們看到圖1- 15，從圖中我們看到，在所有的頁面中，登錄後的用個人面頁面“http://192.168.0.52:8080/oa/oa.jsp”的下載時間最長。
圖1- 15網頁下載時間細分圖
圖1- 16詳細列出了每個頁面所消耗的時間分佈，圖中每一個指標含義見表4所示。該表由LoadRunner使用手冊提供。通過這些指標的數據，我們可以輕易的判斷是哪個頁面、哪個請求導致了響應時間變長，甚至響應失敗。
圖1- 16 oa.jsp頁面下載時間分佈圖
名稱 | 描述 |
Client Time | 顯示因瀏覽器思考時間或其他與客戶端有關的延遲而使客戶機上的請求發生延遲時，所經過的平均時間。 |
Connection Time | 顯示與包含指定URL的Web服務器建立初始連接所需的時間。連接度量是一個很好的網絡問題指示器。此外，它還可表明服務器是否對請求做出響應。 |
DNS Resolution Time | 顯示使用最近的DNS服務器將DNS名稱解析爲IP地址所需的時間。DNS查找度量是指示 DNS解析問題或DNS服務器問題的一個很好的指示器。 |
Error Time | 顯示從發出HTTP請求到返回錯誤消息（僅限於HTTP錯誤）這期間經過的平均時間。 |
First Buffer Time | 顯示從初始HTTP請求（通常爲GET）到成功收回來自Web服務器的第一次緩衝時爲止所經過的時間。第一次緩衝度量是很好的Web 服務器延遲和網絡滯後指示器。 （注意：由於緩衝區大小最大爲8K，因此第一次緩衝時間可能也就是完成元素下載所需的時間。） |
FTP Autherntication Time | 顯示驗證客戶端所用的時間。如果使用 FTP，則服務器在開始處理客戶端命令之前，必須驗證該客戶端。FTP驗證度量僅適用於 FTP協議通信 |
Receive Time | 顯示從服務器收到最後一個字節並完成下載之前經過的時間。接收度量是很好的網絡質量指示器（查看用來計算接收速率的時間 / 大小比率）。 |
SSL Handshaking Time | 顯示建立SSL連接（包括客戶端hello、服務器hello、客戶端公用密鑰傳輸、服務器證書傳輸和其他部分可選階段）所用的時間。此時刻後，客戶端和服務器之間的所有通信都被加密。SSL握手度量僅適用於HTTPS通信。 |
表4網頁下載時間細分指標說明
對於本次測試，從網頁細分圖來看，基本上每個頁面的加載時間都是預期範圍內，oa.jsp頁面因爲集成了用戶的個人工作平臺，需要檢索很多的數據，併合成了很多圖片，所以相應的加載時間較長，這是正確的。
Web服務器資源
上述所有的監控圖形LoadRunner都可以提供，但對於某些測試監控圖來說，LoadRunner就沒有提供了，期望其新版支持這些功能，當然想監控Tomcat、Jboss或者其他的Web服務器可以SiteScope工具，這個工具配置較爲複雜，根據個人需要吧。我這裏監控Tomcat使用的是ManageEngine Applications Manager 8的試用版，測試結束後得出Tomcat的JVM使用率如圖1- 17所示。
圖1- 17 Tomcat JVM使用率監視圖
從圖中我們可以明顯看出，Tomcat的JVM使用率不斷上升，配置Tomcat時共分配了100M左右的物理內存給其，測試初期使用的JVM相對來說較少，我們的測試場景是從15:58:40開始，到16:29:42結束，共歷時31分2秒。從圖中看到，從16:00到16:30這個時間內，也就是測試場景執行期間，JVM的使用率不斷上升，並沒有在請求達到均衡狀態後也呈現一種平衡狀態，所以，從這點可以推斷，如果測試場景繼續執行，或者加大併發數，最終必將導致Tomcat內存不夠用而報出“Out Of Memory”內存溢出的錯誤。在正常情況下，內存的使用應該與“Hit per Second”、“Average Throughput (bytes/second)”等監控圖的圖形走勢是一致的。
從上述過程可以得出一個結論，出現圖1- 17中的問題，可能有兩個原因：
1、 Tomcat的內存分配不足；
2、 程序代碼有錯誤，可能導致內存泄露。
解決方法：
1、 爲Tomcat分配更多的內存，如果是使用的catalina.sh或Catalina.bat啓動的Tomcat，則可在這兩個文件中添加“SET CATALINA_OPTS= -Xms300m–Xmx300m”，如果使用的winnt服務方式啓動的Tomcat，則可在“運行”中輸入“regedit”進入註冊表，然後在“HKEY_LOCAL_MACHINE-->SOFTWARE-->Apache Software Foundation-->Process Runner 1.0-->Tomcat5-->Parameters”修改兩個屬性，一個是JvmMs，另外一個是JvmMx，如圖1- 18所示。
2、 檢查程序代碼，使用一些內存泄露檢查工具進行清查。
圖1- 18修改Tocat的JVM數據
數據庫服務器資源
數據庫服務器資源監控相對來說就複雜的多了，現在常用的數據有Mysql、SQL Server、Oracle、DB2等，LoadRunner提供對後面幾種數據庫的監控方法，但對Mysql沒有提供對應的監控方法。他不提供，咱們就自己找監控工具，我這裏使用的是Spotlight，該工具監控數據庫的好處是配置連接簡單，不僅能監控數據庫，還能監控操作系統的資源，監控結果直觀明瞭。
轉自：http://www.51testing.com/html/21/562021-847976.html