技术开发 频道

如何推广单元测试

【IT168 技术文章】

    软件企业对于单元测试的执行情况可以划分为4类:

  (1)不做单元测试

  (2)组织级要求了开发人员做单元测试,但是开发人员在做单元测试时,测试用例仅覆盖了程序中的正常路径,基本上是一个函数只有一个单元测试用例

  (3)组织级要求了每千行代码必须有多少个单元测试用例,一般是在50个/KLOC到100个/KLOC之间。

  (4)要求语句覆盖与分支覆盖必须达到100%。

        其中(3)、(4)两种情况基本上都是在对日外包的企业中,是日方的客户要求软件开发商必须达到上述要求。

        对于(1)、(2)类的客户要想真正的将单元测试在公司内推广起来,需要从下面3个大的方面着手:

    1 人员

   (1)选择一个推广单元测试的负责人

        对该负责人的基本要求:

        对单元测试理解比较深刻,做过开发和测试

        具有比较好的沟通与管理能力

   (2)改变开发人员及项目经理的思想认识

        大部分开发人员对单元测试存在排斥心理:

        工作量太大,认为得不偿失;

                       编写测试用例

                       准备测试数据

                       覆盖率分析

        工期太紧,没时间做;

        还要学习单元测试工具,麻烦;

        不符合以前的工作习惯。

        改变思想不是1、2次培训可以解决的,需要在实践中逐步改变。改变其思想的主要手段有:

        培训:要充分准备,让开发人员意识到单元测试是有帮助的,单元测试并不复杂。可以是内部讲师培训,也可以外来讲师培训。外来的和尚好念经,公司内部从上到下会比较重视,内部的员工熟悉公司的业务比较容易结合实际。

        试点:要找试点项目,通过试点项目的实例来证明单元测试的有效性,如果选择了试点项目,需要推广测试的负责人花费比较大的精力去指导该项目的试点,确保成功

        行政命令:公司定义相应的考核制度,通过考核约束。考核的力量也是无穷的,考核的制度代表了公司的价值观。

   (3)树立单元测试的模范人物

        任何一项措施,在企业里有反对者也会有支持者,要善于发现支持者,团结支持者,有的员工可能自己已经朴素的实践了单元测试,要树立单元测试的典型人物,榜样的力量是无穷的人,让一个人影响几个人,让几个人影响一群人。

   (4)改变领导的思想

        领导的思想问题在于没有意识到单元测试的重要性,认为只要做后交付前的系统测试就OK了。对于领导要以事实说话、以数字说话、以标杆企业的非常好的实践说话,让领导认识到单元测试的重要性,让领导认识到公司的差距,让领导认可定义的关于单元测试的规章制度。相比而言,领导的思想比开发人员的思想好转变。

    2 技术

        人员问题是第一位的,解决了人员问题,接下来要解决技术问题。要让开发人员比较容易的实现单元测试,此时要从2个方法入手:

   (1)工具

        单元测试的公司有多种,有开源的也有商品化的,为了获得领导的支持,提高投入产出比,可以先采用开源的工具。开源的工具一般比较简单实用,宜于上手。

        在引入工具时,最好是提供关于单元测试工具的整体解决方案,包括:单元测试框架、静态分析工具、缺陷跟踪工具等。这些工具集成在一起,能够极大的提高开发人员的效率。为了工具的集成,需要在推广的前期投入人力资源去探索,当然如果有热心人自告奋勇的去研究那将是很幸运的。

        对于工具的使用,需要经常将有关人员使用工具的经验教训收集起来,整理出来,形成知识,在公司内进行发布、推广。

   (2)方法

        单元测试的方法其实最主要的是测试用例的生成方法。教科书上的方法与实践中还是有些差距的,实践是“不管白猫黑猫,带住老鼠就是好猫”,实践中一般是先对被测单元的入口参数进行等价类划分、边界值分析以生成测试用例,然后再考虑单元内部的实现逻辑进行覆盖率分析以生成测试用例。

    3 过程

        在进行单元测试的过程定义与相关的规范定义时应把握一个基本的原则:“先松后严,形成闭环”。即,在推广的初期,要求可以没有必要那么深入,可能是先要求大家做测试用例,然后再要求测试用例个数,再要求的覆盖率等等。但是定义了制度就要检查,要落实,要确保制度的执行。

        单元测试是由开发人员自己来进行的,过程的定义要简单,只要把握几个关键点就OK了:

   (1)是否写了测试用例?

   (2)测试用例是否达到了组织级要求的个数?

   (3)测试的缺陷是否记录了?

   (4)是否自我分析了缺陷的原因、类型及分布情况?

        测试驱动的开发方法提倡在编码之前写测试用例,这种实践可以很好的预防错误,值得尝试。上述的4个关键点中开发人员就不愿意做的是测试缺陷记录,最容易忽略的是缺陷的分析。自己的BUG,自己改,出了错就去修改,不愿意记录下来,认为耽误自己的时间,没有什么用途,如果开发人员自己分析了自己缺陷的原因、类型等分布情况,可以发现自己的弱点,在以后的开发过程中改进之,实现自我的提高。子曰:君子日三省其身。不反省,就不能天天向上。

        单元测试和同行评审一样,都是很简单的质量措施,但是推广的时候却会有很多的具体问题和阻力,需要从公司建立起这种文化,让开发人员形成这样的开发习惯,才能充分发挥其作用。

0
相关文章