集合點的用處對于LoadRunner來說意義非常大，它可以設置多個虛擬用戶等待到一個點，同時觸發一個事務，以達到模擬真實環境下同時多個用戶操作，同時模擬負載，實現性能測試的最終目的。由此可見，插入集合點主要是為了衡量在加重負載的情況下服務器的性能情況。
　　舉例如下：在客戶的需求中，可能會要求系統能夠承受1000人同時提交數據。在LoadRunner中可以通過在提交數據操作前面加入集合點，當虛擬用戶運行到提交數據的集合點時，Loadrunner就會檢查同時有多少用戶運行到集合點，如果我們設定腳本運行的虛擬用戶數為1000，等到這1000個虛擬用戶都運行到集合點后，就會觸發同時進行提交數據的操作，從而能夠測試系統對于這1000個用戶提交數據的響應情況，依次來看系統是否滿足客戶的該點需求。
　　集合點除了用于多用戶并發操作對服務器施壓的性能測試外，還可以用戶系統的功能測試，而且這些功能測試都是手工測試所不能實現的，下面以本人實際遇到的兩種情況進行說明。
　　A. 用集合點測試編號生成策略：
　　被測系統為一個訂單處理的準生產系統，在系統中形成訂單的時候會自動生成訂單編號，訂單編號的生成規則是【日期+時間+4位隨機數+2位編號】，如：20091216104924276201，系統中要保證所有生成的訂單編號不能重復，而訂單編號中關系編號是否重復的關鍵是“4位隨機數”。現在系統的實際操作可能會出現同時有200個訂單錄入員提交訂單，提交訂單時會生成訂單編號，要保證不會出現重復的編號，設計測試用例：在提交訂單之前插入集合點，虛擬用戶為200，運行腳本，運行結束后查看運行后提交的訂單個數，然后查看訂單編號是否有重復的情況;
　　如果運行腳本發現頻繁出現有訂單編號重復的情況，可能訂單編號的4位隨機數生成策略不能滿足需求，需要考慮采用更好的生成策略;如果多次運行腳本未出現有訂單編號重復的情況，那么可以說明4為隨機數生成策略以滿足訂單編號生成的需求和設計。
　　B. 用集合點測試互斥鎖定策略：
　　被測系統還是訂單處理的準生產系統，生成后的訂單是可以被部分用戶把信息讀取到另一個系統中的，讀取的時候要保證一個訂單同時只能被一個用戶讀取，一旦一個訂單被一個用戶讀取到后，其他的用戶就不能再讀取到這個訂單，只能讀取到其他可以被讀取的訂單。讀取訂單時是可以選擇讀哪一個訂單，也可以不選定，不選定系統就會自動分配。
　　設計實現這個功能的時候，實現方式是，訂單被用戶讀取到后，就將該訂單加鎖，加鎖的訂單其他的用戶是不能讀取到的，這時系統就會按照策略分配其他可被提取的訂單給其他的用戶。手工測試是這樣進行的：
　　預置條件：系統中有多個待讀取的訂單A、B、C……，默認讀取順序就是A、B、C……
　　操作步驟：
　　1、用戶1選擇讀取訂單A，讀取成功;然后用戶2選擇讀取訂單A;
　　2、用戶1讀取訂單，讀取到訂單A;然后用戶2讀取訂單;
　　預期結果：
　　1、用戶2讀取訂單A失敗，返回正確合理的提示信息;
　　2、用戶2讀取到訂單B;
　　手工測試并未測試出設計和實現有什么樣的缺陷，功能正常。
　　考慮到客戶實際使用系統時，提取訂單的用戶是上百個的，很可能出現這些用戶同時讀取訂單的情況，這樣的場景下，幾個測試人員手工測試是不現實的，這時考慮設計集合點并觸發多個用戶同時進行讀取訂單事務操作就比較適用。
　　而實際運行的情況是，在訂單讀取操作前設置集合點，只使用兩個虛擬用戶在同一時刻讀取訂單就出現了讀取到同一訂單的情況，說明程序在實現上是存在缺陷的，這也很好的對手工測試不能覆蓋到的地方做了測試補充。
　　集合點插入方法：
　　1. 錄制時，在需要并發操作的事務前直接點擊插入集合的按鈕;
　　2. 錄制后，錄制的腳本中，在并發操作事務提交前插入，點擊右鍵，選擇，然后選擇后面出現的，輸入集合名稱，腳本中出現，即添加集合點成功;
　　備注：集合點只能插入到Action部分，vuser_init和vuser_end中不能插入集合點。如果想要測試系統所能支持同時登錄的用戶數，登錄的事務要寫入到Action中，然后插入集合點進行測試……

本文轉自（）

【點擊下載最新版LoadRunner試用】

<<<<2016年終盛“惠” 溫情啟幕，挑戰全年最低價 暢享五重奏！點擊查看>>>>