单元测试概述

　　软件就像是一个由很多零件构成的整体，各部分零件分工合作以完成独特的功能。应对软件的这一特点，对软件的最小功能单元进行独立测试，诸如传统程序中的函数，或者面向对象编程中的类的测试，被称为单元测试。

　　软件的单元测试有以下几个特点：（1）是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总之，单元就是人为规定的最小的被测功能模块。（2）单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

　　由以上特点可以看出，单元对不同的软件定义不同，需要独立分析，其次，单元测试时最低级别的测试，且是各自独立的。从这两个特点看起来，单元测试无疑复杂而且繁琐，效率视乎很低，且程序间的函数或者类是无法独立工作的，各个功能单元之间必须协调工作才能完成软件的既定任务。那么，对于各个单元进行独立测试的单元测试是不是就没有必要呢？

　　事实上，再优秀的程序员无法保证自己的程序在编写过程中不出bug，即使通过了编译，也是语法没有问题而已，至于逻辑问题或者设计上的缺陷是无法再编译过程中检测出来的。而当程序员匆忙将各个功能单元进行整合后，层出不穷的bug将会给软件的后续修改造成极大的干扰，毕竟，在一个无比庞大的系统中寻找一个不知道出自何处的错误可比在一个小单元中寻找错误要难上千万倍。而完成了单元测试之后，我们可以自信的交付自己的代码，而没有任何的后顾之忧。

　　如何进行单元测试：

　　·构造最小运行调度系统，即驱动模块（Driver），用以模拟被测模块的上一级模块。

　　·模拟实现单元接口桩（Stub），即被测单元需调用的其他单元函数的接口。

　　·模拟生成数据或状态，为单元测试准备动态环境。

　　

　　孤立测试策略

　　·单元内的全局输入/输出变量测试（Driver）。

　　·单元内调用的函数（Stub）的接口测试。

　　·覆盖测试（语句覆盖/分支覆盖/复合谓词覆盖/路径覆盖）。

　　

　　单元测试中需要记住很多原则，包括：

　　单元测试前应该执行静态检查、代码走读。

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

　　被测试的对象为实现一组相关功能的代码(一个或一组函数) 单元测试根据单元测试的计划和方案进行，排除测试的随意性。

　　项目管理者保证测试用例经过审核(集思广益)。

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

　　当测试达到计划的结束标准时，单元测试结束。

　　对被侧单元需达到一定的代码覆盖率要求。

　　当程序修改后，测试人员要执行回归测试，以保证修改后没有引入新的错误。

 　　

　　其实我们经常在做单元测试。写完一个函数后，总是要执行一下，看看功能是否正常，这就是是单元测试。当然，这种单元测试时临时的。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率不高，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。也就是说，单元测试其实我们也经常做，但是做的不完整。对于追求高质量软件的程序员来说，单元测试是软件编写过程中必须经历的过程。