在运行脚本回放过程中，有时会出现错误，这在实际测试中是不可避免的，毕竟自动录制生成的脚本难免会有问题，需要运行脚本进行验证，把问题都解决后才加入到场景中进行负载测试。下面结合常用的协议（如Web、Web Services协议）录制的脚本进行回放时出现的问题介绍一下解决的方法。

　　需要注意的是，回放脚本时出现的错误有时是程序自身的原因导致的，因此在解决脚本回放问题前必须保证程序录制出的脚本是正确的。

　　1．LoadRunner超时错误：在录制Web协议脚本回放时超时情况经常出现，产生错误的原因也有很多，解决的方法也不同。

　　错误现象1：Action.c(16): 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”选项，再回放是否成功。

　　错误现象2：Action.c(81):Continuing after 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”的值。

　　2．LoadRunner脚本中出现乱码：在录制Web协议脚本时出现中文乱码，在回放脚本时会使回放停止在乱码位置，脚本无法运行。

　　错误现象：某个链接或者图片名称为中文乱码，脚本运行无法通过。

　　错误分析：脚本录制可能采用的是URL-based scrīpt方式，如果程序定义的字符集合采用的是国际标准，脚本就会出现乱码现象。

　　解决办法：重新录制脚本，在录制脚本前，打开录制选项配置对话框进行设置，在“Recording Options”的“Advanced”选项里先将“Surport Charset”选中，然后选中支持“UTF-8”的选项。

　　3．LoadRunner HTTP服务器状态代码：在录制Web协议脚本回放脚本的过程中，会出现HTTP服务器状态代码，例如常见的页面-404错误提示、-500错误提示。

　　错误现象1：-404 Not Found服务器没有找到与请求URI相符的资源，但还可以继续运行直到结束。

　　错误分析：此处与请求URI相符的资源在录制脚本时已经被提交过一次，回放时不可再重复提交同样的资源，而需要更改提交资源的内容，每次回放一次脚本都要改变提交的数据，保证模拟实际环境，造成一定的负载压力。

　　解决办法：在出现错误的位置进行脚本关联，在必要时插入相应的函数。

　　错误现象2：-500 Internal Server Error服务器内部错误，脚本运行停止。

　　错误分析：服务器碰到了意外情况，使其无法继续回应请求。

　　解决办法：出现此错误是致命的，说明问题很严重，需要从问题的出现位置进行检查，此时需要此程序的开发人员配合来解决，而且产生的原因根据实际情况来定，测试人员无法单独解决问题，而且应该尽快解决，以便于后面的测试。

　　4．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 scrīpt”模式来录制脚本；而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的Javascrīpt/VBscrīpt代码、基于浏览器的应用中使用HTTPS安全协议，这时则使用“URL-based scrīpt”模式进行录制。

　　解决办法：打开录制选项配置对话框进行设置，在“Recording Options”的“Internet Protocol”选项里的“Recording”中选择“Recording Level”为“HTML-based scrīpt”，单击“HTML Advanced”，选择“scrīpt Type”为“A scrīpt containing explicit”。然后再选择使用“URL-based scrīpt”模式来录制脚本。

　　5．LoadRunner不执行检查方法：在录制Web协议脚本中添加了检查方法Web_find，但是在脚本回放的过程中并没有执行。

　　错误现象：在脚本中插入函数Web_find，在脚本中设置文本以及图像的检查点，但是在回放过程中并没有对设置的检查点进行检查，即Web_find失效。

　　错误分析：由于检查功能会消耗一定的资源，因此LoadRunner默认关闭了对文本以及图像的检查，所以在设置检查点后，需要开启检查功能。

　　解决办法：打开运行环境设置对话框进行设置，在“Run-time Settings”的“Internet Protocol”选项里的“Perference”中勾选“Check”下的“Enable Image and text check”选项。

　　6．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”安装上即可。

正确选择协议，就要熟悉被测试应用的技术架构。以下列出一些LoadRounner支持的协议：

　　一般应用：C Vuser、VB Vuser、VB scrīpt Vuser、JAVA Vuser、Javascrīpt Vuser

　　电子商务：WEB（Http/Html)、FTP、LDAP、Palm、Web/WinsocketDual Protocol

　　客户端/服务器：MS SQL Server、ODBC、Oracle、DB2、Sybase CTlib、Sybase DBlib、Domain Name Resolution(DNS)、Windows Socket

　　分布式组件：COM/DCOM、Corba-Java、Rmi_Java

　　EJB：EJB、Rmi_Java

　　ERP/CRP： Oracle NCA、SAP-Web、SAPGUI、SAPGUI/SAP-Web Dual Protocol、PropleSoft_Tuxedo、Siebel Web、Siebel-DB2 CLI、Sieble-MSSQL、Sieble Oracle

　　遗留系统：Terminal Emulation (RTE)

　　Mail 服务：Internet Messaging(IMAP)、MS Exchange(MAPI)、POP3、SMTP

　　中间件：Jacada、Tuxedo 6、Tuxedo 7

　　无线系统：i-mode、voiceXML、WAP

　　应用部署软件：Citrix_ICA流：Media Plays(MMS)、Real

　　一段对于loadrunner协议选择的经典解答协议是数据在网络中传输的结构模式。协议不同，其数据报文的结构也有所不同。协议是有层次的，一般我们从ip层开始，往上有TCP协议层，UDP协议层，而TCP和UDP协议层上又有http协议层，ftp协议层，smtp协议层等我们在lr中看到的这些应用层的协议。其实这些高层协议都是对底层协议进行的进一步封装。举个简单例子，本来IP协议的数据报文是无序，不是可靠传输的，在其数据报文外面增加了报文序号，报文状态等数据段就构成了TCP协议层。所以我们很多网络应用，没有找到合适的协议，就用winsock来录制，那是肯定没有问题的。因为几乎所有的网络传输中都是基于tcp 协议或udp协议的，而socket正是这一级上的概念。但是由于socket协议级别太低，你录下来的东西是很难理解的，都是 socket，port，data之类的东西。所以，我们尽量用高层协议来录制，我们就能看懂了。

　　话要再说回来，解决一下具体的问题。我们看到一个软件体系架构，应该怎样选择录制协议呢？说到这里，我要说一下自己对lr录制机理的理解（我没有接触过lr内核，只是凭猜测和推断）。在录制时，lr应该会对你从本机发出去的数据进行截包，并拆包。因为我们知道协议的不同就是体现在数据包的结构不同，lr应该通过对包结构的分析，判断是不是它支持的协议，对包数据的分析，来获取用户发送的东西。比如你用ftp的协议去录制一个访问网页的IE操作，那肯定是无所收获的。因为lr没有在网络截获到 ftp协议格式的包，都是http协议格式的包，它不认，当然就是一个录制为空的结果了。现在我们弄懂了这个事情，就知道该如何选择协议了。看见很多人关心lr是不是支持mysql协议。我认为要寻找的答案的思路是这样的：

　　1、首先弄清mysql协议和其他数据库协议的关系，看能不能用其它数据库协议录制。但其实oracle的cs协议是oracle独有自己开发的协议，sqlserver也是一样，而mysql又与这几大产品又不是隶属关系，其脚本录制的可能性很小。

　　2、mysql协议的底层是基于什么协议的，如果直接构建在tcp协议上，lr又不支持mysql协议，那只能考虑用低一点的协议录录看，即socket。如果mysql协议是构建在odbc协议上的，那么就可能用lr的odbc api来写。

　　很多时候一提到不是基于浏览器的应用，很多人就会想到用 WinSocket协议来录制，仿佛Form窗体都可以用Winsocket 。从道理上讲网络通讯的底层都是基于Socket的，例如TCP、UPD等，似乎所有的程序都可以用Socket协议来录制。但是事实不是这样的，因为选择的协议决定了LoadRunner如何捕获数据包。否则会多捕获很多无用的数据。因此，不是所有的程序都是适合WinSocket协议的。实际上，那些基于Socket开发的应用才真正适合Socket协议来进行录制。其他的，例如基于数据库的应用，就不太时候Socket协议，甚至可能录制不到脚本。很多C/S程序，一定要选择合适的协议。根据作者的经验，C/S的程序多数需要手工开发很多脚本，因为录制的很多回放时候或多或少都会有些问题，但是可以参考录制的结果。所以测试一个程序，一定要搞清楚开发人员用了什么技术、数据流是什么协议封装的。理论上来说我们在对一个系统做性能测试以前，要先和开发人员了解一下他们在开发过程中都用了些什么技术，数据流是用什么协议封装的，还要了解我们要测试的系统的网络结构，服务器的配置等问题；还有就是要知道系统客户端和第一服务器间的协议，这中间就涉及到一个中间件的问题。另外我们要知道协议的选择直接关系到LR会捕获到什么样的数据包。这些是进行性能测试的基础。 下面说几个测试的原则（都是自己遇到过的，呵呵，没遇到过的就不知道了）：

　　1、一般情况下b/s构架的只要 选择WEB（Http/Html)协议就可以了，如果有中间件的则选择中间件服务器的协议 ；

　　2、C/S结构，可以根据后端数据库的类型来选择。如SybaseCTLib协议用于测试后台的数据库为Sybase的应用；MS SQL Server协议用与测试后台数据库为 SQL Server的应用；

　　3、一般不是基于浏览器的，对于一些没有数据库的 Windows应用，我们在测试的过程中都会选择WinSocket协议来录制，理论上来讲我们这样选择是正确的，但我们要知道在录制的时候所选择的协议就决定了LR如何捕获数据包，如果我们选择错误了，将会捕获到一些无用的数据包。cs结构是比较复杂的，在这里我要提醒大家，一定要搞清楚cs是 client-database还是client-server-database结构的，只有这样我们才能够决定是选择WinSocket协议还是 sql协议，或者说选择多个协议；当然协议的选择也是一个探索的过程，只要能够得到我们想要的结果，那就是正确的。还有一点，我们在做性能测试的时候应该是有测试重点的，呵呵。

　　4、关于单协议和双协议，我只知道IE6内核的浏览器在录制脚本的时候要选择单协议，而IE7内核的浏览器在录制脚本的时候要使用双协议。