什么是单元测试？

单元测试是对软件基本组成单元进行测试，这里的基本单元不一定是指一个具体的函数（Function或Procedure）或一个类的方法，“单元”具有一些基本属性，如：明确的功能、规格定义，明确的接口定义，可清晰地与同一程序的其它单元划分开来。

在纯C语言的代码中，为了操作方便期间，我们一般认为一个函数就是一个单元。

1.1.1    单元测试的主要目的：

1.验证代码是与设计符合的

2.跟踪需求和设计的实现

3.发现设计和需求中存在的错误

4.发现在编码过程中引入的错误

1.1.2    何时开展单元测试

一般地，在编码阶段就应开展单元测试，边写程序边测试是一个好习惯。一个组织不要孤立的划分出编码和单元测试两个阶段，也不要等代码都写完了才开始单元测试。

有时候需要将单元测试时间推后到集成阶段，甚至系统完成阶段。

单元测试可以分为计划、设计、实现、执行几个阶段。“计划”是作好人和时间的安排。“设计”确定采用什么样的测试方法，达到一个什么样的覆盖率标准等。“实现”是设计生成各个测试用例。“执行”包括驱动和桩函数的设计实现，测试数据准备，测试结果验证等等。

1.1.3    单元测试所遵循的原则

对于测试来说，我们应当尽早地和不断地进行软件测试。对于单元测试来说我们需要遵循一定的单元测试规范，根据公司CMM规范中的规定，我们列出了一些原则但是这些并不是足够的。

1.                 仅对全新的代码或修改过的代码进行单元测试

2.                 被测试的对象为实现一组相关功能的代码（一个或一组函数）

3.                 单元测试根据单元测试方案进行，排除测试的随意性

4.                 项目管理者保证测试用例经过审核

5.                 当测试用例的测试结果与预期结果不一致时，单元测试的执行人员需记录实际的测试结果

6.                 对被测试单元需达到的一定的代码覆盖率要求

7.                 当程序进行了修改，由测试执行人员执行回归测试以保证对发现错误的修改没有引入新的错误

测试技术组总结的《单元测试过程与结果验收指导书》在这方面给出了比较详细的说明，大家有时间可以看一下。

在做单元测试的时候有时会遇到这样一种现象：既设计人员在设计测试用例的时候或者在调试测试脚本的时候发现了详细设计或者代码中错误，并且改正了这些错误。因此在单元测试用例最后执行的时候发现的问题变少了。这不能表示单元测试的效果变差了。因为在单元测试过程中，通过单元测试方法发现的问题也是属于单元测试发现的问题。单元测试发现的问题不能局限于单元测试用例执行时发现的问题。

仅考虑被测单元的语句覆盖率并不是足够的。语句覆盖100%这是公司硬性的规定，但是不是除此以外我们就不需要兼顾其他覆盖率了呢？不是！有很多错误不是通过达到一定的语句覆盖就能发现的。我们还必须考虑一定的判定覆盖，条件覆盖甚至路径覆盖。一般来说要完全达到路径覆盖几乎是不可能的。但是我们可以考虑McCabe提出的圈路径或Z路径覆盖情况。

同时单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用 。单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。

在VV测试中有一个致命的弱点，也就是它把测试的阶段划分的太明显。其实在实际开发过程中你无法在时间点上严格的结束任何一种测试，因此说单元测试什么时候结束是没有意义的，如果一定要划分，我们可以认为我们的工作重点有单元测试进入另一种测试的标准。