测试 Web 2.0 程序所带来的挑战：使用 GUI 恢复性能评测来补充 Web 2.0 性能测试

核心提示： 每一个从 Rational Functional Tester 中运行测试脚本的个人，都会创建它自己的 CSV 文件，测试 Web 2.0 程序所带来的挑战：使用 GUI 恢复性能评测来补充 Web 2.0 性能测试(5)，为了比较行为，需要对数据进行合并，将已存在的工具合并起来，以继续满足测试

每一个从 Rational Functional Tester 中运行测试脚本的个人，都会创建它自己的 CSV 文件。为了比较行为，需要对数据进行合并。但是，为了确定所有的运行都用相同的脚本完成，计时器描述（基于 TransactionTimer 的名字）也需要是相同的。

采用以下的范例场景 ：

运行脚本作为单个用户，服务器上没有负载

向服务器添加 10 个虚拟用户的负载，重新运行脚本

向服务器添加 50 个虚拟用户的负载，重新运行脚本

向服务器添加 250 个虚拟用户的负载，重新运行脚本

向服务器添加 500 个虚拟用户的负载，重新运行脚本

结果，会产生五个扩展卡。打开单个的用户基线扩展卡，并删除掉起始/终止列。重新设定消失时间列，以指定基线时间。使用合适的标签来为其余的 4 个扩展卡创建列，以运行测试目标。从每一个扩展卡中复制消耗的时间数据到相应的列中。将文件使用新名字作为一个 Microsoft® Excel® 扩展卡保存。

现在您就可以使用五列的数据，以提供显示 GUI 行为趋势的图表，这个提供的图表基于位于服务器上的负载/压力情况。

现在我们推荐您重复上述的测试步骤几次，以为分析提供一些测试用的数据。

在我们前面的例子中，如果新的项目对话框需要 10 ms 来关闭，而不用对服务器造成什么负荷，那么我们需要记得实际上并不是 10ms。这个时间包括了一些 Rational Functional Tester 负荷，以及一些确认负荷。我们说，行列上的值是 10，12，15，50 以及 100。您可以理直气壮地说，对于 50 多个用户，在用户的响应时间上并不会发生什么大的变动。但是在 250 与 500 用户时，时间就会翻倍。还有一个要注意的是，在达到 250 个用户以后，需要的时间会有一个较大幅度的跃升。

另外，标准的性能分析原则用以理解这些结果。

总结

测试工具完整地达到 Web 2.0 的标准，以及为测试新的 Web 2.0 结构提供完整的方案，都需要一些时间。同时，我们可以使用像在上面概括过的一些创新性方案，将已存在的工具合并起来，以继续满足测试的目标，帮助我们的客户得到使用 Web 2.0 程序的积极经验。