这是我对两年来QTP工作的一份总结。详细介绍了Framework的设计理念和方法。

前言：Different QTP

为什么叫做“Different QTP”，具体来说，在我的项目里，下面一些是不使用的

1.   Object Repository（尽量不用）

2.   Reusable Action（严禁使用）

3.   Smart identification（严禁使用）

4.   Keyword view（没有必要用）

5.   Reporter ReportEvent（尽量不用）

简单来说，QTP里一些提高易用性的工具，基本上统统都用不上。

QTP(QuickTestPro)作为最流行的商业软件测试工具，像其他商业软件一样，在软件的易用性方面都是费尽心机。设计了很多工具来让用户能够快速开始设计一个测试脚本。但是，最近我在对这两年QTP测试工作进行总结时，发现在我的项目里，并没有使用QTP提供的这些提高“易用性”的工具，甚至很多工具是严禁使用的。可以说，我做QTP测试项目的开发方式和QTP的推荐方式完全不一样。这就是我把文章命名为“Different QTP“的原因。

在我看来，QTP提供的很多工具只是为了Quick，比如record，对于小项目尚能接受，但对于比较大且长期运行的项目，却带来了维护的问题，反而是效率低下的。

也许你觉得这样比较“激进”，但我的实践证明了这些措施是有效的。在两年的时间里，我按照这样的理念设计了QTP测试的framework，在此framework基础上有超过1000的testcase也是在使用同样的理念开发出来。整个Team都觉得这些testcase的开发效率和可维护性远远超过了按照常规的QTP方式开发的testcase。这也是我有信心把这个过程中的经验教训共享出来的原因。

一个QTP测试项目如果简单的划分，包括三个部分。如下所示。

       +-------------------------+    +--------+
       |                         |    |        |
       |      TestCases          |    |        |
       |                         |    | Mngt.  |
       |                         |    | Tools  |
       |                         |    |        |
       +------------------------->    |        |
       |                         |    |        |
       |                         |    |        |
       |                         |    |        |
       |   Function Library      |    |        |
       |                         |    |        |
       |                         |    |        |
       +-------------------------+    +--------+

Testcase就是根据手动测试的Testcase实现的QTP testcase。

Mngt. Tools是一些脚本工具，来自动化批量执行，产生测试报告，生产代码文档等工作。

Function Library是对产品操作的封装库。对产品的操作既包括高层次的业务层面的操作比如“创建一个用户”，也包括低层次的对某个GUI元素的操作，比如“Click Button”。它的封装形式并不限于Function，QTP支持的Reusable  Action也是一种封装形式。一个测试框架应该包括Function Library和Mngt Tools两个部分，但因为Function Library是主要的部分，所以，有时候也把Function Library叫做Framework。在本文里，并不涉及Mngt. Tools,所以两个名词是可以互换的。

决定一个framework最否有效解决问题的关键是它对问题领域的抽象。所以下一篇，我要介绍Framework里最重要的两个抽象。