【运行速度】对象库 与 描述性

假装不在

场景：
     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

速度问题其实影响不大，不用斤斤计较。我都没怎么关心，反正直觉上都觉得够快的了。

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

zte_boy

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

假装不在

是刚好看到有人在讨论，我就自己做做看。
我极度怀疑你是不是天天在论坛搜索中输入 对象库 描述这2个字眼的... 想找你，只要在论坛发帖，题目有对象库就可以了。
回复 3# 的帖子

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

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

kevin_swpi

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

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

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

泥泥虫

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

假装不在

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

yabest

luckxiaot

描述性编程是比对象库运行要慢，但是偶觉得还是可以接受的！！

hsjzfling

lz有没尝试过将类似于browser("....")page("....").link("html tag:=...","text:=....","x:="...,"y:="....).click的语句执行个成千上万次乃至更多~

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

假装不在

你用论坛的连接44看就知道了。添加进了X  Y后效果很明显。

hsjzfling

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

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

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

假装不在

是的，在9.X后使用的关联对象库确实很好的管理问题。或者QTP就还是想继续弘扬对象库，也许不久将来描述真的被对象库干掉了，就像现在一样都是大的西科医院一样。

yabest

原帖由 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

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

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

假装不在

因为你的名字比较有说服力。
我也是一个action使用。

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

hsjzfling

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


我有这样说过吗？

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

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

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

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

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

hsjzfling

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

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

假装不在

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

yabest

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


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

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

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

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