Session是Web浏览器的会话机制 正常 *** 作后面隐藏的具体过程如下:
张三请求登录(向服务器发Request),Web登录服务器给他回馈一个SessionID_zhangsan,
同时在服务器中记录(注意注意,这就是案底,日后对账要以这个作为依据);
登录之后,张三肯定还要继续请求其他服务(比如请求页面啊等等……),
张三请求服务的时候,得先给服务器喊暗号,服务器根据暗号来区分不同的Client,
张三就喊SessionID_zhangsan,李四就喊SessionID_lisi,王二麻子就喊SessionID_wangermazi……明白吧,
只有client提交的暗号跟服务器自己记录的案底对上了,服务器才能提供相应的服务,
如果对不上,不但不提供服务,还要报错;
以上说的是正常的情况,但是如果这个过程里面掺上了LR,那就不一样了,事情会变成这样:
录制的时候,假如还是张三请求登录,Web登录服务器给他回馈一个SessionID_zhangsan2,
LR会从对话中捕捉这个SessionID_zhangsan2,写死到LR脚本里面(注意注意,这里是第二个关键),
服务器自己也会记录案底,然后一切都好,该请求的请求,该服务的服务,此后无话;
(如果你看过一些资料,你会知道LR的工作原理就是捕捉Client与Server之间的对话)
等到了回放的时候,可就不是张三了,而是张三狗了,这就是LR的运行所引入的不同,
那么张三狗请求登录,Web登录服务器给他回馈一个SessionID_zhangsangou,但是并不捕捉记录到脚本,
(注意注意,这里是第三个关键),
因为这是回放,不是录制,所以不会更新脚本,刚才捕捉的SessionID_zhangsan2不被覆盖,
张三狗请求其他服务的时候,本来应该喊暗号SessionID_zhangsangou,
但是注意,现在是LR代替张三狗登录,并不是真的张三狗,LR只能喊出SessionID_zhangsan2这个暗号,
因为SessionID_zhangsan2是写死的,并且没有被覆盖过,还记得吧,
回放的时候一切忠实于脚本,现在是SessionID_zhangsan2要和服务器记录的底子去对账,
那服务器记录的底子是什么呢?是SessionID_zhangsangou,这是录制的时候记进去的!
那肯定是对不上的呀,这脚本还怎么运行呢?性能测试还怎么继续呢?
关联,就是用来解决这个问题的:
当录制的时候,服务器不是反馈SessionID_zhangsan2吗?因为设置了关联,所以无论是录制过程还是回放过程,只要是服务器返回的,都记到一个变量里面,这样一来,服务器反馈什么,脚本就记录什么,而且是动态的,
不是写死的,这样就不会出现对不上的情况了。
当然并不是所有的服务器都有这么智能,如果服务器没这个对证机制,你就不需要做关联了;
关联可以手动 也可以自动 要在正确的位置插入关联函数 然后写对左右边界
所谓的关联(correlation)就是把脚本中某些写死的(hard-coded)数据,转变成是撷取自服务器所送的、动态的、每次都不一样的数据。举一个常见的例子,有些比较聪明的服务器,在每个浏览器第一次跟它要数据时,都会在数据中夹带一个唯一的辨识码,接下来就会利用这个辨识码来辨识跟它要数据的是不是同一个浏览器。一般称这个辨识码为Session ID。对于每个新的交易,服务器都会产生新的Session ID给浏览器。这也就是为什么执行脚本会失败的原因,因为VuGen还是用旧的Session ID向服务器要数据,服务器会发现这个Session ID是失效的或是它根本不认识这个Session ID,当然就不会传送正确的网页数据给VuGen了。
我的理解就是,在录制脚本时,浏览器跟服务器的对话,服务器都会对这个浏览器的 *** 作发送些动态的辨别码,但后来回放脚本的时候,浏览器还用以前服务器发送的旧辨别码跟服务器对话,服务器就会认出那是以前的“过期”的辨别码,就会拒绝此浏览器对服务器所做的 *** 作,当然回放也就失败了。为了避免回放失败,在浏览器跟服务器对话之前的脚本里加上关联语句,再回放脚本时,浏览器就会向服务器发送一个动态的辨别码,服务器看到这个动态的辨别码是以前没用过的,就会同意此浏览器对服务器的 *** 作;因为关联语句发出的是动态辨别码,所以在回放中的每次迭代和每个vuser的辨别码都不同,可以顺利回放成功。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)