基于 Rational Performance Tester 的持续性测试

　　持续性测试(Long Run)在整个测试过程当中起着举足轻重的作用，通常被安排在测试的后期来进行。此时，软件或解决方案的基本的功能已经稳定，但是，有很多重要的问题，比如资源泄漏等都有可能在持续性测试中被发现。因此，持续性测试一般是软件发布之前的最后一道安全保障。Rational Performance Tester(RPT)是 IBM 性能测试的工具，具有灵活的基于 Http 的录制与回放功能，而且有着很好的用户负荷管理功能，又提供了大量的 API 可以方便使用者自定义附加功能。本文就介绍了利用 Rational Performance Tester 来进行持续性测试的一些方法和技巧。

　　1. 持续性测试介绍

　　1.1 持续性测试(Long Run)的基本概念

　　持续性测试(Long Run)是被测产品或解决方案上线之前的简单性能测试阶段，模拟一定程度的并发用户进行基本的操作，并持续超过 24 小时(持续时间可以依据产品和解决方案的非功能性需求而定)，来测试产品或者解决方案的稳定性，包括使用资源的稳定性，响应时间的稳定性等，是属于性能测试的一部分，通常发生在性能测试接近尾声的时候。持续性测试很难由手工来完成，通常需要借助自动化测试工具 如 IBM Rational Function Tester 等，或者借助性能测试工具 如 IBM Rational Performance Tester 等来完成。

　　持续性测试是众多测试类型中的一种，在持续性测试中，实际客户的惯用操作被模拟，通过长时间的执行来检测程序运行所占用的系统资源是否稳定(系统资源包括物理内存、CPU、硬盘使用率、网络流量、数据库连接数、网络连接数等)。在实际的测试过程中，通常使用高于生产环境的等价用户负荷来进行持续性测试从而争取更早的发现问题。持续性测试的执行时间会根据待测软件或解决方案的复杂程度和应用程度不同而不同。但通常不会少于 1 天。

　　持续性测试被安排在软件测试流程中的后期，此时软件的功能已经趋于稳定，不会有太大的变动。同时，持续性一旦被执行，就需要等待他执行完预计的时间或者直到由于软件问题导致测试脚本无法继续执行下去。

　　1.2 持续性测试的重要性

　　应用软件或者解决方案当中有些问题是无法在功能或者系统测试中被发现的，比如少量的系统资源泄漏或者长时间运行系统的不稳定性等问题。在功能或者系统测试中，由于侧重点的不同，同一个功能点也许只被验证几次，但是在持续性测试中，同一个主要功能点可能被重复千次甚至万次。所以，细微的资源占用问题也将会被放大。这就是在任何的产品上线之前都需要通过持续性测试来保证系统主要功能的正确性和持久性。

　　当然，通过持续性测试并不能发现隐藏在程序代码中的所有问题，因为持续性的测试用例基本会选取用户经常使用的或者比较重要的操作用例。因此，一些异常流程导致的资源泄漏等问题将不会被发现。但是持续性测试会通过最大程度的模拟产品上线后用户的操作来尽量发现隐藏在软件中的细微资源泄漏等问题。

　　1.3 执行持续性测试的工具

　　根据持续性的测试特征可以选取不同的测试工具来执行测试用例，可以选择 RFT(Rational Function Tester)，Watir 等自动化测试工具，也可以选择 RPT 等性能测试工具，也可以自己开发程序或者脚本来执行持续性的测试。

　　相比于 RFT 等自动化测试工具，RPT 具有更好的多用户负荷管理功能和基于 Web 的页面响应时间等性能结果分析，更适应于基于 Web 应用的多用户系统持续性测试的执行。

　　本文就以一个基于 Web 的应用为例，为大家介绍如何使用 RPT 来设计，开发和执行持续性测试。

　　回页首

　　2. 设计基于 RPT 的持续性测试用例

　　在 RPT 当中，测试用例的基本单元是通过录制而生成的测试项。将测试项按照不同的顺序组织起来，并添加一些分支或者循环的过程控制从而生成测试调度。通过 RPT 提供的数据池的功能来完成多用户各自的数据存储。同事还可以在测试项中添加自定义的代码来实现特定的功能。

　　通过执行测试调度来执行持续性测试，因此在测试调度中的循环控制次数需要大到不会在指定的执行期间之内结束，通常选用无限循环模式。

　　实际的基于 Web 的应用大多都是多用户分角色的，因此，在设计基于 RPT 的持续性测试用例时，有以下需要注意的地方。

　　将包含在持续性测试范围内的功能点按照不同的用户角色进行分类，尽量设计端到端的测试用例来模拟用户在生产环境上的应用。在设计过程中，将功能点分散到不同的用户角色上，使所有持续性测试范围内的功能点都被用例覆盖到。

　　划分测试项。测试项是 RPT 测试用例中的最小单位。一个测试项应尽量完成最少但完整的功能，如果一个测试项完成的功能太多，太复杂则会导致测试项脚本非常大，而且还不方便维护，

　　根据不同的用户角色来区分 RPT 中的用户组，每一个用户组由多个测试项组合而成，完成为该用户设计的测试用例中包含的多个功能。

　　不同用户之间在测试中用到的数据通过 RPT 数据池来获取，这样保证了用户运行时的数据与控制逻辑相分离，可以大大的减少测试脚本的维护成本。

　　在持续性的测试脚本执行期间并不需要很高的吞吐量，因此，要适量的在测试项之间添加延迟，来缓解程序服务器的压力。

　　如果由于用户过多导致 RPT 服务器的系统资源紧张，需要将部分的用户分散在 RPT 代理上执行来分担 RPT 服务器的压力，避免由于测试工具服务器的资源问题影响测试结果数据。

　　完成了 RPT 中测试项的划分，测试调度的设计和测试用数据的设计之后便可以开发基于 RPT 的测试脚本了，下一章便介绍了在开发基于 RPT 的持续性测试用例中的经验总结。

　　回页首

　　3. 开发基于 RPT 的持续性测试用例

　　3.1 分功能段录制脚本

　　通常使用 RPT 录制测试脚本时，我们会将整个的场景录制在同一个脚本中，复杂的脚本会包含几十个甚至上百个页面。这样，RPT 会建立起页面间数据复杂的关联引用，即不利于维护，又会造成有时无法正常回放的隐患。

　　为了更好的复用测试脚本，可以分段录制业务场景的脚本，然后组装起来覆盖所有需测试的业务场景，他们之间的数据关联用自定义代码实现。下面是一个实例场景，分为三小部分(登录，业务逻辑操作，注销)，录制成三个独立的脚本。操作步骤如下：

原文转自：http://www.ibm.com/developerworks/cn/rational/r-cn-rptlongrun/index.html