适当采用白盒测试

发表于:2011-2-22 11:12  作者:肖利琼   来源:51Testing软件测试网采编

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试技术 白盒测试

  是否采用白盒测试,从软件工程角度出发,由于白盒测试能看到程序的内部逻辑结构,可以在单元测试阶段就开始测试,在修复Bug的成本方面占极大的优势。且对某一类的Bug,如果用黑盒测试方法,需花很多时间或精力去准备测试数据或测试环境,而用白盒测试方法却很容易做到。白盒测试不只限于单元测试,代码走查、代码的静态分析、动态分析都属于白盒测试的范畴。下面是一个采用代码走查发现的对于黑盒测试来说很难测试到位的边界值问题。

  【案例】一个边界值测试的问题

  背景描述:某精密仪器具有测量环境温度的功能,当环境温度在5℃到35℃时它能正常工作,当温度超过30℃后,测量结果的准确性将受影响,仪器要求进入报警测量状态。

  测试分析:此功能黑盒测试工程师在执行测试时,用一杯热水来加热温度传感器,使其温度上升到边界值35℃,但由于精度的处理问题,传感器感应到的温度通过硬件指令发送给软件后存在一定的误差,软件在界面上显示的30℃,可能已超过真实的30℃,或实际上不足30℃。还有像30.1℃、29.9℃,这样的边界数据,用这种方法基本模拟不出来。在这种情况下,必须考虑其他方法,如进行软件插桩或硬件插桩(指令仿真),这两者的工程成本都不小。最后决定采用代码走查的方法审核代码。

  测试结果:结果很快发现在边界值定义范围的边界上,开发人员把闭区间的表示,写成开区间的表示了,代码片段示例如下:

  1. if( ( EnvrTemp > 5 ) && (EnvrTemp < 30 ) )  
  2. {  
  3. //软件正常工作  
  4. }  
  5. Else  
  6.  {  
  7.   //软件进入报警测量状态  
  8. }

  依据需求,第一行代码正确的表达应是if( ( EnvrTemp>=5 ) && (EnvrTemp<=30 ) )。

  小结:对于黑盒测试难于验证,或重要的逻辑判断处理,核心模块的实现可采用白盒测试手段。方法很多,也可结合工具代替人工分析,如pc-lint代码静态分析工具就是一个不错的选择。

  在项目测试中,决策白盒测试要不要开展很容易回答为“要”,因为它有显而易见的好处,上例便是一个很好的例证。但要如何开展,对代码的覆盖率做到多高,不是拍拍脑袋就能拍出来的。众多因素中,人力的投入与产出应该是最重要也最需要考虑的问题,如项目的代码量会有多少,全部进行单元测试需多少人力?单元测试由开发人员进行的话,对进度的影响可以接受吗?如果测试人员来做,代价会不会太大,目前的资源胜任度如何?如果只对核心模块或核心代码进行白盒测试,质量上可以满足项目需求吗?就白盒测试展开的“度”,包括广度与深度,也是策略决策者必须谨慎考虑的事情,有时甚至就是一个事倍功半或是事半功倍的决策。笔者曾见过的一个失败案例,见下面所述。

  【案例】一个代码测试的失败案例

  一个20.4万代码行的软件,安排2个测试工程师进行代码测试,介入时间在开发人员实现代码的中期。2个测试人员共耗时13个月,对重要模块进行了单元测试、集成测试及代码走查。项目结束时,共提交131个缺陷,被开发人员取消的问题有83个,确认真正被开发人员解决的仅有48个。由于人力产出比与预期相差很远,对项目的实质性贡献不明显,最后只好取消这个代码测试组。导致这个结果的原因很多,其中最主要的是测试人员进行代码测试的条件不够成熟,包括代码的注释低(统计才8.4%,业界公认代码注释率达到整个代码行的30%左右是比较理想的)、测试人员介入晚、人员少、自身能力有限等。

  与黑盒测试技术相比,白盒测试要求门槛高,且弄不好就会吃力不讨好。但无可否认,白盒测试技术,是一把“好钢”,只是好钢要用在刀刃上,方能发挥它应有的价值。

相关链接:

黑盒测试不等于手工测试

确定顶层方向性测试类别

不可忽视从设计需求中提取测试需求

快速理解需求的捷径:需求宣讲

测试需求分析与测试策略制定

好钢用在刀刃上:测试技术应用之合适设计

测试设计不只是测试设计工程师的事

软件测试流程改进设计案例分享

认识测试流程

测试管理中的隐形指挥棒:测试组织模式的设计(3)

测试管理中的隐形指挥棒:测试组织模式的设计(2)

测试管理中的隐形指挥棒:测试组织模式的设计(1)

解读测试设计

测试设计景观


【福利】填问卷 送2019精选测试大礼包+接口测试实战课程!

评 论

  • dyc1012 (2013-9-23 13:11:54)

    继续忽悠

  • dyc1012 (2013-9-23 13:10:40)

    在你那个案例说是失败简直就是放屁,纯粹已白盒测试发现的bug来决定是否有价值吗? 应该就像自动化测试,有回归测试的性质和作用,你靠2个工程师就能发现20多万行代码的大部分bug? 没computer science的价值是不争的事实,纯手工,纯业务,纯你妹 其实这就是兴趣问题,个人认为,测试里面的手工测试为一类,性能测试和分析(必须要有分析,没分析只能是tester, 有分析才算engineer)和百合以及部分UI级别的自动化算一类,且这些和纯业务手工完全两码事(特别是性能分析和白盒)。

  • stevenli (2012-2-26 22:20:32)

    thanks!

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2019, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道