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

原创 2004年05月21日 13:17:00

思考可维护性

脚本维护的需求不是不需要,而是卖自动化工具的人没有提到这点而已。在二月LAWST会议上我们不停的讨论两件事。
当软件用户界面发生变化的时候,你们要做多少修改测试脚本的工作能让脚本正确适应软件的变化并测试软件?
当软件界面语言发生变化(比如英文版到法文版),修正测试脚本让他正确适应软件的变化并测试软件有多困难?我们需要的是处理版本变化的测试策略。

下边两种策略是不推荐的:
建立测试用例利用扑捉回访工具。最普通的方法是利用自动化测试工具的扑捉特性建立测试用例。这是最苯的。

编程第一课可能学习的不是写程序,例如:
set a=2
set b=3
print a+b

隐藏恒量是很傻的。但那对我们是最有用的。我们建立通过录制输入一定顺序键值,鼠标动作,或者命令的测试脚本。这些恒量如2,3。软件用户界面的细微变化测试脚本都会发生错误。简单朴捉回放的脚本对于维护是不接受的。扑捉回访的脚本的好处是帮助你展示怎么样把手工测试用例用自动化工具执行。他们也不是无用的,但是如果你做的脚本越多风险越大。

在特定基础上编写测试用例:测试团队经常在他们的业余时间创建自动化测试用例。他们的计划类似,“尽可能的创建测试用例“ ---- 没有统一计划和主题。每个测试用例设计编码都是独立的,这些脚本中总会有重复的命令序列。这同扑捉回访一样是不健全的。

成功的策略:

我们不用为使用这些工具的风险而哀叹。我们其中很多人已经在comp.software.testing和另一些出版物上做了很多。我们在这里是因为我们已经意识到在处理这些问题上一些试验建立了很有意义的过程。但是信息共享的还不够。一个实验对于另一个是先进的做法是显而易见的。现在在这个既是挑战的环境也是澄清每个人想法的环境里是收集大家的想法的时候了。

一些开发自动化衰退测试测试略的建议:

重新斟酌对于能从自动化测试中得到好处的期望。
承认自动化测试一种软件开发
利用数据驱动体系
利用基于框架的体系
考虑使用其他类型的测试工具

1.重新斟酌对于能从自动化测试中得到好处的期望

我们认可GUI级别的自动化衰退测试执行n次后的结果,如果继续进行这种测试,可能会发现更多的益处。我们都知道在软件发布N次之后开发GUI级别的自动化衰退测试脚本,才能在软件发布N+1次的执行中得到更多的好处。我想大家都很惊奇有这样的结论,因为我们曾经都听说过(或者经验)投资自动化测试的回报这样的理论。

软件发布n次后意识到的好处,例如:
自动化测试一系列验收测试(冒烟测试)用例有很大的好处。在开发第n版软件的时候你可能要运行这些脚本50到100次.如果开发每个测试用例是手工测试执行的10倍时间,另外花10倍时间维护.这样创建一个自动化测试用例的时间可以节省相当于手工执行测试用例30到80次.
    你可以节省时间,减少人为错误,总结怎样很好的跟踪自动化测试配置和兼容性测试所能做的。在这些案例里,你要在不同的环境下和设备下运行同样的测试。如果你和30个印刷工测试程序的兼容性,一周内你就可以重新得到自动执行测试的好处。衰退自动化脚本可以作为处理操作系统和处理不同的开发版本的基准。
    当自动化带有短期获利目的的时候,自动化很容易在近期中发生危机。价值证明每一个附加测试用例或者一组测试用例。
   如果你正在找寻找长期目标,处理软件版本,那么你要认真思考关于版本n的目标:
倘若在一些特定的阶段(比如冒烟测试和兼容性测试)中测试版本n。我们开发的脚本在软件版本n+1时将更加有效和强壮。

2.承认自动化测试一种软件开发

你不可能在还没有在下个版本还没有弄清楚和现实的计划前开发。
你不可能在还没有弄清楚和现实的计划前扩展测试脚本。
你不可能在没有弄清楚和现实的计划前开发出很多低维护成本的测试脚本。

软件自动化测试像其他软件开发一样需要时间,软件测试工程师需要编写自动化脚本代码。即使自动化脚本语言很难。如果决定用应用程序测试应用程序,那么每一个测试用例都有自己的特点。

 从自动化软件测试的观点来看,每一个软件(正在测试的软件)的界面就是数据。我们研究如此多的软件开发工程,软件开发者(在这个例子中,测试工程师)必须 :
 
了解需求:
接受一种有效的的开发方式,维护和集成软件的特点和数据。
接受和执行标准。(我们不必选择如iso或者cmm这样的配置管理,只要两个人可以利用命名规定,文档结构,处理错误等方式,在一个项目上合作工作就可以。任何组内成员都要遵守制定的规定和标准)

遵守规定:
所有的人,测试人员必须承认遵守近似于软件开发的方法代替quick-and-dirty的设计和执行方法有多么重要。没有他,我们必须有执行多少越多测试用例失败越多的心理准备。

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

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

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

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

robotframework ride + selenium grid自动化测试套件的安装与使用示例

1.安装Robot Framework RIDE以及Selenium2Library 1.1安装wxPython 1.1.1安装python-2.7.11.msi (x86版) 1.1.2安装wxPy...
  • wzp1986
  • wzp1986
  • 2016年01月15日 23:31
  • 3162

Fedora 19 Kdump 自动化测试套件的总体设计

本软件的设计思路为:定义
  • crookie
  • crookie
  • 2014年07月22日 10:48
  • 544

net自动化测试之道API测试-自动运行测试套件

Launching a Test Harness Automatically 自动运行测试套件 Problem You want your test harness program tolaun...
  • teaca
  • teaca
  • 2011年08月15日 22:46
  • 396

【翻译】如何写可维护性好的自动化验收测试

原文链接:http://cwd.dhemery.com/2009/11/wmaat,看完这篇文章感觉挺有用,纯手打勉强翻译个意思吧。 测试自动化脚本是软件开发 测试自动化脚本是软件开发.这个原...
  • be5yond
  • be5yond
  • 2017年01月30日 13:16
  • 163

net自动化测试之道API测试-确定测试套件运行的总时间

Determining a Test Run Total Elapsed Time 确定测试套件运行的总时间 Problem You want to determine the total el...
  • teaca
  • teaca
  • 2011年08月14日 22:54
  • 272

ISTQB AL-TA/TTA连载系列14:文档的可维护性测试

[概述] 可维护性测试,我们常常将重点关注在软件产品新增功能或者缺陷修改以后的产品动态测试上面,而文档的可维护性测试往往被遗忘在某个角落。 [正文] 可维护性指的是软件产品可被修改的能力,这里的...
  • Wenqiang_Zheng
  • Wenqiang_Zheng
  • 2011年11月06日 09:30
  • 1307

TestNG进行接口测试,脚本及可维护性框架

testng被普遍使用于基于java和spring的系统结构中,用于保证系统功能,本身testng的特点: 1.结构清晰 2.支持多种数据源 3.可与maven集成 4.环境/数据准备方便 可用于系统...
  • u010321474
  • u010321474
  • 2015年11月22日 15:10
  • 1967

如何提高软件可维护性

软件工程中把软件开发大概分了六步:可行性分析、需求分析、设计、编码、测试、运行与维护,在这几大部分中,维护占有重要地位,一般我们不想把大分分精力、财力花费在维护上,这就需要我们提高软件的可维护性。...
  • lilongsheng1125
  • lilongsheng1125
  • 2011年09月30日 20:20
  • 3213
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:提高自动化测试套件的可维护性 - 2
举报原因:
原因补充:

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