前言
单元测试是对软件基本组成单元进行的测试,是属于白盒测试的范畴,它主要通过对代码的逻辑结构进行分析来设计测试用例。在动态测试手段中,单元测试是一种非常高效的测试方法,并且是软件测试周期中第一个进行的测试。从成本角度考虑,缺陷发现越早越好,加强单元测试力度有利于降低缺陷定位和修复难度,从而降低缺陷解决成本,同时加强单元测试也减轻了后续集成测试和系统测试的负担。根据业界的统计,一个 BUG 在单元测试阶段发现花费是 1 的话,到集成测试就变为 10 ,到系统测试就高达 100 ,到实际推向市场量产后就高达 1000 。但单元测试在目前国内软件企业中开展得并不好,一方面是由于对单元测试重视程度不够,测试投入不足,另一方面是由于在单元测试实践方面积累得也不够,单元测试处于一种摸索状态。
软件的质量由组织、流程和技术三个维度来决定,任何一个维度都不能单独决定软件的质量。好的组织结构可以保证流程的顺利实施,好的流程能提高软件开发的规范性和可控性,从而提高软件开发的效率和质量,而采用了好的技术和有好的技术的载体 —— 人,则从根本上保证了软件的质量。
总而言之,组织、流程和技术是软件质量三角,本文将从这三个方面对如何做好单元测试进行论述。
• 组织结构应该保证测试组参与单元测试
目前无论是工业界还是学术界都认为单元测试应该由开发人员开展,这是因为从单元测试的过程看,单元测试普遍采用白盒测试的方法,离不开深入被测对象的代码,同时还需要构造驱动模块、桩函数,因此开展单元测试需要较好的开发知识。从人员的知识结构、对代码的熟悉程度考虑,开发人员具有一定的优势。
单元测试由开发人员进行能带来一些特别的收益。我们知道,在实践中开发人员进行单元测试一般推荐采用交叉测试的方法,例如由被测单元的调用方进行该单元的测试,即尽量避免对自己的代码进行单元测试。这种交叉的测试安排可以避免测试受开发思路影响太大,局限于原来的思路不容易发现开发过程中制造的问题;二来也达到一个技术备份或充分交流的目的,这对组织非常有利。即使不采用交叉测试的方法,而安排单元的生产者自行开展单元测试,也是有很大的优越性的,其最大的优点是快速,且能更好的实现 “ 预防错误 ” 。在人员紧张的情况下这种自行测试的安排也是不错的选择。