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元素的操作是“所见即所得”。什么叫做“所见即所得”,它的意思是,当访问一个对象时,通过你能看见的标识就能得到这个对象。
这个的关键是“你能看见的标识”。如果你用过QTP的record,你得到代码里,对于GUI对象的访问通常都是通过“看不见的标识”,比如HTML ID,index等等。
例子
比如下面的一个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的束缚,不用再在editor和object repository manager之间来回切换,坦白说,那种开发方式几乎让我疯掉。你所做的就像在编写任何其他语言代码一样,以一种最舒服的方式在开发你的function或者testcase
script。
另外是在对代码修改以适应产品GUI的变化时,你仍旧不需要打开inspector和object repository manager,去重新识别元素。你是需要把你看到的变化在代码里重新匹配即可。
缺点。对某一个特定的产品,建立一套完整的GUI对象查找机制并不是一个很小的工作量。而且在这个过程中还会经常遇到“非常规”需要特别处理的GUI元素。为了达到易用性和能力的平衡,需要做出很多设计上的取舍,这需要一个资深的程序设计人员才能完成。如果非要量化的话,我认为其设计者需要三年通用的面向对象语言开发经验(Java/C#/C++)。
GUI元素库是framwork里最重要的部分,也是工作量最大的部分。它也是业务逻辑库的基础。所以我会用很多笔墨来详细介绍它是设计的,和设计过程中面对的各种问题和解决方法。
收藏
举报
TAG: