基础业务平台测试解决方案

2018-06-22   出处:大商所行业测试中心  作/译者: 大连飞创  

摘要:为达成“建立标准化的灵活、高效、开放的技术平台”的战略目标,中金所某基础业务平台应运而生。基础业务平台测试有两大特点一是在DevOps落地的背景下,借鉴精益制造思想,快速交付高质量产品聚焦消除浪费减少成本二是体现架构测试特点无具体业务载体的情况提炼功能点加以验证。在该平台成功发布上线后,对解决方案加以梳理,以期达到经验传播的目的。

背景

为满足灵活多变的业务需求,中金所规划新一代基础业务平台,支撑公司数字化转型,实现技术引领业务的发展目标。基础业务平台基于JAVA语言开发,采用轻量级SOA架构模式,同时借鉴SOA面向服务以及微服务去中心化理念,支持平台与业务分离、业务与业务隔离、数据与业务隔离、抽象与实现分离。基础业务平台由一个平台框架和一系列通用服务系统组成,交易所各业务系统均基于平台框架二次开发,平台框架封装接口规范,提供开发接口,集成日志管理、会话管理、服务注册与发现等基础模块,是基础业务平台的设计核心;通用服务系统为交易所各类业务系统运行所依赖的通用服务,譬如文件管理系统、统一认证系统、工作流系统等,由基础业务平台统一提供。因此,基础业务平台测试分为两部分,一是平台框架测试,二是多个通用服务系统的测试,按照“平台测试先于业务测试”的原则,在正式推广使用之前,通过多种质量控制手段提升平台质量,保障新平台上线平稳运行;另外,探索JAVA类系统测试解决方案,为交易所业务系统架构升级测试做技术储备。

、持续交付过程质量控制

1设计思想

为快速响应交易所各系统的需求,基础业务平台建立持续交付流水线,质量控制渗透研发过程,通过输出高质量产品保证流水线的有效性。

持续交付流水线即是指一个应用程序从构建、部署、测试到发布整个过程的自动化实现[1],通过流水线的建立,实现高频率、短周期上线,减少库存版本的堆积。持续交付流水线的实现对于每个组织都是不同的,取决于组织对软件发布的价值流定义。持续交付成功的基础是质量控制,在持续交付流水线中嵌入一系列测试套件,每经过一步测试,版本质量信心增加一层,产品通过所有测试环节,便可以正式发布,因此持续交付流水线也是一条测试流水线。


                                   图1测试象限图

 Brian Marick提出了如图所示的测试象限[1],被广泛应用于各种类型测试的建模,基础业务平台同样适用。为达到快速反馈的效果,执行速度越快的环节,越靠近流水线前面,因此从第三象限开始顺时针旋转,形成测试流水线。


                          2基础业务平台测试流水线

2.2过程描述

    流水线由构建、部署、测试、发布四个过程组成,对过程的质量控制手段分别加以描述。

2.2.1自动化构建

创建二进制文件和安装包是流水线的首要步骤。戴明提出“内建质量”理论,在代码转测之前发现并修复缺陷,代价是最小的。基础业务平台在构建阶段,引入单元/集成测试执行、代码覆盖率统计、静态代码扫描、安全扫描等质量控制手段,提前评估代码质量。代码覆盖率统计从正向角度记录未覆盖到的代码行数或分支路径等,反向角度可推测出冗余代码。静态代码扫描提醒代码“坏味道”,安全扫描针对安全规范,将潜在缺陷扼杀在萌芽中。

2.2.2自动化部署

   部署是代码成为可用软件的转换环节,对大多数应用程序来说,部署过程都比较复杂且容易出错。提前并频繁地做让你感到痛苦的事情,将自动化部署变成开发流程的一部分。

理想情况下,一套自动化部署脚本支持开发环境、测试环境、线上环境部署,经过频繁的交付验证,部署脚本满足无风险生产上线要求。基础业务平台自动化部署采用配置中心模式,将平台中的配置文件抽象成配置模板,将配置项参数化。部署时从构建机获取二进制包,根据环境情况修改配置模板参数,并替换配置文件,从而实现自动化部署。

2.2.3自动化测试

为达到高质量交付的目的,按照测试象限模型,除第三象限在构建过程内嵌外,其它测试类型在本环节覆盖。

基础业务平台通过Restful接口对外提供API,功能验收测试从接口层出发,包括接口测试和业务场景测试,利用HttpClient模拟http请求,实现底层测试驱动。并发测试使用Jmeter发送多线程并发请求,验证平台是否存在线程死锁、事务不一致等问题。

手工测试不可避免,如探索性测试在整个项目过程中都在持之以恒地做下去,容量、可用性等非功能性测试目前以手工的方式进行。

2.2.4自动化发布

持续交付流水线的最后环节是自动化发布,代码的任何一次修改都有被发布出去的可能性。经过自动化构建、部署、测试的验证,可执行程序处于可发布状态。自动化发布环节的工作是将可执行程序按照发布包规范进行打包,上传至制品库等待上线。

根据发布包制定规则,发布包由文档和可执行程序两部分组成,为充分利用各种配置管理工具的优势,需求、设计等文档类管理沿用SVN管理,代码、数据库脚本等使用GIT管理。打包的自动化步骤分解为:生成版本目录结构、SVN文档下载、可执行程序下载、生成数据库部署脚本、上传至制品库。


平台框架测试特点

    基础业务平台的平台框架部分,作为二次开发的底层框架,一方面提供基础功能模块,一方面提供开发接口以及与第三方组件的集成和扩展能力,同时在性能、可维护性等非功能方面进行设计。平台框架测试方案的制定,与可运行系统相比天然具有特殊性。

3.1白盒测试设计

平台框架无具体业务功能实现载体,测试设计执行无落脚点,为解决这一问题,催生出了Mock开发。基于平台框架编写测试应用系统,保证测试独立性,达成平台框架具备可测试性的目的。框架某些功能支持灵活配置,譬如可配置单一数据库源或者多数据库源、可配置同一用户重复登录或者踢出登录、可配置本地会话缓存或者远程redis缓存,因配置项互斥,决定了Mock系统需要实现多个,分别设置不同的属性验证框架功能。同时,平台规定系统接口分为客户端调用和系统间调用两大类,处理逻辑不同,也需要多个Mock系统互发请求验证系统间接口调用逻辑。

测试设计采用测试点提炼、代码review、Mock编写三部曲的方式循环进行,测试点提炼来源于概要设计文档和框架使用说明,通过此步骤梳理出平台框架测试需求;代码review分析代码实现逻辑,了解二次开发实现方式,此步骤是开展Mock编写的必要条件;最后编写Mock,完成功能点的具象化。以平台支持自定义session为例:除框架已有的token外,系统可以将自定义对象存储在session中;通过代码review了解到框架实现逻辑为登录完成后,顺序调用callBack接口类,可在callBack接口实现类中将自定义对象保存至sessionMock系统实现callBack接口,然后编写APIsession获取自定义对象,便于期望结果验证,最终测试执行过程分解为用户登录Mock系统、调用API接口获取自定义session、期望结果比对。代码review也是静态测试的一部分,代码了解越深入越会发现新的测试点。


3测试设计三部曲

3.2非功能性测试

软件产品质量要求和测试国家标准《GB/T 25000.51-2016系统与软件工程 系统与软件质量要求和评价(SQuaRE)第51部分:就绪可用软件产品(RUSP)的质量要求和测试细则》明确软件产品质量从功能适合性、性能效率、兼容性、易用性、可靠性、安全性、维护性、可移植性8个特性评估。根据基础业务平台的实际使用情况,排除不涉及的兼容性、易用性和可移植性,从性能效率、可靠性、安全性、维护性4个方面开展非功能性测试。非功能测试在类生产环境进行,按照生产1:1部署多机测试环境,硬件与生产环境接近,相关组件基线与生产一致。

性能效率一是关注请求峰值时的系统瞬间表现,如1秒并发500笔请求,二是关注长时间运行后的系统表现,如每秒并发10笔请求且持续12小时,具体评价体现在响应速度、硬件CPU、内存、I/O使用等综合指标数据。

可靠性是分布式部署模式下的重要测试点,也是系统平稳运行的关键。基础业务平台规定apche和tomcat采用双活模式部署,开源组件如redis和数据库采用主从多机部署,测试点在于网络故障、硬件故障等原因导致单节点或多节点挂掉,系统是否可靠运行;另外验证紧急情况下,应急方案、故障恢复时间是否满足相应的保障等级要求。

维护性从保障运维角度出发,对于节点的启停顺序、部署配置便利性、日志等排障手段加以验证。

3.3开源组件测试

平台框架集成了zookeeper服务注册与管理、redis会话管理两个开源组件,属于公共服务部分。开源组件在大量互联网企业得以应用,在业务支持角度验证必要性不大,风险点在于项目集成过程中使用方式的正确与否。

验证点归类为四大块一是验证开源组件与业务系统的独立性开源组件不可用不影响业务系统正常业务二是验证开源组件集群本身的可用性,单节点故障不影响整个集群的服务,且主从之间数据一致;三是验证开源组件和业务系统之间的容错性,组件存在异常数据或者业务系统报送异常数据,不影响正常业务流程;四是验证开源组件和业务系统之间交互的自适应性,网络故障恢复或者服务重启后可自动重连,重连后数据更新正确。


四、工具体系

持续交付分级技术要求包括:配置管理、构建与持续集成、测试管理、部署与发布管理等,需要相应的工具体系做支撑,下图所示为基础业务平台所依赖的工具体系。JAVA语言优势在于拥有大量的开源社区和开源工具,方便在项目中借鉴使用,基础业务平台测试过程就体现了这一特点。


4工具体系

GIT和SVN是配置管理主流工具,SVN适合文档管理,而Git优势在于代码协同开发、分支管理等,因此文档类使用SVN管理,代码、部署脚本、测试脚本等由Git管理。

测试管理是使用工具最多的部分,分构建阶段、系统测试阶段和用例缺陷管理三部分加以介绍。

构建阶段代码覆盖率统计工具Jacoco评估单元测试覆盖率,SonarQube对代码进行静态扫描。Jacoco支持高JDK版本,可嵌入maven工程,并提供EclEmma Eclipse插件,方便开发人员在开发过程统计单元测试覆盖率;该工具同时支持系统测试代码覆盖率统计,使用JavaAgent技术监控Java程序。SonarQube集中展示静态代码扫描结果,扫描动作通过Sonar Scanner插件完成,集成findbugs、checkstyle等静态代码检查工具,可自定义检查规则,同样方便maven工程集成。

系统测试阶段Fitnesse运行后端功能自动化用例,Jmeter发送并发请求。Fitnesse适合API接口类测试,测试驱动编写和用例编写相分离,方便分工合作。Jmeter支持并发http请求,模拟浏览器操作,也可以直接调用测试驱动,实现测试驱动的复用。性能监控则使用JDK自带的JConsole,可远程监控Java程序使用的内存CPU等参数自动生成报表

TestLink管理手工测试用例,JIRA跟踪缺陷处理,不再赘述。

基础业务平台有两种发布方式一是平台框架发布二是通用服务系统发布。平台框架不上线,平台框架的发布意味着将正式的jar包提供给二次开发系统依赖使用,管理工具采用JFrog,发布时将正式jar包提交至JFrog,二次开发系统更新maven依赖版本,从JFrog获取最新jar包。通用服务系统发布面向保障上线,以发布包的形式提供,制品库目前由FTP管理。


、总结

DevOps理论落地的大背景下,基础业务平台测试解决方案借鉴精益制造思想,构建持续交付流水线,快速交付高质量产品为之后交易所业务系统架构升级积累了测试资源按照上述测试解决方案,基础业务平台的平台框架已成功发布2个版本,推广至多个业务系统使用;3个通用服务系统生产上线,平稳运行至今。


六、参考文献

[1] Jez Humble,David Farley.持续交付:发布可靠软件的系统方法[M].乔梁译.北京:人民邮电出版社,2011.10



欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
199°|1997 人阅读|0 条评论

登录 后发表评论
最新文章