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: