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

I.簡介

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

II.基于SOA的系統(tǒng)軟件測試平臺需求分析

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

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

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

B. 性能測試功能

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

C. 測試用例執(zhí)行功能

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

III.基于SOA的系統(tǒng)軟件測試平臺設(shè)計方案

A. 平臺架構(gòu)設(shè)計

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

圖1 平臺體系結(jié)構(gòu)

B. 數(shù)據(jù)庫設(shè)計

基于SOA的系統(tǒng)軟件測試平臺采用標(biāo)準(zhǔn)SQL數(shù)據(jù)庫，匹配MySQL和SQLite數(shù)據(jù)庫。它支持導(dǎo)入和導(dǎo)出XML格式的文件。表1-3是主要的數(shù)據(jù)庫表。

執(zhí)行 _ env _設(shè)置用于存儲測試案例的運行環(huán)境信息，每條記錄存儲一個服務(wù)的虛擬化配置選項。

功能性_test_案例存儲了原子測試案例的基本信息，包括測試案例的名稱，要執(zhí)行的服務(wù)，以及測試運行的環(huán)境。詳細(xì)情況如下：

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

C. 測試用例生成功能

本文將測試分為三種基本類型：接口測試、功能測試和性能測試，每種測試類型對應(yīng)不同的測試案例形式。接口測試主要是測試服務(wù)間接口的正確性。功能測試主要測試最小服務(wù)單元的功能正確性（如標(biāo)準(zhǔn)Web服務(wù)的操作、DDS服務(wù)中的IDL結(jié)構(gòu)、REST服務(wù)中的資源等）。

性能測試通過構(gòu)建測試場景來測試系統(tǒng)的并發(fā)性能。測試案例類型的詳細(xì)描述見表4。

本文采用了聯(lián)合測試的思想。根據(jù)WSDL文件中的某個操作，綜合使用隨機生成法、邊界測試數(shù)據(jù)生成法和基于約束的測試數(shù)據(jù)生成法，并結(jié)合輸入中各種因素（邊界、隨機性等）對應(yīng)的生成方法來生成測試用例。每個測試用例包括測試用例名稱、測試用例ID、對應(yīng)WSDL的服務(wù)地址、對應(yīng)操作的端口、輸入?yún)?shù)、預(yù)期結(jié)果等。

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

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

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

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

圖2 基于約束的測試數(shù)據(jù)生成流程

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

D. 性能測試功能

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

虛擬服務(wù)的主要功能是在性能測試環(huán)境中模擬第三方服務(wù)。因為被測試對象的性能可能會受到第三方服務(wù)的影響。為了建立一個可靠的性能測試環(huán)境，有必要對第三方服務(wù)進(jìn)行模擬，這樣測試人員可以很容易地控制第三方服務(wù)的質(zhì)量指標(biāo)。使用虛擬服務(wù)來構(gòu)建測試環(huán)境，可以在可控的環(huán)境中實現(xiàn)性能測試活動。

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

圖3 測試集群

圖4 性能測試流程

性能測試過程如圖4所示。首先，主測試器將待測試的服務(wù)部署到服務(wù)容器中，并根據(jù)測試環(huán)境的配置要求創(chuàng)建一個虛擬服務(wù)。

然后，主測試器根據(jù)預(yù)設(shè)的性能測試負(fù)載策略劃分測試任務(wù)，并將不同的負(fù)載生成要求分配給從測試器，測試器可以是主測試器也可以是從測試器。根據(jù)負(fù)載變化策略，每個測試器在不同的時間節(jié)點調(diào)用待測服務(wù)，形成性能負(fù)載。

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

E. 測試案例執(zhí)行功能

基于SOA的系統(tǒng)軟件測試平臺通過發(fā)送SOAP包來執(zhí)行測試用例。測試任務(wù)由Service Executor實現(xiàn)，它被動地工作，并通過Web API向外界公開套接字。

接口接收J(rèn)SON RPC 2.0標(biāo)準(zhǔn)的任務(wù)描述。收到任務(wù)后，Service Executor將任務(wù)放入任務(wù)隊列。當(dāng)一個測試任務(wù)被安排好后，它將從任務(wù)隊列中刪除執(zhí)行。這種工作模式可以保證測試任務(wù)的性能，避免大量測試任務(wù)的擁堵。測試執(zhí)行過程如圖5所示。

圖5 執(zhí)行過程

第一步：由前端發(fā)送的測試任務(wù)消息被struts 2中間件攔截，并調(diào)用DoAction的消息響應(yīng)類的執(zhí)行（）方法來處理這些消息。

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

第三步：任務(wù)隊列找到與新提交的任務(wù)方向相對應(yīng)的JobHandler，并調(diào)用JobHandler的運行（）方法，完成對測試任務(wù)的響應(yīng)。

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

IV.基于SOA的系統(tǒng)軟件測試平臺的應(yīng)用

基于SOA的系統(tǒng)軟件測試平臺被應(yīng)用于基于服務(wù)架構(gòu)的通信管理平臺的軟件測試項目。這個平臺被用來進(jìn)行功能測試和性能測試。測試案例的執(zhí)行結(jié)果如圖6所示。左邊是測試任務(wù)的列表，顯示任務(wù)的名稱、發(fā)生時間和類型。右邊的上半部分是測試結(jié)果的統(tǒng)計，以餅狀圖的形式顯示。右邊的下半部分是測試結(jié)果的細(xì)節(jié)，顯示每個測試案例的執(zhí)行情況。

圖6 功能測試的性能結(jié)果

該平臺通過逐步擴(kuò)大預(yù)設(shè)的執(zhí)行場景，構(gòu)建負(fù)載和壓力過程，觀察被測服務(wù)系統(tǒng)的性能。性能測試執(zhí)行完成后，性能測試執(zhí)行過程中收集的各種指標(biāo)可以通過多個折線圖反映出來，包括流量、平均響應(yīng)時間、最大響應(yīng)時間、最小響應(yīng)時間和呼叫成功率，如圖7和圖8所示。

圖7 性能測試執(zhí)行結(jié)果

圖8 服務(wù)響應(yīng)時間

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

V.總結(jié)

根據(jù)面向服務(wù)、粗粒度、松耦合的特點，本文設(shè)計并實現(xiàn)了基于SOA的系統(tǒng)軟件測試平臺，為功能測試提供測試用例生成和執(zhí)行手段，為性能測試提供靈活可調(diào)的負(fù)載生成手段。實例表明，該平臺對于基于SOA的系統(tǒng)軟件測試具有良好的穩(wěn)定性、靈活性和通用性。

審核編輯 ：李倩