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

原创 2004年05月21日 18:08:00

 

在你创建的库中很多函数可以在几个应用程序中用(或者你把他们设计得很灵活)。不要期望百分之百的灵活。比如openfile函数的一个版本中可能对每个用到标准文件对话框的程序都有用,但是你有些时候你要用到的是附加其他功能的自定义对话框。

框架中包含几种类型的函数,根据应用程序简单包装的函数或者使用处理一个集成任务的复杂脚本函数。下边是一些基本的类型:

a.  定义每个应用程序的功能特征

你写一个菜单选择的函数,下拉菜单,设置变量值,或者发布一个命令。如果UI的其中一个功能发生变化,你只要改动函数功能就可以了。当重新编译连接后,任何用到这个函数的脚本自动更新。

 

框架的本质是当处理自定义控件时,例如自画控件。自画控件就是程序员用画图命令画对话框。自动化测试工具知道那里有个窗体,但是它不会知道内部怎么样。当他不知道那里有个按钮的时候,你如何用工具点击对话框中的按钮呢?当你不知道那里有个listbox框在那里的时候,你如何用工具选择列表框中的选项呢?你可能应用一些技巧选择列表中的第三个选项,但是你如何选择一个在任何位置变长的列表中的项目呢?跟着的问题是:当你决定重新录制的时候,你怎样处理一般不显示的按钮和列表框和其他一些界面元素呢?

   

lawst会议上,我们讨论了如何把想法组合在一起。一些与会者都证实大概有一半自动化开发的时间在处理自定义控件的问题。

组合这些想法是复杂的,维护量很大,对于脚本开发者来说是分心的事情。我认为他们分心的原因是自动化工具问题带来的而不是测试脚本程序的问题。他们把测试人员的焦点转移在工具的缺点上了,而不是在发现和报告程序潜在的问题。

如有你坚持用自画控件,压缩你程序的每一个功能可能是你框架中最紧迫的任务。隐藏每一个组装的函数。用哪个特性,编程人员就调用那个特性,不用考虑组装的函数。如果UI界面变化,组装函数不用影响脚本的情况下重新编写。

 

b.定义命令或者测试工具语言的特征

   自动化工具有自己的脚本语言。你可能发现把每个命令封装到一个间接的层里面很困难。封装函数是把其他函数封装在里面。简单例子是,仅仅调用一个封装的函数。你可以修改封装函数,添加或者修改功能解决测试工具的缺陷,或者增强脚本语言的优势。

   

    Tom Arnold提供wMenuSelect的例子,一个Visual Test选择菜单的函数。他封装了SelMenu函数,SelMenu就是简单调用了wMenuSelect函数。这很灵活。比如你可以修改SelMenu函数,添加日志函数或者错误处理或者内存监视功能,你可以想到的任何功能。添加功能后,每个脚本不用添加任何代码就可以获得新的特性。这很适合压力测试,执行结果分析,错误分析,还可以达到报告和调试的目的。

   用到这个方法的与会者说这样做可以重复使用。

 

c.定义小的,概念性的频繁做的统一目标

    openfile函数是这种类型函数的简单例子。脚本开发者写成千上万个要求大打开文件的脚本,只要关心在这些脚本中打开的文件怎么样就可以。对于测试来说,它就像文件快速打开,完成他测试的目标。写一个库函数可以节省脚本编写时间,改进脚本维护的质量。

这是代码中重用最简单方法,不管在测试自动化开发还是其他软件开发中都一样。

d.定义大而复杂应用到一些测试用例里面的大的测试用例脚本

   压缩大的序列命令是合理的。特别是你过分做这个工作,是有风险的。一个复杂的序列命令可能不是用到很多测试脚本中,所以不值得推广,事实证明,应该加入错误处理代码到你期望适合写库函数中。同样,越复杂的序列,当ui变化越需要维护。一个很少用的脚本命令可能占用你的库维护成本的很大部分。

 

e.定义实用函数

   比如,你可以创建一个用标准方法记录测试结果到硬盘的函数。你可以在开发脚本的时候把它作为标准在每个测试用例后边调用这个函数。

   每个测试工具都提前提供自己写好的实用函数。你可以添加或不添加附加函数。

 

一些框架的风险

   

你不能同时把所有的命令添加到你的库中。你没有足够的支撑。一些自动化工程失败的原因在于测试提供者想创建最终的必须有的每一个编程库。管理维护在框架完成能用前无法再提供支持。你不得不分清优先级。不得不超时运行编译库。

    

     不要期望函数库在那里每个人就都会用它。一些人的编码风格各异。如果你没有一个变量声明,函数的参数顺序,用到的全局变量等等的标准,这些对于一个程序员是合理但是对其他人就可能不合理的。同样,一些人憎恨不是他们写的代码。一些人熟悉工程代码比较慢,不知道库里有什么东西。他们总是很匆忙没有时间任何时间考虑就开始编程。你不得不设法维护这些库正常运行。

  

最后,小心设置执行,尤其如果你程序中有自定义控件的时候。版本1.0中(或者早期的开始自动化测试的版本),你可能花费的大部分时间去包含创建类似于点击按钮,选择列表项,选择tab页等这样模块框架。你可以节省为版本2写脚本的时间从中获益。建立框架是昂贵的。请从新考虑你的期望。

 

4.  认清事实

 

你必须给一些稳定的版本培训你的管理。

 

首先,很多测试人员是初级程序员。他们没有多少设计系统的经验。设计不合理的框架对工程也是有影响的。所以需要有经验的人。如果像自动化成功,你不得不需要一个有丰富编程经验的人加入测试团队。

 

其次,很多黑盒测试人员几乎没有编程经验。他们可以提供类似专家经验或者其他用户体验之类,这些是编程人员无法提供的。这些是有效的强壮测试不可缺少的。因此,你需要一个不用每个人都要写测试代码的稳定开发策略。你要解决创建一个测试开发人员在非测试开发人员之上的问题。很普遍,在我的观点里利用自动化测试工具的队伍中有失去理性和反对多产的偏见。这会伤害老的非测试开发人员,它会花费更多精力测试程序,而不是用户需求本身。

 

非开发测试人员通过往电子表格写测试计划的方式开发测试用例---也就是数据驱动方法,会做的很好。

 

第三,用执行人实现自动化测试要小心。他们不但要有开发经验,而且要肩负培训或者更多的日常任务。

 

最后,必须让管理者知道自动化是需要时间的,不要期望在最初版本中开发的自动化程序中获得效益。如果你应用层次上达到了测试目标,那么你可以添加更多的目标。如果一个项目用十个人手工测试一年正常,你可以加两名优自动化开发经验的测试人员,这时候你就有10个测试人员两个开发人员。在下个版本中,你可以减少测试人员的时间。在这个版本中,你将节省一些同样的任务时间(比如配置测试)但是你将在培训和管理费用上失去时间。在每一个项目结尾,可以提高衰退测试软件面对推迟完成测试的能力,而在计划最后一分钟确定,这样可以帮助你稍作无用的测试,胜于给你砍掉稳定版本的机会。

 

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

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

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

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

软件的可维护性与可复用性

我们常说一个好的系统设计在于其有较高的可维护性和较高的可复用性。其实可维护性与可复用性是两个独立的目标,并不总是方向一致。         软件的维护就是软件的再生。一个好的软件设计,必须能够允许新的...
  • zsh2050
  • zsh2050
  • 2015年01月10日 16:01
  • 1165

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

区块链成熟度评测报告(4)——可维护性、兼容性对比、总结

可维护性对比 区块链的可维护性主要考察印记管理、系统管理、策略管理、智能合约、易部署性五个方面。 (一)应急管理:商业区块链A应急管理体系完善,商业区块链B和Fabric无应急管理体系 应急管理...
  • Blockchain_lemon
  • Blockchain_lemon
  • 2018年01月04日 17:33
  • 98

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

testng被普遍使用于基于java和spring的系统结构中,用于保证系统功能,本身testng的特点: 1.结构清晰 2.支持多种数据源 3.可与maven集成 4.环境/数据准备方便 可用于系统...
  • u010321474
  • u010321474
  • 2015年11月22日 15:10
  • 1970
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:提高自动化测试套件的可维护性 - 4
举报原因:
原因补充:

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