Hi, 如果有任何想法与我沟通, 请用: lifr_nj 在 msn.com
Different QTP: 业务逻辑封装接口设计
上一篇 /
下一篇 2012-08-28 14:56:26
/ 个人分类:QTP
业务逻辑封装接口设计
为了达到“testcase
script和testcase的描述有简单而直接的对应”这样一个目标,需要对产品功能有一个全面而系统的封装,然后提供一套API供testcase
script调用。显然,这会导致大量的API单元产生出来。
QTP提供了resuable action作为业务逻辑封装的工具,但是resuable action过于重型,而且并没有提供与其重量级相对应的强大功能。 function相比于reusable action提供了同样的封装能力,但体积只有1/10,而且使用方式更自然。 这也是不用reuable action的若干重要原因之一。
另外一个必须要考虑的问题就是如何降低这套API使用的难度。这里有一些技巧。
命名规则
VBS没有Module的概念,但显然数量众多业务逻辑封装函数必须组织在模块里。所以我们在命名规则上来模块化。一个业务封装函数的命名如下
BIZ_ModuleName_DoWhat(paramters)
首先BIZ前缀把它与framework里的其他函数分离出来。ModuleName是第二个前缀,指出了模块名。第三个参数才描述了函数所封装的业务。
文档化
VBS没有专门的文档化定义(类似JavaDoc的东东)。当然你不能对它责怪太多,毕竟这是上个世纪70年代的语言。我使用Doxygen加上一个定制的filter来生成framwork里所有函数的文档。
比如下面这段的代码
' create account with given parameters.
'
' @param resourceType Hierarchy/Group/Device
' @param param1 the param to set value in page 1
' @param param2 the param to set value in page 2
'
' @see GUI_Field_HierarchySelect_Set
' @see GUI_Field_GroupSelect_Set
' @see GUI_Field_ProfileSelect_Set
Function
BIZ_Account_Create(accountName, roleName, resourceType, param1, param2)
通过Doxygen生成的文档像下面的样子
去除页面依赖
这里的“页面依赖“是一种函数前置条件。它特指业务逻辑封装函数对进入此函数时的当前页面的要求。比如一个BIZ_User_Create函数,它的前置条件可以是“当前页面在User Management页面”。不满足前置条件时,调用一个函数通常会导致object not found错误。
但是如果BIZ_User_Create函数针真的对前置条件如此要求,那么成百上千的类似的业务封装函数会让Testcase script的设计者“步步惊心”。为了消除这种不必要的心理负担。我对业务逻辑封装函数的要求就是:只要有可能,所有业务逻辑函数都要去除页面依赖。也就是说无论当前应用程序处于那一个页面,函数都能正常工作。对于大部分应用程序来说,前置条件的要求其实是“用户已经登陆进入系统,但可以处于任意页面”。
显然,这会导致更多的执行时间。在函数内部,首先做的就是导航(通过菜单或别的方式)到实际开始业务逻辑的页面。但是相对于其带来的接口的简化,和后续的维护简化。这点成本简直就是微不足道。
这是一个很小的规则,但它在提高API的可用性方面效果非常大。
收藏
举报
TAG: