利用loadrunner分析场景、监视图表_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
7页4下载券26页2下载券29页免费17页1下载券17页免费 7页免费3页1下载券2页1下载券4页1下载券7页免费
喜欢此文档的还喜欢11页免费134页1下载券13页免费24页免费10页免费
利用loadrunner分析场景、监视图表|分​析​以​及​监​视​场​景​
​
​分​析​实​时​监​视​图​表​
​
​利​用​A​n​a​l​y​s​i​s​ ​分​析​结​果
把文档贴到Blog、BBS或个人站等：
普通尺寸(450*500pix)
较大尺寸(630*500pix)
你可能喜欢&&&&&& 在上文中，介绍了如果录制脚本和设置脚本执行次数。如果经过调试脚本能够正常工作的话，就可以设置并发用户数并进行压力测试了。
&&&&&& 首先我们通过脚本编辑界面上的“工具”菜单项，选择该菜单的第二项“Create Controller Scenario(创建控制场景)”，如下图：
&&&&& 这时，lr会弹出一个窗口，我们只要在select scenario type项中的number of vusers设置成1000，这样我们就可以用1000并发用户来测试我们上文中所执行的操作了，如下图：
&&&&& 注:之前在上文中设置脚本执行次数为5，这里又做了1000的并发用户，所以最终我们要创建的“主题数”等于：1000*5 = 5000，而这5000主题要在10分钟左右的时间里创建完成，压力不小，呵呵。
&&&&& 完成了这个设计并点击"ok”之后，我们就可以看到我们所设置的场被“创建”出来了，这里我们只要点击"start scenario”就可以启动压力测试了，如下图：
&&&&& 这里lr就可以运行压力测试了，同时我们可以从下图中看到正在测试过程中的各项参数，如下图（注意红字标注部分）：
&&&&& 从上图中的“并发用户”图中，答道可以看到，大经销商在5分钟时，并发用户数达到了1000的‘上限’，而在“响应时间”中我们看到“发主题”操作的执行曲线在3分钟时创出响应时间的‘高峰’，且其执行时间普遍高于其它页面。而就在3分钟时并发用户数开始接近于1000，看来大并发对于发主题操作的压力不小呀。其实在正常环境下，用户要求的响应时间维护在3-8秒左右，而像上图所posttopic_transaction中的“平均值”却达到了26秒多，显然是不可接受的，但正如我在前一篇中所说的那样，这次测试是抱着一种将“服务器”压死的目的来测试的，所以设置的参数基本上已接近那台1u服务器所能承受的上限了，当然这会上平均页面的响应时间变得‘过长’，但我认为正是这种‘慢动作’的‘假象’才能让系统处于‘疲于奔命’的情况，也才能让其问题能够暴露的更全面一些。当然除了这种加大并发和工作量的方式之后，在lr中还可以通过设置‘集合点’的方式来制造更大的压力，只不过后者更倾向于对那些正在改进或已改进的程序代码进行压力测试的情况，我会在后面优化程序的时候加以说明。&&&&
&&&& 注：这里有必要介绍一下什么是“点击率（Hits/sec）”, 即每秒点击数，是在场景或会话步骤运行过程中VUser每秒向WEB服务器提交的HTTP请求数. 而上图中就是0--5分钟这段采样时间内VUser平均每秒发送的HTTP请求数。而这个值的图表‘走势’是与系统的‘吞吐量（Throughput）’相对应的，这一点会在生成测试报告时加以解释说明。
&&&& 一般在这个时间，我会在到达1000并发用户（图中4分钟左右）时，习惯性的去看一下服务器的cpu，内存和网络情况，因为这时如果cpu处于长时间100%时就是已到了系统瓶颈了，下面就是此时服务器端的cpu，内存使用情况：
&&&& 上图中，我们看到cpu经常在100%的使用率上徘徊，并且一旦到了100%的高峰上时，就会持续一段时间，大约为3-5秒，然后就会迅速下跌。这说明系统在此时‘可能’出现了资源争用情况，比如内存，文件或数据库等，而此时图中内存使用情况并不高，可以排除内存方面的问题，还有就是此时的网络情况也并未造成拥塞（如下图：经常处于20-50%的状态下），所以网络方面的因素也应该予以排除了。
&&&&& 那么就只剩下文件访问和数据库方面的问题了。因为在discuznt中使用了配置文件方式来设置系统参数，并且其文件被加载之后就被static方式进行声明，所以一旦系统运行起来之后，就不会频繁访问文件了，这一点在之前的“”中已做过说明，所以最后就剩下数据库方面的因素了。
&&&&& 注：如果大家有人能搞到正版lisence的话，就不用这么麻烦了，因为lr会自动收集这方面的信息，可以在生成报造时给我们提供在测试周期内的cpu,内存，网络方面的详细结果，以便于我们在‘决策’时有准确的数据进行参考。而我本人这种做法只是权宜之计，且在准确性上也要打上‘折扣’。
&&&&& 如果一切正常的话，这个测试会在10分钟后运行完毕，这时我们就可以点击‘控制场景’中的工具条上的这个图标来生成测试报告了（终于到了采摘‘胜利果实’的时候了），如下图：
&&&&& 这样lr就会将刚才的测试过程生成一份报告，下面就来介绍一下这个报告（关于如何分析报告以及优化程序，因为内容较多，不可能在本文中详细介绍，只能在下一篇中说明了），如下图：
&&&&& 下面就是其报告首页的介绍（注意红框和说明）：
&&&& 而在首页还有一个信息就是静态统计，如下图（红框部分）：
&&&&&& 其中：
&&&&&&& Maxinum Running Vusers:就是模拟的最大运行用户数(951)人，这里为什么不是1000，我想主要还是与测试过程中的服务运行状态和lr测试机本身的情况所决定的，这个值会随你不断反复测试而有所变化的。
&&&&&&& Total Throughput(bytes):即吞吐总量，是在测试过程中场景执行时从Server上接收到的数据总量（以字节为单位，千万别看错单位，要不心脏不好的TX肯定会晕过去了，呵呵）。
&&&&&&& Average Throughput(bytes/second):即每秒吞吐量，即在场景执行期间每秒从Server上接收到的数据量的值。这个值一般与网络带宽相比较，用以判断目前的网络带宽是否是瓶颈。
&&&&&& Total Hits:总点击率，在场景或会话步骤运行过程中VUser向WEB服务器提交的HTTP请求总数.
&&&&&& Average Hits per Second:每秒点击数，即在场景或会话步骤运行过程中VUser每秒向WEB服务器提交的HTTP请求数.
&&&&& 看了这些参数，其实我一般很少看它们，因为对于优化程序来说，多数时间是要看运行图形的变化情况，而不是这些统计值或平均数，它们只是告诉你系统的运行情况是好是坏，却不能告诉你系统的瓶颈出在了哪里。下面就来简单介绍一下报告中几个非常重要的图表，首先就是并发用户图：
&&&&&& 该图显示的是并发用户数量在整个测试周期中的生成情况，可以看到在3分钟后，并发用户数到达了顶峰，并在6分钟后高峰退去。所以在这段时间内是个‘敏感期’，我们要特别重视在这个时间段内系统的反映情况。
&&&&& 接着就是每秒点击率图：
&&&&& 这个图看到在3--6分钟出现了三个高峰（值基本上到达了1300），而这个期间与上面的并发用户高峰时段正好‘稳合’，原因很好解释，必定用户多了，操作多了，自然向服务器提交的http请求就多了。
&&&&& 接下来，再看一下‘吞吐量’：
&&&&&&& 这一张图基本上已上前的点击率图的走势差不多，原因很好解释，因为操作请求多了，服务器端忙了，在服务端能正常处理请求的情况下，自然接收到的数据量相应也会增加了。
&&&&&&& 下面再介绍一下事务执行情况，这张图可以帮助我们看到那些action执行时出了问题（红色部分为出错），那些工作良好（绿色为良好）。
&&&&& 最后一个图就是我经常看的图了，“平均时间响应时间”，它告诉我们那个action的执行时间过长，那些基本稳定，那些先是稳定但大并发来时出了问题。
&&&&&&& 当然，除了这五个图表之后，lr还提供了更多其它方面的图表，比如页面大小，文件(js,css,aspx等)元素加载时间等，比如下图就是我经常添加的图表：
&&& 其中：
&&&&&&& Web Page Breakdown：会告诉你所做的action中，每个页面（aspx,js,css,img）的加载时间（最大，最小，平均值）
&&&&&&& Page Downloaded Time Breakdown: 页面下载时间，包括dns解析时间，首次缓冲时间，发起链接时间等。
&&&&&&& Downloaded Component：每个页面体积尺寸，以便于分析那些页面体积过大，从而影响网络传输或处理速度。
&&&&& 最后声明一下，上面这些图只是说明各个图表的性质和作用，并不是优化前的最终测试结果。
&&&&& 在下一篇中，我们通过最终的测试数据来找出系统有那些瓶颈，以及如果优化数据库访问查询，更新等。
&&&&& 好了，今天的内容就先到这里了。
&&&&& 原文链接:
&&&&& 作者: daizhj, 代震军
&&&&& Tags: loadrunner,压力测试,discuznt
&&&&& 网址:
阅读(...) 评论()LoadRunner在软件性能测试中的应用_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
754页¥59.404页¥2.00158页免费4页¥2.003页¥1.00 3页¥2.0017页免费41页2下载券3页免费1页免费
喜欢此文档的还喜欢16页1下载券100页1下载券134页1下载券19页免费158页免费
LoadRunner在软件性能测试中的应用|关​于​软​件​测​试​的​一​些​方​法​和​标​准
把文档贴到Blog、BBS或个人站等：
普通尺寸(450*500pix)
较大尺寸(630*500pix)
你可能喜欢[转]LOADRUNNER8.1应用实例
【转自】/ruanko-express_4/webpage/tech-overnight_1.html
LOADRUNNER8.1应用实例　　--作者：魏彦荣
　　一.概述 　　应用loadrunner很长一段时间,对它的功能之强大也为之震惊,可以说是无所不能,me做的是一个B/S构架的网站测试(&&),期间发现了一些比较重大的性能问题,对此也颇有成就感。
　　Loadrunner可以完全的模拟实际Internet环境,来对被测软件进行大数据量的负载压力测试,通过监控器实时的收集信息来分析系统的瓶颈和性能。它能够有效的提高软件产品的质量，优化软件性能，减少用户使用软件失败的几率，提高测试工作效率和质量，加大测试的深度和广度。
　　Loadrunner分为三个模块,Generator(录制脚本,加强脚本) ,Controller(创建和运行场景,并对客户和服务器间数据的响应进行监控),Analysis(对整个系统进行压力测试的结果进行分析) 。
　　二.安装　　 Loadrunner的安装过程比较简单,只要按它的安装流程按部就班的执行就OK了,但需要注意的一点是安装的路径必须是英文的,不然一直会提示：& the link file .... may be corrupted or has illegated link string &，导致重复多次均无法安装。为了使你的测试更有效，而不因为杀毒软件的存在而造成不必要的影响，建议在安装及运行的情况下最好关掉杀毒软件。
　　三. Mercury Virtual User Generator 录制测试脚本 　　介绍了这么多,相信大家非常急切的看到它的庐山真面目,在程序中找到它的路径,并且打开Loadrunner你会看到。
　　点击创建/编辑脚本,脚本协议选择,URL地址或软件路径地址输入,将需要测试的流程录制就可以生成测试脚本了.接着就可以加强脚本,最后达到预期目标。
　　1.协议的选择　　Loadrunner的协议选择众多,想正确的选择脚本协议,首先要从Loadrunner的工作原理上深入的理解协议的作用和意义, Loadrunner启动后,在任务栏上有一个loadrunner agent process 进程,这个进程的一项重要的工作就是监视各种协议的客户端和服务器端的通信.只要是能支持的协议, Loadrunner在录制的工程中就可以通过脚本语言将通信工程录制下来,所以要明确被测软件的通信过程和所使用的协议, Loadrunner才能正确的录制脚本。
　　a.选择单协议还是多协议的关键是你对应用的通信细节要清楚.可以多问问开发他们是怎么实现的.比如有个WEB系统需要测试,看上去选择单协议就可以了,但是在和服务器交互的过程中,浏览器下载页面里的APPLET并且用APPLET和服务器建立了SOCKET传输一些数据.这种情况下就该选择多协议了.还有一些邮件方面的应用一般都要选择多协议,邮件系统都会使用到发送和接受两种协议.有些时候不选择多协议,脚本也能运行.但你的脚本没有完全反映出客户端和服务器端的交互过程.选择录制脚本的协议前,还是要多分析一下应用系统
　　b.一般将应用软件分为B/S和C/S结构来选择协议, 对于B/S结构，可以选择WEB（HTTP/HTTML）协议；对于C/S结构，可以根据后端数据库的类型来选择，如SYBASECTLIB协议用于测试后台数据库为SYBASE的应用，MS SQL SERVER协议用于测试后台数据库为SQL SERVER的应用；对于没有数据库的WINDOWS应用，可以选择WINDOWS SOCKETS这个底层的协议；这里需要说明的是，无论使用哪种协议，LOADRUNNER的测试流程都基本是一样的，只有在设定细节上有所不同，测试人员只要对被测应用的技术架构熟悉了，就能够成功完成脚本的录制。
　　2.脚本的录制 　　当选择好脚本协议后,就可以对开始录制了,如果是B/S架构的测试对象,当然选择了web(http/html),接着输入要测试的URL地址,确定就OK了。
　　a.明确脚本的三个部分　　LOADRUNNER 将测试脚本分为3个部分，VUSER_INIT,VUSER_END和ACTION,其中VUSER_INIT和VUSER_END一般用于存放应用程序初始化的脚本和注销关闭的脚本,在重复执行的时候,这两部分的内容只执行一次.而ACTION部分用于存放实际的操作脚本,这部分脚本可以多次执行,测试人员还可以根据需要创建多个ACTION 脚本,但不能创建VUSER_INIT和VUSER_END.所以在录制的时候一定要明确:录制的流程是否要迭代,如果要一定要放入ACTION部分。
　　b.录制时的脚本开发　　在录制的时候在屏幕上会有一个悬浮的控制脚本录制的工具栏,是脚本录制过程中测试人员和VUGEN交互的主要平台,每个可用的按钮都可以执行相应的操作,如上图,测试人员可以新建Action,插入文本检查点,制定开始结束事务,也可以在需要测试的功能点插入集合点,或作一些必要的注释等等&..
　　3.脚本的开发与加强　　该阶段也是脚本录制阶段最重要的部分,为了实现理想中的需求,你可以添加事务,插入集合点,调整运行时的设置,参数化数据,插入文本图片检查点,但是在这之前必须要确保录制的脚本能够跑通,即回放没有问题,有如下提示图。
　　a.添加事务　　除了从总体把握系统的性能问题外,测试工程师可能还要对业务中的某一个具体部分的数据进行分析,来检测该功能点的性能问题,为了达到这个目的,就要为该功能点添加事务,将该功能点用开始与结束事务包起来,分析该事务来了解和把握该功能的性能。
　　所谓事务(TRANSACTION),就是在脚本定义中定义的某段操作(ACTION),更确切的说,就是一段脚本语句.定义事务时,首先在脚本中找到事务的开始和结束位置,然后分别插入一个事务起始标记,这样,当脚本运行的时候,LOADRUNER会自动在事务的起始点计时,脚本在运行到事务结束点时计时结束,系统会自动记录这段操作的运行时间等性能数据；在脚本运行完毕后,系统会在结果信息中单独反映每个事务运行结果。
　　事务的插入操作可以在脚本运行过程中进行,也可以在脚本录制完毕后进行,建议在脚本录制完毕后进行.如下图添加。
　　也可以在脚本中插入事务,在树图列表下右键,选择在该项之前或之后添加事务,开始和结束的事务是成对出现,不然脚本会报错,如下图:
　　b.插入集合点　　在控制台执行负载测试,设置多用户同时加载并发,并发过程仅仅体现在开始执行的那一刹那,随着服务器对请求的响应时间的不一致或系统环境条件的限制,在运行过程中能集合到一点的可能性微乎其微,所以将一定数量的用户同时加载并不是真正意义上的并发。
　　系统压力最大的情况是:所有用户都集中到系统瓶颈的某个点上进行操作,从脚本的角度来讲,这个点就是执行脚本的某一条或一段语句,为了真实模拟这个最坏的情况,查看系统在最坏情况下的反映。
　　为了实现测试一个业务中途的并发性能测试,LR中的集合点就孕育而生了,使跑在前面的用户在该点上等待,让后面的追赶上来, 将众多的Vuser集合到一起,来达到并发的效果.来帮助测试人员实现真正意义上的并发。
　　插入集合点的方法:可以在录制的时候添加,也可以象添加事务一样,在树图列表下添加.当然如果熟悉集合点的语言的话在脚本中直接插入语言也可以。
　　c.运行时设置
　　点击右上角图标,弹出运行时设置对话框,就可以对迭代次数和迭代逻辑进行设置,迭代之间的时间的设置,还可以对网络的速度,浏览器,Internet协议的模拟。
　　每个 Vuser 脚本都包括三部分：vuser_init、Run (Actions) 和 vuser_end。可以指示 Vuser 在运行脚本时重复执行 Run 部分。每次重复称为一次迭代。 运行多次迭代时，将不会重复执行 Vuser 脚本的 vuser_init 和 vuser_end 部分。
　　迭代次数：迭代的次数。Vuser 将按指定的次数重复执行所有 Actions。注意：对于 LoadRunner Controller 和优化模块：如果在计划设置中指定了场景或会话步骤持续时间，则持续时间设置将覆盖 Vuser 迭代设置。这意味着，如果持续时间被设置为 5 分钟（默认设置），Vuser 将在 5 分钟内根据需要连续运行任意多次迭代，即使运行时设置仅指定一次迭代。
　　运行多操作脚本时，可以指明执行操作的方法以及 Vuser 执行这些操作的方法：操作块：操作块是脚本内的操作组。您可以单独设置每个块的属性 - 其顺序、迭代和权重。顺序：您可以设置脚本内的操作顺序。还可以指明是按顺序还是随机执行操作。迭代：除了设置整个 Run 部分的迭代次数以外，还可以设置单个操作或操作块的迭代。该设置非常有用，例如，可以用来模拟一个商业站点，您在该站点执行了多次查询查找某个产品，但只进行了一次购买。权重：对于随机运行其操作的操作块，您可以设置块内每个操作的权重或百分比。
　　d.参数化脚本　　众多用户都使用相同帐户登陆或相同的数据来测试脚本,对系统造成的压力与实际情况会有所不同.而对于那些禁止一个用户多次登陆的系统,也就严重到无法测试的地步了.为了解决这个问题,让系统更加真实的模拟多用户使用的实际环境,LOADRUNNER提供了对脚本进行参数化输入的功能;让每个虚拟用户都拥有自己的帐户进行登录和运行。
　　所谓的脚本参数化,就是针对脚本中的某些常量,定义一个或多个包含数据源的参数来取代,让场景中不同的虚拟用户在执行相同的脚本时,分别使用参数数据源中的不同数据代替这些常量,从而达到模拟多用户真实使用系统的目的。
　　明确需参数的数据，选中该数据，右键替换为新参数，打开属性&&用记事本编辑&&运行脚本，it is over。
　　需要注意的是在参数化属性页面的设置比较复杂，下面就讲解下设置的细节：
Select next row ：多个VU如何取值
Sequential：按照顺序一行行的读取。每一个虚拟用户都会按照相同的顺序读取
Random：在每次循环里随机的读取一个，但是在循环中一直保持不变
Unique ：每个VU取唯一的值。注意：使用该类型必须注意数据表有足够多的数。
Same Line As 某个参数（比如Name）：和前面定义的参数Name 取同行的记录。通常用在有关联性的数据上面。
Update value on：多次迭代如何取值
once在所有的反复中都使用同一个值
each iteration则每次反复都要取新值，
each occurrence则只要发现该参数就要重新取值，也就是如果一个action中有多个该参数，每遇到一个就要重新取一个值
一个参数在一个Action中出现多次时
Random+each iteration 该次迭代中某参数的取值方法为：本次迭代中参数第一次取的值，多次取值不变化
Random+each occurrence 该次迭代中某参数的取值方法为：在本次迭代中参数每次取值都通过Random来变化
Random+once 在所有迭代中某参数的取值受第一次取值的影响。第一次取值通过Random来变化，之后不再改变　　参数化数据的准备：可以通过一些工具来生成需要的数据，如果在数据库中有现成的数据也可以通过数据库导出来达到目的，只要选择数据向导，连接到数据库服务器，输入SQL语句即可，如下图
　　e.插入检查点　　LOADRUNNER检查点的功能主要用来验证某个界面上是否存在指定的TEXT或IMAGE等对象，在使用LOADRUNNER测试WEB应用时，可以检查压力较大时WEB服务器能否返回正常的页面。
定位要检查的页面定位需要检查的页面，最好将脚本视图切换到TREE VIEW方式，这样就可以直观地查看到LOADRUNNER录制时获取的每个页面了。在TREE VIEW视图中用鼠标单击页面左侧列表中页面对应的URL，就能迅速查看到准备检查的页面和页面上需要检查的图象或文本信息。
插入文字检查点选择相应的URL，单击鼠标右键，在系统弹出的菜单中选择INSERT AFTER或INSERT BEFORE命令，在URL的脚本前面或后面插入函数，在ADD STEP对话框中可以插入很多的函数，如果想为WEB应用插入图像或文本检查点，需要选择WEB CHECKS下面的IMAGE CHECK或TEXT CHECK，在系统弹出的检查点属性对话框中，输入要查询的文字或图像名称后，系统会自动在TREE VIEW视图中的树型列表中插入类似的STEP。LOADRUNNER 还允许对要检查的文字内容和图像名称进行参数化，参数化的过程可以在插入检查点的 过程中实现，还可以在插入之后重新打开脚本实现。要想在插入检查点时就直接实现参数化，只需要在设置被检查对象的名称时单击ABC按钮，创建或选择参数输入就可以了。
设定与检查点有关的选项系统在执行时是否起用检查点，是由一个系统参数控制的，该参数的设定方法为：VUSER|RUN-TIME SETTINGS|PREFERENCES，如果想让检查点起作用，需要选中ENABLE IMAGE AND TEXT CHECK 复选框。
查看检查点是否通过脚本运行结束后，要想查看检查点是否通过，可以在TREE VIEW视图下，用鼠标右键单击检查点步骤，选择GO TO STEP IN EXECUTION命令，则系统自动将光标定位到执行日志中获取检查点结果的一行上。
　　4.LoadRunner 脚本中做关联 (Correlation)　　LR中的关联是为了解决脚本中随时变动的数据，一般都是服务器返回给客户端的随机数据，如生成的定单号，session，Cookie号等等，每个数据之间没有任何联系，为了不因为这些数据的不同而导致脚本的不通过，LR提供了关联功能，它可以实时自动找出要关联的值，将这些动态数据联系起来。
　　关联分为自动关联和手动关联，自动关联必须要在录制脚本之前开启自动关联项。
　　a.启用auto-correlation
　　点选VuGen的【Tools】&【Recording Options】，开启【Recording Options】对话窗口，选取【Internet Protocol】&【Correlation】，勾选【Enable correlation during recording】，以启用自动关联。
　　假如录制的应用系统属于内建关联规则的系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，请勾选相对应的应用系统。或者也可以针对录制的应用系统加入新的关联规则，此即为使用者自订的关联规则。
　　b.自动关联----Correlation Studio
　　当录制的应用系统不属于VuGen预设支持的应用系统时，Rule Correlation可能既无法发挥作用，这时可以利用Correlation Studio来做关联。
　　使用Correlation Studio的步骤如下：
录制脚本并执行；
执行完毕后，VuGen会跳出下面的【Scan Action for Correlation】窗口，询问您是否要扫描脚本并建立关联，按下【Yes】按钮。
扫描完后，可以在脚本下方的【Correlation Results】中看到扫描的结果。
检查一下扫瞄的结果后，选择要做关联的数据，然后按下【Correlate】按钮，一笔一笔做，或是按下【Correlate All】让VuGen一次就对所有的数据建立关联。注意：由于Correlation Studio会找出所有有变动的数据，但是并不是所有的数据都需要做关联，所以不建议您直接用【Correlate All】。 一般来说，您必须一直重复步骤1~4直到所有需要做关联的数据都找出来为止。因为有时前面的关联还没做好之前，将无法执行到后面需要做关联的部份。
　　c.手动关联 　　有可能有些需要做关联的动态数据，连Correlation Studio都无法侦测出来，这时您就需要自行做手动关联了。
　　四．Mercury LoadRunner 控制器　　控制器是脚本录制完成后,执行压力负载测试的工具, 测试人员的工作就是了解被测应用的性能需求,从应用程序中找出一个或多个性能测试点,然后针对这些性能点分别进行测试,获取相关的性能指标结果,分析被测应用,追溯性能问题产生的根源.要使用LR实现这一过程,就需要针对这些性能点建立一个个的场景,因此,LR的每个场景都定义了一个在性能测试活动中发生的事件,它能控制虚拟用户的数量,测试脚本和运行脚本的LOAD GENERATOR.对于有经验的测试人员来说，定义场景是在计划阶段进行的，它优先于脚本的录制过程，并指导脚本的录制。只不过计划阶段的场景只能限于纸面上，要想让LR这个测试工具实现自动的负载测试，需要在CONTROLLER中建立实实在在的场景。
　　控制场景可以从程序中打开,然后选择保存好的脚本,也可以从Generator中直接连接到该脚本的控制场景,如下图:
　　打开场景后,可能运行的场景有些单一,实际环境中可能在同一时间有多个功能模块一同运行,为了实现这个目的, 可以添加多个已经录制好的脚本,在控制场景中一同执行,添加的方法如下:
　　在控制场景页面也有多项设置来达到测试需求,如:编辑计划,IP欺骗器,集合点策略,负载生成器,添加资源度量&.
　　1.编辑计划　　编辑计划是用来控制场景的运行时间和运行策略,它分为按场景计划和按组计划,按组计划是为多个场景运行,而限制其中某个场景而设定的项,这就但说明下场景设置就OK了,在场景计划中分为加压,持续时间,减压三个阶段,分别讲了如何加压是所有的Vuser同时负载,还是隔多久加载多少个Vuser,持续时间是为了流程完成为止还是运行时间的限制,减压和加压有点相似,就不多讲了,计划生成器如下图:
　　2.IP欺骗器　　LR进行压力负载测试的时候，是让一台机器模拟成百上千的用户对服务器施压，这样就产生了一个问题，那就是所有用户向服务器发起请求的时候，使用的都是同一个IP地址，即LOAD GENERATOR所在机器的固定IP地址，这是和实际运行环境不符的，而且有些应用系统在设计的时候会根据IP来分配资源，有些还限制同一个IP的多次登陆过程。LR为了解决这个问题，使用了一种称为&IP欺骗（IP SPOOFER）&的技术。也就是让一个LOAD GENERATOR上的虚拟用户模拟从不同的IP来向服务器发起请求，以达到以假乱真的目的。设定欺骗器如下图:
　　1&配置IP SPOOFER　　第一个单选按钮CREATE NEW SETTING，用于创建一个新的设置，首次运行时选用；　　第二个单选按钮LOAD PREVIOUS SETTING FROM可以调用以前保存的设置；　　第三个单选按钮RESTORE 　　ORIGINALSET不是用来创建动态IP，而是将设置恢复为原始状态，这个选项主要用于使用后释放IP，如果使用完毕后不释放IP的话，那么这些IP会被一直占用，别人就无法使用了。
　　2&输入WEB　　SERVER的IP地址，这里主要用来检测新的IP地址加到主机中后，SERVER的路由表是否需要更新，如果SERVER和CLIENT使用的是相同的子网掩码，IP CLASS类型和网络，是无需更新的；
　　3&在添加新的动态IP的时候，需要注意如下几个选项的含义：　　PRIVATE ADDRESS SPACES：选择测试环境的IP地址类型，关于IP地址类型的定义　　FROM IP：要使用IP段的第一个值；　　NUMBER TO：要使用的IP地址的数目。　　SUBMASK：子网掩码，一般采用默认设置就可以了；
　　如果选中VERIFY THAT NEW IP ADDRESS ARE NOT ALREADY IN USE复选框，系统会在所选范围内检测每个IP地址，为了避免冲突，LOADRUNNER只添加那些没有被其他用户使用的IP地址。
　　如果已经预先知道选择范围内的某些地址可能被占用，那么在NUMBER TO文本框中输入的IP地址的个数就要有相应的增加。
　　4&启用IP欺骗　　在CONTROLLER窗口中，选择SCENARIO|ENABLE IP SPOOFER命令，就可以起用IP欺骗了，在IP欺骗启用后，在CONTROLLER状态栏中会显示相应的状态标识；
　　3.集合点策略　　LOADRUNNER在运行场景的时候，允许测试人员根据项目需要自己设定集合点的并发策略，要设定一个集合点以何种方法运行，在创建或打开脚本中包含集合点的场景时，选择SCENARIOI|RENDEZVOUS命令，可以查看场景中所有脚本中的集合点名称，所属脚本，当前状态和相关的虚拟用户列表信息等，根据系统需求，还可以针对集合点的执行进行设定。设置窗口如下:
　　单击禁用集合点按钮可以选定集合点是否启用；　　单击禁用Vuser按钮可以设定一个用户是否参与到集合点中；　　单击策略按钮可以设定集合点执行策略。
　　在策略对话框中的VUSERS之间的超时值文本框中设定了一个超时时间，当第一个用户到达集合点时，系统开始计时。如果在这个设定的时间内没有达到要求的集合点用户数，系统就不在等待，释放用户让场景继续执行；
　　4.负载生成器　　LR对应用程序施压时，采用的方法就是让一台机器模拟很多用户，同时向被测用户发送请求或进行操作。这样，如果一台测试机器模拟的虚拟用户数过多，他本身性能的下降会直接影响测试效果。为了避免这种情况，LR允许使用多台机器运行场景来均衡测试机器的负荷。只要一台机器安装了LOAD GENERATOR并启动了LOADRUNNER AGENT PROCESS进程，就可以被CONTROLLER统一调度来运行场景，CONTROLLER负载收集统一的测试信息和执行结果。
　　如上图添加另一台安装LR的计算机既可,但是要想负载,被添加的机子必须开启LR代理服务器,然后设定负载策略,连接成功后,在某一场景的负载生成器栏中选择该连接的机子就OK了。
　　5. 添加资源度量　　为了能够实时的监控服务器因用户量的递增或因功能点性能问题而导致资源的变化,LR也提供了象Vuser图一样的资源图,只要在相应的区域右键添加度量,将需要关注的资源添加进来即可.如下图
　　1&在AVAILABLE列表中，单击要监视的图表，选择MONITOR|ADD MEASUREMENTS；或者在AVAILABLE GRAPH中先将准备监视的指标拖至右侧图表栏中，然后用鼠标右键单击该图表，在弹出的快捷菜单选择ADD MEASUREMENTS，系统会自动弹出相应的监视服务器对话框；单击上部的ADD按钮，在MONITORED SERVER MACHINES中添加要监视的服务器名称（或IP地址）和相应的系统平台；单击下部的ADD按钮在RESOURCE MEASUREMENTS ON列表中添加相应的计数器，这里可以选择一个或多个性能指标。如果添加成功的话，场景运行的时候，就可以在线监视所选择的指标数据了
　　注意：必须以被监视机器的管理员身份登陆到CONTROLLER所在机器，才能添加被监视机器的性能计数器；
　　2&常见的计数器
MEMORY相关，内存问题主要检查应用程序是否存在内存泄露，如果发生了泄露，PROCESS\PRIVATE BYTES计数器和PROCESS\WORKING SET计数器的值往往会升高,同时AVALIABLE BYTES的值会降低.内存泄露应该通过一个长时间的测试来检查,主要测试当所有内存都耗尽时应用程序的反应情况;
PROCESSOR相关,判断应用程序是否存在处理器的瓶颈如果PROCESSOR QUEUE LENGTH显示的队列长度保持不变(&=2),且处理器的利用率%PROCESSOR TIME超过90%,那么很可能存在处理器瓶颈;如果发现PROCESSOR QUEUE LENGTH显示的队列长度超过2,而处理器利用率却一直很低,那么或许更应该去解决处理器的阻塞问题,处理器一般不是瓶颈;如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(CONTEXT SWITCHES/SEC,显示的上下文切换次数)比较大,那么就会造成大量的系统资源;如果系统吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在1500以上,那么意味着上下文切换的次数过高;还可以比较CONTEXT SWITCHES/SEC和%PRIVILEGED TIME来判断上下文切换是否过量;如果后者的值超过40%,且上下文切换的速率也很高,那么应该检查为什么会产生这么高的上下文切换;
网络吞吐量及带宽BYTES TOTAL/SEC: 判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较,相除结果应该小于50%;
磁盘相关判断磁盘瓶颈的方法是通过以下的公式来计算:每磁盘的I/O数=[读次数+(4*写次数)]/磁盘个数如果计算的每磁盘的I/O数大于磁盘的处理能力,那么磁盘存在瓶颈;
WEB SERVER相关
数据库服务器相关
　　6.使用测试管理工具进行统一管理　　LR和MERCURY QUALIY CENTER的完美结合，给用户组织和管理LOADRUNNER的测试脚本，场景和测试数据带来了极大的便利。QUALITY CENTER是MERCURY 提出的针对质量保证的解决方案。只要将LR连接到基于WEB的QUALITY CENTER，则场景的存储执行和测试结果的收集就会随时随地被MERCURY QUALITY CENTER的测试项目进行有效的管理；
　　1&连接到QUALITY CENTER　　要想让LOADRUNNER使用一个QUALITY CENTER 对测试内容进行管理，首先必须通过URL连接到QUALITY CENTER，这个QUALITY CENTER 既可以是安装在本地的局域网上，也可以是通过广域网访问的测试管理平台；
　　在CONTROLLER模块中，选择TOOLS|QUALITY CENTER CONNECTION 命令，弹出QUALITY CENTER CONNECTION 对话框，在SERVER文本框中输入安装了QUALITY CENTER的WEB服务器的URL地址，单击CONNECT按钮，系统会试图建立对QUALITY CENTER服务器的连接，如果连接建立成功，则会在PROJECT CONNECTION 一栏显示QUALITY CENTER的项目；
　　在PROJECT CONNECTION 一栏输入相关的内容，即选定要连接的测试管理项目，单击CONNECT按钮，系统开始对相应的项目建立连接。一旦建立成功，则QUALITY CENTER的项目信息就变为只读状态；
　　2&断开服务器或项目　　在连接状态中，可以随时单击DISCONNECT 按钮断开QUALITY CENTER服务器或项目的连接；
　　3&打开/保存测试项目场景　　如果LOADRUNNER正在连接到一个测试管理工具上，那么在保存和打开场景的时候，系统弹出的对话框会有所不同，如果仍然希望在文件系统中打开/保存场景，可以单击对话框中的FILE SYSTEM按钮进行切换；关于测试管理工具如何管理和调用LOADRUNNER的场景，请参考TD。
　　五. 利用ANALYSIS分析测试结果　　这个模块是最难最复杂,也是众多LR工程师最头痛的部分,为了更快更多的找出系统存在的性能瓶颈,必须对LR控制器生成的性能指标数据进行分析, LR的ANALYSIS模块是分析系统的性能指标的一个主要工具,它能够直接打开场景的执行结果文件,将场景数据信息生成相关的图表进行显示.ANALYSIS集成了强大的数据统计分析功能,允许测试员对图表进行比较和合并等多种操作,分析后的图表能够自动生成需要的测试报告文档;ANALYSIS作为LR的一个主要模块,是帮助测试人员分析系统性能瓶颈的得力助手;
　　在ANALYSIS中包含了很多在场景运行过程中获取了很多和性能相关的数据的图表;针对每一个被测应用来说,到底哪个性能指标是影响性能的关键了.了解常用的性能指标,熟悉使用ANALYSIS分析工具分析测试结果是确定系统瓶颈的关键.再次强调,不同的应用程序,影响其性能的因素也不同,要分析被测软件的性能因素,首先要熟悉被测软件的技术架构; LR除了将获取的原始数据形成直观的图表外,还对数据进行了一些统计,例如在多数分析图表下方的图例列表中,给出了最大值,最小值,平均值,中间值和STD等一些统计字段,便于用户分析。
请各位遵纪守法并注意语言文明