行業背景

　　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、批量文件、聯機接口”等方式進行數據準備，提升數據準備的質量及效能。最終實現“測試支持與協同、數據全生命周期流轉、測試支持知識分享、數據合規控制、數據預埋與外掛”等測試支持工作的電子化與系統化。

（文章來源：金融電子化雜志）

掃碼即可手機
閱讀轉發此文