银行IT架构转型下测试工作实践与思考

本文节选自《金融电子化》2018年8月刊

作者:中国银行软件中心

赵月 段颖颖 吴冰

编者按

本文探讨了银行IT架构转型给测试工作带来的挑战,并介绍了中国银行主机下移项目的测试实践过程。

银行IT架构转型对测试工作的挑战

当前,互联网金融对传统银行经营带来全面而系统性的冲击,银行信息系统架构转型成为必然趋势。银行大多采用集中式技术架构建设核心交易处理系统,以满足海量客户数、账户数、交易量条件下对业务处理的一致性、实时性和安全性要求。分布式技术架构源于并行计算处理,擅于处理大数据量、高并发量业务场景。互联网公司将分布式技术架构应用于搜索、电商、云服务等领域,充分体现出其在高并发业务处理、海量数据分析和系统建设成本等优势。为满足网络化、数字化和智能化的转型需要,银行需要为不同类型的应用系统选择不同的技术架构。采用集中与分布式并存的融合架构,成为银行业IT架构的新形式。

在银行IT架构从集中到“集中+分布”的转型过程中,如何平稳地完成传统应用向分布式架构的迁移?我们认为,针对传统应用系统迁移工作,有两个方面需要重点关注。一方面是业务功能重塑,即将原有系统迁出的功能基于分布式架构进行重塑,与原集中式架构保持一致,迁移后与其他业务系统逻辑关系保持不变。另一方面是应用系统迁移过程中涉及的业务数据处置,主要包括新建系统数据的一次性迁移或动态同步更新,以保证业务的延续性。测试工作同样也需要关注该重点,传统的测试分析方法能否适应新的挑战,测试质量能否得到保证,测试成本能否得到有效控制,这都成为摆在我们面前亟待解决的问题。

中国银行主机下移项目的测试实践

过去,我行国内核心银行系统联机交易、批量处理及数据批量下传工作均在主机上进行,主机资源的消耗日益增加,而主机资源成本高昂。为节省IT运营成本,我行决定新建分布式非金融核心系统,将主机平台上对交易响应时间不敏感,而CPU消耗占比较高的非金融交易,迁移到成本较低的X86平台,达到降低主机资源消耗、节约IT成本的目的。

此项工作首批实现主机CPU消耗占比最多的查询类交易下移,基于X86平台重塑这些查询交易的业务功能,将交易涉及的业务数据从主机DB2数据库同步到X86平台Oracle数据库,实现103个外围产品对核心银行系统此类查询交易的调用从主机平台转到X86平台,预期降低主机CPU消耗44%。项目后续还将完成主机数据批量下传功能及其他非金融交易的迁移。在此项目中,需重点关注两个方面:下移的业务功能重塑与业务数据处置。

01

业务功能重塑。

传统的功能测试采用黑盒分析方法,以业务场景的覆盖完成新建系统的交易验证。因涉及103个外围产品的全业务场景覆盖,测试难度较大,且难以穷尽所有业务场景,容易因业务场景分析遗漏而无法保证测试质量。因此,测试工作从新建X86核心银行系统作为接口提供方的角度考虑,采用灰盒测试方法,解决接口全字段覆盖的完备性问题,再辅以黑盒测试方法通过外围产品执行交易,进行端到端验证,保证业务主体逻辑的正确性。

在接口测试的分析工作中,我们从接口规范定义出发,梳理出接口报文的组包规则,将外围产品业务场景的验证转换为对接口报文格式、报文内容、报文传输的验证;更深入地关注接口数据包各个栏位的取值及组包规则,可以不依赖于外围系统调用的交易执行,便实现接口测试的全栏位覆盖。接口测试的分析及实施步骤如下。

选择工具:对接口栏位全覆盖、全组合的测试,意味着测试工作量大增,使用自动化测试工具成为必然选择,本项目选用了软件中心自行研发的自动化测试工具。

定义接口:按照接口定义在接口测试工具中定义交易的输入、输出包体。按照不同的调用渠道、调用方式分别定义输入、输出包头及错误返回报文模板。

准备数据:根据接口输入、输出报文规范定义,对测试数据需求进行逐级分析。首先,根据输入、输出报文共性数据,确立输入数据要求,如客户、账户(分存款、贷款)、卡等常用类型,确定第一层数据需求。其次,根据输出栏位要求,将输入数据类型具体拆分,如账户状态、客户证件类型、客户等级、卡状态、卡产品、卡组织等,细化第二层数据需求。最后,将输出栏位中的单一选项、非交易重点关注的栏位,作为数据第三层需求。测试实施时,对第一层、第二层测试数据进行全覆盖,同时将第三层数据进行交叉组合,完成正常测试案例的数据准备。通过梳理交易代码,查找出所有的报错信息,并将报错信息归类,按不同报错场景要求,进行异常测试数据准备。

双路接口测试:使用同一套测试数据,通过自动化测试工具,分别链接主机平台及X86平台核心银行系统,发起交易调用,将交易返回结果分别保存。

批量比对:使用自行研发的批量比对工具,对相同交易、相同数据的主机、X86返回结果进行批量比对,验证重塑的业务功能是否与原功能完全一致。对于返回结果不一致的场景进行逐一分析,确认程序实现逻辑是否正确。

在基于灰盒分析的接口测试基础上,再辅以基于黑盒分析的103个外围产品端到端的主要业务场景测试,形成了我们采用的测试分析方法,全面验证了业务功能的重塑。

02

业务数据处置。

由于本项目只是将部分查询交易迁移至X86平台,因此在业务数据处置上采用了由主机平台DB2数据库与X86平台Oracle数据库实时同步的方式。具体投产时,先进行数据铺底,再通过数据实时刷新,实现数据同步。

传统的黑盒分析方法并不关心数据铺底及数据刷新的过程细节,而只是基于业务场景提前进行数据预埋,使用预埋的数据进行交易,验证业务处理的连续性。这种分析方法对测试经验有较高要求,不同测试人员对于业务场景有不同的测试理解,数据预埋可能存在很大差异,以至于可能造成测试质量的极大不稳定性。本项目涉及数据表较多,其中参数表难以通过业务场景进行全量验证;数据表物理存储涉及的分库、分区场景也无法通过黑盒分析方法加以覆盖。

因此,我们在传统黑盒分析方法基础上结合灰盒分析方法,从数据库建表、数据装载、数据存储、数据同步角度,验证数据铺底功能,并通过执行查询交易验证数据处置正确。业务数据处置的测试重点如下。

验证数据库建表:按照数据铺底需要,进行数据库建表,验证数据表各栏位、索引、键值等定义正确。

验证铺底数据信息与数据源信息一致:在完成主机端全量数据采集后,统计采集到的数据文本中的数据量,并与主机端数据库表中数据量进行比对,保证数据源的正确。将数据文本根据分库分区规则导入X86新建数据库后,统计装载数据量,确保其与数据文本中的数据量一致。在保证数据量正确的同时,对X86每个新建数据库表记录进行抽查,保证装载内容的正确性。

验证铺底数据的转换规则:在数据铺底过程,某些数据表栏位存在数据转换,测试过程中需要重点关注此类栏位,根据数据转换规则,验证栏位转换的正确性。

验证铺底数据的分库分区规则:对于涉及分库的表,使用边界值覆盖法,通过统计工具,验证分库分区规则正确性。对于单独库的,验证其他库不存在数据。

验证数据同步机制:X86平台数据需与主机平台同步,通过增、删、改主机端数据,验证X86平台数据库可同步更新,并能正常被调用,执行交易成功。尤其关注涉及转换数据的同步。验证主机端夜间批量操作的数据可及时同步至X86平台。

通过灰盒分析方法,可以解决103个外围产品测试人员分析水平不一致带来的预埋数据不充分问题,也可以解决难以通过业务场景覆盖的数据库逻辑储存验证问题,提高了对数据铺底及实时同步的验证效率。

小结

目前,我行主机下移项目已完成第一期测试工作,并顺利投产。系统运行稳定,达成了我们的测试目标。

中国银行主机下移项目的测试工作,始终抓住应用系统迁移过程中的业务功能重塑与业务数据处置两个关键点,充分结合灰盒测试方法,形成了普遍适用于银行IT架构转型类项目的测试方法。

对于涉及上百个系统的大型银行系统IT转型类项目,测试工作必须创新方法,不能迷失于复杂的系统调用关系,需要梳理出最重要的产品、分析出最关键的点、抓住最核心的矛盾,采取最有针对性的办法。套用“降维”的概念,测试工作重在抓住主要矛盾,化繁为简。此次测试实践,主要围绕新建X86核心银行系统的业务逻辑重塑及业务数据处置,“毕其功于一役”,简化了103个外围产品的测试复杂度,提升了测试的整体质量与效率。对于IT架构转型中传统应用系统迁移的类似项目,灰盒测试分析方法与“降维”的工作思路也具有普遍的适用性。

《金融电子化》新媒体部:主任 / 邝源 编辑 / 潘婧

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180831B0MUU400?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券