QTP与QC组合业务组件案例PPT推荐.ppt

QTP与QC组合业务组件案例PPT推荐.ppt

《QTP与QC组合业务组件案例PPT推荐.ppt》由会员分享，可在线阅读，更多相关《QTP与QC组合业务组件案例PPT推荐.ppt（32页珍藏版）》请在冰豆网上搜索。

每个组件均与特定的应用程序区域相关联，这使其可访问所需的任何资源和设置。

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

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

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

业务组件简介,业务组件利用QTP与QC的完美结合组成的一个体系架构。

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

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

组合不同的业务组件可以实现不同的业务流程测试。

利用业务组件进行自动化测试的优点：

形象的讲就是：

模块化、标准化、搭积木,相关业务人员可以在没有脚本的环境下组合业务组件，实现业务流程。

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

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

具体体现：

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

明确的角色分工，业务人员负责流程的开发、组织；

QTP工程师负责脚本的开发、维护以及相应函数库的开发、维护。

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

具体工作流程,下面以QTP自带的示例程序演示整个流程的开发过程,划分组件,组织业务测试流程,创建应用程序区域,创建脚本,组织业务流程,组织测试数据,执行测试,本次将系统划分为：

登录；

选择航班并插入；

打开订单；

更新订单；

删除订单；

注销。

1、划分组件,流程1：

登录选择航班并插入注销流程2：

登录选择航班并插入更新订单注销流程3：

登录选择航班并插入更新订单删除订单注销流程4：

登录打开订单更新订单删除订单注销下边需要根据划分的组件来实现组件脚本的实现。

2、组织业务测试流程,首先要做的是要创建一个应用程序区域。

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

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

首先连接QC：

http:

/192.168.100.19:

8080/qcbin创建过程:

fileNewApplicationArea。

依次选择:

fileNewFunctionlibrary。

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

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

同时也方便维护，这也是一个优点所在。

例如一旦函数库改变在此从新加载新的函数库即可，不用在脚本理修改。

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

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

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

根据组件功能在QTP中录制相应的脚本，在此只列出输入参数和输出参数，方便后边的参数化以及数据组织。

4、创建脚本,注：

“”为无相应的参数,在QTP中创建组件脚本有2种模式：

BussinessComponent和ScriptedComponent。

区别：

BussinessComponent只能见关键字视图，QC中亦可见关键字视图；

ScriptedComponent可以看见专家视图，在QC中脚本代码不可见。

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

注意：

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

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

关键字模式实现脚本、业务层、逻辑层的脱离,脚本录制完成之后，保存至QC中。

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

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

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

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

主要是在“测试计划”模块中实现。

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

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

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

5、组织业务流程,测试计划新建测试选择测试类型为：

BusinessesProcess，测试脚本中为测试计划添加业务组件。

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

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

组件之间的流程衔接是否匹配可以在“运行或调试测试”中进行调试。

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

选择某一个流程，在“测试脚本”选项卡中右击要设计数据的组件，在弹出窗口中选择“迭代”，弹出组件迭代设置窗口,6、组织测试数据,可以根据测试需求设置组件要迭代的次数，以及每次迭代的参数值。

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

同时可以设置输入参数选择上一个组件的输出参数（在复选框中打勾，按提示操作即可）.,至此，数据层的设计也已完毕。

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

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

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

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

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

其实无论是在手动测试还是在自动化测试当中，引入“业务组件”的概念，都有助于我们实现业务流程之间的组合，组合不同的组件实现不同的流程测试，规范业务流程，提高测试的覆盖率。

后语,谢谢大家！