性能测试工具的基本功能和可能出现的技术要点分析(4)

　　• 第二部分是界面部分，提供脚本编辑、调试和运行功能，这部分可以用 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 的时候把其放在一个变量 里面，在后面脚本访问服务器的语句里面，把所有的 ”SessionID@12345” 替换为变量 就可以圆满解决这个问题。

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

　　关联的工作往往占据开发脚本的大部分时间，因为我们必需针对每一个具体的系统进行细致的分析，确定其需要关联的动态信息。为了快速开发脚本， Vugen 必需提供帮助我们关联的手段，最好做到自动关联。自动关联的方法有三种：

原文转自：http://www.uml.org.cn/Test/200503183.htm