A good framework allows users who dont know anything about automation to create automated test cases.
A good framework requires very little maintenance compared to traditional automation practises.
A good framework lets you work around things like QC which is after all an expensive defect tracker. 原帖由 marco 于 2007-8-22 09:56 发表 http://bbs.51testing.com/images/common/back.gif
什么是好的自动化框架，在一国外网站看到的，觉得很有道理
什么是好的自动化框架，在一国外网站看到的，觉得很有道理
A good framework allows users who dont know anything about automation to create automated test cases.
...
这只是可笑的妄想。太简单的东西，往往都沦为花哨的玩具，玩玩可以，不能实用！ runner视频及其他资料 ding 原帖由 yabest 于 2007-8-17 14:37 发表 http://bbs.51testing.com/images/common/back.gif
这文章以前有看过，开始期望还挺高的，可是看过后，很失望。
说实在的，我觉得这些在Excel里写伪码，或者啥数据驱动、表格驱动等方式的框架，都是花哨的，功能很受限，根本就不实用。
可能是仁者见仁智者见智吧，文章本身一直在传达这样的一种信息，做自动化框架就是开发一个项目，测试开发人员本身应该具备良好甚至是优秀的开发能力，这和国内往往测试人员根本不懂开发的现状有比较大的出入。
至于啥数据驱动、表格驱动这些都是围绕着一个观点出发的，就是让我们的测试设计人员--（测试设计和开发人员是完全不同的角色，承担的工作任务也不同，这是前提，国内喜欢把角色混淆，或是根本无视这些角色划分，责任不明工作不专）远离框架本身的复杂度，为他们提供一个快捷方便的应用接口罢了，花哨也好，功能受限也好，根本的思想还是值得借鉴的。
另外，如果真要使用STAF，没有扎实的编程功夫是比较难做的，所以请不要轻率的下结论。 原帖由 yabest 于 2007-8-22 10:09 发表 http://bbs.51testing.com/images/common/back.gif
这只是可笑的妄想。太简单的东西，往往都沦为花哨的玩具，玩玩可以，不能实用！
简单？？你看过STAF的源码吗？看过SAFS的源码吗？？
应用接口简单那是正常的，总不能让我们的测试设计人员人人都是编程高手吧。
实用，啥叫实用？？那是建立在会用的基础之上的。~~~~ 原帖由 fennek 于 2007-8-22 11:48 发表 http://bbs.51testing.com/images/common/back.gif
简单？？你看过STAF的源码吗？看过SAFS的源码吗？？
应用接口简单那是正常的，总不能让我们的测试设计人员人人都是编程高手吧。
实用，啥叫实用？？那是建立在会用的基础之上的。~~~~
看了SAFS的介绍，那是一个通用测试运行平台吧（很多公司都有这样的平台），跟我们这里讨论的简化QTP开发和维护工作的QTP自动化框架是两回事。
你都没明白我的意思！
一般而言，一个工具，功能越强，使用就越复杂！（就像画笔和PS这两个画图软件）
虽然可以想办法，做一些封装和固化，来减少使用复杂度，但相应的，却失去了灵活性。
这是个度的问题，也是两难的问题。为了使用简单，就要做封装和固化；但封装和固化越多，功能就越弱、越不灵活。
等你弄到非常非常简单的时候，这工具往往就被你弄得非常僵化了，功能超弱，只能玩玩，不再具有实用性了。
[ 本帖最后由 yabest 于 2007-8-22 13:43 编辑 ] 原帖由 marco 于 2007-8-22 09:56 发表 http://bbs.51testing.com/images/common/back.gif
A good framework allows users who dont know anything about automation to create automated test cases.
.
所以不要指望有这种“good framework“， 可以”allows users who dont know anything about automation to create automated test cases.”
相互学习
相互学习切磋！ 原帖由 yabest 于 2007-8-22 13:39 发表 http://bbs.51testing.com/images/common/back.gif所以不要指望有这种“good framework“， 可以”allows users who dont know anything about automation to create automated test cases.”
厚厚，说严重点，你这是扼杀人们的希望，哈哈。~~~
自动化框架如同自动化测试本身一样，它不是银弹，但起码给大多数迷失于自动化工具的人以希望啊。 原帖由 yabest 于 2007-8-22 13:36 发表 http://bbs.51testing.com/images/common/back.gif
看了SAFS的介绍，那是一个通用测试运行平台吧（很多公司都有这样的平台），跟我们这里讨论的简化QTP开发和维护工作的QTP自动化框架是两回事。
你都没明白我的意思！
一般而言，一个工具，功能越强，使 ...
我只是看到你对STAF的评价，想对此表达一下自己的看法~~~就QTP本身我不会做过多的讨论。
另外，什么是好框架？？很简单，能帮助我的自动化工具为我更好的工作的框架，就是好框架（虽然有点拗口）。
还是仁者见仁智者见智吧~~~
至于你所提到的简单性，我不敢苟同，“封装和固化以致失去灵活性”，貌似这几者之间没有任何联系吧，不然面向对象的开发也不会提倡什么内聚、低耦，接口抽象化之类的原则了吧。 原帖由 fennek 于 2007-8-24 14:52 发表 http://bbs.51testing.com/images/common/back.gif
厚厚，说严重点，你这是扼杀人们的希望，哈哈。~~~
自动化框架如同自动化测试本身一样，它不是银弹，但起码给大多数迷失于自动化工具的人以希望啊。
呵呵，我是要扼杀掉人们的希望，不，应该说是现阶段不该有的奢望！
除非真正的人工智能出现，电脑也能象人那样思考，否则，还是老老实实的干活吧，别做梦了。 原帖由 fennek 于 2007-8-24 15:06 发表 http://bbs.51testing.com/images/common/back.gif
至于你所提到的简单性，我不敢苟同，“封装和固化以致失去灵活性”，貌似这几者之间没有任何联系吧，不然面向对象的开发也不会提倡什么内聚、低耦，接口抽象化之类的原则了吧。
看贴不认真，都说了这是个度的问题，再仔细看看我的帖子吧
虽然可以想办法，做一些封装和固化，来减少使用复杂度，但相应的，却失去了灵活性。
这是个度的问题，也是两难的问题。为了使用简单，就要做封装和固化；但封装和固化越多，功能就越弱、越不灵活。
等你弄到非常非常简单的时候，这工具往往就被你弄得非常僵化了，功能超弱，只能玩玩，不再具有实用性了。
现在用对象封装的东西多了，象各种控件。
可是你也知道越是功能强大的控件，它的接口就越多！
为什么用了面向对象的技术了，用对象的方法做了封装了，它还是这么复杂呢？！
这是它的强大功能所决定的！真要把它封装得非常简单的话，它也就变成一个功能简单的对象了。
[ 本帖最后由 yabest 于 2007-8-24 16:58 编辑 ] 精神值得学习 原帖由 yabest 于 2007-8-24 16:52 发表 http://bbs.51testing.com/images/common/back.gif
看贴不认真，都说了这是个度的问题，再仔细看看我的帖子吧
虽然可以想办法，做一些封装和固化，来减少使用复杂度，但相应的，却失去了灵活性。
这是个度的问题，也是两难的问题。为了使用简单，就要做封 ...
不是看帖不认真，老实地说我觉得这几句话有点不知所云，当然可能是我自己的理解水平有限所致，还请见谅~！~呵呵 原帖由 yabest 于 2007-8-24 16:46 发表 http://bbs.51testing.com/images/common/back.gif
呵呵，我是要扼杀掉人们的希望，不，应该说是现阶段不该有的奢望！
除非真正的人工智能出现，电脑也能象人那样思考，否则，还是老老实实的干活吧，别做梦了。
干活一定是老老实实的，但这梦也是得不停地做下去的，起码还有希望。
不过干活和做梦似乎两者之间并没有多少逻辑关系哦，哈哈哈~~~希望和梦想总是需要人去实现的~~~
好帖啊!!
支持 槛外人 ， 评论很中肯 ！支持 yabest , 对qtp理解很深刻 ！
支持 梦醒 ， 共享的精神很不错，其他。。。。。。 好啊。高手论道，有火花却无攻击， 晕啊，这个贴子已经3个月没人顶了啊，不过对于我这样的新手来说却很有价值哦 第一次来看这个帖子。。。
两个月前自己开始尝试写个框架，所以凡是关于框架的帖子我都没怎么关注，主要不想被局限了思维，可结果才写了一周多刚写完控制部分就被其它事情干扰搁浅到现在，让几位朋友失望了~
框架这个东西确实仁者见仁智者见智，站的角度高度不同，思维看法都会有很大的差别。
在我的设计中，主要将框架分为两大部分，一部分为控制函数部分，这部分是和业务隔离开的，可以直接复用。而另一部分为业务相关的测试套(可扩展支持多种，目前仅开发了一种)，测试用例(可以有多种规范，目前也仅制定一种)，公共函数库(目前提供两种公共函数模式：业务模块模式和动作模式)，数据驱动方式(可支持多种格式数据文件)，日志函数(可根据需要选择记录内容、方式)，数据输出(也可合并到日志中)等。
当然以上也只是简单的分类，还有很多细节可以商榷，比如日志输出也可划分到控制函数部分去，通过参数控制输出模式。
整个框架通过驱动函数调用主控函数，再调用各个测试套依次执行各个测试用例。
等有时间了我把代码整理整理，纯粹是兴趣去研究的，在公司根本就不会去用到这些(偶只是个做手工系统测试的初级Tester:lol )
漏了项关键内容:公共函数库，这里补上
[ 本帖最后由 hsjzfling 于 2007-11-29 17:51 编辑 ] 关键就是要实用，大家也都不想光看大道理，但实际对于写一个实用的框架却没什么大的帮助。
顺便提个观点，就国内的测试状况来看，貌似不太适合使用关键字驱动。。。综合考虑成本、效率等因素来看数据驱动就足够了
楼上不少人的观点都是不错。
yabest提到的不少观点我觉得大家都可以借鉴下（除了对 对象库的偏执，不过他也提到了，有需要的时候也会用到的，哪个方便哪个效率高就用哪个呗～～），比如"功能越强，使用就越复杂"，确实如此，我在框架中每加个功能，就要多一个接口(或多个)来支持，使用时就要多输入一个参数多调用一个函数。。。不过可以加入框架默认设置：）
斑竹的将对象库中的对象自动转化为描述性语言的实现过程偶也很好奇，请解惑
说实话"梦醒十分"的视频我还真没看过，不过看看大家的评论也可以有一定了解了，不讨论它是否实用，仅内容而言那个最多只能算是框架的冰山一角，以偏概全误导大家就不好了。
