Performance Tester和LoadRunner的比较
两款同样都是比较主流的商业性能测试工具，可能LoadRunner的市场占有率和流行程度更高一些，有意思的是这篇比较的文章出自IBM工程师之手，转载过来，供大家进行工具选型的时候参考。
以下转载自：http://www.ibm.com/developerworks/cn/rational/r-cn-rftloadrunner/
本文概要介绍 IBM Rational Performance Tester （简称 RPT）和 HP Mercury LoadRunner （简称 LR）两个性能 / 压力测试工具，主要从脚本开发，场景构建与配置，性能监控，测试结果分析几个方面，对 LR 和 RPT 的使用做了详细的对比分析，并根据 IBM Lotus Form. 系统测试团队从 LR 到 RPT 的迁移的工作经历中总结了一些 RPT 的一些实用技巧。对于那些需要从 LR 工具切换到 IBM RPT 的测试人员的测试技术的平滑过渡，具有较强的借鉴意义。
LoadRunner 是一种适用于各种体系架构的自动负载测试工具，通过模拟实际用户的操作行为和实施实时性能监测，来帮助用户排查和发现问题。相比于 RPT, LR 能支持更广范的协议和技术，适应面很广，为用户的特殊环境提供特殊的解决方案。LR 的组件很多，其中最核心的组件包括：
- Vuser Generator(VuGen)用于捕获最终用户业务流程和创建自动性能测试脚本
- Controller用于组织、驱动、管理和监控负载测试。
- Load Generator负载生成器用于通过运行虚拟用户生成负载。
- Analysis有助于您查看、分析和比较性能结果。
IBM Rational Performance Tester（简称 RPT）也是一款性能测试工具，适用于基于 Web 的应用程序的性能和可靠性测试。Rational Performance Tester 将易用性与深入分析功能相结合，从而简化了测试创建、负载生成和数据收集，以帮助确保应用程序具有支持数以千计并发用户并稳定运行的性能。
- RPT 是针对 Web 应用程序的性能测试工具，基于 Windows 和 Linux 的用户界面，使用基于树型结构的测试编辑器提供高级且详细的测试视图。
- 提供不同用户数的灵活的模拟，支持将 Windows 和 Linux 用作分布式负载生成器，使用最小化的硬件资源实现大型、多用户的测试。
- 支持使用自定义 Java 代码的灵活测试定制。
  |
|
LR/RPT 的脚本的开发过程通常都是采用录制 + 定制的模式。首先通过对典型业务逻辑的录制，完成脚本中的基本业务的框架，然后针对录制结果，通过参数化，数据关联，增加逻辑控制等方式加强脚本的适应性来满足特殊的业务需求。
- LR：直接生成面向过程的运行代码
LR 通过对基本业务的录制，VuGen 将生成的 Vuser 函数（也称作 LR API）并将他们插入到脚本中。在实践中，LR 脚本就是由这样的 Vuser 函数和一些定制代码组成的。对于基于 Web(HTTP/HTML) 的应用程序的测试，多数用户选择基于 C 语言的 LR 脚本，显然，这种 LR 脚本是一种面向过程的脚本，开发者可以对最终运行的脚本进行直接的修改与调整。对于开发者来说，这种 LR 脚本的开发方式比较灵活。相应地，这项工作，对于开发者的编程基础，尤其是 C 语言和 LR API 的了解，要求都比较高。
- RPT：录制结果经过“翻译”生成最终的运行代码
与 LR 不同，RPT 的脚本录制过程可以拆分成两步。如图 1 所示，第一步，RPT Recorder on RAC 负责记录用户的所有 HTTP 请求，生成一系列的 Trace 文件。Trace 文件记录了用户与服务器的交互过程。第二步，当用户完成脚本的录制过程之后，RPT Test Generator 能够根据 Trace 文件“翻译”一遍，生成最终运行的测试脚本。
这种生成临时 Trace 文件的好处是用户可以随时依据该 Trace 文件生成新的测试脚本，然后再对脚本进行测试场景定制，而不用对同一个操作过程做多次录制操作。
图 1. RPT 脚本的录制和生成架构
2.2 参数化
录制业务流程时，LR/RPT生 成一个包含录制期间用到的实际值的脚本。假设用户要使用不同于录制内容的值执行该脚本的操作时，就需要用参数替换已录制的值。这被称为脚本参数化。脚本的 参数化可以简化脚本，同时增强脚本适用性。对于 LR 和 RPT 脚本，参数化过程类似，都是定义参数，为参数指定属性或者数据源的过程。但是在 LR 中，只有函数中的参数才能参数化，除此之外，其他字符串不能进行参数化。
RPT 的参数化过程同样简单（以替换用户登录密码为例来说明），首先，选中需要进行参数替换的请求页面，如图 2 所示，选中左侧的登陆请求页面。在其右侧的 Test Data 中则显示与该请求页面相关的所有数据信息，脚本录制人员可以用其他值代替图 2 中的 password 变量。
图 2. RPT 脚本参数化
2.3 数据关联
数 据关联类似于参数化，可以简化脚本，适应企业应用中需要动态数据的情况。默认情况下，LR 和 RPT 都能做到一些基本的数据关联，但是由于 HTTP 请求之间关联的复杂性，需要用户手动做一些数据关联。数据关联包含三个步骤，一是定义哪个录制的值需要被关联（替换）；二是定义数据源。三是定义被关联的 数据与数据源之间的关联关系。
LR 的数据关联过程如下：lr_save_XXXX（value,dataSource）语句将数据源的值保存到参数dataSource中；用lr_eval_XXXX（dataSource）语句替换被关联的数据。
RPT 中如果需要自己定义关联，则在 HTTP 请求中的 URL 中或者 Data 中选择需要创建关联的部分，然后右键选择替换对象。其中替换对象可以是脚本中已经建立好的引用（这里的引用就是一种用户自定义的数据源），或者 RPT 自带的数据源（例如时间戳对象），或者是Custom Code( 下节介绍 )。
图 3 中浅紫色的部分是已经被关联的 URL，运行测试时该部分将由被引用的 URL 值来替换该 URL。
图 3. RPT 数据关联
2.4 Custom code
Custom code 是 RPT 独有的概念。尽管 RPT 脚本开发过程中，用户可以直接在 UI 层面达到对脚本的定制，但是这种定制能力毕竟有限。将定义好的 Custom Code 通过 UI 穿插到脚本之中，从而为 RPT 录制的脚本提供充足的扩展能力来保证其灵活的定制性。Custom code 本质上就是一个 Java 类。Custom Code 需要实现com.ibm.rational.test.lt.kernel.custom.ICustomCode2接口，并实现该接口中的如下方法：
public String exec(ITestExecutionServices tes, String[] args) |
ITestExecutionServices tes参数是 Test Container 中的一个实例 , 使用它可以访问 Test Container 运行态一些服务。
String[] args参数是我们定义 Custom Code 时定义传入的参数数组。
该 方法的主体就是基于传入的信息进行业务逻辑处理代码，然后将处理结果（一个字符串）返回，其返回的字符串可以被后续的请求引用。Custom Code 是一个纯 Java 的类，所以具有 Java 编程经验的人都可以根据业务需求编写自己的 Custom code。
性能 / 压力测试过程中，通常都需要为某些测试提供大量的测试数据。LR 和 RPT 都提供了数据池功能，即是将一个数据文件作为参数值赋给一个参数。
LR 中，用户可以指定该文件的多个数据以何种方式赋值到该参数中。LR 提供三种选择，顺序，随机，唯一。前两种比较容易理解，最后一种是指每个虚拟用户都从该文件中取不同的值作为参数值，如果该数据池不足够大，所有的备选值 都已经被取出过一次，即该数据池资源被用尽时，LR 报错。
在 RPT 中，用户只能顺序从数据池中读入测试数据。RPT 的数据池是以 XML 格式存储的，并且在测试开始时，将数据池中的所有数据都加载到内存中，这样的实现模式不利于测试中使用大数据量。不过灵活的 Custom Code 功能可以弥补这方面的不足。对于大量的测试数据，可以通过自定义 Custom Code 来实现 On Demand 的数据读取和加载。
图 4. RPT 数据池
http://hhrj.taobao.com
2.6 流程控制
LR 脚本大部分是基于 C 语言的，因此 C 语言中的流程控制语句（例如判断、循环等）都可以加入到 LR 脚本中。RPT 的流程控制操作可以通过 UI 界面轻松进行，它提供了灵活的流程控制模式，包括 IF 条件控制结构，和 LOOP 循环结构。
1. IF 条件控制结构
在 RPT 脚本中，可以将一部分连续的页面或者 HTTP 请求放到一个 IF 条件中去，然后由判断条件来确定 IF 结构中的页面或者 HTTP 请求是否被执行。其判断条件可以是 RPT 自动参数化后的参数，也可以是 Custom Code 的返回值，或者是数字、字符串等。
图 5 是添加了 IF 条件后的脚本，包含了为 IF 语句设置判断条件的配置界面。
图 5. RPT IF 条件控制结构
同样，RPT 也支持 IF-ELSE 的结构。
2. LOOP 循环结构
RPT 中的另外一种流程控制结构就是 LOOP 结构，如图 6 脚本中，将所有的页面放到了一个 LOOP 结构中，然后可以通过指定循环次数来确定其中的脚本循环执行多少次。
图 6. LOOP 控制结构
2.7 全局信息
这里所说的全局信息，实际上是脚本运行时，LR/RPT 产生的内部数据，例如：当时的运行时间，Vu 所在用户组组名，迭代编号等。在 LR 中，所有的全局信息作为特殊的参数类型，供脚本开发者使用。例如 : 如果一个变量为Group Name类型，则该变量的值即为当前用户所在的用户组的组名。
RPT 中的全局信息，存在IDataArea对象中。IDataArea 对象包含三个方面的信息，分别是“Test Data”、“Virtual User Data”、“Engine Data”，这些信息都可以通过 Custom Code 来获得。
Custom Code 的实现需要继承ICustomCode2类，并实现该接口的核心方法“public String exec(ITestExecutionServices tes, String[] args)”，该方法的第一个参数就可以获得IDataArea对象，然后获得全局信息。同时用户也可以向IDataArea对象中添加信息，提供给测试脚本的其它地方使用。
LR 用户可以指定脚本执行期间的错误的处理方法。默认情况下，当脚本执行出现错误，脚本将退出执行。用户也可以配置运行设置指示当Vuser出现错误时仍继续执行脚本。除此之外，用户还可以在脚本中加入lr_error_message函数，便于用户对日志的分析。
RPT 中，当脚本运行出现错误，脚本将继续执行 , 可能后续会出现很多错误。
LR VuGen 可用作常规文本编辑器。您可以在其中打开任何文本文件并进行编辑。当重播期间在输出窗口中显示错误消息时，您可以双击该错误消息， VuGen 将使光标跳到导致问题的测试行。您还可以将光标置于错误代码上并按 F1 键，查看该错误代码的联机帮助 .
RPT 在运行完一个测试之后，会产生相应的测试日志，如果在测试过程中发生任何错误，RPT 会以“Message”的形式提示出该请求发生错误。如图 7 中的测试日志中被选中的 Message 表示该 HTTP 请求在引用前面的关联值时发生错误。
图 7. RPT 错误日志
|
|
3 场景构建与配置对比
脚本只是定义了某些用户的操作步骤，而一个场景则包含了有关如何模拟实际用户的所有信息。LR 和 RPT 的场景构建过程比较类似，只是对脚本循环的控制，分配负载生成器等配置上略有差别。
LR 中，Controller 组件负责场景的创建。您需要在一个场景中添加一个或多个脚本，并为每个脚本分配相应的 Vuser 组。然后，您可以为每个 Vuser 组分配多个虚拟用户，指定模拟该用户组的负载生成器。图 8 中，负载生成器即为本机，即负载生成器跟 Controller 是同一台机器，如果该处配置成其他计算机的 IP 地址，那么该用户组的负载模拟将由其他计算机完成。LR 中不能通过 Controller 指定一个脚本执行与否的概率，但是可以通过 C 语言开发，完成随机调用脚本的功能。Runtime-Setting 包含了所有针对该场景的一些附加配置，如脚本循环次数，等待时间，网络模拟等。
图 8. LR 场景创建
RPT 中测试场景，是通过“Schedule”来组织的。Schedule 通过用户组、循环控制、随机选择器等功能部件来组织测试脚本使其满足实际场景。用户组则由循环控制或者随机选择器，再加上测试脚本等元素组成。循环控制用 来控制其下的测试脚本需要循环执行的次数。随机选择器是为了实现在多个测试脚本中随机选择一个来执行。可以为随机选择器指定权重，通过权重值来决定在多个 随机选择项中某项被随机选中的概率大小。图 9 是一个 RPT 创建场景的例子，其中“Schedule Element Details”提供了对 Schedule 的丰富配置功能，与 LR 中的 Run-Time 配置功能类似。
图 9. RPT 场景创建
RPT 的负载生成器配置也比较简单，首先选中要放到其它 RPT 主机上进行模拟的 User Group，然后在其配置界面中选中“Run this group on the following locations”，在其中添加远端的 RPT 主机信息。
图 10. RPT 负载生成器配置
|
|
LR 和 RPT 内部都集成了一些实时监控器，RPT 可以对事务，Web，系统，Web 应用服务器等资源进行实时监控。LR 的监控范围更广泛一些，除了上述资源之外，还可以对网络，防火墙，Web 服务器，数据库，ERP，Java 等资源进行实时监控。无论使用那种测试工具，在自动测试过程中的任何时间，用户都可以获知系统的多种性能指标的当前值和变化趋势。
在一个测试场景中，用户需要将被监控的服务器信息加入到资源监控列表中。LR 中，如图 11 所示，从左侧资源树中选择资源种类，在右侧对应资源状态显示窗口中，右键添加被监控的服务器名称。
图 11. LR 添加被监控的服务器信息
RPT 中，图 12 所示，用户需要在 Schedule 的配置窗中的“Resource Monitoring”标签栏添加需监控的服务器。
图 12. RPT 添加被监控的服务器信息
|
|
LR 和 RPT 都提供了测试结果的多种图表以及图表之间的叠加效果，方便用户分析测试结果。LR 中测试结果图表的生成由 Analysis 组件完成。默认情况下，用户可以直接看到测试的总体概要分析，吞吐率，事务平均响应时间等图表，如果用户希望看到其他资源的监控图，可以通过添加图表完成 （图 13）。“Merge Graghs”可以帮助用户将同一个测试结果中的多种资源的结果进行叠加（图 14）。“Cross Result”可以生成多次测试结果的比较分析图（图 15）。
图 13. LR 添加其他资源监控图
图 15. LR 多次历史测试结果之间的比较
RPT 也为测试结果提供了直观的图表表现，默认情况下，用户可以直接看到对测试成功率的总体柱状图，整个测试过程完成的总体信息列表，测试中页面的反应时间曲线图等报告。也可以通过添加其他监控信息的方法，将其他资源的监控图叠加到当前的监控图中。
图 16. RPT 叠加其他资源监控图
RPT 也可以实现多次测试结果的比较。在 RPT 的“Test Navigator”中选择待比较的测试结果，在其右键菜单中选择“Compare”，打开“Compare Results”窗口，然后将需要做比较的测试结果添加进来，在下一步中选择要显示的报告，点击“Finish”按钮打开比较结果的显示页面。图 17 是一个测试结果的比较报告。
图 17. RPT 多次历史测试结果之间的比较报告
|
|
6 Rational Performance Tester 实用技巧
1）调整日志采样频率和粒度以适应不同的测试场景
RPT 的 Schedule 提供了测试数据的采样频率和采样粒度的配置，以适应不同的测试场景。在做长时间测试时，在 Schedule 的配置面板中的“Statistics”标签中通过适当增加日志采样间隔时间、日志级别和采样用户量，降低 RPT 的压力，避免因采样数据量过大，使内存耗尽，导致 RPT 无法响应。
图 18. Statistics 配置
在 测试过程中，RPT 会记录测试中的请求数据和响应数据，以便在测试之后查看测试过程中的数据和错误信息。对于长时间测试，会产生大量的请求和响应数据，这些大量的日志信息会 让 RPT 不堪重负。在 Schedule 配置部分的“Test Log”标签中提供了日志记录的级别设置，对于长时间的测试，推荐使用图 19 所示的配置，记录错误和警告信息的级别为“All”，而对于其它信息则只记录“Primary Test Actions”即可。
图 19. LOG 配置
2）通过 Custom Code 实现多条测试数据的随机读取
在 RPT 中通常采用 DataPool 的形式作为少量测试数据（例如模拟多个用户登录所用的多个用户名密码信息）的输入。不过 DataPool 的读取方式为顺序读取。如果对于输入数据需要随机读取，则可以通过 Custom Code 来实现。其实现方式可以是将测试数据存为“*.cvs”等格式文件，然后通过文件操作，并根据随机数从文件中读取内容作为测试输入数据。
3）使用超大测试数据集文件
对 于在测试过程中存在少量测试数据分次作为测试输入数据时（例如模拟多个用户登录所用的多个用户名密码信息），通常采用 DataPool 的形式，但是在测试数据量较大时该方法就不再适用，因为对于 DataPool 中的数据，测试开始时就被全部加载到内存，如果测试数据量过大，这种方式会造成大量的内存浪费。
这种情况可以通过 RPT 提供的扩展功能 Custom Code 来定制代码，达到在测试过程中在需要的时候再去加载所需的内容，其实现也可以采用文件操作的方式。
|
|
本 文中，我们概要介绍了 RPT 和 LoadRunner 两个性能压力测试工具，从多方面对两个工具进行详细的对比分析，并根据实践经验总结了一些 RPT 的实用技巧。通过本文，并学习链接中的网站，希望您能更快，更多的了解和使用 Rational Performance Tester 工具。
