- 快捷搜索
- 全站搜索
" />
銀行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架構轉型中傳統應用系統遷移的類似項目,灰盒測試分析方法與“降維”的工作思路也具有普遍的適用性。
(文章來源:金融電子化雜志)
掃碼即可手機
閱讀轉發此文
目前Hadoop/HBase廣泛應用于各類具有大數據需求的企業,尤其是互聯網企業,
工商銀行啟動業務集中處理改革,研發了具有自主知識產權的業務集中處理平臺