一、
LoadRunner測試結果分析之我見
LoadRunner生成測試結果並不代表着這次測試結果的結束，相反，這次測試結果的重頭戲才剛剛開始。如何對測試結果進行分析，關系着這次測試的成功與否。網上關於LoadRunner測試結果如何分析的介紹相當匱乏，在總結他人的觀點和自己的實驗體會基礎上來介紹如何進行LoadRunner測試結果分析。
1. LoadRunner測試結果分析的第一步應該是查看分析綜述（Analysis Summary），其包括統計綜述（Statistics Summary）、事務綜述（Transaction Summary）、HTTP 響應綜述（HTTP Responses Summary）三部分。在統計綜述中查看Total Errors的數量，HTTP 響應綜述中查看HTTP 404數量，若數值相對較大（HTTP 404則相對於HTTP 200），則說明系統測試中出錯較多，系統系能有問題；另外查看事務的平均響應時間和其90%的事務平均響應時間，若時間過長，超過測試計划中的要求值，則說明系統的性能不滿足我們的要求。
2. 第二步對LoadRunner測試結果圖進行分析，首先對事務綜述（Transaction Summary）進行分析，該圖可以直觀地看出在測試時間內事務的成功與失敗情況，所以比第一步更容易判斷出被測系統運行是否正常。
3. 接着分析事務平均響應時間（Average Transaciton Response Time），若事務平均響應時間曲線趨高，則說明被測系統處理事務的速度開始逐漸變慢，即被測系統隨着運行時間的變化，整體性能不斷下降。當系統性能存在問題時，該曲線的走向一般表現為開始緩慢上升，然后趨於平穩，最后緩慢下降。原因是：被測系統處理事務能力下降，事務平均響應時間變長，在曲線上表現為緩慢上升；而並發事務達到一定數量時，被測系統無法處理多余的事務，此時曲線變現為趨於平穩；當一段時間后，事務不斷被處理，其數量減少，在曲線上表現為下降。如果被測系統沒有等待機制，那么事務響應時間會越來越長，最后系統崩潰。
4. 再分析每秒通過事務數（Transactions per Second/TPS），該曲線表示被測系統在運行的任意時刻，每個事務通過、失敗的情況，其是考查系統性能的一個重要參數。若隨着壓力的增加，曲線如果開始變化緩慢或有平穩的趨勢，則有可能是服務器開始出現瓶頸。
[5]. 分析每秒通過事務總數（Total Transactions per Second），該曲線顯示在任意時刻被測系統通過的事務總數、失敗的事務總數。該曲線走向和TPS曲線走向一致。
[6]. 事務性能摘要（Transaction Performance Sunmmary）該曲線表示被測系統中所有事務的最小、最大和平均事務響應時間。
[7]. 事務在負載情況下的響應時間（Transaction Response Time Under Load），該曲線表示在不同數量的虛擬用戶情況下的事務響應時間情況。該圖對分析具有漸變負載的測試場景比較有用。
[8]. 事務響應時間（百分比）（Transaction Response Time（Percentile）），該曲線可以容易地分析出在給定的響應時間范圍內事務量的百分比重。
[9]. 事務響應時間（分布）（Transaction Response Time(Distribution)），該圖可以容易地分析出在給定響應時間范圍內的事務量情況。
其實，若並不是十分詳細地分析測試結果，第4步與第5步選其一分析，第6步、第7步、第8步為可選項，因為在第1步就在一定程度上分析了，而第9步又與第8步功能相識。LoadRunner生成測試結果圖在很大的程度上具有一定的重復性，只不過是在不同情況下的具體顯示。
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
二、
LoadRunner測試結果分析之我見
上述測試過程的重點在於事務，而LoadRunner生成的測試結果圖並不局限於事務上，其中還有是關於Vusers、Errors、Web Resources、Web Page diagnostics的測試圖。
1. 對於Vusers的測試圖有3種：Running Vusers、Vusers Summary、Rendezvous，其中Running Vusers是關於虛擬用戶加壓、施壓、減壓的情況圖；
Vusers Summary是用戶運行結果的綜述圖；Rendezvous是虛擬用戶的集合點情況圖。這三種圖單獨分析沒有多大的價值，一般都是和其他圖合並分析。
2. 對於Errors的分析，若是在上述測試中發現被測系統運行中有很多錯誤，則Errors測試結果有分析的必要，否則，就不必發費時間在Errors上了。其主要包括Error Statistics、Error Statistics（by description）、Errors per Second（by description）、Errors per Second、Total Errorss per Second，Error Statistics是帶有錯誤代碼編號的餅狀圖，Error Statistics（by description）不僅有錯誤代碼編號，而且帶有錯誤消息，Errors per Second是每秒錯誤數的曲線圖，Errors per Second與Errors per Second（by description）的區別也是在於是否帶有錯誤消息。Total Errorss per Second是被測系統每秒錯誤總數的曲線圖。
若要對系統進行錯誤分析，則Error Statistics與Error Statistics（by description）、Errors per Second（by description）與Errors per Second擇其一即可，不過帶有錯誤描述的圖更加具體。
3. Web Resources測試主要是對Web服務器性能的分析。
3.1每秒點擊次數（Hits per Second）是Vusers每秒向Web服務器提交的HTTP請求數。查看其曲線情況可以判斷被測系統是否穩定，曲線呈下降趨勢表明Web服務器的響應速度在變慢，當然其原因可能是服務器瓶頸問題，但是也有可能是
Vusers數量減少，訪問服務器的請求減少。
點擊數：不是根據用戶的鼠標點擊次數計算，而是根據客戶端向服務器發起的請求次數計算。例如：若一個頁面里包含10張圖片，那么在訪問該頁面時，鼠標僅點擊1次，但是服務器收到的請求數卻為1+10（每張圖片都會向服務器發出請求）。此時其點擊次數為11。
3.2吞吐量（Throughput）度量單位是字節，另外也有兆字節，其是度量服務器性能的重要指標，表示服務器在任意時間的吞吐能力，即任意時間服務器發送給Vusers的流量。
吞吐率=吞吐量/測試時間，單位時間里服務器發送給Vusers的流量。
點擊率=吞吐量/測試時間，單位時間里Vusers發送給服務器的HTTP請求數。
[3.3]狀態代碼概要（HTTP Status Code Summary）表示從服務器返回的帶有HTTP狀態的數量分布。其HTTP狀態有HTTP 200、HTTP 302、HTTP404等。該圖可以容易看出HTTP響應狀況。
[3.4] 每秒HTTP響應數（HTTP Responses per Second）表示每秒從服務器返回的HTTP狀態的曲線圖。其和 HTTP Status Code Summary不同在於后者是總體數量分布，而它是分布在時間段上的平均分布狀況。
[3.5] 每秒重試次數（Retries per Second）表示單位時間內服務器嘗試的連接次數。服務器重試連接的情況：初始連接未經授權、要求代理服務器身份驗證、服務器關閉了初始連接、初始連接無法連接到服務器、服務器最初無法解析負載生成器的IP地址。重試次數概要（Retries Summary）是表示服務器重試連接次數量的餅圖。
[3.6]連接數（Connections）顯示任意時間點的TCP/IP連接數。借助此圖，分析應該何時添加其他連接。每秒連接數（Connections Per Second）顯示單位時間里新建或關閉的TCP/IP連接數。該圖呈下降趨勢，就表明每秒連接數減少，也即服務器性能下降。
對於頁面資源的測試結，3.1步和3.2步應該分析，3.3步和3.4步在分析綜述（Analysis Summary）中已經做了一定的分析，沒有特定需求可以不做分析，若是想了解在什么時間出現何種HTTP（如錯誤HTTP 404），則要分析3.4步。至於3.5步可以了解在何時進行了重新連接，是什么原因導致。3.6步分析恰當的時間添加連接。
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
三、
LoadRunner測試結果分析之我見
前面分析的Web Resource（網絡資源）的測試情況，其主要關注的是服務器性能，而系統本身和環境都有可能存在問題，頁面診斷（Web Page Diagnostics）主要就是關注這方面的問題。頁面診斷可以很好地定位環境問題，如客戶端問題、網絡問題等，也可以很好的分析系統本身的問題，如網頁問題。
1．Web Page Diagnostics （網頁診斷）對測試過程中所有的頁面進行一個
信息匯總，可以很容易地觀察出哪個頁面下載耗時，然后選擇該頁面得其頁面分解圖，分析耗時原因。Web Page Diagnostics是一個匯總圖，選擇要分析的頁面，可得到其4張圖：Download Time、Component（Over Time）、Download Time（Over Time）、Time To First Buffer（Over Time）。
Download Time分析頁面不同組件在不同階段的所需時間，其階段主要包括：
DNS Resolution：DNS域名解析所需的時間；
Connect：與Web服務器建立初始連接所需的時間；
SSL Handshaking：建立SSL連接所用的時間；
FTP Authentication：認證客戶端所需的時間；
First Buffer：初始HTTP請求至WEB服務器響應成功所需的時間；
Receive Time：瀏覽器從服務器接受字節並完成下載所經時間；
Client Time：因思考時間或其它客戶端問題導致的請求發生延遲所經時間；Error：從發出HTTP請求到接收到錯誤消息所需的時間。
這樣就可以分析出時間花費在哪里，進而定位問題。
Component（Over Time）頁面上不同組件在不同時間的平均下載時間曲線圖。
Download Time（Over Time）不同組件在不同時間的平均下載時間面積圖。
Time To First Buffer（Over Time）不同組件不同時間第一次緩沖時間面積圖。
2. Page Component Breakdown 不同組件的平均響應時間占整個頁面平均響應時間的百分比，此為餅狀圖，可以很容易的分析出頁面的那個組件耗時較多。
3. Page Component Breakdown(Over Time) 任意時間不同組件的響應時間曲線圖，和步驟2有異曲同工之處。
4. Page Download Time Breakdown 頁面中不同組件在不同階段的柱狀圖，容易看出不同階段所占面積大小。
5. Page Download Time Breakdown(Over Time) 任意時間不同組件在不同階段響應時間曲線圖。
6. Time to First Buffer Breakdown 不同頁面第一次緩沖並下載完成所需時間的柱狀圖，此圖在分析測試結果時十分重要，其不僅能分析出哪個頁面耗費時間長，而且能分析出之所以耗時是網絡問題還是服務器問題。First Buffer Time分為Network Time和Server Time，客戶端發出http請求並接收到服務器端的應答報文（ACK）所經時間為Network Time，客戶端從接收到ACK到完成下載所經時間為Server Time。若Server Time明顯大於Network Time且是其幾倍，此時服務器性能是問題關鍵。
7. Time to First Buffer Breakdown (Over Time) 不同頁面在任一時間點的Network Time和Server Time分布曲線圖。
[8]. Download Comonent Size（KB）不同頁面在載整個下載量所占百分比例圖。
在對於頁面診斷的分析中，應先查看2. Page Component Breakdown，分析哪個頁面所占比例較大，然后分析其是不是造成耗時的原因。若是，再查看6. Time to First Buffer Breakdown，分析出其是網絡問題，還是服務器問題。再分析7. Time to First Buffer Breakdown (Over Time) 中的曲線，進一步分析原因。可以進一步查看1．Web Page Diagnostics做具體分析。