f
期待各位高手进一步的讨论.谢谢! 原帖由 dionysus 于 2007-8-11 22:17 发表 http://bbs.51testing.com/images/common/back.gif
就如你举的这个例子，我可以使用GetTOProperty函数取得"OK"的index或其他属性值，最后将取得的值替换掉这个逻辑名称，生成一个新的语句，如Button("index:=1").Click这样的语句，再次回放的时候qtp就不会受语言 ...
明白BZ的意思了,但是只用index属性肯定是不行的,比如button,可以用GetTOProperty先取对象库里的name和index属性,然后转化为描述性大概就是Button("name:="&Name,"index:="&Index),这样转化后的脚本应该没有问题,但是对于检查点的转换有点麻烦了,实际值可以用GetROProperty来取得,但是对于录制脚本中我们设置的预期值,转化函数怎么去取得呢?? 原帖由 QTP高手 于 2007-8-11 22:59 发表 http://bbs.51testing.com/images/common/back.gif
在答复的dionyons一个问题，如果梦醒十分，是把QTP语言转化成描述性语言来写，那他就太傻了点。我想十之七八是借助了EMOS的做法，你可以去看看EMOS的源码。说起来也挺简单的！
EMOS有QTP的自动化框架么? 我只见过WinRunner的,确实很牛B,因为我看不懂sdlkfj8
有的QTP的话共享一下撒 难得看到为一个技术,互相争论的帖子.不错,气氛蛮好,呵呵 呵呵，我也有同感 多说无意，认为别人做的不好就把你觉得好的东西拿出来给我们看看，我是新手，没有觉得梦醒十分的视频有什么不好。相反对我还有有一定帮助的～ 原帖由 lengz 于 2007-8-13 10:25 发表 http://bbs.51testing.com/images/common/back.gif
多说无意，认为别人做的不好就把你觉得好的东西拿出来给我们看看，我是新手，没有觉得梦醒十分的视频有什么不好。相反对我还有有一定帮助的～
可以说说对你有什么帮助吗？
还有你会按这样的思想去做QTP自动化吗？
另外我写的帖子也不少了，都在这个版里，你自己可去看的。 原帖由 wtucel 于 2007-8-13 09:40 发表 http://bbs.51testing.com/images/common/back.gif
EMOS有QTP的自动化框架么? 我只见过WinRunner的,确实很牛B,因为我看不懂sdlkfj8
有的QTP的话共享一下撒
是指这个吗？http://www.cbueche.de/ 如果是基于自己的产品，有大量的标准的操作、业务流程。又没有合格的自动化测试人员的情况下，使用框架的方式，不失为一种选择。 我觉得用描述性编程有一个好处就是可以做到测试的前期介入,只要跟开发约定并规范好了各个控件的话,就可以在产品还没有开发出来的时候进行自动化脚本的编写.像梦醒十分的录象,tester可以根据需求来写测试用例,转化为描述性语言,产品出来后再调试,可以节省很多时间呢. 原帖由 wtucel 于 2007-8-13 19:59 发表 http://bbs.51testing.com/images/common/back.gif
我觉得用描述性编程有一个好处就是可以做到测试的前期介入,只要跟开发约定并规范好了各个控件的话,就可以在产品还没有开发出来的时候进行自动化脚本的编写.像梦醒十分的录象,tester可以根据需求来写测试用例,转 ...
这是一个技术优点，不过还是不要这样做的好！
因为自动化测试一般只用来做回归测试，只测试已通过手工测试的、成熟的回归性用例！
你说的这一种情况，还是不要做自动化的好，等产品出来了，先做手工测试吧。等稳定了，再做自动化测试。 原帖由 yabest 于 2007-8-13 20:35 发表 http://bbs.51testing.com/images/common/back.gif
这是一个技术优点，不过还是不要这样做的好！
因为自动化测试一般只用来做回归测试，只测试已通过手工测试的、成熟的回归性用例！
你说的这一种情况，还是不要做自动化的好，等产品出来了，先做手工测试吧 ...
同意，如果软件没有稳定，使用自动化测试，除非你的自动化测试非常强壮。
我试验了模仿Wr的EMOS(http://www.cbueche.de/)，已经全部实现了。然后对同样的测试，使用录制+修改+编程。得出如下感觉
１、如果只有简单的测试功能，简单的数据输入，框架可以支持。
２、但是，如果测试的功能有一些业务流程，逻辑判断的，结果检查的话，架构的支持就有限了。
３、框架的调试非常困难。 原帖由 loho1968 于 2007-8-13 21:26 发表 http://bbs.51testing.com/images/common/back.gif
同意，如果软件没有稳定，使用自动化测试，除非你的自动化测试非常强壮。
我试验了模仿Wr的EMOS(http://www.cbueche.de/)，已经全部实现了。然后对同样的测试，使用录制+修改+编程。得出如下感觉
...
看到这样表格的复杂，对比一下录制的轻松，我只能深深的叹口气，“何苦呢。。。” 看了上面这么多讨论，说说我自己的看法
1.QTP的精髓是对象库，我们可以通过Share OR或者普通OR配合正则表达式，就可以解决绝大多数的问题；
2。描述性编程个人认为只是QTP的一个很好的补充，对于一些对象库不能解决的问题，可以用描述性编程来解决；
个人不太赞同整个测试脚本全部用描述性编程来解决的方案。。。。。 最近工作忙，竟然才发现qtp版有这样的帖子。
有争论才有进步，不过我希望大家不因此变为谩骂。
yabest提了一些不错的观点，也看的出yabest兄弟对对象库的偏执——请允许我这么形容你：）
不过，一个高层次的QTP使用者应该“草木竹石，不滞于物”，对象库的确是一个精华，但描述性编程也有它适用的场合——没必要厚此薄彼，您说呢？
原帖由 yabest 于 2007-8-10 18:36 发表 http://bbs.51testing.com/images/common/back.gif
可笑得都有点生气，还是等晚上消消气了再说！
————————————————————————————————————————————————————————
继续说：
视频1：测试人员在Excel里 ... 宋老大发话了，顶 偏题了啊,怎么又回到讨论对象库和描述性编程上面来了啊.
大家应该是讨论自动化框架吧,不管对象库也好,描述编程也罢,其框架的原理应该一样的吧
不外乎分层、封装、重用、数据驱动吧？？ 小女生，最近工作怎么样啊？sdlkfj2
btw：你的昵称很酷，是不是很喜欢甄子丹？那快去看导火线吧，呵呵
原帖由 杀人跳舞 于 2007-8-14 09:28 发表 http://bbs.51testing.com/images/common/back.gif
宋老大发话了，顶 原帖由 songfun 于 2007-8-14 02:32 发表 http://bbs.51testing.com/images/common/back.gif
最近工作忙，竟然才发现qtp版有这样的帖子。
有争论才有进步，不过我希望大家不因此变为谩骂。
版主批评的对，可能我对培训师对梦醒十分的期望和要求比较高，所以言辞过激了，应该多克制。
yabest提了一些不错的观点，也看的出yabest兄弟对对象库的偏执——请允许我这么形容你：）
不过，一个高层次的QTP使用者应该“草木竹石，不滞于物”，对象库的确是一个精华，但描述性编程也有它适用的场合——没必要厚此薄彼，您说呢？
呵呵，其实对象库和描述性比较起来，描述性编程我玩的更溜一点！而且在工作中，适合描述性编程的地方，我是不会吝啬的。
因为搞技术的，都喜欢玩技术的！描述性编程更有可玩性，对象库啥都给你自动做好了，没啥玩的啊！
但是玩归玩，我可不会误了工作。描述性有它的弊端，所以我对它的使用是很克制的。
因为相比这种单纯技术的玩法，我更喜欢整体开发体系的优美、简洁和高效。或许这是更高层次的玩法，而且这种玩法不会误了你的工作。
支持梦醒十分
一个人拿出自己的东西出来，本来就是非常有勇气的事情。看了好几个贴子LZ以及QTP高手的用词，感觉非常好笑，那才叫真的以小人之心。。。啥的。
对象库及描述性语言各有优缺点，结合并均衡才是王道。
加入对象库是为了简便，否则QTP的关键字驱动何来优势可言。
再说框架了，什么叫框架，一定要神乎其神才能称为框架？这和模式一样，那么多设计模式，其实大多数人用着用着，不知不觉就已经使用模式了，何必在字眼上较劲。
仁者见仁，智者见智的结果，做测试本来就是抱着一种怀疑的态度去看待一切，这么容易就会被误解了？
你在人家贴子里发个言说了就行了，何必再开一贴出来。
