QTP与QC的完美结合实现自动化测试框架业务组件测试.docx

QTP与QC的完美结合实现自动化测试框架业务组件测试.docx

《QTP与QC的完美结合实现自动化测试框架业务组件测试.docx》由会员分享，可在线阅读，更多相关《QTP与QC的完美结合实现自动化测试框架业务组件测试.docx（10页珍藏版）》请在冰豆网上搜索。

QTP与QC的完美结合实现自动化测试框架业务组件测试

QTP与QC的完美结合实现自动化测试框架－业务组件测试

做功能自动化测试都会不约而同的遇到一个比较棘手的问题－测试框架的搭建。

这也是直接影响功能自动化测试成功与否的关键。

框架做的好可以使测试事半功倍，反之轻则很难看到工作的成果重则会使整个测试失败。

目前网上有很多关于测试框架的讨论，其中也有成型的测试框架，其中有很多好的思想在里边，很值得借鉴。

但今天要讨论的不是网上已有的，而是HP已经为我们设计好的一个测试体系，业务组件测试。

他是利用QTP与QC的完美结合组成的一个体系架构。

它可以轻易实现目前比较流行的三层测试架构：

脚本层，业务层，数据层相分离，为开展功能自动化测试提供一个高效、稳定、容易的测试实现。

       一．概述

       1．1业务组件（BussinessProcessTesting）简介

       业务组件是组成流程测试的基本单元，组合不同的业务组件可以实现不同的业务流程测试。

如将fligt系统的登录最为一个组件，选择航班最为一个组件等。

这样可以实现组件的复用，提高开发效率。

        1．2BussinessProcessTesting的优点

       1）  相关业务人员可以在没有脚本的环境下组合业务组件，实现业务流程。

       2）   对业务人员的编程能力没有要求，业务人员只需了解系统的业务流程，不用关心具体的脚本实现。

这一点也实现了业务层和脚本层的分离。

       3）   一旦某个组件开发完毕，即可在不同的流程中使用该组件，实现高可复用性，从而加快业务流程测试的速度。

       4）   明确的角色分工，业务人员负责流程的开发、组织；QTP工程师负责脚本的开发、维护以及相应函数库的开发、维护。

       5）   因为实现了脚本的复用，提高了自动化开发的效率，无形中就降低了测试过程中维护的时间和成本。

       1．3BussinessProcessTesting的简易流程

       如图所示，整个过程分为2条线：

第一个是由业务测试人员划分组件并组合不同的组件实现不同的流程测试；其次QTP专家负责组件的脚本具体实现并负责调试成功，上传到QC供业务测试人员调用。

       注：

测试数据的组织后边介绍，以便实现三层的测试架构；此过程需要QC有BussinessProcessTesting组件许可的支持，也就是需要单独向HP购买。

       下边以QTP自带的示例程序演示整个流程的开发过程

       2．1划分组件

       本次将系统划分为：

登录；选择航班并插入；打开订单；更新订单；删除订单；注销。

这样划分仅为演示之用，不用在实际的测试之中。

       2．2组织业务测试流程

       本次只是用于演示，所以流程不会100％覆盖，在实际的测试过程中要达到100％的流程覆盖。

本次测试流程如下：

       流程1：

登录－选择航班并插入－注销

       流程2：

登录－选择航班并插入－更新订单－注销

       流程3：

登录－选择航班并插入－更新订单－删除订单－注销

       流程4：

登录－打开订单－更新订单－删除订单－注销

       下边需要根据划分的组件来实现组件脚本的实现。

       2．3创建应用程序区域

       在开发脚本之前首先要做的是要创建一个应用程序区域。

应用程序区域提供创建业务组件所需的所有资源和设置，每个业务组建都居于一个应用程序区域，并从这些应用程序区域集成这些资源和设置。

在此创建一个名为“订票系统流程测试”的区域，如图所示。

       创建过程:

依次选择:

file－New－Functionlibrary。

保存后自动上传至QC默认目录。

       在此也可以加载自己的函数库，对象库，恢复场景等，这样以后创建的组建都可以共享该应用程序区域的资源。

同时也方便维护，这也是一个优点所在，例如一旦函数库改变在此从新加载新的函数库即可，不用在脚本理修改。

总之这个应用程序区域很重要，以后所有的脚本均是基于这个区域。

应用程序路径一定要加载正确，否则录制时不能生成脚本。

       2．4创建脚本

       在创建脚本之前最好在QC中组织好目录树，方便保存及调用。

关于脚本的开发过程，每个人、每个公司都有自己的方法。

在此源代码也没法一一贴出。

所以在此只列出输入参数和输出参数，方便后边的参数化以及数据组织。

本次也采用最通用的方式即对象库解决对象识别问题。

脚本的开发规范以及参数命名也以我自己惯用方式。

输入参数

输出参数

名称

说明

名称

说明

登录

logName

用户名

－

－

logPassW

密码

－

－

选择航班并插入

planeData

航班日期

orderNo

订单号

planeFrom

起点

－

－

planeTo

终点

－

－

orderName

订单名称

－

－

ticketNum

机票数

－

－

berthType

舱位种类

－

－

打开订单

orderNo

订单号

－

－

更新订单

planeDate

航班日期

－

－

planeFrom

起点

－

－

planeTo

终点

－

－

orderName

订单名称

－

－

ticketNum

机票数

－

－

berthType

舱位种类

－

－

删除订单

－

－

－

－

注销

－

－

－

－

 注：

“－”为无相应参数。

       在QTP中创建组件脚本有2中模式：

BussinessComponent和ScriptedComponent。

区别：

BussinessComponent只能见关键字视图，QC中亦可见关键字视图；ScriptedComponent可以看见专家视图，在QC中脚本代码不可见。

一般创建后者，本次也是采用后者，方便编辑脚本，控制脚本结构。

       注意：

参数一定要合理设置并对代码中的输入项做参数化与参数关联，否则测试数据传不到脚本，导致脚本运行失败。

参数可以在QTP中创建，也可以在QC中创建，效果等同。

       脚本开发完保存至QC，如图:

输入订票的信息，并将信息插入到数据库中。

用户拥有订票的权限。

成功输入录入信息并保存。

      至此脚本开发完毕。

也实现了脚本和业务层、数据层的脱离，现在单个组件脚本实现业务流程中的某一个功能且脚本中不会涉及具体的测试数据，从而为实现三层结构打下基础。

接下来的工作就是在QC中组织需要测试的业务流程以及需要的测试数据。

       这里有一个需要注意的地方，就是在QTP创建脚本如果选择BussinessComponent类型，在“设计步骤”选项卡可以看到QTP中的关键字视图，相关人员可以像在QTP操作一样，但是看不到代码。

这也是为何上边为何创建脚本组件的原因。

       2．5业务流程的组织

       业务流程的组织主要是在“测试计划”模块中实现。

这的主要工作是由业务测试人员完成。

规划好目录结构以后，根据需要测试的业务流程拖拽需要的组件即可。

这一步和在“测试计划”中拖拽测试用例很相似，区别就是这个是组合业务流程，而且可以自动执行。

组织好后的效果如图：

       需要注意的是，创建用例是请选择“BUSINESS-PROCESS”测试类型，否则组件脚本拖拽不过来。

拖拽脚本是在“测试脚本”选项卡中进行，如上图。

限于篇幅，在此创建目录和拖拽等动作不再详述，请参见QC的用户手册。

另外，根据实际的系统，可以把组件分组，以组的形式控制流程。

例如，选择如图的2到4的组件，然后选择工具栏叉号旁边的图标，即可把组件分成一组。

这样可以更好的控制流程。

至此，所有的业务流程均以实现。

可以在QC中选择运行（绿色箭头），进行相关的调试。

       这里实现的是三层结构中的业务层。

这里进行的业务流程组织和脚本没有任何关系，相关人员不用关心脚本如何实现，只要保证所有的流程均已覆盖即可。

       接下来就是要实现数据层的工作了，从而实现三层的测试架构。

       2．6测试数据的组织

       测试数据的组织也是在“测试计划”模块中实现。

选择某一个流程，在“测试脚本”选项卡中右击要设计数据的组件，在弹出窗口中选择“迭代”，弹出组件迭代设置窗口，如图：

       在此可以根据测试需求设置组件要迭代的次数，以及每次迭代的参数值。

如上图，设置了3次迭代每次迭代输入的订单信息均不相同。

同时可以设置输入参数选择上一个组件的输出参数（在复选框中打勾，按提示操作即可），如下图。

是流程4中的“打开订单”组件，orderNo参数使用的是“选择航班并插入”组件的输出参数。

注意，此流程的“选择航班并插入”设置了三次迭代，所以“打开订单”也要对应三次迭代，否则会提示错误。

       在组织数据时，可以在单个组件中设置每次迭代的数据，由于组件的重用次数很多，所以这样做还是有些麻烦。

解决方法就是在外部组织好数据后，批量导入。

QC默认是txt文本文件，格式可以把现有参数导出，参照它给的格式设计自己数据即可。

       至此，数据层的设计也已完毕。

同时也实现了测试数据和具体的业务流程相分离。

       其实，这里的数据和业务层的分离并不是很彻底，不能根据自己的想法去设计，所以还有很大的改进空间，还需要进一步研究。

       通过以上几个步骤，开发工作基本结束。

以后就是需要相关的维护即可。

当然，最后还是要执行测试。

2．7执行测试

       测试的执行是在“测试实验室”中进行的。

这里和操作QC执行用例很相似。

也是组织目录，拖拽相应的测试流程即可，这里也不在累述。

可参见用户手册执行测试用例部分。

当然执行测试可以选择本机执行，也可以选择在远程机器上执行测试，但要注意要安装相应组件和设置主机。

执行效果如下图：

       QC会记录每次执行的结果，包括流程中每个组件的执行状态，执行时间等信息。

这也是QC的强大之处，它会给出一个很人性化的结果，方便我们后续的分析工作，以及对系统给出一个量化的指标。

这一点QC做的相当完善，从需求开始到最后的缺陷分析以及测试报告，都会有一个图形的界面供我们参考，这对我们写测试报告提供了极大的方便，给我们提供了强有力的，可靠的数据支持。

       注：

以上全部工作在WinXP（sp3）＋QTP9.2＋QC9.0环境下完成。

       三．总结

       本文只是针对业务组件测试给出了一个简单叙述，QTP以及QC的强大之处远不及这些。

对于QTP和QC的其他功能本文没有提及，其他功能在自动化测试中起到的作用，是有些工具不能代替的，也许这也是现在很多公司、很多人都在学习、使用的原因之一吧！

前一段时间51的调查文件就是一个很好的证明，HP（Mercury）的所有产品都是遥遥领先其他工具。

当然有很多公司也有自己的测试框架，也有自己开发的测试工具。

但不可否认QTP确实是一个很好的测试工具，虽然它很贵。

需要提到的是，QTP和QC是一个开放式的架构，HP（也就是以前的MERCURY）为我们提供了很多接口，我们完全可以利用这些接口开发出自己的框架，实现三层乃至更高的框架结构。

这些接口以及函数说明都能在QTP的帮助文档中找到。