LoadRunner進行性能測試過程講解第一頁，共59頁。概述本次講解的目的： 能夠再經過少量的指導就可以直接在實際工作中使用LR進行性能測試；演示實例：綜合運維支撐系統用戶工單接單的性能測試講解的內容：性能測試執行過程，從中講解參數化、集合點、事務、檢查點、場景設置、結果分析

第二頁，共59頁。性能測試執行過程性能測試執行過程大致分為：數據準備錄制、編輯及調試腳本設置及調試場景執行場景分析結果第三頁，共59頁。一、數據準備

數據準備是根據測試的需要，在執行測試之前在被測系統中加入的符合要求的數據。比如，我們在測試接單性能時，需要有待接的工單，那么這些待接的工單就是在數據準備階段完成的。第四頁，共59頁。一、數據準備數據準備方法1.手工要加的數據量比較少的情況下可以手工在系統中加。比如加一個接單的用戶2.使用LR或其他自動化測試工具在數據量比較多情況下就要使用工具（LR/QTP等），我們常用的就是LR，錄制一個加數據的腳本，反復迭代運行腳本或在場景中運行腳本，數據會生成到系統里面去，這種方法也只適用于插入幾千條數據

第五頁，共59頁。一、數據準備3.數據直接寫入數據庫這種方法在插入數據時是最快的，但在準備這些插入數據的sql語句（或存儲過程）時卻很麻煩，因為生成一條系統中能流轉的數據需要很多表關聯，這個需要開發人員大力協助，最理想的是直接要開發人員提供寫好了的存儲過程，我們只運行，不過一般情況下由開發人員提供表信息，然后告訴你怎么做，然后自己組裝sql。這種方法適用于數據量非常大的情況第六頁，共59頁。二、腳本

－－錄制腳本錄制腳本操作步驟請參見LR的操作手冊，這里說一下需要注意的地方。1.最好在腳本錄制的過程中加入備注、集合點和事務2.在編輯腳本前備份一個原始腳本3.再錄制一個同樣操作的腳本，用于與剛才錄制的腳本進行對比，查找出哪些需要參數化值4.兩個用于進行對比的腳本存放的絕對路徑不要太長，比如桌面，這時將無法比較第七頁，共59頁。二、腳本

－－插入集合點插入集合點的目的就是控制所有用戶同時并發開始執行某個動作。例：測試用戶并發接單的性能，則把集合點插入到接單動作提交的前面。這時，先到的用戶該集合點的用戶要等后到集合點的用戶，然后一起執行提交操作。第八頁，共59頁。二、腳本

－－插入事務添加事務的主要目的就是要得到事務開始時間和事務結束時間之間的間隔時間，即事務響應時間；我們把關注的某些動作定義為一個事務，在場景運行時，LR就會自動記錄該事務的所花的時間；如果場景是多用戶并發，迭代多次，則LR會給出事務最大的響應時間、最小響應時間和平均響應時間，我們一般看的是平均響應時間；一個腳本中可以加入多個事務，一個事務也放到另一個事務里面；第九頁，共59頁。二、腳本

－－參數化找出需要參數化的字段1.打開一個腳本，選擇另一個相同操作步驟的腳本用比較器比較第十頁，共59頁。在比較器中查看兩個腳本不同的地方，腳本中不同的地方用黃色標識出來

可能會標識出很多不同的地方，但有些地方我們可以不去管它，比如下載的圖片資源，思考時間等，有些地方則是很可能要參數化的，比如某某ID或value＝一串類似隨機字符串，根據經驗初步判斷哪些是需要參數化的記錄下來。二、腳本

－－參數化第十一頁，共59頁。二、腳本

－－參數化從相關開發人員那里獲取得到這些值的SQL語句

找開發人員要sql語句之前，我們必須清楚我們需要什么樣的數據，比如：接單腳本參數化我們需要特定人待辦的用戶工單的recordsn字段的值

一般項目經理都會告訴你誰開發哪一塊，測哪塊的程序，找相關的開發人員即可，并且他們也會大致告訴你這些表是做什么用的，這些信息是很有用的，以后我們可以自己改sql語句得到更適合我們測試的sql語句。

第十二頁，共59頁。二、腳本

－－參數化待接單參數化需要的sql語句如下：selectm.clogcode,d.recordsnfromsvr_pub_da_dispqueued,org_usero,svr_pub_da_mainqueuemwhered.mainsn=m.mainsnandd.repairoper=o.userid（表與表間的關聯）andm.business='961300261A9D55CD70029C68FE8C4F4F'（工單類型：用戶工單）andcessflag='ACCEPT'（過程標識：接單）ando.loginname=‘張林’（當前待辦箱：張林）andclogcodeLike'zl%'（附加標識：準備數據時方便以后自己識別加入的特殊標識）OrderByclogcode另：svr_pub_da_dispqueue派工工單處理表，也就是子單的一些信息

svr_pub_da_mainqueue工單主表，也就是主單的信息，張主單包含多張子單第十三頁，共59頁。二、腳本

－－參數化參數化1.建立參數化文件*.dat，放入腳本文件夾內2.在PLSQL中根據sql語句查詢出所得的數據，拷貝到參數化文件內3.在腳本中找到要參數化的字段，對其進行參數化，引用參數化文件中的數據第十四頁，共59頁。二、腳本

－－參數化調試腳本，驗證參數化是否正確

1.在腳本編輯器中用少量的迭代次數反復運行腳本；

2.在場景中用少量并發數和迭代數運行腳本。參照下面規則，如果兩種驗證方式都通過，則參數化成功，否則繼續調試腳本。第十五頁，共59頁。二、腳本

－－參數化是否參數化成功規則：如果迭代運行通過，并且使用的參數化值正確，并且被測系統得到的結果和預期結果相同（工單正確流轉），則參數化成功；如果迭代運行不通過，或者引用的參數化的值不是預期的值，或者被測系統中對應的工單沒有正確流轉，則參數化不成功，此時需要：

1.根據錯誤提示解決問題；（比如服務器未連上）

2.檢查參數化值，取數據的方式設置是否正確，調整設置；（比如參數化值的數量不夠）

3.檢查sql語句查出來的數據是否符合要求，主要是看條件限制是否足夠，調整sql語句；（比如需要的是某人的待接單，但查得的是所有未歸檔單據）

4.檢查是否還有需要參數化的值，需要參數化的值再進行參數化（比如有兩個字段需要參數化，但只對一個字段進行了參數化）

5.運行腳本，重復上面的動作，直至參數化成功為止第十六頁，共59頁。二、腳本

－－檢查點為什么要加入檢查點檢查點是檢查腳本運行后，是否真的得到了預期結果。因為曾經發現場景運行后，LR反饋事務運行成功，但其實沒有真正運行成功，工單沒有流轉。雖然我們可以在數據庫中查詢工單的狀態，但插入檢查點后，在場景運行的過程中就可以看到事務運行是否出現了問題，比在數據庫中看更加方便；另外，像測試查詢的性能類的腳本，在數據庫中是看不到變化的，所以插入檢查點就是非常必要的了。

第十七頁，共59頁。二、腳本

－－檢查點檢查點實例（接單腳本的檢查點）

■首先要考慮，在系統中我們手工接單的時候是怎么判斷工單流轉是否成功的，是看接單后工單狀態是否變為了“待回單”，那么，我們就以此做為檢查點。

■接著要在腳本中找到插入檢查點的正確位置。在錄制接單腳本時，已經為設置檢查點做了準備，在接單完成后又在待辦箱查詢了一次剛才接的工單。檢查點就設在查詢出的工單那里。

第十八頁，共59頁。二、腳本

－－檢查點■檢查點實例（接單腳本的檢查點）加入檢查點函數：

web_reg_find("Text=title=\"待回單","SaveCount=i",LAST);

檢查當前頁面上是否有“Text=title=\”待回單”這個字符串，把找到的次數保存在i這個變量里面，因為這個函數必須是先注冊再用，所以把上面這段代碼加在查詢前面。

在用戶工單待辦箱頁面上可以看到，查詢出一張待回單工單，頁面上會有兩個待回單的圖標標識，意味著，i＝2時，才是查到一張待回單，如果i＝1，腳本運行也不會報錯，但其實工單并沒有流轉到待回單。所以我們要對i值進行判斷，看是否等于2 if(atoi(lr_eval_string("{i}"))==2){lr_output_message("找到2次,操作成功！");}elseif(atoi(lr_eval_string("{i}"))==1){ lr_error_message("找到1次，操作沒成功！");}elseif。。。。。。

上面這段代碼要加在查詢后面，查詢之后才能看到結果。場景運行時，如果待回單標識只找到一次，就會有錯誤報出來，lr_error_message實現。第十九頁，共59頁。二、腳本

－－檢查點■檢查點實例（接單腳本的檢查點）根據檢查點函數收集到的數值，判斷工單是否流轉成功：在用戶工單待辦箱頁面上可以看到，查詢出一張待回單工單，頁面上會有兩個待回單的圖標標識，意味著，i＝2時，才是查到一張待回單，如果i＝1，腳本運行也不會報錯，但其實工單并沒有流轉到待回單。所以我們要對i值進行判斷，看是否等于2 if(atoi(lr_eval_string("{i}"))==2){lr_output_message("找到2次,操作成功！");}elseif(atoi(lr_eval_string("{i}"))==1){ lr_error_message("找到1次，操作沒成功！");}elseif。。。。。。

上面這段代碼要加在查詢后面，因為查詢之后才能看到結果。場景運行過程中，如果待回單標識只找到一次，就會有錯誤在場景執行界面報出來，由lr_error_message實現。第二十頁，共59頁。二、腳本

－－檢查點調試腳本，驗證檢查點是否起作用至少要用一個驗證反例來驗證檢查點是否真的有效。比如，更改驗證的字符串標識為“待接單”，運行場景查詢同樣的待回單工單出來，看是否報錯；

■如果不報錯，說明檢查點沒起作用，要檢查加入的檢查點位置是否正確，語句是否正確，或改用其他檢查方式來設檢查點；

■如果反饋報錯信息“找到1次，操作沒成功！”說明檢查點設置生效了，可以繼續往下做。第二十一頁，共59頁。二、腳本

－－調整腳本在腳本調試的過程中，我們已經執行了很多次場景了，在沒有正式測試之前就有可能發現系統的什么地方比較非常耗時，甚至導致運行不到我們本次測試關注的地方。在這種情況下，我們可以對那些比較耗時的代碼段專門再加事務，正式測試的過程中也關注一下這個事務；如果是影響到我們后面運行的代碼段，且屏蔽掉后不影響本次測試的，則先屏蔽掉該代碼段，繼續后面的測試，但在測試報告中告之該代碼段對應的操作性能有問題。

第二十二頁，共59頁。二、腳本

－－調整腳本實例：原來的系統，進入工單查詢界面會默認刷新一次顯示一頁工單，然后才可輸入查詢條件查詢。當然錄制根據條件查詢的腳本也是這個過程。問題是在基礎數量很大的情況下，進入工單查詢，默認刷新頁面這個動作基本上完成不了，所以后面的根據條件來查詢也就測不了。所以最后在腳本中屏蔽掉了默認刷新的代碼，繼續輸入查詢條件查詢的性能測試。當然默認刷新顯示不了工單列表的問題也要告之開發組。在以后發布的測試版本中，開發組針對此問題作了改進，在進入工單查詢界面時，不默認刷新出工單列表，而是讓用戶自己輸入查詢條件，從而避免了上述問題。至于如何知道某個操作對應在腳本中的代碼，就是我在前面錄制腳本中提到的要多寫操作的備注信息，方便查找。第二十三頁，共59頁。三、場景

－－場景分類場景模式的選擇

場景分為手工場景和面向目標的場景。◆手工場景要達到某個測試目的需要根據場景每次運行的結果，需要使用者自己調整虛擬用戶數，直到達到預期目標。◆面向目標場景是在場景運行前設置了目標值，LR在運行的過程中自動逐步加載虛擬用戶以達到預設的目標。

目前我們用的都是手工場景，面向目標的場景還沒有仔細研究過，但前不久我試驗了一下，手工場景和面向對象場景得出的結果差別還比較大，現在還不知道具體原因，待以后解決。

第二十四頁，共59頁。三、場景

－－場景設置選擇腳本設置并發用戶數輸入要使用資源的電腦IP或主機名，連接上Run-timeSettings,設置迭代次數、設置每次迭代的間隔時間、設置只輸出標準日志、忽略思考時間、局域網內不使用代理設置檢查點有效第二十五頁，共59頁。三、場景

－－場景設置設置集合點。◆并發用戶數多的情況下，選擇第一或第三項，可以讓所有用戶都到達集合點后才開始事務；如果使用默認的第二項，所有正在運行的用戶到達集合點后，就開始運行事務了，此時可能還有用戶還處在初始化階段，沒有運行，執行的并發數是沒有到達預期設計的；◆并發數小的情況下，使用哪項都無所謂；◆可以適當將兩個用戶之間的等待時間設置大點。順便說一下，關于這里設置的超時，是設置的前后兩個虛擬用戶到達集合點的間隔，不是第一個虛擬用戶與最后一個虛擬用戶到達集合點的時間間隔。

第二十六頁，共59頁。三、場景

－－場景設置設置登入方式如果并發用戶數較大，最好選擇分批登入。如果選擇一次全部登入，有可能在登入被測系統時就運行失敗了，雖然在登入時候并沒有設置集合點，但登入時間也是相對集中的，壓力較大。第二十七頁，共59頁。三、場景

－－場景設置選擇自動載入分析，場景運行結束后會自動載入分析結果；如果沒有選擇，點工具欄上的“AnalyzeResults”按鈕也可以載入結果

第二十八頁，共59頁。三、場景

－－場景設置設置結果保存路徑，也可以設置自動保存結果，但一般不要選擇自動覆蓋結果，以免誤操作覆蓋掉以前有用的結果第二十九頁，共59頁。三、場景

－－場景設置加入需要監控主機及相關系統資源計數器◆將被測系統的服務器的操作系統拖入顯示窗口◆在窗口中點右鍵，增加一個服務器的IP，聯接上該服務器◆選擇關注的系統資源計數器第三十頁，共59頁。三、場景

－－場景設置加入oracle指標計數器◆將oracle拖入顯示窗口

第三十一頁，共59頁。三、場景

－－場景設置◆連接oracle，其中servername是你本機配置的服務名，登入用戶可以是system也可以是其他用戶第三十二頁，共59頁。三、場景

－－場景設置◆加入關注的計數器，注意選擇obiect時選擇第三項，否則得不到數據。至于這一項具體的內容，介紹一個網址，大家可以去看看：

這里面有一些常用統計的解釋，內容較多不在此列出。第三十三頁，共59頁。三、場景

－－場景設置比如加入physicalreads第三十四頁，共59頁。三、場景

－－場景執行在場景執行的過程中，可以看到執行的信息，如果發現有大量事務報錯或執行時間特別長，可以終止本次執行；但要根據報錯信息判斷是否因為系統無法支撐本次并發數導致的，如果是，則要減少用戶數后再次執行；如果不是，查找錯誤原因，解決錯誤之后再次執行。對同一類場景，要多執行幾次，找出出現次數較多的那個響應時間。另外，在監控linux系統的性能指標時，可以用vmstat、iostat命令來獲得一些信息供以后分析。第三十五頁，共59頁。三、結果分析

－－結果摘要分析結果摘要中包括了本次測試結果大概的信息，我們關注比較多的有：

◆執行的場景的路徑，保存結果的路徑，執行了多長時間◆最大并發用戶數◆事務的通過數，失敗數，終止數◆事務的響應時間◆返回的http狀態代碼，主要看有沒有錯誤信息（參考附件“返回http代碼狀態”）第三十六頁，共59頁。三、結果分析

－－加入新圖表加入新圖表，通常有操作系統相關、數據庫相關、事務相關、網頁細分相關

第三十七頁，共59頁。三、結果分析

－－事務分析查看事務是否通過及響應時間

◆在事務摘要中，看要測試的事務（比如接單事務）是否全部運行通過。如果沒有全部通過，說明在場景運行的過程中出了問題，查找原因；如果全部通過接著查看下面的；◆如果加有檢查點的事務，看檢查點事務是否全部運行成功；如果沒有全部通過，說明在場景運行的過程中出了問題，查找原因；如果全部通過接著查看下面的；◆事務執行后可以在數據庫中看到相應的變化，最好查看數據庫里面的記錄的變化內容及數量，是否與前面的事務執行通過數一致。如果是一致的才算是場景真的執行通過了；◆事務全部通過了，它的平均響應時間才有意義。查看它的平均響應時間是否在我們的要求內，適當增減并發用戶數再執行。

第三十八頁，共59頁。三、結果分析

－－事務分析事務執行未通過，考慮：

◆是否需要更改場景運行的設置（比如接受HTTP請求響應時間默認是120秒超時，如果需要可以改大一點）◆負載過大，服務器的系統資源（CPU、內存、磁盤等）不足以支持事務執行；這種情況下，要分析是哪種系統資源不足，然后再分析是硬件瓶頸引起的還是由程序引起的。◆負載不大，服務器所有資源充足，但仍有事務未運行成功。這種情況主要考慮是否是被測程序的問題。事務響應時間過長，同上面的第二和第三點

第三十九頁，共59頁。三、結果分析

－－獲取常用性能指標目前在做性能測試的時候，如果測的是windows系統，一般就只用LR監控就可以了，在設置場景時加入windows相關的計數器；如果測試的是linux系統，則還要用linux的命令（常用的有vmstat、iostat），因為LR里面包含的linux相關的計數器比較少，所以用這些命令做為補充。第四十頁，共59頁。三、結果分析

－－常用指標分析LR指標－CPUUtilization(CPU利用率)

一般認為，CPU連續長時間處在95％（90％）以上，則可能是CPU的瓶頸。◆“長時間”究竟定義為多長？以前我認為是5秒，因為經常說用戶能忍受的響應時間是5秒，連續5秒CPU都占用95％以上，那事務響應時間很有可能就在5秒以上了；后來做了幾次測試之后我發覺有一點不對，如果拋開用戶能夠承受的事務響應時間，單單來找系統瓶頸時會發現，5秒其實是一個很短的時間。現在我認為“長時間”只是個相對數，相對于事務的執行時間。比如說，假如事務執行時間有10秒，而在事務執行的這段時間內大部分時間（8秒）CPU占用率都在95％以上，那么可以說8秒的時間較長了，可能CPU資源是系統瓶頸；但如果事務執行時間是60秒，其中有連續10秒鐘CPU占用在95％以上，那么這10秒其實算是比較短的了，應該是其他問題導致事務運行花了60秒。第四十一頁，共59頁。三、結果分析

－－常用指標分析LR指標－CPUUtilization(CPU利用率)◆在LR的分析結果中可以看到CPU的平均值，在很多情況下，CPU的平均值都不到90%，但已經可以認為CPU是系統瓶頸了。因為我們在執行場景的時間一般不會太長，所以，在場景剛開始運行時CPU的小值對平均值的影響較大，如果場景運行時迭代次數足夠多，運行時間足夠長則不會存在該問題。在目前的情況下，我們主要還是看事務處理過程中的CPU的利用率，而不是去看平均值，平均值、最大值、最小值，只能做為參考。◆CPU的占用是系統占用和用戶占用之和。一般情況下，系統占用率是很小，5%可能都不到，主要用戶占用多，所以平常我們先看一下是否系統占用是否正常，然后就只看CPU占用的總數就可以了。第四十二頁，共59頁。三、結果分析

－－常用指標分析LR指標－內存相關主要看可用內存和是否頻繁換頁◆如果系統可用內存變的很小，內存可能成為系統瓶頸◆如果頁交換頻繁，將嚴重影響系統性能

第四十三頁，共59頁。三、結果分析

－－常用指標分析LR指標－內存相關可用內存

◆如果是windows系統，直接在LR里面看free的值就行了，建議閥值是4M，不能小于4M。如果發現已經接近4M了，說明可用物理內存不夠了。◆如果是linux系統，LR里面沒有可用物理內存大小的參數。需借助于vmstat命令，后面詳述。

第四十四頁，共59頁。三、結果分析

－－常用指標分析

LR指標－內存相關◆頁交換主要看outrate

每秒從物理內存中換出到磁盤上頁交換文件的頁數。這里可以看到平均值、最大最小值，如果平均值很大，說明有很多的頁交換發生，內存可能不足，需要告訴開發組查找原因。至于值為多大才算大，在網上也沒有找到一個確數，可能要靠經驗的積累。不過如果是達到幾百，頁交換應該是比較頻繁了。

第四十五頁，共59頁。三、結果分析

－－常用指標分析LR指標－Averageload（平均負載）在過去的1分鐘內運行隊列中的平均進程數量。該數值除以cpu個數（邏輯個數）小于5，則是在可接受的范圍，否則說明該服務器負載過重。第四十六頁，共59頁。三、結果分析

－－常用指標分析LR指標－Oracle相關●SELECTname,valueFROMV$sysstatWHEREname=’redologspacerequest‘;

此處value的值應接近于0，否則，應增大初始化參數文件的Log_buffers的值通過查詢V$sysstat表判定redolog（重做日志）文件緩沖區是否足夠。

實際測試過程中，只需要在場景中添加“redologspacerequest”這個計數器即可。第四十七頁，共59頁。三、結果分析

－－常用指標分析●LR指標－數據庫緩沖命中率：命中率=1-physical

reads/(dbblock

gets+consistent

gets)

該值要在90％以上，如果小于90％，則要考慮增加databuffer（數據緩沖區）的大小第四十八頁，共59頁。三、結果分析

－－常用指標分析對linux系統性能的監控和分析，用LR關注的比較少，主要用的是vmstat和iostat命令。◆vmstat對系統的進程情況、內存使用情況、交換頁和I/O塊使用情況、中斷以及CPU使用情況進行統計并報告相應的信息。第一個顯示內容指出了計算機重啟至今的平均使用情況。后面的每一行信息是按延時定期地顯示系統的各部分信息。進程信息和內存信息都是即時產生的。◆iostat也包括了CPU的使用情況，不過它的主要特點是匯報磁盤活動的情況。如果用vmstat命令發現問題可能與磁盤相關，則再用iostat命令來進一步分析磁盤活動。第四十九頁，共59頁。三、結果分析

－－常用指標分析Vmstat命令◆[root@test2~]#vmstat1procsmemory--swap--iosystemcpurbswpdfreebuffcachesisobiboincsussyidwa◆對上面我們關注的指標的分析：●r:進程等待隊列長度，閥值是cpu個數*4,這里的cpu個數指的是邏輯cpu的個數（cat/proc/cpuinfo可以看到）。●id：CPU的空閑時間。粗略的來看，反過來就是占用時間。

第五十頁，共59頁。三、結果分析

－－常用指標分析Vmstat命令相關指標的分析從r和id值看CPU的使用情況。如果r值長時間很大、id值長時間很小，（長時間有很多進程等待，且cpu占用長時間很大），說明CPU資源有可能不足；如果r值長時間很大，id值只是偶爾很小，（長時間有很多進程等待，但cpu大部分時間空閑），說明應該不是cpu硬件處理能力的問題，要找程序的原因；如果r值偶爾很大、id值長時間很小，（偶爾有較多的進程等待處理，但大部分不是，但cpu占用長時間很大），雖然CPU占用很厲害，但只要有進程過來基本上馬上就能處理，至少目前不能說明cpu資源不足。在實際測試的過程中也可以看到這種情況，但事務響應較快。第五十一頁，共59頁。三、結果分析

－－常用指標分析Vmstat命令相關指標的分析●free:空閑的內存，單位KB●buff:被用來做為緩存的內存數，單位：KB●cache：被用來做為cache的內存數，單位：KBvmstat得到的free的值與windows系統的free值不同，不是可用內存，是自由內存，就是還沒有被使用過的內存；linux的內存管理機制認為，用戶可用的內存＝free＋buff＋cache，所以單看free值是沒有意義的。經常會看到free值很小，只有2～3M，但實際可用物理內存要大的多。第五十二頁，共59頁。三、結果分析

－－常用指標分析Vmstat命令相關指標的分析●swpd:虛擬內存使用情況，單位