Primeton BPS Web自动化测试性能之统一测试框架篇

3年前

本文主要介绍了在某单位实施自动化测试过程中,如何编写自动化测试用例,保证自动化测试框架满足测试需求。 因为测试内容多,执行时间长,环境特殊,所以在编写用例过程中对测试公共方法优化,并编写自动化测试用例工具,下文描述了详细优化内容以及达到的效果。

摘要


本文主要介绍了在某单位实施自动化测试过程中,如何编写自动化测试用例,保证自动化测试框架满足测试需求。 因为测试内容多,执行时间长,环境特殊,所以在编写用例过程中对测试公共方法优化,并编写自动化测试用例工具,下文描述了详细优化内容以及达到的效果。



web测试方式


1、测试内容分析


某单位整体开发比较规范,一般流程图都是按照规范开发的,

以业务流程的流程图为示例;



从测试角度分析,定义统一的测试方法:


业务流程中需要验证的是环节和由环节串起来的总场景。环节中需要验证环节中页面的字段,和字段的校验;场景需要考虑是否有分叉,有流转条件等情况。


为了测试页面,需要准备测试数据,凡是页面上输入字段内容要从AS400库中读取的表或字段,都需要放入案例准备库,录入复核中的相关数据,都需要放入案例准备库。


2、测试用例实现


1)测试架构


按照测试分层的测试架构方式,测试用例都是被统一测试平台调用;因为项目组中普遍使用的是EOS开发,拖拽的方式使用起来比较方便,所以测试部封装了运算逻辑方便测试调用,测试用例都是由技术组件和业务组件组成,业务组件是和业务相关的内容,是指开发过程中持续积累的。

最底层的逻辑流中调用的都是运算逻辑,调用的是封装好的组件,例如登录页面打开菜单的逻辑流test.web.bpm.qsbHelper.startBrowse.startBrowse_zhxz :

一个环节的完整输入内容并提交的逻辑流:test.web.bpm.qsb.J023_ETFJJDMWH_ZHXZ.ZHXZ_YWSL_110.ywsl_110Pass

整体场景,串起所有环节的内容:

test.web.bpm.qsb.J023_ETFJJDMWH_ZHXZ.ZHXZ.testScene2,“110_业务受理”图元调用了上面的逻辑流:

按照逐层嵌套功能的方式,通过逻辑流调用公共组件方式,提供的公共组件有两类:一类是技术组件,和业务无关,具体对浏览器操作,一类是业务组件,和业务相关,只需要传参数就可以使用,提高构件的复用度,降低编写代码的难度:


    技术组件,例如模拟鼠标事件进行点击或者双击鼠标,获取文本框的信息,做最基础的键盘操作等和业务无关的组件;业务组件,提供了和EAI中流程相关的业务操作,例如登录,领取代办任务,文件上传,EAI菜单等组件,目前不包括通用的verify,共有62个业务组件,测试用例开发人员可以直接调用相关的业务组件。


2)测试组织


定义具体的测试代码结构和命名规范:

 业务流程:

测试业务流程过程中,按照业务流程图的编号,定义每个环节和场景的包名。



一般环节的测试内容是打开了页面后进行字段的校验,所以每个环节的正常操作是先执行任务到那个环节,再在页面中检查验证点。从页面组织的角度是每个环节定义一个before的逻辑流,用来从环节1走到要验证的环节,然后再执行其它的验证点,执行完成后需要退出登录,关闭浏览器。


为此,框架新扩展了功能,就像junit测试中的before和after,配置测试用例,配置了before和after内容的,在执行前都会先执行before,在执行后会执行after。同时根据utp中选择的用例来决定是否执行before和after。对于一个环节来说,只选择了1个用例,会执行一次before,after,选择全部的用例,也会只在最开始执行before,在最后执行after。


 <handler beforeAction="test.web.bpm.fxb.F026_GSZFXDJ.GSZ_GSYXLR_111.before111" afterAction="test.web.bpm.fxbHelper.startBrowse.after" execute-rule="batch">

   <case>test.web.bpm.fxb.F026_GSZFXDJ.GSZ_GSYXLR_111.boxnumVerify</case>

   <case>test.web.bpm.fxb.F026_GSZFXDJ.GSZ_GSYXLR_111.companyfullnameVerify</case>

  <case>test.web.bpm.fxb.F026_GSZFXDJ.GSZ_GSYXLR_111.companyshortnameVerify</case>

 </handler>


 录入复核


在测试录入复核过程中,为了保证测试用例之间的数据相互不干扰,几乎每个测试用例都需要进行数据库初始化的操作,数据库分层主要分为:基准数据,流程数据,案例数据。其中基准数据和流程数据是初始化到一个运行库中,内容较全面,初始化时间也较长,案例数据是初始化到另外一个运行库中,内容较少,初始化时间较短。

为此,框架新扩展了功能,支持测试用例的AS400的数据库初始化操作:


<handler dsName="as400">

       <case id="CASE00543">CGFYBDPF01-showManager-testScene009</case>

       <case id="CASE00535">CGFYBDPF01-addManager-testScene001</case>

       <case id="CASE00536">CGFYBDPF01-addManager-testScene002</case>

<case id="CASE00537">CGFYBDPF01-addManager-testScene003</case>

</handler>


因为设计时,每个初始化操作都对应了案例编号,所以只需要配置对应的案例编号。虽然也提供了初始化400数据库的公共方法,但是使用目前这种方式,可以不用全部执行基准数据和流程数据,而根据所选择的用例只执行一遍,因为一个配置对应的是一组基准数据和流程数据,这样既方便编写代码,也加强了规范,还提高了执行效率。


问题和方案


搭建了整体的环境,采用了上述的管理框架后,整体功能实现没有问题,只是在性能和稳定性上需要继续做优化。


1、测试用例编写效率


问题:

1、 按照最基本的测试用例编写方式,根据测试设计,编写对应的测试逻辑。最开始编写加调试一个40个环节的流程,需要1个人月

2、 因为必须要使用逻辑流开发,所以对于测试人员来说需要熟悉EOS,熟悉逻辑流开发,调试。


原因:

一个流程有40个环节,分析流程图后可能需要5个测试场景,就有5个逻辑流;每个环节对应的完整操作至少需要40个逻辑流;每个环节有10个字段,就需要10个逻辑流,这样这个流程就需要145个逻辑流用例。字段校验的逻辑流是复用的,其它的逻辑流都需要一个个图元拖拽,设置图元属性,整体花费的时间较多。最开始编写加调试一个40个环节的流程,需要1个人月。


改进:

1) 提供业务流程用例生成工具:

 通过解析流程图来分析业务场景,生成场景代码

 通过读取在数据库中的业务流程的环节配置来生成校验字段代码

 通过代码中字段的规范,默认填入字段的xpath


生成代码按照最初定义的组织结构和规范生成,此工具是另一个开发商开发,是开发了eclipse的一些插件,选择流程图即可生成代码,生成代码前对于多路分支需要进行一些配置,生成代码后需要参考设计文档,对生成的测试用例中的用户名/密码,环节字段值等进行修改。并最终进行调试。


这种方式的好处是:

 基于已经配置完成的流程生成代码,效率较高

 生成和规范一致的代码,规范性较好

 生成的逻辑流代码,有不通用的场景时修改方便,灵活性较高


这种方式的劣势是:

 根据开发的代码生成测试用例,不符合测试开发流程

 生成测试用例代码较多,代码维护工作量较大

 对测试人员要求没有降低,还是需要会逻辑流开发、调试


2) 提供录入复核用例配置工具

 根据录入复核的一般操作,建立录入复核测试模型

 通过页面配置完成测试用例编写,生成的是一组配置文件

 页面配置界面中通过代码中字段的规范,默认填入字段的xpath

录入复核页面配置一般操作方式是:配置待测试的录入复核编号和名称 ,配置登录用户名/密码,登录菜单 ,配置测试的执行步骤,配置字段的校验值。配置完成后进行调试录入复核测试用例。



这种方式的好处是:

 按照测试设计文档进行配置,效率较高

 生成的是配置文件,代码维护工作量小

 不依赖开发代码,可以实现开发、测试并行

 测试人员了解业务即可,要求不高

      这种方式的劣势是:

 按照固定步骤配置,灵活性不高


效果:

改进后,一个40个环节的业务流程加调试从1人月,到只需要5人日。

一个录入复核原本编写逻辑流用例加调试需要10人日,改进后需要2人日。


2、测试用例执行效率


问题:

大的业务流程执行时间过长,一个40个环节的业务流程需要12小时。


原因:

测试一个业务流程的过程是需要验证每个环节和场景的。每个环节的验证需要先走到那个环节,然后再进行验证。这样40个环节的业务流程,环节的验证中,第一个环节就走了40遍,第二个环节走了39遍,第三个环节走了38遍,所以加起来的时间就很长.


改进:

1、 分环节验证时,提供公共方法,直接从开始跳到待测试的环节进行字段校验

2、 因为有些页面跳转比较慢,页面等待时间是写定等待多少秒,而实际等待的时间并不是固定的,改进方式是提供公共组件方法可以等待对象出现再进行下一步操作。


效果:

一个40个环节的业务流程只需要2个小时。一个350个环节8个分支的业务流程需要10小时。


总结


某单位在实施自动化测试过程中遇到了时间紧,编写用例任务重,人员基础低等诸多问题,在解决问题过程中,我们优先解决了可用性,再解决易用性,为了提高性能,新开发了几个工具,从目前来看解决了某单位今年的测试内容,也降低了编写用例的难度。


上述是列举了几个典型问题,未来的改进可能需要从易用性的角度和从管理者的视角考虑,希望上面的总结内容能给未来实施的同学一些启发。也希望我们的产品发展越来越好。



COMMENTS

需要 后方可回复
如果没有账号可以 一个帐号。