LoadRunner基础知识

　　在使用loadRunner进行性能测试时，需要先了解LoadRuner的工作原理、工作过程和内部结构，这样就可以对loadRunner有一个整体的了解和概要的认识。
　　本章主要包括以下内容：
　　●　LoadRuner简介
　　●　LoadRuner工作原理
　　●　LoadRuner工作过程
　　●　LoadRuner内部结构
　　●　LoadRuner性能测试步骤

２.１ LoadRunner简介

　　LoadRunner是一种预测系统行为和性能的负载测试工具，以模拟上千万用户并发负载并实时监测系统性能的方式来确认和查找问题。LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度的缩短测试时间，优化性能和加速应用系统的发布周期。
　　LoadRunner具有以下几个特点：
　　（１）按需生产工作量
　　能够驱动成百上千个虚拟用户、执行不同的业务流程、模拟已部署应用程序将要面临的生产条件。
　　（2）企业环境支持
　　虚拟用户后，测试过程便自动化了。
　　LoadRunner提供广泛的测试环境，支持多种协议和平台。它使得降低总体拥有成本（TCO）称为可能。
　　（3）企业监控支持
　　HP LoadRunner拥有非侵入性的实时性能监控程序，可提供被测系统所有部分的详细指标。这包括Web服务器、应用程序服务器、数据库、企业资源规划（ERP）和CRM系统、防火墙和负载平衡器。HP LoadRunner可识别硬件局限和软件配置问题
　　（4）诊断
　　HP LoadRunner可跟踪、计时处于负载情况下的单独应用程序组件，并可排除故障。可从缓慢的最终用户交易着手，深入查明导致变慢的瓶颈方法或SQL语句。这样详细的结果有助于每个负载测试向开发人员提供最终可采取的行动，减少优化J2EE、Siebel和Oracle部署所需的成本与时间。
　　（5）自动分析
　　HP LoadRunner的AutoCorrelation向导会自动整理所有的监控和诊断数据，并计算导致性能降低的最主要的5个原因。可将性能测试结果转化为可处理的精确数据，从而使开发团队大大减少了解决时间，并允许执行更多的测试周期。这会帮助您将高质量的应用程序投入生产。
　　（6）简易使用
　　HP LoadRunner是从底层为QA用户构建的。它提送可视化脚本语言、数据和AutoCorrelation向导及ActiveScreen技术，使得编写脚本和运行负载测试简单易行。因此带来更短的起步时间、更快的ROI以及在数周培训之内就能进行性能测试。
　　（7）高度可扩展性
　　HP LoadRunner对于在有限的硬件条件下的高度可扩展性来说，每个虚拟用户需要较低的CPU和内存资源。这有助于降低实施过程中潜在的硬件成本。
　　（8）统一的脚本引擎
　　HP LoadRunner与HP Business Availability Center软件具有相同的脚本引擎。这将降低培训成本、脚本开发成本以及HP软件的TCO（Total Cost of Ownership，总体拥有成本）

2.2 LoadRunner工作原理

　　LoadRunner由四大组件组成，即VuGen、控制器、负载发生器和分析器。各组件之间的关系如下图所示。
　　
　　（1）VuGen（Visual User Generator），它的作用是捕捉用户的业务流，并最终将其录制成一个脚本，在录制脚本前首先选择一种协议；接着在客户端模拟客户实际使用过程中的业务流程，并录制成一个脚本；然后编辑脚本和设置Run-Time Setting项；最后VuGen通过对脚本的编译生成一个没有错误的可运行的脚本。
　　（2）控制器（Controller）控制器部分包含两大作用：一是设计场景，脚本编辑完成后，必须对脚本如何运行设计一种策略，场景设计主要包括手动场景设计和目标场景设计两种方式；二是场景监控，控制器可以实时监控脚本运行的情况，可以通过添加计数器来监控Windows资源、应用服务器和数据库使用情况。
　　场景设计的目的是设计出一个最接近用户实际使用的场景，场景设计越接近用户使用的实际情况，测试出来的数据就越接近真实值；场景设计也涉及很多技巧，如IP欺骗、负载均衡等一些手段。
　　执行实时监控更多的是对资源使用情况的监控，以检测这些系统资源是否可能存在瓶颈。
　　（3）负载发生器（Load Generators），模拟用户对服务器提交请求
　　正常情况下，在性能测试过程中，会将控制器和负载发生器分开，即控制器使用一台独立的机器，因为在进行脚本编辑时会产生大量的参数化文件，而这些参数化文件会占用系统资源，再者就是运行时会产生大量的日志文件，所以在测试过程中一般都会讲控制器与负载发生器分开；最主要的原因是因为在模拟成百上千的虚拟用户进行性能测试时，每个虚拟用户都是需要消耗系统资源的，如果虚拟的并发用户过多，会导致测试机出现瓶颈。
　　负载发生器的计算：在测试时，需要计算测试过程要使用多少台负载发生器才算是合理的，每个虚拟用户运行时需要占用一定的系统内存资源，具体的值可以从官方文档中获得。通过这个值可以计算出一台计算机最多可以支持多少个虚拟用户。
　　注意：当使用多台负载发生器是，一定要保证负载均衡。负载均衡是指在性能测试过程中，保证每台负载发生器均匀的对服务器进行施压
　　（4）分析器（Analysis）一个数据分析工具，主要用于对测试结果进行分析，Analysis分析器中提供了很多基础的数据，但是仅仅依靠这些基础的数据是不够的，客户看到这样的报告也不会满意。

2.3 LoadRunner工作过程

　　（1）LoadRunner在性能测试过程中首先是从控制器开始的。控制器包括两部分场景设计和场景监控，通过设计控制器中的场景设计性能测试脚本运行的策略，同时在脚本运行过程中监控性能测试的相关指标。
　　（2）在确定执行策略后，控制器将控制负载机去产生压力，模拟成百上千的虚拟用户去运行脚本，在控制器初始化时，控制器会向负载机发送一个二进制文件，在该文件中记录着如何运行脚本的信息。
　　（3）控制器收集测试过程中的相关数据，在控制器执行脚本场景时，控制器会收集测试过程中相关的一些数据，并将这些数据保存在Access数据库中。
　　LoadRunner工作过程
　　
　　（4）结果分析。当场景执行测试结束后，会生成一些分析结果的数据，这时测试工程师需要对这些数据进行分析，如果结果能满足要求，那么说明系统性能满足要求；反之，就有可能需要进行多次实验，来找到性能瓶颈并向开发工程师提出解决的建议和性能优化的建议。

2.3 LoadRunner内部结构

　　LoadRunner主要通过控制 内部程序的调度来控制整个性能测试过程，LoadRunner内部结构如下图所示，
　　
　　下面从LoadRuuner内部结构的层次来分析LoadRunner性能测试的过程。
　　（1）准备好待测试的应用服务器和待测试的系统
　　（2）LoadRunner中多线程驱动进程mdrv.exe和r3vuser.exe模拟产生压力，其中r3vuser.exe仿真应用程序的客户端，如IE浏览器，它执行了以下3个主要操作：
　　　　1）：cci（C语言编辑器）建立ci文件，然后使用被测系统的协议来执行。
　　　　2）：通过Windows批处理脚本启动mdrv.exe程序从而启动LoadRunner的运行。mdrv能自动停止加载Vuser，因为它们与Vuser和Windows负载发生器上的CPU监视器之间互相通信。
　　　　3）：在Windows机器上，对于每一个基于Java的Vuser都有一个独立的JVM。注意UNIX平台不支持Java Vuser。
　　（3）：虚拟用户在负载发生器端的计算机上使用代理作为服务或进程时，按照组启动方式启动虚拟用户，用户组是多个Vuser组成的逻辑集合，在Vuser发生器上运行相同的脚本。
　　（4）：每个负载发生器（Load Generator）都维护着一个以qtp为后缀名的执行日志。
　　（5）：日志服务启动后，代理会根据用户组进行隔离，在结果文件中为每个虚拟用户组建立一个顺序文件。
　　（6）：在执行过程中，这些文件会在“视图”→“显示”输出窗口中显示出来。
　　（7）：在预先设置延时上，Controller上运行的Scheduler指导代理（通过Windows54345端口或UNIX上的动态端口）初始化场景会话：控制器（wlrun.exe）在发送请求是发送一份场景的副本。
　　（8）：代理是由每一个负载发生器上的Remote Agent Dispatcher进程（8.0叫Remote Command Launcher（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，错误信息会写到Microsoft Access数据库文件output.mdb中。
　　（13）：在每一个结果文件夹中，程序自动创建一个Log文件夹，在这个文件夹中包含每个组的日志文件，运行结束之后，在Controller中查看日志文件，单击
　　
　　按钮，然后在组中右击，在弹出的快捷菜单中选择“查看Vuser日志”。
　　（14）：场景运行的时候，监视器在本地维护每个主机的计数器。
　　（15）：场景运行结束后，进程处理.eve和.lrr结果文件，并且在结果文件夹下创建一个临时的.mdb(M)数据库。在处理大数据量的结果时，为了防止错误发生，通常使用（Microsoft Access）数据库文件。
　　（16）：分析模块（8230K analysisu.exe）使用.mdb数据库中的数据来产生分析图表和报告。
　　（17）：每次设定运行后的LoadRuuner结果文件result_name.lrr(也称为分析器文档文件)，由分析程序来读取并显示百分位图表。
　　（18）：默认情况下，LRReport文件夹被创建在本地分析器的My Documents文件夹下用来存储分析回话文件。
　　（19）：可以使用HTML格式产生报告。
　　（20）：结果文件格式是由.tem模板文件控制的。
　　负载测试的结果可以使用Web浏览器来浏览。
　　以上就是LoadRunner测试的全部过程。

2.5 LoadRunner11.0特性

（1）新增协议
（2）新增功能

2.6 LoadRunner性能测试步骤

　　LoadRunner虽然只是一个性能测试工具，但使用它进行性能测试时也有其自身的一个流程。性能测试过程分为4个阶段：设计、构建、执行、分析/诊断/调节，具体的工作流程如图所示。
　　
　　图中多出性能调优的过程，因为进行性能测试的目的是找到系统性能的瓶颈，进而帮助开发工程师对系统性能进行调优，如果不能给开发工程师提出性能调优的有效建议，那么性能测试是做的不够成功的。实际上项目进行测试过程也是这样，性能调优是一个循环的过程，一般情况下需要经历多次测试才能达到目标能力。
　　4个阶段的任务如下：
　　1）设计阶段定义带测试的业务流程、业务的平均处理量、业务处理的最高峰值、组合业务流程、系统的整体用户和相应时间目标。
　　2）构建阶段涉及设置和配置测试系统及基础设施、使用自动化性能测试解决方案构建测试脚本和负载方案。
　　3）执行阶段包括运行负载方案和测量系统性能。
　　4）分析、诊断和调节阶段主要测量系统性能并使负载测试进入下一级别，重点查找问题原因以帮助开发工程师迅速解决问题，并实时调节系统参数以提高性能。
　　下面对这四个阶段进行详细的描述。
　　1、设计阶段
　　设计阶段是性能测试团队与业务领域的经理合作以收集性能要求的主要业务响应时间。可以将需要关注的问题分为四个方面，即业务需求、技术需求、系统要求和团队要求。业务需求需通过企业分析师或最终用户收集。一个全面的业务要求应该考虑以下问题：
　　●　应用程序情况：创建系统使用演示，让性能测试团队从整体上了解应用程序如何被使用。
　　●　业务流程列表：创建关键业务流程列表，以使用反映最终用户在系统上执行的活动。
　　●　业务流程列表：创建word文档，以便详细记录每个业务流程的正确步骤。
　　●　交易列表：汇编业务流程中需要负载测试量（如登录或转移资金等）的关键活动的列表。
　　●　业务流程图：创建业务流程图，以便描述业务流程的分支情况。
　　技术要求应该通过系统管理员和数据库管理员（DBA）进行收集并确认。这些人员可能是企业开发组或运营部门的成员，或同时隶属这两个部门，一个全面的技术要求考虑以下问题：
　　●　环境预排工作：与系统或基础设施团队开展测试架构的预排工作。
　　●　系统范围会议：举行会议来讨论系统的哪些部分应该排除在测试流程外，并达成一致见解。
　　●　生产图：创建生产基础设备的图表，以标记从ＱＡ迁移到生产过程中可能影响性能的因素。
　　手机系统的要求至关重要，这些是管控负载测试流程通过／未通过状态的系统高级目标，这些通常与来自业务的经理合作而达成一致的，一个全面的系统要求应该考虑以下问题：
　　●　系统在正常和高峰期必须支持的用户数量为多少？
　　●　系统每秒必须处理的交易量是多少？常用的一种估算方法为80~20原理法。
　　●　对于所有的关键业务交易，可接受的最低和最高的响应时间是多少？
　　●　用户社区如何连接到系统？
　　●　生产中需要承载的系统工作量如何？交易组合如何？
　　●　最后是团队要求阶段，需要确定性能测试团队成员。提前收集完整的业务、技术、系统和团队要求，是有效和成功地进行负载测试的基础。
　　２、构建阶段
　　在构建阶段，需要将设计阶段所确定的业务流程和工作量转变为可用来推动可重复、真实负载的自动化组件。可以从两方面来关注：自动化设置和环境设置。
　　（1）自动化设置包括一系列由性能测试工程师执行的序列任务。
　　　　1）制作脚本。将存档的业务流程记录到自动化脚本中。
　　　　２）交易。插入计时器来产生业务所需要的逻辑计时。
　　　　３）参数化。用数据池来代替所有的输入数据（如登录用户名和密码），以便每个虚拟用户使用唯一的数据访问应用程序。
　　　　４）方案。通过为不同的用户组分配不同的脚本、连接和用户行为来创建生产工作量。
　　　　5）监视。确定要监视哪些负载服务器或机器。
　　　（2）环境设置包括组装硬件、软件和数据，这些都是执行成功及真实负载测试所必需的，这可能要与系统人员、DBA、操作人员和业务团队协作。环境设置中最重要的是准备数据，数据来源有两种：一是历史数据；二是创建数据。
　　　历史数据即是真实存在的数据，只需要从数据库抽取出来即可。
　　　创建数据则是测试过程中通过一些方法生成批量数据，制作数据的方法通常包括Ultraedit结合Excel制作数据、数据库、shell编程和java编程。所有创建的数据都应该满足数据模型的要求，否则数据在调用过程中会产生错误。
　　　构建阶段的最终结果是得到一套自动化的方案，可在配置好的可用环境中随意执行。
　　3、执行阶段
　　在刚刚接触性能测试的人员，常常误以为执行只是一个单一事件，而事实上，它是一个多步骤的流程，包括多个类型的性能测试。每种类型的测试所提供的信息对于了解发布应用程序的业务风险都是必不可少的。
　　常见的几类负载测试如下：
　　●　基线测试。用于验证系统及其周围的环境是否在合理的技术参数下运行。性能测试仅运行5~10名用户来对最终用户交易性能进行基线测试，这些测试应该在性能测试流程的开始和结束时执行 ，以测量绝对响应时间的提高量。
　　●　性能测试。可模拟环境中的负载，从而提供有关系可处理多少用户的信息，这些测试应该模拟平均和高峰时的生产用量，它们应该使用真实的用户行为（如思考时间）、调制解调器模拟和多个浏览器类型，以获得最高的准备度，应该运行所有的监视程序和诊断程序，以便于工作最大限度的了解系统的性能降低和瓶颈。
　　●　基准测试。用于在理想的情况下测量和比较每种机器类型、环境、或应用程序版本的性能，这些测试是系统进行了可扩展测试后运行的，旨在了解不同架构的性能影响。
　　●　渗入测试。其目的在于长时间在负载下运行系统，从而检验系统的性能状况。
　　●　峰值测试。其目的在于模拟一段时间内系统上的峰值负载，以便帮助演示应用程序和底层硬件能够在合理的时间内处理高负荷。
　４分析、诊断、调节阶段
　在完成负载测试的设计、构建和执行阶段后，项目将进入分析、诊断和调节阶段，这些阶段是实时和反复进行的，负载测试解决方案应该提供有关最终用户、系统级别和代码性能数据的全面信息，同时查找导致系统性能降低的可能原因，这些信息能使你确定是否已达到性能目标。
　在监控、分析、诊断和调节过程中可以获取大量的信息：
　　●　监控。性能测试过程中的监控可显示基础设备每个层上所发生的一切，同时会更清晰的提供有关测试中数据库服务器、WEB服务器、应用程序服务器、单个应用程序或流程的信息。监控可快速获取有价值的信息，如应用程序服务器的处理器（CPU）只能支持150名用户并发，远低于目标值。
　　●　分析。完成负载测试后，可将各种指标（如虚拟用户、CPU或服务器CPU）关联起来，以获取有关应用程序行为不端的其他信息。
　　●　诊断。高效的性能测试解决方案应该向性能测试工程师提供有关层、组件、SQL语句是如何影响负载条件业务流程整体性能的单个统一视图，性能测试工程师应该能够看到由最终用户交易所接触到的所有组件，然后确定各组件使用的处理时间及调用次数。有了这些信息，就可以针对WEB服务器、应用程序和数据服务器瓶颈进行调优
　　●　许多企业都在应用程序部署前、中和后3个阶段进行自动化性能测试。有些自动化性能测试解决方案可系统的识别并分离基础实施性能瓶颈，然后通过修改系统配置设定来解决他们，通过反复解决基础设施瓶颈，可以不断改进配置。

2.7 小结