51Testing软件测试论坛

标题: Different QTP, 关于QTP测试框架设计的总结 [打印本页]

作者: lifr    时间: 2012-8-27 09:07
标题: Different QTP, 关于QTP测试框架设计的总结
本帖最后由 lifr 于 2012-9-11 12:47 编辑

这个周末写了几篇blog, 关于QTP测试框架, 作为一个总结。 本人并不是QTP高手, 很多高级技巧都不太会用。 不过我有多年的软件开发经验, 特别是Java方面的, 所以对于软件设计还是有一些经验的。 这也决定了, 我设计的QTP测试框架并不会用到很炫的QTP技术, 而会更多的在抽象,架构等方面下功夫。进一步阅读, 请点击下面link。

Different QTP: 前言

Different QTP
两个抽象之一:产品业务逻辑抽象


Different QTP: 业务逻辑封装原则


Different QTP: 业务逻辑封装接口设计


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

Different QTP: GUI元素库:架构

Different QTP: GUI元素库:查找函数

Different QTP: GUI元素库:标识符匹配的规则

Different QTP: GUI元素库:智能查找与批量输入

Different QTP: GUI元素库:复杂对象描述机制

Different QTP: GUI元素库:组合元素

Different QTP: GUI元素库:快捷方式

Different QTP: GUI元素库:用Screen-Field解决复杂组合元素

Different QTP: 总结


Different QTP: 总结2:适应变化和可测试性


Different QTP: 测试执行流程与Mngt Tools


Different QTP: Project目录架构


Different QTP: QTP使用中的陷阱


Different QTP: 后记


ChangeLog:
1. 加了一点业务逻辑封装的内容。
2. 看了网友的评论, 在总结部分加了一些自己的想法。
2012/09/08
添加后面几章, 全部发完.

2012/09/11
PDF 文档:[attach]81349[/attach]
作者: louqqson008    时间: 2012-8-27 10:24
先沙发,学到框架后,再回头来学习
作者: lantianwei    时间: 2012-8-27 16:24
写的挺好的 支持下~
作者: hsjzfling    时间: 2012-8-27 16:47
本帖最后由 hsjzfling 于 2012-8-27 17:53 编辑

完整仔细的读了一遍,相当的不错,支持一下先,稍后上个评论
-----------------------------------------------------------------
评论整理好了

现阶段来看,对QTP部分功能重新定制封装,形成新的关键字驱动框架的设计方式,已经逐渐为越来越多同行接受并应用在实际工作项目中。正如作者的介绍,其好处是不言而喻的,能够尽可能的提高可维护性、易用性、重用性、稳定性以及脚本开发效率等等。就框架而言,做成什么样子算好呢?这个没有一个统一的标尺,一般来说,能用尽量少的开发成本获得一个正好适用的框架,就足够了。可以预留扩展功能的接口,但没必要一次性把框架做成万能的,这样不现实。

lifr提供的分享来看,这方面做得很好,针对web测试过程中的一般性问题与部分场景都做了定制分析,增加了screen的概念,可以看成是一个不错的页面用例模板,一系列底层的封装与控制机制保证了框架能够很好的进行工作,下面就对几个关键点来分别做下讨论。

1. 用哪些QTP内置功能不用哪些内置功能

这点上理解不一样,技术能力不一样所做的取舍就不太一样,并不是所有人都有能力去舍弃掉内置功能而重写一份替代之,部分内置功能若理解得很透彻也是可以很好的融入框架中工作的

2. 业务逻辑抽象

从数年前HP推出的BPT的思想来看,就是编写一系列的原子级业务处理单元,编写用例时只需要逐一调用这些业务单元即可快速生成。Lifr所强调的那个原则非常好。

3. GUI元素库

这个是QTP工作的一个核心,曾经QTP插件都是单独卖的方面就可以确认这一点。作者通过一系列的定制和封装,重写一个web插件与对象库管理,将QTP对象库的大部分功能用更容易被使用的方式呈现出来,并定制部分识别逻辑。这方面lifr介绍得非常详细,值得很好的学习和参考,本人也获益匪浅。对于同类框架而言,封装思路各有千秋,适用就好。

4. Screen-Field

应用在web上很棒,如果要应用在其它的环境中,可能要考虑下扩展性和适用性,当然公司只有web项目那就无所谓了。

5. 其它1

脚本的驱动、数据处理、容错处理、日志等部分,作者并未过多介绍,不过这几个方面可自成体系,与作者介绍的核心没有必然联系。不过从完整框架结构的考虑来看,作者若能补充这方面的大致结构,会对想要学习的朋友有更多的帮助。作者也可以考虑在框架中预留足够的标准接口,为将来的某些可能做准备。

6. 其它2

作者是否有考虑过用其它开源工具来做自动化呢,比如watij, selenium等,都是用java编写的框架,java实现,扩展性好,做web测试也非常不错,关键还免费。

再次感谢lifr的分享。


作者: wspc    时间: 2012-8-27 17:00
牛X呀,学习了,框架是自动化测试的终极目标
作者: 云层    时间: 2012-8-27 17:37
先占个位置,想法很好,我也在写类似的框架,不过估计会夭折没空
作者: zzxxbb112    时间: 2012-8-28 11:08
早上一来就看到这么精彩的帖子,让我激动了一下,写的非常好,最近QTP板块像这样的文章真的很少了,forminput和screen-field的确很实用,对于你所说的所见所得模式建议可以加入DP方式的VISUAL RELATION IDENTIFIER结合使用,我相信这样会更易扩展,因为attachtext有时会失效,而且换成.Net应用就无法使用了,还需要重新封装,只是小小的提议,呵呵,真的非常感谢你能够分享出你的框架思想,强烈支持你!
作者: lifr    时间: 2012-8-28 12:53
本帖最后由 lifr 于 2012-8-28 12:54 编辑

回复 4# hsjzfling
多谢你的评论。

1. 你说的很对。框架采用的技术和 具体的项目和开发团队有关系的。 但是目标都是一样的, 就是更高效率完成工作。

2. 业务逻辑和测试逻辑分离真的很重要。 不过现实情况是开发人员不一定把握的好, 所有我基本上会review所有提交的业务逻辑封装函数。

3. 多谢夸赞。 如文章所说, java对我影响很大, 所以设计上有很多java的影子。

4. 对于Screen-Field, 我个人经验是适合windows程序而不是web应用。 因为它相对比较重型,适合有较多复杂控件的程序。 而windows应用比web应用更方便做一些复杂的控件出来。

5. 脚本驱动, 结果报告等管理工具/脚本, 在我现在的框架也有完整的方案。 以后有时间再写。

6. 我可能也算国内较早用watir+ruby的,watir很犀利, 我一直认为, 从纯技术出发, 对于纯web应用, watir优于qtp。 现在用qtp是因为公司policy。
selenium前端时间也做个一个项目。 感觉selenium提供的api太底层, 要做很多架构的工作才能开始test script的开发, 而且xpath的要求非常高。 总体开发效率, 不一定比qtp高。
作者: lifr    时间: 2012-8-28 12:56
本帖最后由 lifr 于 2012-8-28 16:14 编辑

回复 7# zzxxbb112

我会研究一下“VISUAL RELATION IDENTIFIER”。 多谢。
------------------------------
嗯, 这里有一篇guide
http://www.joecolantonio.com/2012/02/03/qtp-visual-relation-identifier/

非常有趣的技术。 根据位置关系来识别对象。 这让我第一时间想到了“sikuli”(http://sikuli.org) ,而且sikuli把这种方式作为它的基本方式。
对于QTP来说, 这是一种很有用的对象识别方式,不过不应该是基本方式, 而应该是补充方式。 如果要使用, 我倾向于在object repository里用这种方式把对象定义出来。

我做过的一个项目还真的遇到了这种情况, 不过当时我并不知道QTP支持这种技术, 所以解决起来很笨。 是通过X,Y坐标计算而出。
作者: 云层    时间: 2012-8-29 08:33
框架写到后面总觉得越来越像QTP,因为QTP本身其实做了很多不错的东西,呵呵




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2