开着拖拉机上班!

发布新日志

  • LoadRunner出现error问题及解决方法总结(转载)

    2010-01-27 11:46:01

    转载::

     

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

      

    一、Step download timeout (120 seconds)

    这是一个经常会遇到的问题,解决得办法走以下步骤:

    1、修改run time setting中的请求超时时间,增加到600s,其中有三项的参数可以一次都修改了,HTTP-request connect timeoutHTTP-request receieve timeoutStep download timeout,分别建议修改为6006005000run time setting设置完了后记住还需要在control组件的optionrun 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 timeoutsec),可以稍微设大一些”。

      

    三、问题描述connection refused

    这个的错误的原因比较复杂,也可能很简单也可能需要查看好几个地方,解决起来不同的操作系统方式也不同。

    1、首先检查是不是连接weblogic服务过大部分被拒绝,需要监控weblogic的连接等待情况,此时需要增加acceptBacklog,每次增加25%来提高看是否解决,同时还需要增加连接池和调整执行线程数,(连接池数*Statement Cache Size)的值应该小于等于oracle数据库连接数最大值。

    2、如果方法一操作后没有变化,此时需要去查看服务器操作系统中是否对连接数做了限制,AIX下可以直接vi文件limits修改其中的连接限制数、端口数,还有tcp连接等待时间间隔大小,wiodows类似,只不过windows修改注册表,具体修改注册表中有TcpTimedWaitDelayMaxUserPort项,键值在[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\]。因为负载生成器的性能太好,发数据包特别快,服务器也响应特别快,从而导致负载生成器的机器的端口在没有timeout之前就全部占满了。在全部占满后,就会出现上面的错误。执行netstat –na命令,可以看到打开了很多端口。所以就调整TCP的time out。即在最后一个端口还没有用到时,前面已经有端口在释放了。

    1,这里的TcpTimedWaitDelay默认值应该中是30s,所以这里,把这个值调小为5s(按需要调整)。
    2,也可以把MaxUserPort调大(如果这个值不是最大值的话)。

      

    四、问题描述open many files

    问题一般都在压力较大的时候出现,由于服务器或者应用中间件本身对于打开的文件数有最大值限制造成,解决办法:

    1、修改操作系统的文件数限制,aix下面修改limits下的nofiles限制条件,增大或者设置为没有限制,尽量对涉及到的服务器都作修改。

    2、方法一解决不了情况下再去查看应用服务器weblogiccommonEnv.sh文件,修改其中的nofiles文件max-nofiles数增大,应该就可以通过了,具体就是查找到nofiles方法,修改其中else条件的执行体,把文件打开数调大。修改前记住备份此文件,防止修改出错。

    3、linux上可以通过ulimit –HSn 4096来修改文件打开数限制,也可以通过ulimit -a 来查看。

    4、linux上可以通过lsof -p pid | wc -l 来查看进程打开的句柄数。

      

    五、问题描述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锯齿型的变化,上升下降都很快,这应该是不太正常的。

    ---------------------------------------

    实际测试中,可以用telent 站点看看是否可以连接进去,可以通过修改连接池中的连接数和适当增加应用内存值,问题可以解决。

      

    六、问题描述Failed to connect to server

    这个问题一般是客户端链接到服务失败,原因有两个客户端连接限制(也就是压力负载机器),一个网络延迟严重,解决办法:

    1、修改负载机器注册表中的TcpTimedWaitDelay减小延时和MaxUserPort增加端口数。注:这将增加机器的负荷。

    2、检查网络延迟情况,看问题出在什么环节。

    建议为了减少这种情况,办法一最好测试前就完成了,保证干净的网络环境,每个负载机器的压力测试用户数不易过大,尽量平均每台负载器的用户数,这样以上问题出现的概率就很小了。

      

    七、问题描述Overlapped transmission of request to ... WSA_IO_PENDING

    这个问题,解决方法:

    1、方法一,在脚本前加入web_set_sockets_option("OVERLAPPED_SEND", "0"),禁用TTFB细分,问题即可解决,但是TTFB细分图将不能再使用,附图。

    2、方法二,可以通过增加连接池和应用系统的内存,每次增加25%。

      

    八、问题描述Deleted the current transaction ... since response time is not accurate

    这个问题不多遇见,一般出现在压力机器上发生ping值为负数(AMD双核CPU),可以重新启动pc机或者打补丁,附图。

    九、问题描述HTTP Status-Code=500 (Internal Server Error) for

    1、应用服务当掉,重新启动应用服务。

    2、当应用系统处于的可用内存处于阀值以下时,出现HTTP Status-Code=500的概率非常高,此时只要增加应用系统的内存,问题即可解决。

                                    

    十、问题描述Failed to transmit data to network: [10057] Socket is not connected

    这个错误是由网络原因造成的,PC1 PC2上面都装了相同的loadrunner 9.0,且以相同数量的虚拟用户数运行相同的业务(机器上的其他条件都相同),PC1上面有少部分用户报错,PC2上的用户全部执行通过。

    十一、问题描述 Error -27257: Pending web_reg_save_param/reg_find/create_html_param[_ex] request(s) detected and reset at the end of iteration number 1
    解决方法:web_reg_save_param位置放错了,应该放到请求页面前面。
                          
    十二、问题描述 通过Controler调用远程代理时报错,Error: CCI security error:You are running under secure mode and the function system is not allowed in this mode.
    解决方法:在代理开启的时候,去掉勾选防火墙选项。

  • 路人乙总结的LR错误及解决办法

    2010-01-27 11:39:33

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

    错误现象1Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)

    错误分析:对于HTTP协议,默认的超时时间是120秒(可以在LoadRunner中修改),客户端发送一个请求到服务器端,如果超过120秒服务器端还没有返回结果,则出现超时错误。

    解决办法:首先在运行环境中对超时进行设置,默认的超时时间可以设置长一些,再设置多次迭代运行,如果还有超时现象,需要在“Runtime Setting”>“Internet ProtocolPreferences”>“Advanced”区域中设置一个“winlnet replay instead of sockets”选项,再回放是否成功。

    错误现象2Action.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”的值。

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

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

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

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

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

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

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

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

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

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

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

    4LoadRunner请求无法找到:在录制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”模式来录制脚本。

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

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

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

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

    6LoadRunner回放Web Services协议脚本错误LoadRunner 8.0版本在录制Web Services协议的脚本时正常,但在回放时会出现错误,提示停止脚本运行。

    错误现象:利用LoadRunner 8.0版本来录制Web Services协议的脚本没有任何错误提示,回放脚本时会出现如下错误提示“Errorserver 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错误及解决方法总结[转]

    2010-01-27 11:35:04

    LoadRunner错误及解决方法总结[转](2009-08-07 15:48:41)

    标签:杂谈 

    1.  error:missing newline in d:\loadrunner\name.dat

    场景执行时报error:missing newline in d:\loadrunner\name.dat

    第二次执行不报

    两个解决办法:

    第一:如果参数不是很多的话,不要打开记事本去编辑参数,就直接在LR提供的参数的表格中进行编辑即可。

    第二:如果参数很多超过100条的话。 在记事本中编辑好了之后,记着在最后一个参数后打个回车,让鼠标的光标移动到下一行。

    2.load   generator   is   currently   running   the   maximum   number   of   vuser   of   this   type

    使用的是loadrunner8.0,有10000个用户的web的license,global的有10个。

    在测试的时候发现running   vuser到达1000以后就不能再提高,后面的vuser就会出错。错误是“The   load   generator   is   currently   running   the   maximum   number   of   vuser   of   this   type”.

    已经可以排除是load   generator机器本身资源的问题。因为换了性能比较强的酷睿2还是同样的问题,CPU和memory都有空闲。

    解决办法:

    在load   generator中有一个Vuser   limits   tab,可以设置running   user的最大数目。    即设置 load generator----Details------Vuser limits ----Other Vusers 的最大参数

    3.LoadRunner 常见问题:

    (1)sofeware caused connction:这种情况,一般是脚本有问题,或者loadrunner有问题。解决方法:重新启动机器,或者重新录制脚本,估计是loadrunner的bug。

    (2)cannot connect to server:无法连接到服务器。这种情况是服务器的配置有问题,服务器无法承受过多的并发连接了。需要优化服务器的配置,

    如操作系统采用windows 2003 server,

    优化tomcat配置:maxThreads="500" minSpareThreads="400" maxSpareThreads="450"。但是tomcat 最多支持500个并发访问

    优化apache配置:

    ThreadsPerChild 1900

    MaxRequestsPerChild 10000

    其他的错误如:

    Action.c(10): Error -27791: Server has shut down the connection prematurely

    HTTP Status-Code=503 (Service Temporarily Unavailable)

    一般都是由于服务器配置不够好引起的,按照问题(2)处理,如果仍旧不行,需要优化硬件和调整程序了。

    Apache问题:

    (1) File does not exist: C:/Apache/htdocs/favicon.ico:

    这个问题是apache,htdocs目录没有favicon.ico文件引起的,该文件是网站的图标,仅在firefox,myIE等浏览器出现。

    (2) 图片无法显示:

    配置apache后,却无法显示图片。

    解决方法:把程序的图片,按照程序结构copy到apache的htdocs目录下。

    (3) 无法处理请求:

    当我们输入 ***.do 命令后,apache确返回错误信息,而连接tomcat却没有问题。原因是没有把.do命令转发给tomcat处理。解决方法如下:

    在apache配置文件中配置如下内容:

    DocumentRoot "C:/Apache/htdocs"

    JkMount /*.jsp loadbalancer

    JkMount /*.do loadbalancer

     

    4、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系统起作用。

     

    5、问题描述Connection reset by peer  这个问题不多遇见,一般是由于下载的速度慢,导致超时,所以,需要调整一下超时时间。

      解决办法:Run-time setting窗口中的‘Internet Protocol’-‘Preferences’设置set advanced options(设置高级选项),重新设置一下“HTTP-request connect timeout(sec),可以稍微设大一些”;

    6、问题描述connection refused  这个的错误的原因比较复杂,也可能很简单也可能需要查看好几个地方,解决起来不同的操作系统方式也不同;

      1、首先检查是不是连接weblogic服务过大部分被拒绝,需要监控weblogic的连接等待情况,此时需要增加acceptBacklog,每次增加 25%来提高看是否解决,同时还需要增加连接池和调整执行线程数,(连接池数*Statement Cache Size)的值应该小于等于oracle数据库连接数最大值;

      2、如果方法一操作后没有变化,此时需要去查看服务器操作系统中是否对连接数做了限制,AIX下可以直接vi文件limits修改其中的连接限制数,还有 tcp连接等待时间间隔大小,wiodows类似,只不过wendows修改注册表,具体修改方法查手册,注册表中有TcpDelayTime项;

    7、问题描述open many files

      问题一般都在压力较大的时候出现,由于服务器或者应用中间件本身对于打开的文件数有最大值限制造成,解决办法:

      1、修改操作系统的文件数限制,aix下面修改limits下的nofiles限制条件,增大或者设置为没有限制,尽量对涉及到的服务器都作修改;

      2、方法一解决不了情况下再去查看应用服务器weblogic的commonEnv.sh文件,修改其中的nofiles文件max-nofiles数增大,应该就可以通过了,具体就是查找到nofiles方法,修改其中else条件的执行体,把文件打开数调大;修改前记住备份此文件,防止修改出错;

    8、问题描述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锯齿型的变化,上升下降都很快,这应该是不太正常的;

    9、问题描述Failed to connect to server

      这个问题一般是客户端链接到服务失败,原因有两个客户端连接限制(也就是压力负载机器),一个网络延迟严重,解决办法:

      1、 修改负载机器的tcpdelaytime注册表键值,改小;

      2、 检查网络延迟情况,看问题出在什么环节;

      建议为了减少这种情况,办法一最好测试前就完成了,保证干净的网络环境,每个负载机器的压力测试用户数不易过大,尽量平均每台负载器的用户数,这样以上问题出现的概率就很小了。

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

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

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

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

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

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

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

    11.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”模式来录制脚本。

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

  • LR问题记录 _脚本乱码

    2010-01-25 10:53:32

        LR录制脚本,发现有的系统录制的后脚本有乱码,之前碰到过也没去管它,反正只是汉字的显示有问题,不影响脚本运行。但这次碰到乱码问题就比较严重,本来是汉字前后的引号,后引号变没了,要自己手动加上才能运行,并且要脚本中要这样改的地方还比较多,并且每次录了脚本都要这样改太麻烦。刚好一个开发人员和我说他们返回的字符是UTF-8的,可能是字符集引起的问题,后来我在录制时把字符集选成UTF8这个问题就解决了。

     

    选择字符集的路径:

    start record->options->advanced->support charset ->UTF-8;

     

    本来这个默认是没钩选的。

     

     

  • 软件回归测试及其实践

    2009-12-17 14:04:55

    本文描述了软件回归测试的概念和进行回归测试的基本步骤,介绍了可用于回归测试的测试用例库的维护方法,给出了几种可以可保证回归测试效率和有效性的回归测试策略,总结了回归测试时应该注意的一些实际问题。

      一、 概述

      在软件生命周期中的任何一个阶段,只要软件发生了改变,就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改,也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时,如果错误跟踪与管理系统不够完善,就可能会遗漏对这些错误的修改;而开发者对错误理解的不够透彻,也可能导致所做的修改只修正了错误的外在表现,而没有修复错误本身,从而造成修改失败;修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题,使本来工作正常的功能产生错误。同样,在有新代码加入软件的时候,除了新加入的代码中有可能含有错误外,新代码还有可能对原有的代码带来影响。因此,每当软件发生变化时,我们就必须重新测试现有的功能,以便确定修改是否达到了预期的目的,检查修改是否损害了原有的正常功能。同时,还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。

      回归测试在软件生命周期中扮演着重要的角色,因忽视回归测试而造成严重后果的例子不计其数,导致阿里亚娜5型火箭发射失败的软件缺陷就是由于复用的代码没有经过充分的回归测试造成的。

      回归测试作为软件生命周期的一个组成部分,在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中,新版本的连续发布使回归测试进行的更加频繁,而在极端编程方法中,更是要求每天都进行若干次回归测试。因此,通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

      二、 回归测试策略

      对于一个软件开发项目来说,项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中,并对其进行维护和管理。当得到一个软件的基线版本时,用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候,就可以根据所选择的回归测试策略,从基线测试用例库中提取合适的测试用例组成回归测试包,通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本,也有可能是测试用例的手工实现过程。

      回归测试需要时间、经费和人力来计划、实施和管理。为了在给定的预算和进度下,尽可能有效率和有效力地进行回归测试,需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。

      1、测试用例库的维护

      为了最大限度地满足客户的需要和适应应用的要求,软件在其生命周期中会频繁地被修改和不断推出新的版本,修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的改变,软件的功能和应用接口以及软件的实现发生了演变,测试用例库中的一些测试用例可能会失去针对性和有效*,而另一些测试用例可能会变得过时,还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效*,必须对测试用例库进行维护。同时,被修改的或新增添的软件功能,仅仅靠重新运行以前的测试用例并不足以揭示其中的问题,有必要追加新的测试用例来测试这些新的功能或特征。因此,测试用例库的维护工作还应包括开发新测试用例,这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征。

      测试用例的维护是一个不间断的过程,通常可以将软件开发的基线作为基准,维护的主要内容包括下述几个方面。

      (1)、删除过时的测试用例

      因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统,这些测试用例就会过时。例如,某个变量的界限发生了改变,原来针对边界值的测试就无法完成对新边界测试。所以,在软件的每次修改后都应进行相应的过时测试用例的删除。

      (2)、改进不受控制的测试用例

      随着软件项目的进展,测试用例库中的用例会不断增加,其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制,会影响回归测试的效率,需要进行改进,使其达到可重复和可控制的要求。

      (3)、删除冗余的测试用例

      如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试,那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库,并将冗余的用例删除掉。

      (4)、增添新的测试用例

      如果某个程序段、构件或关键的接口在现有的测试中没有被测试,那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。

      通过对测试用例库的维护不仅改善了测试用例的可用*,而且也提高了测试库的可信*,同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。

      2、回归测试包的选择

      在软件生命周期中,即使一个得到良好维护的测试用例库也可能变得相当大,这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例,时间和成本约束可能阻碍运行这样一个测试,有时测试组不得不选择一个缩减的回归测试包来完成回归测试。

      回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时,有可能删除了将揭示回归错误的测试用例,消除了发现回归错误的机会。然而,如果采用了代码相依性分析等安全的缩减技术,就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。

      选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括:

      (1)、再测试全部用例

      选择基线测试用例库中的全部测试用例组成回归测试包,这是一种比较安全的方法,再测试全部用例具有最低的遗漏回归错误的风险,但测试成本最高。全部再测试几乎可以应用到任何情况下,基本上不需要进行分析和重新开发,但是,随着开发工作的进展,测试用例不断增多,重复原先所有的测试将带来很大的工作量,往往超出了我们的预算和进度。

      (2)、基于风险选择测试

      可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试,而跳过那些非关键的、优先级别低的或者高稳定的测试用例,这些用例即便可能测试到缺陷,这些缺陷的严重性也仅有三级或四级。一般而言,测试从主要特征到次要特征。

      (3)、基于操作剖面选择测试

      如果基线测试用例库的测试用例是基于软件操作剖面开发的,测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定,回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例,释放和缓解最高级别的风险,有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠*,但实施起来有一定的难度。

      (4)、再测试修改的部分

      当测试者对修改的局部化有足够的信心时,可以通过相依性分析识别软件的修改情况并分析修改的影响,将回归测试局限于被改变的模块和它的接口上。通常,一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下,回归测试尽可能覆盖受到影响的部分。

      再测试全部用例的策略是最安全的策略,但已经运行过许多次的回归测试不太可能揭示新的错误,而且很多时候,由于时间、人员、设备和经费的原因,不允许选择再测试全部用例的回归测试策略,此时,可以选择适当的策略进行缩减的回归测试。

      3、回归测试的基本过程

      有了测试用例库的维护方法和回归测试包的选择策略,回归测试可遵循下述基本过程进行:

      (1). 识别出软件中被修改的部分;

      (2). 从原基线测试用例库T中,排除所有不再适用的测试用例,确定那些对新的软件版本依然有效的测试用例,其结果是建立一个新的基线测试用例库T0。

      (3). 依据一定的策略从T0中选择测试用例测试被修改的软件。

      (4). 如果必要,生成新的测试用例集T1,用于测试T0无法充分测试的软件部分。

      (5). 用T1执行修改后的软件。

      第(2)和第(3)步测试验证修改是否破坏了现有的功能,第(4)和第(5)步测试验证 修改工作本身。

      三、 回归测试实践

      在实际工作中,回归测试需要反复进行,当测试者一次又一次地完成相同的测试时,这些回归测试将变得非常令人厌烦,而在大多数回归测试需要手工完成的时候尤其如此,因此,需要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。为了支持多种回归测试策略,自动测试工具应该是通用的和灵活的,以便满足达到不同回归测试目标的要求。

      在测试软件时,应用多种测试技术是常见的。当测试一个修改了的软件时,测试者也可能希望采用多于一种回归测试策略来增加对修改软件的信心。不同的测试者可能会依据自己的经验和判断选择不同的回归测试技术和策略。

      回归测试并不减少对系统新功能和特征的测试需求,回归测试包应包括新功能和特征的测试。如果回归测试包不能达到所需的覆盖要求,必须补充新的测试用例使覆盖率达到规定的要求。

      回归测试是重复性较多的活动,容易使测试者感到疲劳和厌倦,降低测试效率,在实际工作中可以采用一些策略减轻这些问题。例如,安排新的测试者完成手工回归测试,分配更有经验的测试者开发新的测试用例,编写和调试自动测试脚本,做一些探索性的或ad hoc测试。还可以在不影响测试目标的情况下,鼓励测试者创造性地执行测试用例,变化的输入、按键和配置能够有助于激励测试者又能揭示新的错误。

      在组织回归测试时需要注意两点,首先是各测试阶段发生的修改一定要在本测试阶段内完成回归,以免将错误遗留到下一测试阶段。其次,回归测试期间应对该软件版本冻结,将回归测试发现的问题集中修改,集中回归。

      在实际工作中,可以将回归测试与兼容性测试结合起来进行。在新的配置条件下运行旧的测试可以发现兼容性问题,而同时也可以揭示编码在回归方面的错误。

      回归测试的概述

      验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。

      验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效*,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。

      通过综合测试之后,软件已完全组装起来,接口方面的错误也已排除,软件测试的最后一步——验收测试即可开始。验收测试应检查软件能否按合同要求进行工作,即是否满足软件需求说明书中的确认标准。

      1.验收测试标准 实现软件确认要通过一系列墨盒测试。验收测试同样需要制订测试计划和过程,测试计划应规定测试的种类和测试进度,测试过程则定义一些特殊的测试用例,旨在说明软件与需求是否一致。无是计划还是过程,都应该着重考虑软件是否满足合同规定的所有功能和性能,文档资料是否完整、准确人机界面和其他方面(例如,可移植性、兼容性、错误恢复能力和可维护性等)是否令用户满意。 验收测试的结果有两种可能,一种是功能和性能指标满足软件需求说明的要求,用户可以接受;另一种是软件不满足软件需求说明的要求,用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正,因此必须与用户协商,寻求一个妥善解决问题的方法。

      2.配置复审 验收测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序,并且包括软件维护所必须的细节。

      3.α、β测试 事实上,软件开发人员不可能完全预见用户实际使用程序的情况。例如,用户可能错误的理解命令,或提供一些奇怪的数据组合,亦可能对设计者自认明了的输出信息迷惑不解,等等。因此,软件是否真正满足最终用户的要求,应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试,也可以有计划、有系统的测试。有时,验收测试长达数周甚至数月,不断暴露错误,导致开发延期。一个软件产品,可能拥有众多用户,不可能由每个用户验收,此时多采用称为α、β测试的过程,以期发现那些似乎只有最终用户才能发现的问题。 α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品(称为α版本)进行测试,试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本,并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。 一般包括功能度、安全可靠性、易用性、可扩充性、兼容性、效率、资源占用率、用户文档八个方面。

      一、施验收测试的常用策略

      施验收测试的常用策略有三种,它们分别是:

      • 正式验收

      • 非正式验收或 Alpha 测试

      • Beta 测试

      您选择的策略通常建立在合同需求、组织和公司标准以及应用领域的基础上。

      正式验收测试

      正式验收测试是一项管理严格的过程,它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向,这一点很重要。在很多组织中,正式验收测试是完全自动执行的。

      对于系统测试,活动和工件是一样的。在某些组织中,开发组织(或其独立的测试小组)与最终用户组织的代表一起执行验收测试。在其他组织中,验收测试则完全由最终用户组织执行,或者由最终用户组织选择人员组成一个客观公正的小组来执行。

      这种测试形式的优点是:

      • 要测试的功能和特性都是已知的。

      • 测试的细节是已知的并且可以对其进行评测。

      • 这种测试可以自动执行,支持回归测试。

      • 可以对测试过程进行评测和监测。

      • 可接受性标准是已知的。

      缺点包括:

      • 要求大量的资源和计划。

      • 这些测试可能是系统测试的再次实施。

      • 可能无法发现软件中由于主观原因造成的缺陷,这是因为您只查找预期要发现的缺陷。

      非正式验收测试

      在非正式验收测试中,执行测试过程的限定不象正式验收测试中那样严格。在此测试中,确定并记录要研究的功能和业务任务,但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不象正式验收测试那样组织有序,而且更为主观。

      大多数情况下,非正式验收测试是由最终用户组织执行的。

      这种测试形式的优点是:

      • 要测试的功能和特性都是已知的。

      • 可以对测试过程进行评测和监测。

      • 可接受性标准是已知的。

      • 与正式验收测试相比,可以发现更多由于主观原因造成的缺陷。

      缺点包括:

      • 要求资源、计划和管理资源。

      • 无法控制所使用的测试用例。

      • 最终用户可能沿用系统工作的方式,并可能无法发现缺陷。

      • 最终用户可能专注于比较新系统与遗留系统,而不是专注于查找缺陷。

      • 用于验收测试的资源不受项目的控制,并且可能受到压缩。

      Beta 测试

      在以上三种验收测试策略中,Beta 测试需要的控制是最少的。在 Beta 测试中,采用的细节多少、数据和方法完全由各测试员决定。各测试员负责创建自己的环境、选择数据,并决定要研究的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。

      Beta 测试由最终用户实施,通常开发(或其他非最终用户)组织对其的管理很少或不进行管理。Beta 测试是所有验收测试策略中最主观的。

      这种测试形式的优点是:

      • 测试由最终用户实施。

      • 大量的潜在测试资源。

      • 提高客户对参与人员的满意程度。

      • 与正式或非正式验收测试相比,可以发现更多由于主观原因造成的缺陷。

      缺点包括:

      • 未对所有功能和/或特性进行测试。

      • 测试流程难以评测。

      • 最终用户可能沿用系统工作的方式,并可能没有发现或没有报告缺陷。

      • 最终用户可能专注于比较新系统与遗留系统,而不是专注于查找缺陷。

      • 用于验收测试的资源不受项目的控制,并且可能受到压缩。

      • 可接受性标准是未知的。

      • 您需要更多辅助性资源来管理 Beta 测试员。

      二、验收测试过程

      1. 软件需求分析:了解软件功能和性能要求、软硬件环境要求等,并特别要了解软件的质量要求和验收要求。

      2. 编制《验收测试计划》和《项目验收准则》:根据软件需求和验收要求编制测试计划,制定需测试的测试项,制定测试策略及验收通过准则,并经过客户参与的计划评审。

      3. 测试设计和测试用例设计:根据《验收测试计划》和《项目验收准则》编制测试用例,并经过评审。

      4. 测试环境搭建:建立测试的硬件环境、软件环境等。(可在委托客户提供的环境中进行测试)

      5. 测试实施:测试并记录测试结果。

      6. 测试结果分析:根据验收通过准则分析测试结果,作出验收是否通过及测试评价。

      7. 测试报告:根据测试结果编制缺陷报告和验收测试报告,并提交给客户。

      三、验收测试的总体思路

      用户验收测试是软件开发结束后,用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求,以及用户能否接受的问题。由于它不只是检验软件某个方面的质量,而是要进行全面的质量检验,并且要决定软件是否合格,因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划,进行软件配置评审、功能测试、性能测试等多方面检测。

      用户验收测试可以分为两个大的部分:软件配置审核和可执行程序测试,其大致顺序可分为:文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试。

      要注意的是,在开发方将软件提交用户方进行验收测试之前,必须保证开发方本身已经对软件的各方面进行了足够的正式测试(当然,这里的“足够”,本身是很难准确定量的)。

      用户在按照合同接收并清点开发方的提交物时(包括以前已经提交的),要查看开发方提供的各种审核报告和测试报告内容是否齐全,再加上平时对开发方工作情况的了解,基本可以初步判断开发方是否已经进行了足够的正式测试。

      用户验收测试的每一个相对独立的部分,都应该有目标(本步骤的目的)、启动标准(着手本步骤必须满足的条件)、活动(构成本步骤的具体活动)、完成标准(完成本步骤要满足的条件)和度量(应该收集的产品与过程数据)。在实际验收测试过程中,收集度量数据,不是一件容易的事情。

      软件配置审核

      对于一个外包的软件项目而言,软件承包方通常要提供如下相关的软件配置内容:

      ●可执行程序、源程序、配置脚本、测试程序或脚本。

      ●主要的开发类文档:《需求分析说明书》、《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》、《测试计划》、《测试报告》、《程序维护手册》、《程序员开发手册》、《用户操作手册》、《项目总结报告》。

      ●主要的管理类文档:《项目计划书》、《质量控制计划》、《配置管理计划》、《用户培训计划》、《质量总结报告》、《评审报告》、《会议记录》、《开发进度月报》。

      在开发类文档中,容易被忽视的文档有《程序维护手册》和《程序员开发手册》。

      《程序维护手册》的主要内容包括:系统说明(包括程序说明)、操作环境、维护过程、源代码清单等,编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。

      《程序员开发手册》的主要内容包括:系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等,实际上就是程序员的培训手册。

      不同大小的项目,都必须具备上述的文档内容,只是可以根据实际情况进行重新组织。

      对上述的提交物,最好在合同中规定阶段提交的时机,以免发生纠纷。

      通常,正式的审核过程分为5个步骤:计划、预备会议(可选)、准备阶段、审核会议和问题追踪。预备会议是对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是最终确定工作产品中包含的错误和缺陷。

      审核要达到的基本目标是:根据共同制定的审核表,尽可能地发现被审核内容中存在的问题,并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时,还要注意文档与源代码的一致性。

      在实际的验收测试执行过程中,常常会发现文档审核是最难的工作,一方面由于市场需求等方面的压力使这项工作常常被弱化或推迟,造成持续时间变长,加大文档审核的难度;另一方面,文档审核中不易把握的地方非常多,每个项目都有一些特别的地方,而且也很难找到可用的参考资料。

      可执行程序的测试

      在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成,就可以进行验收测试的最后一个步骤——可执行程序的测试,它包括功能、性能等方面的测试,每种测试也都包括目标、启动标准、活动、完成标准和度量等五部分。

      要注意的是不能直接使用开发方提供的可执行程序用于测试,而要按照开发方提供的编译步骤,从源代码重新生成可执行程序。

      在真正进行用户验收测试之前一般应该已经完成了以下工作(也可以根据实际情况有选择地采用或增加):

      ●软件开发已经完成,并全部解决了已知的软件缺陷。

      ●验收测试计划已经过评审并批准,并且置于文档控制之下。

      ●对软件需求说明书的审查已经完成。

      ●对概要设计、详细设计的审查已经完成。

      ●对所有关键模块的代码审查已经完成。

      ●对单元、集成、系统测试计划和报告的审查已经完成。

      ●所有的测试脚本已完成,并至少执行过一次,且通过评审。

      ●使用配置管理工具且代码置于配置控制之下。

      ●软件问题处理流程已经就绪。

      ●已经制定、评审并批准验收测试完成标准。

      具体的测试内容通常可以包括:安装(升级)、启动与关机、功能测试(正例、重要算法、边界、时序、反例、错误处理)、性能测试(正常的负载、容量变化)、压力测试(临界的负载、容量变化)、配置测试、平台测试、安全性测试、恢复测试(在出现掉电、硬件故障或切换、网络故障等情况时,系统是否能够正常运行)、可靠性测试等。

      性能测试和压力测试一般情况下是在一起进行,通常还需要辅助工具的支持。在进行性能测试和压力测试时,测试范围必须限定在那些使用频度高的和时间要求苛刻的软件功能子集中。由于开发方已经事先进行过性能测试和压力测试,因此可以直接使用开发方的辅助工具。也可以通过购买或自己开发来获得辅助工具。具体的测试方法可以参考相关的软件工程书籍。

      如果执行了所有的测试案例、测试程序或脚本,用户验收测试中发现的所有软件问题都已解决,而且所有的软件配置均已更新和审核,可以反映出软件在用户验收测试中所发生的变化,用户验收测试就完成了。

      四、测试报告形式

      《验收测试报告》

      《缺陷报告》

      《验收测试计划》中规定的其他文档

      五、验收测试工作流程说明和注意事项

      验收测试业务洽谈

      双方就测试项目及合同进行洽谈

      签订测试合同

      委托方提交测试样品及相关资料

      委托方需提交的文档有:

      •基本文档:(验收测试必需的文档)

      用户手册

      安装手册维护手册

      软件样品(可刻录在光盘)

      •特殊文档:(根据测试内容不同,委托方所需提交下列相应的文档)

      软件产品开发过程中的测试记录

      软件产品源代码。

      编制测试计划并通过评审

      进行项目相关知识培训

      测试设计

      评测中心编制测试方案和设计测试用例集。

      方案评审

      评测中心测试组成员、委托方代表一起对测试方案进行评审。

      实施测试

      评测中心对测试方案进行整改,并实施测试。在测试过程中每日提交测试事件报告给委托方。

      编制验收测试报告并组织评审

      评测中心编制验收测试报告,并组织内部评审。

      提交验收测试报告

      评测中心提交验收测试报告。
  • Alpha测试和Beta测试

    2009-12-10 14:05:49

    AlphaBeta测试简介

     

    大型通用软件,在正式发布前,通常需要执行AlphaBeta测试,目的是从实际终端用户的使用角度,对软件的功能和性能进行测试,以发现可能只有最终用户才能发现的错误。

    Alpha
    测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始,或在模块(子
    系统)测试完成后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册(草稿)等应该在Alpha测试前准备好。

    Beta
    测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。因而,Beta测试是在开发者无法控制的环境下进行的软件现场
    应用。在Beta测试中,由用户记下遇到的所有问题,包括真实的以及主管认定的,定期向开发者报告,开发者在综合用户的报告后,做出修改,最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性,包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后,才能开始Beta测试。由于Beta测试的主要目标是测试可支持性,所以Beta测试应该尽可能由主持产品发行的人员来管理

    由于AlphaBeta测试的组织难度大,测试费用高,测试的随机性强、测试周期跨度较长,测试质量和测试效率难于保证,所以,很多专业软件可能不再进行Beta测试。随着测试技术的提高,以及专业测试
    服务机构的大量涌现,很多软件的Beta测试外包给这些专业测机构进行测试。

  • Web测试要点

    2009-10-14 16:03:21

    Web测试要点-转载

      1、链接测试  
       (1)、测试所有链接是否按指示的那样确实链接到了该链接的页面;
       (2)、测试所链接的页面是否存在;
       (3)、保证Web应用系统上没有孤立的页面(所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问)。 
     2、表单测试
       (1)、注册、登陆、信息提交等,必须测试提交操作的完整性,以校验提交给服务器的信息的正确性;
       (2)、用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等;
       (3)、检验默认值的正确性;
       (4)、如表单只能接受指定的某些值,测试时跳过这些字符,看系统是否会报错。
    3、Cookies测试(session测试同)
       (1)、Cookies是否起作用;
       (2)、Cookies是否按预定的时间进行保存;
       (3)、刷新对Cookies有什么影响。
    4、设计语言测试
       (1)、使用哪种版本的HTML;
       (2)、验证不同的脚本语言。例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等。
    5、数据库测试
       (1)、数据一致性错误:主要是由于用户提交的表单信息不正确而造成的;
       (2)、输出错误:主要是由于网络速度或程序设计问题等引起的。
    二、性能测试
    1、连接速度测试
       (1)、Web系统响应时间;
       (2)、超时的限制。
    2、负载测试
       (1)、某个时刻同时访问Web系统的用户数量;
       (2)、也可以是在线数据处理的数量。
    3、压力测试
       (1)、压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。
       (2)、压力测试的区域包括表单、登陆和其他信息传输页面等。
    三、可用性测试
    1、导航测试

       (1)、导航是否直观
       (2)、Web系统的主要部分是否可通过主页存取
       (3)、系统是否需要站点地图、搜索引擎或其他的导航帮助
       (4)、Web应用系统的页面结构、导航、菜单、连接的风格是否一致 
       (5)、Web应用系统导航帮助要尽可能地准确。Web应用系统的层次一旦决定,就要着手测试用户导航功能。
    2、图形测试
    一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:
       (1)、要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间;
       (2)、Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面;
       (3)、验证所有页面字体的风格是否一致;
       (4)、背景颜色应该与字体颜色和前景颜色相搭配;
       (5)、图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩。
    3、内容测试
        检验Web应用系统提供信息的正确性、准确性和相关性。
        信息的正确性是指信息是可靠的还是误传的 。
    4、整体界面测试
        整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?当然,对界面的整体测试并不能单靠个人直觉来评定;每个人的审美观、专业角度、系统面向的行业及用户、甚至性别与年龄等等,都是可能导致对界面作出不同评价的因素。所以要明白在对整体界面的测试过程中,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。
    四、兼容性测试
    1、平台测试
       在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。
    2、浏览器测试
       (1)、浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、Javascrīpt、ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如,ActiveX是Microsoft的产品,是为Internet Explorer而设计的,Javascrīpt是Netscape的产品,Java是Sun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
       (2)、测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
    五、安全性测试
       (1)、现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等;
       (2)、Web应用系统是否有超时的限制,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用;
       (3)、为了保证Web应用系统的安全性,需要测试相关信息是否写进了日志文件、是否可追踪;
       (4)、当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性;
       (5)、服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。
       (6)、通过模拟攻击的形式拷贝Web应用程序的某个功能点的url地址,然后打开新的页面输入该url地址看其是否能跨过系统的登录模块直接进入该功能点。
       (7)、服务器端IIS是否设置了默认文档功能。
       (8)、IIS服务器的主目录应该与操作系统的安装路径设置在不同的盘符下。
  • SQL Injection(SQL注入)介绍及SQL Injection攻击检测工具

    2009-10-14 15:36:59

    SQL Injection(SQL注入)介绍及SQL Injection攻击检测工具(转载)

    1.关于SQL Injection
    迄今为止,我基本没有看到谁写出一篇很完整的文章,或者说很成熟的解决方案(能做到 的人肯定很多,问题是没有流传开来,很遗憾) 我简单的说几点,希望启发大家思考,起到抛砖引玉的作用

    一、SQL Injection的原理
    SQL Injection的实现方法和破坏作用有很多,但万变不离其宗,其原理可以概括为一句话 :SQL Injection就是向服务器端提交事先准备好的数据,拼凑出攻击者想要的SQL语句,以改变数据库操作执行计划。
    我想,这么说也许不算精炼,但意思应该很明确了,这句话主要包含这么三层意思:
    1.攻击者通过何种途径注入?
    存在SQL Injection漏洞的地方都是应用程序需要根据客户端环境构造SQL语句的地方。由此可以推论,只要存在"客户端数据替换预定义变量"的地方,就有可能被注入。
    客户端提交数据可以有很多种方式:GET,POST,Client-Agent,Cookie,Server Enviroment...
    2.攻击者为什么可以将它想要的语句"注入"?
    因为服务器端应用程序采用拼凑(请特别留意这个词)SQL语句的方式,这使得攻击者有机会在提交的数据中包含SQL关键字或者运算符,来构造他们想要的语句。
    3.SQL Injection最终结果是什么?
    改变数据库操作执行计划。
    这个结果不一定是恶意的,只要你的SQL语句没有按照你预期的计划(plan)执行,那么就 可以视为被注入了,不管提交数据的人是不是恶意的。
    设有这样的sql语句:
    update tableName set columnName1 = " $Client_Submit_Data " where PK_ID = 1234

    $Client_Submit_Data是一个变量,它代表客户端提交的数据,这里我就不管环境是ASP还 是PHP还是其他什么东西了。
    假设这个操作是要更新一篇文章的标题,很多人是不是会这么构造SQL语句?我们看看$Cl ient_Submit_Data包含引号的情况,令$Client_Submit_Data = 谁能告诉我"sql injecti on"是什么?
    那么sql语句将被拼凑成这样:
    update tableName set columnName1 = "谁能告诉我"sql injection"是什么?" where PK_ID = 1234
    执行结果很明显,将执行这样的语句:update tableName set columnName1 = "谁能告诉我"
    where子句被忽略掉了,很遗憾,你的数据库中所有文章标题都会被update为"谁能告诉我 "

    在这个例子当中,用户应该是无心的——标题里面包括引号应该很正常吧——但结果却和SQL Injection无异。

    好啦,说了半天废话,言归正传,说一下如何应对这种问题。

    我相信这里的朋友都看过很多防止SQL Injection的文章了,也大都会通过replace来防范一些注入,问题是:你们知其然的时候是否知其所以然?

    我认为,彻底解决SQL Injection的最好方法是:避免拼凑SQL语句。这就是我在上面要大家特别注意拼凑这个词的原因。
    SQL Injection之所以有机可乘,是因为绝大多数Server Application采用拼凑SQL语句的方式来构建应用程序(阅读这个帖子的诸位,你们回首想想自己的项目,有几个不是通过拼凑SQL语句的方式来操作数据库?想想你们见过的被注入的案例,有几个不是采用的拼凑SQL语句的应用),所谓拼凑SQL语句,简单一点说就是:用连接字符串操作(ASP中的&和PHP中的.)将SQL关键字和客户端提交的数据连接起来并发送给DBMS执行。这样做直接导致 DBMS根本不知道你计划(plan to)做什么,而只知道你要(is to)做什么,不是吗,服务器端脚本总是将要执行的SQL语句构造好,然后发给数据库,DBMS根本不知道客户端数据 替换了变量之后,这个语句的执行计划是否有变化。服务器端脚本总是粗暴的告诉DBMS:你只管这么做好了,别问我为什么。就像上面我提到的更新文章标题的例子,DBMS不知道你只想更新第1234篇文章的标题,它以为你就是要把所有的标题都变成这个,因为你的语句就是没有where子句嘛!

    说到这里,可能大家都明白了,所谓的最好方法是Stored Procedure。Yes! That is!

    要想做出安全可靠的Server application,你最好把自己当作两个人,一个DBA,一个Coder(ASP Coder,PHP Coder or others),很多人往往只知道:我在做一个BBS,我在做一个留言本,我在做一个新闻发布系统,我们的流程都是这样的,给用户一个表单,让用户提交,然后去写数据库,用的时候根据条件把数据记录找出来,然后显示。没事,如果你 是一个业余爱好者,只想自己写点小东西玩玩,这足够了!如果你想把WebDev作为你的职业,或者说,你想成为一个非常专业的业余爱好者,你必须当自己是一个DBA+Coder,至于要不要是一个Designer就看你的能力和精力咯!

    好了,点到为止,我就说这么多,彻底的解决方法是要在DBMS上写入你的数据操作计划,让服务器在开始执行之前知道你的意图,不要粗暴的告诉它:我就是要你执行这个命令,不要问我为什么!

    实现方法嘛,目前比较普遍的,也比较容易实现的就是存储过程了,应用存储过程不仅可以从根本上解决SQL Injection这个安全问题,还会使得你的应用程序速度成倍增长(这个增长的幅度甚至可能达到一个数量级,这跟很多因素有关,不好一概而论),还会使得你开发的系统更想大型系统,拥有更好的架构体系(例如MVC模式)。

    在 MySQL 4.1.x及其后续版本和ODBC中,提供了一种叫做prepared statements的东西,它 本质上也是一种存储过程,一种系统预置(相对于用户自定义)的存储过程。

    如果你没有条件用上存储过程(比如数据库不支持,MySQL,Access,SQLite等都不支持),那么就只能将SQL Injection扼杀在摇篮里了。解决方法,我也只简单的说一句:不要相信任何来自客户端的数据。这个客户端的数据,可以通过很多途径被提交,比如get,post ,cookie,browser参数,IP地址,等等,只要不是服务器上获取的就都算客户端数据,只要是客户端数据,都是不可信的,在TCP/IP这个大框架下,什么都是可以伪造的,包括IP地址。

    凡是来自客户端的数据,必须校验——注意是校验,不是过滤。基本上,不管你多聪明多细心(哪怕像我一样,不许笑,不许笑,严肃点,严肃点,我们这儿讲SQL Injection呢) 也无法穷举可能被用于SQL Injection的符号和关键字,也无法预知替换掉他们是否会有副 作用,最好的办法是不去判断什么数据不符合条件,而改由判断什么数据符合条件,假设你的一个系统用户名只能是字母数字和下划线,那么你就可以用[0-9a-zA-Z_]+这个正则来匹配它,如果不符合条件,拒之即可,这比费尽心思去过滤单引号分号逗号空格什么的要明了和简洁的多。

    当然如果你嫌存储过程麻烦,你也可以使用参数化SQL语句,至少在asp.net可以这么做,请见本人的一篇文章:《在ADO.NET中使用参数化SQL语句的大同小异》,网址是:http://blog.csdn.net/zhoufoxcn/archive/2008/03/19/2195618.aspx,介绍在asp.net中使用参数化SQL语句应注意的事项。

    春节前夕,数万个用PHPBB作为论坛的网站被攻陷,大家有印象吗?罪魁祸首只是一个单引 ,尽管PHP有magic_quotes_gpc,可还是被干掉了,原因是%2527在url_decode函数中会被解析为%27(因为%25就是百分号),%27正是引号,By the way,尽管博客中国的论坛也 是基于PHPBB的,但是那次我们幸免于难,因为在那之前我们被黑过一次了(汗),就是因为这个,哈哈! 其实,SQL Injection不是ASP编程领域特有的,Web开发最容易碰到,但Desktop Application也有,只要有数据库的地方,只要采用拼凑SQL语句的方式,就可能存在Injection的机会,大家牢记,如果有条件,尽量把数据DBMS职责范围的事情交给DBMS去做,如果没条件,一定要注意校验客户端提交的数据,当然,双管齐下也行,^_^

    好了,最后,说句话给那些有志于从事WebDev工作的朋友,如果将来你进入这个领域,你把总结出来这篇文章,你应该会很顺利的通过面试,并得到一个不错的薪水等级。

    附:微软发布3款SQL Injection攻击检测工具

    随着 SQL INJECTION 攻击的明显增多,微软近日发布了三个免费工具,帮助网站管理员和检测存在的风险并对可能的攻击进行拦截。

    Scrawlr
    下载地址:https://download.spidynamics.com/Products/scrawlr/

    这个微软和 HP合作开发的工具,会在网站中爬行,对所有网页的查询字符串进行分析并发现其中的 SQL INJECTION 风险。Scrawlr 使用了部分 HP WebInspect 相同的技术,但只检测 SQL INJECTION 风险。Scrawlr 从一个起始 URL 入口,爬遍整个网站,并对站点中所有网页进行分析以找到可能存在的漏洞。

    Microsoft Source Code Analyzer for SQL Injection
    下载地址:http://www.microsoft.com/downloads/details.aspx?FamilyId=58A7C46E-A599-4FCB-9AB4-A4334146B6BA&displaylang=en

    这款被称作 MSCASI 的工具可以检测 ASP 代码并发现其中的 SQL INJECTION 漏洞(ASP 代码以 SQL INJECTION 漏洞著称),你需要向 MSCASI 提供原始代码,MSCASI 会帮你找到存在风险的代码位置。

    URLScan 3.0
    下载地址: http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1697

    该工具会让 IIS 限制某些类型的 HTTP 请求,通过对特定 HTTP 请求进行限制,可以防止某些有害的请求在服务器端执行。UrlScan 通过一系列关键词发现恶意请求,并阻止恶意请求的执行。

282/2<12
Open Toolbar