浅谈软件测试中的Bug

浅谈软件测试中的Bug          软件测试

引言

现在软件开发公司越来越重视产品质量，很多软件公司纷纷成立了自已的测试团队，测试在软件开发的周期中显得越来越重要。软件测试是为发现错误而运行一个程序或者系统的过程。软件测试的主要目的是发现软件中的错误或缺陷。这里软件中的一个错误或缺陷就是一个Bug。软件测试的过程就是不断的寻找Bug，然后排除Bug。微软的研发管理中，它的Bug管理系统是居于核心地位的。测试人员只要发现问题就立即新建一个Bug予以跟踪并指派给相关的开发小组长，开发人员会根据Bug的详细信息找到问题所在，修改程序解这个Bug并把Bug返回给当初的测试人员。阅读每个Bug，你可以详细的看到大家解决这个问题的完整思路。一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的15%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。

一、软件Bug涵义

Bug一词的原意是“臭虫”或“虫子”。但是现在，在电脑系统或程序中，如果隐藏着的一些未被发现的缺陷或问题，人们也叫它“Bug”，这是怎么回事呢？

 

   原来，第一代的计算机是由许多庞大且昂贵的真空管组成，并利用大量的电力来使真空管发光。可能正是由于计算机运行产生的光和热，引得一只小虫子?Bug 钻进了一支真空管内，导致整个计算机无法工作。研究人员费了半天时间，总算发现原因所在，把这只小虫子从真空管中取出后，计算机又恢复正常。后来，Bug这个名词就沿用下来，表示电脑系统或程序中隐藏的错误、缺陷、漏洞或问题。

 

   与Bug相对应，人们将发现Bug并加以纠正的过程叫做“Debug”，意即“捉虫子”或“杀虫子”。遗憾的是，在中文里面，至今仍没有与“Bug”准确对应的词汇，于是只能直接引用“Bug”一词。虽然也有人使用“臭虫”一词替代“Bug”，但容易产生歧义，所以推广不开。

 

   后来就直接用bug 在现在很多的软件测试中 都用Bug来说明那些问题。

 

二、Bug产生的原因

 

测试遗漏

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

    ．设计及修改原因

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

    ．BUG的概率性及偶然性

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

    ．BUG的潜伏性及阶段性

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

    ．BUG的隐蔽性和周期性

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

三、软件测试中对待BUG的态度

在软件测试过程中，我们需要根据各种度量数据从不同角度来对被测软件的质量进行分析评估，找出软件的质量薄弱点、评价软件发布的风险、预估软件测试结束的时间等等，这些分析评估涉及到各种角度、不同指标，也有一些从工程中总结的分析模型。量化评估，最重要的一点是经验，同时需要大量统计工作作为铺垫。

下面我主要从bug统计来说一下我的经验。

1。hoih项目数和摘出bug数预测

一般来说我们可以根据软件代码行数来粗略估计一个产品可能包含的bug数目和需要的测试项目。现在有些公司流行每千行bug数的标准来制定测试计划，这个标准是通过以往测试经验总结出来的，一般来说，同类的产品，尤其是同一个开发流程的产品，这些数值不应该相差太多，如果相差一个数量级以上，我们几乎可以说，要么是QA出问题了，要么是开发出问题了。

2。测试bug分级

使用bugzilla或者Jira之类的缺陷管理系统何以很容易的实现bug分级，一般至少有Fatal, Major, Minor, cosmatic这几种，还有一种特殊的叫做blocker，意思是这个bug会影响测试进度。产品发布前，可以根据实际情况，定一个界限级别，比如要求新出Major为0，并且所有已有的Major全部close。

3。测试bug收敛

量化评估必不可少的是bug收敛，这个要通过统计每日新出bug并跟踪已有bug制作收敛曲线来实现。收敛曲线的形状发散表明目前产品极其不稳定，收敛曲线开始收敛表示目前产品趋于稳定，完全收敛之后可以认为是发布的时机。

4。测试bug分布

bug分布是决定下面测试重点的一个重要的参考数据。首先还是需要统计，找出所有已有的不同级别的bug在各个模块的分布，假如ABC三个模块，A模块占了bug的60%，C模块占了bug的8%那么，我们可以得出这样的结论，软件的不稳定瓶颈在于A模块，是一个薄弱点，需要开发人员集中力量对应。但是C模块也是一个可疑模块，因为出现bug率太低，如果不是开发的太好就是测试方法不当。

5。测试bug的周期

一个bug的生命历程是一个完整的轮回，从他出生(open)开始，到调查(Aclearcase/" target="_blank" >ccept)到修复(Fix)，再到确认(Verify)是最简单的路线，这个周期越短，说明项目进展越顺利反之则意味着项目进度目前有很大的阻碍。

6。降级bug数

降级bug的多少对于软件质量评估也是一个重要参考标准，降级bug也就是由于修正一个bug又作了一个新bug，降级bug数目过多意味着现在的产品在越修越坏。

一个新的QA团队，在2，3，4，5，6步骤可能会有所迷惑，不知道阈值应该怎样选但如果每次都坚持这样做，很多次之后2，3，4，5，6会给这个团队大量的经验积累，完全可以做到看着统计图估计出一个产品处于什么状态，需要加强哪些方面等等。

 

 

  

原文转自：http://www.ltesting.net