- 背景
- 企業服務總線概述
企業服務總線，即ESB全稱爲Eenterprise Service Bus，指的是傳統中間件技術與XML、Web服務等技術結合的產物。隨着金融系統的架構體系日漸複雜、各系統間交互協議或標準不統一、共有服務存在分離及重複開發等情況發生的風險及頻率增高。爲避免此類情況頻發，企業服務總線正在被越來越多的金融系統架構所採納、建設、實施。企業服務總線提供了連接企業內部及跨企業間新的和現有軟件應用程序的功能，由中間件技術實現面向服務的體系結構（service-oriented architecture，SOA），使得構建在各系統中的服務可以以一種統一和通用的方式進行交互。
- 測試視角解析
在構建企業服務總線的過程中，對應的測試工作需要同步提升及跟進。實施企業服務總線之前，基於分離系統下的獨立接口測試方法正逐漸向以企業服務總線爲中心的整體全流程集中測試方法過渡。本文將根據一些實踐經驗，圍繞企業服務總線闡述具體的測試方法、測試經驗、測試場景運用。通過測試的視角去解析企業服務總線的一些具體場景運用。
- 通用測試方法
- 報文通訊測試
通過建立滿足自身企業服務總線特點（協議\標準\規範）的自動化接口測試平臺或者模擬工具，去模擬報文併發送到對應的ESB服務節點或者對外的F5節點。並通過事先建立與上送請求對應的預期結果檢查點，結合通訊及解析等維度，進行整體的報文通訊結構測試。
圖2-1 接口通訊及解析測試場景
拼裝報文後具體測試流程如下：
- 首先確認報文是否發送成功，發送失敗的原因可能有“上送網絡問題、上送報文格式及規範不合法、目標地址錯誤、被目標端基於某種策略的主動拒絕”等原因。
- 報文發送成功後，確認是否收到ESB返回，未收到ESB返回的原因可能有“返回網絡問題、上送與返回回執關係錯誤、單向接口無返回”等原因。
- 收到ESB返回後，確認是否成功解析報文，根據ESB定義的接口協議、規範及標準進行解析。
- 解析成功後，最終確認檢查點是否驗證成功。根據預先定義的配對預期結果檢查點，確認返回報文中對應信息的匹配性。
- 報文結構測試
根據上文“報文通訊測試”中涉及到的解析報文，展開說明“報文結構測試”。報文結構一般測試點包含：
- 上送報文頭、報文體結構是否正確？
- 返回報文頭、報文體結構是否正確？
- 接口字段中是否包含空格？
- 接口字段是否與約定存在差異（多或少）？
- 每個業務級字段是否都包含了返回值？
- 涉及循環結構的測試是否覆蓋？
- 涉及多層結構嵌套的，是否測試到每個層級（及最深層級）？
- 上送及返回報文最大長度測試等。
- 字段值返回測試
通過設置與業務場景所對應的預期結果檢查點，與實際結果比對後進行字段值返回測試。測試點主要包含如：
- 特定定長字符類型，長度不足是否左填0；
- 預期與實際結果是否一致；
- 多個預期值的“並且”與“或”滿足關係；
- 特定金額類型，是否增加小數點，格式化金額；
- 日期時間格式是否一致等。
圖2-2 預期結果與實際結果比對
- 錯誤碼返回測試
企業服務總線一般提供三種類型錯誤碼形式：1、平臺級封裝錯誤碼；2、應用級透傳錯誤碼；3、應用級mapping（映射）錯誤碼。
對於第一種錯誤碼測試，一般爲平臺層面（系統、環境、解析）等觸發場景，如“發送數據異常、接收數據異常、連接異常、連接關閉、拼報錯誤、解析錯誤、調用服務異常、調用服務超時、組件異常、交易超時”等。有些如“組件異常、連接關閉”等需要與技術配合一同修改測試環境部分代碼適配測試。如“交易超時”則可通過設置測試環境特定請求返回較長時間模擬，或者不做返回處理。本類測試暫不涉及業務層面測試。
後面二種錯誤碼測試，爲接口業務級測試。第二種透傳的測試重點是能夠接收並傳遞被調服務系統的返回錯誤代碼及錯誤信息，並保證按照統一規範輸出，特別注意返回信息的完整性（是否被截位）。第三種mapping測試需要覈對映射關係，一般的映射關係有“數據庫、文件、聯動交易”等形式觸發。多數的映射關係採用非實時模式進行批量更新及加載，以減輕系統實時壓力。映射關係測試的重點，爲“映射源的一致性對照、匹配重複情況下的唯一映射、多映射源的優先級、映射效能測試”等。
- 其他測試
其他測試還包含如下：
- 字段命名規範；
- 接口代碼命名規範；
- 必輸域及條件必輸域測試；
- 上送及返回數據類型；
- 上送及返回長度邊界測試；
- 同步異步模式測試；
- 其他企業服務總線封裝的特定功能測試等。
- 測試場景運用
上文介紹了企業服務總線的一些通用測試方法，本章將介紹圍繞企業服務總線，從測試驅動角度觸發的一些具體場景運用。
- 界面不可見信息測試
測試過程中往往根據界面（渠道）上的可見信息，通過測試輸入及信息獲取進行相關測試或比較。但由於如下等情況，部分重要信息可能處於界面不可見：
- 後臺系統的操作標誌，如“新增、修改、刪除”等；
- 頁面間跳轉傳遞的唯一標識/信息；
- 根據監管要求，需要（超出界面範圍）多送的字段，待後續審計；
- 根據登記簿及相關日誌查詢需要，需要（超出界面範圍）多送的字段；
- 獲取交互行爲及操作的重要埋點信息；
- 系統間傳遞及約定的標識信息等。
如此類信息出現在報文的上下文中，則可以通過圍繞企業服務總線下的標準進行相關接口測試，獲取上送、返回信息。可通過模擬報文，或查看日誌等方式進行重要信息的檢索及收集。
- 作爲唯一數據準備入口
受限於測試環境的侷限性，數據準備不能完全通過UI等系統交互形式進行準備。相關涉及系統，由於“環境及網絡、權限控制、前端校驗、功能未完全開發完畢”等原因，無法進行數據準備。通過圍繞企業服務總線下的標準接口，進行數據準備，很好的解決了這些問題。可以在相關係統操作交互及業務模式不是完全瞭解的情況下，通過接口的方式進行唯一的數據準備入口。
- 獲取相關外部測試信息
部分測試中涉及的外部系統，如“直連商戶系統、支付系統、政府及公安網、企業內部的總分系統、第三方批量代扣代繳平臺”等。涉及外部系統數據（多數情況下）無法通過本地相關係統直接進行相關測試基準信息的展示及獲取。可通過圍繞企業服務總線約定下標準接口的方式提前進行相關測試信息獲取，爲後續測試預期結果建立及與實際結果比對提供重要基準信息。
- 流程測試場景
測試過程中接口測試同業務測試一樣，存在多個場景/交易間的信息傳遞，稱之爲流程接口測試場景。如下場景舉例：
- 接口的輸出是後續接口的輸入；
- 接口的輸入是後續接口的輸出；
- 接口的輸出是後續接口返回的預期結果比較基準；
- 接口的輸入是後續接口返回的預期結果比較基準；
流程測試場景中，通過“請求信息”或者“獲取的返回信息”作爲基準值。將此基準值作爲下一個接口的輸入，進行流程傳接。通過最終測試結果返回，根據基準值（或者按照特定邏輯加工的基準值）進行測試結果的比較，評估測試的正確性。
圖3-1 流程接口測試場景
- 其他場景
其他場景運用還包括：
- 對於渠道界面較難模擬的測試場景，可通過發送接口的方式進行快速批量測試請求，以提升測試效能；
- 測試環境中可能無法通過真實手機接收動態驗證碼，可通過查看返回報文的方式，查看並獲取動態驗證碼進行測試；
- 渠道在獲取返回信息時，可能存在錯位、失真及截取等情況，通過同步獲取接口中對應原始返回信息，進一步提升測試準確性；
- 對於渠道操作，如短時間內重複提交兩次等場景，在無法確認數據是否重複入庫的情況下，可通過檢查上送報文的發送次數，確認相關控制邏輯。
- 總結
隨着越來越多的金融機構採用企業服務總線並按照其自身特點進行演變及擴展，對應的測試解決方案不斷在實踐過程中得以歸納、規範、提升。從圍繞企業服務總線進行單一的測試，逐漸轉變爲通過測試驅動企業服務總線進行多場景、多系統的打通及融合，更好的進行全流程測試。同時各實施金融機構需要同步建設以企業服務總線爲主要對象的自動化接口測試平臺，以滿足日益頻繁的測試任務及需求，使得測試手段及測試方法得到進一步提升，最終提升測試效能及企業服務總線全鏈路系統質量。