发布新日志

  • 转载:(十三)软件测试技术——环境测试

    2008-07-14 11:09:57

    发布时间: 2008-6-20 16:12    作者: 陈能技    来源: 51Testing软件测试网

    本文选自《软件测试大全:测试技术、流行工具、项目实战》

    一些工程师的工作台上会摆满很多机器,测试工程师在同时操作着这些机器。其实很多时候是在进行环境测试,验证在不同的机器环境下,软件系统是否正常工作。环境测试,也有人叫兼容性测试或配置测试等,是指测试软件系统在不同的环境下是否仍然能正常使用。
            软件系统往往在开发和测试环境中运行正常,但是到了用户的使用环境则会出现很多意想不到的问题。由于现在的用户一般不会只使用一个软件系统,可能会同时运行多个软件系统,而且不同的用户有不同的使用习惯和喜好,因此会安装各种各样的软件系统。这些都可能会造成软件发布后出现很多兼容性的问题,以及一些与特定环境设置有关的问题。
            软件系统的应用环境越来越复杂,现在的软件系统一般涉及到以下几个方面的环境:
     操作系统环境;
     软件环境;
     网络环境;
     硬件环境;
     数据环境。
            软件在不同的操作系统环境下的表现有可能不一样。安装包可能需要判断不同的操作系统版本来决定安装什么样的组件。测试时还要注意即使是同一个版本的操作系统,SP的版本不一样也可能会有所区别。
            软件环境包括被测试软件系统调用的软件,或与其一起出现的常见软件。例如,有些软件需要调用Office的功能;一些特定的输入法软件也可能导致问题的出现,例如:通过DevPartner的覆盖率分析工具的命令行来启动一个.NET程序,再使用TestComplete进行录制,但回放时遇到TextBox控件输入的地方则输入不了中文字符。这种就是典型的两个软件之间的兼容性问题。
            对网络环境的测试是指采用的网络协议和结构不一样时,软件系统能否适应。最简单直接的测试方法是拔掉网线,模拟断网的情况,看软件系统是否出现异常,能否正确提示用户。
            对硬件环境的测试一般与性能测试结合在一起,包括检查软件系统在不同的内存空间和CPU速度下的表现。或者有些软件需要操作外部硬件,如打印机、扫描仪、指纹仪等,需要测试对一些主流产品的支持。
            有些软件系统需要导入用户提供的一些真实的基础数据,作为后续系统使用的基础。对这些类型的软件系统应该在发布之前进行至少一次的、加载用户数据后的全面功能测试


    技巧:环境测试一般使用组合覆盖测试技术进行测试用例的设计。

    例如某个软件系统需要运行在下面的环境中。
     操作系统:Windows XP 或 Windows 2003。
     Office版本:Office2003或Office2007。
     内存配置:128MB或512MB。
    如果全覆盖,则需要执行2×2×2=8项测试,如果没有足够的时间做这么多次的测试,则可以利用正交表法,或成对组合覆盖等方法减少测试次数。

  • 转载:(十二)软件测试技术——安装测试

    2008-07-14 11:08:05

    发布时间: 2008-6-19 15:14    作者: 陈能技    来源: 51Testing软件测试网

    本文选自《软件测试大全:测试技术、流行工具、项目实战》

    现在的软件系统很多都通过安装包的方式发布。用户通过安装包安装软件系统。安装包在安装的过程中就把很多参数和需要配置的东西设置好,用户安装好软件就可以马上使用。
    安装测试需要注意以下几点。
            (1)安装过程是否是必要的。有些软件系统根本不需要在安装过程中设置任何参数,不需要收集用户计算机的相关信息,并且软件不存在注册问题,软件系统是为某些用户定制开发的。这些软件系统的安装过程是不必要的。
            (2)安装过程。安装过程是否在正确的地方写入了正确的内容?安装之前是否需要什么必备组件,如果缺少了这些组件是否能提示用户先安装那些组件?能否自动替用户安装?安装过程的提示信息是否清晰,能否指导用户做出正确的选择?安装过程是否能在所有支持的操作系统环境下顺利进行?
            (3)卸载。能否进行卸载?卸载是否为用户保存了必要的数据?卸载是否彻底删除了一些不必要的内容?卸载后是否能进行再次安装?
            (4)升级安装。如果是升级安装的话,是否考虑到了用户旧系统的兼容性,尤其是旧数据的兼容性。
            (5)安装后的第一次运行。安装后的第一次运行是否成功?第一次运行是否需要用户设置很多不必要的东西?
            (6)利用工具辅助测试。安装测试可以利用一些工具辅助进行,例如,InstallWatch可用于跟踪安装过程中产生的所有文件和对注册表进行的修改。
            DevPartner的System Comparison工具则可以创建系统的某个时间点的快照,还可以将两个快照文件进行对比,找出不同的地方,这在安装测试过程中非常有用,可以清楚地知道安装前和安装后操作系统的不同之处。
            下面简要介绍一下System Comparison工具的使用过程。
    (1)首先打开System Comparison,如图9.25所示。

     图9.25  打开System Comparison工具
    (2)对当前操作系统拍一个“快照”,把系统的信息保存起来。在这个界面中选择“Create and Save a snapshot”,则出现如图9.26所示的界面。

    图9.26  选择保存“快照”文件的路径
    (3)在这个界面中选择需要保存“快照”文件的目录,然后单击“确定”按钮。System Comparison就会自动收集操作系统的信息,如图9.27所示的界面。

    图9.27  收集操作系统信息

    收集完操作系统信息后,则会出现如图9.28所示的界面。

    图9.28  “快照”完成

    (4)完成后,测试人员就可以进行其他操作,例如运行安装包,或卸载程序,运行完后重复刚才的步骤再次获得一个操作系统的“快照”文件。这样就可以利用两个“快照”文件之间的差异来判断安装,或卸载程序是否正确地修改了操作系统的相关信息。
    (5)在如图9.25所示的界面中单击“Compare tow snapshot files”,则出现如图9.29所示的界面。

    图9.29  比较两个“快照”文件

    (6)在这个界面中,选择需要比较的两个“快照”文件,然后单击“Compare”按钮,则会分析两个文件之间的区别,然后得出如图9.30所示的结果。

    图9.30  比较的结果
            从结果中可以看出,在操作系统的System32目录下,有几个系统文件的版本改变了。通过这种方式,测试人员可以轻松地检查安装过程修改文件的正确性。

  • 转载:(十一)软件测试技术——安全性测试

    2008-07-14 11:05:50

    发布时间: 2008-6-18 15:46    作者: 陈能技    来源: 51Testing软件测试网
    本文选自《软件测试大全:测试技术、流行工具、项目实战》

      安全性测试是一项迫切需要进行的测试,测试人员需要像黑客一样攻击软件系统,找到软件系统包含的安全漏洞。
    1.网页安全漏洞检测
            一些设计不当的网站系统可能包含很多可以被利用的安全漏洞,这些安全漏洞如同给远程攻击者开了一个后门,让攻击者可以方便地进行某些恶意的攻击。例如,公共漏洞和披露网站CVE(Common Vulnerabilities and Exposures)公布了Element InstantShop中的Web网页add_2_basket.asp的一个漏洞项,允许远程攻击者通过隐藏的表单变量“price”来修改价格信息。这个表单的形式如下所示:

    <INPUT TYPE = HIDDEN NAME = "id" VALUE = "AUTO0034">
    <INPUT TYPE = HIDDEN NAME = "product" VALUE = "BMW545">
    <INPUT TYPE = HIDDEN NAME = "name" VALUE = "Expensive Car">
    <INPUT TYPE = HIDDEN NAME = "price" VALUE = "100">

            利用这个漏洞,不怀好意者可以任意设定price字段的值,然后提交给InstantShop网站的后台服务器,从而可能用100美元就可以获得一部BMW545。
            技巧:发现类似的安全漏洞的最好方法是进行代码审查。除了代码审查,测试人员还可以利用一些测试工具进行检查,例如:Paessler Site Inspector、Web Developer等。

    2.SQL注入
            SQL注入是另外一个经常忽略的安全漏洞,但是SQL注入同时也是一种非常普遍的代码漏洞,它会导致数据库端的敏感数据泄漏,或者服务器受到黑客的控制。例如,下面的一段代码就存在SQL语句的注入漏洞。

    SqlConnection sqlcon = sqlconnA;

    //打开连接
    sqlcon.Open();

    //组合一条查询语句
    SqlCommand cmd = "select count(*) from User where LogonName = ‘" + this.textBox1.Text +”’ and Password = ‘”+this.textBox2.Text;

    SqlDataAdapter adpt = new SqlDataAdapter(cmd, sqlcon);

    DataSet ds = new DataSet();
    adpt.Fill(ds);
    //关闭连接
    sqlcon.Close();

    //如果返回数据不为空,则验证通过
    If(ds.Tables[0].Rows.Count>0)
    {
       retuen true;
    }
    else
    {
       Return false;
    }

            这段代码从textBox1获得用户输入的用户名,从textBox2获得用户输入的密码,然后执行数据库查询操作。假设在textBox1的输入框输入一个已知的用户名,然后再做一些手脚,则可以不输入密码也能登录系统。这个字符串利用了SQL Server对单引号的处理方式,只要简单地组合成类似下面的字符串并输入到textBox1的输入框中即可。

    Admin' or '1' = '1

            这样就可以利用已知的Admin账号,不输入密码就能登录系统。因为给预期的SQL语句注入了额外的语句,所以实际上提交到SQL Server数据库执行的语句变成了如下所示的语句:

    select count(*) from user where LogonName = 'Admin' or '1'='1' and Password=''

            由于1=1是恒等的,因此返回的结果肯定为真,从而干扰了用户信息的正常验证,导致能绕过密码验证而登录系统。
            技巧:检查是否存在SQL语句注入漏洞的最好办法是代码审查,查看所有涉及SQL语句提交的地方,是否正确处理了用户输入的字符串。

    3.缓冲区溢出
            不仅仅是连上Internet的软件系统才会有安全问题,个人软件系统或公司内部的软件系统也存在安全问题,这些安全问题不会导致信用卡密码的泄漏,但是可能导致工作成果的丢失。如果软件系统是采用C语言这类容易产生缓冲区溢出漏洞的语言开发的话,作为测试人员就要注意检查可能造成系统崩溃的安全问题了。
            例如,下面的两行C语言代码就可能造成缓冲区的溢出问题:

    char buf[20];
    gets(buf);

            如果使用gets函数来从stdin读入数据,则可能出现缓冲区溢出的问题。另外一个例子如下:

    char buf[20];
    char prefix[] = "http://";
    strcpy(buf,prefix);
    strncat(buf,path,sizeof(buf));

            这里问题出现在sizeof的参数不应该是整个buf的大小,而是buf的剩余空间大小。
            技巧:测试人员需要对每一个用户可能输入的地方尝试不同长度的数据输入,以验证程序在各种情况下正确地处理了用户的输入数据,而不会导致异常或溢出问题。或者通过代码审查来发现这些问题。还可以利用一些工具来帮助检查这类问题,例如AppVerifier等。

  • 转载:(十)软件测试技术——软件的容量测试

    2008-07-14 11:02:58

    发布时间: 2008-6-17 14:29    作者: 陈能技    来源: 51Testing软件测试网

    本文选自《软件测试大全:测试技术、流行工具、项目实战》

      人们对于性能测试和压力测试的理解往往源于对网站的体验,例如访问某个网站的页面,10秒钟还未打开,于是大部分人都选择了放弃。一个关于网站响应时间对用户影响的调查结果显示如图9.14所示。

    9.14  网站响应时间对用户的影响

        根据上图所示的结果表明,响应时间在4s以内,大部分用户可以接受;4~9s以内,30%的用户选择离开;8~9s,则有60%的用户选择离开;超过10s,则90%以上的用户选择离开。
        /S结构的软件系统的性能问题往往是由于不能支持大量的并发用户造成的,因此在很多人的眼里,性能测试就是模拟并发量的测试,于是一提起性能测试首先是去找LoadRunner之类的工具,却忽略了性能测试的另外一个重要方面——大数据容量的测试。
        说明:大数据容量的测试是指软件系统在处理大数据量的时候,或者是加载了大批量数据时的性能表现。就像货车空车时,或装载较少货物时会跑得比较快,在装载了较多的货物时,则只能慢速行走。

        由于在需求调研和分析设计时,往往忽略了对用户若干年后的数据量和业务单据量的估计,因此在测试时很容易被忽略掉。这也是为什么一些业务系统在使用了若干年后被抛弃的原因——不能支持现有的业务量处理能力。要考虑软件的大数据容量测试,尤其是对于那些会随软件系统的持续使用而增加大量数据的业务系统。大数据容量测试的过程可以参考图9.15所示的步骤。

    图9.15  大数据量性能测试的步骤


        在生成大批量数据之前,首先需要估算软件系统将来使用的业务数据量。

        技巧:大数据容量测试的关键是模拟大批量的用户业务数据,因此首先要估算好用户若干年后可能出现的最大数据量。

    业务数据量不能凭空估算,最好能与用户一起研究业务的发展情况,充分估计可能出现的业务量和单据量。除了估算业务量,还要看哪些功能操作是比较频繁使用的,哪些功能操作是不常使用的,以便性能测试和调优有重点地进行。
            如果某些功能操作是用户经常使用的,那么就要求响应时间要更短些;如果某些功能操作是用户不常用的,例如一些年度统计报表,虽然数据量大,可能导致查询统计的时间比较长,但是因为执行的次数不多,因此即使运行时间比较长也不会对用户造成太大的困扰。
            在估算好数据量后,下一步就是用各种手段来模拟生成业务数据量。找出需要进行大数据量性能测试的功能模块,然后分析该功能模块用到了什么数据库表,然后向这些表插入估算的数据量的业务数据,如图9.16所示。

    图9.16  向功能模块对应的数据表插入数据

            技巧:模拟大批量的数据可以采用一些数据生成工具,例如DataFactory等。也可以自己编写SQL语句插入数据库表或者编写程序产生大批数据。

            下面以DataFactory 5.6为例,简单介绍一下用DataFactory生成大批量数据的过程。
    (1)首先选择需要插入数据的数据库类型,如图9.17所示。
    (2)在这个界面单击“下一步”按钮,出现如图9.18所示的界面。

     图9.17  选择数据库类型

     

    图9.18  配置数据库连接

    (3)在这个界面中指定数据库连接的账号,单击“下一步”按钮,则出现如图9.19所示的界面。
    (4)在这个界面中,选择需要插入数据的表,然后单击“下一步”按钮,则出现如图9.20所示的界面。

    图9.19  指定需要插入数据的表

    图9.20  指定生成数据的名称

    (5)在这里,给即将生成的数据输入一个名称,然后单击“下一步”按钮,则出现如图9.21所示的界面。
    (6)这个界面提示设置完成,单击“完成”按钮,确认各项设置,则出现如图9.22所示的界面。
    (7)在这个界面中,选择需要插入数据的表格节点,指定即将插入的数据行数。选择表格节点下的字段节点,则出现如图9.23所示的界面。

    9.21  设置完成

    图9.22  设置插入数据记录的条数
    (8)在字段节点的属性界面可设置字段数据的生成规则,所有字段都设置完毕后,单击工具栏中的“Run”按钮,DataFactory就会自动按照设置的要求生成数据,生成完毕后,出现如图9.24所示的对话框。

     图9.23  设置字段数据生成的规则

    图9.24  数据生成完毕

            注意:生成的数据应该尽量真实地模拟用户业务数据,而不仅仅是数据量上的模拟。

            有些测试人员在生成一个库存表时,把每条记录中备注字段的数据都填满(这个备注字段是一个长度为500的varchar类型),因为数据的失真而造成了虚假的性能问题。用户在实际使用中很少会填写这个字段的内容,即使填写也不可能每个都填满500的长度。
            在生成了大批量的数据后,接下来就需要把这些数据加载到软件系统进行功能测试。在准备好数据后应该执行所有的功能,找出响应时间明显迟缓的功能操作,监视和记录客户端和服务器的内存使用情况、CPU使用情况、网络传输量和速度、数据库的性能参数等。

  • 转载:(九)软件测试技术——数据库性能检查和压力测试

    2008-07-14 10:51:18

    上面介绍的都是代码层的性能测试,而目前很多软件系统都需要应用到数据库,通常数据库也会成为性能瓶颈之一。如图所示的是一个简单C/S结构系统可能出现性能瓶颈的地方。

     简单C/S结构系统可能出现性能瓶颈的地方


    那么测试人员应该如何发现数据库相关的性能问题呢?
            首先要分析什么会引起数据库的性能问题,一般来说有两个主要原因:数据库的设计和SQL语句。
            数据库的设计又分为数据库的参数配置和逻辑结构设计,前一种比较好解决,后一种则是测试人员需要关注的,糟糕的表结构设计会导致很差的性能表现。例如,没有合理地设置主键和索引则可能导致查询速度大大降低。没有合理地选择数据类型也可能导致排序性能降低。
            低效率的SQL语句是引起数据库性能问题的主要原因之一,其中又包括程序请求的SQL语句和存储过程、函数等SQL语句。对这些语句进行优化能大幅度地提高数据库性能,因此是测试人员需要重点关注的对象。
            技巧:可以借助一些工具来帮助找出有性能问题的语句,例如SQL Best Practices Analyzer、SQLServer数据库自带的事件探查器和查询分析器、LECCO SQLExpert等。

    软件的“极限考验”——压力测试
            是否想知道软件系统在某方面的能力可以达到一个怎样的极限呢?软件项目的管理者以及市场人员会尤其关心压力测试的结果,想知道软件系统究竟能达到一个怎样的极限。压力测试(stress testing)就是一种验证软件系统极限能力的性能测试。
            压力测试与负载测试(load testing)的区别在于,负载测试需要进行多次的测试和记录,例如随着并发的虚拟用户数的增加,系统的响应时间、内存使用、CPU使用情况等方面的变化如何。压力测试的目的很明确,就是要找到系统的极限点。在系统崩溃或与指定的性能指标不符时的点,就是软件系统的极限点。

            说明:实际上,在做性能测试的过程中不会严格区分这些概念,它们的界限有些模糊。对于测试人员来说,更关心的是如何满足性能需求,如何进行性能测试。

            经常碰到性能需求不明确的情况。用户通常不会明确地提出性能需求,在进行需求分析和设计时也通常把性能考虑在后面。即使提出了性能上的要求,也是很模糊的,例如:“不能感觉到明显的延迟”。
            对于不明确的性能需求,通常需要进行的不是极限测试,而是负载测试,需要逐级验证系统在每一个数据量和并发量的情况下的性能响应,然后综合分析系统的性能表现形式。

  • 转载:(八)软件测试技术——单元级别的性能测试

    2008-06-16 10:28:17

    转载:(八)软件测试技术——单元级别的性能测试

            随着网络的发展,软件也越来越复杂,从独立的单机结构,到C/S结构、B/S结构、多层体系架构,面向服务的(SOA)结构等,集成的软件技术越来越多,支持的软件用户也越来越多。一种凸显在人们面前的问题是性能问题。很多软件系统在开发测试时没有任何问题,但是上线不久就崩溃了,原因就在于缺少了性能方面的验证。
    性能测试“从小做起”
            软件是否在上线之前进行性能测试就能解决问题呢?不一定,如果性能测试进行得太晚,会带来修改上的风险。很多软件系统在设计的时候并没有很好地考虑性能问题和优化方案,等到整个软件系统开发出来后,测试人员忙着集成测试,开发人员也疲于应付发现的功能上的Bug,当所有功能上的问题都得到解决后,才想到要进行性能测试。性能测试结果表明系统存在严重的问题,如响应时间迟缓、内存占用过多、不能支持大量的数据请求,在大量用户并发访问的情况下会造成系统崩溃。如果此时再去修改程序已经非常困难了,因为要彻底地解决性能问题,需要重新调整系统的架构设计,大量的代码需要重构,这时的程序员已经筋疲力尽,不想再进行代码的调整了,因为调整带来的是大量的编码工作,同时可能引发大量的功能上的不稳定性和再次出现大量的Bug。
            这给测试人员一个启示,性能测试不应该只是一种后期的测试活动,更不应该是软件系统上线前才进行的“演练”,而应该是贯穿软件的生产全过程,如图所示。


            对于性能的考虑应该在架构设计时就开始,对于架构原型要进行充分的评审和验证。由于架构设计是一个软件系统的基础平台,如果基础不好,也就是根基不牢,性能问题就会根深蒂固,后患无穷。
    性能测试应该在单元测试阶段就开始。从代码的每一行效率,到一个方法的执行效率,再到一个逻辑实现的算法效率;从代码的效率,到存储过程的效率,都应该进行优化。单元阶段的性能测试可以考虑从以下几个方面进行:
     代码效率评估;
     应用单元性能测试工具
     数据库优化。
            应该注意每一行代码的效率,所谓“积少成多,水滴石穿”,一些看似细小的问题可以经过多次的执行累积成一个大的问题,也是一个量变到质变的过程。例如,在用C#编写代码的时候,有些程序员喜欢在一个循环体中使用string字符串变量,类似下面的代码:
    static void Loop1()
    {
         string digits = string.Empty;

         for(int i=0;i<100;i++)
         {
              //累加字符串
              digits+=i.ToString();
         }
         Console.WriteLine(digits);
    }

            这样一段代码其实是低效率的,因为string是不可变对象,字符串连接操作并不改变当前字符串,只是创建并返回新的字符串,因此速度慢,尤其是在多次循环中。应该采用StringBuilder对象来改善性能,例如下面的代码就会快很多:

    static void Loop2()
    {
         //新建一个StringBuilder类
         Stringbuilder digits = new StringBuilder();

         for(int i=0;i<100;i++)
         {
              //通过StringBuilder类来累加字符串
              Digits.Append(i.ToString());
         }
         Console.WriteLine(digits.ToString());
    }

            类似的问题有很多,它们的特点是单个问题都很小,但是在一个庞大的系统中,经过多次的调用,问题会逐渐地被放大,直到爆发。这些问题都可以通过代码走查来发现。

            技巧:如果测试人员不熟悉代码怎么办呢?那么可以借助一些代码标准检查工具,例如FxCop、.TEST等,来帮助自动查找类似的问题。

            测试人员可以使用一些代码效率测试工具来帮助找出哪些代码或方法在执行时需要耗费比较长的时间,例如AQTime是一款可以计算出每行代码执行时间的工具。如图所示,可以看出每一个方法甚至每一行代码的执行时间是多少。这对开发人员在查找代码层的性能瓶颈时,也会有很大的帮助。


    使用AQTime查找低效率的代码行
            除了代码行效率测试工具外,最近还出现了一些开源的单元级别的性能测试框架,可以像使用XUnit这一类的单元测试框架一样,但是不是用于测试单元代码的正确性,而是用于测试函数、方法的性能是否满足要求。例如NTime就是这样的一个小工具。
    NTime可以并发地运行同一个方法多次,查看能否达到预期的性能指标。例如,下面的代码使用NTime框架启动两个线程,在1秒钟内并发地执行MyTest方法多次。

    [TimerHitCountTest(98,Threads = 2,Unit = TimePeriod.Second)]
    Public void MyTest()
    {
         //调用被测试的方法
         MethodToBeTest();
    }

            如果测试结果表明能执行超过98次,则认为“MethodToBeTest”方法的性能达标,否则将被视为不满足性能的要求。

  • 转载:(七)软件测试技术——单元测试

    2008-06-12 14:48:41

    转载:(七)软件测试技术——单元测试

    本文选自《软件测试大全:测试技术、流行工具、项目实战》

            单元测试是针对软件设计中的最小单位-程序模块,进行正确性检验的测试工作,其目的在于发现每个程序模块内部可能存在的差错。由于敏捷开发的兴起,单元测试这个曾经的“昔日黄花”再度被受到追捧。没有采用敏捷开发方式的软件企业也在重新审视单元测试的重要性。
            对于单元测试的定义,应该分成广义的和狭义两种。狭义的单元测试是指编写测试代码来验证被测试代码的正确性。广义的单元测试则是指小到一行代码的验证,大到一个功能模块的功能验证,从代码规范性的检查到代码性能和安全性的验证都包括在内,视单元的范围而定义。
    1.单元测试由谁来做
            关于单元测试应该由谁来做,存在两种截然不同的对立观点。一部分人认为单元测试既然是测试的一种类型,当然应该由测试人员负责;另外一部分人则认为,开发人员应该通过编写单元测试的代码来保证自己写的程序是正常工作的。
            支持单元测试应该由开发人员执行的人认为,单元测试是程序员的基本职责,程序员必须对自己所编写的代码持有认真负责的态度。由程序员来对自己的代码进行测试的代价是最小的,却能换来优厚的回报,因为在编码过程中考虑测试问题,得到的是更优质的代码,这个时候程序员对代码应该做什么了解得最清楚。如果不这样做,而是一直等到某个模块崩溃时,程序员则可能已经忘记代码是怎样工作的,需要花费更多的时间重新弄清代码,即使这样也不一定能完全弄清楚,因此修改的代码往往不会那么彻底。
            那些对程序员不应该测试自己代码的人认为,单元测试应该由测试人员来做。程序员通常都有爱护自己程序的潜在心理,不忍心对程序进行破坏性的测试,而且,程序员也缺乏像测试人员一样敏锐的测试思维,很难设计出好的测试代码。

            说明:广义的单元测试不仅包括编写测试代码进行单元测试,还包括很多其他的方面,例如代码规范性检查,则完全可以由测试人员借助一些测试工具进行。

    2.结对单元测试
            关于单元测试应该由谁来完成,两部分人各持己见,争论了很多年,直到极限编程、测试驱动开发模式(TDD)出现,才使得两种意见得以综合考虑。
            TDD把单元测试的地位提高到了史无前例的最高点,倡导测试先行、用测试驱动开发。测试是最好的设计,在编写代码之前就要把测试考虑清楚,这样在编写代码时才胸有成竹。有人举了两个工匠砌墙的例子来说明TDD。
            工匠一的做法:先将一排砖都砌完,再拉上一根水平线,看看哪些砖有问题,再进行调整,如图所示。


            工匠二的做法:先拉上一根水平线,砌每一块砖时,都与这根水平线进行比较,使得每一块砖都保持水平,如图所示。

            一般人都会抱怨工匠笨,这样多浪费时间啊!然而想想平时在编写程序的时候很多人不也是这样干的吗?甚至比工匠一还要笨,等到正面墙都砌完了,直接进行集成测试,经常让整面墙倒塌。
            TDD认为应该尽早进行测试,甚至在代码还没编写出来之前就先编写测试代码进行测试。如果是这样的话,很明显应该由开发人员进行单元测试了,程序员责无旁贷地要担负起单元测试的职责。
            那么,反对这样做的人的观点是什么呢?测试人员应该与开发人员进行结对的单元测试,测试人员的优势是具有敏锐的测试思维和测试用例设计能力,应该充分利用测试人员的这些优点。一种可行的办法是:把两种观点结合在一起,让测试人员设计测试用例,开发人员编写测试代码实现测试用例,再由测试人员来执行测试用例。也就是说,让测试人员和开发人员结对进行单元测试,如图所示。


            开发人员与测试人员在单元测试的过程中必须紧密地合作,一起讨论应该进行哪些测试以及怎样测试,应该添加哪些测试数据。
            开发人员应该向测试人员提供程序的设计思路、具体实现过程以及函数参数等信息。
            测试人员根据了解到的需求规格、设计规格来进行测试用例的设计,指导开发人员按照测试用例进行测试代码的设计。
            测试人员运行开发人员编写的测试代码进行单元测试以及结果的收集与分析。或者利用单元测试工具让单元测试代码自动运行。
            结对单元测试要求测试人员对需求的把握能力要强,而且对设计和编码过程有基本的认识。开发人员在结对单元测试中应能更好地按需求进行代码设计,同时也能从测试人员身上学到更多关于测试的知识,以便提高代码编写的质量和防止代码出错的能力。


     

  • 转载:(六)软件测试技术——探索性测试

    2008-06-12 14:42:16

    转载:(六)软件测试技术——探索性测试

    本文选自《软件测试大全:测试技术、流行工具、项目实战》

            探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具,但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性,抛弃繁杂的测试计划和测试用例设计过程,强调在碰到问题时及时改变测试策略。
            对探索性测试最直白的定义是:同时设计测试和执行测试。探索性测试有时候会与即兴测试(ad hoc testing)混淆。即兴测试通常是指临时准备的、即席的Bug搜索测试过程。从定义可以看出,谁都可以做即兴测试。由Cem Kaner提出的探索性测试,相比即兴测试是一种精致的、有思想的过程。
            在对测试对象进行测试的同时学习测试对象并设计测试,在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。这个有趣的过程如下图所示。

    探索性测试

            探索性测试强调测试设计和测试执行的同时性,这是相对于传统软件测试过程中严格的“先设计,后执行”来说的。测试人员通过测试来不断学习被测系统,同时把学习到的关于软件系统的更多信息通过综合的整理和分析,创造出更多的关于测试的主意。
    1.探索性测试的基本过程
            探索性测试的基本过程包括如下:
            识别软件系统的目的;
            识别软件系统提供的功能;
            识别软件系统潜在的不稳定的区域;
            在探索软件系统的过程中记录关于软件的信息和问题;
            创建一个测试纲要,使用它来执行测试。
            注意:上面的过程是一个循环的过程,并且没有很严格的执行顺序,完全可以先创建测试纲要,执行测试,然后在测试中学习软件系统;也可以先探索软件系统的各个区域,然后再列出需要测试的要点。

            探索性测试强调创新的测试思维,在测试过程中不断地出现许多关于测试的新想法,因此就像一把叉,下图就是一个所谓的“探索叉”(exploratory forks)。
            探索性测试强调测试过程中要有更多的发散思维,这也是与传统测试方式的最大区别。传统测试方式强调设计完善的测试用例,测试人员严格按测试用例执行测试,这多少限制了测试人员的测试思维,测试人员往往缺乏主观能动性。

    探索叉

    下图展示了一个发散思维的过程,探索性测试强调发散,但并不是盲目地发散,在适当的时候还要收敛回来。例如,当发现在一个测试的分支路径上已经花了很长时间也没有找到问题的答案时,则可以考虑先放弃那个区域的探索,因为还有一个主线的测试任务。

    发散思维

            探索性测试尤其适合于那些需求不是很明确的测试任务,或者是一名刚刚接手一项新的测试任务的测试人员使用。
    2.探索性测试的管理
            探索性测试是一种不是很严谨的测试方法,缺乏可管理性和度量性。因此,James Bach提出了基于任务的测试管理(Session-Based Test Management)。Session-Based测试管理是用于度量和管理探索性测试的一种方法。
            测试人员在采用探索性测试方法的测试过程中,应该及时记录下所谓的“测试故事”,把所有测试中学习到的关于软件系统的知识要点、问题和疑问、测试的主意、进行了怎样的测试等相关信息记录下来,然后周期性地与测试组长或其他测试人员基于记录的“测试故事”展开简短的讨论。
            测试组长基于这些记录的结果来判断测试的充分性,测试人员通过讨论可以共享学习到的软件系统相关的信息,交流测试的主意,总结测试的经验,激发测试人员拿出更多的测试主意,从而指导下一次测试任务的执行。
            在这种方式的测试管理中,测试组长就像一名教练,但是需要参与到测试的实际任务中,指导测试人员测试的方向和重点,提供更多的关于软件系统相关的信息给测试人员,授予测试人员更多的测试技术。

            说明:未必需要完全采用探索性测试的方法,但是可把探索性测试方式作为传统测试方式的补充,在每一项测试后留下一定的时间给测试人员做探索性的测试,以弥补相对刻板的传统测试方式的不足。应该更多地采用探索性测试的思维方式,应用在日常测试工作中。

  • 转载:(五)软件测试技术——手工测试与自动化测试

    2008-06-12 14:40:16

    转载:(五)软件测试技术——手工测试与自动化测试

    本文选自《软件测试大全:测试技术、流行工具、项目实战》

            手工测试自动化测试也是很多测试人员争相讨论的两种测试方法。有人对自动化测试趋之若鹜,也有人对自动化测试嗤之以鼻。在做出如何看待自动化测试的决定之前,首先要对自动化测试有一个清晰的认识。
            自动化测试是对手工测试的一种补充,自动化测试不可能完全替代手工测试,因为很多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判断。而仅仅依赖手工测试的话,则会让测试过于低效,尤其是回归测试的重复工作量对测试人员造成了巨大的压力。
            因此,可以得出一个结论:手工测试与自动化测试与一个都不能少,关键是在合适的地方使用合适的测试手段。
    1.自动化测试
            自动化测试是软件测试发展的一个必然趋势。随着软件技术的不断发展,测试工具也得到长足的发展,人们开始利用测试工具来帮助自己做一些重复性的工作。软件测试的一个显著特点是重复性,重复让人产生厌倦的心理,重复使工作量倍增,因此人们想到用工具来解决重复的问题。
            很多人一听到自动化测试就联想到基于GUI录制回放的自动化功能测试工具,如QTPRobotWinRunner等。实际上自动化测试技术的含义非常广泛,任何帮助流程的自动流转、替换手工的动作、解决重复性问题以及大批量产生内容,从而帮助测试人员进行测试工作的相关技术或工具的使用都叫自动化测试技术。例如,一些测试管理工具能帮助测试人员自动地统计测试结果并产生测试报告,编写一些SQL语句插入大量数据到某个表中,编写脚本让版本编译自动进行,利用多线程技术模拟并发请求,利用工具自动记录和监视程序的行为以及产生的数据,利用工具自动执行界面上的鼠标单击和键盘输入等。
            注意:自动化测试的目的是帮助测试,它可能部分地替代手工测试,但是不可能完全替代测试。

    2.手工测试
            手工测试有其不可替代的地方,因为人具有很强的判断能力,而工具没有。手工测试不可替代的地方至少包括以下几点。
            测试用例的设计:测试人员的经验和对错误的判断能力是工具不可替代的。
            界面和用户体验测试:人类的审美观和心理体验是工具不可模拟的。
            正确性的检查:人们对是非的判断、逻辑推理能力是工具不具备的。
            自动化测试有很强的优势,借助计算机的计算能力,可以重复地、不知疲倦地运行,对于数据能进行精确的、大批量的比较,而且不会出错。由此看来,手工测试和自动化测试是一个都不能少,而且应该有机地结合,充分利用各自的优势,为测试人员查找Bug提供各种方法和手段。
            注意:自动化测试的应用是一个需要详细考虑的问题,尤其是自动化测试工具的引入问题。

            不要为了应用工具而进行自动化测试,工具是为了自动化测试而产生的,有时候工具可能完全失效,因为工具不可能满足和适应所有软件的需求,此时,就需要测试人员自己动手编写程序或脚本来实现自动化了。

  • 转载:(四)软件测试技术

    2008-06-12 14:36:20

    转载:(四)软件测试技术

    软件测试技术
            在外行人看来,软件测试其实没什么技术可言,甚至有人认为测试无非是在摆弄一下软件的功能,只要懂得使用鼠标就足够了,这是对软件测试的一种误解。
    1.  黑盒测试与白盒测试
            很多测试人员喜欢讨论黑盒测试与白盒测试的区别,也有些测试人员感觉白盒测试很神秘,很高深,自己没有足够的开发能力是不可能进行白盒测试的。
    那么什么是黑盒测试,什么是白盒测试呢?下面对此进行简单介绍。
    1.1黑盒测试
            黑盒测试是一种把软件产品当成是一个黑箱的测试技术,这个黑箱有入口和出口,测试过程中只需要了解黑箱的输入和输出结果,不需要了解黑箱里面具体是怎样操作的。这当然很好,因为测试人员不用费神去理解软件里面的具体构成和原理,测试人员只需要像用户一样看待软件产品就行了,如图1所示。

    图1  黑盒测试方法


            例如,银行转账系统提供给用户转账的功能,则测试人员在使用黑盒测试方法时,不需要知道转账的具体实现代码是怎样工作的,只需要把自己当成用户,模拟尽可能多的转账情况来检查这个软件系统能否按要求正常实现转账功能即可。
            如果只像用户使用和操作软件一样去测试软件黑盒测试可能存在一定的风险。例如,某个安全性要求比较高的软件系统,开发人员在设计程序时考虑到记录系统日志的必要性,把软件运行过程中的很多信息都记录到了客户端的系统日志中,甚至把客户端连接服务器端的数据库连接请求字符串也记录到了系统日志中,像下面的一段字符串:

    "Data Source=192.168.100.99;Initial Catalog=AccountDB;User ID=sa;PassWord=123456;

            那么按照黑盒测试的观点,这是程序内部的行为,用户不会直接操作数据库的连接行为,因此检查系统日志方面的测试是不会做的。这明显构成了一个Bug,尤其是对于安全性要求高的软件系统,因为它暴露了后台数据库账号信息。
            有人把黑盒测试比喻成中医,做黑盒测试的测试人员应该像一位老中医一样,通过“望、闻、问、切”的方法,来判断程序是否“有病”。这比单纯的操作黑箱的方式进了一步,这种比喻给测试人员一个启示,不要只是简单地看和听,还要积极地去问,积极地去发现、搜索相关的信息。应该综合应用中医看病的各种“技术”和理念来达到找出软件“病症”的目的,具体作法如下:
     “望”,观察软件的行为是否正常;
     “闻”,检查输出的结果是否正确;
     “问”,输入各种信息,结合“望”、“闻”来观察软件的响应程度;
     “切”,像中医一样给软件“把脉”,敲击一下软件的某些“关节”。

    1.2白盒测试
            如果把黑盒测试比喻成中医看病,那么白盒测试无疑就是西医看病了。测试人员采用各种仪器和设备对软件进行检测,甚至把软件摆上手术台解剖来看个究竟。白盒测试是一种以理解软件内部结构和程序运行方式为基础的软件测试技术,通常需要跟踪一个输入经过了哪些处理,这些处理方式是否正确,这个过程如图2所示。

    图2  白盒测试方法

            在很多测试人员,尤其是初级测试人员看来,白盒测试是一种只有非常了解程序代码的高级测试人员才能做的测试。熟悉代码结构和功能实现的过程当然对测试有很大的帮助,但是从黑盒测试与白盒测试的区别可以看出,有些白盒测试是不需要测试人员懂得每一行程序代码的。
            如果把软件看成一个黑箱,那么白盒测试的关键是给测试人员戴上一副X光透视眼镜,测试人员通过这副X光透视眼镜可以看清楚输入到黑箱中的数据是怎样流转的。
            一些测试工具就像医院的检测仪器一样,可以帮助了解程序的内部运转过程。例如,对于一个与SQL Server数据库连接的软件系统,可以简单地把程序的作用理解为:把用户输入的数据通过SQL命令请求后台数据库,数据库把请求的数据返回给程序的界面层展示给用户。可以把SQL Server自带的工具事件探查器当成是一个检查SQL数据传输的精密仪器,它可以记录软件客户端与服务器数据库之间交互的一举一动,从而让测试人员可以洞悉软件究竟做了哪些动作。
            在测试过程中,应该综合应用黑盒测试方法和白盒测试方法,按需要采用不同的技术组合。不要用黑盒测试方法和白盒测试方法来划分自己属于哪一类测试人员,一名优秀的测试人员应该懂得各种各样的测试技术和查找Bug的手段。

  • 转载:(三)软件测试报告写作实战案例

    2008-06-12 13:29:51

    转载:(三)软件测试报告写作实战案例

            在软件测试中应用PDCA循环的目的是为了提高测试质量和产品质量。大到整个测试过程,小到执行一个测试或者录入一个Bug,都可以体现PDCA的精神。
    首先制定好测试计划,执行测试计划,通过测试执行结果来检查测试计划制定的合理性,然后分析计划偏离的原因,把总结出来的经验用于指导下一次测试的计划,这样就形成了一个PDCA循环过程。
            编写一份
    测试报告或者一个Bug也可以应用PDCA循环。例如,先策划好报告的主题和内容,打好腹稿,再写下来,写完要检查,看是否准确,是否有错别字,然后提交审核,对提出的意见进行分析,将总结的经验用于指导下一次报告的编写,这样的过程同样也是一个PDCA。
            编写测试用例也是一个PDCA。首先计划测试用例的编写方式,搭建测试用例的大纲和框架,然后设计和编写测试用例,并自行检查或与同行一起交叉检查,最后通过评审来发现更多的问题,如有哪些没有考虑周全的,或设计不完善的地方;或者通过执行测试用例,发现Bug,再根据执行的情况和Bug的情况来分析测试用例的有效性,把这些总结出来的经验用于指导下一次的测试用例设计。
            测试的执行过程则是一个可间接用于改进产品质量和程序员能力的PDCA循环。例如,首先开发人员写出代码,策划拥有一定质量水平的产品,测试人员对产品执行测试,发现Bug,通过分析Bug出现的原因,对开发人员的开发方式做出新的指导,从而避免下一次错误的出现。通过这种方式改进质量,同时也提高了程序员编写高质量代码的能力,把错误遏制在产生的源头。
    五、客观全面的测试报告
            测试需要以一个完美的方式结束,编写一份出色的测试总结报告可为一个完美的测试过程划上一个圆满的句号。
            一份测试报告应该包括测试资源的使用情况:投入了多少测试人员,所用时间多长,执行了多少测试用例,以及覆盖了多少功能模块等。
            另外,对测试对象的缺陷分析也是必须的,包括共发现了多少缺陷,缺陷的类型主要是哪些,缺陷集中在哪些功能模块,缺陷主要发生在哪几个开发人员的身上。这些信息都是大家关心的,需要及时报告,项目经理或QA需要根据这些信息做出决策。

            注意:报告应该尽可能客观、尽可能全面地反应测试情况和缺陷情况。

    7.8.6  实用测试经验的总结
            测试总结报告应该包括测试过程的成功与失败经验,从测试过程的管理经验,具体到某个Bug的分析总结,或者是与开发人员合作交流的经验,都可以总结出来。
            测试总结报告应该分析测试的整个过程,如是否合理安排了测试资源,测试进度是否按计划进行,如果没有其原因是什么,如何避免下次出现类似的问题?风险是如何控制的?出现了什么意外情况?下次能否预计到这些问题,等等。
            测试总结报告还应包括某些专门类型的测试经验总结。例如,
    性能测试采用了什么好的方法?碰到的问题是如何解决的?自动化测试脚本如何编写?应该选取哪些功能模块进行自动化测试?等等。
            测试总结报告应该包括对测试用例的分析。例如,测试用例的设计经验总结,哪些用例设计得好,能非常有效地发现Bug,总结的这些东西无论是对本项目组的测试人员,还是对
    其他项目组的测试人员都会大有帮助。
            如果能分析总结出Bug模式,那么总结报告还应该包括Bug模式的总结。

  • 转载:(二)软件测试报告写作实战案例

    2008-06-03 11:26:45

    (二)软件测试报告写作实战案例

    三、典型缺陷与Bug模式
            软件开发有设计模式,测试其实也有模式存在,需要测试人员进行总结和归纳。测试人员应从经常出现的Bug中学习,总结出Bug模式,用于指导测试。如果开发人员能关注这些Bug模式,还能起到预防错误的效果。
            要成为典型缺陷,必须满足以下条件:
            重复出现、经常出现;
            能代表某种类型的错误;
            能通过相对固定的测试方法或测试手段来发现这些错误。
            总结这些典型缺陷出现的现象,出现的原因,以及测试方法,就能成为一个Bug模式。

            说明:根据不同的开发平台、开发工具、开发语言、产品类型、采用的架构等,可以总结出不同的Bug模式,不同的Bug模式可能在不同的平台、语言、产品类型中才会出现。测试人员应该总结适合自己项目特点的Bug模式。

            提炼Bug模式的一般步骤如下:
            步骤1:分析缺陷报告,找出经常出现的Bug类型。
            步骤2:分析Bug的根源,找出Bug产生的深层次原因。
            步骤3:分析找到Bug的方法,总结如何才能每次都发现该类型的Bug。
            下面举一个例子来说明这个过程。
            首先,测试人员在分析缺陷报告时发现,有一类Bug经常出现,并且错误现象一致:执行某功能时提示Time Out。
            测试人员与程序员一起分析原因,发现这些错误都是在操作数据库时发生,发送的SQL语句被数据库长时间执行未返回,因此提示Time Out。通过进一步地分析表明,.NET的SqlCommand的CommandTimeOut属性是用于获取或设置在终止执行命令的尝试并生成错误之前的等待时间。等待命令执行的时间(以秒为单位)默认为30s,而数据库操作在较大数据量的情况下一般都超过这个时间,因此会提示超时的错误信息。
            这样就可以把这种类型的Bug归纳为“数据库操作超时Bug模式”。
            那么,如何才能找出这样的Bug呢?一般情况下,这类Bug基本上不会出现,只有数据量足够大时才会出现,因此需要设置大批数据,结合性能测试或压力测试来发现此类问题。也可以通过白盒的方式,查找程序在使用SqlCommand时是否合理地设置了Command TimeOut属性,这样将更有针对性地揭露上述的错误。
            至此就完成了一个Bug模式的归纳、提炼和总结,如果程序员积极地参与到该总结和分析过程中来,则可形成一个良性的反馈,当下次程序员编写相同的程序时就会避免类似的错误发生。
    四、测试中的PDCA循环
            PDCA循环是一种放之四海皆准的原则。在软件测试的过程中,也充斥着各种PDCA循环。PDCA循环是一个自我完善和改进的全闭环模型,如图7.34所示,对质量的不断提高和改进非常有效。

      PDCA循环模型

  • 转载:(一)软件测试报告写作实战案例

    2008-06-03 11:10:24

    (一)软件测试报告写作实战案例

    测试总结和报告

            测试人员的工作通常并不像开发人员那样能直接体现出来,让大家一目了然。开发人员做的是建设性的工作,如开发了哪些功能,写了几行代码,设计了几个类,都能直观地看到,而且,通过软件能很鲜活地演示开发人员的工作成果。
            但是测试人员的工作相对隐蔽一点,测试人员做的是破坏性的工作,并且没有很多可以直观体现测试人员贡献的东西。笔者曾经听到公司人事部的一位同事说:“你们做测试的真好,整天坐在那里”。当然,这是外行人看内行时说的话,但是给笔者的一个启示是:测试人员需要更多地表现自己,展现自己的工作成果。
            说明:由于缺陷列表太细、太大,测试用例过于专业,很多人对其不感兴趣,因此测试报告能很好地展示自己的工作状况,测试报告是提供给很多人看的一份文档。

            下面是一个项目的测试报告的纲要:
    1 简介
    1.1 编写目的
    1.2 项目背景
    1.3 术语和缩略词
    1.4 参考资料
    2 目标及范围
    2.1 测试目的及标准
    2.2 测试范围
    3 测试过程
    3.1 测试内容
    3.2 测试时间
    3.3 测试环境
    3.4 测试方法及测试用例设计
    4 测试情况分析
    4.1 测试概要
    4.2 测试用例执行情况
    4.3 缺陷情况
    4.4 测试覆盖率分析
    4.5 产品质量情况分析
    5 测试总结
    5.1 测试资源消耗情况
    5.2 测试经验总结
    6 附件
    附件1 测试用例清单
    附件2 缺陷清单
    一、缺陷分类报告
            缺陷分类报告是测试报告的重要组成部分,可以再细分为:缺陷类型分布报告、缺陷区域分布报告和缺陷状态分布报告等。
    1.缺陷类型分布报告
            缺陷类型分布报告主要描述缺陷类型的分布情况,看缺陷属于哪些类型的错误。这些信息有助于引起开发人员的注意,并分析缺陷为什么会集中在这种类型。例如,如果缺陷主要是界面类型的,如界面提示信息不规范、界面布局凌乱等问题,那么就要讨论是否需要制定相应的界面规范,让开发人员遵循,从而防止类似问题的出现。
    缺陷类型分布报告一般用饼图或柱状图显示。如图7.29所示,用饼图表示了几种类型的缺陷各自所占的比例。

    图  缺陷分布报告

    2.缺陷区域分布报告
            缺陷区域分布报告主要描述缺陷在不同功能模块出现的情况,这些信息有助于开发人员分析为什么缺陷会集中出现在某个功能模块。例如,如果缺陷主要集中在单据的审批过程中,那么就要分析是否是审批流程调用的工作流接口设计不合理。
            缺陷区域分布报告一般使用饼图或柱状图表示。如图7.30所示,用柱状图表示缺陷分布在不同的功能模块的个数。

                                                             图  缺陷区域分布报告
    3.缺陷状态分布报告
            缺陷状态分布报告主要描述缺陷各种状态的比例情况,例如Open、Fixed、Closed、Reopen、Rejected、Delay的Bug分别占了百分之多少。这些信息有助于评估测试和产品的现状:
            如果Open的Bug比例过高,则考虑让开发人员暂停开发新功能,先集中精力修改Bug;
            如果Fixed状态的Bug很多,则考虑让测试人员暂停测试新功能,先集中精力做一次回归测试,把修改的Bug验证完;
            如果Closed的Bug居多,则可能意味着功能模块趋于稳定;
            如果Reopen的Bug比较多,则需要分析开发人员的开发状态,是什么原因造成缺陷修改不彻底;
            如果Rejected的Bug比例过高,则要看开发人员与测试人员是否对需求存在理解上的分歧;
            如果Delay的Bug比例过高,则要考虑这个版本是否满足用户的要求,是否缺少了太多应该在这个版本出现的功能特性。
            缺陷状态分布报告一般使用饼图或柱状图表示。如图7.31所示,用饼图表示各种状态的缺陷个数以及所占的百分比。

    图  缺陷状态分布报告

      注意:其他的缺陷分类报告也可以写到测试报告中,例如,严重级别分类报告、优先级别分类报告、负责人分类报告、发现人分类报告、版本分类报告等。但是要注意,应该用这些分类报告来说明问题,而不要用来指责别人,例如使用负责人分类报告来嘲笑某个开发人员是“Bug大王”等。

    二、缺陷趋势报告
            缺陷趋势报告主要描述一段时间内的缺陷情况。如果项目管理比较规范,缺陷管理和测试流程比较正常的话,缺陷趋势报告还可以用来估算软件可发布的日期。
    例如,如图7.32所示的缺陷趋势图,表示在2001年9月3号至2001年9月24号之间的Bug状态变化。

                                                       图  缺陷趋势图
            从图7.32可以看出,Open状态的Bug在不断地增加,Fixed状态的Bug在2001年9月16号后开始骤然下降,这表示,这段时间开发人员有可能在开发几种新的功能,忽略了Bug的修改工作。
            发现并录入Bug,与修改并关闭Bug是一对互相对冲的两个变量,软件产品就是在这样此消彼涨的过程中不断完善和改进质量的。有经验的项目经理和测试人员会非常关注这样的发展曲线,从而判断项目产品的质量状态和发展趋势。笔者曾经在某个项目中与一位项目经理在项目的待发布阶段每天都在观察缺陷趋势图,这位项目经理甚至把它戏称为软件产品的“股市”技术图。
            但是确实能从这些图中看出一个产品的质量趋势,如果项目管理得比较规范的话,甚至可以从这些图的某些关键点推算出可发布版本的日期。在微软的项目管理中,把这种关键点称为零Bug反弹点。例如,图7.33中就有几个零Bug反弹点(用圆圈圈住的地方)。

    图 零Bug反弹

            项目在第一次达到零缺陷,即所有Bug(或者大部分Bug)都基本处理掉了,没有发现新的Bug时,还不能马上发布版本,因为Bug会反弹。由于缺陷的“隐蔽特性”和“免疫特性”,第一个零缺陷点是一个质量安全的假像,测试人员很快就会在新版本中发现更多的Bug,有些项目甚至要到第三个或第四个零Bug点才能安全地发布,这取决于项目的实际控制方式。

Open Toolbar