LoadRunner进行性能测试过程讲解.ppt

LoadRunner进行性能测试过程讲解.ppt

《LoadRunner进行性能测试过程讲解.ppt》由会员分享，可在线阅读，更多相关《LoadRunner进行性能测试过程讲解.ppt（59页珍藏版）》请在冰豆网上搜索。

LoadRunner讲解,实例讲解性能测试执行过程软件测试影响力（）沙漠浪2011-4-25,概述,本次讲解的目的：

能够再经过少量的指导就可以直接在实际工作中使用LR进行性能测试；演示实例：

综合运维支撑系统用户工单接单的性能测试讲解的内容：

性能测试执行过程，从中讲解参数化、集合点、事务、检查点、场景设置、结果分析,性能测试执行过程,性能测试执行过程大致分为：

数据准备录制、编辑及调试脚本设置及调试场景执行场景分析结果,一、数据准备,数据准备是根据测试的需要，在执行测试之前在被测系统中加入的符合要求的数据。

比如，我们在测试接单性能时，需要有待接的工单，那么这些待接的工单就是在数据准备阶段完成的。

一、数据准备,数据准备方法1.手工要加的数据量比较少的情况下可以手工在系统中加。

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

这种方法适用于数据量非常大的情况,二、脚本录制脚本,录制脚本操作步骤请参见LR的操作手册，这里说一下需要注意的地方。

1.最好在脚本录制的过程中加入备注、集合点和事务2.在编辑脚本前备份一个原始脚本3.再录制一个同样操作的脚本，用于与刚才录制的脚本进行对比，查找出哪些需要参数化值4.两个用于进行对比的脚本存放的绝对路径不要太长，比如桌面，这时将无法比较,二、脚本插入集合点,插入集合点的目的就是控制所有用户同时并发开始执行某个动作。

例：

测试用户并发接单的性能，则把集合点插入到接单动作提交的前面。

这时，先到的用户该集合点的用户要等后到集合点的用户，然后一起执行提交操作。

二、脚本插入事务,添加事务的主要目的就是要得到事务开始时间和事务结束时间之间的间隔时间，即事务响应时间；我们把关注的某些动作定义为一个事务，在场景运行时，LR就会自动记录该事务的所花的时间；如果场景是多用户并发，迭代多次，则LR会给出事务最大的响应时间、最小响应时间和平均响应时间，我们一般看的是平均响应时间；一个脚本中可以加入多个事务，一个事务也放到另一个事务里面；,二、脚本参数化,找出需要参数化的字段1.打开一个脚本，选择另一个相同操作步骤的脚本用比较器比较,在比较器中查看两个脚本不同的地方，脚本中不同的地方用黄色标识出来可能会标识出很多不同的地方，但有些地方我们可以不去管它，比如下载的图片资源，思考时间等，有些地方则是很可能要参数化的，比如某某ID或value一串类似随机字符串，根据经验初步判断哪些是需要参数化的记录下来。

二、脚本参数化,二、脚本参数化,从相关开发人员那里获取得到这些值的SQL语句找开发人员要sql语句之前，我们必须清楚我们需要什么样的数据，比如：

接单脚本参数化我们需要特定人待办的用户工单的recordsn字段的值一般项目经理都会告诉你谁开发哪一块，测哪块的程序，找相关的开发人员即可，并且他们也会大致告诉你这些表是做什么用的，这些信息是很有用的，以后我们可以自己改sql语句得到更适合我们测试的sql语句。

二、脚本参数化,待接单参数化需要的sql语句如下：

selectm.clogcode,d.recordsnfromsvr_pub_da_dispqueued,org_usero,svr_pub_da_mainqueuemwhered.mainsn=m.mainsnandd.repairoper=o.userid（表与表间的关联）andm.business=961300261A9D55CD70029C68FE8C4F4F（工单类型：

用户工单）andd.processflag=ACCEPT（过程标识：

接单）ando.loginname=张林（当前待办箱：

张林）andclogcodeLikezl%（附加标识：

准备数据时方便以后自己识别加入的特殊标识）OrderByclogcode另：

svr_pub_da_dispqueue派工工单处理表，也就是子单的一些信息svr_pub_da_mainqueue工单主表，也就是主单的信息，张主单包含多张子单,二、脚本参数化,参数化1.建立参数化文件*.dat，放入脚本文件夹内2.在PLSQL中根据sql语句查询出所得的数据，拷贝到参数化文件内3.在脚本中找到要参数化的字段，对其进行参数化，引用参数化文件中的数据,二、脚本参数化,调试脚本，验证参数化是否正确1.在脚本编辑器中用少量的迭代次数反复运行脚本；2.在场景中用少量并发数和迭代数运行脚本。

参照下面规则，如果两种验证方式都通过，则参数化成功，否则继续调试脚本。

二、脚本参数化,是否参数化成功规则：

如果迭代运行通过，并且使用的参数化值正确，并且被测系统得到的结果和预期结果相同（工单正确流转），则参数化成功；如果迭代运行不通过，或者引用的参数化的值不是预期的值，或者被测系统中对应的工单没有正确流转，则参数化不成功，此时需要：

1.根据错误提示解决问题；（比如服务器未连上）2.检查参数化值，取数据的方式设置是否正确，调整设置；（比如参数化值的数量不够）3.检查sql语句查出来的数据是否符合要求，主要是看条件限制是否足够，调整sql语句；（比如需要的是某人的待接单，但查得的是所有未归档单据）4.检查是否还有需要参数化的值，需要参数化的值再进行参数化（比如有两个字段需要参数化，但只对一个字段进行了参数化）5.运行脚本，重复上面的动作，直至参数化成功为止,二、脚本检查点,为什么要加入检查点检查点是检查脚本运行后，是否真的得到了预期结果。

因为曾经发现场景运行后，LR反馈事务运行成功，但其实没有真正运行成功，工单没有流转。

虽然我们可以在数据库中查询工单的状态，但插入检查点后，在场景运行的过程中就可以看到事务运行是否出现了问题，比在数据库中看更加方便；另外，像测试查询的性能类的脚本，在数据库中是看不到变化的，所以插入检查点就是非常必要的了。

二、脚本检查点,检查点实例（接单脚本的检查点）首先要考虑，在系统中我们手工接单的时候是怎么判断工单流转是否成功的，是看接单后工单状态是否变为了“待回单”，那么，我们就以此做为检查点。

接着要在脚本中找到插入检查点的正确位置。

在录制接单脚本时，已经为设置检查点做了准备，在接单完成后又在待办箱查询了一次刚才接的工单。

检查点就设在查询出的工单那里。

二、脚本检查点,检查点实例（接单脚本的检查点）加入检查点函数：

web_reg_find（Text=title=待回单,SaveCount=i,LAST）;检查当前页面上是否有“Text=title=”待回单”这个字符串，把找到的次数保存在i这个变量里面，因为这个函数必须是先注册再用，所以把上面这段代码加在查询前面。

在用户工单待办箱页面上可以看到，查询出一张待回单工单，页面上会有两个待回单的图标标识，意味着，i2时，才是查到一张待回单，如果i1，脚本运行也不会报错，但其实工单并没有流转到待回单。

所以我们要对i值进行判断，看是否等于2if（atoi（lr_eval_string（i）=2）lr_output_message（找到2次,操作成功！

）;elseif（atoi（lr_eval_string（i）=1）lr_error_message（找到1次，操作没成功！

）;elseif。

上面这段代码要加在查询后面，查询之后才能看到结果。

场景运行时，如果待回单标识只找到一次，就会有错误报出来，lr_error_message实现。

二、脚本检查点,检查点实例（接单脚本的检查点）根据检查点函数收集到的数值，判断工单是否流转成功：

在用户工单待办箱页面上可以看到，查询出一张待回单工单，页面上会有两个待回单的图标标识，意味着，i2时，才是查到一张待回单，如果i1，脚本运行也不会报错，但其实工单并没有流转到待回单。

所以我们要对i值进行判断，看是否等于2if（atoi（lr_eval_string（i）=2）lr_output_message（找到2次,操作成功！

）;elseif（atoi（lr_eval_string（i）=1）lr_error_message（找到1次，操作没成功！

）;elseif。

上面这段代码要加在查询后面，因为查询之后才能看到结果。

场景运行过程中，如果待回单标识只找到一次，就会有错误在场景执行界面报出来，由lr_error_message实现。

二、脚本检查点,调试脚本，验证检查点是否起作用至少要用一个验证反例来验证检查点是否真的有效。

比如，更改验证的字符串标识为“待接单”，运行场景查询同样的待回单工单出来，看是否报错；如果不报错，说明检查点没起作用，要检查加入的检查点位置是否正确，语句是否正确，或改用其他检查方式来设检查点；如果反馈报错信息“找到1次，操作没成功！

”说明检查点设置生效了，可以继续往下做。

二、脚本调整脚本,在脚本调试的过程中，我们已经执行了很多次场景了，在没有正式测试之前就有可能发现系统的什么地方比较非常耗时，甚至导致运行不到我们本次测试关注的地方。

在这种情况下，我们可以对那些比较耗时的代码段专门再加事务，正式测试的过程中也关注一下这个事务；如果是影响到我们后面运行的代码段，且屏蔽掉后不影响本次测试的，则先屏蔽掉该代码段，继续后面的测试，但在测试报告中告之该代码段对应的操作性能有问题。

二、脚本调整脚本,实例：

原来的系统，进入工单查询界面会默认刷新一次显示一页工单，然后才可输入查询条件查询。

当然录制根据条件查询的脚本也是这个过程。

问题是在基础数量很大的情况下，进入工单查询，默认刷新页面这个动作基本上完成不了，所以后面的根据条件来查询也就测不了。

所以最后在脚本中屏蔽掉了默认刷新的代码，继续输入查询条件查询的性能测试。

当然默认刷新显示不了工单列表的问题也要告之开发组。

在以后发布的测试版本中，开发组针对此问题作了改进，在进入工单查询界面时，不默认刷新出工单列表，而是让用户自己输入查询条件，从而避免了上述问题。

至于如何知道某个操作对应在脚本中的代码，就是我在前面录制脚本中提到的要多写操作的备注信息，方便查找。

三、场景场景分类,场景模式的选择场景分为手工场景和面向目标的场景。

手工场景要达到某个测试目的需要根据场景每次运行的结果，需要使用者自己调整虚拟用户数，直到达到预期目标。

面向目标场景是在场景运行前设置了目标值，LR在运行的过程中自动逐步加载虚拟用户以达到预设的目标。

目前我们用的都是手工场景，面向目标的场景还没有仔细研究过，但前不久我试验了一下，手工场景和面向对象场景得出的结果差别还比较大，现在还不知道具体原因，待以后解决。

三、场景场景设置,选择脚本设置并发用户数输入要使用资源的电脑IP或主机名，连接上Run-timeSettings,设置迭代次数、设置每次迭代的间隔时间、设置只输出标准日志、忽略思考时间、局域网内不使用代理设置检查点有效,三、场景场景设置,设置集合点。

并发用户数多的情况下，选择第一或第三项，可以让所有用户都到达集合点后才开始事务；如果使用默认的第二项，所有正在运行的用户到达集合点后，就开始运行事务了，此时可能还有用户还处在初始化阶段，没有运行，执行的并发数是没有到达预期设计的；并发数小的情况下，使用哪项都无所谓；可以适当将两个用户之间的等待时间设置大点。

顺便说一下，关于这里设置的超时，是设置的前后两个虚拟用户到达集合点的间隔，不是第一个虚拟用户与最后一个虚拟用户到达集合点的时间间隔。

三、场景场景设置,设置登入方式如