单元测试、功能测试区别.doc

在过去的几年里，单元测试已成为我编写软件的核心环节，多亏了一种称为极限 编程 (XP) 的简便编程方法（请参阅参考资源）。这种方法要求我为添加的每个 函数编写单元测试，并且要维护这些测试。如果单元测试失败，我就无法整合任 何代码。随着代码库的不断增大，这些测试将使开发人员能够很有把握地完成更 改。 起初，我认为有了单元测试，就没必要再进行功能测试。噢，又错了。 功能测试与单元测试相差甚远。我花了很长一段时间理解二者的区别，以及如何 结合使用两者来改进开发过程。 本文探究单元测试与功能测试之间的区别。 并概述了在日常开发中使用 这两种测试的方法。 测试与开发过程 测试对于开发人员极为重要，您必须在开发过程中不断进行测试。测试 不应该只属于开发周期的某个特定阶段。 它绝不应该是您将系统交给客户前要完 成的最后一项任务。 如何才能知道您何时就完成了所有任务呢？如何才能知道对 一个小错误的修正是否破坏了系统的主要功能呢？目前想像中的系统如何才能 演化为实实在在的系统呢？单元测试和功能测试都应该是开发过程中不可分割 的一部分。 单元测试应成为您编写代码的核心环节， 当您所做的项目时限很紧并且 您希望控制开发进度时尤其如此。由于单元测试是如此重要，所以您应该先编写 测试，再编写代码。 一套适当的单元测试具有以下功能： 说明可能的最实用设计 提供类文档的最佳格式 确定一个类何时完成 增强开发人员对代码的信心 作为快速重构的基础单元测试创建随系统自然发展的设计文档。再读一遍上一句话。文档随 系统自然发展，这是软件开发的“圣杯”。有什么方法比通过提供一个用例编码 集来记录一个类效果更好呢？那就是单元测试： 一系列记录类所做工作的用例代 码，提供输出控制。这样，由于单元测试必须通过，所以设计文档总是最新的。 您应该首先编写测试，然后再编写代码。这样就为要测试的类提供了一 种设计，这稚杓剖鼓恳皇笨潭贾恍杓锌悸且恍】榇搿庵肿龇彩股杓?变得不再复杂。您没有试图为以后着想而实现一些不必要的功能。先编写测试还 使您知道该类何时完成。一旦通过所有测试，任务也就完成了。最后，单元测试可使您高度自信，这又会转化为开发人员的满意度。如 果只要更改代码即运行单元测试， 您立即就能发现您所做的更改是否对系统造成 了破坏。 功能测试比单元测试更重要，因为功能测试将验证系统是否可以发行 了。功能测试以一种有用的方式对您的工作系统进行说明。一套适当的功能测试 具有以下功能： 以有效方式捕获用户需求 增强小组（用户和开发人员）在系统满足用户需求方面的信心功能测试以有效方式捕获用户需求。传统开发通过用例来捕获需求。通 常，人们讨论用例并花很长时间对它们进行细化。他们最后所得到的只是一纸空 文。 功能测试就像自验证式用例。 极限编程方法可解释这一概念。 Stories 将 XP 成为未来用户与开发人员进行沟通的协议。功能测试便是这种沟通的结果。未经 功能测试的 Stories 不可能很完善。 功能测试填补单元测试留下的空白，并可增强小组对代码的信心。单元 测试漏掉许多错误。尽管它可以提供您所需的全部代码，但它可能无法提供您所 需的全部系统功能。功能测试将暴露单元测试遗漏的问题。一套适当的自动化功 能测试也不可能捕捉到每个错误， 但是它能比最好的单一单元测试捕捉更多的错 误。 单元测试与功能测试 单元测试向开发人员表明代码正确执行操作； 而功能测试向开发人员表 明代码执行正确的操作。 单元测试 单元测试是从程序员的角度编写的。 它确保类的某个特定方法成功执行 一系列特定的任务。每个测试都确保只要给定输入，方法将输出预期的结果。 如果没有测试框架，编写一套可维护的自动化单元测试几乎是不可能 的。在开始编写测试之前，请选择一个小组公认的框架。您将经常性地使用这个 框架，因此您最好对它有点好感。极限编程网站提供了几个单元测试框架（请参 阅参考资源）。我最熟悉的框架是 JUnit，它专门用来测试 Java 代码。 功能测试 功能测试是从用户的角度编写的。 这种测试确保系统执行用户期望它执 行的工作。 NextPage 很多时候，系统开发好比建筑房屋。尽管这种类比不很恰当，但为了理 解单元测试与功能测试的区别，我们可以扩充这种类比。单元测试好比房屋建筑现场的建筑监理员。他关心房屋的各个内部系统，如地基、构架、供电系统和管 道设备等。他确保（测试）房屋每一部分的工作都安全、正常，即符合建筑说明。 这种情况下，功能测试类似于视察同一建筑现场的房主。他假定内部系统将正常 运作， 并假定建筑监理员在执行其任务。 房主关心的是住在这所房子里将会怎样。 他关心房子的外观如何，各个房间的大小是否合适，房子能否满足家庭的需要， 以及窗户的位置是否有利于采光。房主对房子执行功能测试。他从用户的角度考 虑问题。建筑监理员对房子执行单元测试。他从建筑工人的角度考虑问题。 就像单元测试一样，如果没有测试框架，编写一套可维护的自动化功能 测试实际上是不可能的。JUnit 非常适合编写单元测试；但是，当试图编写功能 测试时，它就显得力不从心了。就功能测试而言，没有与 JUnit 相当的框架。 也有几种用于功能测试的产品，但我从来没见过它们应用于生产环境。如果找不 到满足您的需要的框架，您就必须创建一个。 无论我们多么擅长于构建手头的项目， 也不管我们正在创建的系统多么 灵活，如果我们的产品不合用，那我们就是白费时间。因此，功能测试是开发最 重要的部分。 由于两种测试都必不可少，您就需要了解编写它们应遵循的原则。 如何编写单元测试 刚开始编写单元测试时很容易恢心。 最佳的入手方式就是为新代码创建 单元测试。（尽管为现有代码创建单元测试比较困难，但并非无法实现）。首先 从新代码着手，待您习惯了整个过程以后，再针对现有代码创建测试程序。 如上文所述，应该首先编写单元测试，然后再编写这些单元测试要测试 的代码。如何为尚不存在的代码编写测试呢？问得非常好。掌握这一方法需要 90% 的思维加 10% 的技术。我的意思是，您只需假定您正在为其编写测试的类 已经存在。 接下来的任务就是编写测试。 起初会犯很多语法错误， 但您先别管它。 这一步您要做的就是定义该类要实现的接口。下一步就是运行您的单元测试，修 正语法错误（即，编写一个类，使它实现您的测试刚定义的接口），并再次运行 测试。重复这一过程，每次仅编写修正故障的代码。运行测试，直到测试全部通 过为止。一旦通过全部单元测试，代码也就完成了。 一般而言，类的每个公共方法都应有一个单元测试。但是，功能简单的 方法（例如，getter 方法和 setter 方法）不需要单元测试，除非它们以某种 特别的方式进行获取和设置。应该遵循下面这条很好的原则：即只要您认为有必 要对代码中的某个行为加注，就编写一个单元测试。如果您像其他许多程序员一 样不喜欢为代码加注，则单元测试是记录代码行为的一种方法。 将单元测试与被测试的相关类放在同一个包内。 这种组织方式使