Bug分析为bug预防奠定基础五

1、Bug分析为bug预防奠定基础五 Bug分析：为bug预防奠定基础Bug分析：为bug预防奠定基础1引言：生产软件的企业安排很多人来测试它们的软件产品。测试的目的就是发现bug（缺陷defect）以便修正它们。正常情况是尽快处理可能的bug从而减少修正bug的成本。因为众所周知bug越早被发现并修正所消耗的资源越少。问题是在很多情况下由于修正已发现的bug测试过程不得不停顿下来。那么以目前正忙于软件产品测试的同样资源来促进组织长期的质量目标不是更好？为了做到这一点我们应该尽快地提前发现可能的bug。就像克劳士比（hili Crosby）几年前所说的那样我们应该努力预防bug而不仅仅是修正它们。

2、这就是真正的质量。2目标：预防bug预防的重要性正如我们所知bug应该尽早地在开发过程中被发现。修正处于开发阶段的产品的bug的成本远远低于修正处于QC（Quality Control质量控制）阶段的产品的bug而相对与修正已经发布给客户的产品的bug的成本更是可以忽略不计。原因就是当你修正一个bug的时候相当于把你之前做的事情重做一次。因此越晚修正bug你所重做的事情就越多。如果bug修正是在产品测试之前那么重做的工作只有代码实现。如果bug修是在测试阶段那么重做的工作就包括代码实现和测试。另一个导致成本增加的因素是依赖的组件和流程（rocess）随着项目的进行产品依赖的组件和流程也会随之增

3、加。接下来从另一个层面来讨论这个问题。如果bug发现和修正越早开发成本越少那么在第一时间就避免bug引入是不是成本消耗得更少？如果bug可以被完全预防那么在开发过程中就不会出现重复工作的情况。这个被克劳士比极力推荐的观点非常有意义而且在很多情况下已得到严密的证实。然而并不是所有的生产软件产品的组织都试着去避免bug。它们花费了大部分的精力在产品发布给客户之前发现和修正其中的bug。在某些情况下软件企业并不试着去达到这样的目标。在产品发布之后企业通过迅速修正产品中的bug来处理客户的抱怨。这是因为这样的企业始终处于“问题解决模式”它们并不试图发现问题的根本原因而只是把局部的大火扑灭。这种模式并不

4、仅仅导致重复工作直接带来成本的增加而且会带来一个长期效应而这将影响企业的业务。首先发布带有bug的产品将给企业的声誉造成影响并可能造成对潜在客户的影响他们在是否建立合作关系上拿不定主意。另外由于企业需要资源来不断解决现有产品中的问题那么开发新产品的资源势必减少。对很多人来说零缺陷的 软件产品似乎是不切实际的。我们总是听到软件开发者说：“软件永远有bug”。产品进入QC阶段时含有bug并不奇怪因为我们“期望”开发人员制造bug。不幸的是发布一个包含很多bug的产品给客户仍然不令人感到惊讶。甚至连客户本身也不再感到惊讶。事实上每个软件企业都可以通过一些简单的方法在不增加任何额外资源的情况下预防bu

5、g。bug预防在于一个简单的道理：最好的方法是适当借鉴我们自己的经验。今天的发现就是明天的预防为了能够预防bug我们必须首先了解bug的。软件bug可以分为几个类别（可能相互之间有所重叠）。第一类bug可能是随机的它们通常是因为一时的疏忽造成的。尽管这些bug可能由于其随机性很难预防但是适当的分析将有助于避免这些bug。另一类的bug来自于需求的误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术。这类bug共同的特点是都来自于开发人员。除非被发现否则这些bug将一直存在。例如一个还不完全理解需求的开发工程师在单测试阶段可能无法发现这些问题只有当产品被其他组织（如QC组）测试时才会发现产品实

6、现与需求不一致。这使得在前期避免类似问题的出现更加重要。一个好消息是软件中的bug往往倾向于重复出现即使是一个随机出现的bug。软件bug的不断出现不仅表现在同一个开发人员的工作上而且表现在一个项目甚至是企业的层面上。这当然不是说公司中的每一个开发人员都会犯同样的错误。但是至少其中一些的错误足以成为经常性出现的问题。所以为什么我们认为重复的错误是一个好消息？因为可以预见的bug更容易预防。事实是我们可以找到一些常见的问题并采取相应的措施去预防它（或至少减少类似错误出现的次数）。人为bug的子集？那么这些bug被预防的可能性更大。域bug？域bug和产品的问题域或解决方案域紧密相关。这样的bug

7、有更大的机会重现因为开发人员、项目组甚至企业不断地在这个域上工作。现在的问题是如何预防各种bug的产生。基于这次讨论的目的我建议我们设定一个更加实际的目标。让我不要考虑完全预防某个bug而是将目标设为预防我们已经知道有一定可能性产生的Bug。这意味着我们可以通过我们各种发现bug的活动来促进将来的bug预防。当某个bug被发现时我们就有了一个很好的机会来阻止类似问题的发生。前提：记录bug前提条件是持续跟踪发现的bug并正确地记录它们离开了这个前提条件将不能将bug发现作为一个工具来预防bug。不论你使用bug跟踪系统,还是只手写了一个报告总结测试的结果 重要的是保存这些数据以便用于后来的分析

8、。在分析bug时bug记录的问题值得注意。bug的定义越广泛bug分析的数据越有用。报告bug的测试人员应该明白这一点并不限于狭义上的bug。可能的话测试人员应该运用他们的经验对bug产生的原因做最初的假设。我们将稍后在阐述分析过程时讨论这个问题。和记录bug同样重要的是bug分析的第一步。仅仅跟踪过去的bug不能预防bug的发生因为许多不同的bug可能于同一个核心问题。不同于信息收集适当地分析bug的原因对bug预防非常有用。3缺陷分析目标在上一节我们说明了bug分析的理由。如上所述最终目标是预防bug而不是修正它们。然而我们可以定义一个重要的子目标这就使不断提高整个开发团队（包括QC组）的

9、技能和实践经验。当然这两个目标是息息相关的。离开了不断的知识累积也不能实现bug预防。不过我觉得有必要提及这个子目标以强调持续性的过程。bug预防并不是一个不切实际的目标。但是你不能期望它在一夜之间发生。你应该为开发小组提教育和知识以使他们逐渐改善他们的工作。策略本次讨论的焦点bug预防策略非常简单和容易实现。秘诀就是使用在大多数开发环境中已经存在的过程素。我们不会介绍任何新的花费昂贵的活动也不会引入一些新的角色到开发过程中。我们的策略是发现bug找出bug的根源然后寻找一个方法来预防类似的bug在将来出现。因为QC过程已经用于在目前的产品中发现bug因此该策略的大部分工作实际上已经执行大多数

10、开发过程缺少的正是分析在QC过程中发现的bug。正如你将看到尽管策略的这一部分并不需要昂贵的花费但是却带来了极大的额外价值。分析过程(1) Bug发现和初步分析如前所述bug分析的第一步是发现bug。然而发现bug的QC工程师（注：测试工程师）不应该满足于记录bug的表面症状。QC工程师的一个重要职责就是试图发现bug的根本原因。QC小组在检验产品质量时不应该将产品看作一个黑盒而应该像开发人员那样了解产品的内在包括深入源代码理解产品的设计和实现。这些能力都是QC小组开始bug分析的基本要求。熟悉了产品的代码QC工程师就可能推测出bug的根本原因。我要强调是下面这个短语的本质：bug的根本原因？

11、bug的根本原因并不是产生这bug的源代码所在尽管这些信息可能和分析过程关系密切。但是发现bug的根本原因意味着找到造成这些错误的原因。通过一些实例来说明这个问题可能更清楚一些。让我们看一个普遍存在的关于线程同步的问题。假设一个多线程的 应用程序需要同步地访问某个数据结构。被指派测试这个产品的QC工程师发现在某种情景下应用程序尽管没有Crash但是会停止响应。正常的QC过程是这个bug被记录在bug跟踪系统中并描述了测试情景和停止响应的实际结果。然而如果这个QA工程师熟悉源代码就可以进行bug产生原因的初步分析。例如这个QC工程师可能断定这个bug产生的原因是之前的线程没有释放mutex从而造

12、成了冲突。这些分析可以记录在bug的详细说明中作为bug分析的一个基础。(2) Bug修订和进一步分析一如既往发现一个bug之后开发人员应该负责处理它。但是如果bug的发现过程包含了bug根本原因的初步分析那么关于如何解决这个bug开发人员可能拥有了更多的信息。虽然这不是QC工程师bug初步分析的目的但是它可能为开发人员提了更多的观点。除了修正缺陷以及记录实现的具体步骤开发人员还应该对bug进行进一步的分析。这次分析应该着眼于导致bug产生的开发情景。在线程同步的例子中开发人员不应该仅仅记录增加了一个调用来释放mutex（注：Mutal Exclusion = 互斥锁保证了共享数据不会同时被多

13、个线程访问只向一个线程授予对共享资源的独占访问权）。反之开发人员应该找出没有释放mutex的原因。假设分析的原因是：因为需要同步的方法超过一个的返回点因此开发人员在某些控制径上忘记清理代码。这一类简单的分析实际带来了非常大的价值。不同于记录具体问题的具体解决办法我们现在有了可以解决许多情况的经验有些情况甚至并不涉及到线程同步和释放mutex。但是分析过程并没有结束我们需要进一步的分析来将收集的所有数据转换为实践从而帮助在将来避免类似bug的发生。(3) bug预防分析分析的最后一步就是寻找一个预防类似错误的方法。这一方法不仅涉及到开发、QC工程师还涉及到不直接负责代码编写的资深开发人员。这一阶

14、段的成果是一些有用的实践经验开发人员可以通过这些实践预防bug而不是修正bug。这些实践不应该是某个具体问题的解决方案。在我们线程同步的例子中可能得到这样一个实践：是否有审计范围机制来获取和释放资源？这种实践 （不一定适合所有编程语言）可以指导开发人员用一个类（class）封装资源, 这样构造(constructor)函数容易分配和而与析构(destructor) 函数释放资源。如果遵守这样的约定, 当程序结束这方法时不管控制径是怎样的资源（上述例子中获得的mutex）总能被释放。Bug预防分析是整个bug分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在 的缺陷。由于分析结果的

15、广泛应用性分析某个具体问题的投入将很容易被收回。非常重要的是我们前面所举的例子是一个随机性的bug。开发人员由于疏忽而忘记了释放资源。在代码实现时这样的bug是随机产生的但是类似bug产生的几率却非常高。所以尽管这一类bug是随机的但仍然可以被预见并防止发生。(4) 发布经验分析得出的实践经验应该被记录并发布这样其他的开发人员就可以通过学习这些经验避免类似的错误。一个发布经验最好的办法就是知识库。这将使得新的知识在组织内流动并被相关的开发人员所学习。如果不将分析结果传达给组织内相关的其他人员那么分析的目的就没有达到。避免下一个bug出现的唯一办法就是让开发人员知道如何避免它并鼓励他们这么做。B

16、ug分析实例让我们研究另外一个例子以便更好地理解bug分析的益处。在这个事例中QC工程师进行了如下的操作：当输入一个长字符串到应用程序时造成其崩溃(crash)。这一结论本身就需要一定程度的分析但这个QC工程师并不满足于这样的分析进一步研究了相关的代码发现crash的原因是输入字符串时的处理有问题。其中一个步骤是将输入的字符缓存在一个固定大小的数组中而这个数组有时候显得太小了。和线程同步的例子一样QC工程师的初步分析带来了很大的价值开发可以更容易的发现和修正这个bug。此外记录缺陷的真正原因而不是表象将帮助其他人避免类似的bug。接着开发人员开始修正这个bug。当修正的时候她不仅记录了解决措施

17、并说明了导致缺陷产生的原因。在这个例子中造成bug的原因是在操作未经处理的C/C+缓冲区时没有经常检验缓冲区的大小是否不够。然而这个结论甚至可以被进一步总结为更广泛应用的经验以便帮助开发人员在以后避免类似的缺陷发生。所以在分析的最后阶段开发人员在组内更资深的开发人员的帮助下得到了下面的实践经验：避免使用未经处理的C/C+缓冲区尽量使用安全的collections和strings如标准模版数据库中提的可用collections和strings。这样就完全可以避免前面发现的这个bug。益处Bug分析带来了很多的好处。第一个好处就是帮助产生错误的开发人员总结经验并使他在将来避免类似的错误。有时只修正

18、一个具体的bug而不去分析它产生的原因并不会帮助在日后得到提高。在这种情况下只有深入分析和资深开发人员的指导才能使开发人员成长和提高能力。更广泛的好处是使得其他开发人员从同事的错误中吸取教训。分析总结的实践经验可以预防bug的产生这样的知识 在组织内的成员间共享。某个开发人员产生的bug可以帮助组织内的其他人避免类似的bug出现。从更一般的角度来看发布最佳实践（如bug分析总结的实践）促进了组织内成员的学习和自我提高。这样看来Bug分析的价值还不仅仅是缺陷的预防。另一个好处是通过从更广的角度上记录bug组织内的其他QC工程师将知道如何发现类似的错误。除了组织内的测试知识和经验bug分析过程可以促进开发更好的测试技术和工具从而帮助发现类似的bug。所以就算缺陷没有被完全预防也能更容易被发现。作为上面所有好处的结果QC在一轮测试中将有更多的时间来测试更复杂的情景并发现更“狡猾的”bug。如果类似的bug都已经被预防而不容易产生而且QC都有更好的技术来发现类似的bug就有了更充裕的时间来进行更高级的测试。当然组织所生产的产品的质量也将得到提高。最后我想强调的是bug分析不仅收集了执行中的问题而且从这些问题中总结了实践经验。举例来说导致一个bug产生的原因可能是需求不够清楚。这样通过bug分析得到的经验提了一种方法来预防需求不清楚。这个经验可能不会对组织中的开发人员产生效果。所以