-------------------------------------------本文轉自網絡
LoadRunner，是一種預測系統行爲和性能的負載測試工具。通過以模擬上千萬用戶實施併發負載及實時性能監測的方式來確認和查找問題，LoadRunner能夠對整個企業架構進行測試。通過使用 LoadRunner，企業能最大限度地縮短測試時間，優化性能和加速應用系統的發佈週期。 LoadRunner是一種適用於各種體系架構的自動負載測試工具，它能預測系統行爲並優化系統性能。
對象
LoadRunner的測試對象是整個企業的系統，它通過模擬實際用戶的操作行爲和實行實時性能監測，來幫助您更快的查找和發現問題。此外，LoadRunner能支持廣泛的協議和技術，爲您的特殊環境提供特殊的解決方案。
主要功能
輕鬆創建虛擬用戶
使用LoadRunner的Virtual User Generator，您能很簡便地創立起系統負載。該引擎能
LoadRunner性能虛擬用戶模擬測試
夠生成虛擬用戶，以虛擬用戶的方式模擬真實用戶的業務操作行爲。它先記錄下業務流程(如下訂單或機票預定)，然後將其轉化爲測試腳本。利用虛擬用戶，您可以在Windows ，UNIX 或Linux 機器上同時產生成千上萬個用戶訪問。所以LoadRunner能極大的減少負載測試所需的硬件和人力資源。
用Virtual User Generator 建立測試腳本後，您可以對其進行參數化操作，這一操作能讓您利用幾套不同的實際發生數據來測試您的應用程序，從而反映出本系統的負載能力。以一個訂單輸入過程爲例，參數化操作可將記錄中的固定數據，如訂單號和客戶名稱，由可變值來代替。在這些變量內隨意輸入可能的訂單號和客戶名，來匹配多個實際用戶的操作行爲。
爲了進一步確定您的Virtual user 能夠模擬真實用戶，您可利用LoadRunner控制某些行爲特性。例如，只需要點擊一下鼠標，您就能輕易控制交易的數量，交易頻率，用戶的思考時間和連接速度等。
創建真實的負載
Virtual users 建立起後，您需要設定您的負載方案，業務流程組合和虛擬用戶數量。用LoadRunner的Controller，您能很快組織起多用戶的測試方案。Controller 的Rendezvous 功能提供一個互動的環境，在其中您既能建立起持續且循環的負載，又能管理和驅動負載測試方案。
而且，您可以利用它的日程計劃服務來定義用戶在什麼時候訪問系統以產生負載。這樣，您就能將測試過程自動化。同樣您還可以用Controller 來限定您的負載方案，在這個方案中所有的用戶同時執行一個動作---如登陸到一個庫存應用程序----來模擬峯值負載的情況。另外，您還能監測系統架構中各個組件的性能---- 包括服務器，數據庫，網絡設備等----來幫助客戶決定系統的配置。
定位性能問題
LoadRunner內含集成的實時監測器，在負載測試過程的任何時候，您都可以觀察到應用系統的運行性能。這些性能監測器爲您實時顯示交易性能數據（如響應時間）和其它系統組件包括application server, web server，網路設備和數據庫等的實時性能。這樣，您就可以在測試過程中從客戶和服務器的雙方面評估這些系統組件的運行性能，從而更快地發現問題。
利用LoadRunner的ContentCheck TM ，您可以判斷負載下的應用程序功能正常與否。ContentCheck 在Virtual users 運行時，檢測應用程序的網絡數據包內容，從中確定是否有錯誤內容傳送出去。它的實時瀏覽器幫助您從終端用戶角度觀察程序性能狀況。
分析結果以精確定位問題所在
一旦測試完畢後，LoadRunner收集彙總所有的測試數據，並提供高級的分析和報告工具，以便迅速查找到性能問題並追溯原由。使用LoadRunner的Web 交易細節監測器，您可以瞭解到將所有的圖象、框架和文本下載到每一網頁上所需的時間。例如，這個交易細節分析機制能
夠分析是否因爲一個大尺寸的圖形文件或是第三方的數據組件造成應用系統運行速度減慢。另外，Web 交易細節監測器分解用於客戶端、網絡和服務器上端到端的反應時間，便於確認問題，定位查找真正出錯的組件。例如，您可以將網絡延時進行分解，以判斷DNS 解析時間，連接服務器或SSL 認證所花費的時間。通過使用LoadRunner的分析工具，您能很快地查找到出錯的位置和原因並作出相應的調整。
重複測試保證系統發佈的高性能
負載測試是一個重複過程。每次處理完一個出錯情況，您都需要對您的應用程序在相同的方案下，再進行一次負載測試。以此檢驗您所做的修正是否改善了運行性能。
LoadRunner完全支持EJB 的負載測試。這些基於Java 的組件運行在應用服務器上，提供廣泛的應用服務。通過測試這些組件，您可以在應用程序開發的早期就確認並解決可能產生的問題。
利用LoadRunner, 您可以很方便地瞭解系統的性能。 它的Controller 允許您重複執行與出錯修改前相同的測試方案。它的基於HTML 的報告爲您提供一個比較性能結果所需的基準，以此衡量在一段時間內，有多大程度的改進並確保應用成功。由於這些報告是基於HTML 的文本，您可以將其公佈於您公司的內部網上，便於隨時查閱。
接下來的文章編者就將輯錄一篇網上的使用LoadRunner®來測試BEA中間件產品文章來與大家分享如何使用LoadRunner進行實際的性能測試。
性能測試
1． LoadRunner的虛擬用戶
LoadRunner使用虛擬用戶（Virtual users）來模擬實際用戶對業務系統施加壓力。虛擬用戶在一箇中央控制器（controller station）的監視下工作。
在做一個測試方案時，要做的第一件事就是創建虛擬用戶執行腳本。LoadRunner提供了Virtual User Generator來錄製或編輯虛擬用戶腳本。
2． 使用Vugen創建虛擬用戶執行腳本
A．從菜單中選擇運行Virtual User Generator：
B．創建一個單協議腳本，選擇協議類型爲"Tuxedo 7"
C．在彈出的窗口中輸入Tuxedo客戶機程序的可執行文件名（SimpApp.exe），並選擇"Record into Action"爲Action。
點擊"OK"開始錄製腳本，這時Vugen就會啓動Simpapp.exe，如下圖所示，輸入WSNADDR，輸入字符串（Tuxedo is powerful!）之後，點擊TOUPPER，TUXEDO服務器完成請求後把輸出字符串（TUXEDO IS POWERFUL！）寫到"Output string"中，點擊停止錄製按鈕。
D．編輯Vuser腳本。在C中做的所有操作都被錄了下來，記錄到一個腳本文件中，其內容如下，把它存爲simpapp。
腳本內容如下：
#include "lrt.h"
#include "replay.vdf"
Actions()
{
lrt_tuxputenv("WSNADDR=//172.22.32.25:7110");
lr_think_time(3);
tpresult_int = lrt_tpinitialize(LRT_END_OF_PARMS);
lrt_abort_on_error();
data_0 = lrt_tpalloc("STRING", "", 1);
lrt_strcpy(data_0, sbuf_1);
data_1 = lrt_tpalloc("STRING", "", 1);
tpresult_int = lrt_tpcall("TOUPPER", data_0, 0, &data_1, &olen, 0);
lrt_abort_on_error();
lrt_tpfree(data_0);
lrt_tpfree(data_1);
lrt_tpterm();
return 0;
}
代碼中加粗的函數是LoadRunner對TUXEDO函數的二次包裝。
E．點擊工具欄中的"執行"按鈕來執行我們剛纔錄製的腳本，確保執行無誤。
3． 使用控制器（Controller）來調度虛擬用戶
A．從菜單中選擇運行Controller：
B．創建一個新的Scenario，選擇剛纔錄製的腳本（simpapp）：
點擊"OK"，彈出Scenario調度界面。在"Quantity"中輸入100，表示使用100個虛擬用戶。（虛擬用戶與購買的LICENSE有關聯）
C．點擊"Edit Schedule"來編輯壓力調度。
D．選擇"Runtime settings"來作運行時設置。
在Pacing的設置中，"Number of Iterations"用於設置Vusers的Actions被執行的次數；"Start new iteration"用於設置調度器在什麼時機迭代執行Vusers的Actions。
"Think Time"用於設置Vusers的反應和思考時間，以儘量做到和正常人一樣來施壓。"Ignore think time"表示忽略思考時間，這是理想狀態，一般不使用。"As recorded"表示按照錄制時的實際操作時間。"Multiply recorded think time by"表示Vusers的思考時間是實際錄製時間的若干倍。
在"Miscellaneous"中設置一些雜項，如使用進程還是使用線程等。對於TUXEDO，好象只能選進程模式。
E．選擇"Start scenario"來開始本次壓力測試調度。
執行結果分析如下：
施壓時間爲5分41秒，Vusers數量爲100，一共完成的Actions交易數量爲5625筆，平均響應時間爲5.561秒，TPS爲17.8。[1]
LoadRunner組件
1、VuGen（虛擬用戶生成器） 用於捕獲最終用戶業務流程和創建自動性能測試腳本 （也稱爲虛擬用戶腳本）。
2、Controller （控制器）用於組織、驅動、管理和監控負載測試。
3、Load Generator（負載生成器）用於通過運行虛擬用戶生成負載。
4、Analysis （分析器）有助於您查看、分析和比較性能結果。
實例應用
在軟件測試工具中如何巧用LoadRunner的隨機函數
LoadRunner有自帶的隨機函數，如果巧妙的加以採用，能解決一些看似很困難的實際問題。
一個項目的性能測試。與數據庫直連，根據外部傳入的SQL ID和SQL參數，從指定數據庫中讀取SQL模版，拼裝成真實的SQL語句、執行，並將得到的結果放入緩存中。目的是減少數據庫的壓力。
該系統將支撐大量的SQL操作，性能自然成爲備受關注的焦點之一。
由於它跟SQL語句相關，在真實環境下，同一時間可能執行着不同類型的SQL，即便是同一類型，其參數也各式各樣。那麼，怎樣才能模擬出最符合實際情況的性能測試場景呢？
首先設計場景，即，在LoadRunner中按照比例隨機取到某一類型的SQL，再隨機傳入參數給它，讓最終的每條SQL都是隨機生成，各不相同。
從場景中，可以看到，此處涉及雙重隨機。只採用loadruner的參數設置是無法實現的。此時需要想辦法先按設定好的比例隨機取到SQL，然後在每條SQL上隨機取參數列表中的參數。
於是想到了loadrunner的隨機函數。先實現隨機取SQL ID，之後再在特定的SQL中隨機取參數列表中的參數。
LoadRunner中，隨機函數是rand()，它用來產生0到rand_max之間的隨機整數。函數原型是
int rand ( void );
然而調用rand之前，必須給隨機數產生一個隨機種子。這個種子由srand()函數產生。其原型是
int srand ( seedTime );
採用上述兩個函數，就能實現第一重隨機了。具體腳本代碼如下：
| //generate rand number int rNum = 0; srand(time(NULL)); rNum = rand() % 10; lr_output_message(”the number is :%d”,rNum); //print the current random number 生成隨機數後，再按比例用if … else … 來取到各種類型的SQL，並給它們傳參。具體腳本代碼如下： //get certain SQL and random value if (rNum>=0 && rNum<2) { web_url(”test”, “URL=http://host_name:8080/interface?sqlId=sqlid_name2&value={random_para2} “, ”Resource=0″, ”RecContentType=text/html”, ”Referer=”, ”Snapshot=tn.inf”, “Mode=HTTP”, LAST); } … else if(rNum>=8 && rNum<10){ web_url(”test”, “URL=http://host_name:8080/interface?sqlId=sqlid_name2&value={random_para2} “, ”Resource=0″, ”RecContentType=text/html”, ”Referer=”, ”Snapshot=tn.inf”, “Mode=HTTP”, LAST); } else { rNum = 0; lr_output_message(”the number is :%d”,rNum); } |
注：sqlid_name是SQL ID名稱；random_para是通過file方式實現的隨機參數；tn是web_url函數的快照名稱。
通過上面的腳本，實現了性能測試設計的場景。調試通過後，放入Controller中執行。實際執行過程中，Vuser將會按比例隨機取到不同類型的SQL，並隨機取到SQL中的參數，執行特定的SQL語句。
巧用LoadRunner的隨機函數，能解決不少實際問題。[2]
用LoadRunner分析資源佔用率
LoadRunner分析頁面
1. 平均事務響應時間
Average Transation Response Time 優秀：<2s
良好：2-5s
及格：6-10s
不及格：>10s
2. 每秒點擊率
Hits per Second
當增大系統的壓力(或增加併發用戶數)時，吞吐率和TPS的變化曲線呈大體一致，則系統基本穩定若壓力增大時，吞吐率的曲線增加到一定程度後出現變化緩慢，甚至平坦，很可能是網絡出現帶寬瓶頸.同理若點擊率/TPS曲線出現變化緩慢或者平坦,說明服務器開始出現.
3. 請求響應時間
Time to Last Byte
4. 每秒系統處理事務數
Transaction per second
5. 吞吐量
Throughout
6. CPU利用率
Processor / %Processor Time 好：70%
壞：85%
很差：90%+
7. 數據庫操作消耗的CPU時間
Processor / %User Time 如果該值較大，可以考慮是否能通過友好算法等方法降低這個值。如果該服務器是數據庫服務器， Processor\%User Time 值大的原因很可能是數據庫的排序或是函數操作消耗了過多的CPU時間，此時可以考慮對數據庫系統進行優化。
8. 核心態CPU平均利用率
Processor /%Privileged Time 如果該參數值和"Physical Disk"參數值一直很高，表明I/O有問題。可考慮更換更快的硬盤系統
9. 處理列隊中的線程數
Processor / Processor Queue Length 如果該值保持不變(>=2)個並且%Processor Time 超過90%，那麼可能存在處理器瓶頸。如果發現超過2，而處理器的利用率卻一直很低，那麼或許更應該去解決處理器阻塞問題，這裏處理器一般不是瓶頸。
10. 文件系統緩存
Memory / Cache Bytes 50%的可用物理內存
11. 剩餘的可用內存
Memory / Avaiable Mbytes 至少要有10% 的物理內存值
12. 每秒下載頁數
Memory / pages/sec 好：無頁交換
壞：CPU每秒10個頁交換
很差：更多的頁交換
13. 頁面讀取操作速率
Memory / page read/sec 如果頁面讀取操作速率很低，同時 % Disk Time 和 Avg.Disk Queue Length的值很高，則可能有磁盤瓶徑。但是，如果隊列長度增加的同時頁面讀取速率並未降低，則內存不足。
14. 物理磁盤利用率
Physical Disk / %Disk Time 好：<30%
壞：<40%
很差：<50%+
15. 物理磁盤平均磁盤I/O隊列長度
Physical Disk / Avg.Disk Queue Length 該值應不超過磁盤數的1.5~2 倍。要提高性能，可增加磁盤
16. 網絡吞吐量
Network Interface / Bytes Total/sec 判斷網絡連接速度是否是瓶頸，可以用該計數器的值和目前網絡的帶寬，結果應該小於50%
17. 數據高速緩存區命中率 命中率應大於0.90最好
18. 共享區庫緩存區命中率 命中率應大於0.99
19. 監控 SGA 中字典緩衝區的命中率 命中率應大於0.85
20. 檢測回滾段的爭用 小於1%
21. 監控 SGA 中重做日誌緩存區的命中率
應該小於1%
22. 監控內存和硬盤的排序比率 最好使它小於 10%[3]
安裝
LoadRunner 分爲Windows 版本和Unix 版本。如果所有測試環境基於Windows平臺，那麼只要安裝Windows 版本即可。 LoadRunner的Unix版本僅提供Load Generator組件的安裝（即LoadRunner中的負載生成器）。也就是說，這個負載生成器可以在Unix環境下安裝和運行，並提供給Controller進行遠程管理。但是，腳本的錄製和場景的設計必須在Windows平臺完成。 系統要求 運行LoadRunner，內存最好在128M 以上，LoadRunner7.8 的最低要求。 內存最好在512M 以上，安裝LoadRunner 的磁盤空間至少剩餘500M。操作系統最好爲Windows 2000。