第一步：計劃測試
1、明確壓力點，根據壓力點設計多少種場景組合
2、把文檔（包括多少種場景組合、場景與場景組合條件的對應表）寫好
3、如果監測UNIX機器，在被監測的機器需要安裝監測Unix的進程
4、讓開發人員幫助我們準備測試數據或他們寫相關的文檔我們來準備數據
5、讓開發人員做一個恢復數據的腳本，以便于我們每次測試的時候都能夠有一個相同的環境
6、針對每一個模塊包括四個子文件夾：如模塊A下包括“腳本”“場景”“結果”“圖表” 四個子文件夾，每個子文件夾儲存對應的文件，如下表所示
其中：結果名“1場景”是在場景中的“Results Setting”中設置的，具體的設置見“建立場景”部分，這里也可以有另外一種方法：在打開模板設置，如下：
選中“Automatically save the session as:”并且在“%ResultDir%”后面填寫你想保存的文件名，當你打開某個lrr文件時，系統自動在當前目錄中生成一個文件保存分析圖表，如下圖所示：
第二步：生成測試腳本
1、把登陸部分放到“vuser_init”部分,把需要測試的內容部分放到“Action”部分執行；但是如果是模擬多個用戶登陸系統，則要把登陸部分放到Action部分來實現
2、錄制腳本后，想查詢某個函數的原型，按“F1”鍵
3、確認腳本中哪些參數是需要進行參數化的（最好能可以和開發人員一起確認）
4、在腳本參數化時把函數web_submit_data()中的ITEMDATA后面的數據參數化，因為這些數據是傳遞給服務器的，當然也可以把一個函數中的所有相同變量都替換掉
5、腳本中無用的部分用“/*”“*/”“//”注釋掉，但最好不要刪除
6、調試腳本遵循以下原則：
確認在VU里SUSI（單用戶單循環次數single user & single iteration）
確認在VU里SUMI（單用戶多循環次數single user & multi iteration）
確認在controller中MUSI（多用戶單循環次數multi user & single iteration）
確認在controller中MUMI（多用戶多循環次數 multi user & multi iteration）
7、事務的名稱取的有意義便于事務之間的區分，把所有的事務名都記錄在一起，便于在測試結果概要中區分它們，這要寫成一個表：某次測試有哪些模塊，每個模塊中有哪些事務(見對應的“關系表”)
8、在 “Parameter List”中可以選擇參數類型“Random Number”，使某一個參數取設定的范圍內的隨機值
第三步：建立場景
1、 把場景名稱編號，并制定出一份場景名稱和場景條件組合的對應表。比如，場景m對應于“某一模塊_xx個vu _分z臺machine”(見“關系表”中的例子)
2、 根據上面的對應表把場景設置好，需要設置的要素如下：總體多少個用戶、分多少個組、每個組有多少個用戶、分幾臺機器運行、每個腳本迭代多少次、是否回放think time時間、檢查Parameter List中每個參數設置是否正確、參數從表中取值間隔是否正確、是否選中“Initialize all Vusers before Run”
3、 測試結果應該保存為“m場景0，m場景1,…”
4、 把虛擬用戶分散到幾臺機器上和在一臺機器上面都要進行測試，因為有可以效果不同
5、 場景中如果有需要改動的地方，必須新建一個場景(建議使用“另存為”，然后再修改結果文件名，再選擇相應的腳本)，并把場景按順序編號，先維護好場景與場景組合條件的對應表，以便以后的查找，并且在結果 “Results Setting”中設置的結果名與場景名相同。建議在“Results Setting”中選中“Automatically create a results directory for each scenario executeon”讓它每次自動累加，不建議選中“Automatically overwrite existing results directory without prompting for confirmation”，因為我們不要覆蓋掉以前的測試結果，把它保存下來以便有個根據。
6、 需要注意的地方：當在“Parameter List”中的“Select next row”選中“Unique”時，如果再在“Edit Schedule\Schedule by Scenario\Duration”中選中第二項“Run for XX after the ramp up has been completed”時系統就會報錯，提示“Unique”類型不相符。
7、 在“Run-time Setting”設置中，“General”中的“Pacing”非常有用，可以設置每次迭代之間相隔多少時間，也可以是隨機的取值
8、 建議：把“Parameter List”和“Run-time Setting”中的所有設置都搞熟悉，這樣便于以后對腳本和場景進行設置
9、 設計“Parameter List”時的小技巧：即在“Allocate X values for each Vuser”時，盡量 把它的間隔在數據容許的范圍內取大些，這樣可以做從一次迭代到最大值迭代，而且對腳本沒有什么影響
10、當一個腳本中有多個事務，在事務前面增加集合點時需要一點技巧�；蛘呶覀儼涯_本復制幾個，或者我這樣做：測試前面的事務的壓力時，把后面的事務前的集合點設置為不激活狀態；在測試后面的事務的壓力時，把前面的事務的集合點設置為不激活狀態，另外最好不選中Initialize all Vusers before Run，具體參見Controller中的“Scenario/Rendezvous”，及用戶手冊(按F1)
11、把持續時間從最后60秒改為整個場景的時間，右鍵單擊某個圖，選擇“Configue”，修
改Graph Time即可
12、每次從一個場景修改后保存為另一個場景時別忘記把結果保存文件名修改相對應的文件名。在設置結果保存文件名時有一個技巧：如果你打開這個窗口時，點擊確定則系統會
默認以“4場景2”為基點向后加“4場景20”“4場景21”等等，但是如果你把結果文件名后面的數據去掉，改為“4場景”，點擊確定后，系統會自動搜索是以“4場景”開頭的文件名，并在它的后面繼續增加，比如把它改為“4場景”時，下次結果保存在“4場景3”中。而且他在搜索的時候搜索以“4場景”開頭的文件名，從0開始，有的話就不取代而跳過，沒有的話就取代。
第四步：運行場景
1、 運行場景前需要注意的事項：每個組的虛擬用戶數、迭代次數、think time、參數化時的取值間隔、執行恢復數據的腳本、確認虛擬機的LoadRunner Agent Service打開
2、 如果監測Unix，運行場景前需要啟動監測Unix進程，啟動的命令“rpc.rstatd”、查看這個進程是否啟動的命令“rpcinfo –p”
3、 運行前使Generator機器處理Ready狀態
4、 確認被監測的機器已經連接上去，并且添加自己所需要的計數器
5、 運行之前一定要確認系統中壓力點的數據量是多少
6、 確認以上都正確時再運行測試場景
第五步：監視場景
1、打開 “Passed Transactions”或“Failed Transactions”，可以隨時觀察到事務的運行狀態
第六步：分析測試結果
1、 打開Analysis后，把經過數據處理的結果圖表保存到“圖表”文件夾，并且文件名和場景名、結果名相同，這樣便于以后的查閱。也可以省去每次進行數據處理的時間。
2、 可以通過點擊界面上的 “View Run Time Setting”可以看到此場景運行時的一些場景設置
3、 在關聯圖表時可以自動調節每個元素的比例，點擊右鍵，選擇 即可
4、 每次測試結束后確認所做的操作是正確的，確認正確后再分析結果
5、 在結果文件夾中為每個場景建立一個文檔，把每次運行時的情況記錄下來以便于寫測試報告，尤其運行錯誤的原因記錄下來，并把開發人員所做的修改也記錄下來以便知道開發人員做了些什么修改
6、 在分析運行結果時可以把幾個結果合在一起進行比較，打開如下“Cross with Result…”
即可，然后增加一個運行結果，這樣就可以把你所需要的結果放到一起比較了
不好意思，部分圖片沒有上傳。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
