LoadRunner设置检查点的几种方法介绍

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

 前段时间在群里跟大家讨论一个关于性能测试的问题,谈到如何评估测试结果,有一个朋友谈到规范问题,让我颇有感触,他说他们公司每次执行压力测试的时候,都要求脚本中必须有检查点存在,不然测试结果将不被认可,这是他们公司的规范。其实,在做压力测试过程,我们很容易忽略很多东西,而且随着自身的技术演变,我们很容易去丢失掉一些很好的习惯,当我们再碰到这些问题的时候,我们才发现其实是我们太粗心大意了,所以说好的习惯要保持。这次我刚好也要接手一些性能工作,因此就如何规范设置检查点来谈谈一些基本的流程和方法。

  使用LoadRunner做压力测试,大致如下几个流程:

  1、明确测试目标

  2、录制测试脚本

  3、脚本优化、调试

  4、场景运行

  5、分析测试结果

当然这里都是概况性的标题,但从这里我们可以明确的是测试脚本是整个压力测试过程中的重点步骤,如果测试脚本都不能确保正确与否,后面的测试过程就无从说起了。很多时候我们把脚本调试就简单的认为是脚本回放没有错误就认为脚本是没有问题的,这当然不能这么肯定,脚本调试是一个非常严谨的过程,我大致归纳如下几步:

  1、明确每一行脚本的作用,也就是说每一行脚本执行的功能是什么;

  2、删减不需要的脚本语句,比如在录制过程由于LR默认设置导致录制之后出现很多冗余的脚本,这些个脚本对我们的测试过程没有用途的应该删除掉,至于哪些是冗余就要具体分析了,所以说脚本录制完之后要分析脚本运行的过程,方能理解脚本执行的用途,不然在后面施压时运行错误,就会开始到处找问题,而又找不出问题;

  3、查找存在的关联并进行相关设置

  4、设置检查点,设置检查点的目的就是为了验证页面每次运行之后是否正确,设置检查点的过程总要通过不能的回放来进行验证检查点设置是否正确。

  5、通过测试目标明确脚本执行的目标事务,并添加事务;

  6、对需要进行并打操作的功能设置集合点

  7、根据实际情况设置ThinkTime

  8、在以上所有脚本调试步骤完成之后,设置迭代次数,通过在Vuser中设置多次迭代来验证脚本在多次循环运行时是否存在错误

注意:在Vuser中运行和回放脚本的过程,要密切关注replay log,也就是回放日志,很多问题通常都暴露在回放日志中,只不过我们没有认真去检查,所以没发觉。因为大多数情况是我们在回放脚本之后只观察回放日志中有没有红色的错误提示信息,如果没有我们就认为我们的脚本是ok的,其实不然,很多时候一些隐藏的错误就在回放日志中可以被发现,比如回放日志中的Warning信息,也就是警告信息,这些信息一旦你不去理会它,它将在场景运行过程中开始频繁暴露出来,而在场景中报错之后我们就认为可能是系统有问题或者是测试过程存在其他问题等等,而很难去考虑到是脚本的问题,是脚本在Vuser中调试就存在的问题。还有的时候一些问题在一次脚本回放中就不能被发现,他需要通过Vuser中设置多次迭代才能在回放日志暴露出问题来,所以说我们通常的思维就是一旦测试脚本没有一次回放没有出现错误,就去场景中运行,结果在场景中哪怕是运行10个用户都还会报错,这就是问题的根源所在。

  下面还是重点说说检查点吧,三种常用的文本检查web_reg_find的方法:

  1、 将脚本切换到树结构,在page view页面上找到你要check的文本内容, 并执行鼠标右键,选择Add a text check.

  2、 通过Vuesr界面去设置检查点,如图所示:

  

  3、 将脚本切换回代码界面, 在光标闪烁的上行,添加如下的代码:

添加的代码根据你检查的方式不同而不同, 你可以选择其中之一即可。

代码一:

web_reg_find("Text=Payment Details",LAST); 

注:“Payment Details” 为你要检查的文本;

脚本执行到此处,若在页面上找到了这几个字符串,那脚本继续执行下去;若没有找到,脚本将在此报错并且结束。

 

代码二: 

 web_reg_find("Text=Payment Details", "SaveCount=para_count", LAST); //check 的函数

这里是要运行的页面脚本

if (atoi(lr_eval_string("{para_count}"))>0)        //验证是否找到了页面上的要检查的字符串

   lr_output_message("Pass!");

 else

lr_output_message("Failed!");

注意:

“Payment Details” 为你要检查的文本;

脚本执行到此处,不管页面上是否存在你要检查的字符串,脚本都不会报错,而是执行下去。

此段代码将找到的你要检查的字符串的个数,存为一个参数。 然后在页面代码的后面,通过检查这个参数的值是否大于0,来判断是否找到了你所要检查的字符串。

注意:这里的测试结果均以200状态码返回,其失败的结果将在分析报告中进行分类标识。

 

代码三:

       web_reg_find("Text=Payment Detdils", "Fail=NotFound",LAST);或者

  web_reg_find("Text=Payment Detdils", "Fail=Found",LAST);

  以上两段脚本就比较简洁,通过查询文本内容来决定此次运行的测试结果是否失败。

 

注意:在使用检查点的时候我们还需要注意一些问题,通常我们都要设置一些中文检查点,但是LR默认不支持,如果你设置了中文检查点而报错,那你就应该注意了,在录制脚本的时候去掉默认设置的UTF-8选择,如下图所示:

并且还设置启用图片和文本检查点,如下图所示:

以上就是设置检查点的全过程,设置检查点的目的不只是为了验证我们的脚本没有错误,而更重要的是一个规范问题,如何使得测试结果更具有说服力,那就所有的测试脚本中都添加检查点设置。














本文转自一米一阳光博客园博客,原文链接: http://www.cnblogs.com/candle806/archive/2011/03/25/1995648.html   ,如需转载请自行联系原作者


相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
测试技术
loadrunner 场景设计-集合点设置
loadrunner 场景设计-集合点设置
348 0
|
Java Unix 测试技术
loadrunner 运行脚本-Run-time Settings之Preferences设置
loadrunner 运行脚本-Run-time Settings之Preferences设置
192 0
loadrunner 运行脚本-Run-time Settings之Preferences设置
|
测试技术
loadrunner 运行场景-运行时设置
loadrunner 运行场景-运行时设置
293 0
|
测试技术
loadrunner 场景设计-设置结果文件保存路径
loadrunner 场景设计-设置结果文件保存路径
155 0
|
存储 XML 缓存
loadrunner 运行脚本-Run-time Settings-Browser Enmulation设置详解
loadrunner 运行脚本-Run-time Settings-Browser Enmulation设置详解
139 0
|
测试技术 程序员
loadrunner 运行脚本-Run-time Settings-ContentCheck简单设置
loadrunner 运行脚本-Run-time Settings-ContentCheck简单设置
101 0
|
测试技术
loadrunner 运行脚本-Run-time Settings->General->Additional attributes设置
loadrunner 运行脚本-Run-time Settings->General->Additional attributes设置
101 0
|
测试技术
loadrunner 运行脚本-Run-time Settings之Pacing设置
loadrunner 运行脚本-Run-time Settings之Pacing设置
198 0
|
XML SQL 前端开发
loadrunner 脚本优化-关联设置
loadrunner 脚本优化-关联设置
232 0
|
缓存 Java 测试技术
loadrunner 脚本优化-检查点设置
loadrunner 脚本优化-检查点设置
248 0