是否采用白盒测试,从软件工程角度出发,由于白盒测试能看到程序的内部逻辑结构,可以在单元测试阶段就开始测试,在修复Bug的成本方面占极大的优势。且对某一类的Bug,如果用黑盒测试方法,需花很多时间或精力去准备测试数据或测试环境,而用白盒测试方法却很容易做到。白盒测试不只限于单元测试,代码走查、代码的静态分析、动态分析都属于白盒测试的范畴。下面是一个采用代码走查发现的对于黑盒测试来说很难测试到位的边界值问题。
【案例】一个边界值测试的问题
背景描述:某精密仪器具有测量环境温度的功能,当环境温度在5℃到35℃时它能正常工作,当温度超过30℃后,测量结果的准确性将受影响,仪器要求进入报警测量状态。
测试分析:此功能黑盒测试工程师在执行测试时,用一杯热水来加热温度传感器,使其温度上升到边界值35℃,但由于精度的处理问题,传感器感应到的温度通过硬件指令发送给软件后存在一定的误差,软件在界面上显示的30℃,可能已超过真实的30℃,或实际上不足30℃。还有像30.1℃、29.9℃,这样的边界数据,用这种方法基本模拟不出来。在这种情况下,必须考虑其他方法,如进行软件插桩或硬件插桩(指令仿真),这两者的工程成本都不小。最后决定采用代码走查的方法审核代码。
测试结果:结果很快发现在边界值定义范围的边界上,开发人员把闭区间的表示,写成开区间的表示了,代码片段示例如下:
|
依据需求,第一行代码正确的表达应是if( ( EnvrTemp>=5 ) && (EnvrTemp<=30 ) )。
小结:对于黑盒测试难于验证,或重要的逻辑判断处理,核心模块的实现可采用白盒测试手段。方法很多,也可结合工具代替人工分析,如pc-lint代码静态分析工具就是一个不错的选择。
在项目测试中,决策白盒测试要不要开展很容易回答为“要”,因为它有显而易见的好处,上例便是一个很好的例证。但要如何开展,对代码的覆盖率做到多高,不是拍拍脑袋就能拍出来的。众多因素中,人力的投入与产出应该是最重要也最需要考虑的问题,如项目的代码量会有多少,全部进行单元测试需多少人力?单元测试由开发人员进行的话,对进度的影响可以接受吗?如果测试人员来做,代价会不会太大,目前的资源胜任度如何?如果只对核心模块或核心代码进行白盒测试,质量上可以满足项目需求吗?就白盒测试展开的“度”,包括广度与深度,也是策略决策者必须谨慎考虑的事情,有时甚至就是一个事倍功半或是事半功倍的决策。笔者曾见过的一个失败案例,见下面所述。
【案例】一个代码测试的失败案例
一个20.4万代码行的软件,安排2个测试工程师进行代码测试,介入时间在开发人员实现代码的中期。2个测试人员共耗时13个月,对重要模块进行了单元测试、集成测试及代码走查。项目结束时,共提交131个缺陷,被开发人员取消的问题有83个,确认真正被开发人员解决的仅有48个。由于人力产出比与预期相差很远,对项目的实质性贡献不明显,最后只好取消这个代码测试组。导致这个结果的原因很多,其中最主要的是测试人员进行代码测试的条件不够成熟,包括代码的注释低(统计才8.4%,业界公认代码注释率达到整个代码行的30%左右是比较理想的)、测试人员介入晚、人员少、自身能力有限等。
与黑盒测试技术相比,白盒测试要求门槛高,且弄不好就会吃力不讨好。但无可否认,白盒测试技术,是一把“好钢”,只是好钢要用在刀刃上,方能发挥它应有的价值。
相关链接: