单元测试

估计对于小白来说，一提到单元测试就是开发、开发、开发，好深奥、好难。但是我想说，单元测试可能是所有测试中最简单的了，想反系统测试可能是最难的，只是所谓的开发门槛让测试人员有些抵触而已。

为何说单元测试是最简单的内容呢，我们先来看一个例子：

有一个人去医院看病，然后医生问了一下病况后直接让你先去抽血，根据抽血的结果告诉你你是感冒了，给你开了一些感冒药。在这个情况下你觉得医生有多少的技术在里面？

另外一种情况，还是去医院看病，病人刚进来还没说话，医生就已经准确的说出了病人的病情和对应的诊疗手段，这个时候你会觉得医生有多少技术在里面？

在上面这个例子中，抽血化验就是一种单元测试手段，通过对血液成分来判断你体内病毒和相关指标是否正常，从而确定病因；而后一种的望闻问切就是通过系统表面的现象来判断病因，相对来说通过系统表面来准确判断所需要的能力需要高很多。而血液成分在早期会比较复杂，因为涉及到各种试剂和观察，而现在有了大型医疗设备，血液分析只要几分钟就能完成了，软件也是如此。

曾经单元测试是以静态扫描为主的方式来实现的，需要专业的人员通过仔细的阅读、调试代码来实现的，单元测试的成本高、时间长，而现在有了很多辅助甚至自动化工具，其难度也大大下降。

那么单元测试到底是怎么回事呢，下面从两个方面来说一下单元测试的要点：

覆盖率

由于单元测试是从代码级别对软件质量进行保证的，单元测试无法验证业务级别的内容，只能通过覆盖率来评估质量。

对于代码的覆盖率常见的无非是：语句覆盖、分支覆盖、条件覆盖、路径覆盖等，这些概念其实本身都不是非常的复杂，而且有很多工具可以支持测试时直接帮你计算覆盖率，所以现在做单元测试用例的代价就会比以前小很多。

通过工具可以做到很高的覆盖率，但是就算代码本身没有什么问题，也不能保证做出来的软件是正确的，所以单元测试从技术上来说有一些要求（编程），但是从业务上要求很低，而如果希望在单元测试上做出点成绩来就需要对业务熟悉点，能够从业务级别来生成合适的单元测试用例，弥补简单覆盖率所带来的思维定式。

覆盖率计算常见的有eclemmla、eCobertura，这两个工具都可以在你单元测试中完成对被执行部分的覆盖率计算并且提供对应的报告。

驱动及桩

驱动和桩是单元测试中的两个基本概念。所谓的驱动就是调用被测对象的代码部分，而所谓的桩就是为了满足代码需要运行起来所存在的一些支撑代码部分。为了达到覆盖率，驱动是比较简单开发，但是也是比较难于准备的。准备的复杂点在于如何对代码方法完成正确的调用，并且有效覆盖对应的代码，所以驱动部分一般会和数据驱动部分在一起。

所谓的数据驱动就是在传统驱动的基础上提供一个数据源，然后依次遍历这个数据源实现一个驱动的多次不同调用，从而提高代码维护度。

从某些角度来说驱动是比较好写的，因为只要知道怎么调用被测对象即可，而设计调用方法的数据受到覆盖率的影响需要一些设计。

而比较复杂的是桩，因为桩是用来替代没有实现的部分，让代码可以运行的“伪装”，而桩又需要根据驱动来完成对应的分支支撑，所以写桩的要求会高很多。

对于驱动部分大家可以考虑使用testng来支撑，而桩部分EasyMock,Jmock和JMockit都是可以考虑的部分，这些东西对于测试人员来说其实不是很重要，因为，单元测试的驱动和桩大部分都应该是开发人员完成的，测试人员只需要支撑一下驱动用例设计部分即可。

而在大多数公司单元测试会因为开发人员的习惯问题，并无法有效的开展，从而导致到系统测试部分，经常会遇到莫名其妙的数据错误，其实有些时候就是因为单元测试并没有有效的验证一些逻辑数据计算导致的。

上面说到的都是偏功能部分的，其实非功能部分也有很多，例如安全和性能，这里就不多提了。

单元测试始终是走在需求之后最前端的测试，所以能在这个阶段发现越多的问题，对项目后期会带来很大的帮助，但是基于能力和意识问题，这点大多数情况都没法做到位。

最后简单总结下在单元上可以推荐的工具（基于JAVA方向）：Findbug、DBunit、junit、Testng、eclemmla、eCobertura、EasyMock,Jmock和JMockit；前端的JS单元测试和数据库单元测试也是大家可以思考的。