對LoadRunner壓力測試結果進行分析
分析原則：
1. 具體問題具體分析(這是由于不同的應用系統，不同的測試目的，不同的性能關注點)
2. 查找瓶頸時按以下順序，由易到難。
服務器硬件瓶頸 網絡瓶頸(對局域網，可以不考慮) 服務器操作系統瓶頸(參數配置) 中間件瓶頸(參數配置，數據庫，web服務器等) 應用瓶頸(SQL語句、數據庫設計、業務邏輯、算法等)
分析的信息來源：
1. 根據場景運行過程中的錯誤提示信息
2. 根據測試結果收集到的監控指標數據
一.錯誤提示分析
分析實例：
1.Error: Failed to connect to server “172.17.7.230″: [10060] Connection
Error: timed out Error: Server “172.17.7.230″ has shut down the connection prematurely
分析：
A、應用服務死掉。
(小用戶時：程序上的問題。程序上處理數據庫的問題，實際測試中多半是服務器鏈接的配置問題)
B、應用服務沒有死
(應用服務參數設置問題)
對應的Apache和tomcat的最大鏈接數需要修改，如果連接時收到connection refused消息，說明應提高相應的服務器最大連接的設置，增加幅度要根據實際情況和服務器硬件的情況來定，建議每次增加25%!
C、數據庫的連接
(數據庫啟動的最大連接數(跟硬件的內存有關))
D、我們的應用程序spring控制的最大鏈接數太低
2. Error: Page download timeout (120 seconds) has expired
分析：
A、應用服務參數設置太大導致服務器的瓶頸
B、頁面中圖片太多
C、在程序處理表的時候檢查字段太大多
D、實際測試時有些資源需要請求外網，而我們的測試環境是局域網環境
3. Error “http://172.17.7.230/Home.do....”
分析：
A、腳本設計錯誤，造成頁面異常。服務器有響應!
B、并發數過大，造成服務器響應延遲。
4. Error page “text=xxxxx”
分析：
A、腳本設計問題，例如，前一腳本修改了某些內容，造成后面的腳本訪問異常。
B、不確定因素，有時候回放正常的腳本，一放到場景中就出現這樣的錯誤。只能反復修改腳本!
二.監控指標數據分析
1.Vusers數
Loadrunner 系統設置的虛擬用戶數目。Vuser去實際調用事先制作的腳本文件中的應用。
每個Vuser產生響應的操作，所有的操作對服務器形成并發。
顏色 比例 度量 圖最小值 圖平均值 圖最大值 圖中間值 圖SD
1 Run 0.0 21.25 44 41 21.276
在實際測試中，Vusers可以根據實際情況的需要，在測試過程中增加或者減少。
2.最大并發用戶數：
顏色 比例 度量 最小值 平均值 最大值 SD
100 Apache CPU 使用情況(Apache):172.17.7.210 0.777 0.852 0.93 0.043
0.01 已發送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924
0.1 點擊次數/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201
應用系統在當前環境下能承受的最大并發用戶數。
在方案運行中，如果出現了大批用戶的業務操作失敗，或出現了服務器shutdown的情況，則說明在當前環境下，系統承受不了當前并發用戶的負載壓力，那么最大并發用戶數就是前一個沒有出現這種現象的并發用戶數。
從上圖可以看出：在測試運行到4個小時左右的時候，apache的點擊數/秒開始迅速增加!
文章來源于領測軟件測試網 http://www.kjueaiud.com/
