下面是一个调用事务定时器的范例伪代码，以显示正确的用法：

ShellTestObject topShell =
(ShellTestObject)getRootTestObject().find(atDescendant("class"，
"org.eclipse.swt.widgets.Shell"， ".captionText"， "My application"))[0];
GuiTestObject projectDlg =
(GuiTestObject)topShell.find(atDescendant("class"，
"org.eclipse.swt.widgets.Shell"， ".captionText"， "New Project"))[0];
GuiTestObject finishButton =
(GuiTestObject)projectDlg.find(atDescendant("class"，
"org.eclipse.swt.widgets.Button"， ".text"， "Finisht"))[0];
TransactionTimer timeCreate = new TransactionTimer
("Creating project: " + " project name:");
timeCreate.startTimer();
finishButton.click();
vpDynamic("Check dialog"， projectDlg).performTest(false);
timeCreate.stopTimer(); 

　　值得注意的一件重要事情是，搜索与其他的对象初始化操作是在事务计时器的外部执行的。只有GUI已经绪的操作和确认才能继续保持在计时器之内。

　　记录计时的结果

　　在这个类中，会初始化一个CSV文件，并且所有的交易时间都会使用一份用户定义的描述来用毫秒记录。

　　PerformanceLogger类支持在运行时指定，而不管测试员是否对记录性能结果感兴趣。通过这种方式，可以将计时代码添加到感兴趣的事务中，但是这些事务只会根据兴趣进行评测。 Performance日志文件同样是可配置的，而且测试员可以指定文件的位置和名字。所有提供的文件名都有一个日期/时间标签以确保一个的文件名。

　　在开始一项测试之前，应该先指定创建文件的信息，并且初始化 PerformanceLoggerINSTANCE。初始化代码如下所示：


if (PerformanceLogger.isEnabled())
{
　　String logDir = "C: empperfLogs";
　　String logPrefix = "Application1Performance";
　　 PerformanceLogger.INSTANCE.setDirectoryPath(logDir);
　　 PerformanceLogger.INSTANCE.createPerformanceLogfile(logPrefix+"_Performance");
}

　　分析结果

　　不论是在什么时候，对趋势与这些结果的分析理解，需要考虑到基线并不是一个的响应时间。我们并没有一种机制，以精确地定量化工具（RationalFunctionalTester）或者Java代码实施所引入的负荷。上面所描述的计时方法学，目的是降低这个负荷，并允许将负荷当做只会轻微变化的静态成本处理。有意义的分析是随其他变量而变化的行为，这些变量例如有沿着一个操作的循环，对系统所施加的负荷等等。当您在报告和分析结果时，您所报告和分析的数据，对于这些值所代表的意义要十分的清楚，这一点很重要。任意真正响应时间的指示都可能会产生错误的结论，并对那些实际上并不能改进产品的方面进行讨论。

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

　　采用以下的范例场景：

　　（1）运行脚本作为单个用户，服务器上没有负载
　　（2）向服务器添加10个虚拟用户的负载，重新运行脚本
　　（3）向服务器添加 50个虚拟用户的负载，重新运行脚本
　　（4）向服务器添加250个虚拟用户的负载，重新运行脚本
　　（5）向服务器添加500个虚拟用户的负载，重新运行脚本

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


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

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

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

　　总结

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