LoadRunner性能测试系统学习教程：工具介绍（下）

LoadRunner内部结构

LoadRunner主要通过控制内部程序的调度来控制整个性能测试过程，LoadRunner内部结构图如下图所示。该图详细地描述了LoadRunner执行过程中内部程序是如何调度的及内部各程序之间的关系。

从LoadRunner内部结构的层次来分析LoadRunner性能测试的过程。

1.首先准备好待测试的应用服务器和待测试的系统。

2.LoadRunner中多线程驱动进程mdrv.exe和r3vuser.exe模拟产生压力，其中r3vuser.exe仿真应用程序的客户端，如IE浏览器。它执行了以下三个主要的操作：

①cci（C语言编译器）建立ci文件，然后使用被测系统的协议来执行。

②通过Windows批处理脚本启动mdrv.exe程序从而启动LoadRunner的运行。mdrv能自动停止加载Vuser，因为它们与Vuser和Windows负载发生器上的CPU监视器之间互相通信。

③在Windows机器上，对于每一个基于Java的Vuser都有一个独立的JVM，注意UNIX平台不支持JavaVuser。

3.虚拟用户在负载发生器端的计算机上使用代理作为服务或进程时，按照组启动方式启动虚拟用户，用户组是多个Vuser组成的逻辑集合，在Vuser发生器上运行相同的脚本。

4.每个负载发生器（LoadGenerator）都维护着一个以qtp为后缀名的执行日志。

5.日志服务启动后，代理会根据用户组进行隔离，在结果文件中为每个虚拟用户建立一个顺序文件。

6.在执行过程中，这些文件会在“视图”→“显示”输出窗口中显示出来。

7在预先设置延时上，Controller上运行的Scheduler指导代理（通过Windows54345端口或UNIX上的动态端口）初始化场景会话；控制器（wlrun.exe）在发送请求时发送一份场景的拷贝。

8.代理是由每一个负载发生器上的RemoteAgentDispatcher进程（8.0叫RemoteCommandLauncher（RCL））启动的。

9.每个代理根据场景（.lrs）定义文件来决定哪个虚拟用户组和脚本需要在主机上运行，这就是说控制器可以从DOS批处理文件（.batch）中启动。

10.控制器通过使用Windows操作系统根目录文件夹里的参数值来启动，因为LoadRunner被设计成在一个机器上并且一次只能运行一个控制器实例，所以需要使用Windows文件夹。

为了在几个应用之间快速的切换，Controller工作之后会保存在LoadRunner的ini文件中，然后使用记事本来制作一个批处理文件，在执行wlrun之前拷贝应用程序的指定版本的ini文件。

11.在Vuser中定义的每个虚拟用户进行的操作都是LoadRunner的VuGen.exe生成的，当这个程序启动后，它在Windows文件夹下存储了comparamui.ini文件来保存[LastTablesUsed]下文件的历史，而[ParamDialogDates]项是由“插入”→“新参数”→“数据”来指定。

12.在运行期间，执行结果存储在一个结果文件夹中。

在结果中设置“为每一个设定执行自动创建结果目录”，这样LoadRunner会在每次启动一个场景之后自动产生一个递增的结果名。

例如，结果名称Res1会自动增长到Res12或是Res11-1，错误信息会写到MicrosoftAccess数据库文件output.mdb中。

13.在每一个结果文件夹中，程序自动创建一个Log文件夹，在这个文件夹中包含每个组的日志文件，运行结束之后，在Controller中查看日志文件，点击按钮然后在组中点击右键，选择“查看Vuser日志”。

14.场景运行的时候，监视器在本地维护每个主机的计数器。

15.场景运行结束后，进程处理.eve和.lrr结果文件并且在结果文件夹下创建一个临时的.mdb（M）数据库。在处理大数据量的结果时，为了防止错误发生，通常使用（MicrosoftAccess）数据库文件。

16.分析模块（8,320Kanalysisu.exe）使用.mdb数据库中的数据来产生分析图表和报告。

17.每次设定运行后的LoadRunner结果文件result_name.lrr（也称为分析器文档文件），由分析程序来读取并显示百分位图表。

18.默认情况下，LRReport文件夹被创建在本地分析机器的MyDocuments文件夹下用来存储分析会话文件。

19.可以使用HTML格式产生报告。

20.结果文件格式是由.tem模板文件控制的。

负载测试的结果可以使用Web浏览器来浏览了。

以上就是LoadRunnerr测试的全部过程。

LoadRunner11.0特性

LoadRunner当前最新版本为11.0版本，在11.0版本中主要新增了以下功能：

新增协议：

AjaxTruClient

协议用于基于JavaScript的现代应用程序（包括Ajax，用于模拟Web浏览器中的用户活动）的高级协议。在MozillaFirefox中以交互方式开发脚本。

Silverlight

协议模拟传输及用户活动的基于Silverlight的应用程序的新协议。允许通过自动导入和配置应用程序所使用的WSDL文件生成高级别脚本。

JavaoverHTTP

协议用于录制基于Java的应用程序和小程序的一种新协议。该协议使用Web函数生成Java语言脚本。该协议与其他Java协议的不同之处在于：它可以录制和回放通过HTTP进行Java远程调用。

Citrix

协议现可支持CitrixOnlinePlugin11.2和12.0两个版本，并且增加了对CitrixXenAppServer5.0的支持。

OracleNCA-NCAJava

协议对象属性现可支持在脚本中自动创建和注册客户端Java对象和OracleNCA服务器之间通信的查询应答表。

SAPGUI

协议增加了对SAPGUIforWindowsClient7.20版的支持。

ServiceTest-LoadRunnerController

协议可以运行在HPServiceTest11.00中创建的脚本。HPServiceTest11.00是用于创建和运行SOA（service-orientedarchitecture面向服务体系结构）和无头技术的自动化测试的HP解决方案。有关为负载测试场景创建ServiceTest脚本的详细信息，请参阅ServiceTest文档。

新增功能：

.数据格式扩展(DataFormatExtensionDFE)：

增强了Web(HTTP/HTML)协议系列的数据格式功能。允许将原始HTTP流量转换为可维护的结构化XML格式，并启用XPATH关联。

CorrelationStudio：

增强了Web(HTTP/HTML)自动关联机制，可在代码生成期间所创建的快照数据（包括通过DFE格式化的数据）中更广泛地搜索可能的关联。

快照视图：

Web(HTTP/HTML)协议步骤的新快照视图，允许以原始格式和DFE生成的格式查看完整的HTTP流量。

VuGen-HPALMIntegration：

增强了与HP应用程序生命周期管理平台的集成，该平台还为QualityCenter和PerformanceCenter版本提供支持。

SLA（ServiceLevelAgreements）定义：

在新的版本中扩展了SAL的使用，可以在更多的测试情况下使用SAL定义。

Windows支持：

增加了对Windows7和WindowsServer2008的支持。

Analysis报告：

增强的Analysis报告可更好地自定义。Analysis数据可导出为各种格式，包括Word、Excel、PDF和HTML。利用新的报告模板，可以保存报告定义并生成基于模板的报告。

LoadRunner性能测试步骤

LoadRunner虽然只是一个性能测试工具，但使用它进行性能测试时也有其自身的一个流程。性能测试过程分为四个阶段：【设计】、【构建】、【执行】和【分析/诊断/调节】。具体的工作流程如图

图中多出系统性能调优的过程，因为进行性能测试的目的是找到系统性能的瓶颈，进而帮助开发工程师对系统性能进行调优，如果不能给开发工程师提出性能调优的有效建议，那么性能测试是做得不够成功的。实际上项目进行测试过程也是这样，性能调优是一个循环的过程，一般情况下需要经历多次测试才能达到目标能力。

四个阶段的任务如下：

1.设计阶段定义待测试的业务流程、业务的平均处理量、业务处理量的最高峰值、组合业务流程、系统的整体用户和响应时间目标。

2.构建阶段涉及设置和配置测试系统及基础设施、使用自动化性能测试解决方案构建测试脚本和负载方案。

3.执行阶段性包括运行负载方案和测量系统性能。

4.分析、诊断和调节阶段主要测量系统性能并使负载测试进入下一级别，重点查找问题原因以帮助开发工程师迅速解决问题，并实时调节系统参数以提高性能。

下面对这四个阶段进行详细的描述：

1．设计阶段

设计阶段是性能测试团队与业务领域的经理合作以收集性能要求的主要业务响应时间。可以将需要关注的问题分为四个方面：业务需求、技术需求、系统要求和团队要求。业务要求需通过业务分析师或最终用户收集。一个全面的业务要求应该考虑以下问题：

应用程序情况：

创建系统使用演示，让性能测试团队从整体上了解应用程序如何被使用。

业务流程列表：

创建关键业务流程列表，以使用反映最终用户在系统上执行的活动。

创建Word文档，以便详细记录每个业务流程的正确步骤。

交易列表：

汇编业务流程中需要负载测量（如“登录”或“转移资金”等）的关键活动的列表。

业务流程图：

创建业务流程图，以便描绘业务流程的分支情况。

技术要求应该通过系统管理员和数据库管理员（DBA）进行收集并确认。这些人员可能是企业开发组或运营部门的成员，或同时隶属这两个部门，一个全面的技术要求应该考虑以下问题：

环境预排工作：

与系统或基础设施团队开展测试架构的预排工作。

系统范围会议：

举行会议来讨论系统的哪些部分应该排除在测试流程之外，并达成一致见解。

生产图：

创建生产基础设备的图表，以标记出从QA迁移到生产过程中可能影响性能的因素。

收集系统的要求至关重要，这些是管控负载测试流程通过/未通过状态的系统高级目标，这些通常与来自业务的经理合作而达成一致的，一个全面的系统要求应该考虑以下问题：

系统在正常和高峰期必须支持的用户数量为多少？

系统每秒必须处理的交易量是多少？常用的一种估算方法为80～20原理法。

对于所有的关键业务交易，可接受的最低和最高的响应时间是多少？

用户社区如何连接到系统？

生产中需要承载的系统工作量如何？交易组合如何？

最后是团队要求阶段，需要确定性能测试团队成员。提前收集完整的业务、技术、系统和团队要求，是有效和成功地进行负载测试的基础。

2．构建阶段

在构建阶段，需要将设计阶段所确定的业务流程和工作量转变为可用来推动可重复、真实负载的自动化组件。可以从两个方面来关注：自动化设置和环境设置。

自动化设置包括一系列由性能工程师执行的序列任务：

第一：制作脚本：

将存档的业务流程记录到自动化脚本中。

第二：交易：

插入计时器来产生业务所需要的逻辑计时。

第三：参数化：

用数据池来代替所有的输入数据（如登录用户名和密码），以便每个虚拟用户使用唯一的数据访问应用程序。

第四：方案：

通过为不同的用户组分配不同的脚本、连接和用户行为来创建生产工作量。

第五：监视：

确定要监视哪些负载服务器或机器。

环境设置包括组装硬件、软件和数据，这些都是执行成功及真实负载测试所必需的，这可能要与系统人员、DBA、操作人员和业务团队协作。环境设置中最重要的是准备数据，数据来源有两种方式：一是历史数据；二是创建数据。

历史数据

即是将真实存在的数据，只需要从数据库抽取出来即可。

创建数据

是测试过程中通过一些方法生成批量数据，制作数据的方法通常包括：Ultraedit结合Excel制作数据、数据库、Shell编程和Java编程等。所有创建的数据都应该满足数据模型的要求，否则数据在调用过程中会产生错误。

构建阶段的最终结果是得到一套自动化的方案，可在配置好的可用环境中随意执行。

3．执行阶段

在刚刚接触性能测试的人员，常常误认为执行只是一个单一事件，而事实上，它是一个多步骤的流程，包括多种类型的性能测试。每种类型的测试所提供的信息对于了解发布应用程序的业务风险都是必不可少的。

常见的几类负载测试如下：

基线测试：

用于验证系统及其周围的环境是否在合理的技术参数下运行。性能测试仅运行5到10名用户来对最终用户交易性能进行基线测试，这些测试应该在性能测试流程的开始和结束时执行，以测量绝对响应时间的提高量。

性能测试：

可模拟环境中的负载，从而提供有关系统可处理多少用户的信息，这些测试应该模拟平均和高峰时的生产用量，它们应该使用真实的用户行为（如思考时间）、调制解调器模拟和多个浏览器类型，以获得最高的准备度，应该运行所有的监视程序和诊断程序，以便于工作最大限度地了解系统的性能降低和瓶颈。

基准测试：

用于在理想的情况下测量和比较每种机器类型、环境或应用程序版本的性能，这些测试是系统进行了可扩展测试后运行的，旨在了解不同架构的性能影响。

渗入测试：其目的在于长时间在负载下运行系统，从而检验系统的性能状况。

峰值测试：

其目的在于模拟一段时间内系统上的峰值负载，以使帮助演示应用程序和底层硬件是否能够在合理的时间内处理高负荷。

4．分析、诊断、调节阶段

在完成负载测试的设计、构建和执行阶段后，项目将进入分析、诊断和调节阶段，这些阶段是实时和反复进行的，负载测试解决方案应该提供有关最终用户、系统级别和代码性能数据的全面信息，同时查找导致性能降低的可能原因，这些信息能使你确定是否已经达到性能目标。

在监控、分析、诊断和调节过程中可以获取大量的信息：

监控：

性能测试过程中的监控可显示基础设备每个层上所发生的一切，同时会更清晰地提供有关测试中数据库服务器、Web服务器、应用程序服务器、单个应用程序或流程的信息。监控可快速获取有价值的信息，例如应用程序服务器的处理器（CPU）只能支持150名用户并发，远低于目标值。

分析：

完成负载测试后，可将各种指标（如虚拟用户、CPU或服务器CPU）关联起来，以获取有关应用程序行为不断的其它信息。

诊断：

高效的性能测试解决方案应该向性能工程师提供有关层、组件、SQL语句是如何影响负载条件业务流程整体性能的单个统一视图，性能工程师应该能够看到由最终用户交易所接触到的所有组件，然后确定各组件使用的处理时间，以及调用的次数。有了这些信息，就可以针对Web服务器、应用程序和数据服务器瓶颈进行调优。

许多企业都在应用程序部署前、中和后三个阶段进行自动化性能测试。有些自动化性能测试解决方案可系统地识别并分离基础实施性能瓶颈，然后通过修改系统配置设定来解决它们，通过反复解决基础设施瓶颈，可以不断改进配置。