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

Different QTP: 总结

上一篇 / 下一篇  2012-08-26 22:22:30 / 个人分类:QTP

总结:关于framwork设计的一些思考

到这里,我已经把这个framework里最重要的部分,开发testcase的基石,Function Library介绍完了。

在设计这个Function Library的时候,有两个最重要的抽象层,一个是对产品业务逻辑的封装,一个是对GUI元素访问的封装。对于业务逻辑封装,最重要的原则是”把业务逻辑和测试逻辑严格分离“,另外就是不要使用QTP提供的Reusable Action对于GUI元素的封装,我舍弃了QTP本身提供的对象库,而完全用描述性编程的方式建立了一套”所见即所得“的GUI对象查询库。

为什么是这样子抽象?是两层抽象,而不是一层(仅仅提供一些GUI元素操作的封装),或者三层(提供data-driven/keywork-driven类似的用户接口)?我的经验告诉我,QTP软件测试项目最大的挑战其实是可维护性。无论你是用record还是层层封装,基本上你都能实现一个testcase但是真正的问题在于当testcase的总数上升到成百上千的数量级,代码库是否还能保持清晰?Testcase是否能够适应今后产品的变化?维护人员是否能快速定位错误?当前的抽象模型是我认为对我目前项目最合适的。

我始终认为,好的framwork设计者应该尽可能取悦framwork的用户。一个QTP test framwork的用户其实有三类,

·        业务逻辑封装函数的开发人员

·        testcase script开发人员

·        testsuite维护人员

一个framwork的设计者,最好同时也从事上面提到的三种类型的开发,这样才能”叫好又叫座“

最后,是没有最好的framework而只有最合适的framework如前言说讲,这是一种“非常规”的开发模式,特别是舍弃了很多QTP提供的智能工具。QTP提供这些工具的目的是为了支持它的”keyword driven”这样一种开发模式。客观的说,这是一种易用,快速的开发模式,但个人之见是仅仅适合小型,且短期的项目,而且和普通的编程语言开发模式非常不一样(java/c#/c++)。基本上,我是把QTP测试的开发模式,转变成了普通语言开发的模式。

我曾经一位在HP工作过的同事告诉我,HP内部也是用QTP推荐的模式,而且其项目也是不小。所以我有时候怀疑这是不是因为我使用Java太长以至于形成了思维定势,也许QTP本身的模式并不是那么脆弱,低效。但是无论怎么样,我现在使用的模式也有成功案例的支持,所以我想可能这个也是一个因人而异的事情吧。只是希望一些新的想法,方法的出现能够激发更多人的灵感,QTP测试项目开发模式更加完善,进一步提高QTP测试开发人员的生产效率。


TAG:

云层专版 引用 删除 云层   /   2012-08-29 08:31:46
5
 

评分:0

我来说两句

Open Toolbar