基于 IBM Rational Build Forge 的自动化性能测试

　　概述

　　敏捷开发(Agile development)是一种以人为核心、迭代、循序渐进的开发方法，开发周期一般是两星期到四星期。性能测试从环境部署、数据准备到测试、分析，是个工作量巨大的工作，如何才能在很短的迭代周期内完成产品的性能测试，尽早尽快的发现和验证产品的性能问题，是敏捷开发环境中实现质量保证的关键。IBM Rational Build Forge(RBF)是业界领先的自动话流程执行软件，可以集中、自动化并且加速不同软件开发组织的软件开发过程。本文将介绍如何使用 RBF 来实现自动化性能测试。

　　回页首测试环境部署

　　云计算，是当今 IT 业界最炙手可热的话题。云计算技术的应用使得测试环境的部署自动化成为可能。当测试者需要申请一个资源时，云计算部署平台会自动创建一个虚机，预装测试者所选择的需要的软件，并对虚机进行管理。我们使用的部署平台基于 TSAM(Tivoli Service Automation Manager)，它是 IBM 目前实施云计算解决方案的一个成熟的核心平台。图 1 描述了如何借助 TSAM 和 RBF 将 CLM3.0.1 部署到虚机的步骤。

　　图 1. RBF 驱动的云计算平台测试环境部署

　　登录 TSAM 的服务请求控制台，选择“Create Project with VMWare Servers”，输入要创建的项目的基本信息，包括名称、访问权限、项目描述和项目的起止时间，也就是期望在哪个时间段使用项目中的虚机。

　　图 2. 在 TSAM 中创建项目

　　选择需要预装的操作系统，调整虚机所需要的资源，包括 CPU、内存、硬盘大小等，并选择需要预装的软件，如图 3，为了方便后续基于 RBF 的性能测试的自动化，此处需要预装自定义的一个软件包 Build Forge Integration prep, 其中包括供 RBF 服务器调用的代理。还要预装软件安装程序 IBM Installation Manager (IM). 值得说明的是，需要预装的操作系统和软件包并不是 TSAM 的默认功能，需要自行基于 TSAM 开发实现自定义。

　　图 3. 输入测试环境的相关参数

　　确认后，TSAM 就会自动生成所需的虚机。系统自动发邮件告知测试员该虚机的用户认证信息。至此，我们完成了通过 TSAM 实现自动部署虚拟机和预装软件包的阶段。下个阶段就是使用 Build Forge 平台部署要测试的产品。

　　登录 RBF 系统，选择库 CLM-E2EProductDeploymentWithWASAndDB2，如图 4，该库实现 CLM 产品在 DB2 和 WAS 系统上的安装，测试员只需要输入刚刚生成的虚机的主机名、密码，并选择需要安装的 CLM 的版本号或者开发阶段的 build 号，选择虚机生成过程中根据主机名在 BF 系统中自动生成的 selector，系统就可以自动开始执行库中的各个步骤：安装 DB2, 安装 WAS，安装 CLM，并完成安装后的配置工作，包括 LDAP 配置等。

　　图 4. 部署待测试产品

　　图 4 大图

　　性能测试往往会涉及不同的平台，只要开发适合测试需求的 RBF 脚本，就会实现测试环境部署的自动化。由于 Agile 开发的测试周期短、产品版本推出快，这个步骤的自动化可以大大节约测试人员用于测试环境部署的时间。

　　回页首性能测试执行

　　CLM 产品的测试使用测试工具 Rational Performance Tester RPT)，但又不仅仅是 RPT 测试或调度的运行。它包括测试环境准备、测试运行、测试结果搜集和测试结果分析。开始测试前，测试人员要将测试数据恢复到一个符合测试要求的“干净”的状态;然后，启动数据库服务器、应用服务器，打开性能监视工具，启动 RPT 中测试的执行，等到执行结束后，要关闭服务器并搜集日志。如果测试环境是个集群系统，这些工作需要登录到不同的机器上执行，不但耗时而且会容易出错。而一旦出错，测试者就不得不解决出现的问题并将待测试的系统恢复到测试前的状态或者正常的状态。在性能测试中，一个测试场景通常需要在不同用户负载和数据负载下执行，以寻找性能瓶颈，或和前一个阶段的性能数据进行比较。而每种负载的测试需要执行多遍以保证测试结果的稳定性。所以，性能测试的工作量可见一斑。通过对不同项目的性能测试员的调查发现，测试执行要占整个测试工作量的 50% 以上。如果这个过程能够实现自动化、标准化、流程化，测试人员会能节约大量的时间以将精力用于性能问题的分析和解决上，减少人为操作的失误。

　　我们开发了 RBF 项目 Run Performance Test 来自动化一个单次的性能测试执行，步骤 2 到 8 为测试准备阶段，其中，第 2～3 步关闭应用以便于后续恢复数据的操作，第 4～5 步恢复并重启数据库，第 6～7 步恢复产品在本地文件系统中的信息，第 8 步启动应用服务器;第 10～11 步为测试执行阶段，第 10 步开启服务器性能监视工具，第 11 步用命令行方式启动 RPT 中的测试调度;从第 12 步开始测试运行结束，第 12 步关闭性能监视工具，第 13 步关闭应用服务器，第 14 步搜集测试过程中产生的 RPT 性能报告及服务器日志以便于性能分析，见图 5。

　　图 5. Run Performance Test 项目

　　如前所述，性能测试经常需要在不同负载下重复某个 RPT 调度的执行或者重复多次同样的测试运行取得稳定的结果，为此，我们开发了个 Back to Back Runs 项目来组织整个测试的执行。见图 6，每个步骤代表一个单次的性能测试，需要指定的是要执行哪个 RPT 的调度、要怎样监控服务器的性能、要加载的用户数和数据量等。这些每次测试中不同的部分可以作为 RBF 中的环境变量，如图 7 所示，这样，在每步中调用项目 Run Performance Test 就可以实现测试调度的连续运行了，图 7 的例子中，我们调用三次同样的运行来获得最稳定的测试结果。至此，性能测试就可以实现不加干涉的自动化执行，即使是在非工作时间。

原文转自：http://www.ltesting.net