LoadRunner脚本对像关联启蒙

假设现在有一间卖面包的商铺，店主是S，顾客是C。顾客C每天都到面包铺里面买面包，面包铺有许多面包，经常卖不出去，有些是前天出炉的、有些是昨天出炉的、还有些是今天出炉的。顾客C为了保证自己买到的面包是新鲜的，一般情况下，他会告诉店主S他需要的是今天出炉的面包，这句话是这样的：“我要买*年*月*日出炉的面包”。店主S根据客户要求，把顾客C指定日期的面包给了顾客C，顾客C通过检查发现，这确实是他所要求的面包，则收下，若不是，则抛弃。

上面的面包铺就是服务器，店主S是应用服务，顾客C则是客户端。
客户端为了保证自己的请求能得到正确的响应，客户端发出了这样的请求“给我*年*月*日某数据”服务器根据客户端发出的请求，给与了响应，返回给客户端。
这就相当于客户端与服务器之间的通讯请求夹带了一个Session ID，客户端通过在请求中夹带Session ID，要求服务器响应的同时也包括这个Session ID，客户端对响应进行检查，确定Session ID为请求中所夹带的，这就算是一个正确的响应，如果客户端对服务器响应进行检查的时候发现，服务器响应所夹带的Session ID和它所发出的是不一样的，则这是一个错误的响应。

突然有一天，顾客C病了，一病不起。顾客C只好每天派他的狗去买面包，可是狗不会讲人话，顾客C就在狗的脖子上面挂了一个牌，写着“我要买今天出炉的面包。”狗去了面包铺，店主S看到这是顾客C家的狗，还看到了狗脖子上面的牌，便把面包给了狗，狗回去，把面包交给顾客C。
在这一步，顾客C做的就是对象关联操作。顾客C为了保证自己的请求能得到正确的响应，也为了方便，不必每天重写一个牌，顾客C对牌上面的时间对像进行了关联处理。

这就相当于客户端与服务器之间的通讯请求夹带的Session ID，被关联了。

看看这两句话区别：
“我要买*年*月*日出炉的面包”   这是顾客C每天亲自去买面包的时候说的。
“我要买今天出炉的面包”        这是顾客C家的狗的脖子上面的牌子写的，也就是关联后的语句。

在店主S眼中，这两句话字面上稍微有点区别，但是意思还是一样的，那就是：我要的是你看到我这个请求这天出炉的面包。
顾客C的关联方法是这样的，首先明确需要关联的对象——日期，找到左边界——我要买，右边界——出炉的面包。
在VuGen里面的语句是（仅为理解方便而假设，实质是错误的）
web_reg_save_param（“日期”，“LB=我要买”，“RB=出炉的面包”，LAST)；
这条语句的放置位置是：顾客C决定派狗出发之后，到达面包铺之前。
也就是：请求发出以后，数据获取之前。

关联问题已经说了个大概，在面对脚本对像需要关联的时候，大致为以下三步：
1. 确定关联对象。这些关联的对象有很多，比如表单提交中的日期、列表当中复选框的ID、记录的ID、操作人的权限ID、身份信息等等；
2. 服务器返回信息。服务器返回的信息在哪里，什么时候返回的，左右边界是什么，单靠左右边界是否足以确定唯一的关联对象等等；
3. 关联语句的放置位置。关联语句的放置位置一般是：脚本请求发出以后，接收服务器响应之前。

LoadRunner VuGen具备了强大的脚本自动关联功能，实际脚本关联中可以自动扫描关联对象，完成所有关联操作。但是很多时候自动关联无法发现所有需要关联的对象，或者找错了左右边界，这个时候就需要人工的去对脚本对像进行关联了。