[唐僧团队] 唐僧是一个好领导,他知道孙悟空要管紧,所以要会念紧箍咒;猪八戒小毛病多,但不会犯大错,偶尔批评批评就可以;沙僧则需要经常鼓励一番。这样,一个明星团队就形成了。做测试工作也是这样,一个人强,不代表整个团队都强,团队合作才是根本~誓死把软件测试进行到底!<-->如果您觉得字体比较小的话,请按住键盘上的Ctrl键并滑动鼠标滚轮以改变字体的大小,谢谢!<-->欢迎交流~~~

为何要进行白盒测试

上一篇 / 下一篇  2008-04-01 21:26:30 / 个人分类:软件测试感想

软件白盒测试是一个与黑盒测试相对的概念,是指测试者针对可见代码进行的一种测试。白盒测试通常再划分为单元测试、集成测试两大类,但依据不同的流程,对白盒测试细分的标准也不尽一致,比如在IBM的IPD流程之下,白盒测试可能划分为如下几类:模块单元测试、模块集成测试、模块系统测试、渐增Build集成测试、系统集成测试等。而在XP实践中,单元测试与集成测试之间的界限并不明显,统称为渐增迭代测试。

  一、从一个比喻开始

  为什么要做白盒测试?这个问题比较复杂,我们先从一个比喻开始讲起。

  假设有一台的面包机,从上面倒入面粉与水,开动机器后从下面出来的就是烤好了的面包,这个机器的功能比较单一,接口很清晰,输入是面粉与水,输出是面包。现在假定这个面包机多年未用,内部都生锈了,现在要清洗它,类似于我们开发的软件,软件有Bug,那得通过测试来清理。
         

  那如何更快速的清洗这台面包机呢?有两种洗法,一是拿水从上往下灌,这是系统测试的方法。另一种是拆开来洗,拆开机 器后,拿抺布沾点清洁剂,把各零件的坑坑槽槽擦洗一遍,然后组装回来,再用水从上往下冲一遍,拆开来洗是白盒方法,组装回来用水冲是黑盒方式,相当于白盒 测试之后再追加一次系统测试。

  无疑,上面第二种方法是正确的,我们的前提是:清洗多年未用的面包机,铁锈够多,如果洗不干净,造出的面包都是致癌物质。当然,清洗面包机还只能算简单劳动,清理软件中的Bug要复杂得多,一个if语句有两条分支,一个while循环判断也是两条分支,还有break、continue、return等,想想看,一个1万行规模的软件能有多少个分支!一个分支就是一条坑坑槽槽,而且软件Bug还具备动态特性,不是静止的明摆在哪儿。

  所以,软件的白盒测试不可或缺,因为遗留Bug的影响很大,就像面包机没洗净留铁锈会致癌,还因为软件系统远比面包机复杂,不拆开来怎么能洗干净!

  二、白盒测试是高效测试

  尽管白盒测试如此重要,为什么还有许多企业不愿做白盒测试,有一个很重要的原因是:认为白盒测试太低效,不值得去做。

  实际上这种观点有许多误解成分,首先,决策者评估各阶段测试的有效性,仅以发现问题的数量为依据,这好比锈蚀斑斑的面包机,第一次冲水下去,看到大量浊水流出就很有成就感,其实这只是表象,思维方式有不足:把发现问题与解决问题割裂开来了。

  我们测试的目标是按既定质量标准稳定推进产品研发进度,只做系统测试的结果是:第一次冲水,很有成效,第二次冲水, 还能冲出点铁锈,第三次就没什么效果了。采用该手段并不能有效的达成既定质量目标。其次,研发质量改善,不只发现问题,还要定位问题、解决问题。白盒测试 是拆开来洗,发现、定位与解决问题不仅是彻底的,也是直接的,效率非常高,所以,单以发现问题数评估一个测试过程是否有效不尽准确,我们应该综合评估一个问题从被发现,到定位、解决,以及针对它完成回归测试的总效率。

下图来源于Capers Jones与McGraw-Hill的“Applied Software Measurement”文章,从该统计数据可看出,针对一个功能点的测试,若将问题发现、定位与解决都计算进去,单元测试效率最高,是集成测试的2倍,是系统测试的3倍。
          

  认为白盒测试低效的另一个误解是,决策者并未认清一个bug若遗留到下一阶段须多付出多少代价。经验数据表明,编码阶段的一个问题遗留到验收测试去解决,所须费用将增加5倍,如下图,一个问题越遗留到后面阶段解决,付出代价就越高,而且是成倍递增关系。

  所以,越早测试就越能节约成本,白盒测试作为早期测试,跳过不做是得不偿失的。

  依据上述原因,我们评估白盒测试效率时,通常将发现问题总数乘上一个系数K,以此为据再与其它测试方段的发现问题效率做对比,来权衡白盒测试值不值得去做。系数K取值与产品形态相关,按照实际经验,系数K取值区间为1.5~2.5,产品越复杂,出现问题越不容易解决的,K值要往大调。

  三、白盒测试能彻底解决编码阶段引入的问题

  前面我们分析了白盒测试是高效的测试,值得一做,下面我们要接着说明白盒测试必须要做,不可或缺。

先看一个案例,在某交换机产品的系统测试中,发现ISDN话机拨打某新业务号码时,在特定线路上,若一位一位的拨至18位,不会有问题,但如果先拨完号码再成组发送,会导致系统死机。这是一个导致死机的致命问题,最后定位出问题所在:呼叫处理的某段代码判断有误,本应小于18的判断,错写成小于等于18。

  这个问题本该在单元测试去发现,由于单元测试没做,问题就遗留到系统测试,庆幸的是没把它遗留到网上,否则问题就大 了。我们从另一个角度去反思,这个问题是特定线路下的特定终端,按特定方式拔打特定业务才暴露,在系统测试好不容易把它揪出来,但类似的其它问题呢?如何 保证在系统测试阶段都能测得出来?

  不同阶段的测试发现问题的特点各不相同,比如:单元测试阶段,容易发现逻辑问题、边界条件(如上例“小于18” 的错误)、变量未初始化、内存越界等问题,而集成测试容易发现接口错误、任务配合问题等,系统测试容易发现业务流程问题、界面操作问题等。如果某阶段的测 试没做,把问题遗留后面阶段,又如何能保证查错的彻底性。比如使用非法内存,出问题是否表现出来是随机的,如果操作非法内存当前被系统还认为是有效的,系统并不死机,但某些情况下,操作非法内存会死机,而另一些情况,非法内存操作将不期望变化的变量改写了,会导致其它莫名其妙的问题。类似这样的问题,在白 盒测试阶段很容易发现,也容易定位解决,但遗留系统测试阶段,就很难去发现、去定位。

  在V模型中,软件开发过程与测试行为具有不同层次的对应关系,如下图:
       

  单元测试针对编码阶段引入的问题,集成测试与功能测试针对软件设计中引入的问题,验收测试针对需求与规格。单元测试不要或缺的重要原因是:编码阶段引入的问题占很高比例,不进行单元测试就难以保证系统最终的稳定性。

我们再来看一个实际案例:有两个产品形态接近的项目,A项目正式实施单元测试与集成测试,另一个项目B项目没正式做白盒测试(简单的拿调试当测试)。最后项目结束时对研发全过程的全部问题进行缺陷分析,如下图:
       

            A项目的缺陷类型分析
        
           B项目的缺陷类型分析

  A项目的所有问题中,应该发现问题的阶段是白盒测试(单元测试与集成测试)的占50%,而B项目所有问题中,应在白盒测试阶段发现的仅占33%,另外,A项目发现逻辑错误占13%,而B项目只占8%。由这个统计数据表明,不做白盒测试必然导致大量问题漏测。 

  四、白盒测试要做到什么程度才算合适

  既然白盒测试不可或缺,那么,白盒测试应做到什么程度才算合适呢?具体来说,白盒测试与黑盒测试应维持什么样的比例才算合适?

  一般而言,白盒测试做多做少与产品形态有关,如果产品更多的具备软件平台特性,白盒测试应占总测试的80%以上,甚至接近100%,而如果产品具备复杂的业务操作,有大量GUI界面,黑盒测试的份量应该更重些。根据经验,对于大多数嵌入式产品,白盒方式展开测试(包括代码走读)应占总测试投入的一半以上,白盒测试发现的问题数也应超过总问题数的一半。

  由于产品的形态不一样,很难定一个标准说某产品必须做百分之多少白盒测试,但依据历史经验,我们还可以进行定量分析的。比如,收集某产品的某历史版本在开发与维护中发生的所有问题,对这些问题进行正交缺陷分析(Orthogonal Defect Classification,ODC),把“问题根源对象”属于概要设计、详细设计与编码的问题整理出来,这些都是属于白盒测试应发现的问题,统计这些问题占总问题数的比例,大致就是白盒测试应投入的比例。

  通过正交缺陷分析,还能推论历史版本各阶段测试的遗留缺陷率,根据“发现问题的活动”,能统计出与“问题根源对象”不相匹配的问题数,这些各阶段不匹配问题的比例就是该阶段的漏测率。

  参考文献:

  1. IPL, "Why Bother to Unit Test? "

  2. Wayne Chan, 《第4代白盒测试方法介绍》

  3. Yang Gu, fromIBM, "Adopting ODC to improve software quality: A case study"



TAG: 软件测试 手机测试 手机软件测试 软件测试感想

zhaoleixinlang的个人空间 引用 删除 zhaoleixinlang   /   2008-04-03 14:20:55
好文章
 

评分:0

我来说两句

Open Toolbar