Rational Performance Tester 还能够使您执行根本原因的分析。这在两个方面获得便利：资源使用（正如前面所提到的）以及代码执行统计表。此处，您从性能报告中能够得到一个响应时间分解报告。这允许您在预定的测试期间从页面元素中分析统计表，或者从外部工具中分析任何导入的历史数据。响应时间分解为您所测试的系统显示了诸如每一项元素的周期等细节。每一个页面元素都被同统计表中的一个入口关联起来。在获得响应时间分解之前，您必须选中 Response Time Breakdown 选项：
- 选择包括测试脚本的调度，然后选择 Schedule Element Details > Response Time Breakdown。
- 在 Quick Links 下，勾选 Enable collection of response time data 复选框。
- 最后，为适当的录制选择复选框。
图 32. 启动响应时间分解
- 确保 DCI 正在运行，并且已经准备好被监控。
- 要启动监控，进入 Start > All Programs > IBM Software Development Platform > IBM Rational Data Collection Infrastructure > Start Monitoring。
Response Time Breakdown 报告提供了与代码执行相关的统计表，它包括根本组件：JDBC、RMI/IIOP (Remote Method Invocation over Internet InterORB Protocol)、网络服务器、EJBs，等等。图33中显示了一个 Response Time Breakdown 报告的例子。（您也能够通过查看 Response Time Breakdown Statistics 获得更多细节，尽管该选项并没有被显示在这里。）
图 33. 响应时间分解
通常来讲，响应时间分解是在开发环境中被捕获的。在它被启用和配置用来收集数据的量（低、中、高）之后，并且数据收集器基础构造被安装和运行之时，您能够通过以下几种方式收集数据：
- 从一个标准的Web 应用程序性能测试中得到；
- 从这些性能监控工具中：IBM® Tivoli® Monitoring for Transaction Performance、IBM® Tivoli® Composite Application Manager for Response Time Tracking、或者 IBM® Tivoli® Composite Application Manager for WebSphere 得到；
- 从 Java™ 2 Platform、Enterprise Edition (J2EE) 应用程序服务器和 Application Response Measurement (ARM) 中得到。它所支持的应用程序服务器包括 IBM® WebSphere® Application Server 版本5和版本6，以及 BEA WebLogic 版本8；
- 从网络服务中得到；
- 从一个配置 ARM 的应用程序中得到。这一模式支持一个不支持 J2EE 的应用程序服务器。数据能够通过手动插入 ARM API 调用而被收集。ARM 工具将通过挖掘工具下面的应用程序提供一个事物序列图表；
- 从应用程序、网络服务器、数据库服务器所生成的应用程序日志中得到。这些能够被导入、分析和关联。
请注意：
每一个应用程序服务器都需要被配置和被用于数据收集基础构造。
启动 Data Collection Infrastructure (DCI) 监控器的唯一目的就是收集分析数据。正如前面所提到的，为了确保数据被收集，DCI 需要为每一台运行应用程序的主机启用（安装和运行）。失败的操作将导致如图34中所示的错误。
图 34. Profiling Agent 错误
Rational Performance Tester 同 IBM® Rational® ClearCase® LT 被打包在一起，使得源版本控制能够更好的鼓励开发环境中的协作。ClearCase LT 配置一个单一的服务器模型以及少量的管理需求。尽管自然地适合于一个比较小型的环境，例如25-30位开发人员和测试人员，但是您也能够将 ClearCase 或者 IBM® Rational® ClearCase MultiSite® 编辑器用于更加大型的环境中，并且为两者都提供了移植路径。
资产，例如项目、调度、测试、定制代码、数据池、位置、以及结果等，能够被放到源代码控制之下。通过 IBM Rational ClearCase LT 源控制，可以提供以下特性：
- 检入和检出：检入资产，使得他人能够在其上面工作。而检出则允许您在您的本地工作台中在其上面工作。
- 透视图支持：CVS Repository Exploring （如图35中所示）和 Team Synchronizing 透视图。
图 35. 与 CVS 相关的透视图
- 多个视图：CVS Console、CVS History 和 CVS Repository。
- 同步与融合：
- 同步是一种通过知识库检查本地工作台之间差异性的一种方式。它允许您在您的本地工作台中更新资源，并且将资源从本地工作台提交到一个知识库中。
- 融合使您能够在资源冲突时找到折中的方案。
同 Rational ClearCase LT 的集成引入了在工作台中共享工作资产的功能，或者资产的并行开发功能。任何人都能够通过检入和检出工作区域共享测试文件，任何团队成员都能够在任何时间对其进行更新。通常来说，个体将本地工作于团队项目的一部分，他们通过同步工作台中发生的任何变化来核对其他人的工作。简而言之，所有的工作都是由一个本地个体所完成的，只有在这个人将它们通过提交到知识库中发布之后，它们才能够被共享。当您已经将变化提交到分部时，变化将会从您的本地工作台被拷贝到分部中。
基于功能性的需求，有许多不同的分部，例如并行运行的每一个项目都有一个分部。同样的道理也适用于处理不同的分部。您将通过首先同步您的工作台，检查其他人的工作。为了进行同步操作，IBM Rational Performance Tester 配备了一个 Team Synchronizing 透视图，以便更加容易的进行定位和管理。有以下四种与同步相关的模式：
- 流入：显示 CVS 知识库中与本地工作台不同的资源（只是流入改变）；
- 流出：显示本地工作台中将被修改的资源（只是流出改变）；
- 流入/流出：显示流入和流出改变的结合；
- 冲突：显示冲突的资源。当知识库中具有比您正在工作的资源更加新近的副本时，资源就会发生冲突。资源冲突的问题可以通过融合技术解决。丢弃您的工作或者其他人的工作也许并不是一个好的选项。
IBM Rational Performance Tester 首先是一个交互式的 GUI 测试器，它使初学者也能够轻松的执行加载测试。然而，有时侯也需要添加定制代码，从而实现更高级的测试方法。
定制代码选项以绿色字符 C 作为图标。您可以在测试脚本中的任何位置插入定制代码。图36中显示了两段即将被插入的定制代码的片段。当您第一次插入定制代码的时候，将自动生成一个类名称。不过，如果您愿意的话，可以将其重新命名为有意义的字符串。
图 36. 插入定制代码
当定制代码被插入之后，您就能够立即通过转换到 Java 源代码视图来输入代码逻辑（点击 View Code）。此外，您还能够将透视图改变为 Java Browsing。另外，内联的 Java IDE 允许您调试您的代码。
图 37. 生成定制代码
系统提供两个接口：CustomCode2 和 ITestExecutionServices，用于扩展测试执行（提供一个完整的 Javadoc）。下面的场景就是扩展测试执行的典型用例：
- 控制循环行为；
- 运行一个已经存在的调用外部程序；
- 找到一组用户或者一个用户的 IP 地址；
- 设置和清除用户的访问消息
- 从用户数据区域中获得信息；
- 将一个页面同另一个页面关联起来。
跨越地理边界为每一个远程分布的测试迭代动态地测试用户负载并不是一种通常的做法。典型的测试方法，即每一项测试都被限定在一个位置上，也许对地理分散的开发团队来说并不具有灵活性。除此之外，跨边界共享测试资产的能力，Rational Performance Tester 使您能够通过一个广域网（WAN）跨越不同的地理位置来执行负载测试。由于服务器可能是地理上分散的，所以远程执行的能力与较低的硬件要求的结合，使得您能够使用 IBM® AIX®、Linux、Microsoft® Windows® 和 z/OS 等操作系统配置远程服务器。
例如，您可能拥有五个低端的服务器，它们从新加坡仿真5000位用户，另外有三台服务器从香港仿真3000位用户，等等。这种测试方法不仅产生更加逼真的测试效果，而且降低了测试的成本，这是因为测试结果可以由团队共享和分析，而且空闲的服务器能够被更好的加以利用。
最低需求，例如每个虚拟用户拥有一个 CPU 和 1MB 的内存（通常来说）首先依赖于测试页面的复杂性。有些因素能够增加每位虚拟用户的内存容量。您能够通过仿真实际的场景获得更高的缩放比例，例如为每位用户使用思考时间和延迟时间。通常来说，将额外的负载放到管理员服务器上并不是一种很好的做法，这是因为与工作台相关的活动需要服务器中的资源。
在您捕获测试脚本之后，扩大虚拟用户的范围就是添加更多的用户组。Rational Performance Tester 通过允许您添加更多的用户组以及指派用户的绝对值数量或者百分点数量，从而无缝的掌控缩放比例。只要测试实例依旧完整的话，我们就无需重新捕获测试脚本。
中央管理部门允许一个集中的视图和管理，只需少量的管理成本就能够管理远程测试系统。管理本地测试服务器和远程测试服务器所花费的精力实际上是一样的，这是因为远程服务器并不必掌控本地服务器复杂。图38中显示了将远程服务器纳入测试服务器是多么的容易实现。
图 38. 远程测试服务器——管理员
在本系列四篇文章的第 1 部分中，我们查看了由 IBM Rational Performance Tester 所提供的各种各样的功能。包括易于使用的 GUI 管理、报告特性、以及可量测性。尽管这些内容仅仅是被简要的概述，但是本文为您提供了一幅功能的鸟瞰图。您能够使用从这一简要介绍中所获得的知识加深对 IBM Rational 软件交付开发平台中的软件选项的负载测试工具的理解。
在第 2 部分和第 3 部分中，您将学习一个完整的负载测试周期。在第四部分中，您将详细看到包括在 Rational Performance Tester 中的许多报告及其变种，并且学习如何根据您的特定需要对它们进行定制。
文章来源于领测软件测试网 https://www.ltesting.net/
