LoadRunner错误提示及解决方法总结

转自:【http://www.7dtest.com/bbs/thread-1854-1-1.html

其中前半部分是转的,后面又加入了些自己平时总结的东西。

一、Step download timeout (120 seconds)
  这是一个经常会遇到的问题,解决得办法走以下步骤:
  1、 修改run time setting中的请求超时时间,增加到600s,其中有三项的参数可以一次都修改了,HTTP-request connect timeout,HTTP-request receieve timeout,Step download timeout,分别建议修改为600、600、5000;run time setting设置完了后记住还需要在controler组件的option的run time setting中设置相应的参数;
  2、 办法一不能解决的情况下,解决办法如下:
  设置runt time setting中的internet protocol-preferences中的advaced区域有一个winlnet replay instead of sockets选项,选项后再回放就成功了。切记此法只对windows系统起作用。


二、问题描述Connection reset by peer  这个问题不多遇见,一般是由于下载的速度慢,导致超时,所以,需要调整一下超时时间。
  解决办法:Run-time setting窗口中的‘Internet Protocol’-‘Preferences’设置set advanced options(设置高级选项),重新设置一下“HTTP-request connect timeout(sec),可以稍微设大一些”;


三、问题描述connection refused  这个的错误的原因比较复杂,也可能很简单也可能需要查看好几个地方,解决起来不同的操作系统方式也不同;
  1、 首先检查是不是连接weblogic服务过大部分被拒绝,需要监控weblogic的连接等待情况,此时需要增加acceptBacklog,每次增加 25%来提高看是否解决,同时还需要增加连接池和调整执行线程数,(连接池数*Statement Cache Size)的值应该小于等于oracle数据库连接数最大值;
  2、 如果方法一操作后没有变化,此时需要去查看服务器操作系统中是否对连接数做了限制,AIX下可以直接vi文件limits修改其中的连接限制数,还有 tcp连接等待时间间隔大小,wiodows类似,只不过wendows修改注册表,具体修改方法查手册,注册表中有TcpDelayTime项;


四、问题描述open many files
  问题一般都在压力较大的时候出现,由于服务器或者应用中间件本身对于打开的文件数有最大值限制造成,解决办法:
  1、 修改操作系统的文件数限制,aix下面修改limits下的nofiles限制条件,增大或者设置为没有限制,尽量对涉及到的服务器都作修改;
  2、 方法一解决不了情况下再去查看应用服务器weblogic的commonEnv.sh文件,修改其中的nofiles文件max-nofiles数增大,应该就可以通过了,具体就是查找到nofiles方法,修改其中else条件的执行体,把文件打开数调大;修改前记住备份此文件,防止修改出错;


五、问题描述has shut down the connection prematurely
  一般是在访问应用服务器时出现,大用户量和小用户量均会出现;
  来自网上的解释:
  1> 应用访问死掉
  小用户时:程序上的问题。程序上存在数据库的问题
  2> 应用服务没有死
  应用服务参数设置问题
  例如:
  在许多客户端连接Weblogic应用服务器被拒绝,而在服务器端没有错误显示,则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息,说明应提高该值,每次增加25%
  Java连接池的大小设置,或JVM的设置等
  3> 数据库的连接
  在应用服务的性能参数可能太小了
  数据库启动的最大连接数(跟硬件的内存有关)
  以上信息有一定的参考价值,实际情况可以参考此类调试。
  如果是以上所说的小用户时:程序上的问题。程序上存在数据库的问题,那就必须采用更加专业的工具来抓取出现问题的程序,主要是程序中执行效率很低的sql语句,weblogic可以采用introscope定位,期间可以注意观察一下jvm的垃圾回收情况看是否正常,我在实践中并发500用户和600用户时曾出现过jvm锯齿型的变化,上升下降都很快,这应该是不太正常的;


六、问题描述Failed to connect to server
  这个问题一般是客户端链接到服务失败,原因有两个客户端连接限制(也就是压力负载机器),一个网络延迟严重,解决办法:
  1、 修改负载机器的tcpdelaytime注册表键值,改小;
  2、 检查网络延迟情况,看问题出在什么环节;
  建议为了减少这种情况,办法一最好测试前就完成了,保证干净的网络环境,每个负载机器的压力测试用户数不易过大,尽量平均每台负载器的用户数,这样以上问题出现的概率就很小了。


七.LoadRunner HTTP服务器状态代码:在录制Web协议脚本回放脚本的过程中,会出现HTTP服务器状态代码,例如常见的页面-404错误提示、-500错误提示。
  错误现象1:-404 Not Found服务器没有找到与请求URI相符的资源,但还可以继续运行直到结束。
  错误分析:此处与请求URI相符的资源在录制脚本时已经被提交过一次,回放时不可再重复提交同样的资源,而需要更改提交资源的内容,每次回放一次脚本都要改变提交的数据,保证模拟实际环境,造成一定的负载压力。
  解决办法:在出现错误的位置进行脚本关联,在必要时插入相应的函数。
  错误现象2:-500 Internal Server Error服务器内部错误,脚本运行停止。
  错误分析:服务器碰到了意外情况,使其无法继续回应请求。
  解决办法:出现此错误是致命的,说明问题很严重,需要从问题的出现位置进行检查,此时需要此程序的开发人员配合来解决,而且产生的原因根据实际情况来定,测试人员无法单独解决问题,而且应该尽快解决,以便于后面的测试。


八.LoadRunner请求无法找到:在录制Web协议脚本回放脚本的过程中,会出现请求无法找到的现象,而导致脚本运行停止。
  错误现象:Action.c(41): Error -27979: Requested form not found [MsgId: MERR-27979]
  Action.c(41): web_submit_form highest severity level was "ERROR",0 body bytes, 0 header bytes [MsgId: MMSG-27178]"
  这时在tree view中看不到此组件的相关URL。
  错误分析:所选择的录制脚本模式不正确,通常情况下,基于浏览器的Web应用会使用“HTML-based script”模式来录制脚本;而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、基于浏览器的应用中使用HTTPS安全协议,这时则使用“URL-based script”模式进行录制。
  解决办法:打开录制选项配置对话框进行设置,在“Recording Options”的“Internet Protocol”选项里的“Recording”中选择“Recording Level”为“HTML-based script”,单击“HTML Advanced”,选择“Script Type”为“A script containing explicit”。然后再选择使用“URL-based script”模式来录制脚本。


九.LoadRunner回放Web Services协议脚本错误:LoadRunner 8.0版本在录制Web Services协议的脚本时正常,但在回放时会出现错误,提示停止脚本运行。
  错误现象:利用LoadRunner 8.0版本来录制Web Services协议的脚本没有任何错误提示,回放脚本时会出现如下错误提示“Error:server returned an incorrectly formatted SOAP response”。
  错误分析:出现此错误的原因是LoadRunner8.0在录制Web Services协议的脚本时存在一个缺陷:如果服务器的操作系统是中文的,VuGen会自动将WSDL文件的头改为<?xml version="1.0"encoding="zh_cn" ?>,所以才会有此错误提示。
  解决办法:下载两个补丁,分别为“LR80WebServicesFPI_setup.exe”和“lrunner_web_ services_patch_1.exe”安装上即可。

 

十. .....

 

尚在更新中。。。

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 好的,对于LoadRunner错误点,以下是一些可能的解决方案: 1. 脚本录制问题: - 确保在录制脚本时使用的是正确的协议(如HTTPHTTPS等)。 - 确保录制脚本中不包含不必要的请求和动作。 - 确保使用的是最新版本的LoadRunner,并且已安装所有的补丁和更新。 2. 脚本设计问题: - 确保脚本中的所有参数都已正确设置,包括登录凭据、会话ID等。 - 确保模拟的用户行为与实际使用情况相符合。 - 确保设置了正确的并发用户数和循环次数。 - 确保在执行测试之前已经完成了必要的预处理步骤(如清除缓存、重置数据等)。 3. 资源限制问题: - 确保服务器端有足够的资源来处理测试负载,包括CPU、内存、磁盘空间等。 - 确保网络带宽和延迟符合预期,并且网络瓶颈不会成为测试的瓶颈。 - 确保在执行测试时没有其他应用程序或服务占用了过多的系统资源。 4. 结果分析问题: - 确保正确地解读和分析测试结果,包括响应时间、吞吐量、错误率等。 - 确保根据测试结果采取适当的行动,如优化代码、增加服务器资源等。 希望这些解决方案能够帮助你解决LoadRunner的问题。 ### 回答2: 当在LoadRunner中进行性能测试时,偶尔会遇到检查点错误的情况。常见的检查点错误可能是由于以下原因: 1. 脚本错误:检查点可能被放置在了错误的位置,或者检查点的设置有误。这可能是因为脚本逻辑错误或操作步骤错误导致的。检查脚本中是否有错误,并确保检查点正确地设置在需要检查的功能或响应上。 2. 异步过程:当涉及到异步操作时,例如AJAX或JavaScript事件,检查点可能会提前或延迟出现。在这种情况下,我们需要使用适当的延迟函数或等待时间,以确保检查点在预期的时间点出现。 3. 动态数据:如果页面中包含动态生成的内容,例如当前时间或会话ID,那么检查点可能无法准确匹配这些内容。在这种情况下,我们可以使用参数化技术,将检查点的预期结果设置为可变的。 4. 网络延迟或性能问题:如果在检查点之前的步骤中存在网络延迟或性能问题,那么检查点可能无法在预期的时间内出现。我们需要仔细检查测试环境和网络配置,确保没有任何潜在的问题。 5. 硬件或软件错误LoadRunner可能面临硬件或软件问题,例如计算机资源限制或版本兼容性。在这种情况下,我们可以尝试重新安装或升级LoadRunner,或者与厂商的技术支持联系,以获得进一步的帮助。 总的来说,当遇到LoadRunner的检查点错误时,我们需要仔细检查脚本逻辑和设置,并确保环境和网络的正常运行。如果问题仍然存在,我们可以尝试使用其他调试工具或与厂商的技术支持寻求帮助。 ### 回答3: LoadRunner是一款常用的性能测试工具,用于模拟多用户访问某个应用系统,以评估其性能和稳定性。在使用LoadRunner进行测试时,我们可以设置检查点来验证系统的响应是否符合预期。 当LoadRunner检查点验证结果与预期不符时,可能会出现检查点错误。检查点错误的原因可能有多种,以下是一些常见的原因和解决方法: 1. 应用系统的动态内容:有些应用系统可能会在每次访问时生成不同的内容,如时间戳、随机数等。如果检查点设置了固定的预期值,当这些值发生变化时,就会造成检查点错误解决方法是使用LoadRunner提供的参数化功能,将动态内容以参数的形式引入,并设置相应的参数提取规则。 2. 加载时间问题:有时候系统的响应时间会根据负载的变化而变化。如果负载高时,系统响应时间变长,可能会导致检查点超时错误解决方法是根据负载情况设置合理的响应时间阈值,或者调整负载使系统负荷适中。 3. 页面结构变化:应用系统的页面结构可能会随着版本更新而发生变化,可能会导致检查点定位的元素或属性发生变化,从而造成检查点错误解决方法是更新检查点的定位信息,确保其准确性。 4. 网络或服务器问题:LoadRunner对应用系统发起的请求可能会受到网络或服务器的影响,如网络延迟、服务器负载过高等,可能导致系统响应超时或错误解决方法是根据具体情况进行网络优化或服务器调优。 总之,loadrunner检查点错误可能是由于动态内容、加载时间、页面结构变化或网络/服务器问题等原因导致的。根据具体情况分析,并结合适当的解决方法,可以有效解决检查点错误,确保测试的准确性和可靠性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值