LoadRunner自動化測試結果分析及感想篇(大結局)

MILY: 宋體; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: 宋體; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-ascii-font-family: Calibri; mso-hansi-font-family: Calibri">導讀

經過前面的測試，我們通過了測試并得到了測試數據。此時，可以通過LR的Analysis模塊進行操作。Analysis是一個獨立的模塊，它可以將測試結果和監控數據轉化為數據庫數據，以利于分析處理。測試人員可以在分析器中選擇感興趣的圖表，通過合并圖，交叉圖和自動關聯等手段，對測試結果和監控數據進行分析處理。以確定性能瓶頸及其產生的原因。最后，可以選擇有價值的部分圖，自動生成HTML和Word格式報告， 這些報告可以作為附件和測試測試報告一起提交，提供性能參考。

詳細分析

場景運行 結束后，必須手動打開Analysis，Analysis啟動時，會自動收集本地計算機上的結果數據，如果壓力產生器在遠端機器上，又沒有選擇自動收集數據，則會先收集測試結果數據。打開后如下圖所示:

在上圖中，帶紅點的是打開自動生成的圖表，沒有紅點的則是通過合并圖，篩選等手段添加上的。Analysis上圖形主要分為四大類，分別是Vusers，事務，Web資源，網頁分析。通過不同的需要選擇不同的圖來分析。下面主要講幾個重要的圖及相關操作。

一，相關圖的解說

1， Vuser圖，如下圖所示：

此圖是經過篩選操作后得到的Vuser圖，顯示了所有Vuser在測試期間的每一秒內，執行Vuser腳本的Vuser的數量及它們的狀態。如果想了解單獨一個Vuser的狀態，也可以將篩選條件設置您想了解的VuserID。具體操作步驟是：在Vuser圖內單擊鼠標右鍵，選擇菜單中的“設置篩選器/分組方式”，在彈出的設置框中進行設置即可。如下圖所示：

用篩選方式可以搜索到特定的Vuser在不同時刻的數據，方便性能分析，初學者要好好掌握。此方法可以運用到對其它圖的操作上，以后對篩選的操作就不再具體描述了。

2， 事務圖。事務圖主要包括平均事務響應時間圖，每秒事務數圖，每秒事務總數，事務概要圖，事務性能概要圖，事務響應時間（負載下）圖，事務響應時間（百分比）圖，事務響應時間（分布）圖。

這里就拿事務響應時間（百分比）圖來分析。它可以幫助測試人員分析在給定時間范圍內執行的事務的百分比和確定合適的事務百分比，以判斷是否滿足系統的性能標準，通常情況下，您需要在可接受的響應時間范圍內，確定事務百分比，最大響應時間可能非常長，但如果大多數事務具有可以接受的響應時間，則整個系統還是適用的。來看看具體的圖：

上圖是所有用戶的全部事務的響應時間百分比，可以通過篩選功能，篩選出具體的用戶和事務進行分析；用向下搜索功能提煉出更加精確的數據，以便好地進行性能分析，定位系統的性能瓶頸，此操作在相應的圖中單擊鼠標右鍵，選擇“向下搜索”，在彈出的設置框中設置相應選項就可以了。我這里就用Vuser9分析

經過LR的篩選功能可以得到更多精確的圖，就可以很清晰很方便地分析出系統是否存在性能問題了。用性能下降曲線分析法，從上圖可以看到，發布博文事務曲線非常平滑，最大響應時間為0.999秒，是屬于非常好的現象，其它事務隨著負載用戶數量的增大，出現相應的波動，從而可以分析性能問題所在。從圖中可以看到，一條曲線可以分為以下幾個部分：

（1）性能平坦區——在不進行更多性能調優情況下所能期望達到的最佳性能。這個區域可被用作基線或是benchmark。

（2）壓力區域——應用“輕微下降”的地方。典型的、最大的建議用戶負載是壓力區域的開始。

（3）性能拐點——性能開始“急劇下降”的點。

這幾個區域實際上明確標識了系統性能最優秀的區間，系統性能開始變壞的區間，以及系統性能出現急劇下降的點。對性能測試來說，找到這些區間和拐點，也就可以找到性能瓶頸產生的地方。因此，對性能下降曲線分析法來說，主要關注的是性能下降曲線上的各個區間和相應的拐點，通過識別不同的區間和拐點，從而為性能瓶頸識別和性能調優提供依據。

在其它圖中，還可以使用LoadRunner中的自動關聯確定造成服務器或網絡瓶頸的原因。自動關聯功能應用高級統計信息算法來確定哪些度量對事務的響應時間影響最大。操作步驟是：單擊“關聯選項”選項卡，選擇要將哪些圖的數據與相應事務關聯，如下圖所示：

除了上述操作外，還可以進行其它操作，如比較不同場景的結果，如果你執行了多個場景的話。最后根據用戶選擇感興趣的圖表，生成HTML或Word格式及其它格式的報告。此次測試的報告我已經上傳到博客上了，感興趣的朋友可以下載看看，謝謝大家的支持。根據測試結果分析數據與事先設計好的測試用例或需求說明書對比，驗證測試是否通過，不通過則分析系統性能瓶頸出在哪里。OK，圖表就分析到這了。 

二，相應服務器性能分析

1， tomcat分析

我這里用的是Lambda Probe來實現的，來看看在運行場景時，tomcat的性能，如下圖：

從圖中兩個表中可以看出，要相同的時間內。每30秒的用戶數和執行的事務數整體上是一致的，并沒有影響系統整體性能，數據庫中也成功在插入了相應數據，如下圖：

在腳本運行設置中，我設置了6個迭代，這里也成功插入了6條數據，再結合事務響應時間（最大為0.999秒），說明這塊的性能是通過測試的。這里想加一句，一個沒有發現bug的測試，算不上是一個成功的測試。因為軟件測試的目的就是要找到bug，如果有條件，盡量把并發的Vuser設多，能把系統搞崩潰最好，這樣就可以提取更有價值的數據，從而分析出系統的瓶頸，解決性能問題。

2， MySQL數據庫服務器分析

MySQL數據庫服務器性能主要參考tomcat中的status可以獲得相應數據，只要tomcat用戶管理文件配置成功，就可以走入了，地址為：http://localhost:8080/manager/status  如下圖:

在運行場景中，這里會記錄所有數據插入的信息，通過這些信息，分析其性能。

如果出現性能問題或現在的性能不符合需求規格說明書上所需求的，則超需要進行性能調優了。針對不同性能問題，實施不同的策略，如存儲空間不足，則可以增加大容量硬盤；內存不足就補內存；服務器問題則可以采用集群等等，但每種都不是單獨考慮，要考慮到成本，風險等問題。不能說存儲空間不足，就惡補大容量硬盤，這種方法不完全正確的。

此次測試的感想

         做性能測試比做功能測試是難很多的。

第一，  如果系統應用復雜，功能眾多的話，就需要進行大量的測試工作，工作量龐大，試想我這里只是測試了登錄和發博文兩個功能，還有其它功能都還沒有測試呢。

第二，  Web腳本如何開發。不想認為僅僅通過錄制就可以解決腳本問題，在一些特定的環境下，要測試人員開發大量的腳本，涉及高級算法，語言等知識。

第三，  場景數據出來后，如何分析。分析測試數據是一個很頭痛的問題，其它涉及到的東西且不說，光是那龐大的數據量就可能讓你窒息了。像阿里巴巴，淘寶這樣的網站，數據都是海量級別的。

第四，  性能問題不僅僅關系到軟件本身，還與服務器，網絡，存儲空間，I/O等等有關。

…………

性能測試工程師職位是具體有挑戰性的，如果你想成為一個優秀的性能測試工程師，必須有牢固的開發測試基礎，廣闊的知識面，良好的分析問題和解決問題的能力，等等。上下不斷求索吧。

OK，關于LoadRunner自動化測試就到這了。LoadRunner中自帶有一個測試web項目，地址是http://127.0.0.1:1080/mercuryWebTours  開啟服務器后，用注冊用戶名和密碼進入。大家可以自己動手試試，盡量整出點性能問題來，學IT，很多時候BUG和異�？赡艹蔀槟慵夹g提高的源泉。謝謝大家的支持，不足之處，請大家諒解和提示。

響應時間百分比