Loadrunner 脚本回放 场景运行过程中 常见错误分析

问题一： 问题一：Loadrunner 超时错误问题描述 Loadrunner 超时错误：在录制 Web 协议脚本回放时超时情况经常出现，产生错误的原 因也有很多，解决的方法也不同。 问 题 现 象 Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。 错误分析对于 HTTP 协议，默认的超时时间是 120 秒（可以在 LoadRunner 中修改） ，客 户端发送一个请求到服务器端， 如果超过 120 秒服务器端还没有返回结果， 则出现超时错误。 解决办法首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设 置 多 次 迭 代 运 行 ， 如 果 还 有 超 时 现 象 ， 需 要 在 “Runtime Setting”>“Internet Protocol ： Preferences”>“Advanced”区域中设置一个“winlnet replay instead of sockets”选项，再回放是否 成功。 问 题 现 象 Error -27498: Timed out while processing URL=http://172.18.20.70:7001/workflow/bjtel/leasedline/ querystat/ subOrderQuery.do 错误分析 这种错误常常是因为并发压力过大， 服务器端太繁忙， 无法及时响应客户端的请求而造 成的，所以这个错误是正常现象，是压力过大造成的。 如果压力很小就出现这个问题，可能是脚本某个地方有错误，要仔细查看脚本，提示的 错误信息会定位某个具体问题发生的位置。 解决办法例如上面的错误现象问题定位在某个 URL 上，需要再次运行一下场景，同时 其他机器上访问此 URL。如果不能访问或时间过长，可能是服务器或者此应用不能支撑 在其他 其他 如此之大的负载。分析一下服务器，最好对其性能进行优化。 如果再次运行场景后还有超时现象， 就要在各种图形中分析一下原因， 例如可以查看是 否服务器、DNS、网络等方面存在问题。 备 注 ： 增 加 一 下 运 行 时 的 超 时 设 置 ， 在 “Run-Time Settings”>“Internet Protocol:Preferences” 中 ， 单 击 “options” ， 增 加 “HTTP-request connect timeout” 或 者 “HTTP-request receive”的值。 问题二： 脚本中出现乱码问题现象某个链接或者图片名称为中文乱码， 问题二：LoadRunner 脚本中出现乱码问题现象某个链接或者图片名称为中文乱码，脚

本运行无法通过。 本运行无法通过。 错误分析 脚本录制可能采用的是 URL-based script 方式，如果程序定义的字符集合采用的是国际 标准，脚本就会出现乱码现象。 解决办法重新录制脚本，在录制脚本前，打开录制选项配置对话框进行设置，在 “Recording Options”的“Advanced”选项里先将“Surport Charset”选中，然后选中支持“UTF-8” 的选项。 问题三： 问题三：LoadRunner HTTP（404/500） （ ）服务器状态代码问题现象 HTTP404 Not Found 相符的资源，但还可以继续运行直到结束。 服务器没有找到与请求 URI 相符的资源，但还可以继续运行直到结束。 错误分析 此处与请求 URI 相符的资源在录制脚本时已经被提交过一次，回放时不可再重复提交 同样的资源，而需要更改提交资源的内容，每次回放一次脚本都要改变提交的数据，保证模 拟实际环境，造成一定的负载压力。 解决办法在出现错误的位置进行脚本关联，在必要时插入相应的函数。 错误现象 HTTP 500 Internal Server Error 服务器内部错误，脚本运行停止。 错误分析 服务器碰到了意外情况，使其无法继续回应请求。 解决办法出现此错误是致命的，说明问题很严重，需要从问题的出现位置进行检查，此 测试人员无法单 时需要此程序的开发人员配合来解决， 而且产生的原因根据实际情况来定， 测试 独解决问题，而且应该尽快解决，以便于后面的测试。 问题四： 问题四：LoadRunner 请求无法找到错误现象 Error -27979: Requested form. not found [MsgId: MERR-27979] 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_find，在脚本 ， 中设置文本以及图像的检查点 但是在回放过程中并没有对设置的检查点进行检查， 像的检查点， 中设置文本以及图 像的检查点 ， 但是在回放过程中并没有对设置的检查点进行检查 ， 即 Web_find 失效。 失效。 错误分析 由于检查功能会消耗一定的资源， 因此 LoadRunner 默认关闭了对文本以及图像的检查， 所以在设置检查点后，需要开启检查功能。 解决办法打开运行环境设置对话框进行设置， 在“Run-time Settings”的“Internet Protocol” 选项里的“Perference”中勾选“Check”下的“Enable Image and text check”选项。

====================================================================== = 在使用 LoadRunner 进行 WEB 脚本录制的时候，很多人不清楚 URL-based 方式和 HTML-based 方式的差别， 以及何种情况下使用何种录制方式，这里给出一个简单的判断方法。 HTML-based 方式 HTML-based 方式对每个页面录制形成一条语句，对 LoadRunner 来说，在该模式下， 访问一个页面， 首先会与服务器之间建立一个连接获取页面的内容， 然后从页面中分解得到其他的元素 （component） ， 然后建立几个连接分别获取相应的元素。 URL-based 方式 URL-based 方式将每条客户端发出的请求录制成一条语句，对 LoadRunner 来说，在该 模式下，一条语句只建立一个到服务器的连接，

LoadRunner 提供了 web_concurrent_start 和 web_concurrent_end 函数模拟 HTML-based 的工作方式。 如何决定选择何种录制方式？ 1、如果应用是 WEB 应用，首选是 HTML-based 方式； 2、如果应用是使用 HTTP 协议的非 WEB 应用，首选是 URL-based 方式； 3、如果 WEB 应用中使用了 java applet 程序，且 applet 程序与服务器之间存在通讯，选 用 URL-based 方式； 4、如果 WEB 应用中使用的 javascript、vbscript 脚本与服务器之间存在通讯（调用了服 务端组件） ，选用 URL-based 方式