基于信用卡业务测试数据支持解决方案

行业背景

　　1. 信用卡业务持续稳健发展

　　根据央行发布的《2018年第一季度支付体系运行总体情况》银行卡信贷规模持续扩大，信用卡和借贷合一卡在用发卡数量共计6.12亿张，环比增长4.23%。全国人均持有信用卡0.44张。相较于美国人均持卡量2.9张，我国信用卡业务尚未饱和，虽然增长速率有所缓和，但是仍然在可预见的未来处于持续上升发展阶段。

　　2. 信用卡业务快速发展与质量稳定需平衡

　　近年各家银行纷纷加大信用卡业务营销投入及角逐高速增长的市场份额。随之而来的各银行对于信用卡业务信息科技投入及研发的同步高速增长，以适应信用卡业务的快速发展并顺应激烈的市场竞争。由于信用卡业务的业务特点及背景，导致了其系统建设/维护过程中存在“迭代周期短、系统变化频繁、与市场活动快速衔接、7*24H运维、受政策及风控影响大”等特点。对于围绕信用卡业务的系统建设过程中（特别是持续集成及快速迭代模式下）测试及质量保障工作变得尤为重要。

　　3. 数据支持能力较弱

　　为平衡高速迭代及基于大数据量下的回归及多流程分支测试，目前多数信用卡业务信息建设的配套测试工作涉及的测试数据准备，存在依靠业务人员提供测试数据或者随意捞取测试数据等方式。由于其随意性且无规划性，无法满足测试过程中对于数据独占性的要求，极易导致测试数据的互相干扰。且多数据情况下是根据已有测试数据进行测试工作，而非测试需求去准备数据，测试的针对性较弱，数据的先天局限性导致了测试覆盖率的不全面。这些都是阻碍信用卡业务系统质量提高的明显“短板”。

图1-1 数据准备现状

开展测试支持工作

　　1. 统筹开展测试数据支持工作

　　应对如上问题，结合“客户对于差异化服务及系统质量愈加敏感、互联网冲击以及信用卡业务持续稳健发展”等市场背景，急需通过组织级高度统筹开展相关测试支持工作的规划、组织及落地。打破相关技术实施部门（或主体）内部沟通及信息壁垒，把此项工作上升到全局层面考虑。

　　2. 组建测试支持小组

　　人员构成方面，测试支持小组成员应分布于各主要系统或系统群，熟悉各自负责领域，以便后续进行数据支持的“承上启下”工作。团队组建并形成一个广泛的、具有代表性的测试支持小组去牵头实施相关测试支持工作。测试支持成员根据分工及职责划分，可以安排自身的部分或者全部工作量去参与测试支持工作。（一般不建议全职参与，需同时兼顾本人负责领域的系统测试工作，从而能及时获悉及了解相关系统，更好的服务于测试支持工作）建议参与的时间占本人的总工作时间的20%~50%。

　　其要职责有：1.相关测试阶段数据的统一受理及支持工作；2.展开围绕信用卡为中心的核心系统数据准备（制卡、养卡等）。3.各系统相关协同测试支持事宜。4.牵头突破测试支持难点，并进行知识分享及推广。5.培养一批数据支撑骨干，牵头后续相关工作及推进。6.提供部分稀有数据的整合及共享机制，减少数据的浪费，提高数据的使用率。7.根据合规要求，建立及宣导测试数据准备准入规范，并按此规范进行测试支持小组范围内的数据支持工作。

提供解决方案

　　围绕信用卡业务特点，基于实际测试支持工作经验，总结如下几个维度测试数据支持解决方案。

　　1.围绕基础数据“制卡”为中心的测试支持

　　信用卡系统测试工作中，制卡（信用卡）是数据准备的基础及重点工作。信用卡业务基础制卡数据模型（如图3-1），以信用卡核心制卡为基础。

　　（1）建立围绕“客户层>账户层>卡片层”的信用卡客户基础账户树，并交叉建立“单账户单卡、单账户多卡、多帐户多卡、主附属卡”等制卡分类场景。根据风控及流程控制要求对于各层的管制码及风险征信进行维护。

　　（2）将制卡中涉及到的重要业务字段作为数据准备分支，包含（但不限于）重要业务逻辑字段分类包含“获客及审批、 客户信息、身份信息、卡产品、卡类别、核准额度”等维度。

图3-1 信用卡基础制卡数据模型

　　建立基础制卡数据准备模型，通过围绕“三层关系账户树”、“各层管制码及风险征信”、“重要制卡参数字段”进行基础“制卡”数据准备工作，结合实际业务需要，减少对于核心业务理解不全面导致的测试场景遗漏。

　　2. 建立分散账单日应对时效性数据准备

　　信用卡业务涉及较多“分期类业务”测试，此类测试的数据准备一般涉及： 客户基础数据、核心分期参数、消费欠款、账单日。基于如上4点，最困难且相对不可控的无疑是“账单日”相关数据准备。由于受限于测试环境共用，跑批无法单独服务于某几个特定系统。跑批时间不可预估，往往很难满足对于测试数据较高时效性要求的测试项目。

　　首先我们了解下一些基本的账单周期概念如下图（具体日期为举例，反映一个相对区间）：

图3-2 通用账单周期

　　名称解释如下表：

　　根据不同银行的测试环境跑批周期特点，建立账单日分散的养卡数据准备。比如某行测试环境平均一天跑批10个会计日期，3天内跑完一个会计周期月。则提前制卡，将账单日平均分布在“1、5、10、15、20、25、28”等日期上。则通过查看核心最近一次跑批周期，快速挑选最接近的卡片进行欠款操作，保证最快时间内造出账单分期等涉及跑批时效性类的数据准备。

　　3.稀有或较难再生数据的循环及共享使用

　　稀有测试数据包含（但不限于）如下：

　　（1）需要较长周期沉淀的数据： 如“特定发卡日期的卡片、卡片过期自动续卡、积分兑换年费、特定历史周期有账单”等。

　　（2）不可逆或者较难准备的测试数据：如“卡片激活、批量类数据准备、长流程节点数据准备”等。

　　（3）依赖于第三方：如“邮寄进度、公安身份识别及其他第三方数据平台”等。

　　此类数据需要建立统一登记簿，收集各系统相关共性测试数据需求，统筹规划进行数据集中准备。按测试流程及优先级，逐一分发或共享给各系统，使得测试数据形成有序状态流转。并尝试打通各上下游系统，尽可能的使得数据能循环利用。

　　4. 借记卡相关测试数据支持

　　信用卡业务涉及到的小额现金贷款/现金取现类业务，需要考虑转入本行及他行借记卡测试场景。此类测试的关键数据准备在于信用卡核心与借记卡核心的客户信息关联，取决于不同银行的系统差异。一般有“按证件类型/号码、核心客户号及其他唯一标识”等方式关联。

　　关联下的本行借记卡，需要考虑监管要求，对于开立过“证券、理财“等投资类业务的借记卡，一般需要准备此类场景进行反例测试。

　　同时考虑借记卡的类别如“一类、二类……”、状态“正常、待激活……”、介质类型“卡、存折、存单……”等测试数据场景。

　　他行借记卡测试重点为历史转入他行借记卡信息的显示及辅助选择，他行借记卡信息一般不存储在信用卡核心，需要找到对应系统本地进行数据插入及维护。

　　5. 数据隔离下的挡板使用

　　在测试环境由于一些系统的独立性，且为了减少模拟此类数据真实链路的复杂度，往往会将这些系统及数据进行分散处理。特别涉及到“数据模型较复杂且需要历史数据加载策略的大数据”及“直连第三方外部的数据平台”等系统。

　　此类数据一般使用其自身的数据库或缓存插入数据的方式进行挡板数据准备。插入数据前需要仔细梳理此类数据与其他系统的关系，需要同步协调相关数据（保持数据源的一致性），并按流程进行“数据上送配对返回”的场景设计工作。

　　如果涉及到一定的报文格式规范，则需要在规范化的报文协议场景下进行数据调试工作，同时查看数据的业务规则及格式规范的正确性。

　　6. 互联网渠道数据准备

　　信用卡业务较多的在互联网渠道进行展示及渠道整合，互联网渠道包含“微信、QQ、支付宝及自主APP”等渠道及平台。

　　此类数据准备一般需要加入特定的测试网段进行“手机唯一标识+基础客户信息”绑定。如果涉及到验证码，一般是通过测试环境写死或者查看日志的方式填写，绕开相关认证。涉及到的人脸识别，一般是在对应挡板下进行人脸信息值的预埋，并生成BASE64编码。

　　互联网渠道数据准备同时需要考虑不同操作系统下的版本兼容，区分如安卓、IOS不同测试地址或下载版本。

总结

　　因地制宜地建立配套的信用卡业务测试支持体系，将有效解决由于测试数据不足导致的测试覆盖不全面问题。逐步实现各系统测试数据流上下游的良性循环及配套知识分享体系，改善信用卡业务测试资源紧张现状、打破各系统间信息闭锁（不对称）、消除由于测试支持缺乏导致重点业务测试风险，形成一套可复制推广的适用信用卡业务的统一测试支持与管理流程。

　　测试数据支持长期规划，将围绕“事前、事中、事后”建立流程化系统及平台，逐步实现“自动化UI、批量文件、联机接口”等方式进行数据准备，提升数据准备的质量及效能。最终实现“测试支持与协同、数据全生命周期流转、测试支持知识分享、数据合规控制、数据预埋与外挂”等测试支持工作的电子化与系统化。

（文章来源：金融电子化杂志）

扫码即可手机
阅读转发此文