发布新日志

  • LR问题收集

    2009-06-12 16:43:31

    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 script方式,如果程序定义的字符集合采用的是国际标准,脚本就会出现乱码现象。

      解决办法:重新录制脚本,在录制脚本前,打开录制选项配置对话框进行设置,在“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 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”模式来录制脚本。

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

  • 只谈LoadRunner中Unique参数属性

    2009-03-25 16:19:17

    只谈LoadRunner中Unique参数属性
    在LoadRunner中进行参数化时,Parameter的取值设置有以下相关参数:
            取值方式:
    Sequence:顺序
    Random:随机
    Unique:唯一
            改变(更新)取值的时机:
    Each Iteration:每次迭代
    Each Occurrence:每次出现
    Once:只改变一次

    (在此,我只讨论Unique的参数设置,其他相关参数会在其他文章中详谈)
    当我们取值方式选为Unique/更新取值时机选为Each Iteration时,还有一个选项可设置,那就是:allocate Vuser values in the controller:它有两个选项:1、automatically allocate block size;2、allocate _____values for each Vuser. 因为我们选择了“每次迭代”更新取值的方式,所以可以指定是由系统自动分配Vuser的参数值数量,还是人为指定为每个Vuser分配的参数值数量。

    我们以某网站登录功能为例来做分析:
    先来看一下登录界面:
    登录
    用户名:        {T_name}
    密码:        {Pwd}
    确认密码:        {Pwd}
    登录        取消

    一、我们选择由系统自动分配Vuser参数值数量的选项,即勾选automatically allocate block size

    1、        首先我们准备一些登陆用的数据,包括用户名,密码
    编号        用户名:        密码:
    1        T_username01        Pwd01
    2        T_username02        Pwd02
    3        T_username03        Pwd03
    4        T_username04        Pwd04
    5        T_username05        Pwd05

    2、        分析user的参数值列表、Vuser数和迭代次数的关系:
    首先确定我们是使用Vuser来虚拟多个用户通过调用多个user的参数值来实现模拟操作动作的,那一个Vuser使用的user参数值的多少就会和Iteration迭代的次数有直接关系。好,我们来看下面这个分析表:
    解释格式:(以1*2;2*2;3*1为例)
                    以分号分割,表示不同的Vuser:共3个Vuser
                    第一位数字表示Vuser的编号:3*1表示第3个Vuser
                    第二位数字表示分配得到的user参数值的数量:1*2表示第一个Vuser得到2个user参数值
    User参数值的数量
    (以5个为例)        迭代次数        最大允许Vuser数        最大Vuser数量下的分配情况
    5        1        5        1*1;2*1;3*1;4*1;5*1
    5        2        3        1*2;2*2;3*1
    5        3        2        1*3;2*2
    5        4        2        1*4;2*1
    5        5        1        1*5

    同样的分析方法,我们刚刚分析的“最大允许Vuser数量”,实际你可以取小于它的值,比如:
    User参数值的数量
    (以5个为例)        迭代次数        最大允许Vuser数        最大Vuser数量下的分配情况
    5        2        2        1*2,2*2
    注:比较和上表中的第二行数据,会发现:当我的每一个Vuser满足了自己的迭代次数,且参数数量够分配时,剩下的未用的1个参数就被忽略了
    (当user参数值数量小于迭代次数时,具体的分配方式和另一个选项有关:1、中止;2、循环Vuser分配到的列表;3、只循环最后一个列表项;这部分内容放到文章最下面 ^_^ ,现在可以默认选在2上)

    同样,我们可以分析一下10个User参数值的时候
    User参数值的数量
    (以5个为例)        迭代次数        最大允许Vuser数        最大Vuser数量下的分配情况
    10        1        10        1*1;2*1;3*1;4*1;5*1;6*1;7*1;8*1;9*1;10*1
    10        2        5        1*2;2*2;3*2;4*2;5*2
    10        3        4        1*3;2*3;3*3;4*1
    10        4        3        1*4;2*4;3*2
    10        5        2        1*5;2*5
    10        6        2        1*6;2*4
    10        7        2        1*7;2*3
    10        8        2        1*8;2*2
    10        9        2        1*9;2*1
    10        10        1        1*10

    由此,我们可以推导出有关User参数值数量、迭代次数和最大允许Vuser数的数学公式:
    令:        User参数值数量——ParamNum
                    迭代次数————IteraNum
                    最大允许Vuser数——MaxVuser
    则公式如下:
            当ParamNum%IteraNum=0时                MaxVuser= ParamNum/IteraNum        
            当ParamNum%IteraNum!=0时                MaxVuser= ParamNum/IteraNum+1

    二、我们选择人为分配Vuser参数值数量的选项,即勾选allocate _____values for each Vuser.并在空格中填入数量(我们以2为例来分析)

    这种方式要比上面的分析方法简单些。
    1、        还是用上面user的参数值列表为例
    2、        分析user的参数值列表、Vuser数和迭代次数的关系:
    User参数值的数量
    (以5个为例)        迭代次数        Vuser的分配情况
    5        1        1*2;2*2
    5        2        1*2;2*2
    5        3        1*2;2*2
    5        4        1*2;2*2
    5        5        1*2;2*2
    由以上分析我们看到:当我们认为确定了分配给Vuser的参数值数量,那么系统会按照你设定的值去分配,前两个Vuser每人得到应有的2个参数值,而此时的Vuser数量如果大于2个地话,那么其他的Vuser是分配不到user参数值的;而且此时的迭代会按照1、中止;2、循环Vuser分配到的列表;3、只循环最后一个列表项;你的设置去迭代

    三、最后一个相关选项:
            When out of values:
    1、        中止:abort Vuser
    2、        循环Vuser分配到的列表
    3、        只循环最后一个列表项

    1、现在我们假设选定2;
    比如迭代3次时:
    假设Vuser1得到的参数值为:T_username01、T_username02
    那么迭代结果:T_username01、T_username02、T_username01
    迭代4次结果:T_username01、T_username02 、T_username01、T_username02
    3、        现在我们选定3:
    同样的迭代3次时:
    假设Vuser1得到的参数值为:T_username01、T_username02
    那么迭代结果:T_username01、T_username02、T_username02
    迭代4次结果:T_username01、T_username02 、T_username02、T_username02

  • LoadRunner中参数设置中连接远程oracle的方式

    2009-02-25 11:05:01

    解决方法:控制面板>>管理工具>>数据源

    输入相关的信息,然后测试连接,提示成功则表示成功;

    建好该信息后,在loadrunner中,点击Data Wizard”按钮

    使用第2项,下一步

    点击“Create

    选择“机器数据源”

    双击hrms(即自己所建的数据源)

    输入信息,点击“ok”后,则在“Connection String”中自动生成相关的连接信息。

    现在就可以在“SQL statement”中写SQL了。点击“Finish”就完成了。

     

  • HTTP服务器状态代码定义(Status Code Definitions)

    2009-02-21 17:34:25

    1.1 消息1xx(Informational 1xx) 
    该类状态代码用于表示临时回应。临时回应由状态行(Status-Line)及可选标题组成, 由空行终止。HTTP/1.0中没有定义任何1xx的状态代码,所以它们不是对HTTP/1.0请求的   合法回应。实际上,它们主要用于实验用途,这已经超出本文档的范围。 
    1.2 成功2xx(Successful 2xx) 
    表示客户端请求被成功接收、理解、接受。 
    200 OK 
    请求成功。回应的信息依赖于请求所使用的方法,如下: 
    GET 要请求的资源已经放在回应的实体中了。 
    HEAD 没有实体主体,回应中只包括标题信息。 
    POST 实体(描述或包含操作的结果)。 
    201 Created 
    请求完成,结果是创建了新资源。新创建资源的URI可在回应的实体中得到。原始服务器应在发出该状态代码前创建该资源。如果该操作不能立即完成,服务器必须在该资源可用时在回应主体中给出提示,否则,服务器端应回应202(可被接受)。 
    在本文定义的方法,只有POST可以创建资源。 
    202 Accepted 
    请求被接受,但处理尚未完成。请求可能不一定会最终完成,有可能被处理过程随时中断,在这种情况下,没有办法在异步操作中重新发送状态代码。 
    202回应是没有义务的,这样做的目的是允许服务器不必等到用户代理和服务器间的连接结束,就可以响应其它过程的请求(象每天运行一次的,基于批处理的过程)。 
    在某些回应中返回的实体中包括当前请求的状态指示、状态监视器指针或用户对请求能否实现的评估信息。
    204 No Content 
    服务器端已经实现了请求,但是没有返回新的信息。如果客户是用户代理,则勿需为此更新自身的文档视图。该回应主要是为了在不影响用户代理激活文档视图的前提下,进行scrīpt语句的输入及其它操作。该回应还可能包括新的、以实体标题形式表示的元信息,它可被当前用户代理激活视图中的文档所使用。 
    1.3 重定向(Redirection 3xx) 
    该类状态码表示用户代理要想完成请求,还需要发出进一步的操作。这些操作只有当后跟的请求是GET或HEAD时,才可由用户代理来实现,而不用与用户进行交互。用户代理永远也不要对请求进行5次以上的重定向操作,这样可能导致无限循环。 
    300 Multiple Choices 
    该状态码不被HTTP/1.0的应用程序直接使用,只是做为3xx类型回应的缺省解释。存在多个可用的被请求资源。 
    除非是HEAD请求,否则回应的实体中必须包括这些资源的字符列表及位置信息,由用户或用户代理来决定哪个是最适合的。 
    如果服务器有首选,它应将对应的URL信息存放在位置域(Location field)处,用户代理会根据此域的值来实现自动的重定向。 
    301 Moved Permanently 
    请求到的资源都会分配一个永久的URL,这样就可以在将来通过该URL来访问此资源。有编辑链接功能的客户端会尽可能地根据服务器端传回的新链接而自动更新请求URI。 新的URL必须由回应中的位置域指定。除非是HEAD请求,否则回应的实体主体   (Entity-Body)必须包括对新URL超链接的简要描述。 
    如果用POST方法发出请求,而接收到301回应状态码。在这种情况下,除非用户确认,否则用户代理不必自动重定向请求,因为这将导致改变已发出请求的环境。 
    注意:当在接收到301状态码后而自动重定向POST请求时,一些现存的用户代理会错误地将其改为GET请求。 
    302 Moved Temporarily
    请求到的资源在一个不同的URL处临时保存。因为重定向有时会被更改,客户端应继续用请求URI来发出以后的请求。新的URL必须由回应中的位置域指定。除非是HEAD请求,否则回应的实体主体 (Entity-Body)必须包括对新URL超链接的简要描述。 
    如果用POST方法发出请求,而接收到302回应状态码。在这种情况下,除非用户确认,否则用户代理不必自动重定向请求,因为这将导致改变已发出请求的环境。 
    注意:当在接收到302状态码后而自动重定向POST请求时,一些现存的用户代理会错误地将其改为GET请求。 
    304 Not Modified 
    如果客户端成功执行了条件GET请求,而对应文件自If-Modified-Since域所指定的日期以来就没有更新过,服务器应当回应此状态码,而不是将实体主体发送给客户端。回应标题域中只应包括一些相关信息,比如缓存管理器、与实体最近更新(entity's Last-Modified)日期无关的修改。相关标题域的例子有:日期、服务器、过期时间。每当304回应中给出的域值发生变化,缓存都应当对缓存的实体进行更新。 
    1.4 客户端错误(Client Error )4xx 
    4xx类的状态码表示客户端发生错误。如果客户端在收到4xx代码时请求还没有完成,它应当立即终止向服务器发送数据。除了回应HEAD请求外,不论错误是临时的还是永久的,服务器端都必须在回应的实体中包含错误状态的解释。这些状态码适用于任何请求方法。 
    注意:如果客户端正在发送数据,服务器端的TCP实现应当小心,以确保客户端在关闭输入连接之前收到回应包。如果客户端在关闭后仍旧向服务器发送数据,服务器会给客户  端发送一个复位包,清空客户端尚未处理的输入缓冲区,以终止HTTP应用程序的读取、解释活动。 
    400 非法请求(Bad Request) 
    如果请求的语法不对,服务器将无法理解。客户端在对该请求做出更改之前,不应再次向服务器重复发送该请求。 
    401 未授权(Unauthorized) 
    请求需要用户授权。回应中的WWW-Authenticate标题域(10.16节)应提示用户以授权方式请求资源。客户端应使用合适的授权标题域(10.2节)来重复该请求。如果请求中已经包括了授权信任信息,那回应的401表示此授权被拒绝。如果用户代理在多次尝试之后,回应一样还是返回401状态代码,用户应当察看一下回应的实体,因为在实体中会包括一些相关的动态信息。HTTP访问授权会在11节中解释。 
    403 禁止(Forbidden) 
    服务器理解请求,但是拒绝实现该请求。授权对此没有帮助,客户端应当停止重复发送此请求。如果不是用HEAD请求方法,而且服务器端愿意公布请求未被实现原因的前提下,服务器会将拒绝原因写在回应实体中。该状态码一般用于服务器端不想公布请求被拒绝的细节或没有其它的回应可用。 
    404 没有找到(Not Found) 
    服务器没有找到与请求URI相符的资源。404状态码并不指明状况是临时性的还是永久性的。如果服务器不希望为客户端提供这方面的信息,还回应403(禁止)状态码。 
    1.5 服务器错误(Server Error )5xx 
    回应代码以‘5’开头的状态码表示服务器端发现自己出现错误,不能继续执行请求。如果客户端在收到5xx状态码时,请求尚未完成,它应当立即停止向服务器发送数据。除了回应HEAD请求外,服务器应当在其回应实体中包括对错误情况的解释、并指明是临时性的还永久性的。 
    这类回应代码没有标题域,可适用于任何请求方法。
    500 服务器内部错误(Internal Server Error) 
    服务器碰到了意外情况,使其无法继续回应请求。 
    501 未实现(Not Implemented) 
    服务器无法提供对请求中所要求功能的支持。如果服务器无法识别请求方法就会回应此状态代码,这意味着不能回应请求所要求的任何资源。 
    502 非法网关(Bad Gateway) 
    充当网关或代理的服务器从要发送请求的上游(upstream)服务器收到非法的回应。 
    503 服务不可用(Service Unavailable) 
    服务器当前无法处理请求。这一般是由于服务器临时性超载或维护引起的。该状态码暗示情况是暂时性的,要产生一些延迟。 
    注意:503状态码并没有暗示服务器在超载时一定要返回此状态码。一些服务器可能希望在超载时采用简单处理,即断掉连接。



    IIS 错误代码大汇总

    400 无法解析此请求。 401.1 未经授权:访问由于凭据无效被拒绝。 
    401.2 未经授权: 访问由于服务器配置倾向使用替代身份验证方法而被拒绝。 
    401.3 未经授权:访问由于 ACL 对所请求资源的设置被拒绝。 
    401.4 未经授权:Web 服务器上安装的筛选器授权失败。 
    401.5 未经授权:ISAPI/CGI 应用程序授权失败。 
    401.7 未经授权:由于 Web 服务器上的 URL 授权策略而拒绝访问。 
    403 禁止访问:访问被拒绝。 
    403.1 禁止访问:执行访问被拒绝。 
    403.2 禁止访问:读取访问被拒绝。 
    403.3 禁止访问:写入访问被拒绝。 
    403.4 禁止访问:需要使用 SSL 查看该资源。 
    403.5 禁止访问:需要使用 SSL 128 查看该资源。 
    403.6 禁止访问:客户端的 IP 地址被拒绝。 
    403.7 禁止访问:需要 SSL 客户端证书。 
    403.8 禁止访问:客户端的 DNS 名称被拒绝。 
    403.9 禁止访问:太多客户端试图连接到 Web 服务器。 
    403.10 禁止访问:Web 服务器配置为拒绝执行访问。 
    403.11 禁止访问:密码已更改。 
    403.12 禁止访问:服务器证书映射器拒绝了客户端证书访问。 
    403.13 禁止访问:客户端证书已在 Web 服务器上吊销。 
    403.14 禁止访问:在 Web 服务器上已拒绝目录列表。 
    403.15 禁止访问:Web 服务器已超过客户端访问许可证限制。 
    403.16 禁止访问:客户端证书格式错误或未被 Web 服务器信任。 
    403.17 禁止访问:客户端证书已经到期或者尚未生效。 
    403.18 禁止访问:无法在当前应用程序池中执行请求的 URL。 
    403.19 禁止访问:无法在该应用程序池中为客户端执行 CGI。 
    403.20 禁止访问:Passport 登录失败。 
    404 找不到文件或目录。 
    404.1 文件或目录未找到:网站无法在所请求的端口访问。 

        注意 404.1 错误只会出现在具有多个 IP 地址的计算机上。如果在特定 IP 地址/端口组合上收到客户端请求,而且没有将 IP 地址配置为在该特定的端口上侦听,则 IIS 返回 404.1 HTTP 错误。例如,如果一台计算机有两个 IP 地址,而只将其中一个 IP 地址配置为在端口 80 上侦听,则另一个 IP 地址从端口 80 收到的任何请求都将导致 IIS 返回 404.1 错误。只应在此服务级别设置该错误,因为只有当服务器上使用多个 IP 地址时才会将它返回给客户端。

    404.2 文件或目录无法找到:锁定策略禁止该请求。 
    404.3 文件或目录无法找到:MIME 映射策略禁止该请求。 
    405 用于访问该页的 HTTP 动作未被许可。 
    406 客户端浏览器不接受所请求页面的 MIME 类型。 
    407 Web 服务器需要初始的代理验证。 
    410 文件已删除。 
    412 客户端设置的前提条件在 Web 服务器上评估时失败。 
    414 请求 URL 太大,因此在 Web 服务器上不接受该 URL。 
    500 服务器内部错误。 
    500.11 服务器错误:Web 服务器上的应用程序正在关闭。 
    500.12 服务器错误:Web 服务器上的应用程序正在重新启动。 
    500.13 服务器错误:Web 服务器太忙。 
    500.14 服务器错误:服务器上的无效应用程序配置。 
    500.15 服务器错误:不允许直接请求 GLOBAL.ASA。 
    500.16 服务器错误:UNC 授权凭据不正确。 
    500.17 服务器错误:URL 授权存储无法找到。 
    500.18 服务器错误:URL 授权存储无法打开。 
    500.19 服务器错误:该文件的数据在配置数据库中配置不正确。 
    500.20 服务器错误:URL 授权域无法找到。 
    500 100 内部服务器错误:ASP 错误。 
    501 标题值指定的配置没有执行。 
    502 Web 服务器作为网关或代理服务器时收到无效的响应。 

    WIN2003 SERVER IIS6.0 ASP 错误解析 

        事件 ID 描述 

    0100 内存不足。无法分配所需的内存。 
    0101 意外错误。函数返回 |。 
    0102 要求字符串输入。函数需要字符串输入。 
    0103 要求数字输入。函数需要数字输入。 
    0104 不允许操作。 
    0105 索引超出范围。数组索引超出范围。 
    0106 类型不匹配。遇到未处理的数据类型。 
    0107 数据大小太大。请求中发送的数据大小超出允许的限制。 
    0108 创建对象失败。创建对象 '%s' 时出错。 
    0109 成员未找到。 
    0110 未知的名称。 
    0111 未知的界面。 
    0112 参数丢失。 

    0113 脚本超时。超过了脚本运行的最长时间。可以通过为 Server.scrīptTimeout 属性指定一个新值或在 IIS 管理工具中修改值来更改此限制。 
    0114 对象不可用于自由线程。应用程序对象仅接受自由线程对象;而对象 '%s' 不可用于自由线程。 
    0115 意外错误。外部对象中发生一个可捕捉的错误 (%X)。脚本无法继续运行。 
    0116 脚本分隔符结束标记丢失。脚本块缺少脚本结束标记 (%>)。 
    0117 脚本结束标记丢失。脚本块缺少脚本结束标记 (</scrīpt>) 或标记结束符号 (>)。 
    0118 对象的结束标记丢失。对象块缺少对象结束标记 (</OBJECT>) 或标记结束符号 (>)。 
    0119 Classid 或 Progid 属性丢失。对象实例 '|' 在对象标记中需要有效的 Classid 或 Progid。 
    0120 Runat 属性无效。脚本标记或对象标记的 Runat 属性只能有 'Server' 值。 
    0121 对象标记中的范围无效。对象实例 '|' 的作用范围不能是 Application 或 Session。要创建有 Session 或 Application 作用范围的对象实例,请将在 Global.asa 文件中加入 Object 标记。 
    0122 对象标记中的范围无效。对象实例 '|' 必须有 Application 或 Session 作用范围。这将应用于所有在 Global.asa 文件内创建的对象。 
    0123 缺少 Id 属性。缺少 Object 标记所需的 Id 属性。 
    0124 Language 属性丢失。缺少 Object 标记所需的 Language 属性。 
    0125 属性结束标记丢失。'|' 属性的值没有结束分隔符。 
    0126 未找到 Include 文件。未找到 Include 文件 '|'。 
    0127 HTML 注释的结束标记丢失。HTML 注释或在服务器端的包含文件缺少结束标记 (-->)。 
    0128 File 或 Virtual 属性丢失。Include 文件名必须用 File 或 Virtual 属性指定。 
    0129 未知的脚本语言。服务器上找不到脚本语言 '|'。 
    0130 File 属性无效。File 属性 '|' 不能以斜杠或反斜杠开始。 
    0131 不允许的父路径。Include 文件 '|' 不能包含 '..' 来表示父目录。 
    0132 编译错误。无法处理 Active Server Page '|'。 
    0133 ClassID 属性无效。对象标记有一个无效的 ClassID '|'。 
    0134 ProgID 属性无效。对象有一个无效的 ProgID '|'。 
    0135 循环包含。文件 '|' 包含它本身(可能是非直接地包含)。请检查包含文件中的其他 Include 语句。 
    0136 对象实例名无效。对象实例 '|' 试图使用一个保留名称。这个名称被 Active Server Pages 的内部对象使用。 
    0137 全局脚本无效。脚本块必须是允许的 Global.asa 过程之一。Global.asa 文件中不允许在 <% ... %> 内使用脚本指令。允许的过程名称是 Application_OnStart、Application_OnEnd、Session_OnStart 或 Session_OnEnd。 
    0138 脚本块嵌套。脚本块不可放在另一个脚本块内。 
    0139 嵌套对象。对象标记不能放在另一个对象标记内。 
    0140 页命令次序有误。@ 命令必须是 Active Server Page 中的第一个命令。 
    0141 页命令重复。@ 命令只可以在 Active Server Page 中使用一次。 
    0142 线程令牌错误。无法打开线程令牌。 
    0143 应用程序名无效。未找到有效的应用程序名称。 
    0144 初始化错误。初始化时页级别的对象列表失败。 
    0145 新应用程序失败。无法添加新的应用程序。 
    0146 新会话失败。无法添加新的会话。 
    0147 500 服务器错误。 
    0148 服务器太忙。 

    0149 正在重新启动应用程序。重启动应用程序期间无法处理请求。 
    0150 应用程序目录错误。无法打开应用程序目录。 
    0151 更改通知错误。无法创建更改通知事件。 
    0152 安全错误。处理用户安全凭据时发生错误。 
    0153 线程错误。新线程请求已失败。 
    0154 HTTP 头写入错误。HTTP 头无法写入客户端浏览器。 
    0155 页内容写入错误。页内容无法写入客户端浏览器。 
    0156 头错误。HTTP 头已经写入到客户端浏览器。任何 HTTP 头必须在写入页内容之前修改。 
    0157 启用缓冲。缓冲启用后不能关闭。 
    0158 URL 丢失。URL 是必需的。 
    0159 缓冲已关闭。缓冲必须启用。 
    0160 日志记录错误。将条目写入日志失败。 
    0161 数据类型错误。将 Variant 转换为 String 变量失败。 
    0162 不能修改 Cookie。不能修改 Cookie 'ASPSessionID'。它是一个保留的 Cookie 名。 
    0163 逗号用法无效。日志条目内不可使用逗号。请选择另一个分隔符。 
    0164 TimeOut 值无效。指定的 TimeOut 值无效。 
    0165 SessionID 错误。无法创建 SessionID 字符串。 
    0166 对象未初始化。试图访问未初始化的对象。 
    0167 会话初始化错误。初始化 Session 对象时发生错误。 
    0168 禁止的对象使用。Session 对象中不能保存内部对象。 
    0169 缺少对象信息。Session 对象中不能保存信息不全的对象。需要对象的线程模型信息。 
    0170 删除会话错误。无法正确删除 Session。 
    0171 路径丢失。必须为 MapPath 方法指定 Path 参数。 
    0172 路径无效。MapPath 方法的路径必须是虚拟路径。使用了一个实际的路径。 
  • LoadRunner出现error问题及解决方法总结收藏

    2009-02-21 16:34:07

    这个好DD是我从一个GG的BLOG里转的,非常受用,尤其新手。。。 嘿嘿  自己也遇到了问题,就找到它了

    LoadRunner出现error问题及解决方法总结


    一、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设置完了后记住还需要在control组件的option的run time setting中设置相应的参数;
    2、   办法一不能解决的情况下,解决办法如下:
    设置runt time setting中的internet protocol-preferences中的advaced区域有一个winlnet replay instead of sockets选项,选项后再回放就成功了。切记此法只对windows系统起作用,此法来自zee的资料。


    二、问题描述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、   检查网络延迟情况,看问题出在什么环节;
    建议为了减少这种情况,办法一最好测试前就完成了,保证干净的网络环境,每个负载机器的压力测试用户数不易过大,尽量平均每台负载器的用户数,这样以上问题出现的概率就很小了;

  • 虚拟用户数和并发用户数的联系

    2009-02-12 15:05:54

    例如OA系统使用用户是100个,这个就是系统用户数,该系统有一个统计查询功能,最高峰在线50人,那么系统的并发数是多少?

          OA系统使用用户是100个,这个就是系统用户数。

          最高峰值50人同时在线,只表明同时登录了这个模块,并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。这50人在线,有可能开着电脑溜达去了,有的看的别的模块等等。

            并发用户:是同时执行一个操作的用户,或者是同时执行脚本的用户,这个并发在设置不同场景的时候并发的情况是不一样的,在实际的测试中需要根据具体的需求进行设计。web系统,在线不等于并发,如何计算这个并发数是个难题。这个就是设置集合点时候设置的在scenario->Rendezvous,policy 设置的用户数。

          估算并发数的公示:

            1) 计算平均的并发用户数: C = nL/T      

            2) 并发用户数峰值: C’ ≈ C+3根号C

             公式(1)中,C是平均的并发用户数;nlogin session的数量;Llogin session的平均长度;T指考察的时间段长度。

            公式(2)则给出了并发用户数峰值的计算方式中,其中,C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

          假设有一个OA系统,该系统有3000个用户,(可以看注册信息)平均每天大约有400个用户要访问该系统,(日志文件查看)对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。

    则根据公式(1)和公式(2),可以得到:

                  C = 400*4/8 = 200

                  C’≈200+3*根号200 = 242

           但是一般的做法是把每天访问系统用户数的10%作为平均的并发用户数。最大的并发用户数乘上一个值,2或者3.

        假如说用户要求系统每秒最大可以处理100个登陆请求,10/25/50/75/100 个并发用户来执行登陆操作,然后观察系统在不同负载下的响应时间和每秒事务数。如果用户数在100的时候,响应时间还在允许范围呢,就要加大用户数,例如120 等 。个人理解这个用户数就是我们经常说的等价类和边界值法来设定。

  • loadrunner 错误应对

    2009-02-09 10:33:57

  • Action.c(8): 错误 -27727: Step download timeout (120 seconds) has expired when downloading resource(s). Set the "Step Timeout caused by resources is a warning" Run-Time Setting to Yes/No to have this message as a warning/error, respectively  
  • Run-Time Setting(运行时设置) -- Internet Protocol -- Preferences -- Option -- Step download timeout(sec)改为15000(根据需要可能更大)

  • 服务器过早关闭
    查看帮助信息。修改网段与网管、子网掩码、路由器等一致。
  • 转一份在 51testing 上的讨论——如何测试一个门户网站是否可以支持10万用户同时在线?

    2009-02-02 13:56:28

    这个帖子的内容比较典型,大家有兴趣可以也思考一下。

    先是楼主提出问题:

    最近公司一个项目,是个门户网站,需要做性能测试,根据项目特点定出了主要测试项和测试方案
    一种是测试几个常用页面能接受的最大并发数(用户名参数化,设置集合点策略)
    一种是测试服务器长时间压力下,用户能否正常操作(用户名参数化,迭代运行脚本)
    还有一种则需要测试服务器能否接受10万用户同时在线操作,但使用的Loadrunner的license只能支持1万用户,请问这时该如何制定该方案
    ?


    后面跟着大家的回复:

     网友 xingcyx  的回复:

    1、找10台电脑也没用,license仍然只支持10000个。
    2、找HP支持。当然,前提是你有足够的钱。
    3、测到10000用户并发。我认为,通常情况下10000用户并发,支持100000用户在线,没有问题的。


    网友 jackloo 的回复:

    总的来说这一类的性能指标对大多数软件来说没什么实际意义,更多的是对硬件的要求。
    如果是用IIS做应用服务器的话,单台可承受的最大并发数不可能达到10万级,那就必须要使用集群,通过多台机器做负载均衡来实现;
    如果是用websphere之类的应用服务器的话,单台可承受的最大并发数可以达到10万级,但为性能考虑还是必须要使用集群,通过多台机器做负载均衡来实现;
    那么,你只要集群的服务器足够多,10万并发数当然可以达到了。
    通常有1个简单的计算方式,1个连接产生1个session,每个session在服务器上有个内存空间大小的设置,在NT上是3M,那么10万并发就需要300G内存,当然实际使用中考虑其他程序也占用内存,所以准备的内存数量要求比这个还要多一些。
    还有10万个用户同时在线,跟10万个并发数是完全不同的2个概念。这个楼上已经说了。但如何做这个转换将10万个同时在线用户转换成多少个并发数呢?
    这就必须要有大量的历史日志信息来支撑了。系统日志需要有同时在线用户数量的日志信息,还需要有用户操作次数的日志信息,这2个数据的比例就是你同时在线用户转换到并发数的比例。
    另外根据经验统计,对于1个JAVA开发的WEB系统(别的我没统计过,给不出数据),一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个(这个状态下大部分操作都是超时报错而且服务器很容易宕机,其实没什么实际意义),可正常使用(单步非大数据量操作等待时间不超过20秒)的最大并发数不超过300个。
    假设你的10万同时在线用户转换的并发数是9000个,那么你最少需要这样的机器18台,建议不少于30台。
    当然,你要是买个大型服务器,里面装有200个CPU、256G的内存,千兆光纤带宽,就算是10万个并发用户,那速度,也绝对是嗖嗖的。


    楼主的回复:

    谢谢jackloo !
    再请问如果我想测试10000个用户同时在线做常用操作的话(每两秒加一个用户,一直加到10000),对服务器的要求有多高
    ?

    网友 jackloo 的回复:

    套用1句经典台词“高,实在是高”
    呵呵。另外暴寒1下,你的设置光全部进入运行状态就需要接近6个小时。
    具体的你可以拿1个系统来压一下看看,可能会出现以下情况:
    1。服务器宕机;
    2。客户端宕机;
    3。从某个时间开始服务器拒绝请求,客户端上显示的全是错误;
    4。勉强测试完成,但网络堵塞或测试结果显示时间非常长。假设客户端和服务器之间百兆带宽,百兆/10000=10K,那每个用户只能得到10K,这个速度接近1个64K的MODEM上网的速度;
    另外以上分析全都没考虑系统的后台,比如数据库、中间件等。
    我从没遇到你说的这样的性能需求过,也只好凭感觉随便掰掰:
    1。服务器方面:上面说的那样的PC SERVER需要50台;
    2。网络方面:按每个用户50K,那至少5根百兆带宽独享,估计仅仅网络延迟就大概是秒一级的;
    3。如果有数据库,至少是ORACLE,最好是SYSBASE,SQL SERVER是肯定顶不住的。数据库服务器至少需要10台4CPU、16G内存的机器;
    4。如果有CORBA,那至少再准备10台4CPU、16G内存的机器;
    再加上负载均衡、防火墙、路由器和各种软件等,总之没个1000万的资金投入,肯定搞不定。

    网友 mybasswood 的回复:

    如果是10万用户的话要看做些什么哈.
    比如对于voip来说,假设有10万用户的话,服务器规定每个client至少要在3600秒内到服务器成功报到一次,否则就被服务器cancel掉.
    client是每隔60秒注册一次.
    所以就要推算在3600秒内,每一个client至少成功报到一次是最少的标准.要10万用户在3600秒内被服务器吃掉才可以
    ---这是最低要求.
    最高要求是: 在60秒内所有的10万用户去注册,如果服务器在60秒可以都吃掉的话,每秒种的平均并发差不多是3334.
    最低要求是:在3600秒内所有的10用户去注册,如果服务器在3600秒内都可以吃掉的话,每秒钟的平均并发用户差不多是60个.还有一过问题是客户端要在3600秒内发送至少60次,至少有一次成功.再加上这些用户分布在全球各地的话,这样数值应该还会有变化的.

     

    下面是偶的看法:

    给楼主一个建议吧。

    你在公司中的测试环境是一定的,你需要做得是现在这个环境中确认一下系统在当前环境下的实际处理能力。如果还有资源,再做一下可伸缩性的测试。
    然后对测试结果进行分析,对系统的处理能力和可伸缩性做一个描述。

    当然,要在报告中说明你的测试环境。


    另外一位网友robust 的留言:

    你的意思是否想用10000个用户测试结果来推测一下10万个用户?
    还是如有些老兄说的,测试一下什么伸缩性测试.然后也来个报告,无非也是想用1万个来推测10万个的情况
    ?(评注:那样的话要你做什么性能测试,只要计算一下就可以得性能结果了.)
    还是如有些老兄说的,这一类的性能指标对大多数软件来说没什么实际意义,更多的是对硬件的要求
    ?(评注:那样的话要你做什么性能测试,做什么性能调优,只要计算一下,添加硬件就可以了.)
    实际上,
    "实践是检验真理的唯一标准!"这句话才是硬道理.只有真实地测试过才知道.任何推测只是推测,并不能反映真实的情况.
    至于性能测试工具,LR只是普及率高(市场占有率高),并不是在性能指标上有优势.世界上比它厉害的工具有不少,举个例子siprent通信公司的avalanche2500,大型计算机实验室配备的性能测试工具.支持录制
    /回放,测试结果分析等.它可以模拟从数据层到应用层的协议,(当然也包含http-web),单个支持100万并发连接.拿它也可以测试100万级的并发性能.

     

    又是偶的回复:

    楼上的提到的见解不错,不过对性能测试的理解有些偏差。

    先抛开性能测试工具不谈,其实这个问题是讨论到一个性能测试到底该怎么做。

    简单举个例子,如果你想知道一种新的疫苗对人的作用,是不是要把所有的地球人全部找来每个人打一针试试呢?当然不是,只能是通过试验和抽样,然后通过统计学的方法来计算出一个模型,通过样本的表现来估算总体的特征。这就是统计学研究的领域,。不过请注意,统计学所包含的内容并不是像楼上的老兄所说的一样:只要计算一下就可以得性能结果了。

    性能测试也同样如此。

    楼主提到的性能需求应该是系统上线以后可能要面临的压力,先不讨论这个需求是否准确和有效,我们先假定它是有效的。那么,既然要验证的是系统在上线以后是否有能力应对10万用户同时在线的情况,那么自然要用生产环境来测试。如果有,那么 OK,可以作这个测试。至于工具,其实可以由开发人员帮忙写一些简单的脚本负责加压,再通过其他第三方工具收集测试数据就是了。

    但是如果没有生产环境,只有一台双CPU,3G内存的 
    2850 服务器,怎么办?这就好像上面提到的例子。可行的方法是在这台服务器上使用不同级别的负载来进行测试,并根据测试数据获得系统在这种环境下的最佳负载和最大负载,并根据测试数据对负载和资源消耗的情况进行估算,找到它们之间的关系。

    一般来说,大型的门户网站不会只用一台超级超级的服务器来承担所有的负载,因为采用负载均衡和集群技术可以更好的解决这个问题,一定是多台服务器分布在不同的地方,内容通过内容分发网络同步到各台服务器上。用户在访问时,其实是被应用层或者前端设备路由到一个合适的服务器去的。所以在测试时,对于可伸缩性的测试是必需的,一定要了解到 cluster 数量增加时,系统的响应能力是否可以线性的增加,也就是说是否可以承受更大的压力,为更多的用户提供服务。

    最后总结一下,对于性能测试,要作的是确认系统的响应能力,然后看系统是否可以满足性能需求。

    如果大家有不同的见解,欢迎 PK 讨论 

     继续偶的回复:

    to jackloo


    你所提到的对于硬件资源和软件资源的要求并不完全准确。因为实际的资源消耗要根据网站所提供的业务类型来推算。
    对于大多数门户网站来说,可供访问的大多是静态页面。在用户访问时,系统只是返回一个静态页面给用户,并不需要保持 session,而且这种情况下负载主要集中在I
    /O和网络流量方面——这也是为什么大型门户网站都会采用分布式的方式来部署服务器。当然,如果使用了 cache,内存的使用会随着服务器运行时间的延长而增加,但是 CPU 通常不会成为关键资源。

    这是门户网站同企业应用或者在线游戏的区别。

    还是偶:

     

    to 楼主


    上面我也提到了,你需要进一步的明确你的测试需求是否有效,合理。

    性能需求需要根据网站具体提供的业务类型来作为依据进行衡量。就如同上面提到的,是只提供了静态页面的访问?还是有其他的业务?

    要区分清楚注册用户、在线用户和并发用户的区别。

    另外,你最迫切需要担心的并不应该是 LR 的 license 问题,而是被测的系统能否支持的了几百或者几千并发用户,如果连这个都支持不了,就更不用考虑上万的并发访问了。

     

    希望大家有不同的看法和意见都可以写下来,大家一起讨论,共同进步。 

  • Error code 10053,Software caused connection abort.

    2009-01-06 11:20:45

  • 使用LoadRunner时如何选择合适的协议

    2009-01-04 10:24:26

    这个问题吧,问的非常好,应该是大家都比较关心的问题。当年我也一直未这个问题很困惑。

      我想在回答这个问题之前,先搞清楚什么是协议,为什么要选择协议。这就需要我们对通信机理有一些的了解。

      首先,什么是协议?

      协议无非就是一个约定,关于数据包发送的格式的约定,就是说如果大家都这样发送,那么通信就能够成功,如果大家都各按各的来,那么就没办法进行通信了。

      那么接下来就是LR录制时的工作原理了,LR的录制和WR不一样,它不关心你的对象识别什么的,不关心你的什么窗口之类的,LR有一个Agent进程,来专门监控客户端和服务器之间的通信,然后用自己的函数进行录制。所以说,LR录制的时候关心的是通信,是客户端和服务器之间的数据包。说到这里,大家就比较清楚了,为什么有的时候不能录制呢?因为,协议不认识阿,导致LR截获的数据包不能解析,所以录制下来是空的。

      到这里我们再来看,那我们怎么样选择协议呢?当然原则就是说,你数据包的通信协议能被LR识别。

      过去流行的一种说法是,只要B/s结构的都是选择http协议,如果不是b/s那么肯定是socket,其实这种说法是比较肤浅或者比较片面的,我觉得要真正理解这个问题,必须搞清楚你所测系统的数据流采用的什么协议包装的。这个我个人觉得,最好是能去向开发人员多了解,多学习。(说到这里,我想顺便建议一点:测试人员向开发人员学习是个好习惯,多学一点底层的东西,或者对程序架构,数据流向,内部结构分析多了解一点,对自己的测试很有帮助,对自己的成长也是有帮助的),另外,个人觉得,作为一个测试人员需要多了解一些网络方面的专业知识,最好学习一些网络分析工具譬如说Sniffer等,这对测试很有帮助。

      说了这么多,似乎跑题了?还是回到正题,如何选择协议。

      我下面给大家推荐一些建议值,是我在某本测试专业书籍上看到了,给大家贴上来,仅供参考。我还是说,具体问题具体分析,选择协议不是一个教条的事情,而是需要研究探索并尝试。

      协议选择参考:

       应用类型      协议选择

      1. Web网站       HTTP/HTML

      2. FTP服务器     FTP

      3. 邮件服务器    IMAP,POP3,SMTP

      4.  C/S (第一种)客户端以ADO,OLEDB方法连接后台数据库   MS SQL Server,Oracle,Sybase,DB2,Infrmix

         C/S  (第二种)客户端以ODBC方法连接后台数据库  ODBC

         C/S  (第三种)没有后台数据库   Socket

      5. ERP系统    SAP Peoplesoft

      6.分布式组件   COM/DACOM  EJB

      7.无线应用     WAP  PALM

      总之,只有充分了解被测系统的应用类型和技术架构,才能做出正确的选择。

  • 数据统计

    • 访问量: 10200
    • 日志数: 29
    • 建立时间: 2008-05-04
    • 更新时间: 2009-06-12

    RSS订阅

    Open Toolbar