社区分享｜杭银消费金融基于MeterSphere开展接口自动化测试

本文主要是介绍社区分享｜杭银消费金融基于MeterSphere开展接口自动化测试，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

杭银消费金融有限公司（以下简称“杭银消费金融”）成立于2015年12月，是经中国银保监会批准，由杭州银行作为主发起人，联合滴滴出行、中国银泰等企业组建的持牌消费金融机构，注册资本为25.61亿元。杭银消费金融秉承“数字普惠金融”的初心，坚持服务传统金融覆盖不充分的、具有消费信贷需求的客户群体，以“数据、场景、风控、技术”为核心，探索消费金融新模式，为全国消费者提供专业、高效、便捷、可信赖的金融服务。

一、系统架构与交互现状

杭银消费金融经历了长期的高速发展，随着科技自研能力的不断提升和系统架构的不断升级，目前拥有上百个内部系统，这些系统之间存在复杂的调用关系，形成了庞大而错综复杂的业务链路（如图1所示）。同时，公司的金融系统与多个引流渠道和三方机构进行外部对接，进一步增加了系统的复杂性。
在这里插入图片描述

▲图1 杭银消费金融系统交互架构

在业务的高速发展期，由于内部系统相对复杂，杭银消费金融在软件高质量交付方面面临着一系列的难点和挑战，具体包括：

1.需求快速迭代，大规模回归测试成为常态

杭银消费金融的用户端种类非常多，用户入口多种多样，包括杭银消费App、消邦App、H5、小程序、公众号等。在持续交付的开发模式下，功能迭代频繁，由于所有入口的底层服务高度耦合，导致每接入一个新产品都可能会影响到其他已有产品，需求上线前面临大量的回归测试工作；

2.金融业务复杂度高，不同产品业务流程千差万别

由于当前各条业务线的业务模式和系统实现差异性很大，存在业务壁垒，各领域采用自动化测试资产离线管理的方式，之前存在测试脚本和数据存储零散、维护困难、跨系统用例冗余等问题；

3.缺乏全链路自动化测试工具

缺乏打通全域的链路级用例，跨系统数据校验不完整，进行全链路回归测试耗时耗力；

4.依赖外部的第三方机构，上下游测试存在数据依赖和环境依赖

测试阶段，在三方环境不通的情况下，需要Mock渠道、银行、外部数据等交互数据。

二、自动化测试发展路径

杭银消费金融的自动化测试进程大致可以拆分为四个阶段：

■ 第一阶段为系统建设期：各系统分别做自动化，虽然已经沉淀了很多提效工具，但是缺乏统一的规则，共享协同性差，难以沉淀；

■ 第二阶段为业务扩展期：建设统一的自动化测试平台，完成各系统自动化用例的统一管理和度量；

■ 第三阶段为流程完善期：自动化测试件在DevOps流程中全面落地，建设了完善的发布质量防护网；

■ 第四阶段为维护和探索期：在自动化基建全面落地之后，还需要不断与时俱进，探索提升交付质量和研发质量的前沿方法，并在公司内部落地。

目前，杭银消费金融的自动化测试进程正在从脚本化向平台化整合的过渡阶段。虽然脚本化的自动化测试往往更能体现出测试人员的代码编写能力和个人测试水平，然而脚本化的自动化测试存在着一些弊端：

1.工程化成本高，对测试人员的要求较高。工程的环境搭建、本地脚本编写以及调试这几环节都具有非常高的时间和人力成本；

2.非平台化自动化测试场景单一。由于测试环境和测试数据与脚本直接关联，而测试人员的编码水平参差不齐，编写的自动化测试脚本在测试环境及测试数据方面，很可能出现数据场景单一、覆盖范围有限等较大弊端；

3.自动化测试的测试经验无法及时沉淀。测试脚本里沉淀的能力也难以快速复用，一旦出现人员的流动变化，将直接导致测试工作的停滞不前，甚至中断；

4.缺乏统一指标度量各个系统自动化用例的完整性、稳定性和有效性。

三、自动化测试平台建设进程

1.自动化测试平台总体架构

围绕杭银消费金融的快速发展战略，以及“需求交付短平快”的原则，在技术资源有限的前提下，杭银消费金融的测试团队希望借鉴业界自动化测试统一平台化的成功经验，对其各系统的测试资产进行治理，采用自动化测试件统一管理和跨系统场景链路编排的方式，实现测试资产管理统一化、度量标准化，最终达成需求交付降本、提效和增收的目标。

经历了一年多不断的探索和尝试，杭银消费金融团队最终确定了其统一自动化测试平台的整体架构，并且在营销业务领域建立了创新试点，取得了非常不错的效果。

杭银消费金融统一自动化测试平台的整体架构图如图2所示。该平台通过构建自动化通用能力的方式来提升测试效率和项目交付质量，包括数据生成能力、用例自动化能力、质量流水线能力等。

其中，数据生成能力包括业务数据和通用数据生成，线上流量采集和脱敏；用例自动化能力包括接口自动化、场景自动化、UI自动化和自动化用例统一管理和度量、用例定时执行、报告自动生成等；质量流水线能力包括在DevOps流程中实现质量门禁，发布通过率度量、自动化持续集成等。
在这里插入图片描述

▲图2 杭银消费金融自动化测试平台总体架构

2.自动化测试平台建设进程

为了将业务快速接入统一自动化测试平台，测试团队花费了半年时间调研、分析和对比了几个主流的自动化测试平台和公司内部的自研平台。考虑到工具的易用性、存量数据的兼容性、功能可扩展性和后期的维护成本，杭银消费金融的测试团队最终选择了MeterSphere开源持续测试平台作为统一的自动化测试基础设施。MeterSphere开源持续测试平台的系统架构如图3所示。
在这里插入图片描述

▲图3 MeterSphere开源持续测试平台系统架构

MeterSphere平台提供的接口测试功能很好地契合了杭银消费金融自动化测试的需求。这一开源持续测试平台的主要优点如下：

① 用例编写可视化，降低测试门槛

MeterSphere开源持续测试平台用例编写可视化，易用性强，测试人员上手容易，有利于聚焦业务；

② 支持多种格式的接口集导入和定时同步

MeterSphere可以兼容多种协议，支持多种协议类型的API管理，包括HTTP、TCP、RPC等。适合对杭银消费金融的各域接口进行统一管理。MeterSphere还支持Postman、Swagger、JMeter等多种格式的接口用例集导入和定时同步，还可以通过插件打通IDEA与测试平台进行接口同步；

③ MeterSphere采用主流技术栈，方便二次开发

MeterSphere平台使用Java语言开发，采用前后端分离的架构，使用Spring Boot（后端）、Vue.js（前端）等常见的技术栈，与测试团队人员的技术栈相匹配，方便开展二次开发。MeterSphere在接口自动化和性能测试方面与JMeter保持一致，并在一定程度上对其进行了二次封装，使得测试操作更加简单、方便；

④ MeterSphere拥有丰富的插件体系，扩展性强

目前，MeterSphere开源社区对外提供各种各样的插件，比如支持发布流水线接入的Jenkins插件、支持工程中接口同步的IDEA插件、支持UI测试的Selenium插件等，甚至还支持用户开发各种自定义插件。

3.自动化测试落地DevOps

在整个项目研发流程中，杭银消费金融的测试团队希望在开发编码阶段，测试人员同时编写好接口测试用例，交由开发人员完成测试准入，通过后由测试人员进行最终的验收。而不是由测试人员去反复执行用例后再将结果通知到开发人员（如图4所示）。
在这里插入图片描述

▲图4 研发协作最佳模式

这看似简单的环节，之前由于没有统一平台的支持，只依靠Postman、Jenkins等工具维护用例脚本，在开发和测试之间想实现无缝对接是非常困难的。MeterSphere平台可以很好地解决这个问题，它将各域的接口管理、自动化用例管理集中在同一个平台进行管理，助力研发协作模式从串行到并行的升级，实现测试左移，最终提升研发效率。

此外，为了在提效、回归时减少手工的测试执行，最终必然会将场景自动化加到整个DevOps流水线中。MeterSphere的Jenkins插件可以方便地将自动化用例集作为一个质量门禁，添加到现有的发布流水线中，通过持续构建和持续测试的方式来保障业务的稳定性。
在这里插入图片描述

▲图5 杭银消费金融质量发布流水线

四、自动化测试实践与成果

1.接口自动化现阶段成果

杭银消费金融的测试团队通过MeterSphere的接口自动化功能，实现了对包括授信、支用、还款等在内的核心业务系统内业务监控的100%覆盖。目前，杭银消费金融已经在MeterSphere平台上通过树状分级分组管理的方式沉淀了1000多条单接口用例，大约100个多个场景用例，覆盖15个核心系统，涉及6个核心业务。
在这里插入图片描述

▲图6 杭银消费金融自动化用例大屏

2.营销域自动化测试最佳实践

测试团队选择营销域作为MeterSphere在杭银消费金融的自动化样板间有以下几点原因：

① 营销领域需求短平快

从2020年开始，在公司快速发展战略的指引下，营销领域需求短平快，在技术资源有限的前提下，亟需提升研发效率；

② 营销领域的需求回归测试覆盖范围广

营销系统覆盖杭银消费金融所有的业务场景，包括自营、渠道联营等。公司科技部的业务系统则相互独立，但底层共用一套信贷系统，每块业务的变更都可能会影响到信贷的主流程。由于当前自营、渠道联营的业务模式和系统实现差异较大，存在业务壁垒，回归测试资源协调难度比较大；

③ 营销系统的变更“牵一发而动全身”

营销活动贯穿整个信贷流程，包括支用、还款等，每次上线新功能都需要对支用和还款主流程进行回归测试；

④ 营销玩法多样，活动配置种类非常多，场景覆盖困难

营销优惠和参与条件是业务设计营销玩法的核心。设置端需对条件和优惠充分开放定制，对活动的配置项做笛卡尔积会产生大量场景，人工覆盖验证不现实。
在这里插入图片描述

▲图7 杭银消费金融营销域业务架构

针对营销领域的业务形态，杭银消费金融的测试团队采用数据驱动的方式，通过构造批量场景数据来进行用例膨胀，最终实现覆盖所有营销场景的主流程自动化回归。

2.1 营销管理端：采用数据驱动的方式实现活动配置自动化

虽然营销管理端活动创建的流程很长，场景种类多，但是流程是相对固定的，可以通过数据驱动的方式批量生成场景用例，通过自动化的方式实现活动配置和更新（如图8所示）。
在这里插入图片描述

▲图8 MeterSphere数据驱动方式

以下是杭银消费金融在MeterSphere平台创建数据驱动的场景用例的具体步骤。

第一步：构造场景数据

定义场景用例所需的参数和预期结果，将数据保存在CSV文件中，每行代表一个场景用例。
在这里插入图片描述

▲图9 MeterSphere场景用例数据文件

第二步：场景用例编排

使用条件控制器进行场景用例编排，可以一键执行场景文件中的所有用例并与文件中的断言进行比对，不同的条件路由到不同的场景用例。
在这里插入图片描述

▲图10 MeterSphere场景用例数据文件
在这里插入图片描述

▲图11 活动管理端创建链路

2.2 用户端：采用链路编排的方式实现用户端的用券链路回归

针对用户端的优惠使用链路，目前对于同类别的活动信贷系统与营销系统使用同一套流程，可以对信贷流程（支用、还款）进行链路编排，实现用户端的用券链路回归。

以自营业务的支用场景为例，网关层发起借款确认请求之后，下游的系统，比如信贷、资产、营销、支付、账务等会经过一系列调用后，将支用金额和状态以异步返回的方式返回给网关层。在这一过程中，除了接口调用之外还存在系统间的消息传递、数据持久化保存等步骤。所以，对于分布式系统进行一次全链路调用，除了验证业务层接口的返回结果之外，更重要的是验证系统之间的数据一致性、数据的正确性等。

图12展示了支用流程的全链路用例，杭银消费金融的测试团队将营销活动抽象成一个通用的节点，通过条件控制器可以路由到不同的活动链路。一条用例几乎可以覆盖营销用户端的所有场景。
在这里插入图片描述

▲图12 杭银消费金融自营业务支用链路场景用例编排

原本进行一次支用操作需要进行8次接口调用和10次SQL查询，涉及跨系统的接口调用、跨库的数据查询、多分支条件执行和循环等待等操作。比较有经验的测试人员执行一次这样的场景用例大概需要15分钟时间，自动化场景测试一键触发只需要4分钟左右时间（如图13所示），通过一次编排，可以多次复用。并且通过数据驱动的方式，一条编排好的链路可以复用到多个场景中，测试效率实现了指数级提升，大大节省测试的回归成本。
在这里插入图片描述