主流软件测试工具介绍[3]
本文在分析市场上已有的商用的性能测试工具实现原理和体系架构的基础上，提出了利用现有的开源代码构建开源的性能测试工具思路。 【关键词】 性能测试、软件测试、软件测试工具、软件测试技术、Vugen 、 Conductor 、 Player 、 Analysis
Vugen 的体系结构分为三部分：·第一部分为底层 proxy 录制器 , 负责捕获客户端和服务器之间通讯的数据包，这样的软件在开放源码的世界里面随处可见，而且非常成熟。 我们只要移植过来就可以使用。
·第二部分是界面部分，提供脚本编辑、调试和运行功能，这部分可以用Visual C++/MFC实现Windows平台版本和Java/AWT实现Unix 版本。
·第三部分是以插件的形式提供的分析各种网络协议的解析器。开发这类插件的强有力的开发工具为 lex 和 yacc 。
·Proxy 二次捕获的问题
Vugen的Proxy方式需要解决的一个问题是二次捕获数据包的问题。早期的网络服务器程序对外提供一个固定端口，客户端仅仅和这个端口通讯就可以了。这对于 proxy 录制非常容易。但是现在很多服务器程序为了提高对客户端并发量的支持，采用两个端口通讯的方式。如下图所示：
第一步：客户端将请求发往 Proxy 录制器。
第二步： Proxy 录制器将请求发往真正的服务器的指定端口，即图中的 3200 端口。
第三步：服务器机器的 3200 端口返回数据包给 Proxy 录制器。该数据包中包含了下一次通讯的目的地址，形式为 IP:Port。很显然，这里的 IP 数据为真正服务器的 IP 地址。
第四步， Proxy 录制器把请求返回给客户端。
第五步，客户端根据提供的 IP:Port 信息直接把请求发往真正的服务器，不再经过 Proxy 录制器。
第六步：以后的通讯只是客户端和服务器之间的通讯了， Proxy 录制器是无法捕获这些通讯包了。
因此一般的Proxy录制器只能捕获头两个收发的数据包。这个问题更一般的情形的例子是HTTP的redirection功能。第二次通讯可能发往另外一台机器了。 Proxy 录制器必需解决这个问题。
关联的问题客户端和服务器之间的通讯，有一部分是数据是动态的，每次通讯都不一样。 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] 就可以圆满解决这个问题。
这种问题在任何系统都是非常常见对外问题。其通用的模式是： “服务器返回给客户端一些动态变化的值，客户端使用这些值去访问服务器的时候，不能把这些值写死在脚本里面，而应该存放在一个变量里面。” 这就是关联的概念。
