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

 

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

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

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

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

　　说明可能的最佳适用设计

　　提供类文档的最佳格式

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

　　是快速重构的基础

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

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

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

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

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

　　有效地掌握用户的需求

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

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

功能测试恰好填充了在单元测试和向项目小组提交的代码依据之间的空隙。单元测试会漏过许多的bug.它可以给出代码中你所需的所有有效部分，它也会 给你所需的整个系统。功能测试可以使单元测试里漏掉的问题曝光。一系列可维护的，自动化的功能测试也会有漏网的情况，但是它至少比独立地进行最全面的单元 测试要有用得多。

　　单元测试VS 功能测试

　　单元测试告诉开发者代码使事情正确地被执行，而功能测试所说的则是代码在正确地发挥功效。

　　单元测试

　　单元测试是从开发者的角度来编写的。它们确保类的每个特定方法成功执行一系列特定的任务。每一个测试都要保证对于给定的一个已知的输入应该得到所期望的输出。

　　编写一系列可维护、自动化、没有测试框架的单元测试几乎是不可能的。在你开始之前，选择一个项目小组都认可的框架。不断地应用它，逐渐地喜欢它。在极端编程的介绍网页上(见资源一节)，有很多适用的单元测试框架。我喜欢用的是Juint 来进行Java 代码的测试。

　　功能测试

　　功能测试则是从用户的角度来编写的。这些测试保证系统能够按照用户所期望的那样去运行。很多时候，开发一个完整的系统更像是建造一座大楼。当然，这种比喻并不是完全地恰当，但我们可以扩展它，来理解单元测试和功能测试之间的区别。

 

注：以上内容来自网络，本人不承担任何连带责任

文章转自：http://se.csai.cn/testtech/200801300052411345.htm