基于SOA的軍用測試系統軟件開發方法研究

范凱胤　王學奇　姚鵬　唐希浪　張景昆

摘 要：針對網絡化條件下，被測對象日益復雜、測試數據難以整合、測試需求變化迅速等問題，提出了一種基于SOA的測試軟件開發方法。從業務需求的角度出發，采用業務流程模型詳細地分析了測試業務過程，捕獲到測試中需要的數據對象和完成的任務。根據業務流程模型，使用面向服務架構建模語言（SoaML），分別從服務框架構建、服務識別和定義、服務實現等幾個方面建立了一個測試服務模型。利用Web Service的技術將測試服務模型映射到服務組件，實現了基于SOA的軍用測試系統軟件。實踐表明，基于SOA的測試軟件開發方法能夠有效解決測試領域面臨的問題。

關鍵詞：測試系統；軟件開發；服務建模；SoaML

中圖分類號：TP311.5 文獻標識碼：A DOI：10.15913/j.cnki.kjycx.2017.08.017

軍用測試系統經歷了專用測試系統、積木式測試系統、模塊化測試系統和網絡化測試系統等4個發展階段。在網絡化的條件下，測試系統能夠實現遠程測試、診斷和信息共享。但隨著被測對象的日益復雜，且產品豐富，測試需求將會更加多變，測試數據也將更加龐大。如何應對迅速變化的測試需求，如何有效整合測試數據，是分布網絡環境下的軍用測試系統所面臨的主要問題。

面向服務的構架（Service-Oriented Architecture，SOA）是包含運行環境、編程模型、架構風格和相關方法論等在內的一整套新的分布式軟件系統構造方法和環境。SOA擁有一套統一的標準，使信息高度共享，且不依賴于特定技術、特定平臺，請求者與提供者之間高度解耦。這種松耦合的系統使得軟件可以靈活地適應業務需求的變化，且復用性強。將SOA應用在自動測試領域，可以有效地解決測試領域面臨的問題。

本文提出了一種基于SOA的測試軟件開發方法，從測試業務需求分析、測式軟件SOA模型建立、Web Service技術實現等幾個實踐過程入手，簡要介紹了如何構建和開發面向服務的測試軟件。這對測試軟件開發人員有一定的參考價值。在開發軟件的同時，也參考了SPR生物傳感檢測系統軟件的設計與實現，基于uC/OS-Ⅱ操作系統的無人機飛控系統軟件設計的一些經驗、方法。

1 測試業務需求分析

傳統的軍用自動測試系統采用的是封閉結構，具有應變能力不足、軟件復用和升級難、系統間互操作性不強、故障診斷的效率和準確性低等缺陷，無法適應信息化條件下多軍種聯合作戰對多型裝備系統、多級維護的需求。為此，國內外專家提出下一代自動測試系統采用開放的體系結構，以便能夠靈活、快速適應需求變化，具有良好的軟件可移植性和互操作能力，提高診斷的有效性。同時，這種結構還具備資源管理服務、測試管理服務、診斷服務、運行時服務和測試數據服務等能力。根據這些需求，整個系統的業務結構如圖1所示。

測試代理采取Web應用的形式，作為測試人員與系統之間的交互代理，提供用戶管理服務和運行時服務，例如用戶登錄、輸入輸出、測試報告等。同時，它也作為各服務之間的統籌模塊，根據測試人員的輸入，協調并請求各服務模塊執行相應的動作。測試管理提供測試服務，接收測試代理的測試請求，加載、運行測試項目，調度測試資源，完成測試任務并返回測試結果。測試數據管理提供數據服務，它收集并保存不同測試平臺、不同環境下的測試結果，形成一個海量測試數據庫，在測試代理的請求下，提供歷史測量數據。另外，它作為一個描述信息庫，可以保存各類描述文件，需要時可以被測試代理調用。故障診斷中心提供故障診斷和故障預測服務，它擁有豐富的診斷算法和知識庫，在測試代理的請求下可以迅速、準確地完成故障診斷或預測，且可以提供有效的維修決策建議。

要想建立一個有效、可靠的SOA模型，需要構建一個業務流程模型，詳細分析業務需求。業務流程模型是一種描述和歸檔業務（或業務的一部分）如何運作（或希望如何運作）的方法，它可捕獲必須執行的步驟或任務（包括決策點），執行這些

步驟或任務的實體或角色，以及它們如何交互實現對信息（數據）的處理和共享。構建業務流程模型可以使用業務流程建模符號（Business Process Modeling Notation，BPMN），它包含以下3個關鍵要素：①通道（Lane）。它表示活動的分組，通常用于表明一組活動均由相同的實體（例如人員或系統）或者角色執行。②任務（Task）。它表示通用活動，僅包含名稱和記錄。③消息（Message）。也可以將其認為是一個數據對象，表示在一個流程內的2個實體間發送的信息。

根據對業務需求的初步分析，可以構建一個測試業務流程模型（為了使后續建模和程序設計具有可溯性，建模均采用英文），具體如圖2所示。

從圖2中可以看出，根據使用需求可設置5個通道，分別對應測試人員（Tester）、測試代理（TestAgency）、測試管理（TestManager）、數據管理（DataManager）和診斷中心（DiagnosticCenter）等5個實體，每個實體在一次測試過程中都擁有各自的任務，在任務之間包含著一些信息的傳遞。采用這種方法，整個測試的業務流程被清晰地展現出來，且各參與者需要在何時完成何任務，數據對象如何流向等信息都會被捕獲到，這將為下一步的建模打下堅實的基礎。

2 基于SOA的測試軟件模型

2.1 SoaML概述

為了建立一個標準的SOA模型，本節將采用SoaML（面向服務架構建模語言）進行建模。SoaML是由OMG（對象管理組織）定義的開源規范，是對UML（統一建模語言）的擴展，它定義了一種符號和元模型來描述面向服務的系統。使用SoaML，可以從2個角度開發服務架構：①自上而下的設計。根據BPMN圖定義服務架構，以探索參與者之間的連接方式，而后識別服務、定義服務、實現服務。②自下而上的抽象。服務模型已經存在，需要被抽象為更高層次的描述。這2種設計方法有所差異，但軟件的設計通常是一個迭代的過程，所以，2種方法都會在設計中用到。由于篇幅有限，本文將以自上而下的方法為例闡述測試軟件的建模過程。

2.2 測試軟件服務框架的構建

運用自上而下的設計方法創建服務框架時，必須要考慮參與者之間怎樣聯系，要試圖解決哪些問題。這些已經在業務流程模型中捕捉到了，將BPMN圖映射到服務框架如圖3所示。

在圖3中，5類參與者對應BPMN圖中的5個通道，參與者之間通過服務契約進行綁定。例如，測試代理與測試管理之間就是通過名為測試執行（TestExcute）的契約綁定的。服務契約實際上反映了2個參與者（服務提供者和服務請求者）之間的交互活動，它將定義一系列協議，規定消費者與提供者之間的活動在何時、何地，以何順序進行。例如，在系統運行時，管理（RunTimeManage）契約可以用時序圖描述，如圖4所示。

圖4清晰地描述了測試代理和測試管理這2種角色之間的活動契約。測試代理作為一種邏輯上的角色，任何參與者（例如測試站、生產方、研究所等）都可以扮演測試代理這種角色，只需要遵循圖4所示的活動契約，就可以調用測試管理所提供的服務接口實現加載項目、卸載項目、啟動測試、獲取測試結果等功能。

2.3 測試軟件的服務識別和定義

服務識別和定義是整個建模過程中最關鍵的一步，它實際上就是要以業務需求為驅動，找出并定義參與者需要提供或消費的服務。在BPMN圖中可以清晰地看到每個參與者均需完成一系列的任務，這些任務實際上就是該參與者所應具備的能力，而服務接口的職責就是要暴露這些能力。下面，以參與者測試管理的測試服務為例加以說明。從BPMN圖中可以明確TestManger通道中所有的任務映射為保證測試管理順利進行而應具備的能力，作為候選服務，有些操作是測試管理內部完成的，例如運行測試動作（Run Test Action）和驅動儀器（Drive Instrument）等，這樣的操作無需作為服務供外部調用，可將其刪除，再根據之前構建的服務框架定義好服務接口，具體如圖5所示。

在定義服務接口時，還需完成另一個重要的任務，即定義服務操作的輸入輸出參數，例如加載測試項目和卸載測試項目需要以測試項目描述作為輸入參數，生成測試結果以測試結果作為輸出參數。這些參數類型應當具有統一的標準，以便實現信息共享。在測試領域，ATML（Automatic Test Markup language，自動測試標記語言）是基于XML（Extensible Markup Language，可擴展標記語言）的數據交換標準，它定義了一個描述，比如測試項目、測試資產、被測對象、測試數據等測試信息的XML模式集合。所以，在服務定義中，操作的輸入或輸出參數實質上是加載或生成的ATML文件，使測試信息高度共享，從而解決了測試數據難以整合的問題。

2.4 測試軟件的服務實現

參與者是實現服務的實體，這些參與者之間的服務和消費關系可以通過服務通道來連接，具體如圖6所示。

圖6反映了所有參與者之間的服務關系，但這些參與者都是大顆粒的，它們只能夠在頂層上描述整個測試服務體系，而在程序的實現上需要作進一步的分解。例如，TestManager（測試管理）可以被分解為TestProjectManager（測試項目管理）、TestProcessManager（測試過程管理）和TestResourceManager（測試資源管理）等3個參與者，所以，在參與者層級又可以按照同樣的方法構建一個新的服務框架。由于方法一致，這里不再贅述。

3 基于SOA的測試軟件實現

從技術層面上來看，實現SOA的方法有多種，而Web Service（Web服務）是其中最主流的實現方案。Web 服務作為功能實現體，向外界暴露能通過Web調用的API，而這些API都采用WSDL（Web Services Definition Language，Web 服務描述語言）進行描述，并使用SOAP（Simple Object Access Protocol，簡單對象訪問協議）進行數據交換，這些標準都是統一、開放的，與平臺無關。

開發Web服務的平臺也有多種，例如JAVA的J2EE平臺和微軟的.NET平臺，開發者可以采用自己比較熟悉的平臺開發。但隨著.NET技術的日益成熟，以及測試行業標準對.NET的支持（例如IVI驅動定義了IVI.NET），基于.NET平臺開發軍用測試系統軟件將成為測試領域的一種趨勢。

技術上實現SOA的過程實際上就是從SOA模型到服務組件的映射過程。有的開發工具能夠自動完成這個映射過程，例如IBM公司的Rational Software Architect就能根據SoaML自動創建SCA（Service Component Architect，服務組件架構）工件，而且能夠生成主干源代碼，開發人員只需擴充源代碼實現功能即可。將Microsoft Visual Studio.net作為編程環境創建Web Service時，可將測試服務模型（服務定義）映射到（或采用工具自動映射到）服務組件，并編寫代碼，實現服務功能。圖7表述的是參與者測試管理實現測試服務的Web Service。

圖7展示了測試管理所提供的Web服務，這些服務接口與平臺無關，任何一個消費者只要按照服務契約均可調用圖7中的服務接口。這樣做，可以大幅提高測試軟件的可重用性和可移植性。另外，測試管理提供的測試服務與其他參與者提供的服務沒有任何耦合關系，當一個服務需要升級時，并不會影響其他服務的工作。例如，診斷管理中心需添加新的診斷算法，暫時停止診斷服務，但它并不會影響測試代理請求測試管理的服務，因而使測試軟件能夠敏捷地應對需求的更新和測試系統的升級。

4 結束語

本文從測試業務需求分析、測試服務建模、測試服務實現等幾個方面入手，研究了SOA在測試領域的實踐方法。使用該方法能夠克服傳統測試軟件復用升級難、數據整合效率低和應變能力不足等缺陷。基于SOA的測試軟件將為大數據和云計算在測試領域的應用創造機會，而如何治理已經實現的測試服務軟件，實現云測試和大數據故障預測將是下一步需要解決的關鍵問題。

參考文獻

[1]肖明清，胡雷剛.自動測試系統概論[M].北京：國防工業出版社，2012.

[2]毛新生.SOA原理·方法·實踐[M].北京：電子工業出版社，2007.

[3]ZHAO Xin，XIAO Ming-qing.Research on the TPS Development based on SOA.2009 IEEE AUTOTESTCON Proceedings. California，2011：151-154.

[4]IBM developerWroks.Design and develop a more effective SOA[EB/OL].[2011-05-02].http：//www.ibm.com/

developerworks/library/ws-designsoapart1/index.html.

[5]方江雄，何紅波，李義兵.基于SOA和BPM的ERP系統的研究與實現[J].計算機應用，2007，27（5）：1264-1267.

[6]楊軍，吳松，李圓怡，等.SPR生物傳感檢測系統軟件的設計與實現[J].傳感器與微系統，2010，29（6）：95-97.

[7]史峰，何立明，馬曉峰，等.基于uC/OS-Ⅱ操作系統的無人機飛控系統軟件設計[J].傳感器與微系統，2008，27（4）：94-96.

本文部分參考文獻因著錄項目不全被刪除。

〔編輯：白潔〕