一、单元测试的意义

　　单元测试会为我们的质量做保证。编写单元测试是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。

　　我们在编码时，一定会反复调试保证它能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给Boss。但代码通过编译，只是说明了它的语法正确；我们却无法保证它的语义也一定正确，没有任何人可以轻易承诺这段代码的行为一定是正确的。

　　从成本角度考虑，BUG发现越早越好，加强单元测试力度有利于降低缺陷定位和修复难度，从而降低缺陷解决成本，同时加强单元测试也减轻了后续集成测试和系统测试的负担。据业界统计，如果一个BUG在单元测试阶段发现花费是1的话，到集成测试变为10，到系统测试高达100，到实际推向市场量产后高达1000，所以，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。但单元测试在目前国内软件企业中开展得并不好，一方面是由于对单元测试重视程度不够，测试投入不足，另一方面是由于在单元测试实践方面积累得也不够，单元测试处于一种摸索状态。

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

　　单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交单元测试代码。测试部门可以对单元测试的过程以及结果作一定程度的审核，作为集成和系统测试准入的一种标准。

　　二、如何做好单元测试

　　1）组织结构应该保证测试部门参与单元测试

　　目前普遍都认为单元测试应该由开发人员开展，这是因为从单元测试的过程看，单元测试普遍采用白盒测试的方法，离不开深入被测对象的代码，同时还需要构造驱动模块、桩函数，因此开展单元测试需要较好的开发知识。从人员的知识结构、对代码的熟悉程度考虑，开发人员具有一定的优势。

　　单元测试由开发人员进行能带来一些特别的收益。我们知道，在实践中开发人员进行单元测试一般推荐采用交叉测试的方法，例如由被测单元的调用方进行该单元的测试，即尽量避免对自己的代码进行单元测试。这种交叉的测试安排可以避免测试受开发思路影响太大，局限于原来的思路不容易发现开发过程中制造的问题；二来也达到一个技术备份或充分交流的目的，这对组织非常有利。即使不采用交叉测试的方法，而安排单元的生产者自行开展单元测试，也是有很大的优越性的，其大的优点是快速。在人员紧张的情况下这种自行测试的安排也是不错的选择。

　　从经验值来看，单元测试投入和编码投入相比基本上是一比一，如果由专职测试队伍来进行单元测试，维持这样庞大的单一任务队伍显然是不合适的，对于一般企业来说也是不小的成本负担。

　　以上谈的是由开发人员进行单元测试的优点，其中主要是从单元测试的效率角度来考虑。但是从单元测试效果的角度考虑，必须从组织结构上保证测试部门参与单元测试，这是因为：

　　首先，从目前国内企业普遍现状来看，测试人员质量意识要高于开发人员，测试人员参与单元测试能够提高测试质量。

　　其次，对被测系统越了解，测试才有可能越深入，测试人员参与单元测试，将使得测试人员能够从代码级熟悉被测系统，这对测试人员后期集成测试和系统测试活动非常有帮助，会很大的提升集成测试和系统测试质量。

　　测试部门以何种方式参与单元测试，应该结合软件组织的实际情况来定。如果软件组织测试充分，测试人员对开发人员的比例较高，那么可以由测试人员独立承担部分重要模块的单元测试工作；如果测试资源不足，测试人员对开发人员的比例较低，那么可以采取由测试人员进行单元测试计划、单元测试设计的工作，而单元测试的实现和执行由开发人员来完成；而如果测试资源非常缺乏或测试人员素质不够全面，连单元测试计划、单元测试设计都无法承担，那么测试部门至少应该参与开发过程的各相关单元测试文档、单元测试报告的评审，保证单元测试的质量。