提高自动化测试套件的可维护性 - 1

原创 2004年05月19日 13:23:00

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

                                                作者:Cem Kaner

                                                翻译:piaocl

                    

   自动化黑盒测试,GUI级别衰退测试工具在当今很流行,根据这些神话,你的编程经验即使不是很丰富,也可以建立很强大的测试套件。这些工具(按照说明)很容易上手。维护测试套件不是问题。因此,神话继续上演,用这些测试工具之一替换掉那些讨厌的软件测试工程师,开发管理者可以节省大量的金钱和负担,使软件很快正常运行。

 

 测试软件的卖主,不懂测试的主管极力推广这样的神话,甚至那些测试经理,测试工程师也这么认为。认为使用测试工具多么好。

 

一些公司已经开始享受成功给他们带来的好处,但是另外一些公司由于没有有效的使用测试工具,失败了。

 

二月,十三个富有经验的软件测试工程师在LAWST聚会两天,讨论成功的模式和测试套件用于衰退测试阶段的黑盒测试脚本的可维护性失败的教训。我们讨论的重点集中在实际经验,以哪些已经在实际中部分有效的解决自动化问题的方案开始。我们的目标是在有限的经验下,在短时间内总结出一套有效的的过程。为了提高的效率,我们在富有经验的-- Brian Lawrence(会议的主持人) 带领下展开讨论。

 

其他参加者: Chris Agruss (Autodesk), Tom Arnold (ST Labs), James Bach (ST Labs), Jim Brooks (Adobe Systems, Inc.), Doug Hoffman (Software Quality Methods), Cem Kaner (kaner.com), Brian Lawrence (Coyote Valley Software Consulting), Tom Lindemuth (Adobe Systems, Inc.), Brian Marick (Testing Foundations), Noel Nyman (Microsoft), Bret Pettichord (Unison), Drew Pritsker (Pritsker Consulting), 和 Melora Svoboda (Electric Communities). 所以的与会者只有一个目的, 表达了个人的观点,不受公司的观点的束缚。

 

下边列出其他与会者的测试经验:

问题是什么?

自动化衰退测试中有很多缺陷。我只列出了一小部分。James Bach(与会者之一)在"Test Automation Snake Oil“中列举出其他很多问题。

 

通过范例举例:

这是个在衰退测试中基于GUI的自动化范例    

设计测试用例,然后运行他

如果这个脚本运行失败,你将写个bug报告,赋予缺陷状态为fixed,然后从新开始。如果这个自动化脚本运行成功,并功能正确。在此运行测试脚本(或者来自于某个脚本,或者来自于某类捕获工具)。在测试后抓取屏幕文件输出,保存测试用例和这个输出文件。下次对比输出文件和这个保存的输出文件,如果一样,那么脚本运行成功,测试通过。

第一个问题:这样做不划算。创建,验证,编写自动化测试脚本和手工创建执行测试一样要花费3到10次甚至更多(直到成功为止)。很多测试人员愿意自动化,但是对于测试人员来说,只运行一次脚本,那么这种效率就很低下了。

很多测试人员建议百分之百自动化测试用例。我强烈不同意这样的要求。我创建的很多黑盒测试用例只执行一次。要把每一个测试用例自动化,我要花费很多时间和金钱。利用这些时间我可以执行很多测试测试用例。为什么要低覆盖高成本的测试呢?

 

第二个问题:这个方法有附加的风险存在.我们知道发现,修正缺陷的成本会随着时间的增长而增长。随着产品越来越接近出货日期人们做的工作就愈多, 作为试用版用户要编写手册和买卖原料. 越后来发现修正重大缺陷越多的人的时间将被浪费。如果你在测试时间前花费大量时间写测试脚本, 你知道最后才发现缺陷, 这是非常昂贵的。

 

第三个问题: 这些测试不够强大. 执行了自动化测试的这些测试已经通过。但是通过这种方法你新的缺陷能发现多少?据我听说的评估大概在百分之六道三十之间。这个数字在你创建测试用例发现缺陷的时候是呈增长的趋势,这仅仅是手工测试,和自动化测试没有关系。

 

第四个问题: 实践,很多测试组织仅仅是简单的运行脚本。测试前期, 简单的设计和程序不可能运行更多复杂的测试用例。稍后, 虽然, 这些测试很简单, 尤其与有经验的测试人员相比这就是无用的测试方法。

 

如何提高代码可读性、可维护性

高质量代码的三大要素: 可读性、可维护性和可变更性 做好代码规范、提高代码质量,能显著增强代码的可读性、可维护性和可变更性。努力提高代码的读写可维护性,是做好代码规范的必要非充分条件。代码规范和架...
  • zm1_1zm
  • zm1_1zm
  • 2016年07月21日 16:05
  • 2891

JUnit自动化单元测试(四):@RunWith测试套件运行器的使用

一些常用的测试方法前面已经说了,但有人又说了,JUnit为项目里每个类都创建一个对应的测试类,虽然一次能把类里面所有的方法都测试一遍,但是,我一个项目有可能有上千百个类,总不能每个类都点一下进行测试吧...
  • u012882327
  • u012882327
  • 2017年05月23日 14:20
  • 323

软件的可维护性问题知识与分析

前言        很多包括自己在内的开发人员都会经常去借用(我们不用剽窃这个词了!呵呵)开源代码进行二次开发;或者在前辈的遗留代码下,继续修修补补。这种经历往往并不像看起来那么简单——有时看懂,进...
  • huwei2003
  • huwei2003
  • 2014年08月22日 16:28
  • 4094

保持应用系统可维护性的八个实际措施

应用系统的可维护性: 整体组织;逻辑分割;细粒度措施;技术决策; 一致处理;有效隔离;消除重复; 对维护敏感...
  • shuqin1984
  • shuqin1984
  • 2013年09月03日 18:00
  • 3679

学习使用Robot Framework自动化测试框架(二)——简单测试例子

上篇文章介绍了Robot framework的环境配置与安装,这一篇介绍如何使用RIDE创建并执行一个简单Web测试用例。 1. 新建一个project,Type选择Directory,Format...
  • u012145166
  • u012145166
  • 2015年12月01日 17:35
  • 4705

2、测试套件与自动化测试

1、目录删除的测试 目录删除类 import java.io.File; public class DeleteAll { public static void deleteAll(F...
  • kaoa000
  • kaoa000
  • 2013年02月17日 13:04
  • 440

spring测试套件

一、会用Spring测试套件的好处 在开发基于Spring的应用时,如果你还直接使用Junit进行单元测试,那你就错过了Spring为我们所提供的饕餮大餐了。使用Junit直接进行单元测试有以下...
  • zheng0518
  • zheng0518
  • 2015年04月03日 16:59
  • 1188

关于自动化渗透测试的理念

2014年BlackHat大会上发布了一款名为Heybe的工具,Heybe是一款包含多个模块的自动渗透测试工具。据称,Heybe可以在几分钟内完成对目标公司所有系统的测试。 Heybe包含的模...
  • Richard_LEE_
  • Richard_LEE_
  • 2017年04月09日 15:38
  • 278

初尝phpunit进行接口自动化测试

年初一个偶然的机会接触到了phpunit,一个用PHP编程语言开发的开源软件,也是一个单元测试框架,有效利用的话可以大大提高接口遍历的效率。废话不多说,直接干货。 1.安装 在php的目录下 p...
  • u010011940
  • u010011940
  • 2017年01月09日 18:20
  • 2022

(selenium 五)unittest通过测试套件组织用例

语法点: 1、implicitlyWait() 不是休眠,是设置超时时间,是每个driver自己去实现的。以IEDriverServer为例,implicitlyWait()会将一个超时的时间阀值...
  • fanxiyanhong
  • fanxiyanhong
  • 2016年06月02日 09:03
  • 2639
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:提高自动化测试套件的可维护性 - 1
举报原因:
原因补充:

(最多只允许输入30个字)