单元测试

内容介绍     本系列文章根据《单元测试与VU2.6应用》视频讲座的理论部分整理而成，主要讨论四个问题：为什么需要单元测试？怎样征服可测性难题？怎样才能高效率测试？怎样保证测试效果？重点阐述单元测试的关键问题，不是一般概念，适合于对单元测试有一定了解的读者。    在选择工具和实施单元测试前，我们应该对相关理论有一个系统的了解，特别是将会遇到哪些难题，如何解决，要心里有数，否则的话，

第4章 怎样才能保证测试效果？ 4.1 衡量测试效果的基本指标：白盒覆盖    衡量测试效果的基本指标是白盒覆盖率，即统计测试对代码逻辑单位的覆盖状况。代码的逻辑单位主要有：语句(块)，条件、判定、分支、路径。常用的白盒覆盖有六种：语句覆盖、条件覆盖、分支覆盖、判定条件覆盖、修正判定条件覆盖、和路径覆盖。每种覆盖都有它的局限性，因此，实践中要多种覆盖组合应用。     除M

3.3 高效率开发     这一节介绍利用单元测试实现高效率开发。单元测试可以在几个方面提高开发效率：测试驱动开发、可视编程、快速排错、和提高调试效率。 测试驱动开发    指先编写测试代码，然后再编写产品代码使测试通过，有很多相关文章和书籍介绍这方面知识，限于编幅，这里就不讲了。 可视编程    是测试驱动开发的升级和改进。如果边开发边测试，那么，工具可以将程序的行为展示

2.2 解决可测性问题     上一节具体分析了可测性问题，接下来，我们来看看如何解决这些问题。下图中，彩色的部分是需要解决的可测性的具体的问题。       与其他代码隔离    为了提高效率，应该一次性将一位工程师负责的测试任务隔离出来。隔离时，应把源文件分为三类：被测文件，外围文件，其他文件。被测文件是测试目标，外围文件是指与被测文件关联密切的底层或相关文件，这些

3.2 高效率测试：四两拔千斤     上一节介绍了一些似是而非的高效率方法，那么，怎样才能真正高效率测试呢？真正的高效率，不能忽略人的智慧这一关键因素。由于工具不可能自动了解代码的设计功能，只有人才了解，因此，只有人的智慧及时介入，工具才能做正确的事情，才能达到真正的高效率。     测试的主要工作在于用例，这方面，工具可以完成大量自动化的工作，主要包括：生成测试代码，生成测

第3章 怎样才能高效率测试3.1 似是而非的高效率     这一节澄清一些流行的误解或误导，一些看起来很不错的高效率，实际上是似是而非的。 全自动生成用例    全自动生成用例是所有测试人员的期盼，好消息是，这是一种简单的技术，十年前就有了，坏消息是，这种技术作用很小。          工具不可能自动了解代码的设计功能，全自动生成的用例，只能发现极端错误，

2.1 可测性问题详解(2)           接下来我们讨论重点问题：覆盖输入。一个函数，输入会有哪些呢？输入包括两方面：外部输入，内部输入。外部输入容易理解，就是函数外部可以设定的输入，包括参数，全局变量，成员变量。              关键是内部输入。因为很少有文献讨论内部输入，对很多人来说，内部输入可能是一个陌生的词，我们首先来看看内部输入是什么

第二章 征服可测性难题 2.1 可测性问题详解（1）     单元测试效益特别高，方法也很简单，但却尝试的企业很多，成功实施的企业很少，为什么呢？主要原因就是难于突破可测性问题。“可测”这个词，意思已经很明白了，如果不“可测”的话，那就是不能测，没法测，就是做不下去，或者困难太多，成本太重，热情被逐渐消磨，最后做不下去。所以可测性问题是单元测试的关键，是我们首先要解决的。 

题外篇：单元测试难于长期坚持的原因与解决探讨     上一篇《单元测试效益》，有网友评论说：“单元测试的好处基本人人知道，就是难坚持！”。这一评论严重提醒了我，不错，“难坚持”也是一个普遍现状。如果不能坚持，那一切都是白搭。因此，这里插入一个题外篇，探讨单元测试难于长期坚持的原因与解决，抛砖引玉，希望大家踊跃讨论，共同找出使单元测试易以坚持的途径。     我以前主要关注如何做得了

1.3 单元测试能产生哪些效益？     单元测试的效益已经得到广泛的认同，现在的问题已经不是有没有必要做，值不值得做，而是如何多快好省地做好单元测试，所以，关于效益，这里只是简单的介绍一下。 效益一，保证代码质量        只有单元测试才能完整检测代码单元的功能逻辑，使代码单元的质量得到保证，只有代码单元的质量得到保证，软件的整体质量才有可能得到保证。 效益二

1.2 单元测试的目标和方法     单元测试的目标是什么呢？就是完整检测代码单元的功能逻辑。找出代码单元本身的所有功能逻辑错误，具体来说，就是检测对数据的各种分类是否考虑全面，处理是否正确。单元测试并不是用来代替系统测试、性能测试的，它的目标相当明确，就是检测代码单元本身的功能逻辑错误。            如果时间紧张，应该优先测试哪些代码呢？代码的功能逻辑越复杂，也就是算法密集

4.2 多角度保证测试效果     对于代码质量要求很高的项目来说，仅有白盒覆盖是远远不够的。白盒覆盖不能发现代码缺失，白盒覆盖基于现有代码，如果代码不存在，当然不能发现。为了检测代码缺失，需要人工对测试数据进行检查。白盒覆盖也不能发现用例未反映功能。如果设计用例时，测试员不了解代码的功能，通过阅读代码来设计用例，这叫跟着代码走，这样测试的话，再高的覆盖率也没有意义。这也从另一个角度说明了