1．引言：
生产软件的企业安排很多人来测试它们的软件产品。测试的目的就是发现bug（缺陷，defect）以便修正它们。正常情况是尽快处理可能的bug，从而减少修正bug的成本。因为，众所周知，bug越早被发现并修正，所消耗的资源越少。
问题是在很多情况下，由于修正已发现的bug，测试过程不得不停顿下来。
那么，以目前正忙于软件产品测试的同样资源来促进组织长期的质量目标不是更好？为了做到这一点，我们应该尽快地提前发现可能的bug。就像克劳士比（Philip Crosby）几年前所说的那样，我们应该努力预防bug，而不仅仅是修正它们。这就是真正的质量。
2．目标：预防bug
预防的重要性
正如我们所知，bug应该尽早地在开发过程中被发现。修正处于开发阶段的产品的bug的成本远远低于修正处于QC（Quality Control，质量控制）阶段的产品的bug，而相对与修正已经发布给客户的产品的bug的成本更是可以忽略不计。原因就是当你修正一个bug的时候，相当于把你之前做的事情重做一次。因此，越晚修正bug，你所重做的事情就越多。如果bug修正是在产品测试之前，那么重做的工作只有代码实现。如果bug修是在测试阶段，那么重做的工作就包括代码实现和测试。另一个导致成本增加的因素是依赖的组件和流程（process），随着项目的进行，产品依赖的组件和流程也会随之增加。
接下来，从另一个层面来讨论这个问题。如果bug发现和修正越早，开发成本越少，那么在 时间就避免bug引入是不是成本消耗得更少？如果bug可以被完全预防，那么在开发过程中就不会出现重复工作的情况。这个被克劳士比极力推荐的观点非常有意义，而且在很多情况下已得到严密的证实。然而，并不是所有的生产软件产品的组织都试着去避免bug。它们花费了大部分的精力在产品发布给客户之前发现和修正其中的bug。在某些情况下，软件企业并不试着去达到这样的目标。在产品发布之后，企业通过迅速修正产品中的bug来处理客户的抱怨。这是因为，这样的企业始终处于“问题解决模式”，它们并不试图发现问题的根本原因，而只是把局部的大火扑灭。
这种模式并不仅仅导致重复工作直接带来成本的增加，而且会带来一个长期效应，而这将影响企业的业务。首先，发布带有bug的产品将给企业的声誉造成影响，并可能造成对潜在客户的影响——他们在是否建立合作关系上拿不定主意。另外，由于企业需要资源来不断解决现有产品中的问题，那么开发新产品的资源势必减少。
对很多人来说，零缺陷的软件产品似乎是不切实际的。我们总是听到软件开发者说：“软件永远有bug”。产品进入QC阶段时含有bug并不奇怪，因为我们“期望”开发人员制造bug。不幸的是，发布一个包含很多bug的产品给客户仍然不令人感到惊讶。甚至连客户本身也不再感到惊讶。
事实上，每个软件企业都可以通过一些简单的方法，在不增加任何额外资源的情况下预防bug。bug预防在于一个简单的道理：最好的方法是适当借鉴我们自己的经验。
今天的发现就是明天的预防
为了能够预防bug，我们必须首先了解bug的来源。软件bug可以分为几个类别（可能相互之间有所重叠）。 类bug可能是随机的，它们通常是因为一时的疏忽造成的。尽管这些bug可能由于其随机性很难预防，但是，适当的分析将有助于避免这些bug。
另一类的bug来自于需求的误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术。这类bug共同的特点是都来自于开发人员。除非被发现，否则这些bug将一直存在。例如，一个还不完全理解需求的开发工程师在单元测试阶段可能无法发现这些问题，只有当产品被其他组织（如QC组）测试时才会发现产品实现与需求不一致。这使得在前期避免类似问题的出现更加重要。
一个好消息是，软件中的bug往往倾向于重复出现，即使是一个随机出现的bug。软件bug的不断出现不仅表现在同一个开发人员的工作上，而且表现在一个项目甚至是企业的层面上。这当然不是说公司中的每一个开发人员都会犯同样的错误。但是，至少其中一些的错误足以成为经常性出现的问题。所以，为什么我们认为重复的错误是一个好消息？因为可以预见的bug更容易预防。事实是我们可以找到一些常见的问题，并采取相应的措施去预防它（或至少减少类似错误出现的次数）。
人为bug的子集？那么这些bug被预防的可能性更大。域bug？域bug和产品的问题域或解决方案域紧密相关。这样的bug有更大的机会重现，因为开发人员、项目组甚至企业不断地在这个域上工作。
现在的问题是如何预防各种bug的产生。基于这次讨论的目的，我建议我们设定一个更加实际的目标。让我不要考虑完全预防某个bug，而是将目标设为——预防我们已经知道有一定可能性产生的Bug。这意味着我们可以通过我们各种发现bug的活动来促进将来的bug预防。当某个bug被发现时，我们就有了一个很好的机会来阻止类似问题的发生。
前提：记录bug
前提条件是持续跟踪发现的bug并正确地记录它们，离开了这个前提条件将不能将bug发现作为一个工具来预防bug。不论你使用bug跟踪系统,还是只手写了一个报告总结测试的结果，重要的是保存这些数据以便用于后来的分析。
在分析bug时，bug记录的问题值得注意。bug的定义越广泛，bug分析的数据越有用。报告bug的测试人员应该明白这一点，并不限于狭义上的bug。可能的话，测试人员应该运用他们的经验对bug产生的原因做最初的假设。我们将稍后在阐述分析过程时讨论这个问题。
和记录bug同样重要的是bug分析的 步。仅仅跟踪过去的bug不能预防bug的发生，因为许多不同的bug可能来源于同一个核心问题。不同于信息收集，适当地分析bug的原因对bug预防非常有用。
3．缺陷分析
目标
在上一节，我们说明了bug分析的理由。如上所述，最终目标是预防bug
而不是修正它们。然而，我们可以定义一个重要的子目标，这就使不断提高整个开发团队（包括QC组）的技能和实践经验。当然，这两个目标是息息相关的。离开了不断的知识累积，也不能实现bug预防。不过，我觉得有必要提及这个子目标以强调持续性的过程。bug预防并不是一个不切实际的目标。但是，你不能期望它在一夜之间发生。你应该为开发小组提供教育和知识，以使他们逐渐改善他们的工作。
策略
本次讨论的焦点——bug预防策略非常简单和容易实现。秘诀就是使用在大多数开发环境中已经存在的过程元素。我们不会介绍任何新的花费昂贵的活动，也不会引入一些新的角色到开发过程中。
我们的策略是发现bug，找出bug的根源，然后寻找一个方法来预防类似的bug在将来出现。因为QC过程已经用于在目前的产品中发现bug，因此该策略的大部分工作实际上已经执行，大多数开发过程缺少的正是分析在QC过程中发现的bug。正如你将看到，尽管策略的这一部分并不需要昂贵的花费，但是却带来了极大的额外价值。
分析过程
(1) Bug发现和初步分析
如前所述，bug分析的 步是发现bug。然而，发现bug的QC工程师（注：测试工程师）不应该满足于记录bug的表面症状。QC工程师的一个重要职责就是试图发现bug的根本原因。QC小组在检验产品质量时，不应该将产品看作一个黑盒，而应该像开发人员那样了解产品的内在，包括深入源代码，理解产品的设计和实现。这些能力都是QC小组开始bug分析的基本要求。熟悉了产品的代码，QC工程师就可能推测出bug的根本原因。
我要强调是下面这个短语的本质：bug的根本原因？bug的根本原因并不是产生这bug的源代码所在，尽管这些信息可能和分析过程关系密切。但是，发现bug的根本原因意味着找到造成这些错误的原因。通过一些实例来说明这个问题可能更清楚一些。
让我们看一个普遍存在的关于线程同步的问题。假设一个多线程的应用程序需要同步地访问某个数据结构。被指派测试这个产品的QC工程师发现在某种情景下，应用程序尽管没有Crash，但是会停止响应。正常的QC过程是，这个bug被记录在bug跟踪系统中，并描述了测试情景和停止响应的实际结果。然而，如果这个QA工程师熟悉源代码，就可以进行bug产生原因的初步分析。例如，这个QC工程师可能断定这个bug产生的原因是之前的线程没有释放mutex，从而造成了冲突。这些分析可以记录在bug的详细说明中，作为bug分析的一个基础。
