查看完整版本: Bug分析：为bug预防奠定基础

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

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

[b]2[/b][b][font=宋体]．目标：预防[/font]bug[/b]
[b][u][color=#ff990][font=宋体]预防的重要性[/font][/color][color=#ff990][/color][/u][/b]
[font=宋体]正如我们所知，[/font]bug[font=宋体]应该尽早地在开发过程中被发现。修正处于开发阶段的产品的[/font]bug[font=宋体]的成本远远低于修正处于[/font]QC[font=宋体]（[/font]Quality Control[font=宋体]，质量控制）阶段的产品的[/font]bug[font=宋体]，而相对与修正已经发布给客户的产品的[/font]bug[font=宋体]的成本更是可以忽略不计。原因就是当你修正一个[/font]bug[font=宋体]的时候，相当于把你之前做的事情重做一次。因此，越晚修正[/font]bug[font=宋体]，你所重做的事情就越多。如果[/font]bug[font=宋体]修正是在产品测试之前，那么重做的工作只有代码实现。如果[/font]bug[font=宋体]修是在测试阶段，那么重做的工作就包括代码实现和测试。另一个导致成本增加的因素是依赖的组件和流程（[/font]process[font=宋体]），随着项目的进行，产品依赖的组件和流程也会随之增加。[/font]
[font=宋体]接下来，从另一个层面来讨论这个问题。如果[/font]bug[font=宋体]发现和修正越早，开发成本越少，[b]那么在第一时间就避免[/b][/font][b]bug[/b][b][font=宋体]引入是不是成本消耗得更少？[/font][/b][font=宋体]如果[/font]bug[font=宋体]可以被完全预防，那么在开发过程中就不会出现重复工作的情况。这个被克劳士比极力推荐的观点非常有意义，而且在很多情况下已得到严密的证实。然而，并不是所有的生产软件产品的组织都试着去避免[/font]bug[font=宋体]。它们花费了大部分的精力在产品发布给客户之前发现和修正其中的[/font]bug[font=宋体]。在某些情况下，软件企业并不试着去达到这样的目标。在产品发布之后，企业通过迅速修正产品中的[/font]bug[font=宋体]来处理客户的抱怨。这是因为，这样的企业始终处于“问题解决模式”，它们并不试图发现问题的根本原因，而只是把局部的大火扑灭。[/font]
[font=宋体]这种模式并不仅仅导致重复工作直接带来成本的增加，而且会带来一个长期效应，而这将影响企业的业务。首先，发布带有[/font]bug[font=宋体]的产品将给企业的声誉造成影响，并可能造成对潜在客户的影响——他们在是否建立合作关系上拿不定主意。另外，由于企业需要资源来不断解决现有产品中的问题，那么开发新产品的资源势必减少。[/font]
[font=宋体]对很多人来说，零缺陷的软件产品似乎是不切实际的。我们总是听到软件开发者说：“软件永远有[/font]bug[font=宋体]”。产品进入[/font]QC[font=宋体]阶段时含有[/font]bug[font=宋体]并不奇怪，因为我们“期望”开发人员制造[/font]bug[font=宋体]。不幸的是，发布一个包含很多[/font]bug[font=宋体]的产品给客户仍然不令人感到惊讶。甚至连客户本身也不再感到惊讶。[/font]
[font=宋体]事实上，每个软件企业都可以通过一些简单的方法，在不增加任何额外资源的情况下预防[/font]bug[font=宋体]。[/font]bug[font=宋体]预防在于一个简单的道理：最好的方法是适当借鉴我们自己的经验。[/font]
[b] [/b]
[b][u][color=#ff990][font=宋体]今天的发现就是明天的预防[/font][/color][/u][/b][b][u][color=#ff990][/color][/u][/b]
[font=宋体]为了能够预防[/font]bug[font=宋体]，我们必须首先了解[/font]bug[font=宋体]的来源。软件[/font]bug[font=宋体]可以分为几个类别（可能相互之间有所重叠）。第一类[/font]bug[font=宋体]可能是随机的，它们通常是因为一时的疏忽造成的。尽管这些[/font]bug[font=宋体]可能由于其随机性很难预防，但是，适当的分析将有助于避免这些[/font]bug[font=宋体]。[/font]
[font=宋体]另一类的[/font]bug[font=宋体]来自于需求的误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术。这类[/font]bug[font=宋体]共同的特点是都来自于开发人员。除非被发现，否则这些[/font]bug[font=宋体]将一直存在。例如，一个还不完全理解需求的开发工程师在单元测试阶段可能无法发现这些问题，只有当产品被其他组织（如[/font]QC[font=宋体]组）测试时才会发现产品实现与需求不一致。这使得在前期避免类似问题的出现更加重要。[/font]
[font=宋体]一个好消息是，软件中的[/font]bug[font=宋体]往往倾向于重复出现，即使是一个随机出现的[/font]bug[font=宋体]。软件[/font]bug[font=宋体]的不断出现不仅表现在同一个开发人员的工作上，而且表现在一个项目甚至是企业的层面上。这当然不是说公司中的每一个开发人员都会犯同样的错误。但是，至少其中一些的错误足以成为经常性出现的问题。所以，为什么我们认为重复的错误是一个好消息？因为可以预见的[/font]bug[font=宋体]更容易预防。事实是我们可以找到一些常见的问题，并采取相应的措施去预防它（或至少减少类似错误出现的次数）。[/font]
[font=宋体]人为[/font]bug[font=宋体]的子集？那么这些[/font]bug[font=宋体]被预防的可能性更大。域[/font]bug[font=宋体]？域[/font]bug[font=宋体]和产品的问题域或解决方案域紧密相关。这样的[/font]bug[font=宋体]有更大的机会重现，因为开发人员、项目组甚至企业不断地在这个域上工作。[/font]
[font=宋体]现在的问题是如何预防各种[/font]bug[font=宋体]的产生。基于这次讨论的目的，我建议我们设定一个更加实际的目标。让我不要考虑完全预防某个[/font]bug[font=宋体]，而是将目标设为——预防我们已经知道有一定可能性产生的[/font]Bug[font=宋体]。这意味着我们可以通过我们各种发现[/font]bug[font=宋体]的活动来促进将来的[/font]bug[font=宋体]预防。当某个[/font]bug[font=宋体]被发现时，我们就有了一个很好的机会来阻止类似问题的发生。[/font]

[b][u][color=#ff990][font=宋体]前提：记录[/font][/color][color=#ff990]bug[/color][/u][/b]
[font=宋体]前提条件是持续跟踪发现的[/font]bug[font=宋体]并正确地记录它们，离开了这个前提条件将不能将[/font]bug[font=宋体]发现作为一个工具来预防[/font]bug[font=宋体]。不论你使用[/font]bug[font=宋体]跟踪系统[/font],[font=宋体]还是只手写了一个报告总结测试的结果，重要的是保存这些数据以便用于后来的分析。[/font]
[font=宋体]在分析[/font]bug[font=宋体]时，[/font]bug[font=宋体]记录的问题值得注意。[/font]bug[font=宋体]的定义越广泛，[/font]bug[font=宋体]分析的数据越有用。报告[/font]bug[font=宋体]的测试人员应该明白这一点，并不限于狭义上的[/font]bug[font=宋体]。可能的话，测试人员应该运用他们的经验对[/font]bug[font=宋体]产生的原因做最初的假设。我们将稍后在阐述分析过程时讨论这个问题。[/font]
[font=宋体]和记录[/font]bug[font=宋体]同样重要的是[/font]bug[font=宋体]分析的第一步。仅仅跟踪过去的[/font]bug[font=宋体]不能预防[/font]bug[font=宋体]的发生，因为许多不同的[/font]bug[font=宋体]可能来源于同一个核心问题。不同于信息收集，适当地分析[/font]bug[font=宋体]的原因对[/font]bug[font=宋体]预防非常有用。[/font]

[b]3[/b][b][font=宋体]．缺陷分析[/font][/b]
[b][u][color=#ff990][font=宋体]目标[/font][/color][color=#ff990][/color][/u][/b]
[font=宋体]在上一节，我们说明了[/font]bug[font=宋体]分析的理由。如上所述，最终目标是预防[/font]bug
[font=宋体]而不是修正它们。然而，我们可以定义一个重要的子目标，这就使不断提高整个开发团队（包括[/font]QC[font=宋体]组）的技能和实践经验。当然，这两个目标是息息相关的。离开了不断的知识累积，也不能实现[/font]bug[font=宋体]预防。不过，我觉得有必要提及这个子目标以强调持续性的过程。[/font]bug[font=宋体]预防并不是一个不切实际的目标。但是，你不能期望它在一夜之间发生。你应该为开发小组提供教育和知识，以使他们逐渐改善他们的工作。[/font]

[b][u][color=#ff990][font=宋体]策略[/font][/color][color=#ff990][/color][/u][/b]
[font=宋体]本次讨论的焦点——[/font]bug[font=宋体]预防策略非常简单和容易实现。秘诀就是使用在大多数开发环境中已经存在的过程元素。我们不会介绍任何新的花费昂贵的活动，也不会引入一些新的角色到开发过程中。[/font]
[font=宋体]我们的策略是发现[/font]bug[font=宋体]，找出[/font]bug[font=宋体]的根源，然后寻找一个方法来预防类似的[/font]bug[font=宋体]在将来出现。因为[/font]QC[font=宋体]过程已经用于在目前的产品中发现[/font]bug[font=宋体]，因此该策略的大部分工作实际上已经执行，大多数开发过程缺少的正是分析在[/font]QC[font=宋体]过程中发现的[/font]bug[font=宋体]。正如你将看到，尽管策略的这一部分并不需要昂贵的花费，但是却带来了极大的额外价值。[/font]
[b] [/b]
[b][u][color=#ff990][font=宋体]分析过程[/font][/color][color=#ff990][/color][/u][/b]
[b](1) Bug[/b][b][font=宋体]发现和初步分析[/font][/b]
[font=宋体]如前所述，[/font]bug[font=宋体]分析的第一步是发现[/font]bug[font=宋体]。然而，发现[/font]bug[font=宋体]的[/font]QC[font=宋体]工程师（注：测试工程师）不应该满足于记录[/font]bug[font=宋体]的表面症状。[/font]QC[font=宋体]工程师的一个重要职责就是试图发现[/font]bug[font=宋体]的根本原因。[/font]QC[font=宋体]小组在检验产品质量时，不应该将产品看作一个黑盒，而应该像开发人员那样了解产品的内在，包括深入源代码，理解产品的设计和实现。这些能力都是[/font]QC[font=宋体]小组开始[/font]bug[font=宋体]分析的基本要求。熟悉了产品的代码，[/font]QC[font=宋体]工程师就可能推测出[/font]bug[font=宋体]的根本原因。[/font]
[font=宋体]我要强调是下面这个短语的本质：[/font]bug[font=宋体]的根本原因？[/font]bug[font=宋体]的根本原因并不是产生这[/font]bug[font=宋体]的源代码所在，尽管这些信息可能和分析过程关系密切。但是，发现[/font]bug[font=宋体]的根本原因意味着找到造成这些错误的原因。通过一些实例来说明这个问题可能更清楚一些。[/font]
[font=宋体]让我们看一个普遍存在的关于线程同步的问题。假设一个多线程的应用程序需要同步地访问某个数据结构。被指派测试这个产品的[/font]QC[font=宋体]工程师发现在某种情景下，应用程序尽管没有[/font]Crash[font=宋体]，但是会停止响应。正常的[/font]QC[font=宋体]过程是，这个[/font]bug[font=宋体]被记录在[/font]bug[font=宋体]跟踪系统中，并描述了测试情景和停止响应的实际结果。然而，如果这个[/font]QA[font=宋体]工程师熟悉源代码，就可以进行[/font]bug[font=宋体]产生原因的初步分析。例如，这个[/font]QC[font=宋体]工程师可能断定这个[/font]bug[font=宋体]产生的原因是之前的线程没有释放[/font]mutex[font=宋体]，从而造成了冲突。这些分析可以记录在[/font]bug[font=宋体]的详细说明中，作为[/font]bug[font=宋体]分析的一个基础。[/font][b][/b]
[b](2) Bug[/b][b][font=宋体]修订和进一步分析[/font][/b]
[font=宋体]一如既往，发现一个[/font]bug[font=宋体]之后，开发人员应该负责处理它。但是，如果[/font]bug[font=宋体]的发现过程包含了[/font]bug[font=宋体]根本原因的初步分析，那么关于如何解决这个[/font]bug[font=宋体]，开发人员可能拥有了更多的信息。虽然这不是[/font]QC[font=宋体]工程师[/font]bug[font=宋体]初步分析的目的，但是它可能为开发人员提供了更多的观点。[/font]
[font=宋体]除了修正缺陷以及记录实现的具体步骤，开发人员还应该对[/font]bug[font=宋体]进行进一步的分析。这次分析应该着眼于导致[/font]bug[font=宋体]产生的开发情景。[/font]
[font=宋体]在线程同步的例子中，开发人员不应该仅仅记录增加了一个调用来释放[/font]mutex[font=宋体]（注：[/font]Mutal Exclusion = [font=宋体]互斥锁，保证了共享数据不会同时被多个线程访问，只向一个线程授予对共享资源的独占访问权）。反之，开发人员应该找出没有释放[/font]mutex[font=宋体]的原因。假设分析的原因是：因为需要同步的方法超过一个的返回点，因此开发人员在某些控制路径上忘记清理代码。[/font]
[font=宋体]这一类简单的分析实际带来了非常大的价值。不同于记录具体问题的具体解决办法，我们现在有了可以解决许多情况的经验，有些情况甚至并不涉及到线程同步和释放[/font]mutex[font=宋体]。但是，分析过程并没有结束，我们需要进一步的分析来将收集的所有数据转换为实践，从而帮助在将来避免类似[/font]bug[font=宋体]的发生。[/font]
[b](3) bug[/b][b][font=宋体]预防分析[/font][/b]
[font=宋体]分析的最后一步就是寻找一个预防类似错误的方法。这一方法不仅涉及到开发、[/font]QC[font=宋体]工程师，还涉及到不直接负责代码编写的资深开发人员。[/font]
[font=宋体]这一阶段的成果是一些有用的实践经验，开发人员可以通过这些实践预防[/font]bug[font=宋体]而不是修正[/font]bug[font=宋体]。这些实践不应该是某个具体问题的解决方案。在我们线程同步的例子中，可能得到这样一个实践：是否有审计范围机制来获取和释放资源？这种实践[/font] [font=宋体]（不一定适合所有编程语言）可以指导开发人员用一个类（[/font]class[font=宋体]）封装资源[/font], [font=宋体]这样构造[/font](constructor)[font=宋体]函数容易分配和而与析构[/font](destructor) [font=宋体]函数释放资源。如果遵守这样的约定[/font], [font=宋体]当程序结束这方法时，不管控制路径是怎样的，资源（上述例子中获得的[/font]mutex[font=宋体]）总能被释放。[/font]
Bug[font=宋体]预防分析是整个[/font]bug[font=宋体]分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。由于分析结果的广泛应用性，分析某个具体问题的投入将很容易被收回。[/font]
[font=宋体]非常重要的是我们前面所举的例子是一个随机性的[/font]bug[font=宋体]。开发人员由于疏忽而忘记了释放资源。在代码实现时，这样的[/font]bug[font=宋体]是随机产生的，但是类似[/font]bug[font=宋体]产生的几率却非常高。所以，尽管这一类[/font]bug[font=宋体]是随机的，但仍然可以被预见并防止发生。[/font]
[b](4) [/b][b][font=宋体]发布经验[/font][/b]
[font=宋体]分析得出的实践经验应该被记录并发布，这样其他的开发人员就可以通过学习这些经验避免类似的错误。一个发布经验最好的办法就是[/font][url=http://www.qualityprogramming.org/Organization/OrganizationalKnowledgebase/OrganizationalKnowledgebase.htm][font=宋体][color=#0000ff]知识库[/color][/font][/url][font=宋体]。这将使得新的知识在组织内流动并被相关的开发人员所学习。[/font]
[font=宋体]如果不将分析结果传达给组织内相关的其他人员，那么分析的目的就没有达到。避免下一个[/font]bug[font=宋体]出现的唯一办法就是让开发人员知道如何避免它，并鼓励他们这么做。[/font]

[b][u][color=#ff990]Bug[/color][/u][/b][b][u][color=#ff990][font=宋体]分析实例[/font][/color][color=#ff990][/color][/u][/b]
[font=宋体]让我们研究另外一个例子，以便更好地理解[/font]bug[font=宋体]分析的益处。在这个事例中，[/font]QC[font=宋体]工程师进行了如下的操作：当输入一个长字符串到应用程序时造成其崩溃[/font](crash)[font=宋体]。这一结论本身就需要一定程度的分析，但这个[/font]QC[font=宋体]工程师并不满足于这样的分析，进一步研究了相关的代码，发现[/font]crash[font=宋体]的原因是输入字符串时的处理有问题。其中一个步骤是将输入的字符缓存在一个固定大小的数组中，而这个数组有时候显得太小了。[/font]
[font=宋体]和线程同步的例子一样，[/font]QC[font=宋体]工程师的初步分析带来了很大的价值，开发可以更容易的发现和修正这个[/font]bug[font=宋体]。此外，记录缺陷的真正原因而不是表象，将帮助其他人避免类似的[/font]bug[font=宋体]。[/font]
[font=宋体]接着，开发人员开始修正这个[/font]bug[font=宋体]。当修正的时候，她不仅记录了解决措施，并说明了导致缺陷产生的原因。在这个例子中，造成[/font]bug[font=宋体]的原因是在操作未经处理的[/font]C/C++[font=宋体]缓冲区时，没有经常检验缓冲区的大小是否不够。然而，这个结论甚至可以被进一步总结为更广泛应用的经验以便帮助开发人员在以后避免类似的缺陷发生。所以，在分析的最后阶段，开发人员在组内更资深的开发人员的帮助下，得到了下面的实践经验：避免使用未经处理的[/font]C/C++[font=宋体]缓冲区，尽量使用安全的[/font]collections[font=宋体]和[/font]strings[font=宋体]，如标准模版数据库中提供的可用[/font]collections[font=宋体]和[/font]strings[font=宋体]。这样就完全可以避免前面发现的这个[/font]bug[font=宋体]。[/font]
[b][u][color=#ff990] [/color][/u][/b]
[b][u][color=#ff990][font=宋体]益处[/font][/color][color=#ff990][/color][/u][/b]
Bug[font=宋体]分析带来了很多的好处。第一个好处就是帮助产生错误的开发人员总结经验，并使他在将来避免类似的错误。有时，只修正一个具体的[/font]bug[font=宋体]而不去分析它产生的原因并不会帮助在日后得到提高。在这种情况下，只有深入分析和资深开发人员的指导才能使开发人员成长和提高能力。[/font]
[font=宋体]更广泛的好处是使得其他开发人员从同事的错误中吸取教训。分析总结的实践经验可以预防[/font]bug[font=宋体]的产生，这样的知识在组织内的成员间共享。某个开发人员产生的[/font]bug[font=宋体]可以帮助组织内的其他人避免类似的[/font]bug[font=宋体]出现。[/font]
[font=宋体]从更一般的角度来看，发布最佳实践（如[/font]bug[font=宋体]分析总结的实践）促进了组织内成员的学习和自我提高。这样看来，[/font]Bug[font=宋体]分析的价值还不仅仅是缺陷的预防。[/font]
[font=宋体]另一个好处是通过从更广的角度上记录[/font]bug[font=宋体]，组织内的其他[/font]QC[font=宋体]工程师将知道如何发现类似的错误。除了分享组织内的测试知识和经验，[/font]bug[font=宋体]分析过程可以促进开发更好的测试技术和工具，从而帮助发现类似的[/font]bug[font=宋体]。所以，就算缺陷没有被完全预防，也能更容易被发现。[/font]
[font=宋体]作为上面所有好处的结果，[/font]QC[font=宋体]在一轮测试中将有更多的时间来测试更复杂的情景并发现更“狡猾的”[/font]bug[font=宋体]。如果类似的[/font]bug[font=宋体]都已经被预防而不容易产生，而且[/font]QC[font=宋体]都有更好的技术来发现类似的[/font]bug[font=宋体]，就有了更充裕的时间来进行更高级的测试。当然，组织所生产的产品的质量也将得到提高。[/font]
[font=宋体]最后，我想强调的是[/font]bug[font=宋体]分析不仅收集了执行中的问题，而且从这些问题中总结了实践经验。举例来说，导致一个[/font]bug[font=宋体]产生的原因可能是需求不够清楚。这样，通过[/font]bug[font=宋体]分析得到的经验提供了一种方法来预防需求不清楚。这个经验可能不会对组织中的开发人员产生效果。所以尽管[/font]QC[font=宋体]工程师开始验证开发人员的实现结果，但是还需要改善开发流程，如需求收集、设计流程等。[/font]

[b]4[/b][b][font=宋体]．总结[/font][/b]
[font=宋体]真正的质量是生产没有[/font]bug[font=宋体]的产品。任何其他目标都使组织内的成员从思想上接受软件缺陷是正常工作流的一部分。所以，第一步就是防止相同的[/font]bug[font=宋体]再次发生。我们可以很轻易地执行这个目标。我们可以通过某个开发人员产生的一个[/font]bug[font=宋体]提高整个组织的实践经验。[/font]
[font=宋体]通过深入产品分析一个[/font]bug[font=宋体]，我们可以明白这个[/font]bug[font=宋体]的机制：为什么会产生？如何去预防它？下一次我们如何更容易地发现它？只要花一点时间去理解我们的[/font]bug[font=宋体]，而不是仅仅是尽快修正它，我们就可以从中得到经验。这样，因为一个缺陷所浪费的时间也可以转化为投入：确保类似的错误永远不会再发生。[/font]

不错，很有价值！::em71::

看了就要顶~~~~~~~~

缺陷预防好难好难。。。。属于5级的课题，我已经被搞的头破血流

真是越看越有味道啊！

真是一篇好文章，谢谢。。。。。。

写的好，太崇拜楼主了！！！

　　　　　　写得好！支持一下

很难落到实处去做呀...不过还是顶楼主,谢谢

理论上很美，很难落到实话啊。
这种理论更适合用在单元测试，对一些程序员的错误习惯以及编码错误规范的改正可以起到好的推动。

[[i] 本帖最后由 kangfu9901 于 2008-2-25 10:27 编辑 [/i]]