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小时。
总结
某单位在实施自动化测试过程中遇到了时间紧,编写用例任务重,人员基础低等诸多问题,在解决问题过程中,我们优先解决了可用性,再解决易用性,为了提高性能,新开发了几个工具,从目前来看解决了某单位今年的测试内容,也降低了编写用例的难度。
上述是列举了几个典型问题,未来的改进可能需要从易用性的角度和从管理者的视角考虑,希望上面的总结内容能给未来实施的同学一些启发。也希望我们的产品发展越来越好。
如果没有账号可以 一个帐号。