C/C++单元测试理论精要（1)
本系列文章根据《单元测试与VU2.6应用》视频讲座的理论部分整理而成，主要讨论四个问题：为什么需要单元测试？怎样征服可测性难题？怎样才能高效率测试？怎样保证测试效果？重点阐述单元测试的关键问题，不是一般概念，适合于对单元测试有一定了解的读者。
在选择工具和实施单元测试前，我们应该对相关理论有一个系统的了解，特别是将会遇到哪些难题，如何解决，要心里有数，否则的话，很可能劳民伤财，半途而废。如果只会测试加法函数或者三角形函数之类的独立小程序，就以为可以做单元测试了，那就像一个人刚学会走路，就去长途跋涉。
本文介绍的是针对企业项目的单元测试。企业项目具有两个特点：项目复杂，时间紧张。项目复杂，意味着测试时会遇到很多难题；时间紧张，要求我们不但要保证测试效果，还要尽可能高效率。本文不是泛泛而谈，而是针对企业项目的两个特点，努力揭示本质性的问题，并提出解决办法，对于常识性的问题，将比较简略的带过。使用的工具是Visual Unit 2.6，本文主要不是介绍工具，而是介绍问题所在和解决办法，涉及到工具，只是为了具体的展示解决办法，也为了说明，这些办法都是可行的，并非空谈。
第1章 为什么需要单元测试
1.1 从代码特性看单元测试的必要性
代码有一个很基本的特性，是什么呢？对数据分类处理。一个判定，就是一次分类。如果判定中又嵌套了判定的话，分类次数就会翻倍。循环判定也是一种分类。
如果一个分类遗漏的话，也就是说，某种输入没有处理，会怎么样呢？一个Bug诞生了！如果一个分类的处理不正确，又会怎么样呢？又一个Bug诞生了！
一个函数要做到没有错误，要保证两点：分类完整，也就是各类可能输入都要考虑到；
处理正确，也就是每一类输入都要进行正确的处理。做到了这两点，就可以说，函数的功能逻辑是正确的。函数的功能逻辑就是对数据的分类以及处理。
那么，怎样才能全面地检测程序的功能逻辑呢？调试，是临时的，不做记录，另一方面，调试的工作方式是拦截数据，并不是所有输入分类都能拦截得到的，如果一个函数有十类输入，调试能覆盖五六个就不错了。系统测试，不针对具体的函数，无法做到对具体函数的输入分类覆盖。要全面地检测程序的功能逻辑，必须把输入分类全部列出来。并检测程序是否处理了这些输入，处理是否正确。这就是单元测试。
1.2 单元测试的目标和方法
单元测试的目标是什么呢？就是完整检测代码单元的功能逻辑。找出代码单元本身的所有功能逻辑错误，具体来说，就是检测对数据的各种分类是否考虑全面，处理是否正确。单元测试并不是用来代替系统测试、性能测试的，它的目标相当明确，就是检测代码单元本身的功能逻辑错误。
如果时间紧张，应该优先测试哪些代码呢？代码的功能逻辑越复杂，也就是算法密集度越高，可能的错误越多，越需要全面的测试，测试效益越大。所以，如果时间不够，应该优先测试算法密集的代码。80-20规则在软件开发中同样存在，也就是80%的代码错误可能存在于20%的代码中，20%的代码可能占用了80%的开发调试时间。这20%就是算法密集的代码，即使只对这些代码进行单元测试，也可以产生巨大的效益。代码复杂度和测试价值可以用工具来统计。
测试方法主要有两种：静态和动态。静态方法主要由工具扫描和分析代码。动态方法则需要执行代码。
静态方法能发现哪些错误呢？从静态测试的角度来看，代码错误可分为代码缺失，语义错误，一般错误。代码缺失是分类遗漏造成的，也就是程序员没有考虑到某些输入，没有编写相应代码。语义错误就是通过分析代码的语法含义，有可能判断的错误，例如，条件语句中将等于操作符写成了赋值操作符、数组越界、除零错。其他错误就是一般错误。对于语义错误，静态测试可能能够发现。对于代码缺失，静态测试无法发现，因为代码不存在，也就无从分析。其他错误，静态测试不能发现，因为工具不了解代码的设计功能。很显然，静态测试并没有真正检测代码的功能逻辑，根本不知道这个代码是干什么的，实现什么功能才对，只是通过分析代码的自然特性来检测错误，所以作用是很有限的。
|
