如何让软件测试变得有趣

  讨厌！我一直讨厌做测试。测试（单元测试和功能测试）是防碍“真正”工作的事情。每个人都确信自己的代码是完美的，不是吗？在确实需要更改代码的极少数事件中，注释编写得如此之好，以致每个人都能领会其中的含义。我需要提高（或许还需要作一些咨询）。

        在过去的几年里，单元测试已成为我编写软件的核心环节，多亏了一种称为极限编程 (XP) 的简便编程方法（请参阅参考资源）。这种方法要求我为添加的每个函数编写单元测试，并且要维护这些测试。如果单元测试失败，我就无法整合任何代码。随着代码库的不断增大，这些测试将使开发人员能够很有把握地完成更改。

        起初，我认为有了单元测试，就没必要再进行功能测试。噢，又错了。功能测试与单元测试相差甚远。我花了很长一段时间理解二者的区别，以及如何结合使用两者来改进开发过程。

        本文探究单元测试与功能测试之间的区别。并概述了在日常开发中使用这两种测试的方法。

测试与开发过程
        测试对于开发人员极为重要，您必须在开发过程中不断进行测试。测试不应该只属于开发周期的某个特定阶段。它绝不应该是您将系统交给客户前要完成的最后一项任务。如何才能知道您何时就完成了所有任务呢？如何才能知道对一个小错误的修正是否破坏了系统的主要功能呢？目前想像中的系统如何才能演化为实实在在的系统呢？单元测试和功能测试都应该是开发过程中不可分割的一部分。

        单元测试应成为您编写代码的核心环节，当您所做的项目时限很紧并且您希望控制开发进度时尤其如此。由于单元测试是如此重要，所以您应该先编写测试，再编写代码。

        一套适当的单元测试具有以下功能：

        说明可能的最实用设计 
        提供类文档的最佳格式 
        确定一个类何时完成 
        增强开发人员对代码的信心 
        作为快速重构的基础
　

        单元测试创建随系统自然发展的设计文档。再读一遍上一句话。文档随系统自然发展，这是软件开发的“圣杯”。有什么方法比通过提供一个用例编码集来记录一个类效果更好呢？那就是单元测试：一系列记录类所做工作的用例代码，提供输出控制。这样，由于单元测试必须通过，所以设计文档总是最新的。

        您应该首先编写测试，然后再编写代码。这样就为要测试的类提供了一种设计，这种设计使您每一时刻都只需集中考虑一小块代码。这种做法也使设计变得不再复杂。您没有试图为以后着想而实现一些不必要的功能。先编写测试还使您知道该类何时完成。一旦通过所有测试，任务也就完成了。

        最后，单元测试可使您高度自信，这又会转化为开发人员的满意度。如果只要更改代码即运行单元测试，您立即就能发现您所做的更改是否对系统造成了破坏。

        功能测试比单元测试更重要，因为功能测试将验证系统是否可以发行了。功能测试以一种有用的方式对您的工作系统进行说明。一套适当的功能测试具有以下功能：

以有效方式捕获用户需求 
        增强小组（用户和开发人员）在系统满足用户需求方面的信心
　

        功能测试以有效方式捕获用户需求。传统开发通过用例来捕获需求。通常，人们讨论用例并花很长时间对它们进行细化。他们最后所得到的只是一纸空文。功能测试就像自验证式用例。极限编程方法可解释这一概念。XP Stories 将成为未来用户与开发人员进行沟通的协议。功能测试便是这种沟通的结果。未经功能测试的 Stories 不可能很完善。

      

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