51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

12
返回列表 发新帖
楼主: lifr
打印 上一主题 下一主题

[讨论] 做了一段时间QTP, 发现趋向于"尽可能少用对象库", 不知道大家以为然否

[复制链接]

该用户从未签到

21#
 楼主| 发表于 2012-1-20 09:31:02 | 只看该作者
回复 19# 云层

你这里列举了多种类型的GUI元素和你采用的识别方法.  我顺便也全面总结一下, 对于QTP里使用到的GUI元素, 我采用的相应的识别方法,

1. 简单的对象
这种对象是指, 通过一个id或者name或者label或者attached text, 等等, 就可以识别出来. 这种对象包括menu, button, edit, list, radiobutton, checkbox, 等等.

通常来说, 对于一个软件产品的节目, 这种类型对象是占大多数的, 我个人经验是80%左右.

这种对象无论 是录制通过QTP自动添加到对象库, 或者通过DP来查找都很简单. 鉴于其有很强的规律性, 我倾向于用DP来做, 就像我前面所描述的FindButton这样的函数, 原因是减少了对象库操作这个步骤, 开发的时候感觉更流畅.

2. 需要通过更多 属性 来识别的对象
举个例子, 页面有一个Table, 没有id. 缺省情况下, 如果把这个table加入对象库, QTP会通过index来识别. 但是index并不是可靠的方式. 这个时候需要把识别方式改成"column names".

这种对象 通过DP反而更麻烦, 不如对象库操作直观, 方便. 所以, 我是把这种对象放入对象库.

3. 另外有些对象只能通过DP来查找, 或者用DP查找更好.
因为TO封装的属性是有限的, 所以如果一个对象只能通过native对象的属性才能识别, 那么只能有DP了.

比如一个用SWT(eclipse)开发的界面, 有一个editbox, 其"attached text"是空值, 但可以通过 native object的message属性来识别.

又比如, 我现在的一个web项目, 所有form里面的input都有对应的label(如果没有可以报bug ), 所以所有的input都可以通过
    a. 根据inner text找到label
    b. 根据label的for属性找到input的id
    c. 根据input的id找到input
相对于input的id这种识别方式, 我认为通过label更直观, 代码的可读性更好. 所以我用了DP通过label查找对象. 如果你问我 "label和id, 谁更容易变化"? 我真不知道, 只能通过时间来检验, 不过有一点我能确定, 无论是id或者label, 新版本更替时变化的比例都会是很小的.
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2012-1-25 14:08:14 | 只看该作者
这个问题很早就被讨论过了。。。。。。

如果没有OR的存在的必要,QTP就早放弃了。
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2012-1-28 12:48:27 | 只看该作者
回复 21# lifr

如果DP和OR处理起来都很方便,那何不使用已经很好封装后更清晰明了的OR呢?
1 就无须讨论了
2 使用OR必须要懂得Object Identification这个配置中心
3 QTP提供了自定义对象接口,有编程能力完全可以通过该接口来自己封装对象,同类型对象定义一次即可
回复 支持 反对

使用道具 举报

该用户从未签到

24#
发表于 2012-1-30 11:14:02 | 只看该作者
回复 21# lifr


    受教了,个人目前的脚本开发模式,和lifr很相似,基本上也是OP和DP混着用,对于同一个web页面下一些存在共性的对象封装成一个函数供调用。对于个别较复杂的则采用QTP的对象库识别。
    这两种模式各有利弊,灵活使用方能效率最大化。对于vbs的class使用,个人不推荐,毕竟脚本不需要太复杂的封装,简单的函数调用就足够了。当然,如果项目庞大,开发外部功能拟用class来管理脚本也不失是个好办法。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2015-12-22 14:29
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    25#
    发表于 2012-1-31 11:25:04 | 只看该作者
    本帖最后由 liujintao00 于 2012-1-31 15:01 编辑

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    26#
     楼主| 发表于 2012-2-9 09:57:03 | 只看该作者
    回复 24# hyholine

    关于class的意见所言极是. 我现在的library大约总共有7k行代码(包括注释). 对于这样规模的代码, 通过命名约束等措施, 不用class也能处理得比较好.

    引入class还得考虑整个team的技术基础. 所以我也是持谨慎态度.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    27#
    发表于 2012-2-14 08:24:11 | 只看该作者
    回复  hyholine

    关于class的意见所言极是. 我现在的library大约总共有7k行代码(包括注释). 对于这样规模 ...
    lifr 发表于 2012-2-9 09:57



        VBS本身对于Class的支持就比较弱,如果大家拼命的想往OO靠拢,那就是自己给自己找麻烦。
        我们公司的第一版VBS代码,就用Class。在第二版的时候,就放弃了。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-15 10:04 , Processed in 0.066751 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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