由于软件企业对软件质量的重视程度越来越高,软件测试在软件研发中的地位越来越重要。越来越多的企业领导也将注意力更多的投入到软件测试方面来,确实测试很需要得到领导的重视与理解并且毫无疑问的支持,如果你所处的团队目前已经很好的得到了领导的重视和支持,那真是一件幸事。可不幸的是,目前很多国内软件相关人士对软件测职业岗位还出于不理解状态,这其中当然包括领导一层,可能大家在日常工作中有时候会碰到领导过问到测试状况或者BUG的事,特别是那些规模小,流程体系还不够完善,处于人治状态的公司也许几率更高一些,通常来说,领导见到那些层出不穷的BUG,直觉反应是测试工作做的不够理想而导致BUG的遗漏,当然这样的假设不一定成立,到底为什么会有层出不穷的BUG呢?
层出不穷的 BUG
大家可能都有这样一种感觉,软件几乎天天在修改,审核,验证再测试,可相当长一段时间的测试过程中会发现居多这样那样的缺陷,层出不穷的发现BUG,到底是什么原因?
笔者总结以下几种常见原因
.测试遗漏
测试的设计主要体现在测试用例的设计,以及通过测试策略将这些测试用例同测试计划,测试执行,还有测试结果数据的收集整理结合在一起执行,由于测试人员水平的高低,测试工具使用的熟练程度,以及对所测试对象的理解深度等原因,测试设计很难完善,主要表现在测试用例设计的不全面,存在遗漏,或者测试方案的不周密,以及可能的测试人员执行时产生的偏差等等,这些测试方面的遗漏和偏差都可能导致软件问题没有及时发现,造成测试的遗漏。
.设计及修改原因
软件需求或者设计方案经常被更改,特别是变更没有导入一套成熟的变更管理体系的情况下,每次变更无疑于埋下大量的地雷,这些都为BUG提供滋生的环境。另外后期修改维护中对BUG未做准确的分析定位,修改方案未审核,或者修改过程中程序员出现“头痛治头,脚痛治脚”,“补了东边漏了西边”等不良修改过程中引发出新的问题,也是导致BUG被扩大的原因。
.BUG的概率性及偶然性
有些BUG的出现呈现概率的特性,它需要反常数量,频率,或者资源的方式下执行系统才能被查找,即通常所说的压力测试。
.BUG的潜伏性及阶段性
有时候,BUG实际存在但由于触发它的条件不满足从而呈现潜伏状态只能在某个阶段才能被发现,单元测试,集成测试,系统测试等阶段测试重点关注的对象就不同,如集成测试可以发现单元测试通过后的模块之间接口上的错误。特别象嵌入式系统中多进程以及多任务处理问题、系统容错性问题、内存问题等等,这些情况下表现出的潜伏性更加复杂多变,导致发现这些BUG需要一个特别长的周期或者需要某一特定测试环境能被有效搭建的情况下才能查找出。
.BUG的隐蔽性和周期性
该BUG实际存在但由于其他BUG的存在导致它所在的代码没有得到执行,因而无法暴露该BUG,这种情况在以黑盒测试为主的测试中表现尤为突出,只有通过周期性的BUG修复及测试才能发现该类BUG。 [Page]
测试的周期性
上文提到BUG的隐蔽性和周期性决定了测试必须是一个周期性的工作,这个周期性不是表现为简单的重复。下面针对黑盒测试的特点来详细阐述这一特性。
黑盒测试的对象大多针对图形用户界面(GUI),它以窗口,菜单以及按键的表现形式,针对它们的测试,通常通过模拟用户的操作来完成,这种特性决定它只能通过自顶往下的测试方法,即只能通过菜单一级一级往下的方式测试,从程序的角度来说必须先有父窗口再到子窗口的过程。当然如果采用白盒测试的方法,可以通过驱动的方式来激发,这里就不阐述!