只要一提到关于软件质量的问题，就会有人问到这个问题。有些学生想知道进行多少测试才行。对于那些认为测试只是在浪费时间或吹毛求疵的学生，我会给他们一个机会让他们以测试工作量最小（有时甚至是没有）的策略来完成他们的软件工程的课程项目 。

　　我的学生经常向我说起他们的模块和类编写得多么巧妙，他们是如何认真地遵守了建模原则。有许多学生还使用了UML（Unified Modeling Language，统一建模语言）图来帮助自己进行开发。这些做法都很好，但测试绝不仅仅是保证你的源代码与你的模型相匹配那么简单。有不少对自己的编程技巧很自信的学生交上来的作业经常存在着一些功能方面的小毛病。虽然那些小毛病一般不至于引发致命错误或崩溃（这在开发工作中经常会遇到），但在集成和软件的运行方面经常出问题。也就是说，这些学生没能做到让他们的软件按照顾客希望的那样工作。

　　如果你对这种场景很熟悉，就说明你已经了解了软件测试的价值。软件测试的形式有很多，目的都是保证和控制软件的质量。在什么时候选择什么技术进行测试是软件测试学需要解决的根本问题。

　　提示 如果你还没有过从测试入手进行软件开发或是与一位专业软件测试人员合作的经历，我建议你赶快去找一位这方面的专业人士。他们对软件的故障往往有着超常的洞察力，很少有开发人员能做到像他们一样。不要因为他们指出了你代码中的缺陷而感到羞愧--那是他们的工作，而且他们都精于此道！

　　1、测试与调试

　　有不少人把“测试”和“调试”混为一谈。虽然它们的目标是同一个--找出缺陷，但它们并不是一回事。调试是一种交互式的过程，是通过分析源代码的内部工作情况去寻找源代码逻辑中的缺陷。测试是通过执行源代码去发现其中隐藏着的缺陷，不需要分析源代码的内部工作情况。

　　2、测试驱动开发

　　测试驱动开发（test-driven development）通常与敏捷编程技术相关。事实上，测试驱动开发在采用极限编程（extreme programming，XP）方法的软件公司里最为常见。这听起来有点儿唬人，我可以向你透露一个关于XP的秘密：你不必采用XP方法也可以进行敏捷编程。

　　因为反对者不负责任的言辞，有不少人对敏捷编程技术持很深的怀疑态度。传统的软件工程方法学在理论和实践方面的成功是有目共睹的，人们把它奉为“金科玉律”也情有可原，但仅凭一知半解就把敏捷开发技术与偷工减料和质量低劣等同起来是毫无道理的，因为事实完全不是这样。

　　敏捷开发技术的核心概念是最大限度地减少软件开发过程中的不必要环节，重视与顾客的交流，只在需要的时候才编写需要的功能，把工作的重点放在满足客户此时此刻的需求上。敏捷开发技术围绕着顾客展开，具体过程并不是它最关心的焦点。敏捷开发技术可以全面推广，也可以有选择地在小范围应用。换句话说，在转向敏捷开发技术的时候，软件公司应该根据自己的具体情况摸着石头过河，而不是一下就扎进自己不熟悉的技术中，那会让它们的开发人员感到难以适应。欲速则不达，有不少软件公司就是因为在接纳敏捷开发技术方面太过急于求成才会陷入困境。正是因为这类负面案例时有发生，才会有人反对或怀疑敏捷开发技术 。如果想了解关于敏捷开发技术与传统方法孰优孰劣之争的更多情况，请访问Agile Alliance网站www.agilealliance.org。

　　在各种敏捷开发技术当中，最有用的要属测试驱动开发技术了。测试驱动开发技术的基本思路很简单：从整个解决方案的一个基本模块开始，编写测试，运行测试，编写解决方案，用测试来验证它确实能够解决问题。这个过程听起来不难理解，但在实践中往往会变得相当复杂。在编写代码之前先编写测试让人有一种本末倒置的感觉--如果某个东西不存在，我们该如何去测试它呢？这么做真的有用吗？先行开发有关测试可以让你把精力集中到你的软件设计方案而不是代码上。我将解释一个典型的测试驱动开发过程，让大家看看测试驱动开发技术是如何紧扣设计方案并“驱动”程序员编写出源代码的。我知道这听起来有点儿奇怪，但我希望大家能给我个机会来证明它是有道理的。

　　测试驱动开发活动从整个系统的一个简单模块开始。用一个简单的类图把系统里的各个基本类以及它们之间的关系画出来。在这个类图中，除了一个暂定的类名外，各个类的代码块部分可以是空白。我说“暂定”是因为这通常是采用传统方法的程序员感到困惑的地方。在敏捷开发技术里，没有什么是固定不变的，什么东西都允许修改。简单地说，只要能把顾客需要的软件交付给顾客，做什么都行。

　　设计好最初的类关系框图之后，把它复制下来放在旁边，它就是所谓的“域模型”（domain model）；它确定了整个系统中类的初始布局。接下来创建用例图（use case diagram）和辅助用例场景（用例及各种执行顺序的文本描述）。然后每个都用一个顺序图来扩充，这就制定出了所引用的类需要的函数。

　　等每一个类都大致成形之后，就可以开始编写测试了。是的，虽然那些类还都不存在，你仍然可以为它们编写测试。这些测试包括对域模型中的每一个类进行集成测试、系统测试和接口测试（它们都属于黑盒测试）。

　　注解 黑盒测试是在不了解系统内部构造的情况下进行的测试。白盒测试是在了解系统内部结构的情况下对其行为进行的测试。

　　就绝大多数以敏捷开发技术开发的项目而言，从这个过程的第一遍循环里学到的东西就是在这个时候融合到设计方案的相关部分（用例图、顺序图，等等）中并根据具体情况做出调整的。

　　注解 有些敏捷程序员还会使用健壮性图（robustness diagram）给这个过程增加一个建模步骤。这种做法与ICONIX过程很相似。关于ICONIX过程的更多信息请参考Agile Development with ICONIX Procress 一书。

　　这些修改包括：新类的发现、对现有类的重新组织以及定义某个类的方法和属性等。换句话说，在编写代码之前编写测试可以帮助你验证你的设计方案。这真的很酷：等你完成了你的设计并开始编写源代码的时候，你已经完成了测试！只需运行测试来证明你的代码的工作情况符合设计要求就行了。当然，如果需要改变测试或改变设计方案，你随时都可以这样做；这正是敏捷开发技术的魅力所在。