查看完整版本: [原创]自动化测试成功秘诀

[原创]自动化测试成功秘诀

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

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

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

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

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

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

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

不知道天网有没有关于如何恢复干净测试环境的文章或者书籍可以推荐，谢谢！

关于自动化测试理论方面的文章或资料，具体的名字真想不起来了。可以上[url]www.qaforums.com[/url]和[url]www.stickyminds.com[/url]上去看看，那里有不少好文章。

还有，纯粹的自动化测试时不存在的，一定要有人对测试脚步进行更新和维护。

好贴

好贴

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

有好的自动化测试框架推荐吗？

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

不错的讨论

真不错，受益匪浅，不过来没到这种程度，希望以后可以利用大家的讨论结果，提高自动化水平。

果然是超级版主，看的都是英文网站，:,(看到头痛，而且读起来也不太懂

粒度变小对于复用和维护都会有好处

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

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

这是传说中的西湖论剑？？？？呵呵。

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

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

well, so wonderful.　我也很想知道“关于恢复干净测试环境”的问题，两位超级版主skinapi和天网是否说得详细点啊？

先谢谢。

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

关于测试环境清理, 我们一般是在执行测试脚本时直接操作数据库

有好的自动化测试框架推荐吗？

以上的楼长说的挺好的

自动化测试要把握好度的问题，过犹不及

一般自动化框分三层
以一个工作流系统为例，那会用动作层，角色层，工作流层

不错
偶是新手
学习中

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

主管要我看loadrunner,说下一个项目就要用...sdlkfj9

支持2楼的，分层十分重要，case结束时的环境清理在多数情况下我认为也是必要的。

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

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

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

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

问一个弱弱的问题，不要拍我，环境清理只针对数据库对吗？

测试也是开发的过程 尤其是自动化测试     把脚本打版本 同开发版本 一一对应

回复 #1 skinapi 的帖子

不错的讨论

真的是不错的帖子，顶！！！

公司在搞自动化测试，只有部分人在弄，我们还没参与

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

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

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

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

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

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

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

讨论，我是搞硬件测试的，谈谈经验，希望能有帮助

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

非常不错

谢谢两位老师

我也是刚刚开始自动化测试脚本的开发，对于两位版主说的自动化测试的框架还不是很懂，能仔细说说吗:$