以一个工作流系统为例，那会用动作层，角色层，工作流层 不错
偶是新手
学习中 同意槛外人的说法,我也是做网站测试,就是因为有好几期的工程运用自动化测试才
会提高效率,要不真的没有那个必要.当然脚本还是细分了好.sdlkfj5 主管要我看loadrunner,说下一个项目就要用...sdlkfj9 支持2楼的，分层十分重要，case结束时的环境清理在多数情况下我认为也是必要的。
至于脚本大小，实战中一个脚本对应一个功能，这样脚本应该是比较小的。大多数情况下，一个脚本过大我认为是封装还做得不够。
重用的应该是类是方法，而不是脚本本身。
我只做了半年的自动化测试开发，一点点看法供大家交流。sdlkfj2
ps:注释也非常非常重要。。。 问一个弱弱的问题，不要拍我，环境清理只针对数据库对吗？ 测试也是开发的过程 尤其是自动化测试 把脚本打版本 同开发版本 一一对应
回复 #1 skinapi 的帖子
不错的讨论 真的是不错的帖子，顶！！！ 公司在搞自动化测试，只有部分人在弄，我们还没参与 关于恢复干净的测试环境.有好的办法可以做到的.有开源工具可以做到.QTP我们只做前端的GUI测试,只是作为一个前段测试入口.潜水太久,随便说两句.....另外每个公司的产品结构有不同,所以要分别对待,分析清楚.有开源的就用开源,但不可能把自动化测试系统搞的太复杂,整合起来也很麻烦.
对于天网的"大的脚本拆分成小的脚本并不能解决问题，可能能解决脚本复用，但无法避免开发设计变更带来的大规模脚本重写，关键要进行自动化框架设计，使得自动化测试是分层实现的，这样底层细节封装起来，对上层屏蔽，开发设计变更的话，只要修改底层脚本实现就可以了。
另外自动化脚本中要解决的一个重要问题是恢复干净测试环境的问题。"
这句话,我想说的是,把大脚本拆分成小脚本有时候也可以解决脚本复用,而且有时候会减少脚本的维护量,对小脚本进行封装,在这一层之上形成一些类似描述性语言的脚本,使普通QA不需要有编程的经验也可以写自动化脚本.因为看见case描述就可以写出对应的脚本,脚本中的内容就是一个个底层封装的library,只需要传入相应的参数就行了.
或许有的产品结构使用这种方法会产生天网说的情况.那么我们可以考虑其它办法.总之,首先要分析自己的产品,找到属于自己的自动化测试方法.
个人见解.呵呵.
[ 本帖最后由 EdmondYe 于 2007-7-31 15:03 编辑 ] 受益菲浅。
环境恢复目前我也是首先直接操作数据库，测试环境是干净了，脚本运行顺畅了，但是实际测试中往往会希望有很多dirty的数据（实际应用中较大的系统也肯定会积累很多这样的数据）
讨论，我是搞硬件测试的，谈谈经验，希望能有帮助
架构很重要，像我们几个产品的测试工具分别是不同时期，不同人员开发的。架构不同。维护起来差别就很大。总体上说，架构分底层（产品、测试工具的接口），AW（对产品、仪器的某项操作），具体功能（产品的状态设置等），测试用例。数据的处理，GUI界面几个部分。
好的架构对新功能的开发，后续的维护帮助很大。
另外对于类，我的看法是不是所有的脚本都用类来实现就好。毕竟我们是做测试工具，目标是用最小的开销实现最好的测试质量。要简单、易用。
另外，注释 很重要，除非你想这个工具离开你就不行：） 非常不错 谢谢两位老师 我也是刚刚开始自动化测试脚本的开发，对于两位版主说的自动化测试的框架还不是很懂，能仔细说说吗:$
