基于SOA的系統軟件所具有的服務性、粗粒度、松耦合等特點，不僅提高了企業平臺架構的靈活性，也給軟件測試帶來新的挑戰。根據基于SOA的軟件測試的要求，本文研究了測試用例的生成和執行以及性能測試的方法，設計并實現了一個基于SOA的系統軟件測試平臺，該平臺能夠滿足基于SOA的系統功能測試和性能測試的要求。該平臺提高了測試的自動化程度，并為基于SOA的系統軟件測試提供了實用的工具支持。

I.簡介

面向服務的體系結構（SOA）指的是圍繞XML及其消息建立的框架，具有一些消息編碼過程的標準，規定了協議語法和服務實例的位置。這些可以通過簡單對象訪問協議（SOAP）、網絡服務描述語言（WSDL）、通用描述發現和集成（UDDI）的規范分別進行。SOA提供了通信的互操作性，服務的可重用性和兼容性，以及客戶端和服務器之間的松散耦合。SOA的這些吸引人的特點加劇了系統分布、可觀察性和可控制性問題。這也使得測試更加困難。巨大且異構的基于SOA的系統加劇了在可控性、可觀察性和分布方面的挑戰。測試用例的設計、生成和執行需要根據被測對象的WSDL、UDDI和BPEL文檔來進行。由于缺乏關于系統的相關知識，定義這樣的測試用例對測試人員來說是很困難的。性能測試也需要負載生成工具來協助測試人員在不同的服務負載下測試服務調用。傳統的測試方法和工具已經不能滿足基于面向服務架構的系統軟件測試的要求。根據面向服務的軟件架構的特點，設計并實現了一個基于SOA的軟件測試平臺。該平臺可以為使用服務架構的系統軟件功能測試提供用例生成和執行手段，為性能測試提供靈活可調的負載生成手段，滿足基于SOA系統的軟件測試要求。

II.基于SOA的系統軟件測試平臺需求分析

為了實現基于SOA的系統軟件測試平臺的通用化，本文從軟件測試的適用性和有效性角度分析了測試平臺的主要功能需求。

A. 自動測試用例生成功能

自動測試用例生成在網絡服務的自動測試中起著關鍵作用［9］。自動測試用例生成需要通過分析WSDL來生成正常、異常和邊界測試用例。本文采用組合測試思想，綜合運用隨機生成法、邊界測試數據生成法和基于約束的測試數據生成法。測試用例以XML的形式保存，可分為界面測試和功能測試。接口測試只檢測測試用例是否能成功執行，但不檢查測試結果是否正確。功能測試可以設置預期的測試結果并驗證結果。

B. 性能測試功能

性能測試功能需要為測試人員提供負載測試工具，并支持負載參數的靈活設置，包括流量、最大響應時間、最小響應時間、平均響應時間、呼叫成功率等參數。

C. 測試用例執行功能

測試執行需要根據服務傳輸協議的格式來打包和發送測試用例，并分析服務返回的消息。功能測試需要提供比較測試結果的功能，為測試人員提供預期結果的輸入方式，并將預期結果與執行結果進行比較。此外，它還支持測試結果的圖文顯示。

III.基于SOA的系統軟件測試平臺設計方案

A. 平臺架構設計

基于SOA的系統軟件測試平臺分為三個主要模塊：前端程序（SOATest）、測試執行程序（ServiceExecutor）和服務部署容器（SvcHost），如圖1所示。SOA測試負責生成和執行測試案例以及性能測試功能。它為測試人員提供了一個編輯和檢查測試用例及其執行的接口。測試用例被存儲在數據庫中。當測試項目需要被執行時，相關的測試配置將被發送到測試執行器，測試執行器可以安排執行。服務執行器執行測試用例，建立測試環境并管理服務容器組。服務執行器從測試用例設計者那里接收測試任務，根據指定的測試任務生成測試消息，如SOAP消息，并將這些消息發送至目標服務器進行測試。同時，在測試任務執行器上將維護一個服務容器列表，這將有利于服務的部署和控制服務的性能。SvcHost的功能是發布要測試的服務并監控服務的運行。黃頁服務器（UDDI Server）用于發布服務信息，服務發布者可以在黃頁中注冊服務信息，方便檢索和使用。代理轉發網關（RedirectProxy）用于監控不同服務之間的消息流。

圖1 平臺體系結構

B. 數據庫設計

基于SOA的系統軟件測試平臺采用標準SQL數據庫，匹配MySQL和SQLite數據庫。它支持導入和導出XML格式的文件。表1-3是主要的數據庫表。

執行 _ env _設置用于存儲測試案例的運行環境信息，每條記錄存儲一個服務的虛擬化配置選項。

功能性_test_案例存儲了原子測試案例的基本信息，包括測試案例的名稱，要執行的服務，以及測試運行的環境。詳細情況如下：

操作_sequence_test_case 記錄測試案例的功能。它的主鍵是project_id。該表包含一系列的關鍵字，如測試用例id，測試用例名稱，服務空間名稱，服務名稱，端口名稱，操作名稱和測試用例輸入。

C. 測試用例生成功能

本文將測試分為三種基本類型：接口測試、功能測試和性能測試，每種測試類型對應不同的測試案例形式。接口測試主要是測試服務間接口的正確性。功能測試主要測試最小服務單元的功能正確性（如標準Web服務的操作、DDS服務中的IDL結構、REST服務中的資源等）。

性能測試通過構建測試場景來測試系統的并發性能。測試案例類型的詳細描述見表4。

本文采用了聯合測試的思想。根據WSDL文件中的某個操作，綜合使用隨機生成法、邊界測試數據生成法和基于約束的測試數據生成法，并結合輸入中各種因素（邊界、隨機性等）對應的生成方法來生成測試用例。每個測試用例包括測試用例名稱、測試用例ID、對應WSDL的服務地址、對應操作的端口、輸入參數、預期結果等。

隨機生成法根據參數的數據類型、限制和生成量在指定范圍內生成測試用例，以滿足生成量。該平臺從WSDL文件中提取各種類型的限定信息（XSD限制），如候選字符串的枚舉值、字符串模式和數字類型的上限和下限，并通過平臺界面提供給測試人員。測試人員根據測試要求進行調整后，數據將被傳送到測試數據生成器，測試數據生成器將根據要求生成隨機數據。

邊界測試數據的生成方法是生成整數、浮點數、時間和日期、字符串、二進制數據、URL等的邊界測試輸入。平臺首先根據測試者定義的數據范圍過濾內置的邊界值，并刪除不在指定范圍內的數據。然后，測試者給出的范圍的兩端（包括剛好在范圍邊界的數據和與范圍邊界略有不同的數據）被添加到候選邊界值表中。在此基礎上，該算法根據測試人員所需的測試數據量，從一組邊界池中隨機選擇，得到一個大小符合測試人員要求的測試集。

基于約束條件的測試數據生成方法主要支持測試人員創建一套關于服務的約束條件描述，以表達與業務相關的數據特征，然后根據給定的約束條件描述生成測試案例。限制條件是由線性不等式和布爾公式的組合來表達的。在約束的基礎上，約束組由三個運算符 “and”， “or” 或者 “not”組成。

每個原子約束都是一個線性不等式或布爾表達式。表達式由約束變量、約束常數和約束操作符組成。在獲得項目的基本約束條件后，利用微軟Z3 SMT約束解算器獲得滿足約束條件的數據組合，從而生成測試數據。具體過程如圖2所示。

圖2 基于約束的測試數據生成流程

首先，從項目的約束樹中提取與服務操作相關的約束，形成一個約束集；將與WSDL中的約束信息相對應的約束添加到約束集；建立從服務操作輸入數據到每個約束變量的相關信息和約束變量的求解結果，即這些參數的設定值；用Z3求解引擎求解約束條件；根據求解得到的約束變量值，推導出服務操作參數值；根據參數值，建立測試所需的完整測試數據。

D. 性能測試功能

對于小規模的性能測試任務，可以在一臺測試器主機上完成。對于大規模的性能測試任務，一個測試器主機很難產生足夠的并行壓力，所以提出了測試集群的概念。一個測試集群由幾個測試器組成。作為主測試代理，其中一個測試代理負責與SOATest進行交互，總結測試結果和設置測試環境。其他測試器的主要工作是啟動并行的測試任務，必要時掛載RedirectProxy，攔截服務間的消息流，實現服務虛擬化。如圖3所示，每個測試器通常被部署在不同的物理主機上，以使用更多的物理資源來啟動測試。通過配置相應的參數，測試器可以被設置為主測試器和從測試器。每個從屬測試器在啟動時都會自動注冊到主測試器，從而組織成一個測試集群。主測試器收到性能測試任務后，根據性能測試的相關配置，向各從測試器發出并發調用請求，并規定負載發生的時間間隔。

虛擬服務的主要功能是在性能測試環境中模擬第三方服務。因為被測試對象的性能可能會受到第三方服務的影響。為了建立一個可靠的性能測試環境，有必要對第三方服務進行模擬，這樣測試人員可以很容易地控制第三方服務的質量指標。使用虛擬服務來構建測試環境，可以在可控的環境中實現性能測試活動。

該平臺提供虛擬服務，通過配置虛擬服務的狀態、處理成功率、訪問能力、延遲等質量性能，構建性能測試環境，從而實現服務的負載和壓力測試。虛擬服務的內部處理邏輯可以根據測試項目的WSDL文件隨機生成輸出消息內容，也可以根據測試人員設定的約束條件生成輸出消息內容。該平臺支持測試人員根據測試要求設置虛擬業務的質量特征：業務狀態特征可設置為正常、暫停和崩潰；處理成功率設置范圍為0%~100%；接入容量設置范圍為1~1000000；延遲設置范圍0~1000000 ms。

圖3 測試集群

圖4 性能測試流程

性能測試過程如圖4所示。首先，主測試器將待測試的服務部署到服務容器中，并根據測試環境的配置要求創建一個虛擬服務。

然后，主測試器根據預設的性能測試負載策略劃分測試任務，并將不同的負載生成要求分配給從測試器，測試器可以是主測試器也可以是從測試器。根據負載變化策略，每個測試器在不同的時間節點調用待測服務，形成性能負載。

性能測試完成后，每個測試器收集服務的各種性能指標，并將其反饋給主測試器。主測試器將向從測試器和服務容器發送控制命令，拆除已部署的待測服務和虛擬服務，并將系統恢復到其原始狀態。

E. 測試案例執行功能

基于SOA的系統軟件測試平臺通過發送SOAP包來執行測試用例。測試任務由Service Executor實現，它被動地工作，并通過Web API向外界公開套接字。

接口接收JSON RPC 2.0標準的任務描述。收到任務后，Service Executor將任務放入任務隊列。當一個測試任務被安排好后，它將從任務隊列中刪除執行。這種工作模式可以保證測試任務的性能，避免大量測試任務的擁堵。測試執行過程如圖5所示。

圖5 執行過程

第一步：由前端發送的測試任務消息被struts 2中間件攔截，并調用DoAction的消息響應類的執行（）方法來處理這些消息。

第二步：DoAction層級初步解壓測試任務，將解壓后的任務放入任務隊列，在處理完任務隊列前的所有其他任務后，開始處理新提交的任務。

第三步：任務隊列找到與新提交的任務方向相對應的JobHandler，并調用JobHandler的運行（）方法，完成對測試任務的響應。

第四步：測試任務的結果被一步步反饋，最后通過struts中間件返回到測試前端界面。

IV.基于SOA的系統軟件測試平臺的應用

基于SOA的系統軟件測試平臺被應用于基于服務架構的通信管理平臺的軟件測試項目。這個平臺被用來進行功能測試和性能測試。測試案例的執行結果如圖6所示。左邊是測試任務的列表，顯示任務的名稱、發生時間和類型。右邊的上半部分是測試結果的統計，以餅狀圖的形式顯示。右邊的下半部分是測試結果的細節，顯示每個測試案例的執行情況。

圖6 功能測試的性能結果

該平臺通過逐步擴大預設的執行場景，構建負載和壓力過程，觀察被測服務系統的性能。性能測試執行完成后，性能測試執行過程中收集的各種指標可以通過多個折線圖反映出來，包括流量、平均響應時間、最大響應時間、最小響應時間和呼叫成功率，如圖7和圖8所示。

圖7 性能測試執行結果

圖8 服務響應時間

在圖7中，紅線表示流量，藍線表示平均響應時間，綠線表示最大響應時間，黃線表示最小響應時間，粉線表示成功率。對于性能測試，平臺將收集數據，如每次調用的請求時間、調用的完成時間，以及調用是否成功。通過分析，可以形成各種圖表來顯示被測對象的性能，包括不同負載場景下的最大響應時間曲線、最小響應時間曲線、流量曲線和調用執行成功率曲線。所有的曲線都可以顯示在圖表上，使人們對性能測試有一個總體的認識，了解性能下降的關鍵節點。

V.總結

根據面向服務、粗粒度、松耦合的特點，本文設計并實現了基于SOA的系統軟件測試平臺，為功能測試提供測試用例生成和執行手段，為性能測試提供靈活可調的負載生成手段。實例表明，該平臺對于基于SOA的系統軟件測試具有良好的穩定性、靈活性和通用性。

審核編輯 ：李倩