一般来说，在性能测试员进行系统性能测试的过程中主要面临以下挑战：

　性能测试脚本的能力：它包括性能测试员构造各种复杂性能测试场景的能力和测试脚本的扩展和维护能力。
　　测试脚本的参数化能力：性能测试总是要模拟大批量虚拟用户对被测系统进行各种操作，因此测试脚本的参数化能力和上下文数据的关联能力，便成了性能测试员进行性能测试时要解决的基本问题。
　　构建各种负载模型的能力：准确模拟被测系统的真实负载情况，是确保性能测试有效、准确的前提。
　　被测对象的性能监控能力：它为性能测试员进行各种性能分析、定位问题和解决问题提供保证。
　　性能测试结果的分析能力：性能测试员需要使用各种报告和报表，对性能测试过程中的各种性能数据进行有效分析，做到正确认识被测系统的各项性能指标。
　　因此，优秀的性能测试工具，一定要满足以上各种性能测试能力要求，使得性能测试员在测试工具的帮助下，能够轻松完成各种性能测试。IBM最新推出的性能测试解决方案：IBM Rational Performance Tester（简称RPT），正是很多性能测试员梦寐以求的，能够为其提供以上各种能力，帮助其轻松完成各种WEB应用系统性能测试的优秀测试工具之一。

2 IBM最新自动化性能测试解决方案：Rational Performance Tester
　　IBM Rational Performance Tester（简称RPT）是IBM基于Eclipse平台及开源的测试及监控框架Hyades，开发出来的最新性能测试解决方案，总体架构如图一所示。它可以有效地帮助测试人员和性能工程师验证系统的性能，识别和解决各种性能问题。它适用于性能测试人员和性能优化人员，用于开发团队在部署基于HTTP和HTTPs通信协议的Web应用程序前，验证其可扩展性、性能和可靠性。在为性能测试员和性能优化人员提供了前面所提到的各种性能测试能力以外，它还提供了可视化编辑器，一方面可以使新的测试人员可以在无需培训和编程的情况下，即可快速上手完成性能测试；另一方面，也为需要高级分析和自定义选项的专家级测试人员，提供了对丰富的测试信息的访问和定制能力、自定义 Java 代码插入执行能力、自动检测和处理可变数据的能力。

图一、IBM Rational Performance Tester体系架构示意图

　　此外，通过和IBM Rational的整个软件平台的完美集成，它第一次为基于Eclipse的Web和J2EE应用系统的性能测试人员，提供了和开发人员同样的操作平台，真正实现了一个平台、统一软件开发团队和性能测试团队的能力。

　3 使用IBM RPT轻松完成自动化性能测试

　　3.1 基于与开发人员同样的平台进行性能测试脚本录制
　　基于开发人员的同一开发平台（Eclipse），如图二所示，性能测试人员使用RPT进行软件性能测试时，只要在开发人员工作的Eclipse环境中建立性能测试项目（其实它也是一种Java项目），就会自动打开测试透视图，立即拥有专业的自动化性能测试工具所拥有的全部功能。

图二、IBM Rational Performance Test工作界面

　
　　在RPT的测试脚本的实现过程中，使用了基于录制的脚本生成技术。当完成性能测试的测试计划和测试设计以后，如图三所示，性能测试员只要在性能测试工具条上选择测试脚本录制按钮，在弹出的"HTTP代理记录器"窗口输入测试脚本名称，就会自动启动测试脚本录制过程。

图三、进行性能测试脚本录制

　　如图四所示，性能测试工具RPT会自动打开浏览器（支持的浏览器包括IE,Netscape,Mozilla）。此时，性能测试员应根据提示，首先删除临时文件，然后在浏览器中输入被测Web应用的网址，按照测试用例的设计步骤浏览Web应用程序，完成测试脚本录制。

图四、性能测试脚本录制的注意事项

　脚本录制和生成架构

　　如上图所示，RPT使用位于代理控制器上的记录器，完成性能测试过程原始协议数据的录制工作，并将其存在跟踪记录文件（.recmodel和.rec文件）中。然后，RPT测试生成器会对跟踪记录文件进行分析，生成测试脚本（.testsuite文件）。RPT提供了图形化的测试脚本编辑器，如图五所示，性能测试员可以通过图形界面，显示测试脚本录制过程中浏览器和Web应用服务器间所有的HTTP/HTTPs协议信息。在可视化的测试脚本编辑器中，性能测试员可以察看具体的消息协议数据，包括请求内容、响应头和响应内容，帮助测试人员理解测试脚本；也可以对指定的消息进行编辑、修改，添加定制的数据关联或进行脚本参数化；还可以加入定制的Java脚本，进行动态验证或控制测试执行逻辑。

图五、测试脚本显示窗口

　　3.2 使用RPT轻松实现性能测试脚本的高级定制能力
RPT提供了灵活的测试脚本编辑能力、数据驱动的性能测试能力和上下文数据智能关联及定制能力。

　3.2.1 测试脚本编辑和定制能力

　在性能测试脚本的录制完成后，如图六所示，基于测试脚本的图形化界面，测试员可以轻松完成以下各种定制工作：

　选取测试消息，通过更改其详细的标题，建立更易于理解和重用的测试脚本；
　　通过在测试脚本中添加自定义的HTTP请求，循环和条件语句，测试员可以随意控制测试脚本的执行过程。循环语句可以控制指定消息的执行次数，条件语句（IF/ELSE语句块）可以实现根据上一消息的响应内容，决定测试脚本的执行路径；
　　通过在测试脚本中添加自定义的Java代码，测试员可以实现对消息返回内容的验证、为后面的消息构造动态消息数据或执行各种特殊任务；
　　通过将一些消息组织成相应的事务，使得整个测试脚本更加容易理解，同时可以更方便的对测试结果进行分析；
　　通过启用页面标题验证点、响应代码验证点和响应包大小验证点，RPT会自动完成对测试执行过程中的页面标题、消息响应代码和数据包大小的验证，生成各种测试验证报告。
　图六、PRT测试脚本的能力

　　通过以上内容，我们可以充分领略到RPT为性能测试员提供的强大性能测试脚本能力。更难得的是，几乎所有这些能力都可以通过图形界面，在轻松的鼠标点击声中得以实现。

3.2.2 数据驱动的性能测试能力及测试数据的智能关联能力

　性能测试的主要任务就是模拟一定数量的虚拟用户，按造指定的负载模型对被测系统进行各种操作，完成测试。因此，性能测试脚本的参数化能力和消息上下文数据的智能关联能力，就会成为性能测试员工作中的一个重要任务。

　RPT在测试脚本录制和生成过程中，能够按照最佳实践经验，自动完成测试数据在不同消息间的智能关联（关联数据用紫色标识）。如图七所示，为了性能测试员更好的理解测试数据的来源，还可以选择指定的测试关联数据，右键菜单转至指定关联的数据源。此外，测试员还可以通过图形界面，自己建立数据关联关系，实现各种动态数据关联需求。

图六、PRT测试脚本的能力

　　图七、测试脚本中消息上下文中数据的智能关联 RPT会自动标识可能进行参数化的动态数据（用绿色标识），测试员可以通过右键选取指定的数据，如图八所示，选择用数据池变量替换，从而实现测试脚本的参数化任务。RPT使用绿的底色标识指定的变量由数据池中读取。当然，在测试员可以使用数据池之前，如图九所示，首先必须在性能测试项目中创建所需的数据池，数据池中的数据可以从外部文件中导入，也可以在数据池的数据编辑窗口中进行编辑。

　图八、测试脚本参数化

　　图九、数据池的创建过程和数据池内容编辑窗口

　　通过以上描述，我们可以充分了解到RPT灵活、方便的测试脚本的参数化能力和上下文数据的智能关联能力，它们将会使性能测试员的性能测试工作变得更加轻松。

3.2.3 自定义Java脚本的使用

　在测试脚本中添加自定义的Java代码，主要是为了实现对消息返回内容的验证、为其后的消息构造动态消息数据或为了完成如验证、加解密、日志记录等的特殊任务。RPT通过内置Java代码执行引擎，提供在测试脚本中灵活插入客户化Java代码的能力。性能测试员可以通过右键菜单（如图六所示），方便地在测试脚本中添加定制Java脚本。

图十、在测试脚本中加入定制代码

　　在加入定制代码过程中，性能测试员通常要根据需要为添加的Java类命名，然后，点击"生成代码"按钮，RPT可以自动生成测试脚本的框架；通过点击"查看代码"按钮，性能测试员可以对生成的代码进行编辑，实现所需的定制任务。自动生成的Java代码框架如下所示：

　从代码中我们可以看到，性能测试员只要把要实现的逻辑写入exec()方法即可。定义了定制脚本之后，我们就可以在其后的测试脚本中使用自定义的代码，完成各种任务了。具体操作过程如图十一所示，RPT用桔黄色来标识变量的值来自定制的Java脚本。

图十一、在测试脚本中使用"定制代码"

3.3 建立性能测试负载模型，执行性能测试
　　压力测试的关键是能够通过测试工具准确模拟被测系统在生产环境运行时的真实负载情况。在进行性能测试前，一般会由性能测试员和用户代表一起，根据性能测试计划中指定的的测试目标，制定测试用例，完成对应的负载模型分析，以便正确执行和实现性能测试目标。一般情况下，性能测试员使用《负载分析文档》来确定性能测试负载模型中要使用的各种变量，并定义变量值。通过它们来确定被测系统在生产环境中运行时，涉及的各种负载角色特征、每种角色要执行的最终用户业务功能（用例及其执行流程与条件）和对应工作量和容量，以便最恰当地模拟最终用户的负载情况。此外，负载模型中还应确定负载模拟持续的时间间隔、测试期间要改变的任何因素或变量，以及测试结果的评测方法。

　进行负载模型分析的关键，在于找出被测系统的主要角色，以及主要角色所进行的关键任务，从而从总体上了解被测系统是如何被各种不同用户使用和在怎样的负载情况下工作的。在进行性能测试前，性能测试员可以通过如下手段获得系统负载模型中的各种变量：

　1) 从最终使用人员获得操作情况，如经常进行的业务类型、业务操作的频率；

　2) 根据系统日志，可以获得每日所进行的各种业务类型和业务量；

　3) 通过和系统测试人员、操作人员、系统架构师充分沟通和配合，对被测系统作如下分析：

　定义系统主要角色,它在UML中被称作主角(Actor)，确定每个主角的属性和工作简档，确定哪些能够唯一标识被测系统最终用户的各种特征的属性和变量（如打字速度、思考时间以及反复出现的因素）。
确定系统主要角色相关联的用例（Use Case），及每个用例中的主要操作流程，即用例中的必选流和主要可选流，明确每种角色通过执行用例来履行业务职责时，每种操作流程所用的工作量比例或耗时百分比。
确定评测指标和标准，用于评估既定性能目标是否已达成。评测指标通常包括响应时间限度或吞吐量。
最终形成如下面例子中的系统负载模型：

　
　　在IBM Rational Performance Tester工具中，如图十二所示，可以使用性能调度（Schedule）完成构建负载模型的任务。它主要提供了以下测试控件，帮助测试员实现灵活的负载模型：

　1) 用户组：实现不同角色的模拟。在用户组中，可以加入各种测试脚本、随机选择器、循环、延时等完成与角色关联的各种典型业务操作流程的模拟。对用户组可以设置具体业务负载百分比，来模拟不同用户组对被测系统造成的负载比例；

　2) 随机选择器：实现用户组内部各种随机业务操作（用例及其事件流）所占不同负载比例的模拟。可以在随机选择器中加入不同的加权块，代表不同的业务操作（用例及其事件流），通过对其设置权重完成对其负载比例的模拟。

　3) 循环：完成用户的重复操作的模拟，例如用户在查询产品时，可能会对不同产品进行多次查询，这时性能测试员可以通过对测试脚本进行参数化和指定脚本的循环次数，来完成对应的负载模拟工作。

　4) 延时：用来模拟真实环境中，用户在进行不同业务操作中可能存在的思考和等待时间。

　通过RPT中的性能调度（Schedule），性能测试员就可以将上表所述的负载模型准确的模拟出来，如图十二所示。

图十二、RPT使用性能调度进行负载模型的模拟

　　在完成负载模型以后，测试员就可以在"性能调度(Schedule)"的属性中动态随需指定想要运行的虚拟用户数，进行不同数量的虚拟用户负载情况的性能测试。

图十三、在RPT中指定不同数量的虚拟用户执行性能调度（Schedule）

　　测试员执行指定的性能调度（Schedule）时，如图十三所示，应该首先选择"运行"，然后在弹出的运行配置管理窗口中，为Schedule创建新的配置。如图十四所示，在配置的属性中，性能测试员可以指定要执行的Scheudle，执行结果的存放项目和目录，以及是否该配置出现在运行或调试菜单中。

图十四、性能调度（Schedule）的运行配置

　　从以上部分我们能够看到，RPT为性能测试员提供了通过鼠标点击就可实现的灵活负载模型建立能力，使得负载模型的建立变得更加的简单。

　3.4 轻松完成测试结果分析
　　测试执行过程中，性能测试员可以通过自动弹出的测试报告窗口，方便的监控整个测试执行过程，并通过不同的报告页面实时察看测试结果信息。

　在进行测试结果分析时，首先性能测试员可以通过总体运行情况报告，如图十五所示，对整个测试运行过程有个一目了然的了解。

　图十五中上面的滚动条显示了整个测试执行的状态：

　正在初始化计算机
　　正在运行
　　正在进行执行历史数据传输
　　完成
　　图十五、总体运行情况报告

　　图十五中四个柱状条分别显示：

页　　面状态码成功百分比
　　页面元素状态码成功百分比
　　通过页面验证点（VP）百分比
　　通过页面元素验证点（VP）百分比
　　当把鼠标移动到某一柱状条上时，可以看到当前柱状条所代表的具体数据值。

　运行小结报告对整个测试运行过程进行总结，如图十六所示，给出性能测试员在进行性能测试时最关心的一些性能指标,例如页面和页面元素的平均响应时间，验证点的通过情况以及页面和页面元素的命中数和尝试数。

图十六、测试运行小结报告

　　而页面性能报告、响应时间总结报告和响应时间详细报告则为性能测试员提供进一步分析性能问题，定位性能问题提供了必要的信息。页面性能报告显示每个页面的平均响应时间，响应时间总结报告（Response vs. Time Summary）显示所有页面和页面元素的平均响应时间在测试运行过程中的变化情况，性能测试员可以通过它们对被测系统性能问题作出初步估计。响应时间详细报告（Response vs. Time Detail）则详细显示每个页面的响应时间在测试运行过程中的变化情况，为性能测试员提供了进一步的信息。一般情况下，开始时页面的响应时间要比稳定状态的响应时间慢。

图十七、页面性能报告

图十八、响应时间总结报告

图十九、响应时间详细报告

　　页面吞吐量报告则为性能测试员报告了在整个测试运行过程中，虚拟用户的活动情况（右图）和页面的吞吐量信息（页面的尝试速率和页面的点击率）；

图十九、页面吞吐量报告

　　如图二十和图二十一所示，服务器健康状况总结报告和服务器健康状况详细报告可以让性能测试员从总体上对服务器运行健康状况一目了然。服务器健康状况总结报告通过显示页面和页面元素总的尝试数、命中数和返回状态码的成功总数，帮助性能测试员方便了解被测服务器的整体健康状况。而服务器健康状况详细报告则把相关尝试数、命中数和返回状态码的成功总数，进一步细化到每个页面和页面元素，帮助性能测试员准确了解被测服务器的整体健康状况，定位问题所在。

图二十、服务器健康状况总结报告

图二十一、服务器健康状况详细报告

　　除以上预定义的各种测试报告外，RPT还为测试员提供了灵活的测试报告的定制能力。通过管理报告功能，性能测试员既可以建立新的报告，也可以编辑各种已经预定义好的报告，修改报告内容或增加报告页面。如图二十二中"我的报告"页面所示，性能测试员可以根据测试要求，把自己关心的多项指标，显示在一个报告页面。

图二十二、性能测试报告的定制能力

　　RPT报告定制能力中最有创造性的技术莫过于它把性能测试员和用户所关心的各种性能指标以计数器（Counter）的形式记录下来，如图二十三所示，测试员在生成报告时，可以根据需要从已定义的各种计数器中选取任何关心的计数器生成报告。这大大增强了性能测试员对测试结果的分析能力和报告能力，这些无疑都会大大改善性能测试员的测试过程体验。

图二十三、基于各种性能指标计数器生成测试报告

　　3.5 系统资源监控
　　为了更好的进行性能问题分析，找出被测系统的性能问题，性能测试员还需要了解在性能测试的运行过程中，被测系统运行的服务器上的各种系统资源消耗情况。RPT通过其强大的概要分析（Prifiling）能力，可以在系统性能测试运行的同时，完成服务器各种系统资源的监控。具体作法如下

　1) 切换到概要分析和日志记录透视图（Profiling and Logging Perspective）;

　2) 在运行菜单，选择"概要分析"，如图二十四所示。

图二十四、在RPT中通过概要分析实现对服务器各种系统资源的监控

　　3) 在弹出的"概要分析"窗口选择"Perfmon数据收集代理程序"，选择"新建"按钮，建立新的概要分析配置，如图二十五所示，并给出要监视的主机和存放监控记录文件的项目或目录。最后，点击"概要分析"按钮，开始概要分析过程。

图二十五、建立概要分析配置

　　4) 在"概要文件监视器"视图中选择新出现的、正在运行的概要分析结点，如图二十六所示，右键菜单中选择"配置Perfmon计数器"，列出所有可以监控的计数器；

图二十六、开始配置要监控的性能计数器

　　5) 在"配置Perfmon计数器"选择想要监控的计数器（例如内存、处理器和网络等），右键选择"获取子计数器"，如图二十七所示，直至找到要监控的计数器，右键选择"开始跟踪此计数器"。性能测试员可以选择多个计数器同时监控；

图二十七、选择要监控的性能计数器

　　6) 然后在"概要文件监视器"中选择正在运行的概要分析，右键菜单中选择"打开方式"－>"统计数据视图"（Statistical View）。这时，性能测试员就可以在"统计数据视图"中，看到前面选定的计数器的变化情况，如图二十八所示。

图二十八、监控性能计数器

　　在"测试透视图"中，性能测试员执行测试时，可以通过选择"Window -> Show View -> Other … -> Profiling and Logging -> Statistical Data"显示"统计数据视图"，实现在性能测试执行的同时，实时监控所关心的各种服务器性能计数器的变化情况。通过将前面分析的各种结果跟被测服务器系统资源消耗情况相关联，性能测试员能够判断是否由系统资源引起了性能问题，从而排除硬件和网络因素对被测系统性能的影响。

　3.6 与其它生命周期管理软件的完美集成
IBM Rational的自动化性能测试工具基于Eclipse平台，提供了和需求管理工具（RequisitePro）、建模工具、代码级测试工具和变更及配置管理工具（ClearQuest和ClearCase）的完美集成，这使得系统测试人员能够和整个软件开发团队在同一个软件平台上，实现系统性能测试的同时，完成测试脚本的配置管理和缺陷追踪任务，这大大提高了性能测试员对整个测试过程的管理和维护能力。

　4 IBM Performance Optimization Toolkit帮您完成性能调优
现在，假设您开发的应用程序正显示出性能问题的征兆，用户可能会发现该应用程序变得出乎意料得慢。它可能在一段时间之后变为不响应。或者它可能没有警告就发生故障，结果导致丢失客户数据。性能问题的原因主要有两类：

　1) 编码问题，问题出在应用程序本身的逻辑中。编写较差的应用程序代码可能导致应用程序执行多余的或者不必要的工作。例如，算法效率低或者伸缩性不好、不必要地频繁调用远程调用、SQL 查询效率低等，都会导致应用系统性能问题。

　2) 配置问题，问题与应用程序无关，而是由外部因素引起的。这些因素包括硬件问题（如内存不足或者处理能力不足）、网络问题（如等待时间长、吞吐量低和连接问题）以及其它相关软件问题（如数据库调整不当）。

　IBM Rational的性能测试解决方案除了RPT提供的各种性能测试功能以外，还包括了最新发布的免费性能优化工具包（IBM Performance Optimization Tookits，简称IPOT），它能够帮助您在您的分布式应用程序中找出并修正与编码相关的性能问题，和性能测试工具RPT配合使用，帮助性能测试员准确定位基于J2EE的Web应用系统性能问题，分析问题根源，解决问题。

　4.1 性能优化工具包的体系架构
性能优化工具包主要由以下两部分组成：数据收集代理和基于 Eclipse 的开发人员工具。

　4.1.1 数据收集体系结构

　数据收集体系结构收集整个分布式环境中的运行时应用程序性能数据。对于每台运行应用程序的主机，如果您想要从该主机收集数据，那么它必须安装并运行数据收集体系结构。

　数据收集体系结构由以下组件构成：

　代理控制器，它管理数据收集代理，并与工作台进行安全通信 ；
　　应用程序响应测量（ARM）引擎，它从应用程序收集 ARM 数据 ；
　　ARM代理和JVMPI代理，它们能够连接到应用程序来收集数据 ；
　　服务器配置实用程序，它配置服务器将数据发送给代理 ；
　　数据收集代理，用于从生产或开发环境捕获跟踪、监视、收集应用程序性能数据以及日志数据，而应用程序性能数据由应　用程序响应测量（ARM）完成。应用程序响应测量（ARM）标准帮助测量应用程序的端到端的事务性能、服务级别以及响应时间。ARM API 是一个开放式标准。可以在http://www.opengroup.org/management/arm.htm下载相关标准文档和示例。运行在受支持的 J2EE 应用程序服务器上的应用程序会自动被 ARM API 调用检测。这意味着它们自动产生数据收集代理收集并分析的数据。其它您想在开发环境中分析的应用程序则必须手动用 ARM API 调用检测。

　4.1.2 基于 Eclipse 的开发人员工具

　基于 Eclipse 的开发人员工具，提供视图和工具以用于查看和分析代码和运行时数据，它把性能测试员数据收集体系结构收集到的各种应用性能数据，和整个应用运行过程进行直观关联，从而有效帮助性能分析人员定位性能问题，并找出性能问题的原因、解决问题。

　4.2 使用性能优化工具包（IPOT）轻松进行应用系统的性能分析
利用性能优化工具包(IPOT)可以从生产或开发环境中运行的应用程序中，收集应用性能数据。帮助性能测试员解决以下多种不同类型的性能问题：

　性能问题 － 执行操作的时间比预期的长
内存泄漏 － 应用程序在内存使用方面处理不当，导致正常操作期间发生内存不足的错误。
应用程序故障 － 应用程序发生故障，表现为或有警告或无警告地突然终止（崩溃），或者进入不响应状态（挂起）。
下面以解决应用程序性能问题为例，解释使用工具进行基于J2EE的Web应用程序的性能优化过程。

　在使用应用程序性能分析工具时，分析问题的第一步是找出什么引发了该问题。这可能是一个用户操作，也可能是在整个应用程序中出现的更普遍的问题。如图所示，在下面的例子中，性能测试员可以通过RPT的页面性能报告，看到蓝色部分显示的欢迎页面是最慢的，所以，下面通过RPT和性能优化工具包结合使用，对其性能进行分析。

图二十九、定位性能问题

　　明确了存在问题的页面以后，性能测试员首先要在对应测试脚本中指定页面的消息属性中选择"启动ARM监控"，如图三十所示，同时也要在将要执行的"性能调度(Schedule)"的属性中选择"启动ARM监控"。

图三十、启动页面的ARM监控

　　然后，性能测试员就可以选择将要执行的"性能调度(Schedule)",右键选择"概要分析"（Profile），启动'概要分析"配置窗口。

图三十一、启动"概要分析"

　　在概要分析配置窗口中，选择"J2EE Application with Performance Schedule"配置项，选择新建配置，如图三十二所示，给出配置名称，在Schdule页面选择要执行的"性能调度(Schedule)"；在Execution Results页面选择用于存放测试概要分析结果的项目；在Profiling页面选择"J2EE Performance Analysis"。最后选择"概要分析"（Profile）按钮，开始概要分析过程。

图三十二、 "概要分析"配置窗口

　　在自动启动的监视器窗口，如图三十三所示，性能测试员可以选择当前运行的监视器节点，右键菜单中选择合适的性能分析视图，进行被测系统的性能分析。

图三十三、 打开各种性能分析视图

　　一般情况下，性能测试员会首先打开"UML2 Class Interaction"类交互图，观察被测应用的总体运行情况。如图三十四所示，性能测试员可以点击不关心的类，在右键菜单中将其从图中过滤掉，从而更好地关注性能相关的部分。

图三十四、性能分析视图－类交互图

　　在"UML2 Class Interaction"类交互图中，性能测试员可以通过图中最左边红色部分，快速定位性能问题所在。

图三十五、在性能分析视图－类交互图中定位性能问题

　　在了解被测应用的总体运行情况和大致问题所在以后，性能测试员可以打开"method Statistics" 方法统计视图，通过排序功能快速、准确的定位耗时最多的方法。

　图三十六、在性能分析视图－方法统计视图中定位性能问题

　　为了进一步了解方法执行过程，在方法统计视图中还可以右键单击指定方法，选择"Show Method Invocation",了解方法中具体的逻辑调用过程。具体信息如图所示。

图三十七、性能分析视图－方法执行动态视图

　　为了进一步定位被测应用系统的性能瓶颈，性能测试员还可以打开"Performance Call Graph"视图，找出在整个应用执行过程中最大路径所在。如图三十八所示，它可以帮助性能测试员一目了然的定位整个被测应用系统的最大执行路径，从而时性能分析人员能够更有效的进行性能分析。如果调用树过于复杂，性能测试员还可以通过右键菜单中的Subtree->Focus on Subtree缩小调用树的显示范围。

图三十八、性能分析视图－性能调用图（Performance Call Graph）

　　在调用树上，如图三十九所示，只要将鼠标置于某一方法之上，性能测试员还可以方便的了解指定方法的具体性能信息。

　图三十九、性能分析视图－在性能调用图上显示方法详细信息

　　在性能调用"Call Graph"视图中，左键双击性能有问题的方法，就会弹出方法详细信息窗口，这里性能测试员可以看到有关方法的详细信息，包括该方法运行所花费时间、被调用次数等，所有调用过它的方法和被它调用的方法的统计信息。

图四十、性能分析视图－方法详细信息视图

　　同时，性能测试员可以通过右键菜单，直接进入指定方法的源代码，在代码级分析代码性能问题，进行代码优化工作。

　通过以上信息，我们可以看到IBM性能测试解决方案不但为性能测试员提供了简单易用的性能测试能力，同时也为性能分析员提供了方便的性能问题诊断、定位和辅助解决信息，使得使用者不但可以通过它快速了解被测系统性能状况，还可以准确定位、诊断及解决性能问题。

　5 小结
　　技术的进步总是在不断地改造测试员的工作和生活环境。IBM最新推出的性能测试解决方案：Rational Performance Tester不但在在工具的易用性、功能和工具集成度方面有了很大改进，帮助系统性能测试员更加轻松的完成性能测试；而且，通过和IBM免费工具包：IBM Performance Optimization Toolkit的结合使用，为性能测试员提供了强大的性能数据收集、问题定位和分析能力，使得解决应用系统性能问题的过程变得更加轻松。