MI检验工具LoadRunner基本培训.ppt

《MI检验工具LoadRunner基本培训.ppt》由会员分享，可在线阅读，更多相关《MI检验工具LoadRunner基本培训.ppt（35页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、LoadRunner培训,负载(Stress)测试工具使用基础培训,1. LoadRunner基本介绍,题目,题目,2. 用LoadRunner测试的步骤,3. 工具使用之一: 录制脚本,4. 工具使用之二: 修改脚本,5. 工具使用之三: 创建场景,6. 工具使用之四: 运行测试,7. 工具使用之五: 分析结果,8. LoadRunner目前的使用情况,LoadRunner基本介绍,1.1 LoadRunner基本介绍,1.2 LoadRunner运行的典型场景,1.3 常用语,1.1 LoadRunner基本介绍,1. Mercury Interactive公司的压力测试工具LoadRun

2、ner，是目前软件负载测试的工业标准,2.LoadRunner是通过模拟多个用户并发负载，并进行实时监控的方式来进行测试,3.支持多种协议，包括HTTP、 WAP 、winsock、Tuxedo、Oracle,4.与其它负载测试工具的不同在于，LoadRunner的每一个虚拟用户所占用的系统资源较少，适合于用较少的负载测试机器来达到大规模的负载测试所要求的并发压力,5. LoadRunner适用于网络应用的负载测试,1.2 LoadRunner运行的典型场景,1.3 常用语,1.Controler: 负责场景的控制，脚本的分发，运行时数据的收集，测试结果的收集 2. Generator: 性能

3、测试中实际压力的发起者，主要是将Controler传送过来的脚本，按场景所要求的运行属性进行收发包的动作；另外，也负责运行时数据的采集 3. Monitor: 负责收集运行时各主机，数据库待测系统的数据，并形成实时的曲线，用于性能测试运行时的实时分析；Monitor总是在Controler所在的机器上 4. Analysis: 主要将收集到的最终的性能测试结果进行统计分析，并形成图表，便于分析系统的总体的性能结果 5. Vuser: 是包含有各种运行时属性（循环次数，打印级别等）的脚本 6. Scenario: 将各脚本按组的方式组织，按指定的运行时环境进行控制，分发，并监控运行情况 7. T

4、ransaction: 脚本中的一部分，用于场景运行时(运行后)，分析该段脚本的各响应时间指标(如平均响应时间、90%响应时间),这是分析用户行为的重要数据,注：Controler和Generator只是逻辑上的区分，即它们可以在同一台物理机器上,2. 用LoadRunner测试的步骤,2.1 用LoadRunner测试的步骤,2.2 最重要的是拟定计划,2.1 用LoadRunner测试的步骤,2.2 最重要的是拟定计划,1.分析应用：进行负载测试前需要了解系统的结构；了解现网的实际部署要求；了解用户的使用方式及行为；了解配置的不同对系统的影响,2.定义测试目标：例如在较大压力下用户可以接受

5、的最大响应延时是多少；系统要求的在多大的压力下不会出错；在多大的压力下出错率为多少是可以接受的；在多大的压力下系统不会崩溃；测试目的是找到系统的最大处理能力，还是找出系统中有瓶颈的地方,3.设计测试所需环境的配置：以上两点结束后，才能给出负载测试的机器配置要求、并发数要求、网络配置要求、以及设计每一个场景，并给出场景成功或者失败的指标，以及场景重复运行的环境准备要求,3. 工具使用之一：录制脚本,3.1 选择脚本类型,3.2 脚本的例子,3.3 录制脚本,3.4 回放脚本确认脚本的有效性,3.1 选择脚本类型,1.当做好测试计划后，就知道需要使用何种类型的脚本了，目前LoadRunner可以支

6、持的脚本类型，可以从Virtual User Generator的新建菜单中选择，如下图： 2.实际的脚本会根据所选择的不同类型，而自动include不同的头文件,3.2 脚本的例子,1.左上图为Web(HTTP/HTML)类型的脚本，其它类型的脚本也基本相同 2.可以看出，脚本是类似C的语言 3.脚本分为Vuser_init、Action、Vuser_end三部分 4.值得注意的是，每一个虚拟用户在脚本的执行过程中，只会运行一次Vuser_init，再运行多次循环的Action部分，最后运行一次Vuser_end，这可以从脚本的Run Time Setting中看到,如左下图,3.3 录制脚

7、本,1.LoadRunner的脚本，一般采用录制的过程获取初始脚本，点击工具栏的可以开始录制 2.在弹出的Start Recoding对话框中可以进行更多选项的修改，例如加入浏览器的起始URL，还可以选择录制的脚本是放在init,Action,end三部分中的哪一部分，一般都选择放在Action部分，点击Options按钮，进入高级选项(里面的设置的变化，LoadRunner会自动记忆），里面有许多可设置部分，这里提到一点：Recoding Level,HTML-Based Script是以HTML的方式来理解录制时的行为，记录的脚本与操作一致，但对于Session类操作或者一些列表类的点击与

8、期望有出入，例如录制的脚本多为web_url()等函数 URL-Based Script是以HTTP的方式来理解录制时的行为，记录的脚本与操作有一定差异，基本上将一个操作分解为多个HTTP请求，可以处理Session类操作或者一些列表类的点击，例如录制的脚本多为web_custom_request()等函数 建议一般Web类脚本采用HTML-Based Script方式，如果有问题，再采用URL-Based Script方式,3.3 录制脚本(续),3.录制时的每一个HTTP请求，都会被按操作顺序记录在脚本里，形成一个或多个LoadRunner的函数，也可以手工写这些函数，具体的函数的使用，参

9、见帮助 4.录制时就应该设置Transaction的动作，(当然，也可以录制完成后再进行设置),方法在是某个需要设置Transaction的动作前设置事务的起始点，如下图在该动作后设置事务的结束点，例如录制一个登录邮箱的动作，在首页点了几个链接后，登录前填好用户名和密码，在点击“登录”按钮之前设置事务起始点“Login”，在点击登录后，邮箱完全显示后，再设置事务结束点“Login”，这样一个Login的事务就设置完成了，生成的脚本如右图： 5.一个脚本中可以有多个事务，事务可以嵌套 6.录制完成后，点击stop按钮，即上图中左数第3个按钮，可以结束脚本的录制，接着可以存盘,3.4 回放脚本确认

10、脚本有效性,当脚本录制完成，并存盘后，应立即回放脚本，以检查是否通过 回放脚本的动作是Run一次脚本，或者点击F5 回放完成后，会有界面弹出，指明该脚本是否执行成功，如下图 如回放通过，则脚本录制就算基本完成,4. 工具使用之二：修改脚本,4.1 参数化,4.2 加入打印信息,4.3 同步点的概念,4.4 备注,4.1 参数化,1.大部分的脚本都需要参数化，例如，一个登录脚本只记录了以一个用户名/密码对登录某个系统，但要达到以不同的用户名/密码对登录，则需要用到参数化 2.参数化就是将脚本中的某个字符串替换为一个参数列表的动作 3.参数化的方法很简单，在脚本中将某个字符串选中，点右键，选择Re

11、place With a Parameter,出现右上图： 4.确定后，脚本中原有字符串被替换成参数名 5.参数化时，参数类型可以采用多种方式，如File、Date/Time、Random Num，以下以File方式来讲解 6.文件方式的参数化是较为常见的一种参数化方式，参数文件以ASCII码文件显示，一般需要手工修改该文件的内容 7.参数属性窗口(右下图）中有几个需要注意的地方： A Sequential B Unique,4.1 参数化(续),考虑做一个10 X 50的负载测试的参数化，即10个并发，每个虚拟用户循环50次,采用文件方式参数化，则： Sequential的方式从参数文件中读

12、取前50行，分给第一个虚拟用户；仍然取这50行，分给第二个虚拟用户，所有的虚拟用户都用前50行，后面的数据无效 Unique的方式从参数文件中读取前50行，分给第一个虚拟用户；再从参数文件中读取接下来的50行，分给第二个虚拟用户，所有的虚拟用户都取不同50行，共从参数文件中获取500条数据. 注：参数文件以及参数文件的设置属于脚本的属性，一直跟随脚本 实际运行时，每个虚拟用户的执行不会按给它的参数的顺序来执行，即单个虚拟用户运行时的所采用的参数是无序的 当参数文件不够用时，在场景里初始化时，会报错,4.2 加入打印信息,1.在负载测试正在进行中，如果出现问题，很难找到问题在哪里，例如web脚本

13、运行时，LoadRunner的Controler通常以返回的HTTP头信息中的状态标识来决定成功与否，例如，状态200为通过；现有的应用已经很智能化，如果未找到页面，也会重定向一个友好的出错提示页面，这样返回200，LoadRunner却不知道应用已报错 2.一般而言对于上述情况，可以采用以下方法处理：LoadRunner先进行条件判断，如果不满足条件，则在运行时以及报告里打印信息，来报错，典型的例子为登录时用户不存在，可以采用以下方法： A）检查登录后的返回页面中有无特征字符串或特征图片 B）如未找到匹配值，则打印一条信息 3.常用的打印函数有几个，如lr_errro_message(),l

14、r_output_message()等等 4.打印信息也常用于跟踪每个虚拟用户的事务状态，例如在脚本的多处加入打印信息，一旦出错，能够知道错误具体是在虚拟用户做哪一个操作时出的错,4.3 同步点的概念,1.首先提到的应该是LoadRunner在执行负载测试时各虚拟用户的运行情况，每个虚拟用户都会不间断地按照Action里的语句来执行，此时会有一个问题，即很难保证每个虚拟用户都是同时发起请求的,可能一个用户在发起请求时，其它的一些用户都在等待上一个请求的回应，这样如果10 X 50的负载测试时，实际对服务器的压力没有10个并发，当事务响应时间越长，则实际的并发量则越小 2.同步点的目的就是让所有

15、的虚拟用户在同一时刻发起下面的请求，它能保证后面紧接的一个请求是所有虚拟用户同时发起的 3.当设置同步点后，先运行完的虚拟用户会在同步点处等待，直到所有的虚拟用户都到达该点后，再同时发起请求 4.设置同步点可以直接在脚本中写lr_rendezvous()函数;,rendezvous,Action Of Script,4.4 备注,1.Session的控制 Session用得越来越多了，这样会导致原来录制的脚本，在以后回放时，由于Session串已不存在，则会报错，因为Session是自动生成的，每次都不一样 解决方法是在产生Session之前的脚本前面加入以下函数：web_reg_save_p

16、aram(“ParaName”,”LB=XXX”,”RB=“YYY”,LAST); 原脚本中以后的请求中的Session串用该函数中的参数名代替 该函数的实际处理动作是从接下来的HTTP请求的返回包体中找到一个满足左边界为字符串XXX，右边界为字符串YYY的地方，并将两个字符串中间的部分保存为Session的值，以便以后使用,即 XXXnnnnnnnnnYYY 如果出现在下面的返回包体中，则nnnnnnnnn这个串的值将会作为未来的Session串来使用,5. 工具使用之三：创建场景,5.1 场景的创建,5.2 场景的属性修改,5.3 场景的保存,5.1 场景的创建,1.场景的创建可以从Con

17、troler里新建一个,也可以从Virtual User Generator中直接生成，以下讲从Controler里新建场景 2.创建场景的始初框中有两种选则，一为手工创建场景，另一个为基于目标的场景，后者主要是给定一些条件，让LoadRunner自己去控制运行时的Vsser的多少,例如让Vusr数从50个到100个变动，直到点击率达到30后，再运行30分钟后退出 3.手工创建场景是较常见的,选择已有的Script，加入到场景后，会形成右下图，可以看出，每个Script是以Group的方式存在于场景中的，新建时每个Group并发数为10 4.可以让每个Group采用不同数目的Vuser，在不同

18、的Generator上运行，这样可以进行分布式的负载测试，只要有足够多的Generator机器和License，就可以进行超强的并发压力,5.2 场景的属性修改,1.LoadRunner的脚本是有一些属性的，例如，循环次数，是否有thinktime等等，有些属性跟随脚本带入场景(例如thinktime)，有些属性在场景中还需要重新设置（例如循环次数） 2.所以创建场景后，还应对每个Script的属性分别进行检查，看是否满足场景设计的要求 3.关于Schedual，可以进一步定义场景的运行时属性，例如定义该场景以10个并发开始，每2分钟增加5个并发，直到全部并发上去后，再运行10分钟后，再每30

19、秒停止5个并发用户，直到全部停止，这样可以形成阶梯式的并发，更趋向现网,而且更利于发现问题,5.2 场景的属性修改(续),4.场景的属性修改，可以完成控制每秒种发包数量的功能（一般用于HTTP响应极快时，例如DSMP接口测试） 如果每个请求中有lr_thinktime(1),即Sleep一秒钟，当请求的响应时间很小(千分之几秒）时,这样我们可以将请求包/响应包的时间忽略不计，则N个并发，就是控制了发送包的速度为N个包/秒,5.3 场景的保存,1.场景的保存，可以保存和该场景相关的脚本位置，场景的属性设置，以及测试结果的位置；另外，它还可以保存Monitor相关的测试配置，这样可以大大减少下次重

20、复测试需要的准备时间 2.经验表明,最好把场景,脚本,结果,数据文件保存在一个目录下,再分子目录归类,而数据文件在Script中采用相对路径,这样可以保证这些东西拷到其它机器或其它目录下仍能使用,常用的目录结构如下:,6. 工具使用之四：运行测试,6.1 运行测试完成的事项,6.2 运行时监控待测系统,6.3 运行后注意事项,6.1 运行测试完成的事项,1.当点击Controler里的 按钮时,可以选择Result放置的目录位置，选择并确定后，开始运行测试，运行测试实际完成的动作有： A）编译各脚本(Pending) B）Controler连接各Generator(Init) C）Contro

21、ler将编译后的各脚本以及对应的数据按场景要求，通过FTP方式分发到各Generator机器（Ready) D）各Generator发起请求（对应Run),6.2 运行时监控待测系统,1.Run的时候，可以监控一些数据，分为两类：基本性能数据、服务器性能数据 2.基本性能数据 是从Generator采集的数据，Controler定时从各个Generator上FTP获取，并图形化显示出来,这类数据包括Run Vuser,Transactions Response Time，Hit Per Sencond，Throughput 3.服务器性能数据(需要在场景运行前就进行设置） 是从待测系统的各个服

22、务器采集的数据，这样数据的采集点就在待测系统主机上，部分服务器性能数据可以直接从服务器获取(那些服务器已提供这些数据采集的接口），另外一些需要在服务器上启动相应的Agent或采集进程，具体参考手册描述。（盛晓婷曾专门写过一份Monitor的PPT，请参考） 4.运行时的监控数据会随着场景不断运行，曲线也会不断变动，按目前的经验，这些曲线的变动十分精确地反映了系统的运行情况，建议大家不断参考各手册，并多一些实践来综合分析Monitor曲线的变动的意义。 5.服务器性能数据(如Oracle，Tuxedo，Unix，Weblogic)与具体的应用平台相关，且能帮助分析系统瓶颈，十分重要；一般而言，需

23、要各部分的专家协同进行运行时性能分析，包括了SA，开发人员，DBA。建议在测试计划中明确需要进行的服务器性能采集的种类和需要参与分析的专家列表。,6.3 运行后的注意事项,1.当分布在各Generator机器上的Vusr均运行完毕后，Controler显示运行完成，此时，Controler会从各Generator上获取各Vuser的测试结果，一般而言，这些数据量较大，而且随着并发数和循环次数的增大，数据量也会增大,因此，大规模的压力测试的场景结果收集是需要一定时间的。 2.每个场景运行完成后，都应该进行数据的清理动作，包括数据库的清理，应用中的日志的清理，以便可重复执行；有时候，还需要重启Lo

24、adRunner测试机器,7. 工具使用之五：分析结果,7.1 利用Analysis分析测试结果,7.2 将各曲线叠加分析,7.3 应用瓶颈的分析,7.1 运用Analysis分析测试结果,1.场景的测试结果为一个目录，一般用Analysis程序来分析里面的数据，并形成图表 2.在Controler里面可以直接对刚运行完的场景进行Analysis，也可以通过打开Analysis的程序，再从Analysis的程序里打开某些结果目录 3.由于Analysis进行分析要消耗较多的时间和资源，建议每次分析完成后，在Analysis中保存分析后的结果,7.2 将各曲线叠加分析,1.方法是在某个曲线上点左键，选择Merge Group，从列表中选择另一个曲线，确认后，即可将两个曲线叠加 2.叠加曲线便于分析当某些条件变化时，对系统性能的影响，横坐标为时间，这样可以对同一时间上的变化导到的结果进行分析,7.3 应用瓶颈的分析,1.应用的服务器性能，需要在场景中设置Monitor后，数据才会记录到Result里，最后才能进入Analysis 2.应用瓶颈的分析可以通过在Analysis中New Graph来获取，可以和基本性能数据以及其它的图表同时叠加分析 3.应用瓶颈的分析同样需要专家们的协同工作,感谢大家,