【摘要】本文重点针对测试中的周期性特点，阐述BUG层出不穷的几个原因，越来越多的企业领导关注并重视测试，他们往往专注于软件测试中的BUG现状，对层出不穷的BUG产生居多的疑问，本文可以给出部分的参考。

【关键字】周期性，黑盒测试，自顶向下

．引言

由于软件企业对软件质量的重视程度越来越高，软件测试在软件研发中的地位越来越重要。越来越多的企业领导也将注意力更多的投入到软件测试方面来，确实测试很需要得到领导的重视与理解并且毫无疑问的支持，如果你所处的团队目前已经很好的得到了领导的重视和支持，那真是一件幸事。可不幸的是，目前很多国内软件相关人士对软件测职业岗位还出于不理解状态，这其中当然包括领导一层，可能大家在日常工作中有时候会碰到领导过问到测试状况或者BUG的事，特别是那些规模小，流程体系还不够完善，处于人治状态的公司也许几率更高一些，通常来说，领导见到那些层出不穷的BUG，直觉反应是测试工作做的不够理想而导致BUG的遗漏，当然这样的假设不一定成立，到底为什么会有层出不穷的BUG呢？

．层出不穷的BUG

大家可能都有这样一种感觉，软件几乎天天在修改，审核，验证再测试，可相当长一段时间的测试过程中会发现居多这样那样的缺陷，层出不穷的发现BUG，到底是什么原因？

笔者总结以下几种常见原因

．测试遗漏

测试的设计主要体现在测试用例的设计，以及通过测试策略将这些测试用例同测试计划，测试执行，还有测试结果数据的收集整理结合在一起执行，由于测试人员水平的高低，测试工具使用的熟练程度，以及对所测试对象的理解深度等原因，测试设计很难完善，主要表现在测试用例设计的不全面，存在遗漏，或者测试方案的不周密，以及可能的测试人员执行时产生的偏差等等，这些测试方面的遗漏和偏差都可能导致软件问题没有及时发现，造成测试的遗漏。

．设计及修改原因

软件需求或者设计方案经常被更改，特别是变更没有导入一套成熟的变更管理体系的情况下，每次变更无疑于埋下大量的地雷，这些都为BUG提供滋生的环境。另外后期修改维护中对BUG未做准确的分析定位，修改方案未审核，或者修改过程中程序员出现“头痛治头，脚痛治脚”，“补了东边漏了西边”等不良修改过程中引发出新的问题，也是导致BUG被扩大的原因。

．BUG的概率性及偶然性

有些BUG的出现呈现概率的特性，它需要反常数量，频率，或者资源的方式下执行系统才能被查找，即通常所说的压力测试。

．BUG的潜伏性及阶段性

有时候，BUG实际存在但由于触发它的条件不满足从而呈现潜伏状态只能在某个阶段才能被发现，单元测试，集成测试，系统测试等阶段测试重点关注的对象就不同，如集成测试可以发现单元测试通过后的模块之间接口上的错误。特别象嵌入式系统中多进程以及多任务处理问题、系统容错性问题、内存问题等等，这些情况下表现出的潜伏性更加复杂多变，导致发现这些BUG需要一个特别长的周期或者需要某一特定测试环境能被有效搭建的情况下才能查找出。

．BUG的隐蔽性和周期性

该BUG实际存在但由于其他BUG的存在导致它所在的代码没有得到执行，因而无法暴露该BUG，这种情况在以黑盒测试为主的测试中表现尤为突出，只有通过周期性的BUG修复及测试才能发现该类BUG。

．测试的周期性

上文提到BUG的隐蔽性和周期性决定了测试必须是一个周期性的工作，这个周期性不是表现为简单的重复。下面针对黑盒测试的特点来详细阐述这一特性。

黑盒测试的对象大多针对图形用户界面（GUI），它以窗口，菜单以及按键的表现形式，针对它们的测试，通常通过模拟用户的操作来完成，这种特性决定它只能通过自顶往下的测试方法，即只能通过菜单一级一级往下的方式测试，从程序的角度来说必须先有父窗口再到子窗口的过程。当然如果采用白盒测试的方法，可以通过驱动的方式来激发，这里就不阐述！

以手机这类嵌入式系统测试举例，手机软件的测试对象通常是窗口结构、信息流、控制流，以及逻辑控制等都具有很强的层次性，一旦某一窗口出现BUG，通过黑盒测试来引导程序运行的测试很可能就因该BUG的存在而就此中止了运行，从而无法执行剩余的测试用例来遍历其他的路径，这样就无法查找到那些未遍历的代码中可能存在的缺陷。

假设下图所示意的测试模块中红色框圈中的为BUG所处的节点，该模块假设共在3个节点处存在错误。（为了方便大家的理解不防把各“节点“看成一窗口菜单，从而下图就看成一菜单树结构）。

测试周期1：

上图中，如果节点“2“处出现了BUG，程序在此中断，黑盒测试无法遍历从节点”2“到节点”4“，以及节点”2“到节点”3“的边，测试就无法发现在节点”4“及节点”7a“处的的BUG，这就是因为节点”2“处的BUG存在将其它BUG隐蔽起来了，剩余遍历其它路径的测试用例无法再执行，测试在此中断，等待修复节点“2“处的BUG。

测试周期2：

新版本解决完节点“2“处得BUG，测试可以执行从节点”2“到节点”4“的边，从而又暴露出节点”4“处的BUG，同样的道理，测试继续被中断，无法遍历从节点”4“－”6“－”7a“，以及节点”4“－“5－“7a””这两条路径，无法发现节点”7a“处的的BUG，这就是因为节点”4“处的BUG存在将其它剩余的BUG隐蔽起来，等待修复节点“4“处的BUG。

测试周期3：

解决完节点“4”的BUG后，前一版本无法遍历的路径在此可以被执行，从而发现节点“7a”处的BUG，从上所叙的黑盒测试过程，需要通过整整3个周期的测试，才能执行完所有测试用例，达到遍历上图所有路径。

上面只是一个简单的例子，实际的测试情况比这要复杂得多，目的在于阐述BUG的隐蔽性决定了发现它们需要一个周期，从而说明查找BUG不能象大家想象得那样，通过在某一个版本上投入大量的人力物力做尽量多的测试就可以暴露出所有的缺陷，同样的道理，如果希望在某一个版本的测试报告中去评估一个系统的稳定性或者质量状况，也是不科学的，上图是一个很好的例子，一个节点处的错误足可以屏蔽数倍于它的BUG，有的甚至是致命的错误。

．结论

笔者整理此文曾经是因为领导的一个疑问“为什么会有层出不穷的BUG？”，很庆幸遇到一位不耻下问又虚心学习的领导，通过对此文的解读，让他更深的理解了测试的周期性特征，测试很需要得到领导的重视与理解并且毫无疑问的支持，如果大家对测试理解更深入一点，就会对测试这行业更热爱些，领导的注意力和投入也会更多一些，希望此文能给大家一些可以。