LoadRunner进行性能测试过程讲解

1、LoadRunner讲解,实例讲解性能测试执行过程 软件测试影响力() 沙漠浪 2011-4-25,概述,本次讲解的目的： 能够再经过少量的指导就可以直接在实际工作中使用LR进行性能测试； 演示实例： 综合运维支撑系统用户工单接单的性能测试 讲解的内容： 性能测试执行过程，从中讲解参数化、集合点、事务、检查点、场景设置、结果分析,性能测试执行过程,性能测试执行过程大致分为： 数据准备 录制、编辑及调试脚本 设置及调试场景 执行场景 分析结果,一、数据准备,数据准备是根据测试的需要，在执行测试之前在被测系统中加入的符合要求的数据。 比如，我们在测试接单性能时，需要有待接的工单，那么这些待接的工单

2、就是在数据准备阶段完成的。,一、数据准备,数据准备方法 1. 手工 要加的数据量比较少的情况下可以手工在系统中加。比如加一个接单的用户 2. 使用LR或其他自动化测试工具 在数据量比较多情况下就要使用工具（LR/QTP等），我们常用的就是LR，录制一个加数据的脚本，反复迭代运行脚本或在场景中运行脚本，数据会生成到系统里面去，这种方法也只适用于插入几千条数据,一、数据准备,3. 数据直接写入数据库 这种方法在插入数据时是最快的，但在准备这些插入数据的sql语句（或存储过程）时却很麻烦，因为生成一条系统中能流转的数据需要很多表关联，这个需要开发人员大力协助，最理想的是直接要开发人员提供写好了的存储

3、过程，我们只运行，不过一般情况下由开发人员提供表信息，然后告诉你怎么做，然后自己组装sql。这种方法适用于数据量非常大的情况,二、脚本 录制脚本,录制脚本 操作步骤请参见LR的操作手册，这里说一下需要注意的地方。 1.最好在脚本录制的过程中加入备注、集合点和事务 2.在编辑脚本前备份一个原始脚本 3.再录制一个同样操作的脚本，用于与刚才录制的脚本进行对比，查找出哪些需要参数化值 4.两个用于进行对比的脚本存放的绝对路径不要太长，比如桌面，这时将无法比较,二、脚本 插入集合点,插入集合点的目的就是控制所有用户同时并发开始执行某个动作。 例：测试用户并发接单的性能，则把集合点插入到接单动作提交的前

4、面。这时，先到的用户该集合点的用户要等后到集合点的用户，然后一起执行提交操作。,二、脚本 插入事务,添加事务的主要目的就是要得到事务开始时间和事务结束时间之间的间隔时间，即事务响应时间； 我们把关注的某些动作定义为一个事务，在场景运行时，LR就会自动记录该事务的所花的时间； 如果场景是多用户并发，迭代多次，则LR会给出事务最大的响应时间、最小响应时间和平均响应时间，我们一般看的是平均响应时间； 一个脚本中可以加入多个事务，一个事务也放到另一个事务里面；,二、脚本 参数化,找出需要参数化的字段 1.打开一个脚本，选择另一个相同操作步骤的脚本用比较器比较,在比较器中查看两个脚本不同的地方，脚本中不

5、同的地方用黄色标识出来 可能会标识出很多不同的地方，但有些地方我们可以不去管它，比如下载的图片资源，思考时间等，有些地方则是很可能要参数化的，比如某某ID 或value一串类似随机字符串，根据经验初步判断哪些是需要参数化的记录下来。,二、脚本 参数化,二、脚本 参数化,从相关开发人员那里获取得到这些值的SQL语句 找开发人员要sql语句之前，我们必须清楚我们需要什么样的数据，比如：接单脚本参数化我们需要特定人待办的用户工单的recordsn字段的值 一般项目经理都会告诉你谁开发哪一块，测哪块的程序，找相关的开发人员即可，并且他们也会大致告诉你这些表是做什么用的，这些信息是很有用的，以后我们可以

6、自己改sql语句得到更适合我们测试的sql语句。,二、脚本 参数化,待接单参数化需要的sql语句如下： select m.clogcode,d.recordsn from svr_pub_da_dispqueue d,org_user o,svr_pub_da_mainqueue m where d.mainsn=m.mainsn and d.repairoper = o.userid （表与表间的关联） and m.business=961300261A9D55CD70029C68FE8C4F4F （工单类型：用户工单） and cessflag = ACCEPT （过程标识：接单

7、） and o.loginname = 张林（当前待办箱：张林） and clogcode Like zl% （附加标识：准备数据时方便以后自己识别加入的特殊标识） Order By clogcode 另：svr_pub_da_dispqueue派工工单处理表，也就是子单的一些信息 svr_pub_da_mainqueue工单主表，也就是主单的信息，张主单包含多张子单,二、脚本 参数化,参数化 1.建立参数化文件*.dat，放入脚本文件夹内 2.在PLSQL中根据sql语句查询出所得的数据，拷贝到参数化文件内 3.在脚本中找到要参数化的字段，对其进行参数化，引用参数化文件中的数据,二、脚本 参

8、数化,调试脚本，验证参数化是否正确 1.在脚本编辑器中用少量的迭代次数反复运行脚本； 2.在场景中用少量并发数和迭代数运行脚本。 参照下面规则，如果两种验证方式都通过，则参数化成功，否则继续调试脚本。,二、脚本 参数化,是否参数化成功规则： 如果迭代运行通过，并且使用的参数化值正确，并且被测系统得到的结果和预期结果相同（工单正确流转），则参数化成功； 如果迭代运行不通过，或者引用的参数化的值不是预期的值，或者被测系统中对应的工单没有正确流转，则参数化不成功，此时需要： 1.根据错误提示解决问题；（比如服务器未连上） 2.检查参数化值，取数据的方式设置是否正确，调整设置；（比如参数化值的数量不够

9、） 3.检查sql语句查出来的数据是否符合要求，主要是看条件限制是否足够，调整sql语句；（比如需要的是某人的待接单，但查得的是所有未归档单据） 4.检查是否还有需要参数化的值，需要参数化的值再进行参数化（比如有两个字段需要参数化，但只对一个字段进行了参数化） 5.运行脚本，重复上面的动作，直至参数化成功为止,二、脚本 检查点,为什么要加入检查点 检查点是检查脚本运行后，是否真的得到了预期结果。 因为曾经发现场景运行后，LR反馈事务运行成功，但其实没有真正运行成功，工单没有流转。虽然我们可以在数据库中查询工单的状态，但插入检查点后，在场景运行的过程中就可以看到事务运行是否出现了问题，比在数据库

10、中看更加方便；另外，像测试查询的性能类的脚本，在数据库中是看不到变化的，所以插入检查点就是非常必要的了。,二、脚本 检查点,检查点实例（接单脚本的检查点） 首先要考虑，在系统中我们手工接单的时候是怎么判断工单流转是否成功的，是看接单后工单状态是否变为了“待回单”，那么，我们就以此做为检查点。 接着要在脚本中找到插入检查点的正确位置。在录制接单脚本时，已经为设置检查点做了准备，在接单完成后又在待办箱查询了一次刚才接的工单。检查点就设在查询出的工单那里。,二、脚本 检查点,检查点实例（接单脚本的检查点） 加入检查点函数： web_reg_find(Text=title=待回单, SaveCount

11、=i, LAST); 检查当前页面上是否有“Text=title=”待回单”这个字符串，把找到的次数保存在i这个变量里面，因为这个函数必须是先注册再用，所以把上面这段代码加在查询前面。 在用户工单待办箱页面上可以看到，查询出一张待回单工单，页面上会有两个待回单的图标标识，意味着，i2时，才是查到一张待回单，如果i1，脚本运行也不会报错，但其实工单并没有流转到待回单。所以我们要对i值进行判断，看是否等于2 if (atoi(lr_eval_string(i) =2) lr_output_message(找到2次,操作成功！); else if(atoi(lr_eval_string(i) =1)

12、 lr_error_message(找到1次，操作没成功！); else if。 上面这段代码要加在查询后面，查询之后才能看到结果。场景运行时，如果待回单标识只找到一次，就会有错误报出来，lr_error_message实现。,二、脚本 检查点,检查点实例（接单脚本的检查点） 根据检查点函数收集到的数值，判断工单是否流转成功： 在用户工单待办箱页面上可以看到，查询出一张待回单工单，页面上会有两个待回单的图标标识，意味着，i2时，才是查到一张待回单，如果i1，脚本运行也不会报错，但其实工单并没有流转到待回单。所以我们要对i值进行判断，看是否等于2 if (atoi(lr_eval_string(

13、i) =2) lr_output_message(找到2次,操作成功！); else if(atoi(lr_eval_string(i) =1) lr_error_message(找到1次，操作没成功！); else if。 上面这段代码要加在查询后面，因为查询之后才能看到结果。场景运行过程中，如果待回单标识只找到一次，就会有错误在场景执行界面报出来，由lr_error_message实现。,二、脚本 检查点,调试脚本，验证检查点是否起作用 至少要用一个验证反例来验证检查点是否真的有效。 比如，更改验证的字符串标识为“待接单”，运行场景查询同样的待回单工单出来，看是否报错； 如果不报错，说明检

14、查点没起作用，要检查加入的检查点位置是否正确，语句是否正确，或改用其他检查方式来设检查点； 如果反馈报错信息“找到1次，操作没成功！”说明检查点设置生效了，可以继续往下做。,二、脚本 调整脚本,在脚本调试的过程中，我们已经执行了很多次场景了，在没有正式测试之前就有可能发现系统的什么地方比较非常耗时，甚至导致运行不到我们本次测试关注的地方。在这种情况下，我们可以对那些比较耗时的代码段专门再加事务，正式测试的过程中也关注一下这个事务；如果是影响到我们后面运行的代码段，且屏蔽掉后不影响本次测试的，则先屏蔽掉该代码段，继续后面的测试，但在测试报告中告之该代码段对应的操作性能有问题。,二、脚本 调整脚本

15、,实例： 原来的系统，进入工单查询界面会默认刷新一次显示一页工单，然后才可输入查询条件查询。当然录制根据条件查询的脚本也是这个过程。 问题是在基础数量很大的情况下，进入工单查询，默认刷新页面这个动作基本上完成不了，所以后面的根据条件来查询也就测不了。所以最后在脚本中屏蔽掉了默认刷新的代码，继续输入查询条件查询的性能测试。当然默认刷新显示不了工单列表的问题也要告之开发组。在以后发布的测试版本中，开发组针对此问题作了改进，在进入工单查询界面时，不默认刷新出工单列表，而是让用户自己输入查询条件，从而避免了上述问题。 至于如何知道某个操作对应在脚本中的代码，就是我在前面录制脚本中提到的要多写操作的备注

16、信息，方便查找。,三、场景 场景分类,场景模式的选择 场景分为手工场景和面向目标的场景。 手工场景要达到某个测试目的需要根据场景每次运行的结果，需要使用者自己调整虚拟用户数，直到达到预期目标。 面向目标场景是在场景运行前设置了目标值，LR在运行的过程中自动逐步加载虚拟用户以达到预设的目标。 目前我们用的都是手工场景，面向目标的场景还没有仔细研究过，但前不久我试验了一下，手工场景和面向对象场景得出的结果差别还比较大，现在还不知道具体原因，待以后解决。,三、场景 场景设置,选择脚本 设置并发用户数 输入要使用资源的电脑IP或主机名，连接上 Run-time Settings,设置迭代次数、设置每次

17、迭代的间隔时间、设置只输出标准日志、忽略思考时间、局域网内不使用代理 设置检查点有效,三、场景 场景设置,设置集合点。 并发用户数多的情况下，选择第一或第三项，可以让所有用户都到达集合点后才开始事务；如果使用默认的第二项，所有正在运行的用户到达集合点后，就开始运行事务了，此时可能还有用户还处在初始化阶段，没有运行，执行的并发数是没有到达预期设计的； 并发数小的情况下，使用哪项都无所谓； 可以适当将两个用户之间的等待时间设置大点。顺便说一下，关于这里设置的超时，是设置的前后两个虚拟用户到达集合点的间隔，不是第一个虚拟用户与最后一个虚拟用户到达集合点的时间间隔。,三、场景 场景设置,设置登入方式

18、如果并发用户数较大，最好选择分批登入。如果选择一次全部登入，有可能在登入被测系统时就运行失败了，虽然在登入时候并没有设置集合点，但登入时间也是相对集中的，压力较大。,三、场景 场景设置,选择自动载入分析，场景运行结束后会自动载入分析结果；如果没有选择，点工具栏上的“Analyze Results”按钮也可以载入结果,三、场景 场景设置,设置结果保存路径，也可以设置自动保存结果，但一般不要选择自动覆盖结果，以免误操作覆盖掉以前有用的结果,三、场景 场景设置,加入需要监控主机及相关系统资源计数器 将被测系统的服务器的操作系统拖入显示窗口 在窗口中点右键，增加一个服务器的IP，联接上该服务器 选择关

19、注的系统资源计数器,三、场景 场景设置,加入oracle指标计数器 将oracle拖入显示窗口,三、场景 场景设置,连接oracle，其中server name是你本机配置的服务名，登入用户可以是system也可以是其他用户,三、场景 场景设置,加入关注的计数器，注意选择obiect时选择第三项，否则得不到数据。至于这一项具体的内容，介绍一个网址，大家可以去看看： 这里面有一些常用统计的解释，内容较多不在此列出。,三、场景 场景设置,比如加入physical reads,三、场景 场景执行,在场景执行的过程中，可以看到执行的信息，如果发现有大量事务报错 或 执行时间特别长，可以终止本次执行；但

20、要根据报错信息判断是否因为系统无法支撑本次并发数导致的，如果是，则要减少用户数后再次执行；如果不是，查找错误原因，解决错误之后再次执行。 对同一类场景，要多执行几次，找出出现次数较多的那个响应时间。 另外，在监控linux系统的性能指标时，可以用vmstat、iostat命令来获得一些信息供以后分析。,三、结果分析 结果摘要,分析结果摘要中包括了本次测试结果大概的信息，我们关注比较多的有： 执行的场景的路径，保存结果的路径，执行了多长时间 最大并发用户数 事务的通过数，失败数，终止数 事务的响应时间 返回的http状态代码 ，主要看有没有错误信息（参考附件“返回http代码状态”）,三、结果分

21、析 加入新图表,加入新图表，通常有操作系统相关、数据库相关、事务相关、网页细分相关,三、结果分析 事务分析,查看事务是否通过及响应时间 在事务摘要中，看要测试的事务（比如接单事务）是否全部运行通过。如果没有全部通过，说明在场景运行的过程中出了问题，查找原因；如果全部通过接着查看下面的； 如果加有检查点的事务，看检查点事务是否全部运行成功；如果没有全部通过，说明在场景运行的过程中出了问题，查找原因；如果全部通过接着查看下面的； 事务执行后可以在数据库中看到相应的变化，最好查看数据库里面的记录的变化内容及数量，是否与前面的事务执行通过数一致。如果是一致的才算是场景真的执行通过了； 事务全部通过了，

22、它的平均响应时间才有意义。查看它的平均响应时间是否在我们的要求内，适当增减并发用户数再执行。,三、结果分析 事务分析,事务执行未通过，考虑： 是否需要更改场景运行的设置（比如接受HTTP请求响应时间默认是120秒超时，如果需要可以改大一点） 负载过大，服务器的系统资源（CPU、内存、磁盘等）不足以支持事务执行；这种情况下，要分析是哪种系统资源不足，然后再分析是硬件瓶颈引起的还是由程序引起的。 负载不大，服务器所有资源充足，但仍有事务未运行成功。这种情况主要考虑是否是被测程序的问题。 事务响应时间过长，同上面的第二和第三点,三、结果分析 获取常用性能指标,目前在做性能测试的时候，如果测的是win

23、dows系统，一般就只用LR监控就可以了，在设置场景时加入windows相关的计数器；如果测试的是linux系统，则还要用linux的命令（常用的有vmstat、iostat），因为LR里面包含的linux相关的计数器比较少，所以用这些命令做为补充。,三、结果分析 常用指标分析,LR指标CPU Utilization(CPU利用率) 一般认为，CPU连续长时间处在95（90）以上，则可能是CPU的瓶颈。 “长时间”究竟定义为多长？以前我认为是5秒，因为经常说用户能忍受的响应时间是5秒，连续5秒CPU都占用95以上，那事务响应时间很有可能就在5秒以上了；后来做了几次测试之后我发觉有一点不对，如果

24、抛开用户能够承受的事务响应时间，单单来找系统瓶颈时会发现，5秒其实是一个很短的时间。现在我认为“长时间”只是个相对数，相对于事务的执行时间。 比如说，假如事务执行时间有10秒，而在事务执行的这段时间内大部分时间（8秒）CPU占用率都在95以上，那么可以说8秒的时间较长了，可能CPU资源是系统瓶颈；但如果事务执行时间是60秒，其中有连续10秒钟CPU占用在95以上，那么这10秒其实算是比较短的了，应该是其他问题导致事务运行花了60秒。,三、结果分析 常用指标分析,LR指标CPU Utilization(CPU利用率) 在LR的分析结果中可以看到CPU的平均值，在很多情况下，CPU的平均值都不到9

25、0%，但已经可以认为CPU是系统瓶颈了。因为我们在执行场景的时间一般不会太长，所以，在场景刚开始运行时CPU的小值对平均值的影响较大，如果场景运行时迭代次数足够多，运行时间足够长则不会存在该问题。在目前的情况下，我们主要还是看事务处理过程中的CPU的利用率，而不是去看平均值，平均值、最大值、最小值，只能做为参考。 CPU的占用是系统占用和用户占用之和。一般情况下，系统占用率是很小，5%可能都不到，主要用户占用多，所以平常我们先看一下是否系统占用是否正常，然后就只看CPU占用的总数就可以了。,三、结果分析 常用指标分析,LR指标内存相关 主要看可用内存 和 是否频繁换页 如果系统可用内存变的很小

26、，内存可能成为系统瓶颈 如果页交换频繁，将严重影响系统性能,三、结果分析 常用指标分析,LR指标内存相关 可用内存 如果是windows系统，直接在LR里面看free的值就行了，建议阀值是4M，不能小于4M。如果发现已经接近4M了，说明可用物理内存不够了。 如果是linux系统，LR里面没有可用物理内存大小的参数。需借助于vmstat命令，后面详述。,三、结果分析 常用指标分析,LR指标内存相关 页交换 主要看page-out rate 每秒从物理内存中换出到磁盘上页交换文件的页数。 这里可以看到平均值、最大最小值，如果平均值很大，说明有很多的页交换发生，内存可能不足，需要告诉开发组查找原因。

27、 至于值为多大才算大，在网上也没有找到一个确数，可能要靠经验的积累。不过如果是达到几百，页交换应该是比较频繁了。,三、结果分析 常用指标分析,LR指标Average load （平均负载） 在过去的1分钟内运行队列中的平均进程数量。 该数值除以cpu个数（逻辑个数）小于5，则是在可接受的范围，否则说明该服务器负载过重。,三、结果分析 常用指标分析,LR指标Oracle相关 SELECT name,value FROM V$sysstat WHERE name=redo log space request; 此处value的值应接近于0，否则，应增大初始化参数文件的Log_buffers的值 通

28、过查询V$sysstat表判定redo log （重做日志）文件缓冲区是否足够。 实际测试过程中，只需要在场景中添加“redo log space request ”这个计数器即可。,三、结果分析 常用指标分析,LR指标数据库缓冲命中率： 命中率=1-physical reads/(dbblock gets+consistent gets) 该值要在90以上，如果小于90，则要考虑增加data buffer（数据缓冲区）的大小,三、结果分析 常用指标分析,对linux系统性能的监控和分析，用LR关注的比较少，主要用的是vmstat 和 iostat命令。 vmstat 对系统的进程情况、内存使

29、用情况、交换页和 I/O 块使用情况、中断以及 CPU 使用情况进行统计并报告相应的信息。第一个显示内容指出了计算机重启至今的平均使用情况。后面的每一行信息是按 延时定期地显示系统的各部分信息。进程信息和内存信息都是即时产生的。 iostat也包括了CPU的使用情况，不过它的主要特点是汇报磁盘活动的情况。如果用vmstat命令发现问题可能与磁盘相关，则再用iostat命令来进一步分析磁盘活动。,三、结果分析 常用指标分析,Vmstat命令 roottest2 # vmstat 1 procs -memory- -swap- -io-system- cpu r b swpd free buff

30、cache si so bi bo in cs us sy id wa 对上面我们关注的指标的分析： r:进程等待队列长度，阀值是cpu个数*4,这里的cpu个数指的是逻辑cpu的个数（ cat /proc/cpuinfo可以看到）。 id：CPU的空闲时间。粗略的来看，反过来就是占用时间。,三、结果分析 常用指标分析,Vmstat命令相关指标的分析 从r和id值看CPU的使用情况。 如果r值长时间很大、id值长时间很小，（长时间有很多进程等待，且cpu占用长时间很大），说明CPU资源有可能不足； 如果r值长时间很大，id值只是偶尔很小，（长时间有很多进程等待，但cpu大部分时间空闲），说明应

31、该不是cpu硬件处理能力的问题，要找程序的原因； 如果r值偶尔很大、id值长时间很小， （偶尔有较多的进程等待处理，但大部分不是，但cpu占用长时间很大），虽然CPU占用很厉害，但只要有进程过来基本上马上就能处理，至少目前不能说明cpu资源不足。在实际测试的过程中也可以看到这种情况，但事务响应较快。,三、结果分析 常用指标分析,Vmstat命令相关指标的分析 free: 空闲的内存，单位KB buff: 被用来做为缓存的内存数，单位：KB cache：被用来做为cache的内存数，单位：KB vmstat得到的free的值与windows系统的free值不同，不是可用内存，是自由内存，就是还没有被使用过的内存；linux的内存管理机制认为，用户可用的内存freebuffcache，所以单看free值是没有意义的。经常会看到free值很小，只有23M，但实际可用物理内存要大的多。,三、结果分析 常用指标分析,Vmstat命令相关指标的分析 swpd: 虚拟内存使用情况，单位：KB si: 从磁盘交换到内存的交换页数量