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

lifr · 发表于 2012-1-17 21:26:27

做了QTP快两年了, 主要做了两套基于QTP测试框架, 分别是Web和Eclipse平台的应用. 不知不觉的, 发现自己在朝"尽可能少用对象库"这样的一个方向前进.

因为自己以前的自动化测试项目都是比较"低级"的, 没有基于商业的测试工具, 而是用Java, Ruby, Shell, 等等这样语言构建起来的. 所以骨子里有"自己控制一切"的倾向. 对于QTP本身, 我还只是半瓶子水, 所以我不敢确定这是否是一条正确的道路? 不知道各位资深的QTP测试开发人员是否同意我的观点?

突然有这样一个反思, 是因为前几天, 我在试图实现这样这样的一些函数: 通过函数调用(不用访问对象库), 就能在当前window把一些GUI元素找出来, 比如Button, Edit, Table, List, 等等.

Function FindButton(strText)
'找出当前的window, 逻辑大概是这样
Set cw = Nothing
if 有popup window Then
set cw = popupWindow
else
Set cw = mainWindow
End If
'用 DP找出此button
set desc = Description.create
desc("to_class").value = "Button"
desc("index").value = 0
desc("attached text").value = strText
Set ele = cw.Button(desc)
' 如果不能找到, 那么引用对象库
if Not ele.Exist(0) Then
Set ele = win.Button(strText)
End if
Set FindButton = ele
End Function

复制代码

为什么要实现这样一套函数库是因为在写 testcase script的时候, 常常不得不中断下来, 把对象加入对象库. 而这样的"中断" 让我很恼火, 因为它破坏了写代码的流畅性.

如果有比较完善的这样的"找出对象"的函数库, 那么在写testcase script的时候, 几乎不会为录制"对象"而中断, 这样就更像我用Java, Ruby, Shell等语言开发的状态.

这种方法的缺点也很明显. 因为QTP对象库提供了一层中间层, 所以GUI元素发生了改变, 比如改名, 那么仅仅需要修改对象库里对象的定义, 而不需要修改任何引用它的code.

想听听大家的意见.

heqingbluesky · 发表于 2012-2-14 08:24:11

回复 hyholine

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

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

lifr · 发表于 2012-2-9 09:57:03

回复 24# hyholine

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

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

liujintao00 · 发表于 2012-1-31 11:25:04

本帖最后由 liujintao00 于 2012-1-31 15:01 编辑

hyholine · 发表于 2012-1-30 11:14:02

回复 21# lifr

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

hsjzfling · 发表于 2012-1-28 12:48:27

回复 21# lifr

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

heqingbluesky · 发表于 2012-1-25 14:08:14

这个问题很早就被讨论过了。。。。。。

如果没有OR的存在的必要，QTP就早放弃了。

lifr · 发表于 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, 新版本更替时变化的比例都会是很小的.

lifr · 发表于 2012-1-20 08:53:35

回复 18# 木卫十二

恩, 知道了. 多谢.

云层 · 发表于 2012-1-19 20:19:54

回复 12# lifr

我的意思是简单的东西用OP，略微复杂的可以用DP来辅助，因为总是调整OP来配合某些对象很麻烦，特别麻烦的成套对象还是用OP好

木卫十二 · 发表于 2012-1-19 17:50:07

回复 16# lifr
支持，但功能不强。参考：
http://www.51testing.com/index.p ... wspace-itemid-64875

archonwang · 发表于 2012-1-19 17:18:28

高手云集。激活一下。

lifr · 发表于 2012-1-19 17:10:53

回复 15# 木卫十二

看来你更"严重".

. 我在QTP的IDE里面写testcase script. 用vim写外部函数.

有个问题? vbs支持class吗?

木卫十二 · 发表于 2012-1-19 16:12:59

描述性编程，封装得好，跟用对象库效果一样的。
封装的原则：页面上一个元素的改动，脚本也应该只改动一个地方。

我不仅使用函数，还使用Class，总之，一个项目全是脚本+数据，编写用例的时候甚至不需要打开QTP。
使用PsPad管理项目脚本。

lifr · 发表于 2012-1-19 14:25:46

本帖最后由 lifr 于 2012-1-19 14:27 编辑

回复 9# davy_chen

我想是否我真的很"非主流"的使用QTP, 下面是我做QTP项目的特点.

1) 重度的函数使用者.
关于函数库的设计, 我也许会另开一贴讨论. 我的项目中确实使用了大量的函数.
2) 绝不使用ReusableAction
3) 从不使用Keywork View
3) 尽可能少用Checkpoint, 而使用AssertXXX函数
4) 尽可能少用对象库, 而使用建立在DP之上的对象识别机制
5) 没有(机会)使用QC, 使用自己的Batchrun脚本和report生成工具(都是用VBS开发)

lifr · 发表于 2012-1-19 14:11:21

回复 10# yujie6832

能否详细阐述"OP简单的多", 或者举例一二.

lifr · 发表于 2012-1-19 14:05:38

本帖最后由 lifr 于 2012-1-19 14:08 编辑

回复 8# 云层

你指的麻烦是 "写复杂的description来定位对象"? 我想你误解了我的意思, 这应该是因为我之前的表达并不精确, 我再重新明确一下.

我赞同你的观点. 对于需要比较复杂的条件才能定位的GUI元素, 用对象库更有效率. 所以, 在 FindButton函数逻辑里, 在用DP查找失败的情况下, 还会通过对象库来查找.

通过DP就能找到的GUI元素, 恰恰不是这种"需要复杂条件才能"的元素, 反而是有规律的, 简单的方式就可以定位的元素. 这样的所谓的简单的GUI元素, 我个人经验是占总量的80%以上.

所以, 重新回到以前的问题, 对于这一些"简单的GUI元素", 是通过对象库来引用有效率, 还是写一些像FindButton这样的函数来引用比较有效率? 这里的效率既包括开发效率, 也包括后期维护的效率.

hsjzfling · 发表于 2012-1-19 12:07:47

这需要个过程的，一般都是OR->DP->? 只有对OR DP都有足够的认识的基础上才能够根据实际情况作出最合适的选择，本人也是自4年前开始就一直坚定拥护OR为主的

yujie6832 · 发表于 2012-1-19 09:29:16

云层兄的想法跟我一致，OP也可以玩得很简单，自动化关键在于多用脑子去思考，用活了，你就会发现OP简单的多，这个是QTP的精华中的精华，我的理念是OP为主，DP为辅

davy_chen · 发表于 2012-1-19 09:28:52

让QTP做它擅长的工作，不用对象库的QTP，好像是让研究生卖猪肉，虽然效果未必差，但是不是主流。

		自动登录	找回密码
密码			(注-册)加入51Testing

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

相关帖子

站长推荐 /1