关联原理说明

 关联的问题

客户端和服务器之间的通讯，有一部分是数据是动态的，每次通讯都不一样。 Proxy 录制器在录制的时候是无法区分哪些是静态的信息，哪些是动态的信息，所有的信息都以 hard-coded 的方式记录下来。但是在回放的时候，如果有些信息不改变，那么脚本是不能执行成功的。考虑如下情形：

 

如上图所示，用户 jojo 以 jojo/bean 的账号 / 口令登录某一 web 服务器，查询某产品的信息，由 Vugen 录制交易的全部通讯包。 web 服务器返回给 jojo 一个动态的会话 ID: SessionID@12345 ，作为这次登录的会话标识。由于 Vugen 无法知道哪些信息是动态的，它会照单全收的方式，把所有的数据就记录下来。接着 jojo 根据 Web 服务器告诉他的 SessionID 去查询产品列表，交易可以正常执行下去。

我们会观察到，当 Vugen 根据捕获的通讯包生成 http 脚本的时候， SessionID 是 Hard-coded 的，即 “ 写死 ” 在程序里面的。当我们不加修改的回放该脚本的时候，会出现什么问题呢？如下图所示： 

按照录制时候的脚本， jojo 以 jojo/bean 登录后， Web 服务器返回给 jojo 一个动态会话 ID: SessionID@23456 ，这个值已经不是录制时候产生的 SessionID@12345 了，而是新的值： SessionID@23456 。那么脚本根据记录的 SessionID 的值，仍然会使用 SessionID@12345 去执行下面的查询交易。由于会话 ID 是有时效性的，用户退出系统后，其 SessionID 会失效，那么，服务器会给出一个 “SessionID 失效 ” 的错误，从而导致脚本无法正常执行下去。

对于上面的问题的通用解决方法如下图所示：

 

在第一次从服务器得到 SessionID 的时候把其放在一个变量 <session_id> 里面，在后面脚本访问服务器的语句里面，把所有的 ”SessionID@12345” 替换为变量 <session_id> 就可以圆满解决这个问题。

这种问题在任何系统都是非常常见对外问题。其通用的模式是： “服务器返回给客户端一些动态变化的值，客户端使用这些值去访问服务器的时候，不能把这些值写死在脚本里面，而应该存放在一个变量里面。” 这就是关联的概念。

关联的工作往往占据开发脚本的大部分时间，因为我们必需针对每一个具体的系统进行细致的分析，确定其需要关联的动态信息。