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

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

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

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

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

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

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

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

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

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

好贴

好贴

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

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

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

不错的讨论

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

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

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

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

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

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

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

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

先谢谢。

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