本文旨在介紹使用LoadRunner進行基礎的性能測試。
我們在接到一個性能測試任務的時候，需要從以下幾點考慮：我們的測試對象是什么，測試要求是什么，測試環境是怎么部署的，業務規模如何，哪些業務點是客戶最關注的等等，下面將從性能測試啟動開始講解基本的測試流程。
在使用loadrunner工具前，需確定哪些業務需要使用該工具進行測試，不需要的時候堅決不用，不要認為這個工具萬能。以本次測試中的綜合查詢（預付費綜合業務信息查詢）為例進行講解。
1.1錄制前準備工作
在錄制腳本前需檢查壓測環境的整體功能是否正確，待測部分的功能是否正確，只有確保功能正確后才可進行壓測。如本次測試，可先驗證50環境是否正常，CICS服務器（49）是否正常，/var/cics_regions目錄的使用率是否過高等等，一切確定OK后，開始驗證功能，這些都保證沒有問題后，檢查一下測試工具loadrunner是否正常使用，可簡單的點點用用，確保工具OK。
1.2錄制及調試腳本
在準備工作OK后，進行腳本的錄制，具體過程如下：
1、打開“開始－>程序－>Mercury LoadRunner－>Mercury LoadRunner”出現下圖
2、點擊“Create/Edir Scripts”,出現下圖，如果沒有出現，則可在“File”下選擇New新建。
3、出現這個界面后，選擇Web(HTTP/HTML)協議，我們測試的是B/S模式，采用的是Web協議。選擇后，點【OK】按鈕。出現下圖：
4、點擊界面中的Start Record，這個表示開始錄制腳本，點這個按鈕后，出現下圖：
圖中的URL輸入待測的網址，如本次測試網址：http://10.243.211.50/boss/loginauthservlet
在Record into Action中選擇vuser_init，把登錄部分放在vuser_init中，vuser_init與vuser_end在測試過程中僅執行一次，這里解釋一下，Action的作用是將測試功能主體放在里面執行，舉例，假如做產品轉換，我們講登陸的部分放在vuser_init中， 具體業務操作放在Action中，退出部分放在vuser_end。這樣，我們將壓力集中在業務操作上，而不是登陸退出上。同時，可以創建多個Action，將業務操作分成多個部分，比如用戶鑒權放在Confirm中，將選擇產品放在Select_Prod中，將業務分開放在多個Action的好處是可以統計這個操作的處理時間，處理速度等，便于定位問題。
Action的增加、修改、刪除：Action可以在錄制前增加，具體方法是選中上圖界面左邊的部分，然后點右鍵，可以看到有增加Action的按鈕（Create New Action），也可進行刪除、重命名。在測試前可以根據需要將業務分為幾個操作部分，建立對應的Action，名稱最好能清晰操作部分的功能。錄制腳本的時候，可以將對應的操作放在對應的Action中。
這里我們假設綜合查詢需要以下幾個步驟：
可設計Action為這幾個：vuser_init（這個默認有）、IntoMenu、SubQue
5、設置好后，點【OK】，進行錄制
在錄制前，如果已經打開待測頁面的話，建議關閉該頁面。點【OK】后，這時會出現待測頁面，如http://10.243.211.50/boss/loginauthservlet，同時會出現：
這表示現在已經開始錄制，可根據需要將業務放在一個Action中，也可以分成多個，放在多個Action中，具體方法是在進行下一個業務操作前，點上圖中的，選擇對應的Action，如果事先沒有創建Action的話，則可點擊：
增加新的Action。
在頁面中輸入用戶名后，登陸到系統，待頁面都加載完畢后，將vuser_init改為IntoMenu，點擊相應的菜單，如查詢統計 -> 營業受理查詢 -> 預付費查詢 -> 預付費綜合業務信息查詢，頁面加載完畢后，將IntoMenu改為SubQue，在“服務號碼：”中輸入號碼13539300000（測試號碼），點擊【查詢】，待頁面返回查詢結果后，將SubQue改為vuser_end，退出系統。
注：頁面加載完畢可以參考網頁左下角有個信息提示“完畢”。
所有操作完成后，點擊：
中停止按鈕：
停止錄制，頁面將自動關閉，返回到loadrunner錄制界面，將在界面中顯示錄制腳本代碼，保存錄制的腳本。
6、調試代碼并進行參數化
錄制后的代碼需要進行調試才可用于壓測，調試的辦法就是進行回放操作，如果回放過程無錯誤，運行結果也正確的話，則可用于壓測。具體調試步驟如下：
點擊界面中的按鈕進行單次運行調試，運行后，會彈出運行預覽的一個窗口，可以看到每一個Action的執行過程，運行結束后，會出現一個結果報告，如果有錯誤，會在報告中以紅色叉標志顯示出來，同時在Execution log中也會打出錯誤信息，可以根據這些錯誤信息進行調試。如果無錯誤，則可進行插入事務、參數化設置等其他操作。現在假設調試無錯誤，進行參數化設置。
在測試過程中，有可能需要不同的測試號碼，如果產品轉換，首次激活等，如果有同樣的號碼將導致測試失敗，因為相同的號碼不能做同樣的業務操作多次，所以需要大量不同的測試號碼，這個就需要用到參數化設置。我們在編寫測試方案的時候，已經得出要準備多少測試號碼，在測試工作準備的時候，已經準備好測試號碼，那么可以利用這些準備的號碼進行參數化設置。參數化設置的意思就是將需要用其他數據代替的地方設置為一個參數，在運行時讀到這個參數，就使用其他的值代替，在這個例子中，我們需要設置參數的地方是服務號碼。這樣，我們需要先創建一個參數，步驟如下：
先準備好號碼，可在數據中導出，存放在txt文本中，格式為：測試號碼，一行一個號碼，最后一行要為行，如果文件名為test_num.txt
a、點擊界面中：
出現下面界面
在這個界面中，點擊左邊的New，創建一個新的參數，在界面的右邊，Parameter type選擇File，File path選擇存放號碼的txt文件路徑，選定文件后，會在下面的表格中列出測試號碼，我們在Select next row中選擇Unique，這個表示整個測試過程僅使用唯一的號碼，保證號碼不重復，這樣就要號碼資源足夠多，同時測試時間也需要控制好，否則會報錯。
創建好參數后，返回到剛才錄制的腳本中，找到對應的Action，如SubQue中服務號碼字段，選擇該號碼，右鍵選擇“Replace with a parameter”，在Parameter name的下拉列表中選擇需要替換的參數，選定后點擊OK。
設置OK后，可進行調試，如無問題，則可以進行場景的設置。這里有個注意點要說明一下，參數化也可以直接在腳本中選中需替換的地方，點右鍵，選擇“Replace with a parameter”，更改Properties進行設置，但這樣做經常出問題，不容易調試，不建議這樣做。
在腳本錄制完成，調試通過后，可以進行測試場景的設計。具體步驟如下：
1、打開“開始－>程序－>Mercury LoadRunner－>Mercury LoadRunner”出現下圖
2、點擊圖中的Run Load Tests，出現下圖界面
在新建場景的窗口，選擇一種場景類型。下面對三種類型進行簡單的說明。
3、Goal—Oriented Scenario： 在測試計劃中，一般都包括性能測試要達到的目標。選擇該項后，LoadRunner 基于這個目標，自動為你創建一個場景。在場景中，我們只要定義好我們的目標即可。
4、在上圖中出現的Available scripts，選擇要進行場景設計的腳本，若沒有出現需要對應的腳本，可點擊Browse查找后添加進來，選擇好腳本后，點Add，則可加入到右邊的窗口中，然后點【OK】，出現下圖
5、上圖中的ScenarioGroups，顯示的是腳本的路徑與并發數個數，根據測試方案中的并發數可更改此處的并發數，在上圖中點擊Edit Schedule，出現下圖
舉個例子，假如我們設計的場景是每15秒增加2個，所有并發數增加完后持續運行5分鐘，5分鐘運行結束后，每30秒減少5個并發，則上面三張圖的設置就行了，注意那個Initialize…必須勾選上。
6、再點擊頁面右下角的“Run-time Settings”，出現下圖
選擇圖中的Think Time，在右邊選擇Replay think time，再勾選中Limit think time to：1 seconds，表示即使腳本think time時間可能超過1秒，也用1秒替換，可以自行調整這個時間。這樣做的目的是在測試過程中使得每個業務操作里加上think time，表示用戶在操作的時候，有個時間延遲，真實的模擬用戶的操作，比如用戶在做產品轉換的時候，可能在選擇產品的時候，有個停頓思考的時間，這樣loadrunner會記錄下來。如果選擇Ignore think time，這樣對服務器造成的壓力是最大的，在運行時，會沒有停頓的，持續對服務器加壓，不太符合實際使用情況。
設置好Think Time后，選擇Miscellaneous，在出現的窗口中勾中Continue on error，表示在遇到錯誤的時候，繼續執行場景，直到場景運行結束。
7、一切設置OK后，點擊：
運行測試場景，如下圖
在圖中的左邊可以查看并發用戶數的運行情況，右邊可以查看通過的事務數、失敗的事務等，如果運行過程中有錯誤出現，則可以點擊Errors右邊的放大鏡，查看詳細錯誤信息。窗口下面是各種監控窗口，Running Vusers展示的是目前并發用戶數的運行情況，Trans Response Time表示的是事務的響應時間，即每個事務處理的時間是多少秒。
場景執行結束后，可以使用loadrunner自帶的分析工具進行結果分析，這里我們主要考察兩個地方，第一是平均事務響應時間Average Transaction Response Time，第二是并發數運行情況Running Vusers，這兩個顯示了場景運行過程中并發數的執行情況與每筆事務的處理時間。還有其他幾個考察點，做簡要解釋。
注：事務數概念解釋：事務就是腳本中定義的每個Action。
具體分析步驟是：
先打開“開始－>程序－>Mercury LoadRunner－>Mercury LoadRunner”出現下圖
點擊Analyze Load Tests，出現下圖
在圖中的菜單欄中選擇打開，找到要分析的場景執行結果，點【打開】即可，還可以直接在場景運行結束后，點擊Controller菜單欄的：
直接收集場景運行結果進行分析。
打開場景執行結果后的界面如下：
界面左邊是各個指標的列表，右邊是圖形的顯示，下面是指標對應的采集數據。接下來將重點選擇幾個指標做解釋。
3.1 并發數執行情況（Running Vusers）
并發數執行情況反映了在場景執行過程中各個并發數的運行情況，成功了多少，失敗了多少，是否按照既定的場景執行計劃運行，是否達到預期的執行效果，如果在某個時間，執行失敗了，或者存在異常，那么并發數的圖表將是波動，可以從圖中直觀的看出來，同樣根據場景中Error的信息，定位在何時出現了錯誤，此時執行的并發數是多少。并發數的圖表如下：
3.2 事務通過數（Throughput）
事務通過數的意思是每個特定時間間隔內通過的事務數，如果隨著場景執行時間的推延，通過事務數曲線應該是平緩的，如果突然上升，則可能是服務不穩定，或者網絡因素導致的，如果持續下降，則表示服務的處理能力在下降，此時可以查看服務器段是否有進程堵塞，或者服務器的連接數不夠，也可能是網絡帶寬不夠。事務通過數的圖表如下
3.3 平均事務響應時間（Average Transaction Response Time）
平均事務響應時間在整個測試過程中是一個很重要的參考指標，他能清晰的反映出場景執行過程中，每個事務的執行時長，整個業務中哪個操作最耗時等等。
場景執行結束后，可以根據這個圖表分析出在一定響應時間要求下，系統可支持的并發數，假如我們要求在查詢的時候要求這個返回結果的時候不超過5秒，那么可以在場景中找到對應的SubQue事務在處理時間為5秒左右的時間點，再從Running Vuser圖中找到對應的時間點，查看對應的并發用戶數。同樣，在整個執行過程中，當并發數達到一定數值后，平均事務響應時間曲線應該是平緩的，如果出現突然升高或者降低的情況，則表示系統存在異常，這樣我們可以找到這個時間點去查看服務器端的運行日志，查找原因。平均事務響應時間的圖表如下：
3.4服務器資源分析
服務器資源監控利用的是nmon工具，在得出分析結果后，可以查看對應的圖表進行分析。
敏捷的技術時代需要測試開發者在提高產品質量的同時，能夠縮短發布時間和精簡工作流程。研發人員們現在正在短時間內自己完成端到端的周期，并不斷發布新的修復和功能。
測試開發人員節省時間的方式之一是盡可能多的重復使用現有的腳本。這節省了創建新腳本的時間，并且還實現了自動化。
通常情況下，你可以通過很多可用的工具來對一個應用軟件進行測試并可以得到有關性能級別和臨界點等方面的報告。像大多數工具一樣，你要先退出你所運行的東西并對測試做徹底的準備。我們今天就來聊一聊一個常用工具LoadRunner如何在大負載下進行測試？
首先，什么是負載測試？
負載測試是通過逐步增加系統負載，測試系統性能的變化，并最終確定在滿足性能指標的情況下，系統所能承受的最大負載量的測試，例如，訪問一個頁面的響應時間規定不超過1秒，負載測試就是測試在響應時間為1秒時，系統所能承受的最大并發訪問用戶的數量。
負載測試的目標是確定并保證系統在超出最大預期工作量的情況下仍能正常運行，還能評估系統的性能特征。
下面介紹一下關于負載測試的幾個基本概念：
吞吐率：服務器并發處理能力的量化描述（單位reqs/s）,單位時間內處理的請求數。
并發連接數：某一個時間點允許最大的請求數量，這個常用來衡量系統的并發處理請求的能力，應該區分與下面的并發用戶數。
并發用戶數：一個用戶可能會產生多個并發連接，例如IE8目前支持6個并發連接。
用戶請求平均時間：大量用戶請求從發起到接收到處理結果的一個平均時間，在web頁面默認不超過3秒是最佳的用戶體念。
服務器平均處理請求時間：處理完成一個請求所用的平均時間，這個指標可用來衡量業務邏輯復雜度和機器的性能指標。
再來了解下，什么是LoadRunner？
LoadRunner是一款適用于多種軟件體系架構的負載測試工具，從用戶關注的響應時間、吞吐量，并發用戶數和性能計數器等方面來衡量系統的性能表現，輔助用戶進行系統性能優化。
原理：LoadRunner通過模擬成千上萬用戶實施并發負載及實時性能監測的方式來確認和查找問題，優化性能和加速應用系統的發布周期。
組成：LoadRunner主要包括三個前臺功能組件，分別為VuGen（虛擬用戶腳本生成器）、Controller（測試控制器）和Analysis（結果分析器）。系統會自動調用后臺功能組件LG（負載生成器）和Proxy（用戶代理）來完成性能測試工作。
如何使用LoadRunner實現大負載測試？
第一步：配置系統參數
大并發用戶的情況下，會出現如下問題：
1)當采用netstat命令時，看到很多Socket處于"WAIT"狀態
2)負載增大時連接失敗
3)mmdrv的句柄數 隨著虛擬用戶的運行而增加
4)當建立連接時出現"No buffer space available"錯誤信息
解決方法
編輯以下注冊表項：
1.為了避免出現"No Buffer Space Available"的錯誤，需要進行如下配置：1）修改注冊表：* 設置"HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters\TcpTimedWaitDelay"為 30* 設置"HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters\MaxUserPort"為 65534* 在"HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SessionManager\Sub Systems\Windows"設置SharedSection 為 4096 2）通過在每個腳本的開頭添加如下函數來設置"SHUTDOWN"模式為"ABRUPT"web_set_sockets_option("SHUTDOWN_MODE","ABRUPT")
第二步：配置LR
1)腳本運行時設置
消息處理時勾選"send message only when error occurs"
禁用snapshot on error
"define each step as a transaction"取消勾選
取消"simulate browser cache"勾選, 勾選"simulate new user on each iteration"和它的子選項
2)將腳本中web_url函數中的"Mode=HTML"默認方式改為"Mode=HTTP",這將減小LG機器上的壓力(不解析HTML)
3)將在controller的diagnostics->configuration中，禁止web page breakdown
4)在Controller通過Tools > Options > Run-Time Settings限制同一時間在所有LG上初始化虛擬用戶的數值，設置會被每臺LG獲得，這樣做的目的是為了避免在腳本執行的初始階段LG系統資源的過度利用.
5)限制controller在運行時存儲的錯誤數.通過修改wlrun.ini中的[output]項來實現:? FlagLimitOutputMessages=1? MaxNumberOfOutputMessages=<errors count> (default is 10,000)
6)在Controller通過Tools>Options>Monitors修改monitor的采樣率，這將減小測試運行時Controller的CPU利用率，如下圖所示：
7)修改wlrun7.ini中的ExportMessagesToFile=1重定向輸出信息到.txt文件而不是到MDB文件
此外：關閉Controller和LG上的防病毒,防間諜軟件,關于運行在以上電腦上不要的Windows服務；在Controller不要運行虛擬用戶；不要頻繁打開Error/Output窗口，因為這將增加額外Controller上額外的數據庫連接數這些都是對進行成功的大負載測試的有益的建議。
第三步：修改腳本
1)在負載測試時，保證Controller和Generator的網絡通信非常重要，大量的信息（error message,output message）大并發負載測試有著很大的負面影響
如以下兩例
把腳本中所與打印信息的腳本去掉.如下面的代碼每次迭代都會調用一次,對大量并發用戶的運行產生負面的影響.
Controller處理所有虛擬用戶的信息,這樣會大大降低Controller的性能. 如下是類似的代碼:
這些語句都僅僅應該出現在腳本調試時而不應該出現在負載測試時的腳本中，在正式的負載測試前，注釋掉這些語句。
2)去掉腳本中所有的sleep()的調用,用lr_think_time()來代替.lr_think_time給LR讓出控制,即LR能夠在Vuser休眠的時候去做其他有用的事情.不要去掉lr_think_time:使用該函數能更準確的模擬負載,對LG產生相對小的壓力
3)web_reg_save_param和web_reg_find()函數:在 web_reg_save_param() 中添加"Notfound=empty" 參數.在 web_reg_find() 添加 "Savecount=some_parameter_name". 如果你想知道它是否成功可以使用atoi(lr_eval_string("{some_paramater_name }"))來衡量.
第四步：設置組策略
大負載測試時會有以下情況發生：
●產生很多錯誤，數據量大于1GB
●假如每秒產生1000條左右錯誤的話，Controller的行為將很難預測
●壓力測試產生很多運行數據
這些問題可以通過設置一個合理的組策略避免，以下舉一個例子說明
場景為1000個虛擬用戶，用一個Group運行
這時把這個Group分為兩個Group：
G1-〉100 Vusers
G2-〉900 Vusers
這兩個組可以跟原始的組產生一樣的負載,對于G2在組命令行中添加如下參數:-disable_data -disable_messages_disable_data : 讓這個組不發送任何信息,不發送任何online信息,不寫任何offline信息._disable_message: 讓這個組不給Controller發送任何信息(錯誤,日志)注意:使用上面的命令行選項會使該LG不給congtroller發送online和offline信息.這樣這個組上的虛擬用戶的分析數據就收集不到了.
總結：
通過一段時間的學習發現，結合LR自帶的使用手冊，以及在網上找的N多資料，多看學習視頻，然后多動手操作。慢慢的LR的一些操作步驟就會做的，所謂熟能生巧就是這回事情，至于分析結果這塊所涉及的東西很多，這個要靠長期的經驗的積累和學習。堅持做做多學多問，就很收獲良多。加油！