基于SOA的系統(tǒng)軟件測(cè)試平臺(tái)需求分析

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

I.簡(jiǎn)介

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

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

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

A. 自動(dòng)測(cè)試用例生成功能

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

B. 性能測(cè)試功能

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

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

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

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

A. 平臺(tái)架構(gòu)設(shè)計(jì)

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

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

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

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

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

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

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

C. 測(cè)試用例生成功能

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

性能測(cè)試通過(guò)構(gòu)建測(cè)試場(chǎng)景來(lái)測(cè)試系統(tǒng)的并發(fā)性能。測(cè)試案例類(lèi)型的詳細(xì)描述見(jiàn)表4。

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

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

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

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

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

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

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

D. 性能測(cè)試功能

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

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

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

圖3 測(cè)試集群

圖4 性能測(cè)試流程

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

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

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

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

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

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

圖5 執(zhí)行過(guò)程

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

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

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

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

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

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

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

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

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

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

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

V.總結(jié)

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

審核編輯 ：李倩