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: 总结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/)