二、关于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；在Bydesign情况下，通常是争论多的时候。这时候也需要三方都坐下来谈，其结果一般有三种:坚持原来的设计、修改原来的设计并增加特性、或者取消该设计。对Notrepro和Won'tfix情况也是这样，需要测试人员、开发人员和项目经理进行协商，直到三方达成共识。

　　四、软件测试方法和辅助工具

　　有了Bug类型的定义以后，如何去找出这些Bug呢？这需要采用好的测试方法。以下介绍几种常用的钦件测试方法。有多种方式对软件测试方法进行分类。例如，从代码和用户使用的角度可以将软件测试方法分为如下几种。

　　(1)覆盖性测试(CoverageTesting)覆盖性测试是从代码的特性角度(即内部)出发的测试方法，包括以下方式。

　　①单元测试(UnitTest):按照代码的单元组成逐个进行测试。

　　②功能测试(FunctionTest)或特性测试(FeatureTest):按照软件的功能或特性逐个进行测试。例如，在Exchange中，发送邮件和接收邮件是两个不同的功能或特性，在测试时分别对它们进行检查，看是否工作正常。

　　③提交测试(Check-inTest):在开发人员对代码做了任何修改，或者修复了某个Bug时，需要重新Check-in代码(即将修改后的代码放大到整个大的系统中)。这时，开发人员往往也要进行测试，看代码是否工作正常。为了保险起见，开发人员往往要找测试人员帮着一起进行测试(我们把这种情况称做BuddyTest)。测试人员和开发人员之间搞好关系是非常重要的，稍后我会专门讲述这一点。

　　④基本验证测试(BuildVerificationTest，简称BVT):对完成的代码进行编译和连接，产生一个构造，以检查程序的主要功能是否会像预期一样进行工作。这是简单而又省时的一种测试方法。每产生一个新的构造时都要进行测试。如果连BVT都通不过，表明问题很严重，开发人员需要尽快修复出现的问题，测试人员也不用浪费时间做其他测试了。

　　⑤回归测试(RegressionTest):过一段时间以后，再回过头来对以前修复过的Bug重新进行测试，看该Bug是否会重新出现。

　　(2)使用测试(UsageTesting)使用测试是从用户的角度(即外部)出发的测试方法。它也包括许多类型。

　　①配置测试(ConfigurationTest):从用户的使用出发进行多方面的测试。例如，保证软件不仅能够在Windows9X下运行，也能够在WindowsME下运行，还能够在WindowsNT/200O/XP下运行;或者软件不仅能够在配置高的计算机上运行，也能够在配置很低的计算机上正确地运行。总之，要考虑到用户的多种情况，用多种配置对软件进行测试。

　　②兼容性侧试(CompatibilityTest):主要考虑兼容性问题，比如同一个产品的不同版本(如Office2O00和OfficeXP)之间的兼容问题，不同厂家的同一个产品(如IE和Netscape)之间的兼容问题，不同类型软件(如IE和Office)之间的兼容问题等。难测试的往往是软件的兼容性问题，往往要投人巨大的人力和物力。一些厂商开发出来的产品在兼容性上做得很不好，是因为没有足够的人力和物力进行测试。

　　我在做SQLServer的XML测试的时候，为了解决XML的兼容性问题，用了6个测试人员和100台计算机进行测试。正因如此，微软产品的兼容性都非常好。而不像市场上的一些产品，安装以后导致计算机上的许多其他软件无法使用，或者出现各种各样的问题，这样不仅伤害了其他软件，也伤害了用户。

　　③压力测试(StressTest):在各种极限情况下对产品进行测试(如很多人同时使用该软件，或者反复运行该软件)，以检查产品的长期稳定性。例如，我们在开发IE4.0的时候，由于当时有一个非常强的竞争对手，因此我们必须保证IE4.0要做得非常好。当时，为了测试IE4.0的长期稳定性，我们专门设计了一套自动测试程序，它一分钟可以下载上千个页面。我们使用这个测试程序对IE4.0进行了连续72小时的测试，也没有出现任何问题，如内存泄漏、程序崩溃等。

　　本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，会导致系统崩滑。

　　④性能测试(PerformanceTest):本项测试是保证程序具有良好的性能。如果别人的产品只需5秒钟能得出结果，而你的产品需要10秒钟才能得出结果，说明你的产品

　　性能不好。如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，要考虑到软件的性能问题。