使用 RPT进行 Web 应用程序的负载测试: 第 1 部分：概述
上一篇 / 下一篇 2010-10-25 13:52:10 / 个人分类：Rational Performance Tester
简介： 紧张的进度加上有限的资源，看起来会在不同阶段困扰着开发工作。有一些团队选择在每一次迭代时进行负载测试。大多数情况下，负载测试仅仅在开发周期的末期即项目被首次展示之前被执行。这就不可避免的会威胁到应用程序的质量及其满足客户的 SLA （服务级别协定）的能力。IBM® Rational® Performance Tester Version 7 使您能够迅速的进行负载测试，从而确保软件的性能和质量。
本文适用于以下任何一类人群：
IBM® Rational® Performance Tester 是一款性能测试工具，它仿真各种各样的用户负载来模拟真实生活中的负载。通过适当的计划，这一工具利用当前的负载来估计未来的负载。例如，一个客户的应用程序可能最多只能够服务5000位用户。通过 Rational Performance Tester，您能够轻易的估计出用户负载分别为1000、2000、3000、4000、5000以及更多的情况，以便您能够设计正确的用户增长，并且能够更加精确的设计服务的规格，例如最佳的 CPU 和内存需求。您能够识别并且诊断出性能的瓶颈，无论这种问题是发生在网络、数据库、应用服务器、甚至是用户应用程序之中。这一基础导致分析能力进一步分析应用程序的等级，它可能包括诸如 Enterprise Java™Beans (EJBs)、servlets、Java™ Database Connector (JDBC) API、网络服务器等等页组件。这一功能性使您能够通过分析在线的或者解压的报告轻易地和有效地查明性能问题。
Rational Performance Tester 也有助您在配置您的基于网络的应用程序之前创建、运行和分析性能测试，并且验证其可量测性和可靠性。默认支持的协议包括 HTTP 和 HTTPS，允许您在Web 应用程序上运行负载测试。若干扩展也被提供如下：
- IBM® Rational® Performance Tester Extension for Citrix Presentation Server
- IBM® Rational® Performance Tester Extension for SOA Quality
- IBM® Rational® Performance Tester Extension for Siebel Test Automation
- IBM® Rational® Performance Tester Extension for SAP Solutions
Rational Performance Tester 同使用一个可携式摄像机录制录制一段视频剪辑拥有相似的工作方式。它允许您录制您想要运行负载测试的每一步操作，然后通过适当的用户负载重放这些操作。本系列文章的第 1 部分（即本文）介绍了 Version 7 中所包括的特性和功能。
在一个典型的场景中，为了测试一个 Web 应用程序，您就要通过定义良好的测试计划来识别各种各样的场景。在一个负载测试期间，一位导致多个测试服务器负载崩溃的用户往往是我们所想要的。通过在多个机器之间适当的分摊用户负载，能够确保生成有意义的报告。这是一种在某些避免测试器负担过重的同时，另一些测试器却没有被充分利用的好方法。本系列文章的第 2 部分和第 3 部分将讨论在不影响您先前所录制的测试脚本的情况下，有效地降低用户负载所需要考虑的事项。它将探索一个视觉指导的、基于目录的（基于树形结构的）编辑器和步骤来创建、编辑、确定评价时间、并且获得分析报告。
本系列文章的第 4 部分全部是关于报告的。我们将解释如何检查、诊断、分析和解释 Rational Performance Tester 所提供的各种各样的分析报告。例如，一个Web 应用程序可以被分解为不同的组件，诸如 EJBs、servlets、JDBC 以及用于分析的 Web 服务器。我们还将探索默认的报告，并且描述如何定制它们。
本系列文章的目的是帮助您理解特性、拓扑事项、以及约束条件，以便您能够创建和测试 Web 应用程序，并且分析其性能报告。根据这一知识以及 Rational Performance Tester 的使用的便捷性，负载测试一个Web 应用程序不再是一项繁重的重担，您能够将其包含在软件的每一次迭代中。
IBM Rational Performance Tester 为您提供了特性丰富的功能，它能够有效并且容易的加载测试。您不再需要在维护复杂的测试脚本上面浪费时间，而是能够在大多数情况下使用半自动的测试工具来帮助您完成相应的操作。您也不再需要编写测试脚本，因为管理员任务是基于一个 Eclipse 3.2 框架结构中的交互式的图形用户接口（GUI）的。换句话说，您能够通过使用 GUI 完全掌控测试周期，您还可以使用定制代码进行高级的测试。这种 GUI 的方法主要包括以下种类：
- 交互式的绘图测试
- 测试的创建、精炼、重放和时序安排
- 数据池和相互关系
- 工作量的分解和分配
- 实时系统监测控制
- 实时系统报告分析
- 版本控制
- 定制代码和扩展测试
- 缩放比例和维护
本文将对以上每一个种类进行探索：
首要的问题是，IBM Rational Performance Tester 是建立在一个可扩展的开发平台之上的，使用的是 Eclipse 框架结构 Version 3.2。从开发的角度来看，Eclipse 框架结构的优势十分明显，但是从实践者的角度来看，IBM Rational Performance Tester 提供了全面而广泛的、上下文相关的 GUI 透视图来创建、管理和规划测试脚本。从测试的创建、用户负载的分发、到数据的收集，您都能够得到相应的视图。图1中显示了默认的测试透视图。
依据您所使用的透视图，相应的视图可能会有所变化。例如，默认的测试透视图提供一个四个面板的控制台及其相应的视图，包括：位于左下方面板的General > Outline, General > Properties, Test > Performance Test Runs和位于底部面板的General > Tasks, Test > Recorder Control, Test > Protocol Data。然而，您不仅局限于这些默认的视图。在任何时间，您都能够将与特定任务相关的视图包括进来，例如 Database Explorer 或者 Error Log 视图。向您的工作空间中添加一个特定的视图是非常直截了当的。例如，使用 Database Explorer 探索数据库的连通性，只需遵照如下步骤：
- 选择Windows > Show View > Other。更加通用的视图，例如 Error Log、Outline 和 Tasks 被列在下拉列表中，如图2中所示。默认的测试透视图设定了一组预先配置好的视图。您能够通过定制操作添加或者删减这些视图。
- 使用Type-Forward Filtering特性（如图3中所示）搜索您想要的视图，您无须完整匹配整个字符串。在这种情况下，后缀为data的Database Explorer视图。
透视图具有针对不同任务所提供的相应的视图，范围包括 General、Analysis、Connectivity、CBS、Debug、Profiling、Logging 和 SQL Development。我们需要做的是在正确的时刻选择正确的透视图。您能够拖动视图到面板中的任意位置，重新排列它们，或者当您需要返回原始布局时将它们归还到默认的透视图中。然而，透视图的重新安排是配置到当前打开的透视图的。例如，当其被选中时，数据库探索视图将如图4中所示：
其他值得注意的方面包括：
- 您能够使用下拉菜单搜索视图。从菜单中选择Windows > Navigate > Next View。
- 您能够通过按下“up”和“down”箭头在工作空间中当前处于打开状态的任意视图中进行定位。同样的操作也适用于定位透视图。
- 同样，您也能够使用快捷键来定位视图，例如 CTRL-F7 （向后定位）或者 CTRL-SHIFT-F7 （向前定位）。您能够从Menu > Windows > Preferences > Keys中定制快捷键。General > Keys下面的设置将被应用到所有的透视图中。
- 透视图能够根据您的需要被定制和保存，如图6中所示。三种定制方式分别为：可用的命令组、菜单中的详细内容、工具条中的详细内容。
- 还将提供一个Web 服务浏览器。
捕获、精炼、重放和时序安排一个测试的操作十分简单，这是因为 Rational Performance Tester 就是为了初学者能够方便使用而设计的。根本机制，诸如自动捕获和重放，对于用户来说都是不可见的。这使得测试的创建和维护变得十分简单。要录制一个测试，需要执行以下步骤：
- 首先，创建一个测试项目。从菜单中选择File > New > Performance Test Project。根据提示输入项目的名称。
- 选择一个录制。对于 Web 应用程序，选择HTTP recording。点击Next。
- 在下一个页面，为您所选择的测试项目命名。
- 您能够为测试下的应用程序捕获任何一个 Web URL，如图10中所示。如果您对录制满意的话，点击Exit Recorder。现在，您就能够精炼您的测试脚本（通过点击）并且以任何方式重放它了。
在您录制测试脚本之后，通常还需要精炼测试调度。例如，您能够按照以下方式定制您的脚本：
- 添加每一个虚拟用户之间的延迟时间（单位是微秒）、用户“思考时间”和统计级别的设置。
- 定义您自己的数据池（下一主题中将会对此进行讨论）。
- 使数据相互关联（确保有意义的数据在页面到页面之间平稳的流动）。
- 添加验证点（检查测试下每一个页面的通过率）。
- 添加特定协议元素、事务、循环、注释、条件处理和定制代码。
IBM Rational Performance Tester 使您能够为运行测试脚本创建任意数量的测试项目、录制和时序安排。进一步的解释将在本系列本章的第 2 部分中加以介绍，您将使用 IBM Rational Performance Tester 实现一个完整的负载测试周期。
IBM Rational Performance Tester 能够为动态加载测试数据提供变量数据，或者直接从 CSV 文件中提供，或者从定制代码中提供。数据池是一种仿真实际生活场景的方式。例如，想象一下您希望测试 ACME Online 应用程序，即一个在线购物系统。在登录之后，用户将使用特定的关键字进行搜索、浏览目录、选购商品、输入细节、添加评论、或者在以一种指定的付费方式结算之前评价他们以前的购物经验。传统上说，测试数据要求富有技巧的人员提供定制代码。拥有数据池的话，您就能够使用您定制的测试数据评价每一个要求输入的页面。在这个 ACME Online 场景中，数据池能够被创建用于用户登录、搜索关键字、等等。这一特性使您能够建造精力充沛和灵活的测试实例。
图11显示了在数据池编辑器中一个被导入的数据池的例子。
您能够在被导入的数据池中执行以下操作：
- 添加一个录制
- 删除一个录制
- 添加一个变量
- 编辑一个变量
- 删除一个变量
一个典型的测试实例由多个页面组成，根据页面的自然属性，需要不同的变量。这一用户输入被封装在 HTML 格式中。您能够通过命名创建同每一个页面相对应的数据池。例如，为了有效的测试一个端对端的Web 应用程序，数据池可能包括诸如 UserLogin、SearchString、ItemName、PaymentMethod 等等的池。创建数据池并且将其同一个页面相关联只需进行如下操作：
- 右键单击Datapools文件夹（将所有 Datapools 放到一个文件夹中是一个很好的习惯）或者Test Navigator中的任何位置，如图12中所示。
- 接下来，指定新数据库所在的文件夹。在这个例子中，是在Yahoo Entertainment > Datapools文件夹下。在点击Next赋予其一个名称，如图13中所示。
- 您能够创建任意行和列的数据池。提供一个描述是可选项，如图14中所示。
- 浏览想要得到的 CSV 文件（您需要事前创建它）。点击Finish完成添加数据池的操作。
- 将页面同数据池相关联是一项简单明了的操作。从性能测试录制的测试数据小节中，选中替代为数据池的那一行，然后点击Data Variable，如图16中所示。
提示：
包含查询字符串的 URLs 将被自动检测到，并且用深绿色被显示出来。
- 点击Add Datapool，在您想要添加的数据池上点击，然后点击Select，如图17中所示。
- 完成关联数据池和页面的操作，请您定位到该列并且点击Use Column按钮，如图18中所示。
IBM Rational Performance Tester 的数据池特性使您能够替换不同的数据，基于不同的页面定位，从而避免了例如定制代码等更多的复杂性。您能够构造基于页面定位的不同联合的测试实例，并且将每一个要求用户输入的页面同一个或者多个数据池相关联。然而，对于使用大量测试数据构造起来的真正可升级的测试实例来说，替换数据池也许并不是最佳的解决方案。在那些情况下，您能够使用定制代码功能。例如，一个 Java™ 开发人员能够将定制代码插入。（关于这一内容的更多详细信息，请您参见 IBM® developerWorks® 题为使用 IBM Rational Performance Tester 7.0 处理测试数据，第 2 部分: 使用超大测试数据集文件的文章。）
在运行中替换数据池的能力与关联不同数据的能力结合起来通过测试一个多用户的环境进行评价。相互关系（也被称为使用动态数据）是确保当前页面上的请求是基于前一个页面的引用（值）的一种方法。通常，当前页面上的数据请求是基于前一个页面中的响应数据的。Rational Performance Tester 认可并且自动将这些引用相关联，从而清楚地评价每一个用户的活动。这样的话，通过从所有测试页面中被请求的截然不同的数据，就能够将不同用户彼此区分开来。
关联数据有以下两种方法：
- 自动的：（自动的数据关联），测试生成器自动检测到当前请求中要替换的前一个值。正如前面所提到的，引用（从前一个中响应的值）将被用于关联后续请求的值。您也可以使用自己定制的代码扩展这一相互关系。
- 手工的：通过阻断现已存在的相互关系，并且将前一个的响应作为值链接到当前的请求。尽管这是默认的行为，但是您能够关闭自动的数据关联。然而，当您将其关闭之后，您将依靠您自己，直到用于测试页面的数据流程关系被关注为止。关闭操作十分简单，如图19中所示：
- 进入Menu, Windows > Preferences > Performance Test Generation。
- 选择Data Correlation标签。
为了在应用程序负载测试期间仿真实际生活的场景，Rational Performance Tester 为您提供了灵活的选项，使得测试如同实际情况一样。您能够动态地创建任意多个测试脚本和调度，以及任意虚拟用户负载的结合。通常，您还想知道您是否拥有以下这些选项：
- 我是否能够指定1000个虚拟测试人员，以相等的用户负载运行于三台远程机器中？
- 我是否能够首先运行虚拟测试人员总数的10%，然后运行再运行另外10%？
- 我是否能够让一组虚拟测试人员运行测试下的应用程序内部的某一部分？
- 我是否能够指定用户思考时间？
- 我是否能够是测试序列随机化？
- 我是否能够通过每一位虚拟用户使用不同的 IP 远程运行负载测试？
- 我是否能够以一定的比率运行测试？
由于 Rational Performance Tester 允许您完成这些选项的任何变换，所以我们将首先探索它是如何允许不同的活动通过附加到它们上面的测试元素被指派到不同组的，以及这些元素是如何影响一个负载测试的行为的。图20中显示了您能够轻易的分解工作量，并且指派到不同的用户组，使得每一个组负责不同的虚拟用户。例如，添加一个新的组：
- 只需右键单击测试调度中的组（在Schedule Contents下方）。
- 选择Add > user group选项。
当您创建一个组后，您就能够通过将测试脚本（录制）附加到这些组上，分解所有组间的分配。
请注意：
用户组和测试脚本之间的关系是 1:N。换句话说，一个用户组能够运行不止一个的测试脚本。至于工作量的分配是按照用户的绝对值还是相对比例，完全取决于您。
然而，要仿真一个实际生活的场景，仅仅将工作量在不同的组间分配对于反映一个好的测试场景来说并不是必须的。为了克服这一点，Rational Performance Tester 提供了不同的元素，您能够将它们同一个测试调度关联起来。无论调度中是否包括这些取决于您正在测试的场景。这些元素被直接关联到一个调度中。图21中描述了能够被包括在一个调度中的某些元素。
您能够将这些元素添加到一个测试调度中：
- 测试脚本（录制）：在它被录制之后，您能够将测试脚本指派到调度中。一个调度能够拥有不止一个通过不同的用户组被直接指派的测试脚本，这是因为每一个用户组都能够拥有不止一个的测试脚本。
- 组和百分点指派：它用于分解工作量的用户组。它包括设置开始运行的用户数量的能力。例如：50位用户在 T1 时间点开始运行。
- 用户思考时间：要仿真典型的思考时间，需要设置如下四个选项：
- 被录制的思考时间；
- 固定的思考时间（默认是2秒钟）；
- 动态增加或者减少思考时间的百分点；
- 随机设定思考时间的百分点。
- 延迟时间：您能够包括两个用户运行之间的延迟时间（单位是毫秒）。任何一种实际生活的场景都很难达到一个高的、真正的并发（例如，20位用户在 T1 时间点精确地同时运行）。通常来讲，50-100毫秒的延迟时间都属于正常的范围。如果您将延迟时间设置为100毫秒，那么这意味着一个用户（虚拟用户）在 12:00:00:00 开始运行，第二个用户在 12:00:00:01 开始运行。
- 循环：它用于以一个规定的比率运行测试。从 Schedule Element Details 面板中，您能够设置迭代的数量，并且控制迭代的比率（例如，每两秒中一次）。您还能够随机化迭代之间的延迟。
- 随机选择器：在现实生活中，应用程序页面击中通常是随机的。这个元素用来通过添加随机选择器，为一个测试运行序列提供随机选择，而不是按照测试顺序地运行。在随机选择器的设置期间，要求输入权重。在后面的操作中，您将把权重同一个测试脚本相关联。
- IP 别名：它使您能够对每个拥有一个专用 IP 地址的虚拟用户进行仿真。
本系列文章的第二部分将更加详细地解释这些元素。
性能测试的目标就是通过为所有涉及到的组件收集分析数据，识别性能的瓶颈。这包括应用程序等级性能监控，例如应用程序服务器级别instrumentation for IBM® WebSphere® Application Servers（版本5或者更高的版本），以及 BEA WebLogic Version 8 或者使用面向应用程序服务器的 Application Response Measurement (ARM) API 的数据收集，例如 JBoss、Apache Tomcat 等等。另外，数据库等级监控可以是 ARM 激活的。在这种意义下，所有的数据库活动都能够被收集和显示为 UML 顺序图。启用现实生活的应用程序监控仅仅是性能测试监控的一个方面。数据收集的这些级别（应用程序和数据库等级）在不具备收集服务器端资源级别监控（应用程序的各个组件正是运行于此）的情况下是无法完成的。
IBM Rational Performance Tester 支持三种以上默认的实时资源水平监控方法，其中包括：
- IBM® Tivoli® Monitoring
- UNIX® 或者 Linux®
rstatd后台程序 - Microsoft® Windows® Performance Monitor (perfmon)
作为一个例子，如果要使用 Windows Performance Monitor 进行监控，您就需要启用资源监控。按照以下步骤收集 Windows Performance Monitor 的分析数据。
- 选择调度；
- 在Schedule Element Details面板中，点击Resource Monitoring标签；
- 勾选选项Enable resource monitoring，如图22中所示；
- 对于一个新的安装，点击New添加它。您还能够将一个现已存在的服务器添加为被监控的，或者从之前定义的服务器中进行编辑。
- 在您点击Add New之后，您就能够在Location标签下输入您的
username和password。 - 然后，您能够在Resource标签下选择您所希望的statistics，如图23中所示，并且在Options标签下选择polling和time-out intervals。
请注意：
如果要通过 IBM Tivoli Monitoring 和 UNIX （或者 Linux）的 rstatd 进行监控，您就必须确保在它们被连接之前就已经启动并且运行。除了实时系统监控之外，您还能够从 IBM Tivoli Monitoring 将历史数据导入到一个性能报告之中。例如，从菜单中选择File > Import，然后选择Profile和Logging > Resource Monitoring Data。下一幅屏幕将允许您指定 Tivoli 监视服务器。现在，您只能够导入 IBM Tivoli Monitoring 历史数据，如图24中所示。
使用 Rational Performance Tester 的好处之一就是在线（以及不在线）分析报告能够被生成出来分析性能，以及工具找出特定问题的根源的能力。默认的报告远不止通常的目的。如果需要更加高级的报告，您就能够定制分析报告，从而为更加深刻的洞察性能问题生成更加有意义的、深入的报告。在 IBM Rational Performance Tester 中提供四种类别的 HTTP 报告：
- 性能报告
- 页面元素报告
- 百分点报告
- 确认报告
请注意：
不同性能报告的细节将在本系列文章的第 2 部分中进一步阐述。
性能报告由高级别的报告组成，例如全部运行成功率、一个显示全部已完成用户的概要页面、流逝的时间总计、所有页面的平均响应时间，等等。在线性能报告为方便定位被显示为不同的格式（9个标签）。例如，图25中显示了响应与时间的概要格式。
页面元素报告，一个5个标签的报告，由其自己的默认分析报告集组成，例如 Response vs. Time Details 和 Page Element Throughput。图26中显示了一个典型的页面元素吞吐量报告。
百分点报告，一个4个标签的报告，显示了同页面响应时间相关联的百分点范围。它所提供的默认报告包括概要和 85th、90th 以及 95th 百分点。这一报告类型通常被用于决定异常的情况，例如页面活动中的震荡。通过关联百分点和页面，数据能够在每个页面级别上被集合以识别那些关键百分点的页面行为。这些报告是一种表达 85% 的页面在X毫秒内被完成、90% 的页面在Y毫秒内被完成等的方式。您能够创建百分点和页面响应时间之间的关系，以便它为您提供保障 85% 的页面能够在指定时间内被响应。然后，通过将报告同百分点报告进行可视化的比较，您就能够轻易的看到任意时刻异常事件发生的情况。
图27捕获了 85th 百分点，而且对于一个页面来说，精确捕获到 90th 和 95th 百分点也并不是一件不寻常的事情，它意味着事情都进展的很顺利。如例子中所示，85% 的用户都在 16,954 毫秒内完成 Yahoo! Entertainment 页面的下载。
验证点报告，一个3个标签的报告，为页面提供了“通过”或者“失败”的状态，以便进行确认。确认是测试脚本下面的 Test Content 下面的集合。它是一种判断页面请求是“通过”还是“失败”测试的方法。测试的内容可以是 HTML 页面标题、HTML 返回代码、以及 HTML 响应大小（请参见Windows > references > Performance Test Generation > Verification Points）。验证点能够为每一个页面打开，如图28中所示：
页面验证点报告列出了每一个页面及其相应的“通过”或者“失败”率，以及百分比通过率。一个例子“页面验证点”报告显示了完成的页面的通过率。在图29所示的例子中，没有失败的页面；因此，通过率是百分之百。
除了这四个报告，您还能够挖掘到页面级别，以便更好的理解基于页面级别的响应时间。
- 挖掘一个页面，选择Page Performance默认性能报告中的标签上的一个页面（垂直工具条），并且右键单击选择Display Page Element Responses。例如，图30中显示了 My MTV Movie Awards '07 页面，以及 Breaking News on Yahoo! 被选中用于挖掘。
图 30. 页面元素响应，步骤一
图 31. 页面元素响应，步骤二
Rational Performance Tester 还能够使您执行根本原因的分析。这在两个方面获得便利：资源使用（正如前面所提到的）以及代码执行统计表。此处，您从性能报告中能够得到一个响应时间分解报告。这允许您在预定的测试期间从页面元素中分析统计表，或者从外部工具中分析任何导入的历史数据。响应时间分解为您所测试的系统显示了诸如每一项元素的周期等细节。每一个页面元素都被同统计表中的一个入口关联起来。在获得响应时间分解之前，您必须选中Response Time Breakdown选项：
- 选择包括测试脚本的调度，然后选择Schedule Element Details > Response Time Breakdown。
- 在Quick Links下，勾选Enable collection of response time data复选框。
- 最后，为适当的录制选择复选框。
- 确保 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 获得更多细节，尽管该选项并没有被显示在这里。）
通常来讲，响应时间分解是在开发环境中被捕获的。在它被启用和配置用来收集数据的量（低、中、高）之后，并且数据收集器基础构造被安装和运行之时，您能够通过以下几种方式收集数据：
- 从一个标准的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中所示的错误。
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 透视图。
- 多个视图：CVS Console、CVS History 和 CVS Repository。
- 同步与融合：
- 同步是一种通过知识库检查本地工作台之间差异性的一种方式。它允许您在您的本地工作台中更新资源，并且将资源从本地工作台提交到一个知识库中。
- 融合使您能够在资源冲突时找到折中的方案。
同 Rational ClearCase LT 的集成引入了在工作台中共享工作资产的功能，或者资产的并行开发功能。任何人都能够通过检入和检出工作区域共享测试文件，任何团队成员都能够在任何时间对其进行更新。通常来说，个体将本地工作于团队项目的一部分，他们通过同步工作台中发生的任何变化来核对其他人的工作。简而言之，所有的工作都是由一个本地个体所完成的，只有在这个人将它们通过提交到知识库中发布之后，它们才能够被共享。当您已经将变化提交到分部时，变化将会从您的本地工作台被拷贝到分部中。
基于功能性的需求，有许多不同的分部，例如并行运行的每一个项目都有一个分部。同样的道理也适用于处理不同的分部。您将通过首先同步您的工作台，检查其他人的工作。为了进行同步操作，IBM Rational Performance Tester 配备了一个 Team Synchronizing 透视图，以便更加容易的进行定位和管理。有以下四种与同步相关的模式：
- 流入：显示 CVS 知识库中与本地工作台不同的资源（只是流入改变）；
- 流出：显示本地工作台中将被修改的资源（只是流出改变）；
- 流入/流出：显示流入和流出改变的结合；
- 冲突：显示冲突的资源。当知识库中具有比您正在工作的资源更加新近的副本时，资源就会发生冲突。资源冲突的问题可以通过融合技术解决。丢弃您的工作或者其他人的工作也许并不是一个好的选项。
IBM Rational Performance Tester 首先是一个交互式的 GUI 测试器，它使初学者也能够轻松的执行加载测试。然而，有时侯也需要添加定制代码，从而实现更高级的测试方法。
定制代码选项以绿色字符C作为图标。您可以在测试脚本中的任何位置插入定制代码。图36中显示了两段即将被插入的定制代码的片段。当您第一次插入定制代码的时候，将自动生成一个类名称。不过，如果您愿意的话，可以将其重新命名为有意义的字符串。
当定制代码被插入之后，您就能够立即通过转换到 Java 源代码视图来输入代码逻辑（点击View Code）。此外，您还能够将透视图改变为 Java Browsing。另外，内联的 Java IDE 允许您调试您的代码。
系统提供两个接口：CustomCode2和ITestExecutionServices，用于扩展测试执行（提供一个完整的 Javadoc）。下面的场景就是扩展测试执行的典型用例：
- 控制循环行为；
- 运行一个已经存在的调用外部程序；
- 找到一组用户或者一个用户的 IP 地址；
- 设置和清除用户的访问消息
- 从用户数据区域中获得信息；
- 将一个页面同另一个页面关联起来。
跨越地理边界为每一个远程分布的测试迭代动态地测试用户负载并不是一种通常的做法。典型的测试方法，即每一项测试都被限定在一个位置上，也许对地理分散的开发团队来说并不具有灵活性。除此之外，跨边界共享测试资产的能力，Rational Performance Tester 使您能够通过一个广域网（WAN）跨越不同的地理位置来执行负载测试。由于服务器可能是地理上分散的，所以远程执行的能力与较低的硬件要求的结合，使得您能够使用 IBM® AIX®、Linux、Microsoft® Windows® 和 z/OS 等操作系统配置远程服务器。
例如，您可能拥有五个低端的服务器，它们从新加坡仿真5000位用户，另外有三台服务器从香港仿真3000位用户，等等。这种测试方法不仅产生更加逼真的测试效果，而且降低了测试的成本，这是因为测试结果可以由团队共享和分析，而且空闲的服务器能够被更好的加以利用。
最低需求，例如每个虚拟用户拥有一个 CPU 和 1MB 的内存（通常来说）首先依赖于测试页面的复杂性。有些因素能够增加每位虚拟用户的内存容量。您能够通过仿真实际的场景获得更高的缩放比例，例如为每位用户使用思考时间和延迟时间。通常来说，将额外的负载放到管理员服务器上并不是一种很好的做法，这是因为与工作台相关的活动需要服务器中的资源。
在您捕获测试脚本之后，扩大虚拟用户的范围就是添加更多的用户组。Rational Performance Tester 通过允许您添加更多的用户组以及指派用户的绝对值数量或者百分点数量，从而无缝的掌控缩放比例。只要测试实例依旧完整的话，我们就无需重新捕获测试脚本。
中央管理部门允许一个集中的视图和管理，只需少量的管理成本就能够管理远程测试系统。管理本地测试服务器和远程测试服务器所花费的精力实际上是一样的，这是因为远程服务器并不必掌控本地服务器复杂。图38中显示了将远程服务器纳入测试服务器是多么的容易实现。
在本系列四篇文章的第 1 部分中，我们查看了由 IBM Rational Performance Tester 所提供的各种各样的功能。包括易于使用的 GUI 管理、报告特性、以及可量测性。尽管这些内容仅仅是被简要的概述，但是本文为您提供了一幅功能的鸟瞰图。您能够使用从这一简要介绍中所获得的知识加深对 IBM Rational 软件交付开发平台中的软件选项的负载测试工具的理解。
在第 2 部分和第 3 部分中，您将学习一个完整的负载测试周期。在第四部分中，您将详细看到包括在 Rational Performance Tester 中的许多报告及其变种，并且学习如何根据您的特定需要对它们进行定制。
TAG:
-
引用 删除 colorfulbinary / 2011-09-15 11:20:09
-
评 5 分
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | 6 | ||||
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | |||
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | |||
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | |||
| 28 | 29 | 30 | |||||||
我的存档
数据统计
- 访问量: 52149
- 日志数: 30
- 文件数: 2
- 建立时间: 2009-02-01
- 更新时间: 2012-03-15
