linkman 阅读(1088) 评论(3)

在两年以前,我写了一系列关于单元测试的文章,希望在公司内部的产品开发过程中,引进完整的单元测试,当单元测试工作推动起来后,我便停止了这方面的写作。前几天,与公司不同部门的同事谈起单元测试,很有一些感触,因此,又动了写单元测试文章的想法。

话题的起因是这样的,这位同事以及其他几位同位,正在全力开发一个全新的产品,团队人数不多,项目周期也不长,想在内部引入单元测试,因为觉得我部门单元测试的工作推动得不错,这位同事向我搬救兵,希望我部门给他支援一两个单元测试人员。问他打算如何推动单元测试工作,他的想法是,他和另一个核心开发人员全力编写系统,我支援的测试人员全力给他们做单元测试。

我当时问了他几个问题:

1、你们两个核心人员准备参与单元测试吗?

回答:不准备参与。

2、如果两个测试人员的测试速度跟不上两个核心人员的开发速度,怎么办?

回答:只测主流程和基础模块,不测分支流程和上层模块(也是非界面)。

3、测试人员如何理解拟测试的程序及模块?

回答:核心开发人员给测试人员讲解模块的功能,由测试人员自我阅读理解。

我当时这样回答那位同事:如果是这样,我建议你还是不要引入单元测试。

这样回答,不是给那位同事拨冷水,也不是不愿意支援两个单元测试人员,这两年,我们团队在单元测试的过程中,尝到了太多酸甜苦辣。回想这两年以来的产品开发工作,在我的强力推动下,单元测试工作推动得不错,取得了一些成绩,也发现了很多以前没有发现的问题。在这里将一些感受写出来,算是两年单元测试的总结吧。

总结1:如果项目团队的主要领导对单元测试的理论和技术不熟悉,一定不要引入单元测试。

总结2:当项目的开发周期紧,开发人员的投入不多,一定不要引入单元测试。

总结3:在项目的开发过程中,要只少有一位核心开发人员投入到单元测试,或者,每位核心开发人员至少要投入1/3的时间到自己所编程的单元测试中。

总结4:单元测试是一项长期的系统性的工程,启动容易,长期坚持难,对单元测试如何能够长期适应项目的变动,是单元测试中最难处理的事情。

总结5:当项目需求经常变化,或内核模块未达到一定的功能稳定期,不要贸然投入单元测试,否则,大量的单元测试工作会全部白做。

总结6:如果单元测试对被测试代码不能够达到一定程度的测试覆盖度,不如不做单元测试。

总结7:当代码的文档不全时,对单元测试人员的水平要求非常高,如果单元测试人员的水平不够,会编出很多无意义的单元测试用例。

总结8:同水平的单元测试人员与开发人员的数量如果不能达到1:1,不要引入单元测试,要使单元测试发挥效果,单元测试人员与开发人员的数量最好达到或超过2:1。

总结9:不要试图对第三方库、或历史遗留模块做单元测试;

总结10:不要迷信单元测试所得出的系统稳定性指标,再严格单元测试也不能完全保证系统质量,需要与模块测试、接口测试、集成测试等一并保证系统质量。

写了以上这些内容,并不是反对在项目中引入单元测试,只是希望那些对单元测试不太了解的团队,在是否要引入单元测试时,一定要慎重,否则,会发现投入了很多,产出却少得可怜。

事实上,我们团队已经在项目中尝到了单元测试的甜头,我们也希望在单元测试方面做得更好,我相信,经历过这两年的酸甜苦辣,我们有信心在单元测试这条路上走得更远。


评论列表
lostpencil
re: 关于单元测试的10点总结
我习惯在每个功能模块中都加入自动化测试脚本,这样单元测试基本就没有什么小毛病。由开发人员亲自或者指导测试人员编写,工作量也不大,而且好处很多
jzhang
re: 关于单元测试的10点总结
单元测试难道不应该都是有开发人员自己编写吗?还有专门的单元测试人员?
jxsccsb
re: 关于单元测试的10点总结
我们公司单元测试从来都是开发人员自己编写测试例自己测,我们公司是家超过8万人的大公司:)

发表评论
切换编辑模式