在开发过程中怎样利用单元和功能测试[1]

　　在开发过程中怎样利用单元和功能测试[1]   软件测试

　　在过去的几年中，单元测试逐渐成为我编写软件的核心内容，在这里要感谢一种叫做极端编程-XP(注1)(见“资源”一节)的简便程序设计方法。这种方法要求我为新加入的每个函数都编写单元测试，并且维护这些测试。没有通过单元测试，我就不能将任何一个的代码加到模块中。在代码基数增长的同时，这些测试允许开发者有依据地将改变集成起来。起初，我认为这些单元测试就足以应付全局，没有必要涉及到功能测试。噢，又错了。功能测试和单元测试完全不同的两者。我花费了很长的时间才理解到两者的区别，以及如何将它们结合起来，用以改进开发进程。

　　本文探讨了单元测试和功能测试之间的差别，同时介绍在你的日常开发的过程中如何来利用它测试和开发过程作为一个开发人员，测试如此之重要，以至于你甚至应该花费几乎所有的时间来完成它。它不仅需要只被划分为开发过程中的某个特定阶段。显然，它不该是在你把系统交付给客户之前完成的最后一项任务。然而，你又如何得知它在何时结束呢?或是你如何得知是否因为修改一个微小的bug而破坏了系统的主要功能呢?或是系统可能会演化成超乎现在想象的模样?测试，单元的和功能的都应该是开发的过程中的一部分。

　　单元测试应成为你编写代码的核心环节，尤其当你在从事一个项目时，紧张的时间约束你的开发进度，你也很想让它是在可控的有序下进行。我希望测试也是在你编写代码之前编写测试时的重要内容。

　　一套适用的单元测试应具备以下功能：

　　说明可能的最佳适用设计

　　提供类文档的最佳格式

　　判断一个类何时完成增强开发人员对代码的信心

　　是快速重构的基础

　　在系统中自然要包含单元测试所需的设计文档。重新阅读它，你会发现这是软件开发进程中的圣杯，文档跟随系统的变化而逐步演化。为每一个类提供完备的文档比起为它提供一系列的使用框架，或是一系列可控的输入要好得多。这样，设计文档就会因为单元测试的逐步通过而随时更新。

　　你应该在你编写代码之前完成编写测试的工序。这样做会为测试所涉及的类提供设计方案，并促使你关注代码中更小的程序模块。这种练习也会使设计方案变得更加简单。你不能试图去了解将来的情形，去实现不必要的功能。编写测试工作也会让你清楚类会在什么时间结束。可以说，当所有的测试通过时，任务也就完成了。

　　最后，单元测试会提供给你更高级别的依据，这绝对会满足开发者的。如果你在改动代码的同时，进行单元测试，你就会在你破坏的同时立即察觉到事态的发生。

　　功能测试甚至比单元测试更加重要，因为它们说明了你的系统就要预备发布了。功能测试将把你的工作系统放置于一个可用的状态中。

　　一套适用的功能测试应具备以下功能：

　　有效地掌握用户的需求

　　向项目组成员(包括用户和开发者)给出系统面临这些需求的依据

　　功能测试要在有效地情况下掌握用户的需求。而传统的开发者是在使用的过程中发现需求的。通常，人们赞同使用项目工程并且花费相当的时间去重新定制它们。当它们被完成时，它们所得到的仅仅是一堆废纸。功能测试雷同于自行生效的使用项目的情况。极端程序设计方法(ExtremeProgramming)能够说明这种概念。XP 的说法就是对未来发生在用户和开发者之间的交流技巧的描述。功能测试也是这种交流的结果。而没有功能测试，这种说法也不会建立起来的。

原文转自：http://www.ltesting.net