基于QC流程Bug预防策略与分析方法研究.pdfVIP

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初步分析的目的，但是它可能为开发人员了的观

点。除了修正以及记录实现的具体步骤，开发人员还应该对bug进行进一步的分析。这

次分析应该着眼于导致bug产生的开景。

程同步的例子中，开发人员不应该仅仅记录增加了一个调用来释放mutex（注：

MutalExclusion=互斥锁，保证了共享数据不会同时被多个线程，只向一个线程授予对

共享资源的独占权）。反之，开发人员应该找出没有释放mutex的。假设分析的原

因是：因为需要同步的方法超过一个的返回点，因此开发人员在某些控制路径上忘记清理代

码。

这一类简单的分析实际带来了非常大的价值。不同于记录具体问题的具体解决办法，我

们现在有了可以解决许多情况的经验，有些情况甚至并不涉及到线程同步和释放mutex。但

是，分析过程并没有结束，我们需要进一步的分析来将收集的所有数据转换为实践，从而帮

助在将来避免类似bug的发生。

(3)bug预防分析

分析的最后一步就是寻找一个预防类似错误的方法。这一方法不仅涉及到开发、QC工

程师，还涉及到不直接负责代码编写的资深开发人员。

这一阶段的成果是一些有用的实践经验，开发人员可以通过这些实践预防bug而不是修

正bug。这些实践不应该是某个具体问题的解决方案。在我们线