吕振山
【摘要】 移动联调测试工作引入自动化势在必行,本文主要从业务角度和自动化框架实现的角度进行分析,论证联调测试工 作引入自动化的可行性,从业务角度主要分析业务实现自动化的要素,以及自动化的结果判定标准,从自动化角度主要分析自动化的框架搭建,以及自动化的实现流程,并从工作效率及人力成本的角度对自动化实现前后进行总结。
【關键字】 自动化 联调测试 充值业务 JENKINS
Abstract:System interaction test of CMCC is trend, The article analysis form business and automation frame to prove practicability of automation, From business analysis key element of realizing automation and judging standard, From automation analysis frame build and work flow, Then sum up work efficiency and human cost of realizing automation.
Keywords: Automation System Interaction Test Recharge Business JENKEINS
一、引言
随着互联网的快速发展,移动充值业务也与互联网紧密结合,与多家互联网公司合作,不断增加网站和APP的充值接口,随着业务的不断扩展,与31省的联调测试工作变得越来越繁多, 而这些联调测试工作都是重复的,因此联调测试工作引入自动化变得越来越必要。
移动运营商的联调测试,即是指31省的移动业务支撑系统与中心的业务支撑系统,以及第三方系统实现对接的测试,由于涉及的系统多且跨区域,使联调测试的难度系数大大增加,31省及第三方系统的资源投入及自身系统的稳定性,存在太多不确定因素,作为中心的业务支撑系统与之对接测试,必然会造成一定的资源浪费,因此联调测试引入自动化即可解决资源浪费,又可以提升联调测试的效率。
二、移动业务实现自动化分析
根据移动运营商现有业务,需要联调测试的业务按照处理方式可以划分为实时交易和对账两大类型的业务,实时交易属于消息类型的业务,对账属于文件类型的业务,两种业务存在质的差别,因此自动化的实现框架会存在一定差别。
在讨论自动化实现框架之前,首先对当前联调测试各方的角色进行一个简单的介绍,中心系统统一进行实时消息的转发及数据信息的管理,省侧即可做为实时交易业务的发起方,也可做为实时交易的结束方,而第三方系统只能做为实时交易业务的发起方,对账类的业务也是由中心系统实现三方对账,对账的差异下发给相应的系统,中心系统做为一个核心与各方系统进行对接及联调测试,联调测试由中心系统的联调人员组织,并进行联调结果的记录和联调状态的通报。
实时交易类型的业务,主要是通过实时消息进行充值和查询等业务的操作,当前的联调方式主要是通过联调人员手动,由省侧或者是第三方系统发起,通过中心系统进行转发,各方联调人员通过对业务的处理结果判断联调用例是否通过。
分析实时交易类业务的联调特点,同一用例31省各测一遍,需要重复测试31遍,自动化恰巧是解决重复测试人力浪费的技术,中心侧实现自动化后,整个测试过程可变为:一、发起方根据测试用例批量发起交易,测试用例对应的关键信息整理为表格,发给中心侧。二、中心侧根据表格关键信息作为自动化的输入,进行自动化检测,判断中心侧处理结果。这样中心侧联调人员只需要检查自动化的执行结果,就可以判断联调是否成功,既节省人力又提高了效率。
对于实时交易关键信息的提取,发起方需要提取的关键信息是:每个用例执行的交易流水号,作为中心侧自动化执行的输入。
中心侧自动化输出信息包括:自动化执行结果和省份信息,以判断是哪个省份用例的执行结果。
自动化如何判断执行结果是否通过,不同的业务流程,有不同的判断标准,下面就以移动商城充值流程为例来探讨如何精确的判断执行结果。首先看一下移动商城的充值流程:
根据流程图,中心系统与其它系统交互点有6个:
1、中心系统收到移动商城发起的充值请求
2、中心系统给移动商城回应确认收到充值请求
3、中心系统发送充值请求到省系统
4、省系统返回充值结果给中心系统
5、中心系统返回充值结果给移动商城
6、移动商城给中心系统回应确认收到充值结果
因此对于中心侧判断充值是否成功需要从这6个方面进行信息提取,作为判断依据:
1、自动化检查移动商城回应的报文,若报文存在则此判断通过
2、自动化检查省返回给中心系统的充值结果报文,报文头的“应答/错误代码”和“应答/错误描述”以及报文体“二级应答码”和“应答描述”,这些字段值与预设的值进行比对,若一致则此判断通过
3、自动化检查中心系统返回给移动商城的充值结果报文体的“交易结果代码”和“交易结果描述”,这些字段与预设的值进行比对,若一致则此判断通过
4、自动化检查移动商城收到充值结果的回应报文,若报文存在则此判断通过
依据这个判断标准可以精确的判断用例是否执行通过,联调人员只需要查看自动化的执行结果和对应的省份,就可以确定用例是否执行通过,其它流程依据这个思路亦可实现自动化。
对账属于文件类型的业务,对账的基本流程相对实时交易比较简单,仍以移动商城的对账为例,首先简单介绍一下对账流程,省对账文件和移动商城对账文件每日定时自动上传到中心系统平台,由中心系统平台进行对账,对平的记录和有差异的记录生成文件发给移动商城,并生成差异文件下发给省,对于自动化结果的输出省份和文件下发信息,执行自动化后联调人员可以清晰的看到各省文件下发情况,此时自动化不能直接判定对账用例是否通过,仍需要线下与各方确认文件的处理结果后,才可以判定用例的执行结果,此处实现自动化的目的优化联调人员重复的查看日志和相应表格,提升工作的效率。
每个联调过程都会有新版本的提交,由于服务器比较多,环境部署也是一个繁琐重复的过程,公司的版本管理流程规范化为实现环境部署自动化创造了优越的条件,对于环境部署的构思,也可以引入自动化,大大减少人工参与的程度,减小了版本升级过程人工误操作的风险,各服务器同时并行版本升级,也大大减少了版本升级花费的时间。
三、自动化框架分析
接下来讨论一下自动化框架的搭建,现在流行的自动化构建工具比较多,根据不同的需求,可以选择适合自己的构建工具,联调自动化的引入,计划采用JENKINS构建自动化框架。
如下图2是对自动化框架的整体构思。
JENKINS构建自动化涉及的主要插件有Robot Framework Plug-in、Email Extension Plug-in、Token Macro Plug-in、FTP Publisher Plug-in、SSH Plug-in,对于所需的JENKINS插件及其安装,这里就不再赘述,这里主要讨论一下自动化的整理架构,自动化的处理过程是一个端到端的过程,在整个过程中不需要人为干预,整个自动化实现流程如下:
1、发布版本归档到SVN,自动化脚本实现自动获取版本,放入指定目录;
2、自动化自动执行版本编译,编译完成后自动进行版本部署,在版本部署过程中出现任何错误,都会进行版本回退;
3、版本部署成功后自动执行用例脚本;
4、执行完所有脚本后自动生成自动化执行结果报告,并邮件发送给相关人员。
四、总结
从业务角度分析及自动化实现框架分析,联调工作具备引入自动化的条件,且可以实现,实现自动化后,整个联调过程中心侧联调人员,人工干预的程度就非常的小,由于参与联调的机构较多,无法端到端的实现自动化,因此只能从自身的工作内容考虑,来进行优化。根据当前人工联调的效率的估算,实现自动化后,每次联调只需要投入1-2人就可以高效的支撑31省的联调工作,减少人力的投入,节省人力成本,在此也体现了自动化解决重复工作问题的优越性,在工作过程中需要不断的总结,不断的过程优化,以提升工作的效率。
參 考 文 献
[1]统一支付平台与移动商城系统接口技术方案-V1.0.7,2014年
[2] Jenkins用户手册V1.0,2014年
[3]刘华婷.基于Jenkins 快速搭建持续集成环境[DB/OL].(2011-11-24)
[4]陶镇威.基于Jenkins的持续集成研究与应用[D];华南理工大学;2012年
[5] Jenkins: The Definitive Guide,John Ferguson Smart,2011年7月
[6] teve McConnell.Daily build and Smoke Test[J].IEEE Software, 1996, 13(4):144-143