关联是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:搜寻的范围。可以是Headers(只搜寻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为几，对应的关联就应该插入到此行前面。切记：第一次查找是确定动态值是否需要关联，第二次查找日志是确定关联函数应插入在什么位置
————————————————
版权声明：本文为CSDN博主「debug」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u011446864/article/details/38395975