自动化测试:为什么受伤的总是我?

发表于:2009-07-02来源:作者:点击数: 标签:自动化受伤
自动化测试 专家Elfriede Dustin在2008年10月的《Software Testing and Performance》杂志上发表文章,深入探讨了为什么如此多的自动化测试项目会最终失败。 1、IDT的自动化测试调查 IDT(Innovative Defense Technologies)在2007年进行了一次软件自动化测
自动化测试专家Elfriede Dustin在2008年10月的《Software Testing and Performance》杂志上发表文章,深入探讨了为什么如此多的自动化测试项目会最终失败。

  1、IDT的自动化测试调查

  IDT(Innovative Defense Technologies)在2007年进行了一次软件自动化测试的研究调查。调查研究表明:虽然很多公司都认为自动化测试是非常有用的,但是很少有公司真正成功地实施了自动化测试。在问及没有很好地开展自动化测试的原因时,大部分人回答是由于缺乏资源,例如:时间、预算、技术等,其中:

  ·37%认为缺乏时间。

  ·17%认为缺乏足够的预算。

  ·11%认为缺乏合适的工具。

  ·20%认为缺乏专家的技术指导。

  研发领域的技术在过去20、30年间得到了高速的发展。然而我们对这些技术的测试能力并没有跟上发展的速度。现实告诉我们,测试变得越来越重要。IDT研究测试技术多年,发现一些有趣的东西:

  (1)软件测试开始和软件开发一起驱动着业务。

  以前,业务驱动着软件和测试的技术发展。现在,软件和测试技术逐渐对业务起着驱动作用。业务部门可以有很好的业务idea,但是如果软件开发和测试部门不能很好地交付产品,或者测试能力有所欠缺的话,业务的竞争力会很快地消失。抢占市场的先机很重要,但是应该给予产品开发和质量保证更多的关注。

  (2)应该给予“感知质量”更多的测试

  质量过程和标准往往过于关注数据,例如出现了多少个Bug缺陷的密度等数据,而忽略了顾客的“感知质量”。例如,对于一个产品,频繁出现的10个缺陷,并且会影响到关键的功能运行,这往往会被顾客认为是一个低质量的产品,即使相对于整个项目而言,缺陷密度是非常低的。

  相反地,如果发布的产品中有100个缺陷,但是不经常出现,而且几乎不影响正常的功能操作,顾客则会认为这是个高质量的产品,即便从数据看来,其缺陷率非常高。

  到目前为止,并没有太多“基于使用的测试”的研究。“基于使用的测试”探索感知质量的内涵,追求高的感知质量,从而获得更高的顾客满意度。在 Elfriede Dustin看来,amazon.com相比起其他在线书店网站,拥有更高的顾客感知质量,因为amazon.com的用户体验非常友好。

  我们的目标是提高产品的感知质量。提高的途径是:让测试专注在那些最常使用的功能上(确保正常工作,没有任何缺陷),专注于测试那些最常用功能的可用性、可靠性

  (3)测试人员总是会受到责备

  Deadline临近,而在多种环境下的测试周期看起来是无止境的。测试人员通常会因为Deadline而受到责备,还会因为项目超出预算、没有覆盖产品的所有Bug、缺乏创新等,受到责备。

  但是,通常造成这种结果的真正原因是因为缺乏系统工程的过程。例如,对于一个上百万行代码、包含大量功能模块的产品,仅仅依靠测试组的黑盒测试,费尽九牛二虎之力才找到一些Bug。

  从另外一个角度来看,测试对项目进度拖延的真正原因是:不良的开发习惯导致充满Bug的代码,需要很长的、重复的修改周期。

  还有一个原因是:缺乏单元测试。调查分析表明:单元测试越充分、越有效,则系统测试会开展得越顺利,系统测试的周期也会越短。

  不能忽略的一个问题是产品构建。构建(Build)和发布(Release)的过程应该自动化。如果没有实现构建的自动化,那么软件构建的过程将会是非常浪费时间、并且容易出错的一件事情。

  另外,如果Deadline本身设置得就不合理,那么导致失败的可能性就非常大。有些Deadline的设置没有考虑清楚究竟需要多长的时间来开发和测试软件。

  (4)开发人员不做测试

  虽然已经有不少的开发人员采用单元测试、测试驱动的开发方式,他们确实做得不错。但是开发人员仍然缺少集成和系统方面的测试。开发人员往往倾向于关注自己编写的功能模块的问题,缺乏对整个系统的全局观。

  为什么开发人员不做一下系统测试呢?他们没有时间,他们不是专业的测试人员,他们缺少测试的技巧,他们忙着开发新的代码和功能,并且测试系统整合部分的代码不是他们的职责。

  开发人员疲于应付新功能的开发,以便满足那些不合理的Deadline。毕竟,大部分人认为抢占市场是很关键的。然而,事实证明,我们不仅仅要关注R&D,还要关注R&D&T。

原文转自:http://www.ltesting.net