两个抽象之一：产品业务逻辑抽象

 第一个抽象层是关于对产品业务逻辑的封装。它的目标是，在设计testcase script时，要求做到“testcase script和testcase的描述有简单而直接的对应”。也就是说在阅读一个testcase script的时候，加上少量的注释，就像在阅读这个testcase的人类语言描述。

例子

我们来看一个testcase的描述。它关注于对测试逻辑的描述，它的语句表达了业务层面上有意义的步骤，而不会/很少涉及到很具体的GUI的操作，比如下面的例子。这是一个测试创建新用户的testcase描述。

Preconditions:

Login as Administrator

Steps:

1. goto admin->user management

2. create a new user with

1) name: ABC

2) password: 123

3. logout administrator

4. login as ABC with initial password 123 and change password to 234

5. Logout ABC

6. Login as ABC and with password 234

Checkpoints

·        step2, ABC is created

·        step6, ABC can login

一个testcase的script，应该像下面的样子

'precondition

BIZ_LoginAsAdmin

'create user ABC

BIZ_CreateUser "name=ABC;password=123"

AssertTrue BIZ_UserExist "ABC", "user ABC not created"

BIZ_Logout

'login as ABC and change pswd

BIZ_LoginWithInitPswd "ABC", "123", "234"

BIZ_Logout

'login as ABC again

loginFlag = BIZ_Login "ABC", "234"

AssertTrue loginFlag, "ABC failed to login with pswd 234"

如你所见，一个testcase script的开发人与，在编写testcase script的时候，同样也只关注测试逻辑，他用framework提供的API来把人类语言的测试逻辑“翻译”为VBS语言。这就是第一个抽象/封装所要达到的目标。

优点与缺点

这种方法的最大优点就是。testcase script的开发效率更高，同时维护成本更低。

首先是项目代码更能适应变化了，因为他对两个变化源彻底的分离，无论是产品功能的变化，或者测试逻辑的变化，其影响范围都限制在了最小。

testcase script的简单易读使得后期维护更容易。设想你去维护一个别人开发的QTP project。当你打开一个失败的testcase时，你能够通过读代码就能明了其测试逻辑，马上开始调试工作。。。

Testcas script的开发效率更高。在对产品功能有一个全面而系统的封装的天体下，Testcase开发的要求降低了，无论是复杂度还是代码量都会少很多。 但是，这需要更多的时间来开发framwork，所以总时间并不一定会少。但我能确定后期维护时间会少很多。

这样做的缺点也有，就是对framework开发人员要求更高，除了会使用QTP，还必须具有良好分析和抽象的能力，我认为至少要有一年的通用的面向对象语言开发经验（Java/C#/C++）。公司需要更高的价格才能在市场上雇佣到这样的人。