為什么要關聯動態數據呢？舉個例子，在對我們平臺的工作流性能測試時，在待辦任務里面選擇一條記錄執行發送操作，LoadRunner VuGen會詳細記錄下來流程發送操作的細節，但在回放腳本的時候會有問題。待辦任務里面找不到那條記錄了，已經發送到下一個環節了。另一個更易理解的例子，在初始化查詢頁面，選擇一條記錄進行刪除，錄下腳本進行回放的時候會出錯，記錄已經刪除了，回放腳本的時候服務器返回的記錄不再包含那條記錄，再向服務器發送刪除那條記錄的請求，就報錯了。關聯動態數據需要我們在腳本中設置一個變量，保存從服務器返回的起標識作用的數據，發送請求的時候使用該變量代替動態數據，這樣再回放、反復測試就不會報錯了。需要關聯的標識性數據一般是各種主鍵，工作流的發送的例子很復雜，需要對流程編碼、環節編碼、參與者編碼、表單編碼等進行關聯，下面使用復雜的工作流發送的例子進行演示。
手動關聯動態數據的復雜做法是，回放腳本，在Execution Log和Recoding Log打出的信息中找需要關聯的動態數據及動態數據的左右邊界。甚是麻煩，我沒怎么看明白。其實每次回放腳本，Recoding Log打印的信息都是一樣的，也和錄制腳本的時候生成的\data\RecordingLog.txt文件的內容一樣。下面直接使用\data\RecordingLog.txt文件，關聯動態數據的時候不再需要回放腳本，減少了關聯動態數據的工作時間。
執行同樣的操作，先后錄制兩次腳本保存，比較一下生成的Action.c，注意動態數據不能放在vuser_init.c文件中。自帶的WinDiff工具不好使用，推薦使用Beyond Compare工具。不是所有的差異處都要關聯的，WEB_URL()等方法的參數列表的先后順序是沒關系的，思考時間當然也可以不同。下圖中右邊的腳本已經關聯過動態數據了，如果是剛錄制的兩份腳本，右邊的id、processId等也是32位的主鍵，左右兩份腳本的差異一目了然，記下這些動態數據的值。
以左圖id的值：40287ae91c4b7dbb011c4b85e17204da為例，在腳本\data\RecordingLog.txt中查找該值。找其第一次出現的地方，一般在該值的上方會有這樣的字樣：*** [tid=2258 Action 145] Receiving response from host 192.168.250.105:7001 ( 10/9/2008 17:40:37 )。如下圖，記下40287ae91c4b7dbb011c4b85e17204da的左邊界：<input type=\"hidden\" name=\"id\" value=\"和右邊界：\">。注意看一下這樣的左右邊界是否唯一。
在剛才的腳本的文件\data\RecordingLog.txt中小心向上翻動，可以找到這樣的字樣： *** [tid=2258 Action 145] Recording Function ( 10/9/2008 17:40:37 )
該字樣的下面緊接著是方法web_submit_data("jspformtaskdeal.cmd",……)，這個方法在Action.c中是同樣存在的，通過這個方法我們可以知道在Action.c的什么地方插入web_reg_save_param()方法�，F在我們需要做的就是在腳本Action.c中，方法web_submit_data("jspformtaskdeal.cmd",……)的前面，緊挨著這個方法寫上web_reg_save_param()方法用于保存動態數據，其中LB、RB分別是剛才記錄下的左右邊界值，primary是我們起的變量名字。完整的方法如下：
web_reg_save_param("primkey",
"LB=<input type=\"hidden\" name=\"id\" value=\"",
"RB=\">",
LAST);
修改后的Action.c的腳本，見下圖：
文章來源于領測軟件測試網 http://www.kjueaiud.com/
