銀行業(yè)務(wù)處理的回歸測試工具的設(shè)計與開發(fā)

摘要：本文介紹的回歸測試工具是以某銀行業(yè)務(wù)處理的需求為基礎(chǔ)，提出對應(yīng)的設(shè)計方案，采用基于Struts2架構(gòu)實現(xiàn)的分層設(shè)計MVC模式，實現(xiàn)了視圖、控制和模型的分離，提高了設(shè)計的規(guī)范性，實現(xiàn)了各層之間的松耦合性?；贘avaEE的實現(xiàn)，通過集成客戶端和服務(wù)端，實現(xiàn)案例導(dǎo)入管理、協(xié)議管理、執(zhí)行管理和結(jié)果分析等一套回歸測試流程的自動化，測試結(jié)果表明，該系統(tǒng)達(dá)到了設(shè)計要求，可滿足實際需求。

Abstract： In this paper， the regression test tool is based on the needs of the business processing of a bank. The corresponding design scheme is put forward. The hierarchical design MVC pattern based on the struts 2 architecture realized the separation of view， control and mode. The standardization of design is improved， and the loose coupling between each layer is realized. Based on the implementation of JavaEE， the automation of a set of regression test processes， such as case import management， protocol management， execution management and result analysis， is implemented through integration of client and server. The test results show that the system meets the design requirements and meets the actual requirements.

關(guān)鍵詞：企業(yè)服務(wù)總線；回歸測試；案例庫

Key words： ESB；regression testing；banking system

中圖分類號：TP311.5 文獻(xiàn)標(biāo)識碼：A 文章編號：1006-4311（2017）35-0140-03

0 引言

隨著金融業(yè)和線上消費的不斷發(fā)展，各行各業(yè)對銀行的依賴日漸顯著，隨著客戶的需求變化以及各種各樣的金融衍生產(chǎn)品的問世，不可避免的要對己有的接口功能進(jìn)行改動。但是由于銀行系統(tǒng)本身的嚴(yán)謹(jǐn)性，每次針對系統(tǒng)的改動都面臨著較大風(fēng)險，多數(shù)銀行時常會發(fā)生二次缺陷，需要經(jīng)過緊急版本修補，因此對每次上線的版本進(jìn)行全量的回歸測試成為了銀行運維中的重中之重，然而，目前回歸測試采用的人工測試的方式，卻費時費力成本高，沒辦法進(jìn)行大規(guī)模重復(fù)測試，測試結(jié)果也不準(zhǔn)確，也無法通過大批量的比較數(shù)據(jù)結(jié)果來發(fā)現(xiàn)存在的問題，測試過程無法復(fù)用，同時對版本的質(zhì)量也不能有一個良好的控制，所以有必要設(shè)計一款自動化回歸測試的工具。

1 相關(guān)開發(fā)技術(shù)

ESB是企業(yè)服務(wù)總線，是一種實現(xiàn)面向服務(wù)架構(gòu)模式（SOA）的一種技術(shù)，是為了解決企業(yè)之間多個服務(wù)或者功能散落在各個不同的系統(tǒng)中的一個工具集。它通過整合不同的系統(tǒng)之間的接口和服務(wù)，形成企業(yè)一個完整的業(yè)務(wù)處理流程的服務(wù)，如圖1所示。

MVC是一種架構(gòu)設(shè)計模式，該模式主要應(yīng)用于圖形化用戶界面（GUI）應(yīng)用程序。在進(jìn)行架構(gòu)設(shè)計的時候，將用戶界面層和邏輯層以及數(shù)據(jù)層分開，是一種用于軟件表現(xiàn)層架構(gòu)的模式。

Struts2是一個基于MVC設(shè)計模式的Web應(yīng)用框架，它本質(zhì)上相當(dāng)于一個Servlet，在MVC設(shè)計模式中，Struts2作為控制器來建立模型與視圖的數(shù)據(jù)交互，以WebWork為核心，采用攔截器的機制來處理用戶的請求，這樣的設(shè)計也使得業(yè)務(wù)邏輯控制器能夠與ServletAPI完全脫離開，如圖2所示。

本系統(tǒng)的數(shù)據(jù)庫設(shè)計采用數(shù)據(jù)庫模型設(shè)計工具 Sybase PowerDesigner來進(jìn)行。

2 需求分析

本文的回歸測試的自動化測試工具，主要分為客戶端、服務(wù)端和案例基線庫。服務(wù)端用來監(jiān)聽接收到的數(shù)據(jù)，并返回對應(yīng)的數(shù)據(jù)。案例基線庫是將所有的案例歸集為一個集合，存放至數(shù)據(jù)庫中?？蛻舳酥饕脕砟M消費方，將案例轉(zhuǎn)化為請求報文，并發(fā)送至企業(yè)服務(wù)總線。客戶端支持對案例的批量導(dǎo)入，支持對案例的修改，支持對案例執(zhí)行結(jié)果的查看和導(dǎo)出，主要分為案例管理，執(zhí)行管理，結(jié)果管理和協(xié)議管理，系統(tǒng)的功能結(jié)構(gòu)模圖如圖3所示。

案例管理：是本系統(tǒng)的基礎(chǔ)模塊，包括案例的導(dǎo)入、修改、查詢等功能，需要將單條案例的詳細(xì)信息體現(xiàn)在頁面上，支持批量的案例導(dǎo)入，將批量的案例打包成.zip包后，點擊導(dǎo)入，系統(tǒng)即完成插庫的操作，支持對單條案例的請求和返回報文的在線編輯保存。

執(zhí)行管理：是本系統(tǒng)的核心模塊，提供對案例的批量執(zhí)行。輸入案例對應(yīng)的用戶名和相關(guān)的批次號，點擊執(zhí)行按鈕，由系統(tǒng)自動完成對案例的執(zhí)行，對比和分析，包括案例的ID，執(zhí)行人，協(xié)議類型等信息，并將最后的執(zhí)行結(jié)果進(jìn)行計算，包括執(zhí)行的案例數(shù)、執(zhí)行的成功數(shù)、成功率等，最終顯示于頁面。

結(jié)果管理：是本系統(tǒng)的結(jié)果查詢模塊，提供對單批次案例的詳細(xì)執(zhí)行結(jié)果。以批次為粒度的，每個批次的案例，可以查詢到對應(yīng)的測試用戶、開始時間、結(jié)束時間、案例數(shù)、執(zhí)行數(shù)、成功數(shù)、失敗數(shù)、成功率和備注。支持導(dǎo)出操作，所有的測試結(jié)果均可以以Excel的格式導(dǎo)出，Excel主要顯示測試結(jié)果的概況、結(jié)果詳情以及未覆蓋的測試案例。endprint

協(xié)議管理：本模塊主要提供對所有案例所需協(xié)議信息的管理功能。支持對協(xié)議類型和協(xié)議地址的在線修改，修改后點擊保存，下次執(zhí)行案例即可生效。

3 系統(tǒng)分析與功能模塊設(shè)計

自動化回歸測試工具系統(tǒng)是一個分模塊、以案例基線庫為中心，客戶端和服務(wù)端集成一體，相輔相成的架構(gòu)。該系統(tǒng)的各個模塊與銀行的業(yè)務(wù)系統(tǒng)，企業(yè)服務(wù)總線共同組成整個自動化測試環(huán)境。

3.1 案例管理模塊

案例管理模塊的核心功能是案例的解析導(dǎo)入，因為某銀行的測試案例都是以Excel的形式保存的，所以采用POI對案例進(jìn)行解析。采用FileUpload提供的API接口對案例文件進(jìn)行操作，實現(xiàn)對文件讀寫處理。當(dāng)File獲取到文件路徑后，進(jìn)行實例化，并調(diào)用ServletFileUpload的parseRequest方法，解析文件為一個List數(shù)組，然后采用Iterator迭代器進(jìn)行循環(huán)寫文件。

采用POI解析Excel時，首先根據(jù)傳入的文件路徑，實例化一個File對象的輸入流，然后讀取文件，創(chuàng)建一個Excel工作表，根據(jù)getSheetAt獲取到表格，最后調(diào)用getRow和getCell方法獲取對應(yīng)的某行某列的信息。

3.2 協(xié)議管理模塊

協(xié)議管理實現(xiàn)了對協(xié)議的修改，頁面修改協(xié)議后，數(shù)據(jù)庫做同步修改。連接數(shù)據(jù)庫，取得表單中的id、type和address參數(shù)，更新協(xié)議信息表。

3.3 執(zhí)行管理模塊

案例執(zhí)行模塊實現(xiàn)了對客戶端和服務(wù)端的模擬。當(dāng)實例化Socket客戶端成功后，即可以通過實例化的端口進(jìn)行通訊，本系統(tǒng)的數(shù)據(jù)通訊內(nèi)容為報文，需要從數(shù)據(jù)庫取得報文后，才能進(jìn)行相關(guān)的操作。采用TCP協(xié)議來實現(xiàn)，需要有一個發(fā)送方法和接收方法，發(fā)送方法負(fù)責(zé)從數(shù)據(jù)庫取得案例報文，進(jìn)行發(fā)送，接收方法負(fù)責(zé)接收響應(yīng)信息。

3.4 結(jié)果分析模塊

結(jié)果分析模塊主要用來對比分析案例執(zhí)行結(jié)果，分析預(yù)期的報文和實際收到的報文的區(qū)別，本系統(tǒng)將收到的報文全部存放于數(shù)據(jù)庫，進(jìn)行對比時，從數(shù)據(jù)庫取得預(yù)期報文和實際報文，將報文轉(zhuǎn)為字節(jié)數(shù)組，循環(huán)對比每一個字節(jié)數(shù)組的值是否相同。

4 系統(tǒng)測試

系統(tǒng)測試是軟件項目開發(fā)的必要步驟，它能有效檢測出軟件中存在的錯誤，并能夠及時的進(jìn)行更正，使我們所開發(fā)的項目產(chǎn)品質(zhì)量更高。

4.1 功能測試

功能測試又稱為黑盒測試，能更好的從用戶的角度來考查被測試系統(tǒng)的功能性需求。

4.1.1 案例模塊測試

以一個批次案例模塊為例，進(jìn)行完整的導(dǎo)入、查詢和修改功能測試。單擊“選擇文件”按鈕，選中要導(dǎo)入的文件，單擊“導(dǎo)入”按鈕，結(jié)果如圖4所示，導(dǎo)入完成后，頁面彈出導(dǎo)入結(jié)果，顯示導(dǎo)入成功。導(dǎo)入成功后，輸入導(dǎo)入的某條記錄的服務(wù)碼，進(jìn)行查詢，可以查詢到對應(yīng)的數(shù)據(jù)。選中某條案例，單擊請求報文，進(jìn)入案例修改頁面，如圖5所示，修改報文內(nèi)容后，單擊“保存”按鈕。從數(shù)據(jù)庫去查看報文內(nèi)容是否已經(jīng)修改成功，結(jié)果顯示修改成功，則說明案例管理模塊的所有功能模塊均能正常操作。

4.1.2 協(xié)議管理模塊測試

協(xié)議管理測試修改后，驗證數(shù)據(jù)庫是否同步修改，頁面是否同步刷新協(xié)議信息。在協(xié)議頁面上直接修改“協(xié)議”，如圖6所示，完成后單擊“保存”按鈕，彈出“修改成功提示框”。然后去數(shù)據(jù)庫查看協(xié)議信息，協(xié)議已經(jīng)被修改“成功”，表明協(xié)議管理模塊能正常操作。

4.2 工具測試

結(jié)構(gòu)測試又稱為白盒測試，需要深入考查系統(tǒng)程序代碼的內(nèi)部結(jié)構(gòu)和邏輯設(shè)計等。JMeter是基于javaTM Swing的桌面應(yīng)用程序，是為了進(jìn)行負(fù)載測試、測試系統(tǒng)性能而設(shè)計的。本系統(tǒng)利用JMeter工具對各個模塊進(jìn)行環(huán)境測試、錄制測試腳本進(jìn)行性能測試，結(jié)果表明，案例報文數(shù)在300以內(nèi)的訪問響應(yīng)速度很快；在300-500以內(nèi)的訪問響應(yīng)速度是3秒以內(nèi)，還是比較理想的。

5 結(jié)論

本文的回歸測試工具在某銀行業(yè)務(wù)處理系統(tǒng)的回歸測試中達(dá)到了銀行業(yè)提高測試效率和節(jié)約測試成本的要求，具有實際意義，并證實了本系統(tǒng)的設(shè)計方案是可行的。

參考文獻(xiàn)：

[1]詹金珍.高校學(xué)生水電收費管理系統(tǒng)的設(shè)計與開發(fā)[J].價值工程，2014，355（33）：711-716.

[2]詹金珍.基于公平性的D2D時隙調(diào)度算法[J].計算機應(yīng)用，2017，37（3）：225-227.

[3]Liang Zhihong；Lu Jun； Design on Information management System of Gas Station， ICICTA，2012， pp.139-142.endprint