基于SOA的協同系統自動化測試技術研究*

楊 箴，吳方權

（貴州電網有限責任公司信息中心，貴陽 550002）

0 引言

依據南方電網公司“十三五”信息化發展規劃，某電網公司建設的CSGII企業管理信息系統已在貴州電網全面推廣應用。CSGII系統從頂層設計了各系統的協同業務、跨系統數據流及業務流程。

CSGII 系統交互遵循SOA[1]（面向服務的體系結構）技術路線。隨著CSGII系統應用的不斷深入和系統實用化的工作要求，跨系統SOA 接口測試的問題日益暴露出來，急需引入有效的技術工具提升多系統間SOA 接口服務的測試效率，提高協同業務集成質量。

本文提出了構建基于SOA 的協同系統自動化測試的設計和實現方法，闡述了項目背景，介紹了建設目標、技術路線、功能架構及系統關鍵技術、項目技術難點等，為保障企業級應用系統的安全穩定運行提供參考。

1 背景

隨著企業級應用系統實用化程度的不斷提升，系統協同業務運行質量顯得尤為重要。作為信息系統建設質量檢驗的最有效手段，在系統運維階段也離不開軟件測試。在系統上線和發布前進行充分的協同功能測試，提前發現接口和功能缺陷，才能確保系統發布后的穩定運行。傳統依靠人工的協同應用接口測試已經無法滿足工作的要求，在具體的接口測試過程中主要存在以下問題。

（1）CSGII系統接口數量龐大，沒有高效的自動化測試手段支撐，測試效率低。因CSGII系統涉及230個協同場景，系統間交互的SOA 接口813 個，僅依靠傳統人工測試，給上線前的協同功能測試帶來極大的人力和時間壓力，也給運行過程中的缺陷排查帶來極大困難，協同應用測試效率偏低。眾多的系統接口相互集成產生海量的交互信息，測試工作量大，純人工測試效率低，無法滿足版本管理和高效測試的要求[2]。

（2）協同業務場景的業務邏輯和接口交聯復雜，且各系統由不同開發商開發，管理難度大。協同功能出廠文檔資料覆蓋不全，且需求不斷擴充，業務持續更新。CSGII系統協同應用涉及230 個協同場景，因系統出廠測試文檔覆蓋不全且更新周期較長，協同應用的交互過程基本屬于黑盒或灰盒狀態[3]，沒有完整明晰的文檔詳述系統間的交互流程、數據約束條件，對于排錯和指導實操的支持度還較差。

（3）流程問題難定位，各系統間缺乏業務流程匯集、交互的展現，沒有完整的文檔記錄，導致問題出現時，無法快速、準確地定位問題的所在。如一個完整的配網電子化移交流程涉及23次不同接口之間的交互，出現問題時要想迅速定位解決問題，在沒有完整地梳理交互流程的情況下是不可能實現的。

（4）系統上線之后，相比于建設階段，存在較多的現實難題和壓力，如不能引起業務運行中斷，不能破壞系統存儲的真實業務數據等。

（5）SOA 接口測試過程無相關報文記錄，測試過程、測試結果難于管控、追溯。高效的協同應用測試必須有完整、科學的方法論進行指導，并且需要借助測試工具提升工作效率，在完備測試的基礎上才能持續正確地更新協同應用相關知識文檔，做好知識積累。

面對這些問題，對CSGII系統協同功能測試方法進行深入研究，構建一套自動化測評應用平臺就顯得十分必要。

1.1 CSGII系統

CSGII 系統是南方電網公司遵循“統一領導、統一規劃、統一標準、統一建設”的“四統一”原則建設的企業級應用系統2.0版本，主要涵蓋7大業務域，包括資產管理、營銷管理、人力資源管理、財務管理、協同辦公、綜合管理及決策支持，為南方電網公司的核心業務提供信息系統支撐。CSGII系統主要包括了資產管理系統（含5個子系統）、營銷管理系統、人力資源管理系統、財務管理系統、GIS 平臺、4A 平臺、數據資源管理平臺等業務系統及基礎技術平臺。目前CS?GII系統包含了230個協同應用子場景。

貴州電網CSGII系統明細如表1所示。

表1 主要CSGII系統明細Tab.1 List of main CSGII systems

1.2 協同應用場景

CSGII 系統包含了230 個協同應用場景，通過CSGII 系統協同應用實現各系統之間的數據交互、跨系統的數據流及業務流程。如營銷系統95598 客服模塊接收故障單后，派單到資產管理系統生產子系統進行處理就是一個典型的協同應用場景。

CSGII系統協同業務應用是系統實用化過程中非常關鍵的一環，體現了各系統橫向協同的理念，通過信息系統的頂層設計，打破了部門級系統之間的界限和壁壘。

1.3 藍鯨平臺

企業級系統協同功能自動化測試平臺是基于藍鯨智云PAAS平臺構建的應用，該平臺是南方電網公司統建統推的運維平臺，基于該平臺的深度集成大大降低了后期的推廣難度和成本。藍鯨提供了完善的前后臺開發框架、調度引擎、公共組建等模塊[4]。

藍鯨平臺主要分3個層次。第1層為用戶界面層，是系統使用界面，也是系統的入口，主要針對測試人員；第2層為業務邏輯層，是系統的核心開發部分，主要是完成系統要求的各個模塊的邏輯功能；第3層為基礎服務層，主要完成一些通用服務，例如API 請求代理服務、數據持久化服務、隊列緩存服務等；最底層為平臺系統層，主要完成對硬件資源的調配，為上層提供服務。

2 技術實現方案

2.1 建設目標

建設一套協同業務接口自動化測評應用平臺，并完成貴州電網實用化協同業務接口自動化測試腳本的編制，實現協同業務接口的自動化測評，提高測評效率，降低運行過程中的缺陷排查難度。

2.2 技術路線

基于SOAP 協議[5]構建接口自動化測試平臺，模擬客戶端請求及響應，支持貴州電網CSGII定制化協議報文解析，實現接口協議的功能性、符合性測試；基于XML[6]描述軟件接口測試腳本，實現測試用例和測試數據分離，并基于規范隨機生成測試數據；運用最新數據分析和數據挖掘技術，對測試結果統計分析，實現測試質量度量。自動化測試原理如圖1 所示。

圖1 自動化測試原理Fig.1 Schematic diagram of automatic test

2.3 系統功能設計

從系統功能角度，基于SOA 的協同系統自動化測試平臺分為2層6大模塊。功能架構如圖2所示。

圖2 功能架構Fig.2 Functional architecture

2.3.1 核心層

核心層功能如下：

（1）SOA 測試引擎，系統最核心模塊，負責執行測試用例、捕獲消息體、預言判斷等；

（2）數據MOCK，負責產生隨機數據；

（3）定時任務，負責定時任務執行。

2.3.2 業務層

業務層功能如下：

（1）用例配置，負責生成一個具體用例測試配置；

（2）用例管理，負責用例及測試集合管理；

（3）測試日志管理，負責測試日志及結果展示。

3 關鍵技術

3.1 接口自動化測試示例

配置接口自動化測試示例分為5步：（1）配置相關自動測試引擎；（2）準備相關的場景測試用例；（3）根據測試用例，執行測試步驟；（4）查看各消息在SOA 系統的分發記錄；（5）查看是否按預定路徑分發及驅動下一個消息，查看請求及響應體是否符合預期。協同自動化測試示例如圖3所示。

圖3 協同自動化測試示例Fig.3 Example diagram of collaborative system automation test platform based SOA

一般情況下，測試人員基于一個測試集合（TestUnit）執行一次測試工作。對于單接口連通測試，一個TestUnit包括了多條接口測試用例。在此場景下，測試要點是消息請求和返回是否符合預期即可。對于SOA 場景測試，一個場景測試相當于一個TestUnit，內部可能包含一條或多條接口，而每條接口可能觸發一個或多個節點。在此場景下，測試要點包括每個接口的請求、響應，還包括其所有的傳播路徑及每個觸發節點是否符合預期。復雜度比單接口測試高一個數量級。

3.2 會話保密設計

3.2.1 會話管理

系統提供的會話管理具體控制措施主要有：（1）用戶登陸藍鯨平臺后點擊該應用，應用會向API 接口服務發起認證請求，認證通過后返回臨時調用憑證；（2）獲取憑證后進入到應用主頁即項目搜索頁面，每次調用后端接口均需攜帶臨時憑證，后端驗證憑證成功后會延長憑證有效期；（3）在應用頁面超過有效期未操作，則臨時憑證會失效，會重新開始之前的認證過程；（4）后端綁定了認證服務器來源，因此只有藍鯨平臺的用戶才能成功獲取臨時憑證，從而調用接口，正常使用該應用。

3.2.2 訪問控制

系統使用藍鯨平臺的用戶管理模塊，即用戶權限在藍鯨平臺操作，不同的用戶通過藍鯨平臺認證后，通過接口獲取個人相關的測試項目以及相關數據。

3.2.3 數據安全管理

數據安全管理如下。

（1）服務端數據安全控制措施[7]包括隔離應用的源代碼等文件，不能通過外部網絡請求方式獲取文件數據；用戶登錄的驗證信息通過對稱加密的方式進行加密傳輸，后臺通過秘鑰進行解密，獲取用戶信息。

（2）客戶端數據安全控制措施包括用戶的信息數據不通過URL 參數形式傳遞；禁止表單中的自動填充功能，防止用戶信息被盜用。

3.2.4 接口程序安全

該系統主要用于企業內部網絡，相應的接口亦只能通過內部網絡調用，這能起到一定的網絡隔離作用，只有通過驗證的合法用戶才能調用接口程序。

4 技術難點及處理方法

4.1 協同應用測試方法論

4.1.1 接口總體版本管控

接口總體版本管控如下。

（1）做好CSGII系統接口的版本管理，記錄好本系統提供的接口的關鍵信息，如接口名稱、接口編號、歷史版本、下發時間、更新情況等。

（2）做好接口的版本管理工作，接口需要更新時提交審批，確保版本的穩定性。

（3）在測試期間按“SOA 技術管控”相關模板提交對應資料，并提供必要的紙質資料簽字確認，確保服務注冊、服務變更、服務注銷的全過程管控。

4.1.2 測試環境聯調關鍵點

測試環境聯調關鍵點如下。

（1）確認聯調哪些場景、功能點。

（2）各個系統版本聯調兼容性確認。

（3）相關場景、功能點調用的服務/數據隊列梳理。

（4）確認數據準備是否完備（試點單位的數據是否已導入、涉及主數據是否已完成初始化）。

（5）服務連通性測試1（各系統本身發布的服務能夠正常訪問）。

（6）確認各系統接口服務器到SOA總線的端口正常訪問。

（7）服務連通性測試2（注冊到SOA的服務各個系統能夠正常訪問）。

（8）各個系統確認是否有服務調用的配置項或流程，是否已經啟用，平臺檢查用戶名、密碼、參數、模型、流程等配置是否正確。

（9）配置自動測試流程。

（10）開始聯調。

（11）排錯（查日志、報文、定位故障點、解決問題、記錄問題及解決方法）。

（12）確認完成技術聯調，整理過程調用報文以便復用，自動生成測試報告。

4.2 協同場景自動化測試配置

場景即一個測試場景，一個場景包含一個或多個SOA 服務，這些SOA 服務可能在執行順序上有先后順序，有可能參數與返回結果有引用關系。這一組SOA 服務也可以沒有任何關系，僅僅是因為他們在一起組成了一個場景。創建場景后，根據場景涉及的SOA 服務，逐個搜索出SOA 服務，通過簡單地點擊服務名稱，為場景添加測試用例。啟動場景測試，即可對涉及的一系列接口進行測試，測試的詳情會記錄到日志，點擊查看場景日志，會羅列出該場景的每次測試整體結果，查看詳情可以還原測試現場，包括調用接口時傳遞了哪些參數，服務接口詳細的返回值，很好地支持測試結果的分析。

4.3 SOA接口無法正常調用

大多數情況下，SOA 參數類型為基本類型，例如數字類型、字符串類型。但是對于服務接口參數類型非基本類型的，即參數的只是一個復合體，此種情況下僅能解析第1層參數，無法設置參數值為復雜類型。基版直接采用列表的方式展示其參數的輸入，對與含有復合參數的服務，調用時無法解析參數總是服務調用失敗。

重新調整了參數輸入界面，對于普通參數接口仍采用列表形式展示參數輸入，對于包含特殊復雜參數的SOA 服務，采用文本域接收器[8]參數。添加用例時會自動識別參數是否為復雜類型，復雜類型會生成JSON格式模版，較往常的XML簡潔許多，便于填寫參數。

5 效益分析

5.1 經濟效益分析

5.1.1 接口技術連通性批量測試

貴州電網目前有SOA接口813個，每次大版本發布只能檢查服務連通性時，都只有人工調用確認，效率低、工作量大。按每個SOA 接口需要10 min 確認，813×10/60/8＝16.93 人·天；按每年6 次大版本發布，每年SOA 接口連通性自動化批量測試可節約101.58 人·天；按每天1 400 元實施費計算，每年可節約14.22萬元。

5.1.2 協同應用自動化測試

按230 個協同場景，每次大版本測試涉及30%的協同場景，每個協同場景測試2人·天，每次大版本發布自動測試可節約230×0.3×2＝138 人·天；按每年6 次大版本升級計算，每年可節約828人·天；按每天1 400元實施費計算，每年可節約115.92萬元。

5.1.3 異常日志快速定位、統計

通過協同業務功能建模，全面梳理了協同應用調用邏輯，提升異常快速定位的能力。出現性能異常時，可按系統接口維度直接定位問題日志，可視可控，提升問題排查效率。按每年6次大版本發布，每次大版本測試異常個數50個計算，每個異常定位15 min，可節約人力50×15×6/60/8＝75 人·天；按每天1 400元實施費計算，每年可節約10.5萬元。

5.2 社會效益分析

CSGII系統與企業及所有員工都有密切的關系，通過該自動化測試平臺的建設，提升測試工作質量和效率，為各個業務系統及時測試、發布提供了更高效的工具，保障了電網核心信息系統相關業務的高效運轉。

（1）有力地保障了配網電子化移交、故障搶修等跨專業、跨系統核心業務在系統測試過程中高效的迭代，支持了電網核心業務的正常流轉，提升了整體的工作效率。

（2）通過嚴密的協同應用版本管理，確保了協同升級的穩定性，保證了公司企業級管理信息系統及重要信息系統的安全上線及無間斷運行，有力地保障了電網的安全穩定運行，樹立了公司的企業形象。

（3）通過日志管理模塊的應用，對各個系統的測試情況進行分類分析，可按系統維度反向分析各信息系統的開發質量，為供應商評級提供依據。

6 結束語

協同系統自動化測試平臺實現了協同自動化測試的固化，支撐了協同測試用例管理、實施管理、測試結果管理及展示。平臺設計了可視化測試配置模塊，將測試項規則化，實現接口測試信息域自動提取，自動產生測試報文。

協同系統自動化測試平臺實現了貴州電網實用化協同業務接口自動化測試腳本編制與驗證，建立接口自動化腳本集，可以將協同功能測試由人工測試向自動化測試轉變，增強測試充分性和全面性，提升測試效率，減少測試人力投入，減少系統運行異常，降低缺陷排查的難度。