对“关联”的理解

根据自己使用loadrunner有些经历，总结了下对“关联”的理解，不过不知道说的对不对，有待阅读者指正。

关联是将脚本中提交的内容（包括动态参数值的）从其他请求的服务器返回值中获得并在脚本回放时使用的一种策略方法。

使用关联的第一步：理解关联
个人理解关联其实就是参数化的一种方式。只不过它的参数值获取是要通过服务器端返回的信息动态获得的。

使用关联的第二步：哪些是需要关联的呢？
服务器应用动态生成并反馈给客户端，客户端又使用这个动态值重新向服务器发送请求，一般这种情况都需要进行关联。
简单举例：
        如每次登录系统服务器端都自动生成sessionid，这个id就是每次不同且是服务器动态生成，在后续的操作中通过sessionid来判断用户的有效性的。sessionid对于模拟不同的用户就需要进行关联。
        如一个邮件系统的应用登录后查看收件箱。这个过程服务器根据登录用户的不同生成一个对每个用户都唯一的标识串，在进行收件箱查看时用户使用这个标识发送给服务器端，这个标识就是需要关联获得的。如果读取收件箱中的邮件，则每运行一次脚本的未读邮件是不同的，需要动态获得则需要关联。

使用关联的第三步：关联与参数化的区别：
关联是服务器动态生成的，每次用户不同或操作不同该值是不可预见的，需要从服务器的动态返回给客户端的值进行获取。
参数化是由客户端选择传递给服务器端的，是预先已知的。如想模拟不同的用户登录系统，用户名就是提前已知要提交给服务器端的，需要进行参数化。

使用关联的第四步：如何进行关联
1、确定关联的对象。
一种方法是目测：查看脚本中的提交语句中的参数值为数字串或字符串的，而且该值不是参数化的部分，则极有可能需要进行关联的。这时运行脚本如报错，查看出错日志，日志中表现出来的语句进行分析是否需要进行关联。
一种方法是两个脚本对比：使用Vugen工具录制两个同样操作同一用户的脚本（脚本进行的操作应该是完全一致的），打开一个脚本使用loadrunner的vugen的tools——Compare with，选择另一个脚本，则打开了WDiff工具，寻找两个脚本中不一样的提交给服务器的请求的语句。（lr_think_time是排除在外的）通过语句分析是否需要关联。
一种方法是运行脚本如果报错，则请开发人员在程序里输出日志，查看日志中的报错定位是否是什么地方需要进行关联。

2、进行关联
确定了需要关联的值，要找出这个值生成的地方。通常为该管理值之前的语句中的提交语句的返回结果。分析在进行这个需要用到关联值的语句之前的操作是什么（假如是B操作），到Vugen的view tree界面，查看B操作的server response值。可以在其中搜索该关联对象的值，找到第一次出现的为止。
使用web_reg_save_param,设置LB，RB，ORD，SaveLen，SaveOffset，Search
LB，RB左右边界，SaveLen存储的长度，SaveOffset从左右边界内的第几个字符开始计算
ORD 表示第几个匹配的值，如果是想获得所有的匹配值则列为ALL，这时会存储到一个array中
Search 表示在什么部分查找 ，包括 headers,body,Noresource,ALL

如web_reg_save_param("TEST","LB=ABC","RB=EFG","SaveOffset=2","SaveLen=1","ORD=ALL","Search=body",LAST);
如果结果是个数组的话，可以通过：
{TEST_count}查看个数
{TEST_0}第几个的值，0起始。

3、调试结果
可以在脚本中打印参数值，要使用lr_eval_string函数来获得字符串的值。
lr_out_message("The parameter is %s",lr_eval_string("{TEST_0}"));
在场景中，选择run_timesetting中log，将log开放到parameter，这样可以每个输出所获得的参数是什么是否是动态的值以确定关联是否正确。