中国软件质量管理和测试工具的应用状况分析
 

2010-02-24 作者:青润 来源:it168

 

IT开发技术人员作为信息化技术的使用者、应用的规划者和实施者是中国信息化建设的中坚力量。2006年年末,IT168基于深蓝和企业信息化频道以及ITPUB的资源,开展了一次调研活动。

通过对软件开发过程技术应用的研究,以及对比在研究中所涉及的调查数据,可以看出国内软件企业的规范化程度正在不断提升,在开发过程中对软件开发辅助工具的使用也日益普及,但是,中国软件企业仍然有大部分处于原始开发状态,需要真正懂得软件工程技术和管理的技术人员、国内软件咨询技术企业的自我完善和成长。

中国的软件行业从上世纪八十年代末开始形成,到现在已经经历了将近二十年的时间,这二十年时间里,国际软件行业和技术的革新变化非常之大,我们不得不面对国际软件行业企业已经走过了几十年的历程和经验积累对我们产生的压力。

从下面的调查数据上我们可以看到中国软件行业的从业人员的努力与拼搏,但是,仍然有太多的地方是不如意的,也使得我们中国软件行业的从业人员不得不再次的深入思考,反省我们曾经的做法,规划我们将来的道路。

一组组的数据上到底说明了些什么问题,下面我们会在文中进行详细的分析和讲述。

本文中主要针对开发者的中国软件质量管理和测试工具的应用状况进行调查、分析。

1 开发者对代码质量管理的状况

图表:开发者对代码单元测试的频率分布状况

这个调查的图表显示国内开发者对单元测试的认可程度和实施状况,而每日、每周的单元测试居然合起来达到了81%,而每小时进行单元测试的比例只有6.6%,对比前面的数据中关于完全采用迭代化开发的比例为6.4%,我们可以看到这两个数据是何其得接近。

由于单元测试是随时进行的,而每周或者更长时间进行单元测试可以认为是单元测试执行的较为粗略或者很难达到实际的效果。对比前面的每小时进行集成的频度比例只有2.1%,而每日的集成频度也只有25.2%,我们也可以看到能够真正把单元测试做到位的开发者和企业比例还是十分少的。

从这个比例数上也可以看到国内软件企业与开发者对于测试仍然没有像对开发过程那样重视,甚至有接近10%的企业和人员从来不进行单元测试,这意味着我们的开发者和企业交付给用户的产品中之少有9.4%是几乎没有经过任何测试(如果没有做过单元测试,那么其他级别的测试效果也是可想而知的)就交付给用户的,而且从下面的调查问卷中也可以看到,单元测试是作为代码质量的最主要的保障手段而存在的。

图表:开发者保证代码质量所采取的方法分布状况

代码质量的保障包括上面提到的三个方法:代码走查、单元测试、提高代码覆盖率,此外还有同行评审、编码规范等措施和手段来进行。

而这里单元测试居然有超过一半达到了54%的比例来作为代码质量的保证手段,而从前面的问卷中我们已经得到的结论:目前国内单元测试的执行情况并不理想,甚至是相当得差。在这种情况下,我们如何才能通过单元测试来保证我们的代码质量呢?

其实单元测试是在功能层面上保证代码质量的手段,而在格式、可读性等代码规范化方面代码走查和编码规范都是十分重要的手段,这些手段却没有得到很好的实施。由此可见,我们的代码传承性,也就是代码的可读性和格式都是在开发者和企业并不关注的情况下进行的,这样的代码即使功能上目前达到了要求,又如何保证项目可以有后续版本的持续不断的开发和扩展呢?

软件开发者和开发团队对测试的轻视是自古有之的,这个“古”是指从最开始有了单独的成品软件出现开始。而且,这个“轻视”不仅仅在中国有,在国外也是一样的。但是,这种思想在个人英雄主义的时代曾经盛行一时,而当软件进入工业化时代的时候,大家开始逐渐意识到原来的开发状况出来的产品问题较多,于是对应于制造业的品质保障阶段,测试逐渐被重视起来。这个情况我们在后面的几个问卷中还会有更深入的讨论。

2 开发者对软件测试的方法和工具

图表:开发者测试团队对软件质量的测试周期分布状况

从这里可以看到测试周期的长度的比例,也可以看到测试的实际效果和企业与团队对测试的重视程度,从这里还可以看到测试人员与开发人员的比例关系。这里我们还是按照上面的四个阶段划分进行对比分析:

  • 每小时都进行测试

在传统模式下对于国内的企业和开发团队基本上只有进入测试阶段,也就是代码编写基本完成以后才会进行每小时的测试,所以,更多的人会选择时间较长的测试周期。

而每小时进行测试的方式是极限编程中提出来的测试策略,对比前面采用XP的42.5%的比例也可以看到这些XP过程管理框架的应用组织,实际上并没有很好的推行XP的核心关键实践。而这个数据比例与迭代思想已经被采用并比较彻底的6.4%(这个比例应该与相关参与者的数据进行同比折算)和系统集成频度为每小时的2.1%以及每小时进行单元测试的6.6%的比例都是十分接近的。

由此可见,国内测试能够将XP中的测试实践做到相对比较好的程度的组织的比例也就只有2%左右。

每小时进行测试的测试人员与开发人员的比例基本上是在1:1的状态下才能做到的。

  • 每天都进行测试

能够做到每天测试的有21.4%,这个数据说明了国内能够将测试作为软件工程活动的一个重要环节的比例系数,加上每小时进行测试的2%,可以认为国内现在基本上有接近四分之一的组织已经十分重视软件测试活动了。可以认为至少做到每天测试是软件企业和开发团队成熟的标志之一。

每天进行测试的测试人员与开发人员的比例基本上是在1:1到1:3之间的状态下就能做到的。

  • 每周才进行测试

每周才进行测试的52.3%说明这些企业或者开发团队所进行的测试不包括单元测试,基本上主要停留在系统测试和集成测试上。也就是说,这些产品并没有考虑代码的有效性问题,而只是从系统的表层进行了检查。这里就好像一个曾经很有名的笑话:外科医生给一个中“箭”的病人治病,只是把表皮上面的“箭”给剪掉的感觉。至于里面是否还有“箭”的剩余部分的残留,测试组是完全不管的。

每周进行测试的测试人员与开发人员的比例基本上是在1 :3以上就能做到的。

  • 每月进行测试

每月进行测试的24.3%的企业可以这样认为,他们根本就没有想过要做测试,甚至领导者会认为测试完全属于浪费时间,浪费资源的做法。他们可能根本就不会考虑团队内存在专职的测试人员。这也说明他们的项目管理完全出于混乱的状态,他们交付的产品也将是没有任何保障的。

同样的问题在下面的调查图表中也可以看到。

上图中的测试方式上的比例让我们对中国软件业的未来产生了更多的担忧,但也看到了一些希望。

占有29.2%的采用自动化的测试工具的比例已经远远高于前几年国内测试行业的状况,这个数据是令我们欣喜的。这也是国内在逐渐形成的对测试重要性的争论中,逐渐走出了一批高水平的测试人员积累的成果。而能够自己动手编写测试脚本进行测试的比例超过了半数,这也说明中国的测试团队已经形成了一定的实力。

但是,上面的三个数据却没有一个能够超过60%,可以说都不占有大多数,对比前面每月进行测试的24.3%的比例,可以看出国内还有40%(这个40%的比例可以从后续的几张图表中得到数据支持)以上的企业和组织根本没有认同测试,他们仍然处在最原始的软件开发状态下生存着。

图表:开发者及其团队经常使用的黑盒测试工具分布状况

MI LoadRunnner一直在国内的推动力度都是比较大的,在网站上可以经常看到关于LoadRunnner的问题和一些讨论。这方面Rational做得相对较弱,可能因为Rational将自己的核心宣传力量投入到了开发建模工具方面,而没有把测试作为最主要的切入点来考虑。当然,Rational的相关测试工具即使在没有很大的宣传力度的情况下,仍然占有相对较高的用户比例,这也和它在开发建模工具方面的影响力是分不开的。

我们可以看到有接近40%的开发者和开发团队没有使用过自动测试工具,这并不是很令人惊讶的事情,但是却有接近四分之一的开发者和开发团队没有听说过自动测试工具,这就很惊人了。没有用过,可能是因为自己周边没有人会使用,或者地域偏僻,或者没有学习到;但没有听说过,这个差别就说明中国国内软件企业和开发者在测试领域缺乏认知程度,同样的比例数在白盒测试上也是存在的。

当然,这也从一定程度上说明中国大陆还有着广阔的测试技术的发展和推广空间,这也使我们国家的教育业尤其是大学教育和职业教育在软件工程领域需要着重考虑并关注的重要着眼点之一。

图表:开发者及其团队经常使用的白盒测试工具分布状况

Rational旗下的两个工具居然占有了百分之三十左右的比例,这说明白盒测试方面其他公司所开发的工具的确是相对较弱的。白盒测试与黑盒测试不同,其技术难度和复杂度都要比黑盒测试要高很多。可以这样说,有能力开发白盒测试工具的厂商肯定能够推出自己的黑盒测试工具,而相反,则很难。

这里与黑盒测试中有着相似的比例关系,因此就不做更多的赘述了。

火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。

资源网站: UML软件工程组织