LoadRunner-關聯詳解
原文鏈接：http://blog.csdn.net/u011446864/article/details/38395975
關聯是LoadRunner的精髓，可以說不會關聯就不會性能測試，在網上有很多關於關聯的文章和博客，但是發現很多文章把做關聯時如何確定兩份腳本中不同的值是否需要關聯，以及關聯函數插入的位置的確定都介紹的很模糊，我感覺這裏是重點，因為這個過程有兩次查詢日誌的操作，且這兩次的目的並不一樣，而且兩次復制的查找內容也是不同的，初學者很容易搞暈。這裏網上很多教程介紹兩次都復制腳本中的動態值去日誌中查找，真心不明白。Replay log是回放日誌，腳本經過回放後服務器返回的唯一辨識碼已經改變，再次復制錄制時的腳本中的辨識碼去查找怎能找到？反正本人當初是被很多文章給誤解了。下面進入正題，我們用LoadRunner自帶的訂票系統做演示。
在做關聯之前我們先了解一下LoadRunner的工作原理，這樣更便於理解為什麽會做關聯。
當執行腳本時，VuGen偽裝成瀏覽器，然後根據腳本，把當初真的瀏覽器所說過的話，再對網站伺服器重新說一遍，VuGen企圖騙過服務器，讓服務器以為它就是當初的瀏覽器，然後把網站內容傳送給VuGen。
所以紀錄在腳本中要跟服務器所說的話，完全與當初錄制時所說的一樣，是寫死的（hard-coded）。這樣的作法在遇到有些比較聰明的服務器時，還是會失效。這時就需要透過「關聯（correlation）」的做法來讓VuGen可以再次成功地騙過服務器。
所謂的關聯（correlation）就是把腳本中某些寫死的（hard-coded）數據，轉變成是擷取自服務器所送的、動態的、每次都不一樣的數據。
舉一個常見的例子，服務器在每個瀏覽器第一次跟它要數據時，都會在數據中夾帶一個唯一的辨識碼，接下來就會利用這個辨識碼來辨識跟它要數據的是不是同一個瀏覽器。一般稱這個辨識碼為Session ID。對於每個新的交易，服務器都會產生新的Session ID給瀏覽器。這也就是為什麽執行腳本會失敗的原因，因為VuGen還是用舊的Session ID向服務器要數據，服務器會發現這個Session ID是失效的或是它根本不認識這個Session ID，當然就不會傳送正確的網頁數據給VuGen了。
如上圖，當錄制腳本時，瀏覽器送出網頁A的請求，服務器將網頁A的內容傳送給瀏覽器，並且夾帶了一個ID=123的數據，當瀏覽器再送出網頁B的情求時，這時就要用ID=123的數據，服務器才會認為這是合法的請求，並且把網頁B的內容送回給瀏覽器。
在執行腳本時會發生什麽狀況？瀏覽器再送出網頁B的請求時，用的還是當初錄制的ID=123的數據，而不是用服務器新給的ID=456，整個腳本的執行就會失敗。請仔細去理解此圖內容，這裏真正明白下面內容就好理解了。
手動關聯的過程大致如下：
第一步：錄制測試腳本，錄制二遍
第二步：使用BeyondComparePortable工具找出兩次腳本的不同，判斷是否需要進行關聯
第三步：確定插入關聯的位置
第四步：在VIEW TREE中使用web_reg_save_param函數手動建立關聯
第五步：將腳本中有用到關聯的數據，用參數代替
第六步：驗證關聯的正確性
下面詳細介紹：
第一步：
錄制測試腳本，錄制二遍
這一步就不用多說了，相同的操作，錄制兩份，分別保存
第二步：
使用BeyondComparePortable工具協助找出需要關聯的數據
1. 在第二份腳本中，點選VuGen的【Tools】>【Compare with Vuser…】，並選擇第一份腳本。
2. 接著BeyondComparePortable會開啟，同時顯示二份腳本，並顯示有差異的地方。WinDiff會以一整行黃色標示有差異的腳本，並且以紅色的字體顯示真正差異的文字。（假如沒看到紅色字體，請點選【Options】>【View】>【Show Inline Differences】）。
查看二份腳本中差異的部份，每一個差異都可能是需要做關聯的地方。
註意：lr_thik_time部分的差異可以忽略
找到不同的部分後，復制，然後打開Recording Log或是CodeGenerationLog.txt，按Ctrl+F，在查找窗口中粘貼差異部分的內容，點擊查找找到後，查看該部分的信息，確認是客戶端的請求信息還是服務器回應的信息
如果出現在$$$$$$ Request Header For Transaction With Id 3 Ended $$$$$$這個部分，那證明是客戶端發出的請求，這裏是不需要做關聯的
一般做的關聯都是出現在****** Response Header For Transaction With Id 7 ******和****** Response Body For Transaction With Id 7 ******中的部分。
在找到這個信息後，需要記錄如下信息：
a.記錄這個不同數據之前的內容和之後的內容
b.記錄這個不同數據出現的位置，是Header還是Body
第三步：
確認插入關聯的位置
我們在日誌中找到了兩次腳本的不同點的位置，根據這個位置，我們再確定是在哪個請求之後產生的，也就是說要定位發生不同點的response是由哪個request產生的，找到了這個請求的函數位置，我們就知道要往哪裏做關聯了
一般情況下關聯函數寫到發出請求的函數之前就可以了
第四步：
插入關聯函數
在插入關聯函數前，我們先介紹關聯函數web_reg_save_param
一個web_reg_save_param函數的例子：
web_reg_save_param ("sessionid",
"LB=Session_id:",
"RB=;",
"Search=Body",
LAST);
在這裏我們只介紹幾個常用參數的含義
語法：int web_reg_save_param(const char *ParamName, <list of Attributes>, LAST);
參數說明:
ParamName: 存放得到的動態內容的參數名稱
list of Attributes: 其它屬性，包括：Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert, SaveLen。屬性值不分大小寫
LB( Left Boundary ) : 返回信息的左邊界字串。該屬性必須有，並且區分大小寫。
RB( Right Boundary ): 返回信息的右邊界字串。該屬性必須有，並且區分大小寫。
Search : 返回信息的查找範圍。可以是Headers，Body，Noresource，All(缺省)。該屬性質可有可無。
那麽如何插入該關聯函數呢？
1.將vugun切換到 view tree 模式下
2.在左邊的列表中，找到在上一步發出請求的函數，點擊“右鍵”
選擇“insert before”
3.在彈出的“add step”對話框的“find function”中輸入“web_reg_save_param”，點擊“ok”
在“parameter name”中輸入,關聯函數的名稱，這裏最好有含義，“sessionid”
在“left boundary”中輸入，剛才記錄下的不同點字符串的左面的幾個字符，定義左邊界，Session_id:
在“right boundary”中輸入，剛才記錄下的不同點字符串的右面的幾個字符，定義右邊界，;
在“search in ”中，選擇“body”
點擊“ok”
4.回到腳本編輯模式下，查看該函數插入是否正確
在發出請求的函數前應該看到：
web_reg_save_param ("sessionid",
"LB=Session_id:",
"RB=;",
"Search=Body",
LAST);
第五步：
將腳本中有用到關聯的數據，用參數代替
如發出請求的參數如下，那麽將原來服務器返回的動態值使用{ sessionid } 來替換：
web_submit_form("login.php_2",
"Snapshot=t2.inf",
ITEMDATA,
"Name=login", "Value=wangjin", ENDITEM,
"Name=password", "Value=wangjin", ENDITEM,
"Name=Session_id","Value={ sessionid } ", ENDITEM,
"Name=Submit", "Value=Login", ENDITEM,
EXTRARES,
"URL=/media/images/border_bg_l.gif", ENDITEM,
"URL=/media/images/header_bg.gif", ENDITEM,
"URL=/media/images/th.gif", ENDITEM,
LAST);
第六步：
驗證關聯的正確性
回放腳本，驗證關聯的正確性
LoadRunner-關聯詳解