白盒测试作为软件质量保证中的重要一环,对产品稳定性起到至关重要的影响,不幸的是,由于实施白盒测试有较高技术难度,该软件过程常被嵌入式厂商忽略,因为难于实施,所以容易失败,失败后产生畏惧心理,就更不愿意进一步去尝试,如此形成恶性循环。更令人担忧的是:产品进度很少有不紧张的,大家习惯于在产品发布前补做测试,甚至把测试留给用户,成天陷于紧张的救火工作。研发进度总会被许多意外打断,在最终交付日要严防死守的前提下,白盒测试自然最先被喀嚓掉了。

  本篇总结实施白盒测试的几个主要误区,我们先从认识上端正对白盒测试的看法。

  误区之一:白盒测试太耗时间,不值得一做

  这是救火式团队对白盒测试的最典型看法。

  评估白盒测试值不值得去做,不只要看白盒测试能发现多少问题,还要看白盒方式下发现问题并解决它的工作效率。另外,在确定的质量标准下,还要分析不做白盒测试,以其它测试方式(如系统测试)代替是否能达到目标,也即:让产品达到能满足市场的稳定程度,只做系统测试需要多少时长,若改成一半时间做白盒测试,另一半做系统测试,看看这两种方式的测试总投入差别有多大?

  依据实际经验,成功的白盒测试与不做白盒测试相比,测试投入应节约1/3以上。当然,这个对比是产品要保证较好发布质量的前提下才成立的,如果不做测试,产品一调通就发布,那没得比了,这样测试投入是最节约的。

  以上观点的详细论述请参考《为何进行白盒测试 从“清洗面包机”讲起》。

  误区之二:系统测试可以发现所有问题,不必做白盒测试

  从理论上讲,系统测试是可以代替白盒测试的,但现实操作中,让系统测试代替白盒测试的代价太高。白盒测试直接面对函数内的各个分支,如果在系统测试阶段设计用例,也让每个分支情况都能覆盖到,恐怕要付出数万乃至数百万倍的测试投入,现实情况是不可能这么操作的。

  白盒测试不可或缺,不仅因为白盒测试的发现与解决问题效率很高,也因为白盒测试独具特点,能发现其它测试手段很难发现的问题,比如逻辑问题、边界条件、变量未初始化、内存越界等问题。

  更详细内容请参考《为什么要做白盒测试》一文。

  误区之三:白盒测试必须在真实环境下进行

  近代量子力学有一个海森堡测不准原理,讲的是某个粒子的位置与动量不能同时被测量出来,由测量存在干扰,对其中一个参数测量越准确,另一个参数就越不准确。测不准原理在我们日常生活中很常见,比如要测试某物质的导电性,我们串联接上一个安培计来观察电流,但是,安培计本身也带电阻,导致测不准,测量值会偏小。

  在软件测试领域也存在类似情况,比如要测试系统的CPU占用,于是添加代码统计CPU占用率,但添加的代码运行时,它本身也会消耗CPU。再如,为了实施白盒测试,必然追加测试代码,比如:构造特定运行环境、替换桩函数使之在特定情况下返回特定值,这些都改变了被测对象自身的特性,追求完全准确的测试非常困难。所以,我们并不是一定要追求在真实环境下做测试,而是要评估非真实环境(或仿真环境)下的测试对最终结果能产生多大偏离。

  本人曾辅导过一个白盒测试项目,该项目是一个中间件系统,支持Windows与RT-Linux跨平台运行,当时本人竭力推荐在VC环境下做测试,但产品经理断然否决了这个提议,原因是他们有重要客户要跑RT-linux,测试就必须在RT-linux下进行。这下可好,也怪他们的调测环境不争气,且不论RT-Linux下缺乏测试手段,单单下载程序到驻留实时linux系统的单板,一次就要5分钟,如此测试完全可以想见最终结果是什么!后来我们统计该产品与RT-Linux平台相关的API总共不到15个,基本上都与任务调试、内存申请分配相关,完全可以改用Windows测嘛,整整两万多行源码,仅仅担心几个API不真实,而最终导致白盒测试做不下去,可悲呀。

  根据我们多年实践经验,嵌入式产品的白盒测试大可不必非得在真实环境下进行,而且,绝大部分情况下,只有移到仿真环境下白盒测试才能做成功。这方面我们有太多经验教训了,众多坚持上单板做单元测试的尝试都失败,而在仿真平台下的白盒测试,成功率接近百分之百。

  我们先看看上单板做测试的几个致命问题:

  1、测试成本高

  上单板做测试,搭建测试环境的成本比较高,调试与测试都很麻烦,上面提到的每次测试都要花5分钟下载程序就是一个例子。

  2、面对初始代码,导致工作效率低下

  因为白盒测试经常要面对初始代码,尤其是单元测试,刚写完的代码很不稳定,就要做单元测试,测试中代码跑飞是常事,更加剧了测试成本飞涨。而且,目前多数在单板运行的实时系统,都不具备像个人PC那样拥有完善的异常捕获与处理的能力,测试支撑手段必然不够稳健,经常要复位重起,严重影响测试效率。

  3、上单板做测试的起点是多任务集成测试

  要上单板能做测试,至少加载任务要起来,下数据配置的任务也起来,另外任务调度模块也要正常启动,这已经是复杂的运行环境了。让这种环境稳定运行就需要一个测试过程,这加大了上单板做测试的难度。而且,许多不依赖多任务调度环境的测试项,容易受单板任务调度影响,增加了调测难度,若改在仿真环境下在单机桌面系统中做测试,孤立的一个代码片断是很容易把单元测试做起来的。

  ......

本文转载自51Testing软件测试网,查看全文:http://www.51testing.com/html/72/n-223672.html