51Testing软件测试论坛

标题: 刚看了梦醒十分的自动化框架演示视频，感觉。。。 [打印本页]

作者: yabest 时间: 2007-8-10 18:36
标题: 刚看了梦醒十分的自动化框架演示视频，感觉。。。
感觉比较好笑

视频1：测试人员在Excel里写伪码，自动化专家再将其转化为QTP脚本
这种在Excel里写伪码的所谓QTP框架在网上多的是，但功能都是弱智的可笑，根本没实用性，拿来推销也太不负责了。

视频2：测试人员在Excel里写伪码，点按钮自动转换为QTP描述性方式脚本
在Excel里写伪码已经够弱智的了，还要把弱智伪码做这样的简单转换，简直多此一举，还不如直接写QTP脚本呢！

视频3：测试人员录制了QTP对象库方式脚本，点按钮自动转换为QTP描述性方式脚本
总算开窍了，知道在Excel里写伪码是弱智的了。以为还有救，谁知道竟拿出了更让人晕倒和吐血的方案！
人家QTP费这么大心血搞出的对象库，简直是QTP的精华，有人却费尽心机的要把这精华阉割掉，估计QTP设计者会被活活气死！
真那么喜欢描述性方式脚本，就直接用Robot好了！Robot没有对象库，生成的脚本直接就是描述性的，何必转换来转换去这么麻烦呢！

自己做做实验未尝不可，不过要给人家做培训，那就得谨慎，不要把不成熟不实用的东西随便推销给别人！

实话实说，不要介意！

[ 本帖最后由 yabest 于 2007-8-17 23:26 编辑 ]

作者: wasd2615 时间: 2007-8-10 20:42
我没分下不了哦你可以发给我看看不咯楼主大哥

作者: QTP高手 时间: 2007-8-10 22:42
这是我对他框架的评价！和你有同感！呵呵
看了视频，不得不说一个话题，这是一个QTP熟悉者玩得花招！如果把它作为框架无疑是误人子弟，如果让新手看到之后，反而把别人带到一个错误的自动化框架的方向。而且一个业务人员一个QTP人员就能实施公司的自动化，那么公司老总发财了。这些言论无疑实在对自动化讽刺。以及自动化的神化。建议新手看看他的技巧，别学思想。另外一个建议：想通过视频作培训，不如把QTP谈谈好，否则别人也不感请你做培训，因为老板很喜欢听你的言论，但是苦了辛辛苦苦工作的同行们

作者: dionysus 时间: 2007-8-11 10:30

原帖由 yabest 于 2007-8-10 18:36 发表
可笑得都有点生气，还是等晚上消消气了再说！

————————————————————————————————————————————————————————
继续说：

视频1：测试人员在Excel里 ...

我认为梦醒十分上传的自动化架构视频是他逐步探索总结的一个过程，通过调用函数自动转换成描述性编程在测试过程中是十分有用的。我想lz肯定是没有做过多语言版程序的自动化测试吧。同一个网站包含FJGK多钟语言，但总体结构却是一样的，这样只需录制一遍操作之后批量转换成描述性脚本即可。这是实践出来的结果。

作者: raymanan 时间: 2007-8-11 10:56
期待各位高手进一步的讨论.
谢谢!

作者: wtucel 时间: 2007-8-11 10:56
感觉LZ说得有点过分了,人家抽出自己的空余时间录制了这么多实际的例子,确实给我们这些还在探索中的人开阔了很多思路,自动化框架的实践本来就是逐渐改进的过程,大家都不是傻瓜,自动化本来就是用来提高效率,舍易求难肯定会失败,所以根本不存在你说的误倒.
我觉得这里还是一个'做'与'不做'的问题,去做了,就算做出的东西是拙劣的,也总比纸上谈兵,大谈理论的强,相信大家小时侯都学过'第三只小板凳'的故事吧.

作者: 梦醒十分 时间: 2007-8-11 11:02
特此声明：
此贴不存在为“梦醒十分”炒作之嫌
两位批评者并不是我请的托儿。
期待两位高手做一个真正的自动化框架视频，让大家分享。

[ 本帖最后由梦醒十分于 2007-8-13 09:46 编辑 ]

作者: yabest 时间: 2007-8-11 13:30

原帖由 dionysus 于 2007-8-11 10:30 发表

我认为梦醒十分上传的自动化架构视频是他逐步探索总结的一个过程，通过调用函数自动转换成描述性编程在测试过程中是十分有用的。我想lz肯定是没有做过多语言版程序的自动化测试吧。同一个网站包含FJGK多钟语言，但总体结构却是一样的，这样只需录制一遍操作之后批量转换成描述性脚本即可。这是实践出来的结果。

多语言版程序就更应该用对象库了！

我们测试的系统都是同时有中文、英文、日文等多种语言的。一般都是在英文版本下录制好脚本，然后只要修改对象库，用正则表达式匹配兼容其他语言版本，根本就不用修改脚本，简直太方便不过了！

我不知道你说的描述性编程对处理多语言版本有什么作用。
难道转换成描述性脚本后，将里面的文字一个个替换过去？这也太累，太容易出错了吧！
而且这样处理过后，就存在多套脚本了，将来怎么修改，怎么维护呢，难道要同时修改、维护多套脚本？

作者: yabest 时间: 2007-8-11 13:53

原帖由 梦醒十分 于 2007-8-11 11:02 发表
十分感谢LZ的批评，包括8月10日才新注册的“QTP高手”，我早知道“培训”同行是冤家，在我预料之中。
我想会有很多新注册的“QTP高手”对我进行批评，我都会“虚心”接受。

再次感谢楼主的这个贴子，它会让更多的初学者来看我的视频，“从此上当而走向QTP的弯路”，
我希望看过的人，像LZ这样多给一些直率的批评，谢谢。

做培训师给人做培训，就要更加谦虚，更加谨慎，要虚心接受别人的批评，时刻反省自己。
因为这不是你一个人的事，你犯的错误，将通过培训传播给很多人，到时只会害了很多人。

[ 本帖最后由 yabest 于 2007-8-15 15:16 编辑 ]

作者: dionysus 时间: 2007-8-11 14:23

原帖由 yabest 于 2007-8-11 13:30 发表

多语言版程序就更应该用对象库了！

我们测试的系统都是同时有中文、英文、日文等多种语言的。一般都是在英文版本下录制好脚本，然后只要修改对象库，用正则表达式匹配兼容其他语言版本，根本就不用修改脚 ...

我说一下描述性编程对多语言软件的测试吧，我这里同样也是首先在英文版上录制一遍操作，这时脚本里面记录的都是英文版的对象和属性值，之后调用automatic framework（一个函数库，里面包含将录制出的语句自动转换为描述性编程语句的一系列函数和操作），把脚本语句中所有的逻辑对象替换成属性和属性值，通常是以index来替换。这时生成的这一套描述性编程的脚本就可以在所有语言环境下回放了。当然其中肯定还需要调试。
在对象库中使用正则表达式兼容所有语言也是一个方法，但我想它的工作量一定不小，而且还需要对正则表达式掌握较熟练的人才能操作。
使用自动化框架则可以只运行一个自定义好的函数就将所有录制的语句转换过来，对一般操作人员来说相对简单不少，不过这个框架的编写和维护也是很需要技术的。
另外lz不要动怒，这只是一个技术上的讨论和分歧，QTP提供多种方法支持回放，我们就找一个适合自己的。如果发现以后在应用中逐渐不满足了，看看其他的方法也是一种启发。练剑练气全看自己的选择，我们不用非要灭了一派吧sdlkfj3

作者: yabest 时间: 2007-8-11 14:41

原帖由 dionysus 于 2007-8-11 14:23 发表
我说一下描述性编程对多语言软件的测试吧，我这里同样也是首先在英文版上录制一遍操作，这时脚本里面记录的都是英文版的对象和属性值，之后调用 automatic framework（一个函数库，里面包含将录制出的语句自动转换为描述性编程语句的一系列函数和操作），把脚本语句中所有的逻辑对象替换成属性和属性值，通常是以index来替换。这时生成的这一套描述性编程的脚本就可以在所有语言环境下回放了。当然其中肯定还需要调试。
在对象库中使用正则表达式兼容所有语言也是一个方法，但我想它的工作量一定不小，而且还需要对正则表达式掌握较熟练的人才能操作。
使用自动化框架则可以只运行一个自定义好的函数就将所有录制的语句转换过来，对一般操作人员来说相对简单不少，不过这个框架的编写和维护也是很需要技术的。
另外lz不要动怒，这只是一个技术上的讨论和分歧，QTP提供多种方法支持回放，我们就找一个适合自己的。如果发现以后在应用中逐渐不满足了，看看其他的方法也是一种启发。练剑练气全看自己的选择，我们不用非要灭了一派吧

啊，你转换成描述性脚本，就是为了去掉对象的其它属性，改成只用index附加属性？
可用index也太不可靠了吧，不然QTP干嘛要设置一大堆属性啊，都用index属性好了！

我说的对象库兼容，不需要用太复杂的正则表达式啊，只要用最简单的|表达式即可，比如 “OK|确定”、"Cancel|取消“这样子，就可以兼容中英文了，而且这样才准确才有保证嘛!

各种技术都有各自的特点的，虽然万法归一，条条通罗马，但是适用情况和成本代价是不一样的。
就像现在没人要灭了汇编语言，汇编语言还是有它的特点和适用范围的，但是你要跟初学者说明，大部分情况用高级语言，特殊情况才用汇编啊！这可不能搞混的！不然就没必要讨论了！

作者: danmy 时间: 2007-8-11 15:41

原帖由 dionysus 于 2007-8-11 14:23 发表

我说一下描述性编程对多语言软件的测试吧，我这里同样也是首先在英文版上录制一遍操作，这时脚本里面记录的都是英文版的对象和属性值，之后调用automatic framework（一个函数库，里面包含将录制出的语句自 ...

automatic framework 这玩意在哪? 貌似挺有用d

作者: dionysus 时间: 2007-8-11 15:45

原帖由 yabest 于 2007-8-11 14:41 发表

啊，你转换成描述性脚本，就是为了去掉对象的其它属性，改成只用index附加属性？
可用index也太不可靠了吧，不然QTP干嘛要设置一大堆属性啊，都用index属性好了！

我说的对象库兼容，不需要用太复杂的正 ...

肯定不止是用index一个属性来标识对象的。在我们测试的程序通常都很有7、8个语言的版本，如果在对象库中把每一个对象的label或text都加上不同语言那是很费时间的，而且容易出错（德语的单词比其他欧洲语言要长很多，8个语言都写到一个属性值里，不知道是否有长度的限制，对于GB18030四字节的文字能否正确显示没有试过，也不太清楚）
我开始接触描述性编程的时候也对它的便捷性有过疑问，如果真是对照对象库来把脚本都一一改成描述性语句，那纯粹是胡闹，有时间没处打发了。
但后来接触到自动化框架后，觉得普通tester只需调用一个函数就能自动转换所有语句为描述性语句，确实方便快捷。
在QTP的一般应用里对象库优点很明显，甚至都无需对它做什么修改，但接触到像这种多语言版本测试时，使用自动化框架转为描述性编程，脱离语言的限制效果更好。
像我这样的QTP初学者肯定偏向于用对象库，简单明了何乐而不为。而企业级的应用或高手们的自动化框架探索则描述性编程可以发挥更大的作用吧

作者: yabest 时间: 2007-8-11 17:13

原帖由 dionysus 于 2007-8-11 15:45 发表

肯定不止是用index一个属性来标识对象的。在我们测试的程序通常都很有7、8个语言的版本，如果在对象库中把每一个对象的label或text都加上不同语言那是很费时间的，而且容易出错（德语的单词比其他欧洲语言要长很多，8个语言都写到一个属性值里，不知道是否有长度的限制，对于GB18030四字节的文字能否正确显示没有试过，也不太清楚）
我开始接触描述性编程的时候也对它的便捷性有过疑问，如果真是对照对象库来把脚本都一一改成描述性语句，那纯粹是胡闹，有时间没处打发了。
但后来接触到自动化框架后，觉得普通tester只需调用一个函数就能自动转换所有语句为描述性语句，确实方便快捷。
在QTP的一般应用里对象库优点很明显，甚至都无需对它做什么修改，但接触到像这种多语言版本测试时，使用自动化框架转为描述性编程，脱离语言的限制效果更好。
像我这样的QTP初学者肯定偏向于用对象库，简单明了何乐而不为。而企业级的应用或高手们的自动化框架探索则描述性编程可以发挥更大的作用吧

我还是很好奇，也没看懂你这个转换是怎么做的，能简单举个例子吗?

比如 Button("OK").Click，对象库里OK按钮的属性是Text=OK，那你转换后的描述性脚本是怎么样的？
因为要兼容很多种语言，又不一一修改成多种语言文字，也就是你就不用Text属性了，只用index附加属性了？但是你怎么知道OK按钮的index是多少？

作者: dionysus 时间: 2007-8-11 22:17
就如你举的这个例子，我可以使用GetTOProperty函数取得"OK"的index或其他属性值，最后将取得的值替换掉这个逻辑名称，生成一个新的语句，如Button("index:=1").Click这样的语句，再次回放的时候qtp就不会受语言的限制了

作者: QTP高手 时间: 2007-8-11 22:34
我来回复梦兄的疑问，第一、我不是做培训的，我听得你后面的话觉得很有趣。我想你的目的希望寻求培训的机会。这个无可厚非。只要你有本事就出来做了。我想你做QTP可以但是你硬说这是框架，把框架说的这个神乎。简直难以想象的
第二：你把别人的看法，当成对你的攻击言辞，是不是非得我捧你几下才不算是攻击呢

你把QTP中的技巧当作框架，让我实在无法接受，你不懂框架的基本的设计模式，而谈框架。实在听不下去。也许你的QTP知识不错。但是距离框架一说差的太远了。我在我的答复过程中我希望大家学习的QTP技巧，而不能学你的框架思路。而且什么一个业务人员一个QTP人员来写这种你想得框架。唯一结果你是把别人带到死胡同里面去了。

作者: QTP高手 时间: 2007-8-11 22:38
Button("index:=1")，这种写法也许在某一特定环境下可用，但是有个很大的局限性。你的开发人员将这个顺序换掉了。这个对程序一点影响都没有。那你的脚本就完蛋了。而且使用这种方法会影响运行速度！不建议使用！大家有兴趣去看看win32 SDK的属性识别技巧！呵呵！

作者: yabest 时间: 2007-8-11 22:39

原帖由 dionysus 于 2007-8-11 22:17 发表
就如你举的这个例子，我可以使用GetTOProperty函数取得"OK"的index或其他属性值，最后将取得的值替换掉这个逻辑名称，生成一个新的语句，如Button("index:=1").Click这样的语句，再次回放的时候qtp就不会受语言 ...

更晕了，对象库里OK按钮的属性只有“Text=OK”，没有index属性的。即使有，那也是index=0（因为只有一个Text=OK的按钮）。
但是窗口里按钮有多个，OK按钮不一定是排第一个，Button("index:=0")不一定指向OK按钮的。

所以我更糊涂了，是不是记错了？

作者: QTP高手 时间: 2007-8-11 22:59
在答复的dionyons一个问题，如果梦醒十分，是把QTP语言转化成描述性语言来写，那他就太傻了点。我想十之七八是借助了EMOS的做法，你可以去看看EMOS的源码。说起来也挺简单的！

作者: yabest 时间: 2007-8-12 11:11

原帖由 wtucel 于 2007-8-11 10:56 发表
感觉LZ说得有点过分了,人家抽出自己的空余时间录制了这么多实际的例子,确实给我们这些还在探索中的人开阔了很多思路,自动化框架的实践本来就是逐渐改进的过程,大家都不是傻瓜,自动化本来就是用来提高效率,舍易求难肯定会失败,所以根本不存在你说的误倒.
我觉得这里还是一个'做'与'不做'的问题,去做了,就算做出的东西是拙劣的,也总比纸上谈兵,大谈理论的强,相信大家小时侯都学过'第三只小板凳'的故事吧.

主要是对他期望太高了，当初他那口气（是回复我对他视频一的意见），把我胃口吊得老高。
就耐心等啊等的，等到视频二、三出来了，一看，简直。。。
我们在这边随便讨论和尝试也就算了，但是培训师不一样，培训师要更加负责任的！

原帖由 梦醒十分 于 2007-7-20 09:43 发表
1：我讲的都是以前在项目中的亲身经历，我想经验能使人少走弯路。
2：我想传达的是一种设计思想和方法（要求是能真正理解），实不实用另说。
3：如果讲完第二期，甚至第三期，你还不理解什么是框架或还把某段框架代码看成是实用的万能工具，那么是我讲的不好。
4：如果讲完第二期，甚至第三期，你还不能自己动手用VBS或excel VBA(宏)写出类似的东东，只能向别人索取现成的，那么我白费劲了。。

[ 本帖最后由 yabest 于 2007-8-15 15:25 编辑 ]

作者: pignut2006 时间: 2007-8-13 09:01
标题: f
期待各位高手进一步的讨论.
谢谢!

作者: wtucel 时间: 2007-8-13 09:36

原帖由 dionysus 于 2007-8-11 22:17 发表
就如你举的这个例子，我可以使用GetTOProperty函数取得"OK"的index或其他属性值，最后将取得的值替换掉这个逻辑名称，生成一个新的语句，如Button("index:=1").Click这样的语句，再次回放的时候qtp就不会受语言 ...

明白BZ的意思了,但是只用index属性肯定是不行的,比如button,可以用GetTOProperty先取对象库里的name和index属性,然后转化为描述性大概就是Button("name:="&Name,"index:="&Index),这样转化后的脚本应该没有问题,但是对于检查点的转换有点麻烦了,实际值可以用GetROProperty来取得,但是对于录制脚本中我们设置的预期值,转化函数怎么去取得呢??

作者: wtucel 时间: 2007-8-13 09:40

原帖由 QTP高手 于 2007-8-11 22:59 发表
在答复的dionyons一个问题，如果梦醒十分，是把QTP语言转化成描述性语言来写，那他就太傻了点。我想十之七八是借助了EMOS的做法，你可以去看看EMOS的源码。说起来也挺简单的！

EMOS有QTP的自动化框架么? 我只见过WinRunner的,确实很牛B,因为我看不懂sdlkfj8
有的QTP的话共享一下撒

作者: xiaonan 时间: 2007-8-13 10:04
难得看到为一个技术,互相争论的帖子.不错,气氛蛮好,呵呵

作者: bobile 时间: 2007-8-13 10:18
呵呵，我也有同感

作者: lengz 时间: 2007-8-13 10:25
多说无意，认为别人做的不好就把你觉得好的东西拿出来给我们看看，我是新手，没有觉得梦醒十分的视频有什么不好。相反对我还有有一定帮助的～

作者: yabest 时间: 2007-8-13 10:48

原帖由 lengz 于 2007-8-13 10:25 发表
多说无意，认为别人做的不好就把你觉得好的东西拿出来给我们看看，我是新手，没有觉得梦醒十分的视频有什么不好。相反对我还有有一定帮助的～

可以说说对你有什么帮助吗？
还有你会按这样的思想去做QTP自动化吗？

另外我写的帖子也不少了，都在这个版里，你自己可去看的。

作者: loho1968 时间: 2007-8-13 13:37

原帖由 wtucel 于 2007-8-13 09:40 发表

EMOS有QTP的自动化框架么? 我只见过WinRunner的,确实很牛B,因为我看不懂sdlkfj8
有的QTP的话共享一下撒

是指这个吗？http://www.cbueche.de/

作者: loho1968 时间: 2007-8-13 13:53
如果是基于自己的产品，有大量的标准的操作、业务流程。又没有合格的自动化测试人员的情况下，使用框架的方式，不失为一种选择。

作者: wtucel 时间: 2007-8-13 19:59
我觉得用描述性编程有一个好处就是可以做到测试的前期介入,只要跟开发约定并规范好了各个控件的话,就可以在产品还没有开发出来的时候进行自动化脚本的编写.像梦醒十分的录象,tester可以根据需求来写测试用例,转化为描述性语言,产品出来后再调试,可以节省很多时间呢.

作者: yabest 时间: 2007-8-13 20:35

原帖由 wtucel 于 2007-8-13 19:59 发表
我觉得用描述性编程有一个好处就是可以做到测试的前期介入,只要跟开发约定并规范好了各个控件的话,就可以在产品还没有开发出来的时候进行自动化脚本的编写.像梦醒十分的录象,tester可以根据需求来写测试用例,转 ...

这是一个技术优点，不过还是不要这样做的好！
因为自动化测试一般只用来做回归测试，只测试已通过手工测试的、成熟的回归性用例！
你说的这一种情况，还是不要做自动化的好，等产品出来了，先做手工测试吧。等稳定了，再做自动化测试。

作者: loho1968 时间: 2007-8-13 21:26

原帖由 yabest 于 2007-8-13 20:35 发表

这是一个技术优点，不过还是不要这样做的好！
因为自动化测试一般只用来做回归测试，只测试已通过手工测试的、成熟的回归性用例！
你说的这一种情况，还是不要做自动化的好，等产品出来了，先做手工测试吧 ...

同意，如果软件没有稳定，使用自动化测试，除非你的自动化测试非常强壮。
我试验了模仿Wr的EMOS(http://www.cbueche.de/)，已经全部实现了。然后对同样的测试，使用录制+修改+编程。得出如下感觉

１、如果只有简单的测试功能，简单的数据输入，框架可以支持。
２、但是，如果测试的功能有一些业务流程，逻辑判断的，结果检查的话，架构的支持就有限了。
３、框架的调试非常困难。

作者: yabest 时间: 2007-8-13 21:43

原帖由 loho1968 于 2007-8-13 21:26 发表

同意，如果软件没有稳定，使用自动化测试，除非你的自动化测试非常强壮。
我试验了模仿Wr的EMOS(http://www.cbueche.de/)，已经全部实现了。然后对同样的测试，使用录制+修改+编程。得出如下感觉

...

看到这样表格的复杂，对比一下录制的轻松，我只能深深的叹口气，“何苦呢。。。”

作者: Jimmyshao 时间: 2007-8-13 21:44
看了上面这么多讨论，说说我自己的看法
1.QTP的精髓是对象库，我们可以通过Share OR或者普通OR配合正则表达式，就可以解决绝大多数的问题；
2。描述性编程个人认为只是QTP的一个很好的补充，对于一些对象库不能解决的问题，可以用描述性编程来解决；
个人不太赞同整个测试脚本全部用描述性编程来解决的方案。。。。。

作者: songfun 时间: 2007-8-14 02:32
最近工作忙，竟然才发现qtp版有这样的帖子。
有争论才有进步，不过我希望大家不因此变为谩骂。

yabest提了一些不错的观点，也看的出yabest兄弟对对象库的偏执——请允许我这么形容你：）
不过，一个高层次的QTP使用者应该“草木竹石，不滞于物”，对象库的确是一个精华，但描述性编程也有它适用的场合——没必要厚此薄彼，您说呢？

原帖由 yabest 于 2007-8-10 18:36 发表
可笑得都有点生气，还是等晚上消消气了再说！

————————————————————————————————————————————————————————
继续说：

视频1：测试人员在Excel里 ...

作者: 杀人跳舞 时间: 2007-8-14 09:28
宋老大发话了，顶

作者: wtucel 时间: 2007-8-14 09:46
偏题了啊,怎么又回到讨论对象库和描述性编程上面来了啊.

大家应该是讨论自动化框架吧,不管对象库也好,描述编程也罢,其框架的原理应该一样的吧

不外乎分层、封装、重用、数据驱动吧？？

作者: songfun 时间: 2007-8-14 10:13
小女生，最近工作怎么样啊？sdlkfj2
btw：你的昵称很酷，是不是很喜欢甄子丹？那快去看导火线吧，呵呵

原帖由 杀人跳舞 于 2007-8-14 09:28 发表
宋老大发话了，顶

作者: yabest 时间: 2007-8-14 10:14

原帖由 songfun 于 2007-8-14 02:32 发表
最近工作忙，竟然才发现qtp版有这样的帖子。
有争论才有进步，不过我希望大家不因此变为谩骂。

版主批评的对，可能我对培训师对梦醒十分的期望和要求比较高，所以言辞过激了，应该多克制。

yabest提了一些不错的观点，也看的出yabest兄弟对对象库的偏执——请允许我这么形容你：）
不过，一个高层次的QTP使用者应该“草木竹石，不滞于物”，对象库的确是一个精华，但描述性编程也有它适用的场合——没必要厚此薄彼，您说呢？

呵呵，其实对象库和描述性比较起来，描述性编程我玩的更溜一点！而且在工作中，适合描述性编程的地方，我是不会吝啬的。
因为搞技术的，都喜欢玩技术的！描述性编程更有可玩性，对象库啥都给你自动做好了，没啥玩的啊！
但是玩归玩，我可不会误了工作。描述性有它的弊端，所以我对它的使用是很克制的。
因为相比这种单纯技术的玩法，我更喜欢整体开发体系的优美、简洁和高效。或许这是更高层次的玩法，而且这种玩法不会误了你的工作。

作者: qiubole 时间: 2007-8-14 10:38
标题: 支持梦醒十分
一个人拿出自己的东西出来，本来就是非常有勇气的事情。

看了好几个贴子LZ以及QTP高手的用词，感觉非常好笑，那才叫真的以小人之心。。。啥的。

对象库及描述性语言各有优缺点，结合并均衡才是王道。
加入对象库是为了简便，否则QTP的关键字驱动何来优势可言。

再说框架了，什么叫框架，一定要神乎其神才能称为框架？这和模式一样，那么多设计模式，其实大多数人用着用着，不知不觉就已经使用模式了，何必在字眼上较劲。

仁者见仁，智者见智的结果，做测试本来就是抱着一种怀疑的态度去看待一切，这么容易就会被误解了？

你在人家贴子里发个言说了就行了，何必再开一贴出来。

作者: yabest 时间: 2007-8-14 11:47

原帖由 qiubole 于 2007-8-14 10:38 发表
...
你在人家贴子里发个言说了就行了，何必再开一贴出来。
...

呵呵，这我也不想啊，但是在垃圾贴里没办法讨论的！
不信你去原帖看看，就知道只要有附件下载并需要点数的帖子，马上就会被“点数不够”等垃圾回复淹没，变成垃圾帖了！
所以觉得论坛这种设计很有问题，只会逼人家发垃圾回复，把好好的一个帖子垃圾化，没有意义，害处多多。

作者: suifengpiao 时间: 2007-8-15 10:11

原帖由 loho1968 于 2007-8-13 21:26 发表

同意，如果软件没有稳定，使用自动化测试，除非你的自动化测试非常强壮。
我试验了模仿Wr的EMOS(http://www.cbueche.de/)，已经全部实现了。然后对同样的测试，使用录制+修改+编程。得出如下感觉

１、如 ...

loho1968,你好;你发得那个图片看不清楚,能否发到我得邮箱里面,谢谢!

作者: hehemeimei 时间: 2007-8-15 11:28
支持梦醒十分。

作者: jackymail 时间: 2007-8-15 12:14
标题: 我都不知道应该支持谁。
一头是我顶礼膜拜的对象。。yabest。
一头是我的职业目标---通过qtp培训骗钱。

还是继续学习吧。

yabest其实也没什么具体的框架可以拿出来，我能感觉到，他只是希望一切都很简捷。相对模块化一些就够了，不需要什么复杂的转变，而后工程化让其更加复杂。

梦醒十分属于术业有专攻的类型。他的学生肯定嗷嗷崇拜他。。。

点评完毕，欢迎拍砖。。。

作者: jackymail 时间: 2007-8-15 12:15
顺便说一句：yabest.我看了你们的帖子，梦醒十分没有恶意。请不要多想。完全在讨论的框架内。。。

作者: jackymail 时间: 2007-8-15 12:17
不行，还要补充一下。
梦醒十分，你的卖帖子的行为实在不好。就算不卖也有很多人回复，那样会更有意义。

作者: chenjie021 时间: 2007-8-15 12:35
看到眼花,但还没明白你们讨论的框架该怎么写,请高手指明

作者: 梦醒十分 时间: 2007-8-15 13:39

原帖由 jackymail 于 2007-8-15 12:17 发表
不行，还要补充一下。
梦醒十分，你的卖帖子的行为实在不好。就算不卖也有很多人回复，那样会更有意义。

我没有卖贴子呀，只是做完就传上去了，也没做任何设置，就希望有更多的人能看到。
够不够分下载，是管理员定义的吧。

作者: ∮随风而去~ 时间: 2007-8-15 13:52

原帖由 qiubole 于 2007-8-14 10:38 发表
一个人拿出自己的东西出来，本来就是非常有勇气的事情。

看了好几个贴子LZ以及QTP高手的用词，感觉非常好笑，那才叫真的以小人之心。。。啥的。

对象库及描述性语言各有优缺点，结合并均衡才是王道。
加 ...

强烈支持~
别个免费的做成这样的已经不简单了好不?~
为什么不做点比他好的呢却只在这那个那个呢?~

作者: wtucel 时间: 2007-8-15 15:44
这个帖子太多口水了,真正谈技术的回复没几个啊,还以为可以讨论出个框架的基本模型来

结果没想到又变成XXX粉丝与XXX粉丝的口水大战

作者: jackymail 时间: 2007-8-15 15:46
楼上你来个框架看看。

作者: Dorpnight 时间: 2007-8-15 17:49
标题: 回复 #1 yabest 的帖子
搞不清楚那个梦醒时分为什么要用QTP这个工具去搭建他的什么框架，如果只是拿出来做为抛砖引玉也就算了，竟然要靠这个来给别人做培训。对象库是qtp的精华，他舍了命都要把他给删掉。我看到他去点那个对象库的时候非常的困惑，等他移动那只愚蠢的鼠标把对象删掉时，我一口血喷到屏幕上！！！
梦醒时分到底懂不懂qtp啊？！！对它的对象库认识怎么这么的肤浅！！！还错误的引导新手。这比不发贴更可恨！！！因为不懂对象库的人很容易就让他给误导了！！！

第二点，梦醒时分的框架是什么类型的框架？什么架构？！这些都不说，我也没看出来，不知道他是自己也不知道还是等着别人上当呢？！

作者: Dorpnight 时间: 2007-8-15 17:52
标题: 回复 #4 dionysus 的帖子
晕，多语言就更应该用对象库了！！

作者: jackymail 时间: 2007-8-15 17:54
谁要真牛就来个像样点的框架。口水多了确实不太好。已经都52楼了。

作者: 423799223 时间: 2007-8-16 08:29
梦醒十分也够伤心的哦
支持下

作者: 梦醒十分 时间: 2007-8-16 09:58

原帖由 423799223 于 2007-8-16 08:29 发表
梦醒十分也够伤心的哦
支持下

我开心！
哇哈哈，果奶（插播广告）
我也顶呀！！！

作者: 梦醒十分 时间: 2007-8-16 10:07

原帖由 Dorpnight 于 2007-8-15 17:52 发表
晕，多语言就更应该用对象库了！！

一个被测程序有几K个对象，要在7，8个语言平台上运行，你想在每个语言平台上把几K个对象都折腾进对象库？
我的方法，只给我英语平台就能做出一套通用于多语言的脚本（不用再去设置什么语言变量，也不用环境变量去替换各个属性值。）

作者: jianglm 时间: 2007-8-16 10:37

原帖由 梦醒十分 于 2007-8-16 09:58 发表

我开心！
哇哈哈，果奶（插播广告）
我也顶呀！！！

态度决定一切sdlkfj5

开心就好!sdlkfj3

作者: yabest 时间: 2007-8-16 10:38

原帖由 梦醒十分 于 2007-8-16 10:07 发表

一个被测程序有几K个对象，要在7，8个语言平台上运行，你想在每个语言平台上把几K个对象都折腾进对象库？
我的方法，只给我英语平台就能做出一套通用于多语言的脚本（不用再去设置什么语言变量，也不用环境变 ...

哎，别犯职业病啊！要说就直接说，不要来个“且听下回分解”啊！
这个我倒是挺好奇的，不过对可行性感到怀疑。

[ 本帖最后由 yabest 于 2007-8-16 10:40 编辑 ]

作者: 厍仕杰 时间: 2007-8-16 10:40
学什么都是从一个幼稚走向成熟的过程。
如果弄一个很高深的视频给大家没几个能看得明白
其实高深的东西在实际中意义并不大
越简单的东西在越有意义。
为什么自动化不就是为了简单高效么？
不要一味的追求效果啊什么的
达到我们的测试目的就行了呗

作者: Dorpnight 时间: 2007-8-16 10:46

原帖由 梦醒十分 于 2007-8-16 10:07 发表

一个被测程序有几K个对象，要在7，8个语言平台上运行，你想在每个语言平台上把几K个对象都折腾进对象库？
我的方法，只给我英语平台就能做出一套通用于多语言的脚本（不用再去设置什么语言变量，也不用环境变 ...

这样就是框架了？真是可笑。非常的质疑你是否真的懂框架

作者: 梦醒十分 时间: 2007-8-16 11:41
欢迎大家批评指导：
视频1：
   http://bbs.51testing.com/thread-83167-1-1.html
视频2：
   http://bbs.51testing.com/thread-86351-1-1.html
视频3：
   http://bbs.51testing.com/thread-86353-1-2.html
QTP学习笔记：QTP的127个问题。
   http://bbs.51testing.com/viewthr ... 2&highlight=127

作者: dionysus 时间: 2007-8-16 13:12

原帖由 yabest 于 2007-8-16 10:38 发表

哎，别犯职业病啊！要说就直接说，不要来个“且听下回分解”啊！
这个我倒是挺好奇的，不过对可行性感到怀疑。

梦醒十分说的这个情况是存在的，我之前测试的就是一个有五个语言版本的web项目，PM让我们录制一套操作脚本用来做以后的冒烟测试，后期这个项目又追加了四个语言，并且新的版本中可能还会有更多国家的语言进入。如果在对象库中手工添加正则表达式来增加对其他语言的支持那工作量会很大，而且相当一部分的精力也将花费在对象库上，而没时间对脚本做维护修改。由于这样的种种原因，我们只能使用公司自动化组给的一套“框架”，用来对普通录制出的脚本转换成描述性编程的语句（只调用一个函数，就可以自动生成所有描述性语句，而不是我们自己去一句句修改）。说实话这样做确实节省了不少时间，但对于刚接触QTP的人来说却丧失了很多可学习的地方。
可以看得出来大家对框架，包括对象库和描述性编程的讨论都是有实际工作支持的，谁也不想承认自己现在用的就是一套蠢办法，语言激烈些挺正常。不过后来越来越多的回复开始空谈、嘲笑。我建议这样的人你们可以先闭嘴听听别人的想法，不要逮这个机会就开始乱发，没意义。

ps：看过yabest的其他帖子，对QTP的理解相当深入，希望能多看到技术总结和讨论的文章，大家可以各立旗帜，而不用非扳倒他人

[ 本帖最后由 dionysus 于 2007-8-16 13:24 编辑 ]

作者: yabest 时间: 2007-8-16 13:19

原帖由 dionysus 于 2007-8-16 13:12 发表

梦醒十分说的这个情况是存在的，我之前测试的就是一个有五个语言版本的web项目，PM让我们录制一套操作脚本用来做以后的冒烟测试，后期这个项目又追加了四个语言，并且新的版本中可能还会有更多国家的语言进 ...

我对这是很感兴趣的，他又要说不说的，所以我才要追问。不是要嘲笑啥的，你别误会！

说实在的，你前面几个帖子里写的方法，我还是没看懂！
你能不能再解释清楚一下，原来对象里用text属性识别的，你怎么进行转换，变成不用text属性，用其它属性就能识别的？

比如窗口上很多button，OK Button的属性设置原来是text=OK，你怎么转换，就变得不用Text属性，而用其它属性（包括index属性），就能识别这个OK Button的！

要知道窗口上Button可能有很多个，原来它用text来识别的，哪有index属性啊。即使有，也是index=0啊。如果把text属性去掉，那index就要变了，你哪知道index应该是多少！

[ 本帖最后由 yabest 于 2007-8-16 13:27 编辑 ]

作者: Dorpnight 时间: 2007-8-16 13:34
标题: 回复 #63 dionysus 的帖子
可以看得出来大家对框架，包括对象库和描述性编程的讨论都是有实际工作支持的，谁也不想承认自己现在用的就是一套蠢办法，语言激烈些挺正常。不过后来越来越多的回复开始空谈、嘲笑。我建议这样的人你们可以先闭嘴听听别人的想法，不要逮这个机会就开始乱发，没意义。

你这段话有含沙射影之嫌，你还是直接指明谁在进行所谓的“空谈、嘲笑”吧！因为你首先排除了yebest的嫌疑。那么请你直接指出来。

“你们可以先闭嘴听听别人的想法，不要逮这个机会就开始乱发，没意义。”
～~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
我想大家就是因为看了梦的demo，发现他在混淆概念，才立即站出来指出他的误导！可是他的态度非常的傲慢，这不是做学问应该有的态度！！包括你这个版主也应该发帖敬告大家，指明梦的demo不是什么所谓的framework!!有很多的人在跟贴向梦请教，但是他的反应是什么？！！大概他在等着别人给他送了钱以后，再单独说吧！！

知识是共享的，你不愿意没有关系，但装神弄鬼糊弄别人就有失厚道！！！包括你这个版主！！

你可以封我的id，我无所谓！！
但是让我看到不平不对的事不说，我办不到！！！

不懂装懂的人不应该得到庇护！！！不懂装懂还要以此骗钱的更应受到谴责！！

[ 本帖最后由 Dorpnight 于 2007-8-16 13:37 编辑 ]

作者: yabest 时间: 2007-8-16 13:51

原帖由 Dorpnight 于 2007-8-16 13:34 发表
。。。

唉，别这样激动啊。
这个世界各人有各人的想法，没办法也不可能统一的。
反正每个人都要为自己的想法负责的，你也不可能替别人做主的，而且你也不是绝对正确的。
所以还是尽量宽容点、克制点好了！
也不是什么大不了的事，别人犯错了也死不了人。

作者: 梦醒十分 时间: 2007-8-16 14:42
呵呵，没想到几个小视频引得天下大乱。
找我培训的屈指可数，却引来了大批猎头，测试人事，哥们改行做HR了，
帮失业的或想跳的兄弟找工作，总是件善事吧，不会挨砖了吧。
如您公司想招测试人员请您找我，我光在MSN上就有超500位的测试同仁，另有自己的一个测试人才库。
如您是测试人员正处于失业或想有更好的发展，也请联系我，我几乎在每个测试公司内部都有线人，帮你推荐。

作者: dionysus 时间: 2007-8-16 14:43

原帖由 yabest 于 2007-8-16 13:19 发表

我对这是很感兴趣的，他又要说不说的，所以我才要追问。不是要嘲笑啥的，你别误会！

说实在的，你前面几个帖子里写的方法，我还是没看懂！
你能不能再解释清楚一下，原来对象里用text属性识别的，你怎么 ...

因为这个“框架”不是我写的，我只是拿来看过，所以只能从我的理解说起，有不对的地方大家就分析着取舍吧。首先需要重新定义QTP识别对象的必要属性，将index或location或nativeclass等属性设置为必须参与识别的（这个可以通过vbs等实现），之后录制操作，通过调用一个函数库，将所有录制下来的对象得到其index和其他属性值，并重新将语句变为描述性语句。我不知道这个算不算是框架。目前我能看得明白的也就是这些了。

作者: jackymail 时间: 2007-8-16 15:00

原帖由 梦醒十分 于 2007-8-16 14:42 发表
呵呵，没想到几个小视频引得天下大乱。
找我培训的屈指可数，却引来了大批猎头，测试人事，哥们改行做HR了，
帮失业的或想跳的兄弟找工作，总是件善事吧，不会挨砖了吧。
如您公司想招测试人员请您找我，我光 ...

大哥，把你的资源给我共享一下啊。

作者: toneyzhang 时间: 2007-8-17 00:31
在下

作者: wtucel 时间: 2007-8-17 09:10

原帖由 dionysus 于 2007-8-16 14:43 发表

因为这个“框架”不是我写的，我只是拿来看过，所以只能从我的理解说起，有不对的地方大家就分析着取舍吧。首先需要重新定义QTP识别对象的必要属性，将index或location或nativeclass等属性设置为必须参与识别 ...

说说我的观点:

我认为梦醒十分的视频严格上来说确实算不上QTP框架,只能说是一种方法,将录制的对象库语言转化为描述性语言的方法. 关于自动化框架的讨

论大家可以看看http://bbs.51testing.com/viewthr ... =%D7%D4%B6%AF%BB%AF,我觉得很不错

这两天也试着在写将录制的语言转化为描述性的函数,但是遇到一些问题,不知道斑竹能不能共享一下你的那个函数啊,大家学习学习

作者: vickywang_no1 时间: 2007-8-17 10:01
这个贴好。

作者: fennek 时间: 2007-8-17 11:09
我说些貌似题外话的东西：
看了半天，唯独没有人肯出来说说到底什么是自动化测试框架，我建议有兴趣的人去看看STAF和SAFS里面对自动化框架的介绍：推荐Carl Nagle的文章<Test Automation Frameworks>。
链接：http://safsdev.sourceforge.net/F ... ationFrameworks.htm
自动化框架有点类似于开发人员的IDE环境，而自动化工具是应该嵌入到这个环境中的，框架的目的就是重用、扩展和维护我们的自动化测试工作，同时持这一观点的人认为自动化测试应该完全算是一项开发工作（测试开发正是大多数测试组织的弱项和软肋）。

作者: yabest 时间: 2007-8-17 14:37

原帖由 fennek 于 2007-8-17 11:09 发表
我说些貌似题外话的东西：
看了半天，唯独没有人肯出来说说到底什么是自动化测试框架，我建议有兴趣的人去看看STAF和SAFS里面对自动化框架的介绍：推荐Carl Nagle的文章。
链接：http://safsdev.sourceforge. ...

这文章以前有看过，开始期望还挺高的，可是看过后，很失望。
说实在的，我觉得这些在Excel里写伪码，或者啥数据驱动、表格驱动等方式的框架，都是花哨的，功能很受限，根本就不实用。

[ 本帖最后由 yabest 于 2007-8-17 14:40 编辑 ]

作者: leoomo 时间: 2007-8-17 19:29
哇塞

英雄会～

作者: lizkli 时间: 2007-8-20 11:33
sdlkfj5

作者: jackei 时间: 2007-8-21 16:28
希望有过非商业工具自动化实施经验的同行来参与讨论一下。

自动化工具的某些特性是有它的用处，但是也很容易局限了实现的思路；究竟使用哪种方法实现自动化测试才好？自己在项目中完全实施一遍就明白了。

个人看法：纯粹的关键字驱动框架本身的开发和维护成本太高，特别是随着框架变得日益庞大时，对于框架的扩展和维护都会变得日益困难。

就像上面 loho1968 朋友的回帖说的一样，关键字驱动的框架在处理一些业务逻辑简单，但是重复琐碎的页面填写、验证很多时，是比较适合的。但是对于稍微复杂一些的业务规则验证，就已经显得有些不够灵活了。

就像 Selenium 自动化测试框架，有两种模式，其中 Core 模式就是一个 100％的纯粹的关键字驱动框架，如果在一个实际的项目中应用比较过 Core 模式和 Remote Control 模式，就知道到底哪种更有优势了。

最后，说点偏激的话。很多商业工具大肆宣扬的特性是厂家希望拿来卖的，而未必就是最适合和你最需要的。软件测试自动化说到底还是一个开发工作，如果真的想掌握好这门技术，要么有两到三年的开发经验打底，要么就认认真真研究一个开源框架，当需要用到某个商业工具中已经提供的功能时，就自己实现它。等到你真的在一个项目中实施了自动化测试后，就抓到它的真谛了。
对于一个没有开发经验的新手来说，是不可能通过商业工具真正掌握自动化测试技术的。

作者: gy21st 时间: 2007-8-21 17:11
这个主题很火,个人的意见:

QTP本来就是提供一个自动化测试的框架.再去提炼,仅仅从工具上去琢磨,意义不会很大.
我们更应该和具体被测对象结合提炼框架.就是不同的应用程序和测试对象,要进行具体设计.这就和开发过程中的概要设计是一样的.找出通用的东西,划分模块,确定接口,列出测试点和常变化的东西.这显然是一个设计的过程.完全可以通用软件开发过程中的设计方法.

就像QTP中的例子flight,实际上对函数的设计和把握是很好的,虽然简单,但lib设计得很不错的.简洁又通用,我们是否该认为是一个很好的框架?

至于对象的识别,是用描述性编程还是对象库,都只是一种方法,不同的被测对象的特性决定了采取不同的方法.

作者: 槛外人 时间: 2007-8-21 17:47
标题: 看到了这个帖子，我也看了下视频，过来说2句
自动化测试框架从我的理解来看，至少包含测试数据的组织、错误处理及日志处理、验证点的实现机制等这些内容，说到底是一种解决方案。

而梦醒十分所讲的内容，其实只是一种技巧，应用的范围不知道是什么样的？什么样的项目，测试的工期等等。这些都不知道。如果对于项目测试来讲，单靠测试工程师去录制，然后生成描述性编程，请允许我说一下这太可笑了。尝试做过自动化测试的人会明白我为什么这样说。

另外，对于国际化的测试，用描述性编程也不见得是最合适的办法。至少别的工具都会提供依赖对象库中的某个属性去查找对象，如果你需要使用index去定位唯一一个对象的话，设置也是非常简单的（楼上有的朋友就说到了ROBOT）。描述性编程只适用于类似动态出现的对象，例如选择某个按钮会出现某些对象，当然也不绝对。

对于QTP来讲，使用对象库的方式也不局限于简单的录制、回放。可以在这个基础上开发很多通用的处理。对象入库后，可以自己写脚本实现不同的业务流程的。

最后，不得不说，现在社会上的一些人已经丧失了基本的价值观，为了钱，什么不靠谱的事都敢拿来说。做学问，还是要严谨一些。

作者: 梦醒十分 时间: 2007-8-22 09:17
批评的好，支持！顶上去！

作者: marco 时间: 2007-8-22 09:56
什么是好的自动化框架，在一国外网站看到的，觉得很有道理

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.

作者: yabest 时间: 2007-8-22 10:09

原帖由 marco 于 2007-8-22 09:56 发表
什么是好的自动化框架，在一国外网站看到的，觉得很有道理
什么是好的自动化框架，在一国外网站看到的，觉得很有道理

A good framework allows users who dont know anything about automation to create automated test cases.
...

这只是可笑的妄想。太简单的东西，往往都沦为花哨的玩具，玩玩可以，不能实用！

作者: testdear 时间: 2007-8-22 10:21
runner视频及其他资料 ding

作者: fennek 时间: 2007-8-22 11:46

原帖由 yabest 于 2007-8-17 14:37 发表

这文章以前有看过，开始期望还挺高的，可是看过后，很失望。
说实在的，我觉得这些在Excel里写伪码，或者啥数据驱动、表格驱动等方式的框架，都是花哨的，功能很受限，根本就不实用。

可能是仁者见仁智者见智吧，文章本身一直在传达这样的一种信息，做自动化框架就是开发一个项目，测试开发人员本身应该具备良好甚至是优秀的开发能力，这和国内往往测试人员根本不懂开发的现状有比较大的出入。
至于啥数据驱动、表格驱动这些都是围绕着一个观点出发的，就是让我们的测试设计人员--（测试设计和开发人员是完全不同的角色，承担的工作任务也不同，这是前提，国内喜欢把角色混淆，或是根本无视这些角色划分，责任不明工作不专）远离框架本身的复杂度，为他们提供一个快捷方便的应用接口罢了，花哨也好，功能受限也好，根本的思想还是值得借鉴的。

另外，如果真要使用STAF，没有扎实的编程功夫是比较难做的，所以请不要轻率的下结论。

作者: fennek 时间: 2007-8-22 11:48

原帖由 yabest 于 2007-8-22 10:09 发表

这只是可笑的妄想。太简单的东西，往往都沦为花哨的玩具，玩玩可以，不能实用！

简单？？你看过STAF的源码吗？看过SAFS的源码吗？？
应用接口简单那是正常的，总不能让我们的测试设计人员人人都是编程高手吧。
实用，啥叫实用？？那是建立在会用的基础之上的。~~~~

作者: yabest 时间: 2007-8-22 13:36

原帖由 fennek 于 2007-8-22 11:48 发表

简单？？你看过STAF的源码吗？看过SAFS的源码吗？？
应用接口简单那是正常的，总不能让我们的测试设计人员人人都是编程高手吧。
实用，啥叫实用？？那是建立在会用的基础之上的。~~~~

看了SAFS的介绍，那是一个通用测试运行平台吧（很多公司都有这样的平台），跟我们这里讨论的简化QTP开发和维护工作的QTP自动化框架是两回事。

你都没明白我的意思！
一般而言，一个工具，功能越强，使用就越复杂！（就像画笔和PS这两个画图软件）
虽然可以想办法，做一些封装和固化，来减少使用复杂度，但相应的，却失去了灵活性。
这是个度的问题，也是两难的问题。为了使用简单，就要做封装和固化；但封装和固化越多，功能就越弱、越不灵活。
等你弄到非常非常简单的时候，这工具往往就被你弄得非常僵化了，功能超弱，只能玩玩，不再具有实用性了。

[ 本帖最后由 yabest 于 2007-8-22 13:43 编辑 ]

作者: yabest 时间: 2007-8-22 13:39

原帖由 marco 于 2007-8-22 09:56 发表
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.”

作者: lyscu 时间: 2007-8-24 12:38
标题: 相互学习
相互学习切磋！

作者: fennek 时间: 2007-8-24 14:52

原帖由 yabest 于 2007-8-22 13:39 发表

所以不要指望有这种“good framework“，可以”allows users who dont know anything about automation to create automated test cases.”

厚厚，说严重点，你这是扼杀人们的希望，哈哈。~~~
自动化框架如同自动化测试本身一样，它不是银弹，但起码给大多数迷失于自动化工具的人以希望啊。

作者: fennek 时间: 2007-8-24 15:06

原帖由 yabest 于 2007-8-22 13:36 发表

看了SAFS的介绍，那是一个通用测试运行平台吧（很多公司都有这样的平台），跟我们这里讨论的简化QTP开发和维护工作的QTP自动化框架是两回事。

你都没明白我的意思！
一般而言，一个工具，功能越强，使 ...

我只是看到你对STAF的评价，想对此表达一下自己的看法~~~就QTP本身我不会做过多的讨论。

另外，什么是好框架？？很简单，能帮助我的自动化工具为我更好的工作的框架，就是好框架（虽然有点拗口）。
还是仁者见仁智者见智吧~~~
至于你所提到的简单性，我不敢苟同，“封装和固化以致失去灵活性”，貌似这几者之间没有任何联系吧，不然面向对象的开发也不会提倡什么内聚、低耦，接口抽象化之类的原则了吧。

作者: yabest 时间: 2007-8-24 16:46

原帖由 fennek 于 2007-8-24 14:52 发表

厚厚，说严重点，你这是扼杀人们的希望，哈哈。~~~
自动化框架如同自动化测试本身一样，它不是银弹，但起码给大多数迷失于自动化工具的人以希望啊。

呵呵，我是要扼杀掉人们的希望，不，应该说是现阶段不该有的奢望！

除非真正的人工智能出现，电脑也能象人那样思考，否则，还是老老实实的干活吧，别做梦了。

作者: yabest 时间: 2007-8-24 16:52

原帖由 fennek 于 2007-8-24 15:06 发表

至于你所提到的简单性，我不敢苟同，“封装和固化以致失去灵活性”，貌似这几者之间没有任何联系吧，不然面向对象的开发也不会提倡什么内聚、低耦，接口抽象化之类的原则了吧。

看贴不认真，都说了这是个度的问题，再仔细看看我的帖子吧

虽然可以想办法，做一些封装和固化，来减少使用复杂度，但相应的，却失去了灵活性。
这是个度的问题，也是两难的问题。为了使用简单，就要做封装和固化；但封装和固化越多，功能就越弱、越不灵活。
等你弄到非常非常简单的时候，这工具往往就被你弄得非常僵化了，功能超弱，只能玩玩，不再具有实用性了。

现在用对象封装的东西多了，象各种控件。
可是你也知道越是功能强大的控件，它的接口就越多！
为什么用了面向对象的技术了，用对象的方法做了封装了，它还是这么复杂呢？！

这是它的强大功能所决定的！真要把它封装得非常简单的话，它也就变成一个功能简单的对象了。

[ 本帖最后由 yabest 于 2007-8-24 16:58 编辑 ]

作者: lyscu 时间: 2007-8-24 17:08
精神值得学习

作者: fennek 时间: 2007-8-27 11:04

原帖由 yabest 于 2007-8-24 16:52 发表

看贴不认真，都说了这是个度的问题，再仔细看看我的帖子吧

虽然可以想办法，做一些封装和固化，来减少使用复杂度，但相应的，却失去了灵活性。
这是个度的问题，也是两难的问题。为了使用简单，就要做封 ...

不是看帖不认真，老实地说我觉得这几句话有点不知所云，当然可能是我自己的理解水平有限所致，还请见谅~！~呵呵

作者: fennek 时间: 2007-8-27 11:06

原帖由 yabest 于 2007-8-24 16:46 发表

呵呵，我是要扼杀掉人们的希望，不，应该说是现阶段不该有的奢望！

除非真正的人工智能出现，电脑也能象人那样思考，否则，还是老老实实的干活吧，别做梦了。

干活一定是老老实实的，但这梦也是得不停地做下去的，起码还有希望。
不过干活和做梦似乎两者之间并没有多少逻辑关系哦，哈哈哈~~~希望和梦想总是需要人去实现的~~~

作者: reverie128 时间: 2007-8-30 11:21
标题: 好帖啊!!
支持　槛外人，　评论很中肯　！
支持　yabest , 　对qtp理解很深刻　！
支持　梦醒　，　共享的精神很不错，其他。。。。。。

作者: gwell 时间: 2007-11-29 11:25
好啊。高手论道，有火花却无攻击，

作者: gwell 时间: 2007-11-29 11:37
晕啊，这个贴子已经3个月没人顶了啊，不过对于我这样的新手来说却很有价值哦

作者: hsjzfling 时间: 2007-11-29 17:25
第一次来看这个帖子。。。
两个月前自己开始尝试写个框架，所以凡是关于框架的帖子我都没怎么关注，主要不想被局限了思维，可结果才写了一周多刚写完控制部分就被其它事情干扰搁浅到现在，让几位朋友失望了~

框架这个东西确实仁者见仁智者见智，站的角度高度不同，思维看法都会有很大的差别。

在我的设计中，主要将框架分为两大部分，一部分为控制函数部分，这部分是和业务隔离开的，可以直接复用。而另一部分为业务相关的测试套(可扩展支持多种，目前仅开发了一种)，测试用例(可以有多种规范，目前也仅制定一种)，公共函数库(目前提供两种公共函数模式：业务模块模式和动作模式)，数据驱动方式(可支持多种格式数据文件)，日志函数(可根据需要选择记录内容、方式)，数据输出(也可合并到日志中)等。
当然以上也只是简单的分类，还有很多细节可以商榷，比如日志输出也可划分到控制函数部分去，通过参数控制输出模式。

整个框架通过驱动函数调用主控函数，再调用各个测试套依次执行各个测试用例。

等有时间了我把代码整理整理，纯粹是兴趣去研究的，在公司根本就不会去用到这些(偶只是个做手工系统测试的初级Tester

)

漏了项关键内容:公共函数库，这里补上

[ 本帖最后由 hsjzfling 于 2007-11-29 17:51 编辑 ]

作者: hsjzfling 时间: 2007-11-29 17:46
关键就是要实用，大家也都不想光看大道理，但实际对于写一个实用的框架却没什么大的帮助。
顺便提个观点，就国内的测试状况来看，貌似不太适合使用关键字驱动。。。综合考虑成本、效率等因素来看数据驱动就足够了

楼上不少人的观点都是不错。
yabest提到的不少观点我觉得大家都可以借鉴下（除了对对象库的偏执，不过他也提到了，有需要的时候也会用到的，哪个方便哪个效率高就用哪个呗～～），比如"功能越强，使用就越复杂"，确实如此，我在框架中每加个功能，就要多一个接口(或多个)来支持，使用时就要多输入一个参数多调用一个函数。。。不过可以加入框架默认设置：）

斑竹的将对象库中的对象自动转化为描述性语言的实现过程偶也很好奇，请解惑

说实话"梦醒十分"的视频我还真没看过，不过看看大家的评论也可以有一定了解了，不讨论它是否实用，仅内容而言那个最多只能算是框架的冰山一角，以偏概全误导大家就不好了。

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