51Testing软件测试论坛

标题: [原创]自动化测试成功秘诀 [打印本页]

作者: skinapi 时间: 2004-7-14 17:17
标题: [原创]自动化测试成功秘诀
前言
   其实这篇文章主要是我对以下两篇文章的理解，并加上少许自己的思路。至于取标题为自动化测试成功秘诀，主要是也想不到什么好的标题，这个标题虽然俗点，但好歹能吸引大家的眼球。希望大家看过之后对自动化测试的认识能有少许的深入，如果能引起大家的思考那是更好了。废话少说，言规正传。
http://www.automated-testing.com/PATfinal.htm
http://www.automated-testing.com/multi.htm

正文
   都说自动化测试不好搞，搞的不好往往是费力不讨好，那么究竟该如何入手自动化测试呢？首先需要理解的是四个与自动化测试成败密切相关的因素：自动化测试系统、测试体系、软件测试生命周期、整个团队对自动化测试的支持。下面对这四个因素分别详细一点说明。
1。自动化测试系统
   包含自动化测试框架和自动化测试脚本。自动化测试框架让自动化测试变成可能，而自动化测试脚本则让自动化测试成为现实。自动化测试框架这里就不细说了，可以利用已有的工具，也可以自己来搭。这里要重点说的是自动化测试脚本，如何让自动化测试脚本更适合于自动化测试、更能提高自动化测试的效率。
   我们知道对于自动化测试而言，自动化测试脚本的巨大工作量是一个很让人头疼的问题。具体可以分成两方面：一是由于设计开发的变更，往往导致大量脚本的修改；二是自动化测试脚本数量巨大，如果都是独立来写，编写以及修改都让人望而却步。那么怎样才能尽量减轻这种问题呢？可以从两个方面来入手：一是将大的脚本拆分成可以重用的小的脚本；二是在脚本中进行动态比较时，比较的精细程度一定要慎重，可考虑设计不同精细程度的脚本。
   将大的脚本拆分成小的脚本有两个好处：一是可以复用，减小编写脚本的工作量；二是在由于设计修改导致需要修改脚本时，只需要修改小的脚本即可。采用这种方法可以有效的减小编写和修改自动化测试脚本的工作量。当然这种方法需要对流程或者过程进行比较准确的划分，划分的越好产生的效力也就越高。另外对于不同复杂度的软件项目以及不同的测试阶段，脚本的精细程度也应该存在差异。脚本的精细程度可以从两个方面来理解：一是流程上的测试采样点；二是比较的程度。当需求或者设计还不是很稳定时，需要采用较疏的测试采样点，比较时也不要太精确，这样可以避免脚本的大量修改。当设计相对稳定后，可增加测试采样点，同时比较时更精确一些，提高对错误的敏感度。对于同一个子过程，可以设计不同精细程度的脚本，根据实际需要来使用。

注：这几天一直太忙，搞的都没时间好好思考思考，把后面的写下去，只好等以后再补充了：（。写的有什么不对的大家尽管提，几块板砖还是拍不死我，呵呵。

作者: 天网 时间: 2004-8-5 17:51
大的脚本拆分成小的脚本并不能解决问题，可能能解决脚本复用，但无法避免开发设计变更带来的大规模脚本重写，关键要进行自动化框架设计，使得自动化测试是分层实现的，这样底层细节封装起来，对上层屏蔽，开发设计变更的话，只要修改底层脚本实现就可以了。
另外自动化脚本中要解决的一个重要问题是恢复干净测试环境的问题。

作者: skinapi 时间: 2004-8-5 22:13
1。关于自动化测试的分层实现以及底层细节的封装，不知道天网能不能稍微再详细一点解释，谢谢。
2。关于恢复干净测试环境，我的理解是不同的用例执行后不管正常还是异常，最后的状态很可能不能为下一个用例所用，所以需要将该状态变成用例执行前的状态，以便能够运行下一个用例。一种可用的方式就是设计RESET函数。

作者: 天网 时间: 2004-8-6 11:03
1、其实自动化分层设计和软件分层的思想是一样的，例如在windows上开发的应用软件可以在不同的PC上运行，是因为操作系统层的windows把底层的硬件细节屏蔽掉了，所以上面的应用软件可以不用修改直接运行。
在自动化分层设计的时候，可以把会由于开发设计变更引起变更的部分放在底层，向上层屏蔽。
当然，由于测试是开发的下游部门，如果开发的设计完全不受控制的彻底变更，做为下游的测试部门，无论多么好的自动化框架设计都是没有办法规避这种大规模更改的风险的。

2、RESET能够对特定的被测对象有用，但一些大的系统（如通信、航天等），RESET系统是一个很废时间的过程，并且在这个过程中，如何判断测试台和被测系统的通信的恢复、如何判断下个用例脚本可以开始执行都是比较复杂的。
这是自动化测试中一个难点。

作者: skinapi 时间: 2004-8-6 21:19
不知道天网有没有关于如何恢复干净测试环境的文章或者书籍可以推荐，谢谢！

作者: 天网 时间: 2004-8-12 11:56
关于自动化测试理论方面的文章或资料，具体的名字真想不起来了。可以上www.qaforums.com和www.stickyminds.com上去看看，那里有不少好文章。

作者: sunpxt 时间: 2005-1-10 17:12
还有，纯粹的自动化测试时不存在的，一定要有人对测试脚步进行更新和维护。

作者: nono 时间: 2005-4-8 00:39
好贴

作者: nono 时间: 2005-4-8 00:40
好贴

作者: black_tulip 时间: 2005-4-8 09:57
看得出天网有实战经验。同意天网的意见。粒度变小只能对复用有好处，维护的工作量会更庞大。
框架就很重要了，而且专有性很强。
脚本还有个问题，对其也需要当作软件一样的去维护和测试。
至于reset，在很多系统中，不是那么容易的回到干净的状态，书上也不可能有一统的条条。

作者: ghostystep 时间: 2005-4-30 15:39
有好的自动化测试框架推荐吗？

作者: kernzhang 时间: 2005-6-20 00:02
我们现在讨论的测试的自动化！实际也是IBM现在所提出的SOA的概念！实际这个概念也不新！开发的变化，必然导致测试的变化！有句话说得好“不变的是变化”，我们所谓完全的自动化只是我们的一个梦想，我们能够做到是在能力范围的变化，在开发测试脚本开发上面，我们能做的是脚本原子化，提高脚本的重用性，我认为这最多会提升20%的自动化，就像现在IBM公司在我们作一个项目，他们安排了中国最好的SOA工程师来做这个项目，但是到后来还是不尽人意！所以大家所期望的自动化，也不要报一个非常宏高的理想！世上没有一个东西可以完全自动化的！

作者: jmichael 时间: 2005-6-22 12:06
不错的讨论

作者: swallow1981328 时间: 2005-11-17 15:39
真不错，受益匪浅，不过来没到这种程度，希望以后可以利用大家的讨论结果，提高自动化水平。

作者: swallow1981328 时间: 2005-11-17 15:43
果然是超级版主，看的都是英文网站，:,(看到头痛，而且读起来也不太懂

作者: qiuyangzh 时间: 2005-11-17 16:51
粒度变小对于复用和维护都会有好处

关于恢复干净状态的问题，我的体会是：在所有的测试用例执行前，先执行一个检测脚本，检查系统的基本状态是否正常。在每个测试用例的尾部都包含一段清理环境的脚本，作为该测试用例脚本的一部分。

测试确实是开发的下游，但开发、测试是一个系统性的工作，所以在项目之初，要说明变动对测试的影响，尽量减低测试的成本

作者: 槛外人 时间: 2005-11-25 16:19
标题: 这是传说中的西湖论剑？？？？呵呵。
从我自己实际的工作中说两句吧，我搞的是网站的测试。
我碰到的开发的变更引起脚本的变更主要有2个方面：
1、对某个功能新增了个页面，这种情况下，不论上下层分得多清楚，还是要修改你相关的代码。分得越多，需要改动的脚本越多。
2、页面的组件变了名称。在QTP、Funtional Tester及大部分的功能测试软件中都需要根据对象的属性进行识别，而这些属性中名称占的比值很重。这种情况下也需要修改测试脚本。
所以我觉得要搭建什么样的测试框架是跟所测试的项目紧密相关的。可以在项目初期评估此项目以后可能的变化都在什么方面，之后再设计组件的测试框架。当然这是对长期的项目来说的，比如说网站。如果只是一个一次性的项目，那么就没有必要做自动化测试了。

作者: sword_zhu_1 时间: 2005-12-30 12:45
另外对于脚本也要注释清楚。如果脚本是由消息组成的，建议可以通过建立消息库来将消息独立出来。因为一个测试脚本应该有两部分组成，测试的流程和参数的配置。这两者之间有联系也有区别。

作者: hicome 时间: 2006-2-11 16:33
well, so wonderful.　我也很想知道“关于恢复干净测试环境”的问题，两位超级版主skinapi和天网是否说得详细点啊？

先谢谢。

作者: April.H.X 时间: 2006-4-1 10:09
比较同意天网的观点...除了测试环境的问题, 还有一个大问题就是人员...大部分的测试人员编码水平较低,对框架的理解也不透...工作很难展开...头痛!!!

作者: April.H.X 时间: 2006-4-1 10:13
关于测试环境清理, 我们一般是在执行测试脚本时直接操作数据库

作者: xiaocao412 时间: 2006-5-15 13:52
有好的自动化测试框架推荐吗？

作者: 心情回收站 时间: 2006-6-29 19:22
以上的楼长说的挺好的

作者: jeffson_joe 时间: 2006-7-26 23:09
自动化测试要把握好度的问题，过犹不及

作者: auqdppyv 时间: 2006-9-3 02:38
一般自动化框分三层
以一个工作流系统为例，那会用动作层，角色层，工作流层

作者: 423799223 时间: 2006-11-30 18:35
不错
偶是新手
学习中

作者: windfly1314 时间: 2006-12-29 14:16
同意槛外人的说法,我也是做网站测试,就是因为有好几期的工程运用自动化测试才
会提高效率,要不真的没有那个必要.当然脚本还是细分了好.sdlkfj5

作者: skybusy2000 时间: 2007-1-11 13:47
主管要我看loadrunner,说下一个项目就要用...sdlkfj9

作者: Rue1 时间: 2007-1-17 16:59
支持2楼的，分层十分重要，case结束时的环境清理在多数情况下我认为也是必要的。

至于脚本大小，实战中一个脚本对应一个功能，这样脚本应该是比较小的。大多数情况下，一个脚本过大我认为是封装还做得不够。

重用的应该是类是方法，而不是脚本本身。

我只做了半年的自动化测试开发，一点点看法供大家交流。sdlkfj2

ps:注释也非常非常重要。。。

作者: ireneyao 时间: 2007-4-25 16:16
问一个弱弱的问题，不要拍我，环境清理只针对数据库对吗？

作者: firemonth 时间: 2007-5-23 09:15
测试也是开发的过程尤其是自动化测试把脚本打版本同开发版本一一对应

作者: wymln 时间: 2007-6-4 17:53
标题: 回复 #1 skinapi 的帖子
不错的讨论

作者: lantianwei 时间: 2007-6-16 20:06
真的是不错的帖子，顶！！！

作者: gaoyanfang1 时间: 2007-7-5 13:22
公司在搞自动化测试，只有部分人在弄，我们还没参与

作者: EdmondYe 时间: 2007-7-31 14:57
关于恢复干净的测试环境.有好的办法可以做到的.有开源工具可以做到.QTP我们只做前端的GUI测试,只是作为一个前段测试入口.潜水太久,随便说两句.....

另外每个公司的产品结构有不同,所以要分别对待,分析清楚.有开源的就用开源,但不可能把自动化测试系统搞的太复杂,整合起来也很麻烦.

对于天网的"大的脚本拆分成小的脚本并不能解决问题，可能能解决脚本复用，但无法避免开发设计变更带来的大规模脚本重写，关键要进行自动化框架设计，使得自动化测试是分层实现的，这样底层细节封装起来，对上层屏蔽，开发设计变更的话，只要修改底层脚本实现就可以了。
另外自动化脚本中要解决的一个重要问题是恢复干净测试环境的问题。"

这句话,我想说的是,把大脚本拆分成小脚本有时候也可以解决脚本复用,而且有时候会减少脚本的维护量,对小脚本进行封装,在这一层之上形成一些类似描述性语言的脚本,使普通QA不需要有编程的经验也可以写自动化脚本.因为看见case描述就可以写出对应的脚本,脚本中的内容就是一个个底层封装的library,只需要传入相应的参数就行了.

或许有的产品结构使用这种方法会产生天网说的情况.那么我们可以考虑其它办法.总之,首先要分析自己的产品,找到属于自己的自动化测试方法.
个人见解.呵呵.

[ 本帖最后由 EdmondYe 于 2007-7-31 15:03 编辑 ]

作者: danmy 时间: 2007-8-1 10:53
受益菲浅。
环境恢复目前我也是首先直接操作数据库，测试环境是干净了，脚本运行顺畅了，但是实际测试中往往会希望有很多dirty的数据（实际应用中较大的系统也肯定会积累很多这样的数据）

作者: li_lzw 时间: 2007-8-10 20:32
标题: 讨论，我是搞硬件测试的，谈谈经验，希望能有帮助
架构很重要，像我们几个产品的测试工具分别是不同时期，不同人员开发的。架构不同。维护起来差别就很大。
总体上说，架构分底层（产品、测试工具的接口），AW（对产品、仪器的某项操作），具体功能（产品的状态设置等），测试用例。数据的处理，GUI界面几个部分。
好的架构对新功能的开发，后续的维护帮助很大。
另外对于类，我的看法是不是所有的脚本都用类来实现就好。毕竟我们是做测试工具，目标是用最小的开销实现最好的测试质量。要简单、易用。
另外，注释很重要，除非你想这个工具离开你就不行：）

作者: lanxiaowen 时间: 2007-9-28 18:36
非常不错

作者: yuandjing 时间: 2007-9-29 17:15
谢谢两位老师

作者: liuxl 时间: 2007-10-31 17:01
我也是刚刚开始自动化测试脚本的开发，对于两位版主说的自动化测试的框架还不是很懂，能仔细说说吗

作者: luffy2095 时间: 2007-11-28 14:06
好帖，受益匪浅。

作者: ft1986926 时间: 2008-1-14 00:00
继续关注中

作者: 阿妮妲 时间: 2008-1-23 15:26
好铁就要用起来.
因为是测功能驱动,我只写了几个小的可以重复利用的脚本.至于说的搭建框架,就不太清楚了.

作者: guzhenyu503 时间: 2008-1-23 16:29
标题: 好帖!顶了
我搞测试快2年了,想学习下自动化测试,请问各位高手有没有什么自动化测试方面比较好的书籍或资料啊???

作者: jiline 时间: 2008-1-28 11:26
有没有通用的搭建自动化脚本的例子？

作者: gforg 时间: 2008-4-2 10:17
标题: 回复 45# 的帖子
能不能提供例子啊？

作者: baby0808 时间: 2008-7-9 10:10
急需自动化测试人员

做测试的兄弟朋友们大家好
1.五百强的it公司-欧美企业
2.急需自动化测试，白盒测试人员
3.地点是上海，成都
4.英语可以沟通

有家是四川的或者是周边地区的测试的朋友，回家发展也是很不错的选择，和家人在一起，生活的舒适惬意。
有感兴趣的朋友可以加我msn：bess.zhang@live.cn详谈，当然有朋友的朋友也可以互相推荐呀！！

作者: tracy-fmsi 时间: 2008-11-12 15:18
收藏了，继续学习

作者: chillbin 时间: 2008-11-17 11:14
看了这个帖子很受启发。。。最近在研究如何搭建测试框架，继续关注中～～～～

作者: lvxdoo 时间: 2008-11-29 23:12
如果设计变化很大，维护成本过高，还不如从新录制脚本，这样用新脚本替换老的脚本，也是不错的

作者: 点点滴滴 时间: 2008-12-23 11:38
好贴，好话题！

作者: yetties2005 时间: 2008-12-23 13:38
学习了

作者: lky3 时间: 2009-3-8 14:08
顶一个。

作者: zhuximei 时间: 2009-3-19 22:17
标题: 回复 54# 的帖子
说得很清楚

作者: ls_721521 时间: 2009-5-6 09:32
good

作者: beryl_lin 时间: 2009-5-14 12:22
同意天网的分层设计自动化框架的观点，但其实大的脚本拆分成小的脚本，也是有效的方法之一，同样可以解决复用和易维护的问题，而且需要尽量的将一些能够共用的部分（全局变量的形式）提取出来，更加有利于维护。

作者: liuxl 时间: 2009-5-22 15:37
1、关于如何恢复一个干净的测试环境的问题：我采用备份和恢复数据库的办法，每次运行完整的测试之前首先是恢复数据库。曾经参加过的微软测试培训中老师举例中用到还是代码实现恢复环境，如：你new一个东西，测试完最后的步骤就是delete；
2、设计的测试数据互相不能有关联性，否则一个路径fail就会很麻烦，不能准确定位问题
3、自动化脚本颗粒度的选择是个问题，我带过的很多人刚上手的时候最头疼的就是这个，其实我平时也是凭感觉来的，反正还是粒度小一点好，既能减少维护工作又能增加脚本复用性
4、自动化脚本的管理问题是我一直面对的一个问题，因为我们公司是买的现成的自动化测试工具，工具本身并没有提供很好的管理办法，也没有提供与一些管理工具的借口，不知道有哪位高人能给予指点呢？

作者: yy397375197 时间: 2009-6-6 11:04
我觉得如果要想做好一个项目的自动化测试，首先一点就是手工测试人员对自动化的重视程度，如果手工测试人员对自动化测试持漠不关心的态度，那自动化开展起来就难了。测试是一个团队合作的过程，如果你手工测你的，我自动化做我的，那最终自动化将被扼杀！

作者: woza 时间: 2009-7-31 22:22
尽可能不要做基于GUI的automation。Presentation layer的自动化测试属于投入产出比不太核算的做法。如果一定要做基于GUI的，那一定要用automation framework。录制回放的方法，维护会累死的。

设计automation framework的时候，一定要把所有的控件做成动态识别。然后设计test的时候，必须考虑每个test的独立性，以及可以不间断的重复运行。自动化测试中，人工干预的成分越多，自动化的价值越低。

作者: park_p 时间: 2009-8-6 16:40
标题: 交个朋友，希望能多多交流，分享经验
现在在做一个web程序自动测试框架的程序，是基于GUI的功能测试框架（性能测试以后也考虑纳入其中），用的开源工具selenium来作为测试脚本基础，因为selenium的核心是js脚本语言，所以在web测试时理论上可以做适当的屏蔽和支持用户自己配置操作的行为，这个框架在开发过程中，才开始没多久，这里就不能深入的跟大家讨论了，等有了成果之后，不管好坏与大家交流分享。

作者: lilycheng 时间: 2009-8-28 17:27
头晕眼花，没力气看了……
最新版本C++test免费下载：www.edukit.com.cn
全开放ARM学习平台：www.tryarm.com

作者: sunshine_2009 时间: 2009-10-28 16:02
学习中。。。

作者: efficient 时间: 2010-3-8 09:57
好的讨论可以激发更多的想法同时也可以再其中得到完善的学习，都说自动化测试不是会用工具就行，但是本人一直深入不到自动化测试中，自动化测试框架的具体使用时怎样子的？还有自动化测试思想太多东西要学了，向各位学习中 ^_^

作者: carol2000 时间: 2010-7-23 13:11
网页还可以用开源的，如果是应用软件，不用收费的真的没法做
===========
具体使用时你需要考虑的：
1. 自动化测试脚本代码的管理（与SVN等版本管理工具的整合）
2. 测试脚本的定时回放机制
3. 脚本代码与测试数据的分离(Data-Driven-Test)
4. 测试软件界面输入/输出值或者图片的如何存取读取和比较
5. 测试过程中异常窗口的处理
6. 测试结果报告如何清晰的呈现
7. 与bug管理工具(如Mantis)以及testcase管理工具(如TestLink)的整合等等

作者: nideba321 时间: 2010-8-17 15:28
你们说的这些无疑显现了一个问题，就是测试人员一定要比开发能力强，薪水高，地位高

作者: brin_zhang 时间: 2010-11-27 01:04
我也说2句：
我个人认为，作为一位测试人员掌握自动化，非常必要而且重要，因为测试是无穷尽的，我们必须要把重复性的工作丢给机器帮我们做，这样我们才能够腾出时间做更重要的事情。
自动化也不要想的很神秘，只要是机器自动的帮我们做了我们需要做的事情就达到了它的目的，小到一个编写的宏命令，大到整个测试框架的测试任务。
至于自动化为什么做的越来越累，是我们的态度的问题，很多人是为了实现自动化而做自动化，我们要知道自动化仅仅是一个方法，是测试的手段，不是目的。
很多厉害的牛人，实际上是分析和抽象的能力非常强，能够把复杂的东西简单化，抽象化，而我们现在很多人是把简单的东西复杂化了，所以做到最后掉里面了。
自动化测试的应用需要结合具体项目来灵活处理的，一个系统有它变化的成分也有不变的成分，所以也很简单，自动化主要集中在比较稳定的系统测试回归上面会达到他最大的价值，如果整个系统每个部分都在重构，显然这个系统不稳定，不适合自动化。

作者: lavern 时间: 2010-12-13 11:33
复杂的问题简单化

作者: wangze1123 时间: 2011-3-1 14:58
nnd,我就瞎扯下我搞自动化：
先说下自己啊。
我目前负责通信产品的自动化测试工作，框架部分主要是组建初始化和端口连接；用例的执行部分；组建停止。我不知道自己对所谓的框架这块理解的是否正确。
头疼问题：目前公司的用例脚本都由我来合入和审核，并且执行，目前有用例2000个左右，由于工具不稳定或环境问题，会导致用例执行的稳定性很差，比如好的时候，成功率会达到87％，不好的时候执行65％。

工具问题，只能在发现过程中不段修改。就环境恢复的问题，我们是这样的原则，动了哪里，执行完后，就恢复哪里。比如，我们执行不同用例前，需要通过MML命令配置环境，用例执行完后，立刻恢复。从而不影响执行下个用例。但是事实情况就是，随着用例的累加，维护起来很麻烦，无法保证用例前都是默认干净的环境，这也是我现在努力提高自动化成功率一个坎。
希望大家共同进步。

作者: riwater 时间: 2011-3-2 13:52
脚本要做到低耦合，这样在后期即使产品功能有变动也容易维护。
脚本中ui和逻辑分开，脚本清晰明确。同样便于修改和维护1

作者: sarahwsn 时间: 2011-3-4 16:45
天网是做自动化测试方面的吗？还有哪位是做自动化测试方面的？有事情向大家请教，方便的话可以加我msn:sarahwangsuna@hotmail.com qq:642403889 欢迎随时沟通。电话：13436928295

作者: 散步的SUN 时间: 2011-3-12 10:46
回复 70# wangze1123

我也负责的是通信产品的自动化测试，我们系统测试部门两百多人，产品线一堆，所以自动化测试工作开展起来的话，难度和投入蛮大的
从开始起，我们的定位就是将自动化测试定位在例行测试和回归验证测试。
自动化测试最关键之处在于定位（来源于用例，服务于用例）
然后在于框架（按我们现在做的，主要是将框架分层，尽量做到底层是测试点不变，上层面对设备和数据配置、在上层面对界面，可以传递全局参数）
之后在于需求（需求引导自动化测试的开展程度和覆盖率，需求的提出需要自动化测试人员理解产品以及其实现原理）
最后在于脚本技术
最近很是苦恼于需求....需求很多，但是如何实现，有所考虑
后期框架的扩展还有很大一步路

作者: 散步的SUN 时间: 2011-3-12 10:52
回复 68# brin_zhang
没错，说的很对
自动化测试定位很重要
定位低了，是因为自动化测试人员没有站在产品内部的原理出发以及本身自动化水平不够
定位高了，是因为对自动化测试要求过高，太理想化而造成的
关键是要定好位，到底要用自动化测试实现什么，实现的意义多大，然后再就是一个平台的问题，一个东西做不到一个平台则相当于形式了

作者: 散步的SUN 时间: 2011-3-12 10:53
回复 67# nideba321

测试人员要想比开发强
则要看其能够帮公司节约多少成本了，带来的价值是否大于开发了

作者: 散步的SUN 时间: 2011-3-12 10:54
回复 67# nideba321

测试人员要想比开发强
则要看其能够帮公司节约多少成本了，带来的价值是否大于开发了
其实一个项目50%以上的成本在于测试和维护，所以测试人员如果很好的抓住测试点和方法，还是很值得重视的

作者: 散步的SUN 时间: 2011-3-12 10:55
回复 65# carol2000
同意
应用程序试过蛮多开源的，效果还不是很强大，也许是自己的水平局限性吧

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)