三、关于Bug

Bug 的定义很广泛，在软件使用过程中所出现的任何一个可疑问题，或者导致软件不能符合设计要求或满足消费者需要的问题都是Bug，即使这个Bug 在实践中是可行的。有时候，Bug 并不是程序错误。例如，软件没有按照一般用户的使用习惯来运行，此时也可以把这个问题看成是该软件的一个Bug。通常，对Bug 的跟踪过程如图所示。

    首先，测试人员根据测试结果来报告他发现的所有Bug 。通常，这项工作还需要用户的参与。微软在正式发布一个软件之前，经常要依次发布Alpha 测试版、Beta 测试版让用户试用，以便用户能够反馈出相关Bug 的信息。但是，现在随着微软测试队伍的扩大及测试水平的提高，越来越多的 Bug 都是我们内部的测试人员自己发现的，很少出现外部用户所反馈的Bug 没有被测试人员发现的情况。 

    然后，开发经理根据这些Bug 的危害性对它们进行排序，确定Bug 的优先级，并安排给相关的开发工程师。
接着，开发人员根据Bug 的轻重缓急依次修复各个Bug 。最后，测试人员再对开发人员已经修复的Bug 进行验证，确认Bug 是否已经被彻底更正。 

    微软开发一个产品经常会遇到几十万条Bug 。随着测试人员越来越多，测试工作也越来越完善。但是，如何快速有效地追踪并修复Bug，仍然是摆在软件测试人员面前的一个主要困难。测试产品和追踪Bug 时最重要的是问题的定义，要清楚需要解决什么样的问题，确定Bug 的主次关系，挑选出最主要的问题，并先解决它们。例如，有些Bug 可能会导致死机或程序崩溃，这时就要先修复它们，而另一些Bug 可能对软件的运行影响不大，或者出现的机会很少，就可以考虑以后再修复。 

    可以说，没有任何一个产品没有Bug，也永远不可能找出并修复所有的Bug。在修复了旧的Bug 的同时，往往又会生新的Bug。 

    根据微软的经验，每修复三到四个Bug 一般就会产生一个新的Bug。 

    这个过程就类似于数学中的“极限”的定义，尽管我们知道某个极限值为0，但是它永远也不可能达到0。这也就产品的Bug 永远也修复不完的原因。因此，我们在修复 Bug 时要注意，一定要记住用户最需要的是什么，然后优先尽力修复那些影响用户使用的Bug; 而对于大部分对用户影很少、甚至根本不影响的Bug，则可以推迟修复，甚至不修复。 

    在查找并修复Bug 的过程中，测试人员和开发人员经常会发生争执。例如，当开发人员宣布某一个Bug 已经被Fixed 时，测试人员往往还不放心，又重新对该Bug 进行检查;当开发人员宣布某一个Bug 是Duplicated 时，细心的测试人员也要验证该Bug 是否和另外一个Bug 相重复，如果另外一个 Bug 己经被修复了，但这个Bug 还存在，就会让开发人员重新修复该Bug;对于是否需要Postponed 一个Bug，测试人员和开发人员也常常争论不休，测试人员认为这个Bug 需要修复，而开发人员则认为修复这个Bug 不值得，这时候就需要项目经理来决定，因为测试人员要从用户的角度来看待Bug ，开发人员则要考虑到开发期限和付出的代价，而项目经理要同时考虑到这两种情况。 

    只有项目经理经过权衡之后才能确定是否要推迟修复该 Bug；在By design 情况下，通常是争论最多的时候。这时候也需要三方都坐下来谈，其结果一般有三种:坚持原来的设计、修改原来的设计并增加特性、或者取消该设计。对Not repro 和Won't fix 情况也是这样，需要测试人员、开发人员和项目经理进行协商，直到三方达成共识。