随笔 - 3, 文章 - 152, 评论 - 17, 引用 - 0
数据加载中……

单元测试-理论篇

作者:Moxie

        测试是软件开发的重要环节之一。按照软件开发的过程测试可分为:单元测试、集成测试、系统测试、域测试(Field test)等。我们这里将讨论面向程序员的单元测试。本文首先介绍单元测试的定义,为什么要使用单元测试?单元测试能给我们带来的好处。之后我们将介绍单元测试的范畴,最后将讨论很多朋友不写单元测试的借口。希望本文能够再次引起您对单元测试的重视,并说服您老板对编写单元测试的支持,能让美丽的单元测试真正应用到您的项目之中。

什么是单元测试
      单元测试是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。例如,你可能把一个很大的值放入一个有序list 中去,然后确认该值出现在list 的尾部。或者,你可能会从字符串中删除匹配某种模式的字符,然后确认字符串确实不再包含这些字符了。
    单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。

为什么要使用单元测试
    我们编写代码时,一定会反复调试保证它能够编译通过。如果是编译没有通过的代码,没有任何人会愿意交付给自己的老板。但代码通过编译,只是说明了它的语法正确;我们却无法保证它的语义也一定正确,没有任何人可以轻易承诺这段代码的行为一定是正确的。
    幸运,单元测试会为我们的承诺做保证。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试,我们可以自信的交付自己的代码,而没有任何的后顾之忧。

单元测试有下面的这些优点:
1、它是一种验证行为。
    程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支缓。就算是开发后期,我们也可以轻松的增加功能或更改程序结构,而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障。这样,我们就可以更自由的对程序进行改进。
2、它是一种设计行为。
    编写单元测试将使我们从调用者观察、思考。特别是先写测试(test-first),迫使我们把程序设计成易于调用和可测试的,即迫使我们解除软件中的耦合。
3、它是一种编写文档的行为。
    单元测试是一种无价的文档,它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的,并且它保持最新,永远与代码同步。
4、它具有回归性。
    自动化的单元测试避免了代码出现回归,编写完成之后,可以随时随地的快速运行测试。

单元测试的范畴
    如果要给单元测试定义一个明确的范畴,指出哪些功能是属于单元测试,这似乎很难。但下面讨论的四个问题,基本上可以说明单元测试的范畴,单元测试所要做的工作。
1、 它的行为和我期望的一致吗?
    这是单元测试最根本的目的,我们就是用单元测试的代码来证明它所做的就是我们所期望的。
2、 它的行为一直和我期望的一致吗?
    编写单元测试,如果只测试代码的一条正确路径,让它正确走一遍,并不算是真正的完成。软件开发是一个项复杂的工程,在测试某段代码的行为是否和你的期望一致时,你需要确认:在任何情况下,这段代码是否都和你的期望一致;譬如参数很可疑、硬盘没有剩余空间、缓冲区溢出、网络掉线的时候。
3、 我可以依赖单元测试吗?
   不能依赖的代码是没有多大用处的。既然单元测试是用来保证代码的正确性,那么单元测试也一定要值得依赖。
4、 单元测试说明我的意图了吗?
    单元测试能够帮我们充分了解代码的用法,从效果上而言,单元测试就像是能执行的文档,说明了在你用各种条件调用代码时,你所能期望这段代码完成的功能。

不写测试的借口
    到这里,我们已经列举了使用单元测试的种种理由。也许,每个人都同意,是的,该做更多的测试。这种人人同意的事情还多着呢,是的,该多吃蔬菜,该戒烟,该多休息,该多锻炼……这并不意味着我们中的所有人都会这么去做,不是吗?
1、 编写单元测试太花时间了。
    我们知道,在开发时越早发现BUG,就能节省更多的时间,降低更多的风险。
    下图表摘自<<实用软件度量>>(Capers Jones,McGraw-Hill 1991),它列出了准备测试,执行测试,和修改缺陷所花费的时间(以一个功能点为基准),这些数据显示单元测试的成本效率大约是集成测试的两倍,是系统测试的三倍(参见条形图)。
 
    术语:域测试(Field test)意思是在软件投入使用以后,针对某个领域所作的所有测试活动。
    如果你仍然认为在编写产品代码的时候,还是没有时间编写测试代码,那么请先考虑下面这些问题:
        1)、对于所编写的代码,你在调试上面花了多少时间。
        2)、对于以前你自认为正确的代码,而实际上这些代码却存在重大的bug,你花了多少时间在重新确认这些代码上面。
        3)、对于一个别人报告的bug,你花了多少时间才找出导致这个bug 的源码位置。
    回答完这些问题,你一定不再以“太花时间”作为拒绝单元测试的借口。
2、 运行测试的时间太长了。
    合适的测试是不会让这种情况发生的。实际上,大多数测试的执行都是非常快的,因此你在几秒之内就可以运行成千上万个测试。但是有时某些测试会花费很长的时间。这时,需要把这些耗时的测试和其他测试分开。通常可以每天运行这种测试一次,或者几天一次。
3、 测试代码并不是我的工作。
    你的工作就是保证代码能够正确的完成你的行为,恰恰相反,测试代码正是你不可缺少的工作。
4、 我并不清楚代码的行为,所以也就无从测试。
   如果你实在不清楚代码的行为,那么估计现在并不是编码的时候。如果你并不知道代码的行为,那么你又如何知道你编写的代码是正确的呢?
5、 但是这些代码都能够编译通过。
    我们前面已经说过,代码通过编译只是验证它的语法通过。但并不能保证它的行为就一定正确。
6、 公司请我来是为了写代码,而不是写测试。
    公司付给你薪水是为了让你编写产品代码,而单元测试大体上是一个工具,是一个和编辑器、开发环境、编译器等处于同一位置的工具。
7、 如果我让测试员或者QA(Quality Assurance)人员没有工作,那么我会觉得很内疚。
   你并不需要担心这些。请记住,我们在此只是谈论单元测试,而它只是一种针对源码的、低层次的,为程序员而设计的测试。在整个项目中,还有其他的很多测试需要这些人来完成,如:功能测试、验收测试、性能测试、环境测试、有效性测试、正确性测试、正规分析等等。
8、 我的公司并不会让我在真实系统中运行单元测试。
    我们所讨论的只是针对开发者的单元测试。也就是说,如果你可以在其他的环境下(例如在正式的产品系统中)运行这些测试的话,那么它们就不再是单元测试,而是其他类型的测试了。实际上,你可以在你的本机运行单元测试,使用你自己的数据库,或者使用mock 对象。

总结
  总而言之,单元测试会让我们的开发工作变得更加轻松,让我们对自己的代码更加自信。无论是大型项目还是小型项目,无论是时间紧迫的项目还是时间宽裕的项目,只要代码不是一次写完永不改动,编写单元测试就一定超值,它已成为我们编码不可缺少的一部分。

参考资料
《单元测试之道Java版——使用JUNIT》:这是一本非常好的介绍单元测试的书,作者讲的非常透彻,译者的文笔也很好。在此向您强烈推荐。本文内容,也有很多直接引用于此书!
《JUNIT IN ACTION》:这是一本专门介绍JUNIT的好书。

posted on 2005-04-11 14:45 阅读(165) 评论(0)  编辑  收藏 所属分类: 测试


只有注册用户登录后才能发表评论。


网站导航: