自动化测试是一个独立的项目吗?

发表于:2012-4-23 11:33

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:油炸小朋友 等    来源:51Testing软件测试网原创

  摘要:如果由指定的团队负责自动化测试,亦或者自动化成员把它作为一个单独的项目工作,那么自动化测试将会成为一个令人头疼的事。在这篇文章中,丽莎·克里斯宾继鲍勃·琼斯之后呼吁需要整个团队来进行自动化测试并详细阐述了将自动化测试归为独立项目而不是纳入整个软件开发过程的危险性。

  最近我读到一封关于“失败的自动化测试项目”的电子邮件。邮件所阐述的内容让我不得不停下来思考。不同类型的自动化测试是软件开发的一个组成部分,这不仅是对于敏捷型开发团队而言。早在20世纪90年代时期,我曾为waterfall shop工作过。那里的程序员对其所有的单元测试都进行自动化,并且在持续构建中运行自动化。我的测试团队在每一个项目中,都是从一开始就参与进来,并持续到结束。我们不仅对图形界面级别的功能测试执行自动化,也对性能和负载进行自动化。我们的产品在生产中没有发现重大的错误。

  很多人仍然认为自动化测试一定要自动化测试专家才能做并且QA应该是一个独立的团队,甚至在敏捷项目中,对此我感到很失望 。我想如果每个软件团队在 “自动化测试项目”条款中停止多想,他们将受益匪浅。

  为什么要进行自动化测试?

  我们进行自动化测试,以帮助我们的团队维持技术费用在可控的水平,从而让团队保持合理的步伐。我们进行自动化回归测试,以缩短新代码的嵌入和发现回归失败之间的反馈周期。我们对负载和性能测试进行自动化,因为的确没有其他方法可以用来做这些类型的测试。在建立探测性测试场景时,我们自动化执行重复的步骤以节省时间。我们根据不同的测试目的,自动化产生测试数据。

  这都是些必要的工作。这对及时地交付高质量的且具备商业价值的软件,是必不可少的。这些“工作”避免了带来致使团队了无生趣的繁重任务以及单调乏味的键入工作。

  项目相关问题

  由于“自动化测试”这个术语中包括了“测试”一词,管理者认为自动化测试应该让测试员来做。他们购买一个图形化界面的测试工具,这种工具通常具备“记录和回放”的功能,然后给QA部门安排一个将所有手动回归测试自动化的项目。或许,他们期望一旦这些测试自动化了,那么他们将不再需要麻烦的QA部门。

  一些公司会组建一支由测试人员组成的,致力于自动化测试项目的团队。毕竟,公司购买了测试工具,他们认为工具如此简单,任何人都可以创建自动化测试脚本。

  在这样的情况下,如果这些团队确实进行了自动化测试,那么他们的测试很可能只停留在图形界面级别。创建测试脚本的测试人员很可能只有极少甚至没有编程经验。他们并不熟悉代码设计模式,比如“一次且仅一次”,以致测试代码里满是重复代码。而测试工具是不可能为测试脚本提供具备良好的代码设计。故这些测试脚本都是不友好、难以维护的。

  我曾听说过有些测试团队,他们拥有几十万行不再使用的测试脚本。我还遇到过其他团队里的测试人员花费100%的精力去更新测试从而保证他们可以通过一系列的一体化进程。这是一个失败的投资,不仅增加了技术费用,甚至减慢了开发过程。

  ……………………

  查看全文请点击下载:http://www.51testing.com/html/56/n-811856.html

  自动化与良好的投资回报率

  在整个团队的合作下,大家一起为他们的测试工作寻找恰当的方法、规范及风格。然后,他们找出相应的驱动程序、框架,或者是能实现他们要求的其他工具,又或者由他们自己进行编译。整个团队在不断摸索,直到他们找到他们认为最适合的。

  自动化测试是一个巨大的投资。正确使用的话,可以长期保持低技术成本和缩短开发反馈周期,从而获益。所有回归测试的自动化可以让软件测试人员腾出手来做更有价值的工作以帮助提供尽可能好的软件。

  下面是一个例子

  2003年,我的团队承诺,我们将会尽我们的一切努力去做出最优质的软件。为了实现这一目标,我们采用测试驱动开发,依据实际制订规范,并且整个团队在所有阶段都会采用各种类型自动化测试方法进行测试。开始的一年很辛苦,但我们不断改良了我们这样年来一直使用的自动化测试。这让我们在保持低技术花费的同时又快又好的实现了新的产品功能。

  最近,我们希望在我们的web应用程序中使用Dojo代码,但我们现有的GUI测试工具不支持它。作为一个团队,我们需要集思广益解决这个问题。最后,我们的系统管理员提出一个由一个开源驱动器程序和一个自主开发的框架构成的解决方案。他把这个方案上交给我们的首席架构师,首席架构师提出了一个具有相同的驱动程序和开源框架的解决方案。整个团队商议结果并选择一个方法实施。我们把这个作为一个用户实例,编制预算时间进行试验。显然,这是一个需要整个团队合作的用户实例。

  别把自动化测试做成了一个项目

  对于自动化测试带来的挑战,我们不可能逃避。如果我们不把自动化测试当成一个独立的项目,那些可有可无的事情也许或者根本就不会发生,那么我们就可以成功的战胜这些挑战。相对致力于自动化测试而言,我们更应该专注于持续不断地提供更高质量的代码。

  自动化测试并不是目的的本身,而是为了可控的技术花费,高质量的软件,以及享受尽情工作带来的乐趣。就自动化测试而言,越来越多的团队意识到测试不是一个单独的阶段,而是整个软件开发的一个组成部分。应该站在把测试和编码作为一个整体的两部分的角度来考虑,随时注意团队前进到哪个环节。

  本文出自油炸小朋友/寵、纤宝儿/小狐狸/Winnie翻译

  查看全文请点击下载:http://www.51testing.com/html/56/n-811856.html

  版权声明:51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。

《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • dnsdeier
    2012-4-24 10:50:49

    懂了好多

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号