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

　　人为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分析的一个基础。

　　(2) Bug修订和进一步分析

　　一如既往，发现一个bug之后，开发人员应该负责处理它。但是，如果bug的发现过程包含了bug根本原因的初步分析，那么关于如何解决这个bug，开发人员可能拥有了更多的信息。虽然这不是QC工程师bug初步分析的目的，但是它可能为开发人员提供了更多的观点。

原文转自：http://www.uml.org.cn/Test/200611295.htm