51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: yabest
打印 上一主题 下一主题

[原创] 刚看了梦醒十分的自动化框架演示视频,感觉。。。

[复制链接]

该用户从未签到

21#
发表于 2007-8-13 09:01:42 | 只看该作者

f

期待各位高手进一步的讨论.
谢谢!
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2007-8-13 09:36:45 | 只看该作者
原帖由 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来取得,但是对于录制脚本中我们设置的预期值,转化函数怎么去取得呢??
回复 支持 反对

使用道具 举报

该用户从未签到

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


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

使用道具 举报

该用户从未签到

24#
发表于 2007-8-13 10:04:14 | 只看该作者
难得看到为一个技术,互相争论的帖子.不错,气氛蛮好,呵呵
回复 支持 反对

使用道具 举报

该用户从未签到

25#
发表于 2007-8-13 10:18:07 | 只看该作者
呵呵,我也有同感
回复 支持 反对

使用道具 举报

该用户从未签到

26#
发表于 2007-8-13 10:25:17 | 只看该作者
多说无意,认为别人做的不好就把你觉得好的东西拿出来给我们看看,我是新手,没有觉得梦醒十分的视频有什么不好。相反对我还有有一定帮助的~
回复 支持 反对

使用道具 举报

该用户从未签到

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


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

另外我写的帖子也不少了,都在这个版里,你自己可去看的。
回复 支持 反对

使用道具 举报

该用户从未签到

28#
发表于 2007-8-13 13:37:30 | 只看该作者
原帖由 wtucel 于 2007-8-13 09:40 发表


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


是指这个吗?http://www.cbueche.de/
回复 支持 反对

使用道具 举报

该用户从未签到

29#
发表于 2007-8-13 13:53:17 | 只看该作者
如果是基于自己的产品,有大量的标准的操作、业务流程。又没有合格的自动化测试人员的情况下,使用框架的方式,不失为一种选择。
回复 支持 反对

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

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


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

使用道具 举报

该用户从未签到

32#
发表于 2007-8-13 21:26:36 | 只看该作者
原帖由 yabest 于 2007-8-13 20:35 发表


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


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

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

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复 支持 反对

使用道具 举报

该用户从未签到

33#
 楼主| 发表于 2007-8-13 21:43:32 | 只看该作者
原帖由 loho1968 于 2007-8-13 21:26 发表


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

...



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

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

35#
发表于 2007-8-14 02:32:55 | 只看该作者
最近工作忙,竟然才发现qtp版有这样的帖子。
有争论才有进步,不过我希望大家不因此变为谩骂。

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


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

————————————————————————————————————————————————————————
继续说:

视频1:测试人员在Excel里 ...
回复 支持 反对

使用道具 举报

该用户从未签到

36#
发表于 2007-8-14 09:28:16 | 只看该作者
宋老大发话了,顶
回复 支持 反对

使用道具 举报

该用户从未签到

37#
发表于 2007-8-14 09:46:10 | 只看该作者
偏题了啊,怎么又回到讨论对象库和描述性编程上面来了啊.

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

不外乎分层、封装、重用、数据驱动吧??
回复 支持 反对

使用道具 举报

该用户从未签到

38#
发表于 2007-8-14 10:13:14 | 只看该作者
小女生,最近工作怎么样啊?sdlkfj2
btw:你的昵称很酷,是不是很喜欢甄子丹?那快去看导火线吧,呵呵
原帖由 杀人跳舞 于 2007-8-14 09:28 发表
宋老大发话了,顶
回复 支持 反对

使用道具 举报

该用户从未签到

39#
 楼主| 发表于 2007-8-14 10:14:42 | 只看该作者
原帖由 songfun 于 2007-8-14 02:32 发表
最近工作忙,竟然才发现qtp版有这样的帖子。
有争论才有进步,不过我希望大家不因此变为谩骂。

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

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

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

使用道具 举报

该用户从未签到

40#
发表于 2007-8-14 10:38:33 | 只看该作者

支持梦醒十分

一个人拿出自己的东西出来,本来就是非常有勇气的事情。

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

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

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

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

你在人家贴子里发个言说了就行了,何必再开一贴出来。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-23 21:21 , Processed in 0.082367 second(s), 22 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表