LoadRunner使用之变量关联
性能测试LR小结之参数关联（LoadRunner11.0）
关联对于LR是经常需要用到的，本章使用简单登录来介绍关联功能。
1. Q：何为关联？
所谓的关联就是把脚本中某些写死的代码（hard-coded）数据，转变成撷取自服务器所送的、动态的、每次都不一样的数据。通俗讲就是变量替换，把每次访问页面中的一些动态参数，使用固定的变量进行替换。如：最常见的sessionid，不同用户访问系统会产生不同的sessionid，
2. Q：为什么要关联？
如在一个登录脚本中用户登录每次都会生成一个sessionid。而该sessionid再下一次脚本回放时，就不能使用了，导致脚本执行失败。这时候我们就需要关联，通过关联把该sessionid在脚本中也设置成动态，保证脚本能够正确运行。
3. Q:如何关联？
下面内容将详细介绍如何进行关联，自动关联部分只做简单介绍，不用实例讲解，因为实际工作中LR自带关联，远没有手动关联好用。
3.1. 自动关联
LR自带一些关联规则，可以在录制脚本的时候启用这些关联规则， VuGen内建自动关联引擎（Auto-correlation Engine），提供Rules Correlation和Correlation Studio两种机制，可以自动找出需要关联的值，并且自动使用关联函数建立关联。
使用“Correlation Studio”的步骤如下：
（1）录制脚本并执行。
（2）执行完毕后，VuGen会跳出“Scan Action for Correlation”窗口，询问用户是否要扫描脚本并建立关联，单击“Yes”按钮，扫描脚本。
（3）扫描完后，可以在脚本下方的“Correlation Results”中看到扫描的结果。
（4）检查一下扫描的结果，选择要做关联的数据，然后单击“Correlate”按钮，逐次关联，或是单击“Correlate All”让VuGen一次就对所有的数据建立关联。
由于Correlation Studio会找出所有有变动的数据，但是并不是所有的数据
都需要做关联，所以不建议用户直接用“Correlate All”。
重复步骤（1）~（4），直到所有需要做关联的数据都找出来为止。
有时关联的地方有多处，前面的关联如果没有执行通过，执行将停止验证脚本的正确性，后面需要做关联的部分无法被扫描出来。
|
注意这里不推荐使用自动关联，有几个理由： Ø 有时候自动规则并不能扫描出需要关联的内容 Ø 扫描出来的可以关联内容，并不是所有内容都需要关联 Ø 有些自动关联出来的内容不是我们需要的 |
与其浪费大量时间去调试关联规则，不如直接使用手动关联，所以如果你专心于做性能测试，那么就直接放弃使用自动关联吧，有益无害，也显得我们的高端。
3.2. 手动关联
虽然手动关联比自动关联方法麻烦一些，操作复杂，对于没有代码编程经验的测试初学者来说，甚至有时连需要关联的位置都无法找到，但是经过多次实践后，会发现很多关联的方法与技巧。毕竟手动关联出来的脚本拥有更大的灵活性，可以随意改动来满足用户不同的需求。
手动关联其实只需以下三步即可：
Ø 找出需要关联的数据。
Ø 使用web_reg_save_param函数手动建立关联。
Ø 将脚本中有用到关联的数据，以参数取代。
3.2.1. 如何找出关联数据
笨拙的办法就是录制两次脚本，然后使用在第二份脚本中，单击VuGen的“Tools”>“Compare with Vuser…”，并选择第一份脚本。接着WinDiff会开启，同时显示两份脚本，并显示有差异的地方。WinDiff会以一整行黄色标示有差异的脚本，并且以红色的字体显示真正差异的文字（假如没看到红色字体，请单击 “Options”>“View”>“Show Inline Differences”）。
逐一检视两份脚本中差异的部分，每一处差异都可能是需要做关联的地方。选取差异的脚本，然后复制。在复制时，有时并不需要取整行脚本，可能只会选取脚本中的一部分。
如果在Recording
Log中找不到要找的数据，这时请先确认是否找对了脚本，毕竟现在开启了两个几乎一样的脚本，很容易弄错。
如果在Recording
Log中找到了要找的数据，这时要确认数据是否为从服务器端传送过来的。首先可以检查数据的标头，从标头的Receiving response可以知道数据是否是从服务器端传送到客户端的。假如此数据第一次出现是在Sending request中，则表示此数据是由客户端产生，不需要做关联，但是有可能需要做参数化（Parameterized）。
|
注意： 请忽略lr_thik_time的差异部分，因为lr_thik_time是用来模拟每个步骤之间使用者思考延迟的时间的。 |
在实际测试工作中很少用这种办法，如果对系统业务足够的熟悉，完全凭自己经验，对脚本内容中的动态参数进行查找，且可以选择性查找，进行关联。
3.2.2. 使用web_reg_save_param函数手动建立关联
（1）web_reg_save_param函数
对于关联来说，web_reg_save_param是最重要的一个函数，其功能是在下载的网页内容中，通过设定的边界字符串，找出特定的数据并将其存储在一个参数中，以供后续脚本使用。
web_reg_save_param是一个服务端函数（Service function，主要用来完成一些特殊的工作，如关联、设定proxy、提供认证信息等），当其作用时，不会对网页的内容做任何的修改。
web_reg_save_param同时也是一个注册类型的函数（Registration Type Function，只要函数名称中包含_reg_的字眼，表示其为注册类型的函数）。注册类型的函数意味着其真正作用的时机是在下一个动作函数（Action Function）完成时。举例来说，当某个web_url执行时所接收到的网页内容中包含了要做关联的动态数据，则必须将 web_reg_save_param放在此web_url之前，web_reg_save_param会在web_url执行完毕后，也就是网页内容都下载完后，再执行web_reg_save_param，寻找要做关联的动态数据并建立参数。
谨记，当使用注册类型的函数时，要注意其放置的位置必须在要作用的动作函数之前。
（2）web_reg_save_param的语法
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”。
下面将详细说明每个属性值的意义。
Notfound：指定当找不到要找的动态数据时该怎么处理。
当指定Notfound=error时，表示着找不到动态数据时，就发出一个错误消息。此为该属性的默认值。
当指定Notfound=warning时，表示当找不到动态数据时，不发出错误消息，只发出警告，脚本也会继续执行下去不会中断。在对脚本出错时，可以如此设置。
LB：动态数据的左边界字符串。此属性是必须要有的，而且区分大小写。
RB：动态数据的右边界字符串。此属性是必须要有的，而且区分大小写。
RelFrameID：相对于URL而言，欲搜寻的网页的Frame。此属性可以是All或是数字，而且可有可无。
Search：搜寻的范围，其值可以是Headers（只搜寻headers）、Body（只搜寻body部分，不搜寻header）、 Noresource（只搜寻body部分，不搜寻header与resource）或是All（搜寻全部范围，此为默认值），此属性可有可无。
ORD：指明从第几次出现的左边界开始才是要撷取的数据，默认值是1。假如该属性值为All，则所有找到符合的数据会存储在数组中。此属性可有可无。
SaveOffset：当找到符合的动态数据时，从第几个字符开始才开始存储到参数中。此属性值不可为负数，其默认值为0。
Convert：转换数据格式。当指定该属性值为HTML_TO_URL时，意味着将
HTML-encoded数据转成URL-encoded数据格式。如果是HTML_TO_TEXT，表示将HTML-encoded数据转成纯文字数据格式。
SaveLen：当找到匹配项后，偏移量之后的几个字元存储到参数中。此参数可有可无，默认值是-1，表示一直到结尾的整个字符串都存入参数中。
（3）确定使用web_reg_save_param函数的位置
开启所有的Log，再重新执行一遍脚本。
在VuGen中单击“Vuser”>“Run-Time Settings”。单击“General”>“Log”，勾选“Enable logging”、“Always sends messages”、“Extended log”以及“Extended log”下的所有选项。然后，单击“OK”按钮就可以执行脚本了。
执行完脚本之后，在Execution Log中搜寻需要关联的参数。找到字符串后，在字符串前面会有A.tion1.c(7)，这个7就是到时候要插入web_reg_save_param函数的位置，也就是说要插入到脚本的第7行。
例：以下为登录脚本内容：
web_submit_data("login.pl","Action=http://127.0.0.1:1080/WebTours/login.pl","Method=POST","RecContentType=text/html","Referer=http://127.0.0.1:1080/WebTours/nav.pl?in=home","Snapshot=t9.inf","Mode=HTTP",ITEMDATA,"Name=userSession", "Value= A939058C4F0948A3035A87F0A094EE0A ", ENDITEM,"Name=username", "Value=tsbc520", ENDITEM,"Name=password", "Value=123456", ENDITEM,"Name=JSFormSubmit", "Value=off", ENDITEM,"Name=login.x", "Value=0", ENDITEM,"Name=login.y", "Value=0", ENDITEM,LAST);
根据经验从上面脚本中可以看出，userSession，username，password 三个参数是变量。而userSession是服务器自动生成的，因此需要我们对userSession进行关联。
定义关联变量：
web_reg_save_param("ts_Session","LB=userSession value=","RB=>","Ord=1","Search=Body",LAST);
将关联函数插入到web_submit_data函数上方的web_url（访问页面的链接的）前面的。
3.2.3. 将脚本中有用到关联的数据，以参数取代
最后将登录函数中userSession变量进行关联替换。如：
web_submit_data("login.pl","Action=http://127.0.0.1:1080/WebTours/login.pl","Method=POST","RecContentType=text/html","Referer=http://127.0.0.1:1080/WebTours/nav.pl?in=home","Snapshot=t9.inf","Mode=HTTP",ITEMDATA,"Name=userSession", "Value= {ts_Session} ", ENDITEM,"Name=username", "Value=tsbc520", ENDITEM,"Name=password", "Value=123456", ENDITEM,"Name=JSFormSubmit", "Value=off", ENDITEM,"Name=login.x", "Value=0", ENDITEM,"Name=login.y", "Value=0", ENDITEM,LAST);
将参数的替换为：{ts_Session} 这样每次运行脚本，即使更换不同的用户进行登录，userSession也会动态生成。
可以使用输出函数将生成的动态值打印出来进行确认。
lr_log_message("userSession is: %s",lr_eval_string("{ts_Session} "));
结果会在Replay Log 中显示。
至此，简单的参数关联就结束了，在实际使用中会有更多的需要我们进行关联的地方，问题面前不要吓到，一个一个分析一个一个解决，积累经验小白最终会变成老鸟。
上面内容Web_reg_save_param 函数位置问题，没有讲的很详细，个人感觉这里，大家在使用过程中可以去尝试，但必须放在web_submit_data的上面。
