• 12
  • 12
分享

  票据系统交易具有错综复杂,跨系统,多协议的特点。为更好的开展票据系统接口自动化测试,提升接口测试水平,笔者基于Xmeter(客户端版)开展系统间接口测试,积累环境可用性的快速验证方法和测试数据准备方法。

  一、背景

  测试人员在票据系统的测试过程中,发现业务流程很长,系统间调用频繁,比如票据系统要和C3、BoEing,网银交互,还和ECDS交互,还用到Air,内部也是有票据交易系统(CPES),贸易通(HERMES),数字票据(DCDP),每个系统都有单独的界面和服务,票据系统还有服务端,用户端,前置,批量等子系统,相互调用,协议众多,包括http和soap协议,后续还要推广DevOps,自动化,性能,同时测试人员也饱受各种票据操作和出票流程的困绕,繁琐而重复。

  二、工具

  结合自己对测试工具的了解,包括行内的擎云,Xmeter(客户端版),Xmeter等。擎云自动化目前有个局限,暂时无法进行界面和接口的联合自动化,而且系统跨BoEing,CPES,DCDP,C3也为擎云自动化增加了难度,

  选择Xmeter(客户端版)进行尝试,一是作为一款业界流行的性能测试工具,该工具在实际的性能测试中,可以应对多种协议,界面和接口交易,可以说不惧任何协议,不惧界面接口,应用广泛。

  三、研究

  1.通过性能测试工具抓取界面或者接口交易的原理,进行扩展发散,以数字票据电票出票申请为例,如下图:

1-1.png

  填写界面参数,包括反显的内部接口(红框里),均能被Xmeter(客户端版)捕捉到,如下图:

1-2.jpg

  下面截图就是第一个红色框反显的调用的接口。

1-3.png

  Xmeter(客户端版)提供参数化和回放功能,合理的配置可以轻易满足回归测试需要,同时进行简单的初步性能测试。

  2.Xmeter(客户端版) 还可应用到BoEing的票据模块的接口交易的测试,以BoEing结算服务中的承兑回复经办为例。

1-4.png

  从BoEing开发人员或者Log中获取报文,拼装报文,通过Xmeter(客户端版)作为接口测试工具,如下图,业务编号可以参数化为${业务编号},业务编号可以通过前后交易关联获得,也可以去数据库中查找。

1-5.png

  3.Xmeter(客户端版)同样适用于C3系统的界面录制。

1-6.png

  录制完成的Xmeter(客户端版)脚本如下图,发起手工登记保存,涉及到工作流需要通过正则表达式从上一交易中获取,省去了这种情况在ATP接入时需要二次开发解析的过程。

1-7.png

  4.Xmeter(客户端版)另一个优势就是可以连接数据库获取所需数据,数据库配置如下。

1-8.jpg

  查询所需数据,直接将sql语句嵌入即可,参数也可参数化。

1-9.jpg

  四、希望

  经了解,目前TFS暂时无法调起Xmeter(客户端版)或Xmeter,在DevOps推广中没有勇武之地,后续如果TFS能直接调起Xmeter(客户端版)或者Xmeter,将会从另一方向提高中心接口自动化水平和DevOps加分点,因为Xmeter(客户端版)是性能测试工具,TFS调起Xmeter(客户端版)或者Xmeter,即是接口自动化回归和性能测试自动化的又一方式,可以与行内擎云平台互补。

  五、总结

  老生常谈,工欲善其事必先利其器,经过了对Xmeter(客户端版)一定的摸索和研究,结合现在中心强调的DevOps工作和接口测试深化工作的开展,借此契机,向各位读者介绍Xmeter(客户端版),希望能抛砖引玉,让各位受益于Xmeter(客户端版)的使用,应用于自己的开发和接口测试中,将银行研发测试一体化工作提升上新台阶。


作者:王炜   

来源:51Testing软件测试网原创

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 一、Appium加载的过程图解Appium的原理WebDriver script:我们的测试脚本(java or python)Appium:会首先开启一个监听4723端口的server,接收测试脚本发送过来的对应请求,再将对应的请求发送给中间件Bootstrap.jar(注意这里的请求不是整个脚本文件,而是对应的命令请求,比如:点击一个元素就是一条请求)Bootstrap.jar:监听4724端口由appium发送过来的相关请求,并且将请求转换成UiAutomator可以识别的命令发给UiAutomator进行处理二、初步认识appium工作过程appium是c/s模式的 appi...
            0 0 1154
            分享
          • 测试用例运行稳定性是自动化质量的一个重要指标,在运行中需要尽可能的剔除非bug造成的测试用例执行失败, 对于失败用例进行重跑是常用策略之一。一种重跑策略是所有用例运行结束后对失败用例重跑, 另一种重跑策略是在运行时监控用例运行状态,失败后实时重跑。下面,详细介绍TestNG如何对失败测试用例实时重跑并解决重跑过程中所遇到问题的实践和解决方案。对失败测试用例进行实时重跑,有以下几个方面需求:测试用例运行失败,监听到失败后立即进行重跑;测试用例通过 dependsOnMethods/dependsOnGroups标记依赖其他测试用例,在被依赖的测试用例重跑运行成功后,该测试用例可以继续运行;对于重...
            0 0 921
            分享
          • Android App兼容性测试是一个比较重要的App评价内容,实际上兼容性测试不仅仅和测试人员相关,在开发阶段就应当着重考虑,因为兼容性问题是除了实现App本身要求的功能后,必须要关注、而且至关重要的一个点。因此,App兼容性是否良好,首先要求App开发人员在开发阶段进行保障,有经验的Android工程师能够在开发过程中保证60%以上用户机型的兼容与适配,经验丰富的工程师几乎能够做到90%以上的兼容适配。当然,由于市场上Android机型出新速度快,系统升级快,一味的追求在开发阶段的兼容适配保障,一方面延误开发进度,另一方面需要较高的开发投入,因此需要做好权衡,这也是后续Android兼容性...
            0 0 853
            分享
          • 在测试工作中,缺陷管理是我们必不可少的工作内容之一。既然是管理,也就少不了时间、人物和管理内容。本文将分享软件项目中缺陷管理的基本内容以及对缺陷管理的一些思考。如图1-1所示,缺陷通常包含以下八个状态:打开、重新打开、已修复、未复现、问题重复、不是问题、延期修复和关闭。其中,研发人员需要关注和处理打开和重新打开这两个状态下的缺陷,测试人员需要关注和处理已修复、未复现、问题重复、不是问题和延期修复这五个状态下的缺陷。当然,不同企业对缺陷状态的设置会存在一定的差异,本文暂时以这些状态为例。图1-1 软件缺陷状态图当我们新录入一个缺陷后,缺陷即处于初态,也就是处于打开状态,这时缺陷的负责人就流转到了...
            0 0 847
            分享
          •   对于测试人员、开发人员来说,善用抓包工具确实是快速分析和定位问题的一大必备神技,现将配置过程记录如下:  1、打开jmeter后,首先添加一个线程组:  2、线程组可以重新命名按项目名称分类:  3、然后在工作台里添加一个代理服务器,把你的电脑做为一个代理服务器。  4、然后配置代理服务器,选择目标控制器,选择你要录制的线程组,比如说这里我选择的就是测试项目。然后点击启动就可以了,其他的配置可以先不管。  4.1 这里重点说明一下,要在HTTP代理服务器下增加一个查看结果树,这样抓到的接口地址、请求参数、返回数据才能够完整显示出来,才能够分析问题,有很多文章都没有说明这一点,其实就只是一个...
            0 0 2153
            分享
      • 51testing软件测试圈微信