51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4512|回复: 13
打印 上一主题 下一主题

[原创] QTP脚本优化__对象释放

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-9-19 15:54:44 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
QTP脚本优化__对象释放
    关于QTP,由于个人的编码习惯,会让脚本随时间的增加,QTP会占得越来越多的内存,并且会有可能出现“跑不动”的情况
    今天做了下简单的测试,以小见大,26个变量去做数据内存记录。分析得到的结论如下:
        无释放类对象
运行前        运行后                差值        平均值
80632        81252                620        424
81428        81912                484
81788        82000                212
81448        81828                380

        释放类对象,无释放类变量                
运行前  运行后                差值        平均值
73900        74292                392        308
73244        73204                40
72940        73492                552
72860        73108                248

        有释放类以及变量   
运行前  运行后                差值        平均值
73312        73388                76        160
73380        73736                356
73296        73460                164
73384        73468                84

不过第三个方法中,显得很麻烦,也很少去做到这一步,代码量也会随之增加,所以见仁见智,大家各自取舍。

'1,都无释放,请把41--68行注销
'2,只做释放类实例,请把41-66行注销
'3,都做了释放

本帖子中包含更多资源

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

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

14#
发表于 2009-12-31 14:47:42 | 只看该作者

好谢谢

好谢谢好谢谢好谢谢好谢谢好谢谢好谢谢好谢谢
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2008-9-24 17:56:30 | 只看该作者
工作时间不能下载,看不到lz的代码了

这个突然让偶想起了前几个月玩武林三国时候的事情,用QTP执行同样功能的自动建造建筑的脚本,同样都是执行24个小时,对于临时对象的处理方式不同,QTP消耗的内存差别超过80MB

暂时在公司项目上还没有因为QTP内存消耗而遇到瓶颈,脚本在周末都会从周五晚跑到周一凌晨,没发现会有内存方面的问题~~
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2008-9-24 17:43:53 | 只看该作者

回复 1# 的帖子

问个很傻的问题啊:这个脚本可以直接拿来用么?怎么用啊??
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2008-9-23 14:17:28 | 只看该作者
原帖由 loho1968 于 2008-9-23 12:19 发表



QTP使用测试对象时,先查找对象库中记录的对象属性,然后在内存中找到对应的对象,然后建立一个Reference。这个Reference占用资源吗?
或者说,如果使用描述性编程,创建的对象如果不释放是否点内存?


当然占内存了,要不然脚本的最后为什么都是Set ××=nothing
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2008-9-23 12:19:54 | 只看该作者
原帖由 heqingbluesky 于 2008-9-23 11:17 发表
QTP运行时候,使用的是对象的Reference,不是保存在内存中的对象保存的地址,7#的TX搞错了吧。



QTP使用测试对象时,先查找对象库中记录的对象属性,然后在内存中找到对应的对象,然后建立一个Reference。这个Reference占用资源吗?
或者说,如果使用描述性编程,创建的对象如果不释放是否点内存?

[ 本帖最后由 loho1968 于 2008-9-23 12:21 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2008-9-23 11:17:52 | 只看该作者
QTP运行时候,使用的是对象的Reference,不是保存在内存中的对象保存的地址,7#的TX搞错了吧。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
 楼主| 发表于 2008-9-22 18:06:11 | 只看该作者
原帖由 loho1968 于 2008-9-22 17:56 发表
这个是自己创建的对象,QTP对象库中的对象是否有释放呢?有的话,应该如何释放呢?


你说的对象释放是指它这个对象的object还是这个对象描述呢?
1,如果是它的object,那你就理解错误了,对象库只是类似一个id库,里面存放了很多ID数据,然后去找这些人。
2,如果是这些对象的描述,你要是释放了,第2次要怎么用呢,或者说,QTP一开始运行,对象库中的那些对象就已经类似一个description一样被创建出来,并且是唯一的,不会被释放。除非停止QTP运行。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2008-9-22 17:56:38 | 只看该作者
这个是自己创建的对象,QTP对象库中的对象是否有释放呢?有的话,应该如何释放呢?
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2008-9-22 12:51:02 | 只看该作者
这...怎么...呵呵
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2008-9-22 10:43:08 | 只看该作者
经过QTP的实际测试,三次结果还是很有说服力的,
运行前,Available  Memory:605580K
*********************************************
第一次运行完:Available Memory:598848K
第二次运行完:Available Memory:615059K
第三次运行完:Available Memory:623110K
************************************************
结论:销毁对象和销毁对象属性在释放内存方面还是有帮助的,实践是检验真理的唯一标准。

当然VBS本身是没有内存管理机制的,但是它还是可以获取内存存取空间,释放内存空间。
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2008-9-19 18:01:33 | 只看该作者
原帖由 xiaoyaoke 于 2008-9-19 17:17 发表
VBS本身没有内存管理机制,要靠代码编写者自己去释放无效的内存空间。当生成一个类的实例(对象)时,解释器(QTP)会在内存中申请一段空间来储存这个实例(对象)的信息(属性),当我们销毁这个实例的时候,系统会 ...


其实,你自己做下数据的收集,你会发现,“销毁对象”与“销毁对象和销毁对象属性”两中它占的内存消除大小是不一样的。
也就是说,当我们的QTP脚本在跑的时候,它自己(QTP主程序)并没有做内存清理的工作。
因此,QTP运行了几个小时如果都没做销毁操作,哪么它的内存会越来越多,直到把QTP停止掉。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2008-9-19 17:17:52 | 只看该作者
VBS本身没有内存管理机制,要靠代码编写者自己去释放无效的内存空间。当生成一个类的实例(对象)时,解释器(QTP)会在内存中申请一段空间来储存这个实例(对象)的信息(属性),当我们销毁这个实例的时候,系统会回收这段内存,所以既销毁对象的属性又销毁对象是没有意义的。
也就是说,‘2和3’应该说在内存管理层面来说意义是一样的。

个人理解...
回复 支持 反对

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2008-9-19 15:55:24 | 只看该作者
再次抛砖,不知道已经丢死多少人了
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-27 03:57 , Processed in 0.080263 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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