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服务器、应用程序和数据服务器瓶颈进行调优。 许多企业都在应用程序部署前、中和后三个阶段进行自动化性能测试。有些自动化性能测试解决方案可系统地识别并分离基础实施性能瓶颈，而后经过修改系统配置设定来解决它们，经过反复解决基础设施瓶颈，能够不断改进配置。