51Testing软件测试论坛

标题: 【运行速度】对象库与描述性 [打印本页]

作者: 假装不在 时间: 2008-8-13 12:53
标题: 【运行速度】对象库与描述性
场景：
   1，使用了QTP论坛页面中某个主题的连接link
2，为了公平起见，使用先把browser,page等对象先添加进对象库，使用描述时候只使用link点击才测试速度
   3，对象库中的link对象属性就使用了html tag 与 text

方法：一个方法至少运行5次
1，browser("...")page("....").link("....").click
平均时间是：0.501 sec

2，browser("....")page("....").link("html tag:=...","text:=....").click
平均时间是：1.031 sec

3，dim a
set a =description.creat
a("html tag:=").value=....
a("text:=").value=....
browser("....")page("....").link(a).click
平均时间是：1.060 sec

4，browser("....")page("....").link("html tag:=...","text:=....","x:="...,"y:="....).click
平均时间：0.750 sec

由上面数据（可能有点不太科学）可以得到的结论如下：
1，QTP的对象库运行速度比描述的速度有优势，但是是建立在忽悠用户的基础上（带了点感情色彩）。为什么这么说呢？
使用对象库的测试，速度确实一目了然，我们在对象库中看到的属性也就只有html tag 与value，而我们使用描述方法中使用的也是这2个，速度却是将近一半的差距。但是后来在第四个方法中，简单的添加进x,y的相对坐标后，速度却可以提高0.3sec之多？！这说明了，在描述的时候，只要给的有效属性值越多，找到对象速度越快！
为什么说忽悠用户呢？我这人心眼特坏，好吧，对象库你不老实，说明只用html tag和text的，哪么我就给你改，我随便在论坛顶了一个帖子，那个原来的帖子位置变了，大家猜用的平均时间是多少？0.653sec(有高无减)
2，论坛有人说是先拟定和虚拟的对象出来，这个说法很不科学。
3，由上面的结果可以看到了对象库的优势！这点我也不得不承认(不喜欢犯规的人)，描述的速度没有对象库实现代码的速度快，或者到这里也就应验了那句话，对象库是QTP的精华。
4，可以这么说，如果对项目的要求速度不高，可以使用描述，而且是测试人员在这个过程中享受编程乐趣的时候，大家喜欢就干吧。对于对象库来说，速度确实快（还是那句话，你作弊），而且代码速度高，适合新手（自然不是说那些用到出神入化的高手），入手快，见效好。
这就好比中药与西药。中药重调理，西药重速度...

作者: yabest 时间: 2008-8-13 13:07
速度问题其实影响不大，不用斤斤计较。我都没怎么关心，反正直觉上都觉得够快的了。

另外注意QTP提供了两种Run Mode，分别是Normal和Fast，你选了Fast模式后，速度那快得不是一点点！

作者: zte_boy 时间: 2008-8-13 13:13
理论上来说，在DP中使用描述的属性越多找到对象的速度越快，就象找一个人一样，光有名字，可能很多，还需要去定位其他信息，但如果在加上国家、省份、城市、性别、年龄等属性，那么定位就会快很多了
至于你说对象库忽悠人的那个时间问题，我不知道你的时间是怎么来获取的，而且仅仅是0.1的区别，就这点差距完全可能是其他因素造成的，如果机器当前系统资源问题等等，都可能会有这样的影响，但凭这一点我觉得还是不能说对象库忽悠你了，呵呵
对于QTP自动化测试来说，业务脚本不推荐使用DP，其实也享受不到编程的乐趣，无非都是属性的堆砌罢了，重复性劳动而已，再着，对象库确实是QTP的精华，对于企业来说，重要的是实施的效果，要考虑时间成本问题，呵呵，最好的办法还是采用共享对象库，个人看法

作者: 假装不在 时间: 2008-8-13 13:27
标题: 回复 2# 的帖子
是刚好看到有人在讨论，我就自己做做看。
我极度怀疑你是不是天天在论坛搜索中输入对象库描述这2个字眼的...

想找你，只要在论坛发帖，题目有对象库就可以了。

回复 3# 的帖子

忽悠人的地方是：
他显示说只用那2个对象属性，但实际上，他会偷偷用其它没有被勾选上的属性。这就是我说的忽悠。

[ 本帖最后由假装不在于 2008-8-13 14:10 编辑 ]

作者: kevin_swpi 时间: 2008-8-13 13:55

假装不在的研究精神值得人学习

我最近在写代码的时候
采用的是将对象抓出来放到对象文件中通过命名等来进行统一管理
然后再来手写代码封装成函数

结果发现最后主控程序在启动执行的时候速度比较慢
应该是在启动时候需要去加载检查这些这些外部调用文件吧

作者: 泥泥虫 时间: 2008-8-13 15:30
我想对象库越庞大,识别对象的速度不是越快吧?描述性编程,直接写入有效识别的对象属性识别起来不是更快?似乎,QTP也要通过匹配对象库的属性来识别对象然后执行操作??个人愚见,别见笑 ^_^

作者: 假装不在 时间: 2008-8-13 15:53
标题: 回复 6# 的帖子
对象库越庞大，速度影响不大，因为就类似简单的索引，搜索起来很简单。
找到这个对象在对象库中存在某个位置后，拿到它的属性，再去程序中找。时间没多大影响，近乎0。
但是有影响的地方是，如果对象库越来越盘大，如果早期自定义的管理方法不对，到了后期就会让你很头痛，对象如果多到很恐怖那种，估计你也跟着乱，说到底还是管理。
关于有效属性在描述中的应用，也需要多点（自然如果对速度要求不高，1 2个就够了。），而如果要和我的第4个方法一样，速度是快了，但很麻烦。
所以你说的话，前2句是有点偏差，后一句对了...
QTP的对象库就类似存储了全国人民的身份证号码一样，然后去识别并对它做操作。

作者: yabest 时间: 2008-8-13 15:57

作者: luckxiaot 时间: 2008-8-13 16:36
描述性编程是比对象库运行要慢，但是偶觉得还是可以接受的！！

作者: hsjzfling 时间: 2008-8-13 16:36
标题: 回复 1# 的帖子
lz有没尝试过将类似于browser("....")page("....").link("html tag:=...","text:=....","x:="...,"y:="....).click的语句执行个成千上万次乃至更多~

项目后期往往会做这样的测试，比如持续运行系统一周，如果大量使用这种隐式描述性编程语句的话，呵呵。。。。。。

作者: 假装不在 时间: 2008-8-13 16:47
标题: 回复 10# 的帖子
你用论坛的连接44看就知道了。添加进了X Y后效果很明显。

作者: hsjzfling 时间: 2008-8-13 16:49

原帖由 泥泥虫 于 2008-8-13 15:30 发表
我想对象库越庞大,识别对象的速度不是越快吧?描述性编程,直接写入有效识别的对象属性识别起来不是更快?似乎,QTP也要通过匹配对象库的属性来识别对象然后执行操作??个人愚见,别见笑 ^_^

关于对象库的管理，其实9.x后的关联对象库就很好的解决了这样的问题。很早以前yabest就提过Action的划分以及对象的管理问题，合理的划分Action，就会使得单个对象库文件不可能过于庞大，否则就继续拆分Action。这样的话关联对象库用起来还是很爽的。

共享对象库用的比较少，不太确定对象库过于庞大时候会不会有什么问题，这个其他兄弟应该更有话语权~

作者: 假装不在 时间: 2008-8-13 16:55
标题: 回复 12# 的帖子
是的，在9.X后使用的关联对象库确实很好的管理问题。或者QTP就还是想继续弘扬对象库，也许不久将来描述真的被对象库干掉了，就像现在一样都是大的西科医院一样。

作者: yabest 时间: 2008-8-13 16:59

原帖由 hsjzfling 于 2008-8-13 16:49 发表

关于对象库的管理，其实9.x后的关联对象库就很好的解决了这样的问题。很早以前yabest就提过Action的划分以及对象的管理问题，合理的划分Action，就会使得单个对象库文件不可能过于庞大，否则就继续拆分Action。 ...

我有这样说过吗？

我都是用函数组织代码的，只用一个main action，不用多个action的，所以更不用划分action来划分对象库。

对象库大就大了，不会有啥问题的，这点对象库数据，现代的计算机处理起来还不是小case，又不是大型数据库、海量数据。
反正我们是一个软件一个版本对应一个共享对象库文件，比如 nms_1.0.tsr , nms_2.0.tsr ,oss_2.0.tsr

作者: kevin_swpi 时间: 2008-8-13 17:03

目前我就是用的这样的方式
不过我在想函数多了...如何管理比较有效....

要准备个list菜单..不然N久后
我都不晓得都有那些函数了...

作者: 假装不在 时间: 2008-8-13 17:09
标题: 回复 14# 的帖子
因为你的名字比较有说服力。
我也是一个action使用。

函数多到不是问题，反正不同类型的函数就放在不同VBS和不同文件中就可以了。

作者: hsjzfling 时间: 2008-8-13 17:41

原帖由 yabest 于 2008-8-13 16:59 发表

我有这样说过吗？

我都是用函数组织代码的，只用一个main action，不用多个action的，所以更不用划分action来划分对象库。

对象库大就大了，不会有啥问题的，这点对象库数据，现代的计算机处理起来还不是 ...

咦。。。那是谁说过的。。。

我之前有一个框架就是仿照你的做法，用函数来组织代码，保存在vbs文件中。但是感觉在维护的时候还是有一点点麻烦的。我现在的做法就是在一个划分Action的脚本中来调试(该脚本只做调试，除了baseline版本之外就没有做版本控制了)，改完后将改动的Action更新到对应的函数与tsr文件中去。

请教下yabest兄是怎么来维护的呢？

作者: hsjzfling 时间: 2008-8-13 17:46

原帖由 假装不在 于 2008-8-13 16:47 发表
你用论坛的连接44看就知道了。添加进了X Y后效果很明显。

我又没怀疑这一点。。。我提出的是隐式描述性编程在长时间运行过程中暴露的问题。。。

作者: 假装不在 时间: 2008-8-14 09:56
标题: 回复 17# 的帖子

小数怕长算....
确实是这样，但是...

不说，一会被人群殴，但还是要来上几点...
1，对象库管理学问。对象库管理，对对象的添加，删除，修改，与否影响到上级对象的录制或者多出browser_1的问题，导致了脚本维护成本增加（这个估计要yebest来帮忙解决），但是使用描述就没有这个烦恼。
2，对象库的移植问题。这点我觉得也是需要很好的解决才能不让我对对象库的偏见。或者，导致这样的问题，其实是QTP自身对控件的识别问题。例如一个对象，不同机器上识别出来的分别是webelement和一个是link（打比方）。哪么，我们需要做的事情是：1，统一OS环境。2，导出录制机器的QTP的4个配置文件 3，导入运行机器。4不行就重装。
之前好像有位达人和我说，用公共机就好了，我相信和我说这话的高人也一定被移植问题烦过，而且这个并不是解决问题的根本方法，治标不治本，玩笑一句，你喜欢在家里安静的写代码还是喜欢在公车上写代码呢...

作者: yabest 时间: 2008-8-14 11:08

原帖由 hsjzfling 于 2008-8-13 17:41 发表

咦。。。那是谁说过的。。。

我之前有一个框架就是仿照你的做法，用函数来组织代码，保存在vbs文件中。但是感觉在维护的时候还是有一点点麻烦的。我现在的做法就是在一个划分Action的脚本中来调试(该脚本只做 ...

因为函数是放在函数库里的，QTP8.x不能直接调试库文件，所以需要调试时得把函数代码拷入Action中进行调试，调试好了再拷回库文件中。

QTP9.x就没这个问题了，库文件和Action一样可以打开、编辑、调试。

作者: yabest 时间: 2008-8-14 11:19

原帖由 假装不在 于 2008-8-14 09:56 发表

小数怕长算....
确实是这样，但是... 不说，一会被人群殴，但还是要来上几点...
1，对象库管理学问。对象库管理，对对象的添加，删除，修改，与否影响到上级对象的录制或者多出browser_1的问题，导致了脚 ...

导致 Browser、Page、Frame 录制时变成多个对象的问题，其实是参数设置问题，都是可以轻松解决的。

我们都是用一台win2000 Server作为公共的QTP服务器，大家都用远程终端服务连接上去使用QTP，跟自己机子一样，不会感觉到什么差别。

个人办公的机子乱七八糟的，我也不想在这种环境里录制QTP脚本，更不想在这种环境里运行QTP脚本，那简直是找苦头吃啊！

即使个人办公的机子没有问题，我也更喜欢单独的QTP服务器，那种干净、爽快的感觉，可以让你心旷神怡，工作高效百倍！

[ 本帖最后由 yabest 于 2008-8-14 11:20 编辑 ]

作者: 假装不在 时间: 2008-8-14 11:30
标题: 回复 21# 的帖子
偏见，拖出去打板子....

作者: hsjzfling 时间: 2008-8-14 16:24

原帖由 yabest 于 2008-8-14 11:08 发表

因为函数是放在函数库里的，QTP8.x不能直接调试库文件，所以需要调试时得把函数代码拷入Action中进行调试，调试好了再拷回库文件中。

QTP9.x就没这个问题了，库文件和Action一样可以打开、编辑、调试。

正好公司又有个项目需要做自动化测试了，彻底的贯彻你的思路来尝试下好了~做完就能比较出差异和优劣了~

作者: yabest 时间: 2008-8-14 16:59

原帖由 hsjzfling 于 2008-8-14 16:24 发表

正好公司又有个项目需要做自动化测试了，彻底的贯彻你的思路来尝试下好了~做完就能比较出差异和优劣了~

做不好的话，你要先反省一下自己

作者: yabest 时间: 2008-8-14 17:09

原帖由 kevin_swpi 于 2008-8-13 17:03 发表

目前我就是用的这样的方式
不过我在想函数多了...如何管理比较有效....

要准备个list菜单..不然N久后
我都不晓得都有那些函数了...

这个肯定是要的，我们是写一个Excel list文件，里面分模块写了各函数的说明，参数含义，返回值等等

这样大家用时，才知道有哪些函数可以用

作者: zte_boy 时间: 2008-8-15 09:08
觉得yabest的方案不错，呵呵，基本上用出了QTP的精华，呵呵，只要运行合理，应该是木有问题的

作者: ylm77ojn 时间: 2008-8-17 01:21
使用描述性编程肯定慢啊，想下，qtp要去系统中寻找匹配的对象，多废时间啊，呵呵

作者: 假装不在 时间: 2008-8-18 10:36

原帖由 ylm77ojn 于 2008-8-17 01:21 发表
使用描述性编程肯定慢啊，想下，qtp要去系统中寻找匹配的对象，多废时间啊，呵呵

使用对象库同样也需要去系统中查找匹配对象，谢谢。

作者: hsjzfling 时间: 2008-8-20 16:32

原帖由 yabest 于 2008-8-14 16:59 发表

做不好的话，你要先反省一下自己

框架的结构大致定好了，下午开始录脚本，发现所有对象都放在一个对象库中管理实在有点麻烦。。。

虽然用url属性并使用正则表达式确实能够把对象都放在对应的页面中，但貌似也太麻烦了点，上百个页面就得强暴对象库上百次，它不累我累了。。。

难道是yabest兄还私藏了什么绝招~~

作者: yabest 时间: 2008-8-20 17:00
哈哈，笑死了，没叫你每个页面都设置一个page对象。

适当的按照模块来划分page，这样相似的对象会放在同一个page下，不相似的对象会放在不同的page下，就又简单又好管理啦！

作者: 假装不在 时间: 2008-8-21 09:36

原帖由 yabest 于 2008-8-20 17:00 发表
哈哈，笑死了，没叫你每个页面都设置一个page对象。

适当的按照模块来划分page，这样相似的对象会放在同一个page下，不相似的对象会放在不同的page下，就又简单又好管理啦！

还没死吧....
能说下“按照模块划分”是怎么做呢？“相似对象”是指例如webedit之类的对象？

作者: yabest 时间: 2008-8-21 09:56
不是啊，比如用户管理模块里的添加用户、修改用户、查看用户几个页面的内容都是相似的，里面的对象也基本是一样的。

那么这几个用户管理页面都可以共用一个page对象，这些页面里的对象都可以放在这个page下，这样可以使得对象的管理既简单又清晰，既减少了冗余又不会混乱。

作者: hsjzfling 时间: 2008-8-21 10:10

原帖由 yabest 于 2008-8-20 17:00 发表
哈哈，笑死了，没叫你每个页面都设置一个page对象。

适当的按照模块来划分page，这样相似的对象会放在同一个page下，不相似的对象会放在不同的page下，就又简单又好管理啦！

如果能简单的按照模块来划分就好了。。。按照模块来划分还是得根据page的url属性吧(title更不用考虑了)，但即使是同一个模块，有些并未链接到其它模块的弹出页面url除了前一段同一环境的IP一样，后面部分完全不同，当然这和代码的规范相关，但这样的话，同一模块也只能用多个page了。

还有一种情况，有几个模块很庞大，子功能非常多，这时候按照模块来划分的话一个page中的对象就太多了，如果特殊的来处理，按子模块划分，那么标准就不明确了。我自己用是没关系，但是要写成文档确定规范和标准，告诉其他同事怎么用，貌似就不太好了。

继续请教yabest的高招

作者: 假装不在 时间: 2008-8-21 10:32
标题: 回复 33# 的帖子
page我们一般都是直接page("index:=0")
但这里我们说的是对象库，在这种情况，我可能会参数化title，至于url我不用这个。
哪么每次要用这个page时候，修改它的参数title就可以用了。
或者把标题给zz化。

作者: yabest 时间: 2008-8-21 10:46

原帖由 hsjzfling 于 2008-8-21 10:10 发表

如果能简单的按照模块来划分就好了。。。按照模块来划分还是得根据page的url属性吧(title更不用考虑了)，但即使是同一个模块，有些并未链接到其它模块的弹出页面url除了前一段同一环境的IP一样，后面部分完全不同 ...

不用对模块的概念这么严格，我们的目的是将对象分开管理。

主要是对象太多了，都放在一个page下太多太乱了。所以把对象按页面分开存放，相似内容的页面共用一个page！

就像切蛋糕一样，切多大、切几块都可以，只要你觉得舒服就行。

作者: yabest 时间: 2008-8-21 10:50

原帖由 假装不在 于 2008-8-21 10:32 发表
page我们一般都是直接page("index:=0")
但这里我们说的是对象库，在这种情况，我可能会参数化title，至于url我不用这个。
哪么每次要用这个page时候，修改它的参数title就可以用了。
或者把标题给zz化。

page和url都可以，看哪个好区分页面，就用哪一个！

作者: 假装不在 时间: 2008-8-21 11:59
一般例如你说的修改或者增加，它的URL很大的可能不一致。

作者: 假装不在 时间: 2008-8-21 12:00
所以说么，大家还是用描述的好，方便...

作者: hsjzfling 时间: 2008-8-21 12:02

原帖由 yabest 于 2008-8-21 10:46 发表

不用对模块的概念这么严格，我们的目的是将对象分开管理。

主要是对象太多了，都放在一个page下太多太乱了。所以把对象按页面分开存放，相似内容的页面共用一个page！

就像切蛋糕一样，切多大、切几块都可 ...

这样确实会比较舒服，但是仅仅依靠页面的相似性来划分，概念比较模糊啊。
我希望的是能有一个明确的统一的规范，让其他同事在开发新脚本的时候能够有法可依，这样做出来的脚本和我自己做的相比，除了个别细节上的处理外，就基本不会有什么差别了，而其他人维护的时候也会更方便一些。
我想严格控制模块的概念也就在于此。

作者: yabest 时间: 2008-8-21 14:34

原帖由 hsjzfling 于 2008-8-21 12:02 发表

这样确实会比较舒服，但是仅仅依靠页面的相似性来划分，概念比较模糊啊。
我希望的是能有一个明确的统一的规范，让其他同事在开发新脚本的时候能够有法可依，这样做出来的脚本和我自己做的相比，除了个别细节上 ...

这个可以先一个人把各page对象划分好建好了，其他人就可以直接添加对象到所属page里去了。

作者: yabest 时间: 2008-8-21 14:40

原帖由 假装不在 于 2008-8-21 11:59 发表
一般例如你说的修改或者增加，它的URL很大的可能不一致。

这个当然不一致了，所以可以用模式匹配url或者title（用'|'或者'.*'通配符），简单设置一下，就一劳永逸了。

磨刀不误砍柴工的！

比起你描述性编程还得手工写一行行代码，一处界面变动了，不知道要到哪里修改上n处的脚本，实在是好太多了。

作者: yugeyuetian 时间: 2008-8-23 23:24
标题: 欢迎加入软件测试群60709105
60709105

作者: hsjzfling 时间: 2008-8-25 10:33

原帖由 yabest 于 2008-8-21 14:40 发表

这个当然不一致了，所以可以用模式匹配url或者title（用'|'或者'.*'通配符），简单设置一下，就一劳永逸了。

磨刀不误砍柴工的！

比起你描述性编程还得手工写一行行代码，一处界面变动了，不知道要到哪里修 ...

为什么使用描述性编程，一处界面变动了，就要到处去找地方修改呢？一处界面变动，影响到的最多是一个模块或者子模块，其它模块如果都是调用该模块来进行该界面上的操作，那么改动只会局限在某个Action或者Function。如果该界面实在是难以写成一个通用模块来复用，那么还可以尝试全文查找替换嘛。

btw,按模块来划分Test，按子模块来划分Action的方式来组织可复用脚本的结构，个人觉得还是好用些，也许是用习惯咯~

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