關聯是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，整個腳本的執行就會失敗。請仔細去理解此圖內容，這里真正明白下面內容就好理解了。

由于自動關聯很不靠譜，人還是比機器更智能，所以我們只介紹手動關聯，手動關聯的執行步驟大致如下：

1、使用相同的業務流程與數據，錄制二份腳本

2、找出兩份腳本中不同的地方

3、確定腳本中有差異的地方是否需要關聯

4、確定關聯函數的插入位置

5、使用web_reg_save_param函數手動建立關聯

6、參數化要關聯的動態值

7、回放腳本驗證關聯是否成功

使用相同的業務流程與數據錄制二份腳本

先錄制一份腳本并存檔，

依照相同的操作步驟與數據錄制第二份腳本并存盤。注意，所有的步驟和輸入的數據一定都要一樣，這樣才能找出由服務器端產生的動態數據。有時候會遇到真的無法使用相同的輸入數據，那您也要記住您使用的輸入數據，到時才能判斷是您輸入的數據，還是變動的數據。

找出兩份腳本中不同的地方

如上圖，選用文本對比工具將兩份腳本進行對比 （也可以使用LoadRunner自帶的WinDiff進行對比）

逐一檢視二份腳本中差異的部份，每一個差異都可能是需要做關聯的地方。選取差異的腳本，然后復制。

在復制時，有時并不需要取整行腳本，可能只會選取腳本中的一部分。

注意：請忽略lr_thik_time的差異部份，因為lr_thik_time是用來模擬每個步驟之間使用者思考延遲的時間。

確定腳本中差異的地方是否需要做關聯

如上圖，復制其中一份腳本中不同的內容，然后在該腳本對應的Generation Log中找這個值。將鼠標光標點到Generation Log的第一行開頭，按下Ctrl+F，開啟【Find】窗口，貼上剛剛復制的腳本，找出在Generation Log第一次出現的位置。

在Generation Log中找不到要找的數據，這時請先確認您找對了腳本，畢竟現在開啟了二個幾乎一樣的腳本，很容易弄錯。

在Generation Log中找到了要找的數據，這時要確認數據是從服務器端傳送過來的。首先可以先檢查數據的標頭，從標頭的Response Body可以知道數據是從服務器端傳送到client端的。假如此數據第一次出現是在Request Header中，則表示此數據是由client端產生，不需要做關聯，但是有可能需要做參數化（parameterized）。

您要找的標頭格式如下：

******* Response Body For Transaction With Id 13 ******

確定關聯函數的插入位置

在之前的步驟，我們已經在Execution

Log中找到可能需要關聯的動態數據，復制動態值部分進行關聯就可以進行關聯了，但是我們的關聯函數應該插入到腳本的什么位置呢？所以我們要先找出使用web_reg_save_param函數的正確位置，所以我們要再重新執行一遍腳本，而且這次會開啟所有的Log。

在VuGen中點選【Vuser】>【Run-Time

Settings】>【General】>【Log】>勾選【Enable logging】、【Always sends

messages】、【Extended

log】以及【Extended log】下的所有選項，按下【OK】，然后就可以執行腳本了。

如上圖，執行完腳本之后，復制動態值所在行的其他腳本內容（而不是動態值本身）在Repaly? Log中進行查找。找到字符串后，在字符串前面會有Action.c(4):，這個4就是到時候要插入web_reg_save_param函數的位置，也就是要插入到腳本的第4行。

為什么關聯函數要插入到第4行？而不是動態值所在的那一行？

因為web_reg_save_param函數為注冊函數，必須在動態值的前面，相當于先聲明，后作用。注意：并不是在動態值的前面就行了，一定得在該動態值所屬的請求前，如例子中應該在“web_url”前面，而不是第17行的“web_submit_data”之前，這里需要好好理解一下。

使用Web_reg_save_param函數建立關聯

將光標定位在腳本的第四行前(在日志中我們查找到的那一行雙擊也可自動跳轉到需要關聯的位置)，右擊>Insert>New step...，在彈出的窗口中展開Services結點，選擇“Web_reg_save_param”，然后點擊ok。

如上圖，在彈出的窗口中填寫的“UserSession”是自己隨意取的參數名，取名時盡量見名知意，左右邊界值為所要關聯的動態值在Genertion log中的左右邊界值，其他參數項均為可選項。

關聯函數中的各個參數意義

ParamName:存放動態數據的參數名稱

list of Attributes:其它屬性，包含 Notfound, LB, RB, RelFrameID, Search, Instance, SaveOffset,? 以及 SaveLen。屬性值不分大小寫，例如 Search=all。

Notfound:指定當找不到要找的動態數據時該怎么處置。

Notfound=error:當找不到動態數據時，發出一個錯誤訊息。假如沒設定此屬性，此為LoadRunner的默認值。

Notfound=warning:當找不到動態數據時，不發出錯誤訊息，只發出警告，腳本也會繼續執行下去不會中斷。在對角本除錯時，可以使用此屬性值。

LB:動態數據的左邊界字符串。此屬性質是必須要有的，而且區分大小寫。

RB:動態數據的右邊界字符串。此屬性質是必須要有的，而且區分大小寫。

RelFrameID:相對于URL而言，欲搜尋的網頁的Frame。此屬性質可以是All或是數字，而且可有可無。

Search:搜尋的范圍?？梢允荋eaders(只搜尋headers)、Body(只搜尋body部分，不搜尋header)、Noresource(只搜尋body部分，不搜尋header與resource)或是All(搜尋全部范圍，此為默認值)。此屬性質可有可無。

Instance:指明從第幾次出現的值開始才是要擷取的數據。此屬性質可有可無，默認值是1。假如值為All，則所有找到符合的數據會儲存在數組中。

SaveOffset:當找到符合的動態數據時，從第幾個字符開始才開始儲存到參數中。此屬性不可為負數，其默認值為0。

SaveLen:從offset開始算起，到指定的長度內的字符串，才儲存到參數中。此參數可有可無，默認值是-1，表示儲存到結尾整個字符串。

關聯函數中的這些參數存在的目的主要是幫助用戶去確定需要關聯內容的唯一性，所以使用時應靈活運用，只有ParamName、LB、RB這三個參數是必須的，其他的都不是，但一般會再用上Notfound=error，這樣如果沒關聯到我們容易發現錯誤。

參數化要關聯的動態值

做完以上工作后點擊“ok”看到腳本中已插入“Web_reg_save_param”函數，至此關聯工作還沒有完成，我們剛才設置了參數”usersession“，現在需要把我們要關聯的動態值參數化，且參數名要為”usersession“，這樣關聯函數才能識別出來要關聯哪些內容。（參數名是自己取的，它就是用來動態值的，就是一個變量，可以隨便去取，但是最好見名知意）

在腳本中選中關聯的動態值，右鍵>Replace with a Parameter>將參數名改為usersession>OK.

參數化后被參數的動態值部分變為usersession，且以粉紅色顯示。

回放腳本驗證關聯是否成功

最后運行一下腳本，并查看回放日志，驗證關聯是否成功

注意：運行腳本時也要開啟全部日志，這樣我們可以在日志中看到關聯函數的事件信息（藍色字體），以確保關聯成功；如果腳本中有以”cookie“開頭的報錯信息，不用去處理，對測試無影響。

關于易混淆的兩個地方這里再廢話幾句：

1、第一次是在Generation log日志中查找動態值，看動態值在日志中的標頭是“response...”還是“request...”，來確定該動態值是否需要關聯

2、第二次是在Repaly log日志中查找動態值所在行（注意：查找時復制的查找內容并不是動態值，而是動態值所在行的其他腳本內容，因為Repaly log日志是回放腳本時產生的，腳本經過回放后，動態值已改變，再復制動態值查找極有可能查找不到），目的是看該行前面的Action（X），來確定關聯函數應該插入的位置，X代表行，X為幾，對應的關聯就應該插入到此行前面。切記：第一次查找是確定動態值是否需要關聯，第二次查找日志是確定關聯函數應插入在什么位置

原網址：http://blog.csdn.net/u011446864/article/details/38395975