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

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

上一篇 / 下一篇  2012-08-28 14:56:26 / 个人分类:QTP

业务逻辑封装接口设计

 

为了达到“testcase scripttestcase的描述有简单而直接的对应”这样一个目标,需要对产品功能有一个全面而系统的封装,然后提供一套APItestcase 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:

 

评分:0

我来说两句

Open Toolbar