Hi, 如果有任何想法与我沟通, 请用: lifr_nj 在 msn.com

Different QTP:两个抽象之二:GUI元素操作抽象层

上一篇 / 下一篇  2012-08-26 21:31:06 / 个人分类:QTP

两个抽象之二:GUI元素操作抽象层

第二个抽象层是关于对GUI元素的操作的封装。

在我的项目里,除了最顶层的Window 几乎完全不使用Object Repository来定义GUI元素。而是使用一套对GUI元素封装的API

对于GUI元素的封装的API它的目标是,在编码的时候,GUI元素的操作是“所见即所得”。什么叫做“所见即所得”,它的意思是,当访问一个对象时,通过你能看见的标识就能得到这个对象。

这个的关键是“你能看见的标识”。如果你用过QTPrecord你得到代码里,对于GUI对象的访问通常都是通过“看不见的标识”,比如HTML IDindex等等。

例子

比如下面的一个login web页面。

对于login操作,如果通过record,代码像下面的样子

Browser("XXX").Page("YYY").WebEdit("loginform.:name").Set "ABC"

Browser("XXX").Page("YYY").WebEdit("loginform.:pswd").Set "111111"

Browser("XXX").Page("YYY").WebButton("loginform.:login").Click

而使用“所见即所得”的GUI元素库,代码像下面的样子

GEdit("Login name").Set "ABC"

GEdit("Password").Set "111111"

GButton("Login").Click

 

如你所见,对元素的引用通过你能看见的标识,而不是id或者name你不能看见的标识。这也是不使用Object Repository的重要原因之一。

优点与缺点

这样一种抽象/封装方式带来的好处,首先是开发效率的提高。在写代码的时候,完全没有了Object Repository的束缚,不用再在editorobject repository manager之间来回切换,坦白说,那种开发方式几乎让我疯掉。你所做的就像在编写任何其他语言代码一样,以一种最舒服的方式在开发你的function或者testcase script

另外是在对代码修改以适应产品GUI的变化时,你仍旧不需要打开inspectorobject repository manager去重新识别元素。你是需要把你看到的变化在代码里重新匹配即可。

缺点。对某一个特定的产品,建立一套完整的GUI对象查找机制并不是一个很小的工作量。而且在这个过程中还会经常遇到“非常规”需要特别处理的GUI元素。为了达到易用性和能力的平衡,需要做出很多设计上的取舍,这需要一个资深的程序设计人员才能完成。如果非要量化的话,我认为其设计者需要三年通用的面向对象语言开发经验(Java/C#/C++)。

GUI元素库是framwork里最重要的部分,也是工作量最大的部分。它也是业务逻辑库的基础。所以我会用很多笔墨来详细介绍它是设计的,和设计过程中面对的各种问题和解决方法。

TAG:

 

评分:0

我来说两句

Open Toolbar