服務接口測試自動化工具的研究

卓欣欣 白曉穎 許 靜 李恩鵬 劉 喻 康介恢 宋文莉

1(清華大學計算機科學與技術系 北京 100084)2(南開大學計算機與控制工程學院 天津 300350)(zhuoxinxin@mail.nankai.edu.cn)

服務化作為網絡化環境下軟件的基本存在形態已然成為一種趨勢.將軟件功能封裝為單個服務并通過明確定義的接口使用服務，在屏蔽服務實現細節的同時，能夠有效支持軟件復用和松耦合的分布式應用.服務接口的屬性、約束與調用方式通常以標準協議描述，如同一份契約，需要大家的共同遵守才能正確地使用服務提供的功能.對于提供者而言，契約代表了對所提供功能的一種承諾，對服務消費者而言，則在編程和調用的過程中需要嚴格遵從這份契約的約定.互聯網上越來越多的服務商都在以服務接口的方式提供應用，因而接口的質量非常重要，一個開放接口中存在的缺陷很容易四處擴散，進而導致大規模的軟件故障.所以，服務接口測試對于確保服務和服務組合的質量和可靠性至關重要.然而，服務固有的開放、協同和動態等特性，增加了對其進行有效測試的難度，尤其是服務具有在線發布、升級、演化的特性，這就要求針對服務接口的測試需要具有快速、高效、持續的特點.因此，研究針對服務接口的自動化測試方法具有重要意義[1-3].

模型驅動測試是實現自動化測試的一種重要策略.測試人員使用模型抽象化描述被測系統，并基于模型進行有效測試用例的生成，進而實現測試自動化.將模型驅動測試適當地應用到軟件生命周期的不同階段中將有助于提高軟件故障檢測效率、降低測試成本和時間、有效應對軟件需求變更、增強測試自動化水平[4].當模型驅動用于服務接口測試時，一般都是對被測服務接口進行建模，并基于接口模型實現測試用例的自動生成.

然而，模型驅動測試的高效與否取決于其采用的建模技術是否能夠充分捕獲被測系統的有效特征.建模技術的選取是模型驅動測試研究的關鍵問題之一.目前，已有的基于模型驅動的服務接口測試方法普遍存在這樣一些問題：1)模型描述方法形式化程度較差，自然語言以及文本方式的描述使得自動化處理難以實現.2)表述能力十分有限，缺乏對服務操作行為和集成信息的語義描述，導致無法準確定義服務的使用場景和約束關系.這些問題向消費者屏蔽了一些客觀存在的隱含信息，導致服務提供者和消費者無法對服務采用達成一致的理解，進而造成服務無法正確運行.3)生成的測試用例過于抽象，自動化執行難，由于采用模型語言描述的服務接口通常具有語言無關性，因此生成的測試用例往往采用通用語言描述(如XML)，無法在不同編程語言環境中自動執行.

為此，本文提出了一種基于語義的服務接口測試方法，使用模型驅動測試生成，并設計實現了測試自動化工具——AutoTest.通常，服務接口簽名采用接口操作名稱以及相應特定數據類型描述的輸入輸出返回值參數來定義服務接口函數.無論是參數之間還是函數之間都隱藏著多種類型的約束條件，例如數據的范圍和分區、函數的前置后置條件和可執行約束(參數間的依賴關系、執行順序、時間約束等).為了強化測試的有效性，將上述信息作為領域知識添加進服務接口規范中是相當有必要的.AutoTest工具首先采用半形式化建模方法基于語義規則和本體技術為服務及其相關數據構建了統一的基于接口語義契約(interface semantic contract，ISC)的領域概念模型，支持對被測服務接口數據結構和操作行為的領域建模，在增強服務的易理解性的同時，也使得服務的信息表達更加豐富；其次，基于模型實現測試數據和用例的自動生成，采用多種組合算法優化測試數據和用例生成，支持圖形化的測試計劃編排，能有效完成單個服務和組合服務的測試用例設計和生成；第三，借助用例元模型，實現對測試用例的跨語言描述，靈活生成不同語言的測試代碼文件.圖1為自動化測試工具AutoTest的體系架構圖.AutoTest的視頻演示鏈接地址為：https:v.qq.comxpagey0377oapdi9.html.

AutoTest是基于Eclipse的插件平臺進行設計和實現的.它提供了一個可視化的用戶友好界面，并基于模型驅動測試方法實現了對接口建模到測試生成這一測試全過程的支持.AutoTest中實現了多種基于組合測試的決策表生成算法用于優化測試生成.實驗結果表明，AutoTest可為服務接口測試快速生成大量有效的測試用例.

Fig. 1 AutoTest approach overview圖1 AutoTest體系架構

1 模型的定義與生成

1.1 接口語義契約模型

服務提供者和消費者基于服務接口契約對服務達成一致理解是服務正確調用和執行的重要前提條件.契約中主要包含服務運行所需的數據信息和上下文信息.數據信息中蘊含著豐富的領域概念.上下文信息反映了數據之間的約束和依賴關系、服務與服務之間的依賴關系以及服務與環境之間的依賴關系，捕獲這些關系并將其添加進服務接口模型中將會在一定程度上提高所構建模型的準確性.

文獻[1-2, 5-9]在測試設計中應用了基于語義的知識表達技術，豐富了數據的表達含義，獲得了更加全面的服務接口描述.文獻[1-2]基于Web服務接口的契約和語義知識，使用本體和規則語言為接口構建接口語義契約模型(數據模型和服務模型)，并基于模型實現了用于生成測試數據的分區生成算法和模擬退火算法.文獻[5]使用基于語義的領域模型對服務的外部行為進行了刻畫，并且提供了領域模型轉化為測試用例的映射機制.文獻[6]構建的語義模型能夠對服務的數據、功能以及約束進行良好定義，并且通過語義規則實現了對服務預期行為的描述.由該語義模型計算所得的測試斷言獨立于服務的具體實現，可在具有相同接口標準的服務間實現復用.文獻[7]基于對滿足OWL-S規范的組合服務及其工作流的分析，將OWL-S語義中可能包含的突變算子劃分成了4類，分別是數據突變、條件突變、控制流突變以及數據流突變，并提出了一種基于本體的突變解析方法.通過將該解析方法應用到服務實例BookFinder中，對該方法是否能夠作為標識OWL-S組合服務測試充分性的指標進行了驗證.文獻[8]使用過程控制等方法豐富了傳統契約所能夠表達的信息，使用OWL-S 過程模型形式化描述服務契約，并通過檢驗服務功能和契約表述是否一致來確認契約定義是否有效.文獻[9]通過構建測試本體模型(test ontology model, TOM)定義了測試設計和執行階段的語義信息，并且基于OWL-S中的語義說明解析了服務參數的類屬性和類間關系，進而為其劃分了數據分區.

本文在上述文獻的基礎上，從3個層次為被測服務構建基于語義契約的接口模型(ISC)：數據模型、服務模型以及實現組合測試所需的計劃模型，如圖2所示.構建ISC模型時，采用類、屬性、關系、約束以及個體等本體元素描述特定服務接口的領域概念知識.使用語義規則對ISC模型的數據約束進行描述，包括單個數據模型內約束的描述，如區間約束、枚舉約束和模式定義約束；以及多個模型間約束的描述，如簡單數據模型、復雜數據模型以及服務參數模型間約束優先級的定義和測試計劃模型中數據依賴關系的定義.

數據模型用于服務接口參數信息建模，分為簡單數據模型和復雜數據模型，分別用于描述領域內的基礎概念和復雜概念，復雜數據模型一般由多個簡單數據類型構成.每個數據模型都可以定義自己的約束關系.

Fig. 2 ISC class diagram圖2 ISC模型類結構圖

服務模型通過描述服務執行所必需的數據信息和上下文信息來刻畫被測服務功能.具體地，數據信息的描述是建立在數據模型的基礎之上，而上下文信息的描述是通過添加相關頭文件來實現.

計劃模型是以單個服務模型為基礎，增加了對服務之間控制依賴和數據依賴等多種依賴關系的定義，從而能夠更加準確地描述特定業務場景下各個服務之間的協同關系和執行條件.

1) 數據模型定義

DatatypeSimpleDatatype|ComplexDatatype.

SimpleDatatypeID,classType,generalType,Description,Constraints.

ComplexDatatypeID,classType,Description,Attributes.

①ID：數據模型唯一標識；

②classType：數據模型的名稱；

③generalType：基本數據類型，如int，char；

④Description：數據模型的描述信息；

⑤Constraints{Constrainti}：約束集合；

⑥ConstraintInterval,Enumeration,Schema-Definition：3種約束類型，即區間約束、枚舉約束和模式定義約束；

⑦Attributes{Attributei}：復雜數據模型的屬性集合；

⑧AttributeID,Name,SimpleDatatype,AttrConstraints：屬性定義，由簡單數據類型構成.

2) 服務模型定義

ServiceID,Name,Inputs,Outputs,Return,HeaderFiles.

①ID：服務模型唯一標識；

②Name：服務模型的名稱；

③Inputs{Parameteri}：輸入參數集合；

④Outputs{Parameteri}：輸出參數集合；

⑤ReturnParameter：返回值；

⑥ParameterID,Name,Type,isPointer,Description,Datatype,ParaConstraints：參數定義，以數據模型為基礎；

⑦HeaderFilessystemFiles,userdefined-Files：服務的頭文件集合，用于描述服務運行時所必需的上下文信息.

數據模型和服務模型之間通過數據的約束依賴關系緊密聯系，協同合作實現服務功能.簡單數據模型、復雜數據模型以及服務模型之間的數據依賴關系可看作為優先級由高到低的不同約束(Constraints，AttrConstraints，ParaConstraints)，低級約束的添加需滿足高級約束的限制.

3) 計劃模型定義

PlanID,Name,Description,Services,Dependencies.

①ID：計劃模型的唯一標識；

②Name：計劃模型的名稱；

③Description：計劃模型的描述信息；

④Services{Servicei}：組成計劃的服務集合；

⑤Dependencies{ControlDpi},{DataDpi}：依賴關系集合，用于描述各個服務之間的交互信息，包括控制依賴和數據依賴；

⑥ControlDpseqInvokes,parInvokes,self-Invokes：控制依賴關系，描述了服務的調用序列，包括順序調用、并行調用和自調用；

⑦DataDpIn-InDps,Out-OutDps,In-OutDps：數據依賴關系，描述了服務之間的參數依賴關系.例如：服務IS1和服務IS2順序執行，In-InDps指的是IS2的輸入依賴于IS1的輸入，Out-OutDps指的是IS2的輸出依賴于IS1的輸出，In-OutDps指的是IS2的輸入依賴于IS1的輸出.

1.2 服務模型的轉換與生成

本文設計并實現的測試工具AutoTest雖然可以輔助完成建模工作，但是對建好的模型如何重復利用？這是決定自動化測試優勢能否發揮的關鍵點之一.如圖1所示，本文通過解析服務接口的接口描述文檔及其相關領域概念知識構建ISC模型中的數據模型和服務模型.在初始條件下，模型的構建基于機器可理解的輸入完成，建好的模型可以導出為本體語言描述的模型文件；而在后續回歸測試中，模型的構建可通過直接導入模型描述文件自動化生成.對于頻繁更新的服務接口而言，回歸測試在整個測試周期中占比相當高，AutoTest為測試人員高效更新模型并快速重新生成大量可執行測試用例提供了便捷，規避了人工方式下的繁瑣和易錯性，能夠有效降低測試生成成本，提高測試效率，縮短測試周期[10].

與文獻[1-2,5-9]一樣，本文同樣采用本體語言——OWL (Web ontology language)作為模型描述語言對ISC模型中的數據模型和服務模型進行刻畫.使用AutoTest工具提供的可視化模板完成ISC模型中數據模型和服務模型的構建后，模型可以導出為“.owl”格式，后續可將OWL描述的模型文件直接導入到測試工具中.

ISC模型和OWL模型采用XML的JDOM樹形結構進行轉換描述.轉換的關鍵是確定OWL語言數據結構和ISC模型之間的對應規則，這其中主要涉及到了4種OWL語言結構，它們分別是“DatatypeProperty”，“Class”，“Thing”，“Named-Individual”.“DatatypeProperty”用于指明描述對象為數據模型.“Class”結構用于對數據模型進行更加細致的描述，父類為“Thing”結構的“Class”結構用于描述簡單數據模型和復雜數據模型；父類為非“Thing”結構的“Class”結構用于描述構成復雜數據模型的簡單數據模型，這種情況下，父類即為相應復雜數據模型對應的結構.“NamedIndividual”結構用于描述服務模型及其參數信息.該結構中的“process:hasInput”，“process:hasOutput”，“process:hasReturn”可用于區分輸入參數、輸出參數和返回值參數.通過為OWL模型中的相應屬性賦值可實現ISC模型到OWL模型的轉換；通過解析OWL模型中相應屬性的值可重構ISC模型.具體的OWL文件生成和解析算法如算法1和算法2所示：

算法1. OWL文件生成算法.

輸入：簡單數據模型、復雜數據模型、服務模型；

輸出：OWL文件.

Elementroot=GeneHeadForOwl();

Documentd=newDocument(root);

addDataModel(simpleData,complexData,root);

For (eachsinservices) do

root.addContent(GeneService(s));

End For

For (eachsinservices) do

For (eachpins.inputParas) do

root.addContent(GeneInputForService(p));

End For

For (eachpins.outputParas) do

root.addContent(GeneOutputForService(p));

End For

For (eachpins.returnParas) do

root.addContent(GeneReturnForService(p));

End For

End For

DocTypedType=newDocType(“rdf:RDF”);

StringstrDeclare=GetDeclare();

dType.setInternalSubset(strDeclare);

d.setDocType(dType);

owlFileGenerate().

算法2. OWL文件解析算法.

輸入：OWL文件；

輸出：簡單數據模型、復雜數據模型、服務模型.

/*root為OWL文件根節點*/

For (eacheleinelels) do

If (ele節點名稱為“DatatypeProperty”)

then

addToSimpleData(ele);

End If

If (ele節點名稱為“Class”) then

If (ele第0個孩子節點屬性為“Thing”)

then

addConstrainToSimpleData(ele);

Else

addConstrainToComplexData(ele);

/*解析約束，添加到已有的復雜數據模型中，若該復雜模型不存在，則新建*/

End If

End If

If (ele節點名稱為“NamedIndividual”)

then

If (ele第0個孩子節點屬性為

“AtomicProcess”) then

addToServices();

For (eachcinele第1個以后孩子節點) do

If (c節點名稱為“hasInput”) then

addInputParaToService();

Else

If (c節點名稱為“hasOutput”)

then

addOutputParaToService();

Else

If (c節點名稱為“hasReturn”)

then

addReturnParaToService();

End If

End If

End If

End For

End If

End If

End For

2 基于模型的測試生成

在需求分析時，我們遇到了以下4個問題需要解決:1)自動化生成方法固然能夠在短時間內快速生成大量測試數據，但是如何挑選具有高覆蓋率、低數量級的測試數據集？這對于降低后續測試執行成本而言是一個關鍵問題；2)無論采用哪種組合算法，生成的決策表都會存在冗余和無效的決策，如果不能及時剔除，在后續生成測試用例時會造成額外的開銷；3)被測服務的開發語言存在差異，測試工具可以根據自然語言描述的服務接口文檔完成建模工作，無需關注內部實現語言，但在生成測試代碼時卻缺少靈活性，只能以程序中固化的方式生成特定語言的測試代碼；4)進行組合測試時，服務之間會存在數據和控制依賴關系，如何能便捷直觀地描述各種依賴關系，高效完成測試計劃編排？

針對上述問題，我們在測試工具的設計與實現中采取了針對性的解決方法.

2.1 基于數據分區的組合測試數據生成

基于數據模型和服務模型中的參數約束，可以根據測試覆蓋率的需求生成測試數據.使用服務參數的整個輸入域作為測試輸入，無疑會得到最大的測試覆蓋率，但是會帶來針對性差、代價高的問題.并且，當同時存在多個參數時，追求全覆蓋會導致參數組合爆炸.

為此，本文提出基于數據分區的組合測試方法，通過為服務參數的輸入域劃分數據分區并為分區組合構建決策表，解決測試數據生成的盲目性問題，同時在覆蓋率和組合爆炸之間取得折中.方法描述如圖3所示.

1) 數據分區劃分.依據等價類劃分的思想，為服務的每個輸入參數劃分數據分區，包括合法分區和非法分區，用于描述更加細化的參數數據約束條件.

2) 分區數據集設置.針對每個數據分區，可采用隨機方式或者自定義方式從每個分區中選取少數代表性數據作為分區數據集，用于最終的測試數據自動生成.分區數據集的設計，既有效避免了使用整個分區作為輸入時可能導致的測試數據量過大的問題，又能有效提高測試的針對性，為滿足使用盡量少的測試用例達到盡量大的覆蓋率的測試目標提供了可能.

3) 決策表生成.以服務的輸入數據分區作為條件屬性，以服務的返回值作為決策屬性，為服務的輸入參數組合創建決策表.為了避免組合爆炸，采用了多種組合測試算法(全組合、IPO2組合、基于擬水平法的正交實驗設計、基于并列法的正交實驗設計)來生成滿足不同測試覆蓋率需求的決策表.

Fig. 3 Generation of test partitions and test data based on combinatorial algorithms圖3 基于組合測試算法的數據分區和測試數據的生成

計劃模型的測試用例來自于其組成服務的測試用例集組合，對這些用例數據進行笛卡兒積組合遍歷無疑會導致組合爆炸，因此，也采用組合測試算法來支持計劃模型的測試數據生成.

2.2 決策表約減算法

組合測試算法生成的決策表由決策規則集R={r1,r2,…,rn}構成，其中，每條決策規則rx均是由p項條件屬性Crx={c1,c2,…,cp}和q項決策屬性Drx={d1,d2,…,dq}構成.為了對決策表中可能出現的冗余和無效規則進行剔除，本文定義了如下的決策表約減規則：

對于決策表中的任意2條決策規則rx和ry，R={r1,r2,…,rx,…,ry,…,rn}，如果它們的條件屬性中有且僅有1項是不同的，即Crx={c1,c2,…,cix,…,cp}，Cry={c1,c2,…,ciy,…,cp}，并且它們的決策屬性均相同，即Drx=Dry={d1,d2,…,dq}，則可將rx和ry進行約減合并，R={r1,r2,…,rx+y,…,rn}，Crx+y={c1,c2,…,cix+ciy,…,cp}，Drx+y={d1,d2,…,dq}.

在決策表中不斷重復執行上述約減規則，直至找不到符合約減規則的決策規則為止.具體的決策表約減算法如算法3所示.對決策表進行約減能夠提高后續測試用例的生成效率，有效避免了決策表冗余可能造成的額外開銷.

算法3. 決策表約減算法.

輸入：原始決策規則集R={r1,r2,…,rn}；

R′←R;

Forx=0 to |R′|-1 do

Fory=x+1 to |R′|-1 do

If (rx和ry的p項條件屬性有且僅有1項不同) && (rx和ry的q項決策屬性均相同) then

rx=rx+y;

R′.remove(ry);

x=x-1;

break;

End If

End For

End For

算法3所示決策表約減算法的復雜度為O(n2)，在面對規模較大的決策表時，其執行代價較高.如何改進算法，降低算法執行成本，進而助力于縮短測試數據生成時間，是本文后續工作的重點之一.

2.3 跨語言測試代碼生成

為屏蔽被測服務在實現語言上的差異性，支持不同編程語言測試代碼的靈活生成，首先，我們提出了通用用例元模型的概念，使用XML作為模型描述語言，根據用例信息，對測試代碼生成所需的各類要素進行建模，包括：被測服務的基本信息、被測服務的參數信息以及測試數據等.定義如下：

TestCaseServiceInfo,ParametersInfo,TestData.

1)ServiceInfoServiceName：被測服務信息，用于測試代碼中被測服務接口的聲明；

2)ParametersInfoParaName,Type,isPointer,Datatype,GeneralDataType：被測服務參數信息，用于測試代碼中被測服務參數的聲明；

3)TestData：測試數據，即服務參數取值.

其次，考慮到Velocity模板引擎技術[11]具有基于模板引擎快速生成代碼的強大優勢，而且遵循相應編程語言的語義和語法定義設計出來的Velocity模板能夠為測試數據轉換成指定編程語言的測試代碼提供映射規則，我們將用例元模型所需的各要素映射到Velocity模板中，即可實現基于多種編程語言的測試代碼的自動生成，比如C++或者Java.其中，生成C++代碼時會包含2個版本，一個是直接編碼版本，另一個是動態鏈接庫版本.

圖4展示了基于通用用例元模型生成測試用例代碼文件的過程.使用用例元模型，不僅能夠幫助用戶更清晰地理解測試用例，同時還能夠簡化測試用例的自動生成過程，為驗證不同語言測試用例代碼的一致性提供依據.

Fig. 4 Test cases generation based on the meta-model圖4 基于通用用例元模型生成測試用例代碼

Fig. 5 Test plan visual editor圖5 測試計劃圖形化編排

2.4 可視化測試計劃編排

我們提出一種可視化的測試計劃編排思路，并基于圖形化編輯框架(graphical editor framework，GEF)開源框架予以實現.GEF符合標準的模型-視圖-控制器(model view controller， MVC)架構，模型和視圖之間彼此透明，僅通過控制器進行信息傳遞，將模型和視圖的具體實現分割開來，減少二者之間的交互操作，從而提高了框架的可復用性.圖5是使用AutoTest測試工具編排的測試計劃.

測試計劃定義為有向圖，節點(矩形)表示被測服務的用例代碼集合，邊表示被測服務用例代碼集合之間的控制依賴關系，可定義用例代碼集合之間的控制流和數據流結構.控制流結構可定義自調用依賴關系(折線)、順序調用依賴關系(直線)、并行調用依賴關系.數據流結構可定義輸入輸入參數依賴關系、輸出輸出參數依賴關系、輸入輸出參數依賴關系.AutoTest采用圖形化編輯工具進行測試計劃有向圖的編輯，通過拖拽方式編輯測試用例代碼集之間的組合關系.

Fig. 7 The data model of MailService圖7 MailService數據模型

據此，圖5所示測試計劃MailService可表示為由節點構成的集合V和由有向邊構成的集合E構成的圖G，記為G=(V,E).其中：

1)V={UserLogin,MailSend,MailCheck,UserLogout}，共4個節點；

2) 有向邊e使用二元組(c,d)表示，其中c=v1,v2表示1條由v1指向v2的有向邊；d={[p1=p2]}表示有向邊上的屬性依賴集合，例如p1屬性依賴于p2屬性；

3)E={e}={(c,d)}={(UserLogin,Mail-Send,{[MailSend.seOperateGroupID=UserLogin.inOperateGroupID]}),(UserLogin,MailCheck,{[MailCheck.chOperateGroupID=UserLogin.inOperateGroupID]}),(MailSend,MailSend,{}),(MailCheck,MailCheck,{}),(MailSend,UserLogout,{[UserLogout.outOperateGroupID=MailSend.seOperateGroupID]}),(MailCheck,UserLogout,{[UserLogout.outOperate-GroupID=MailCheck.chOperateGroupID]})}，共6條有向邊.

為了提高測試計劃的可復用性，測試計劃模型使用XML文件進行描述和存儲.圖6為測試計劃的部分XML描述.

Fig. 6 XML specification of test plan圖6 測試計劃的XML描述

2.5 實例研究

本文設計并實現的測試自動化工具AutoTest，支持服務建模、測試數據生成、測試用例生成及可視化測試計劃編排.該工具用于服務接口測試時，測試活動分成2個階段進行：1)獨立測試階段，完成單個被測服務的建模和測試生成；2)組合測試階段，將多個服務按照應用場景編排成測試計劃，生成計劃用例.

本節使用郵件服務組合MailService作為測試對象來簡要描述AutoTest工作過程.該組合包括4個單獨的服務，分別是用戶登錄服務UserLogin、郵件發送服務MailSend、郵件查看服務MailCheck和用戶注銷服務UserLogout.根據業務邏輯，4個服務之間存在控制依賴關系，即用戶需要先登錄，然后進行郵件發送或查看操作，最后退出登錄.

2.5.1 獨立測試階段

在該階段，分別對組合中的4個服務進行獨立測試.以MailSend為例，為了向服務模型提供數據和約束支持，在對服務的接口文檔和領域知識進行解析之后，構建如圖7所示的數據模型.“基本類型”為系統提供的基本數據類型，“領域概念”為描述被測服務接口領域知識所必需的特定數據類型.除此之外，依據服務的測試需求，還需要為相應的數據模型定義必要的約束條件，例如，在本實例中為數據模型Email定義了模式定義約束“*@mail.nankai.edu.cn”.

在數據模型構建完畢之后，即可進行服務模型的構建.服務模型使用圖7中構建的數據模型描述其參數信息，并通過添加頭文件來提供服務運行時所必需的上下文信息.圖8為MailSend的服務模型.而圖9所示為郵件服務組合MailService的OWL文件描述.

MailSend：mailssendingserviceParametersIDNameTypeDatatypeDescriptionParaConstraints1seOperateGroupIDinputIDTypetheidentificationofgroupofoperationsdefault2seMailAddressinputAddressInfowherethemailfromandwherethemailtodefault3seMailSubjectinputContentType?thesubjectofthemaildefault4seMailAttachmentinputAttachmentInfoattachmentsinformationofthemaildefault5seMailContentinputContentType?thecontentofthemaildefault6seMailIDoutputIDTypetheidentificationofthemail[1，500]7seReturnCodeIDreturnIDTypestateofMailSendservice{0，1}HeadFilessystemFilesuser?definedFilesnone“AgentCaller．h”

Fig. 8 Service model of MailSend
圖8 MailSend的服務模型

在服務模型構建完成后，有必要為服務的每個輸入參數劃分合法數據分區和非法數據分區.分區的劃分以參數的數據約束為基礎.當參數約束為“default”類型時，約束內容由高一級的類型約束決定.以圖8中的參數seOperateGroupID為例，其參數約束由IDType類型的約束決定.由于復雜數據類型的輸入參數包含多個簡單數據類型的子參數，在劃分分區的時候，需要分別為每個子參數劃分合法和非法分區以構成復雜數據類型參數的分區.當測試人員未進行分區劃分時，系統會依據參數的數據約束自動地為相應參數生成1個合法分區和1個非法分區.根據測試需求，在本文實例中手動地為郵件發送服務MailSend劃分了17個數據分區，如表1所示:

Table 1 Data Partitions of MailSend表1 MailSend的數據分區

基于數據分區，測試人員可以選擇不同的組合測試算法(全組合、IPO2組合、基于擬水平法的正交實驗設計、基于并列法的正交實驗設計)，為服務生成決策表，并基于分區數據集和決策表采用隨機或者遍歷的策略生成測試數據.

測試數據生成后，測試人員可以選擇測試代碼的語言類型，借助于通用用例元模型的描述，映射到Velocity模板中.Velocity模板引擎在初始化后，合并存放在其上下文中的測試數據和相應的代碼模板，并將結果進行輸出，從而得到所需語言的測試代碼.

2.5.2 組合測試階段

根據郵件服務組合MailService的測試需求，將獨立測試階段中生成的4個服務UserLogin，Mail-Send，MailCheck，UserLogout的測試用例集拖拽進計劃模型編輯區域，如圖5所示，根據順序調用、并行調用和自調用3類控制依賴關系使用可視化連接組件連接各個服務.同時，定義了2個UserLogin→MailSend和UserLogin→MailCheck的In-OutDps，2個MailSend→UserLogout和MailCheck→UserLogout的In-InDps，共4個數據依賴.

數據依賴關系是否成立，取決于存在依賴關系的2個參數在數據類型和數據約束2個方面是否同時匹配.數據類型的匹配檢查在依賴定義時進行，數據約束的匹配檢查在計劃用例執行過程中進行.

3 實驗結果及分析

3.1 數據分區覆蓋率

為評估不同組合算法生成的測試數據的覆蓋率，我們對決策表規模和組合覆蓋率2個指標進行了分析.實驗對象為第2節的郵件發送服務MailSend.

Fig. 10 Comparison of the size of decision tables of MailSend using various combinatorial algorithms圖10 基于不同組合測試算法為MailSend生成決策表的規模

分別使用全組合算法、IPO2組合算法、基于擬水平法的正交實驗設計算法以及基于并列法的正交實驗設計算法生成決策表，圖10(a)是約減前的決策表規模，圖10(b)是約減后的決策表規模.從圖10(a)中可以看出，對于同樣的數據分區，全組合算法生成的決策表規模最大，IPO2組合算法得到的決策表規模最小.這是因為相比較于IPO算法，正交實驗設計算法不僅需要滿足一定的組合覆蓋率，還要兼顧正交性，因此其決策表規模會稍大些.

從圖10(a)和圖10(b) 對比可以看出，全組合算法生成的決策表規模在約減后顯著減小，而由其他組合算法生成的決策表的約減效果并不十分明顯.這主要是因為本文實現的約簡算法是針對有且僅有1個條件屬性不同，其余條件屬性以及決策屬性均相同的決策規則集進行約減合并.全組合算法生成的決策表確保了對各個參數取值的全集覆蓋，從而其中必然存在大量滿足約簡算法約減規則的決策規則集，因此其約減效果相當顯著.IPO2組合算法生成的決策表確保了對各個參數取值的2組合覆蓋，也即確保了任意2條決策規則至少有2個條件屬性是不同的，從而不存在滿足約簡算法約減規則的決策規則集，因此約簡算法對其是無效的.基于擬水平法的正交實驗設計算法和基于并列法的正交實驗設計算法生成的決策表為了確保其正交性，會在其決策表中添加少量滿足約減算法約減規則的冗余決策規則集，因此其約減效果存在但并不明顯.

圖11為2組合、3組合、4組合以及5組合數據分區中各組合測試算法為郵件發送服務MailSend生成的決策表的覆蓋率統計結果.其中，N組合是指隨機選取N個參數，并從每個參數中隨機挑選1個數據分區，構成N個數組分區的組合.覆蓋率計算公式為：(決策表覆蓋的組合數量隨機的組合數量)×100%.其中，隨機的組合數量是指隨機地挑選相應數量的N組合.

Fig. 11 Comparison of the combination coverage of MailSend圖11 MailSend組合覆蓋率的比較統計

Fig. 12 Comparison of decision table coverage of MailSend圖12 MailSend決策表覆蓋率比較

從圖11中，可以看到，在2組合中，3種組合測試算法均達到了100%的組合覆蓋率；當組合內包含更多的數據分區時(3組合、4組合、5組合)，正交實驗設計算法的組合覆蓋率始終優于IPO2組合算法.這是因為IPO2組合算法僅能夠確保對兩組合進行覆蓋，無法確保對更多組合的覆蓋率；而兼顧了正交性的正交實驗設計算法依然能夠在更多組合的情況下表現出良好的覆蓋率.

圖12為不同組合測試算法生成的決策表對不同數據分區組合的覆蓋情況.從圖12中，可以看到隨著組合內包含的數據分區數量的增加，各算法的組合覆蓋率均有明顯下降.但是，由于軟件失效大多數是發生在單點故障和2組合故障中，極少是由更多組合同時出現故障引起的，因此本文中的組合測試算法所生成的決策表能夠對數據分區組合具有較好的覆蓋率.

3.2 測試代價分析

實驗使用第2節的郵件發送服務MailSend作為被測單個服務，郵件服務組合MailService作為被測組合服務，驗證本文設計并實現的基于ISC模型的AutoTest能夠有效支持大批量測試用例的設計和生成.

決策表中的每1行稱作為決策規則.測試用例生成方式包括隨機方式和遍歷決策規則方式2種.在隨機方式下(圖13(a))，測試人員可指定隨機的決策規則數量以及每條規則生成的隨機測試用例數量.這就是說，在該方式下測試人員能夠指定生成的測試用例總數量.在遍歷決策規則方式下(圖13(b))，由于所基于的分區數據集的規模可能是確定的(自定義方式)，也可能是不確定的(隨機方式)，所以該方式下，每次生成的測試用例總數量是不同的，并且測試人員無法指定生成的測試用例總數量.考慮到測試應用場景的規模，本文在AutoTest工具中對生成的測試用例總數量的上界進行了限制(≤100 000)且使用自定義方式定義分區數據集.統計生成不同數量測試用例的總時間，如圖13所示，可以發現生成單個測試用例的用時很短，并且大部分時間是用于文件的寫入.這說明使用本文提出的測試方法能夠快速為單個服務生成大量測試用例，這是手動方式無法趕超的.

Fig. 13 Comparison of test generation time and size of MailSend圖13 MailSend測試用例生成的時間和數量

Fig. 14 Comparison of test generation time and size of MailService圖14 MailService測試用例生成的時間和數量

圖14為使用不同組合測試算法為郵件服務組合MailService生成計劃用例的數量和時間.觀察圖14可以發現，為郵件服務組合MailService生成計劃用例時所表現出的在用例數量和生成時間上的特點與為郵件發送服務MailSend生成測試用例時的一致.并且，雖然由于單個計劃用例中包含了更多的代碼文件導致其平均生成時間有所增加，但該時間依舊是秒級的.這說明，在面對更為復雜的應用場景時，本文提出的測試方法仍然能保持較高的測試用例生成速度，有效降低了測試過程中的人力開銷.

由于對各級模型進行了持久化存儲，因此模型在被構建完畢之后可被不斷復用，從而簡化測試用例的自動生成進程，這為面向服務測試中最常進行的回歸測試提供了極大的便利.

3.3 真實Web服務接口的測試生成與執行

實驗挑選了百度第三方接口分發平臺API Store上具有較多接口參數的3個較為典型的Web服務接口：HolidayService(節日查詢服務接口)、GeoService(地理位置查詢服務接口)和Currency-Service(匯率轉換服務接口)作為被測服務，其服務接口鏈接地址如表2所示，驗證自動化測試工具AutoTest能夠為真實Web服務接口快速生成大量測試用例，并且這些測試用例具有可執行性和一定的錯誤檢測率.

Table 2 URL of Web Services表2 Web服務接口鏈接地址

Fig. 16 Statistics of test of GeoService圖16 GeoService測試生成與執行統計

圖15(a)、圖16(a)、圖17(a)為使用AutoTest為HolidayService，GeoService，CurrencyService生成測試用例集的時間和數量統計結果，可以發現，AutoTest能夠在短時間內為真實Web服務接口快速生成大量測試用例，極大地節約了測試成本，在解放人力的同時有效避免了手動生成測試用例時的繁瑣和易錯.

圖15(b)、圖16(b)、圖17(b)為訪問Web服務HolidayService，GeoService，CurrencyService，執行測試用例的結果統計，可以發現，由本文自動化測試工具AutoTest生成的測試用例具有可執行性并且具有發現接口錯誤的能力.同時，基于IPO2組合生成的測試用例具有最高的錯誤發現比率，基于并列法的正交實驗設計算法次之，基于擬水平法的正交實驗設計算法相對最低.這是因為這3個服務接口可能包含的錯誤基本上是單點或者是2組合的，因此決策表規模更小、生成測試用例數量更少的IPO2組合算法優勢更為明顯.通過解析CurrencyService未通過的測試用例發現，該服務接口具有不穩定性，會不定時出現“Service provider response status error”的錯誤，因此圖17(b)所示未能滿足上述規律.

Fig. 15 Statistics of test of HolidayService圖15 HolidayService測試生成與執行統計

Fig. 17 Statistics of test of CurrencyService圖17 CurrencyService測試生成與執行統計

通過解析HolidayService未通過的測試用例，發現了該Web服務未對輸入的合法性進行檢測，例如向該服務輸入包含非數字字符的日期，服務仍能返回是否為節假日的查詢結果，未對此類錯誤作異常處理；同時，發現該Web服務未對輸入的日期有效性進行檢測，即未對閏年、年月日值域等進行識別，導致服務在此類錯誤輸入下仍能進行是否為節假日查詢，出現錯誤的查詢結果.

通過解析GeoService未通過的測試用例，發現該服務未對經緯度以及坐標系的非法輸入進行檢測，導致服務在此類錯誤輸入下仍能返回查詢成功的結果，未能向用戶提供正確的服務執行結果.

4 相關工作

4.1 服務測試

近年來，對服務測試的研究工作涉及多個研究方向[12-14]，包括測試建模、測試數據生成等.

1) 基于契約的測試設計.Bertolino等人[15]使用UML2.0協議狀態機(PSM)增強了網絡服務描述語言(Web service description language， WSDL)的描述能力，特別是其中的前置、后置條件和數據、進程約束，為用戶驗證不同條件下服務的可使用性提供了支持.Heckel等人[16]為基于XML的服務協議定義了基于XML的契約描述語言，擴展了此類服務協議的信息表達，通過使用圖形轉換規則修正基于UML的概念模型，從而實現了對契約的可視化展示.Bruno等人[17]使用測試用例來刻畫服務契約.測試用例由服務提供商給定，并且可被用戶用來進行回歸測試，追蹤服務在在線演化過程中功能和非功能特性的變化.基于契約的設計思想有助于服務提供商和用戶形成對服務的一致理解，為二者的合作達成奠定基礎.本文在設計服務模型時借鑒了基于契約的設計思想，并使用基于語義的知識表達技術進行輔助刻畫，豐富了數據的表達含義，獲得了更加全面的服務數據描述.

2) 組合服務測試.一般情況下，組合服務的方式有2種：一種是編制，另一種是編排.在編制方式下，存在一個主服務，該服務負責協調剩余的其他各個服務，使它們能夠有條不紊地執行.然而，在編排方式下，所有的服務均具有平等的地位，它們彼此協同合作實現統一的功能.BPEL是描述編制方式的主流語言.Ni等人[18]通過捕獲WS-BPEL描述的消息序列信息，包括順序信息和約束信息，形成服務的消息序列圖(MSG)，并以此圖為基礎生成消息序列.Ilieva等人[19]開發出了一個健壯的測試框架—TASSA.該框架將使用BPEL語言描述的編制服務作為測試目標，同時在其具體實現中考慮了故障注入機制.Bentakouk等人[20]使用符號轉換系統為WS-BPEL構建模型，并通過符號執行生成所需的測試用例.WS-CDL和WSCI是描述編排方式的2種語言.在編排方式下，服務之間通過交換消息實現信息交流.該過程中的數據流由XPaths進行刻畫.Mei等人[21]提出了使用XPath重寫圖(XPGs)來描述XPath 和XML模式之間的映射關系.經過XPGs增強的標簽轉換系統能夠更好地描述編排方式下各個服務的協同合作過程.Wieczorek等人[22]開發出了一個測試套件生成器，其中包括 Event-B和ProB.Event-B是該生成器的輸入模型，由消息編排模型轉化得來(MCMs)；ProB是該生成器的模型檢驗器.本文的組合測試基于編排方式，采用可視化技術實現了對業務流程的靈活定制，從而可以更快地響應不斷改變的業務測試需求.

4.2 組合測試

組合測試(combinatorial testing)是一種高效的以規約技術為基礎的測試生成方法，其目的是用于檢測被測軟件中由少量參數組合交互所引發的一系列缺陷.Kuhn等人[23]通過實證研究證明了，絕大部分軟件缺陷的發生僅與少量參數的組合具有相關性，從而組合測試能夠在確保缺陷檢出率的同時有效縮減測試用例集的規模.近年來，組合測試獲得了國內外許多研究學者的關注，多種組合測試算法被提出.這些算法可被大致歸納為3類，分別是代數構造算法、貪心算法以及啟發式搜索算法[24-25].目前，組合測試已被廣泛成功地應用于學術界和工業界.

1) 代數構造算法.基于正交表的正交實驗設計算法能夠在極短的時間內為被測軟件快速生成測試用例，并且，在部分情形下能夠產生具有最優覆蓋的測試用例集合.Mandl[26]將該算法應用于Ada編譯器的測試中，Brownlie等人[27]基于該算法設計并實現了OATS工具.正交實驗設計算法會額外地生成一些測試用例用以確保其所基于的正交表的正交性，這無疑會增加軟件測試的成本，Williams等人[28]將組合數學中使用頻繁的遞歸構造思想引入正交實驗設計算法中，為改善上述問題提供了一種實用方案，同時，設計并實現了TConfig工具.該工具的優點是其適用范圍廣泛，并且具有較快的運行速度，缺點是其輸出的測試用例數量通常過于龐大.本文實現了經典的代數構造組合測試算法——基于擬水平法和并列法的正交實驗設計算法，和全組合算法相比，能夠在有效降低生成的決策表規模的同時確保組合覆蓋率，對于測試工具而言具有實用價值.

2) 貪心算法.one-test-at-a-time是一種典型的一維擴展算法，它遵循貪心策略，每次增添1個能夠覆蓋最多尚未覆蓋組合的測試用例，直至全部組合均被覆蓋.目前，基于該算法設計并實現的組合測試用例生成算法和工具有很多.Cohen等人[29]設計實現了商業測試工具AETG，但由于該工具將隨機技術引入其測試生成過程中，因此最終獲得的測試用例集具有不確定性.Tung等人[30]提出的TCG算法，通過對參數值域進行排序確保獲得具有確定性的測試用例集.微軟公司研發的工具PICT[31]，通過固定隨機種子確保其獲得的測試用例集的確定性，但該工具現階段只能適用于2組合測試場景中.Bryce等人[32]提出的基于密度的DDA算法，以參數密度為參照排序各個參數的取值順序，因此其所獲得的測試用例集不僅規模較小，還兼具確定性，但該算法也僅能在2組合測試情形下適用.史亮等人[33]針對2組合測試問題提出了基于解空間樹的PSST算法，該算法能夠在某些輸入下得到具有最優覆蓋的測試用例集.Lei等人[34]提出的IPO是一種典型的2維擴展算法，該算法初始為被測軟件的前2個參數構建滿足全組合覆蓋的測試用例集，之后逐個添加參數并從水平和垂直2個維度對該測試用例集進行擴展，重復執行該二維擴展過程，直到所構建的測試用例集覆蓋全部參數的兩兩組合.IPO算法通過復用先前生成的測試用例集來構建新的測試用例集，這使得它在面對參數數量或者參數取值頻繁更新的被測軟件時總能保持較高的測試用例生成速度.Lei等人后來對僅滿足2組合覆蓋的IPO算法進行擴展獲得了可滿足N組合覆蓋的IPOG算法，同時基于該算法設計并實現了測試工具FireEye[35].本文實現了經典的貪心組合測試算法——IPO2組合算法，和正交實驗設計算法相比，可進一步降低生成的決策表規模，并確保2組合的全覆蓋.由于軟件失效大多數是發生在單點故障和2組合故障中，極少是由更多組合同時出現故障引起的，因此，對測試工具而言實現該算法具有實用價值.

3) 啟發式搜索算法.常見的啟發式搜索算法有模擬退火算法、禁忌搜索算法、遺傳算法等.與代數構造算法和貪心算法相比較，啟發式搜索算法在測試用例生成過程中引入了各式各樣的啟發式策略，規避了算法陷入局部最優的可能性，從而可能得到具有更優覆蓋的測試用例集合.然而，絕大多數基于啟發式策略的算法需要多次,同時變換多個覆蓋矩陣，導致測試用例生成時間過長[24].當前，此類算法仍處于研究階段.

本文并不僅局限于IPO2組合算法以及基于擬水平法和并列法的正交實驗設計算法的實現，工具提供了開放的接口，可以根據被測軟件的應用背景和測試需求，靈活選取適用的組合測試算法進行測試生成.

4.3 接口(API)測試

在軟件設計中采用接口的形式提供功能實現是一種普遍現象，單個接口中存在的缺陷在軟件執行時很容易四處擴散，進而導致大規模的軟件故障.因此，接口測試對于確保軟件的質量和可靠性至關重要.Shelton等人[36]借助測試自動化框架——Ballista對Win32 APIs在不同操作系統的各個版本上的執行健壯性和可靠性進行了測試評估.Hoffman等人[37]設計并實現了針對JavaAPI的測試工具Roast，該工具首先為接口生成邊界值，之后組合邊界值生成測試用例.在2個Java組件中執行測試用例的實驗結果證明了該工具具有可行性和有效性.然而，該工具也存在不足之處：1)沒有可視化界面，用戶體驗不友好；2)測試設計沒有考慮接口的語義信息，測試充分性不足.Jorgensen等人[38]提出將馬爾可夫模型和等價類劃分方法進行結合為API生成測試用例，并對Windows平臺上的C++APIs進行了實測.該方法的不足之處在于它是一種人工密集型的測試方法，測試成本過高.McCaffrey在文獻[39]中對.NET環境下的自動化API測試技術和原理進行了介紹.Kim等人[40]提出的REMI技術能夠預測識別出具有高風險性的API，進而在測試階段將更多的資源分配給此類API的測試.當面對有限的測試時間和測試資源，大量的被測API時，該項技術具有重要意義.

與上述大部分接口測試研究工作關注單個接口的測試不同，本文實現了對單個接口和多個組合接口的測試生成，并且基于ISC模型獲得了對接口更加充分的描述、采用劃分數據分區和組合測試算法在有效減少生成的測試用例數量的同時確保了測試覆蓋率.

5 總 結

本文針對現有服務接口測試方法中存在的接口模型表述能力有限、測試數據覆蓋率不夠充分、用例自動生成欠缺靈活性等問題提出了基于語義的服務接口測試方法.該方法以模型驅動自動化測試方法為基礎，借鑒基于語義的知識表達技術和基于契約的設計思想，解析服務相關的數據信息和操作行為，構建基于ISC的數據模型和服務模型用于描述單個服務；通過組合多個不同服務的測試用例集，定義服務間的依賴關系，構造基于ISC的計劃模型描述更為復雜的業務場景.同時，本文提出通用用例元模型的概念，用于多種測試用例代碼的自動生成，豐富了測試用例的表現形式.

基于ISC模型，本文設計并實現了一個自動化測試工具——AutoTest.實驗表明，AutoTest能夠快速為單個服務和組合服務生成大量測試用例，并且所生成的測試用例具有理想的覆蓋率.同時，所構建的ISC模型可被不斷復用，這為面向服務測試中最常進行的回歸測試提供了極大的便利.

[1]Hou Kejia, Bai Xiaoying, Lu Hao, et al. Web service test data generation using interface semantic contract[J]. Journal of Software, 2013, 24(9): 2020-2041 (in Chinese)(侯可佳, 白曉穎, 陸皓, 等. 基于接口語義契約的Web服務測試數據生成[J]. 軟件學報, 2013, 24(9): 2020-2041)

[2]Hou Kejia. Research on test automation for software as a service based on interface semantic contract[D]. Beijing: Tsinghua University, 2015 (in Chinese)(侯可佳. 基于接口語義契約的服務化軟件自動測試技術研究[D]. 北京: 清華大學, 2015)

[3]Tsai W T, Bai Xiaoying, Huang Yu. Software-as-a-service (SaaS): Perspectives and challenges[J]. Science China: Information Sciences, 2014, 57(5): 1-15

[4]Belli F, Endo A T, Linschulte M, et al. A holistic approach to model-based testing of Web service compositions[J]. Software: Practice and Experience, 2014, 44(2): 201-234

[5]Bai Xiaoying, Lu Hao, Zhang Yao, et al. Interface-Based automated testing for open software architecture[C] //Proc of the 35th Annual Computer Software and Applications Conf Workshops. Piscataway, NJ: IEEE, 2011: 149-154

[6]Bai Xiaoying, Hou Kejia, Lu Hao, et al. Semantic-Based test oracles[C] //Proc of the 35th Annual Computer Software and Applications Conf. Piscataway, NJ: IEEE, 2011: 640-649

[7]Lee Shufang, Bai Xiaoying, Chen Yinong. Automatic mutation testing and simulation on OWL-S specified Web services[C] //Proc of the 41st Annual Simulation Symp. Piscataway, NJ: IEEE, 2008: 149-156

[8]Dai Guilan, Bai Xiaoying, Wang Yongbo, et al. Contract-based testing for Web services[C] //Proc of the 31st Annual Int Computer Software and Applications Conf. Piscataway, NJ: IEEE, 2007: 517-526

[9]Bai Xiaoying, Lee Shufang, Tsai W T, et al. Ontology-based test modeling and partition testing of Web services[C] //Proc of the Int Conf on Web Services. Piscataway, NJ: IEEE, 2008: 465-472

[10]Dalal S R, Jain A, Karunanithi N, et al. Model-based testing in practice[C] //Proc of the 21st Int Conf on Software Engineering. New York: ACM, 1999: 285-294

[11]The Apache Software Foundation. The Apache Velocity Project[EB/OL]. [2014-07-01]. http: //velocity.apache.org/

[12]Canfora G, Di Penta M. Service-oriented architectures testing: A survey[M] //Software Engineering. Berlin: Springer, 2009: 78-105

[13]Bozkurt M, Harman M, Hassoun Y. Testing Web services: A survey, TR-10-01[R]. London: Department of Computer Science, King’s College, 2010

[14]Rusli H M, Puteh M, Ibrahim S, et al. A comparative evaluation of state-of-the-art Web service composition testing approaches[C] //Proc of the 6th Int Workshop on Automation of Software Test. New York: ACM, 2011: 29-35

[15]Bertolino A, Frantzen L, Polini A, et al. Audition of Web services for testing conformance to open specified protocols[C] //Proc of the Int Conf on Architecting Systems with Trustworthy Components. Berlin: Springer, 2006: 1-25

[16]Heckel R, Lohmann M. Towards contract-based testing of Web services[J]. Electronic Notes in Theoretical Computer Science, 2005, 116: 145-156

[17]Bruno M, Canfora G, Di Penta M, et al. Using test cases as contract to ensure service compliance across releases[C] //Proc of the Int Conf on Service-Oriented Computing. Berlin: Springer, 2005: 87-100

[18]Ni Yitao, Hou Shanshan, Zhang Lu, et al. Effective message-sequence generation for testing BPEL programs[J]. IEEE Trans on Services Computing, 2013, 6(1): 7-19

[19]Ilieva S, Manova D, Manova I, et al. An automated approach to robustness testing of BPEL orchestrations[C] //Proc of the Service Oriented System Engineering. Piscataway, NJ: IEEE, 2011: 193-203

[20]Bentakouk L, Poizat P, Za?di F. A formal framework for service orchestration testing based on symbolic transition systems[C] //Proc of the 21st IFIP WG 6.1 Int Conf on Testing of Software and Communication Systems and 9th Int FATES Workshop. Berlin: Springer, 2009: 16-32

[21]Mei Lijun, Chan W K, Tse T H. Data flow testing of service choreography[C] //Proc of the 7th Joint Meeting of the European Software Engineering Conf and the ACM SIGSOFT Symp on the Foundations of Software Engineering. New York: ACM, 2009: 151-160

[22]Wieczorek S, Kozyura V, Roth A, et al. Applying model checking to generate model-based integration tests from choreography models[C] //Proc of the 21st IFIP WG 6.1 Int Conf on Testing of Software and Communication Systems and 9th International FATES Workshop. Berlin: Springer, 2009: 179-194

[23]Kuhn D R, Wallace D R, Gallo A M. Software fault interactions and implications for software testing[J]. IEEE Trans on Software Engineering, 2004, 30(6): 418-421

[24]Yan Jun, Zhang Jian. Combinatorial testing: Principles and methods [J]. Journal of Software, 2009, 20(6): 1393-1405 (in Chinese)(嚴俊, 張健. 組合測試: 原理與方法[J]. 軟件學報, 2009, 20(6): 1393-1405)

[25]Chen Xiang, Gu Qing, Wang Xinping, et al. Research advances in interaction testing [J]. Computer Science, 2010(3): 1-5 (in Chinese)(陳翔, 顧慶, 王新平, 等. 組合測試研究進展[J]. 計算機科學, 2010 (3): 1-5)

[26]Mandl R. Orthogonal Latin squares: An application of experiment design to compiler testing[J]. Communications of the ACM, 1985, 28(10): 1054-1058

[27]Brownlie R, Prowse J, Phadke M S. Robust testing of AT&T PMX/StarMAIL using OATS[J]. AT&T Technical Journal, 1992, 71(3): 41-47

[28]Williams A W. Determination of test configurations for pair-wise interaction coverage[M] //Testing of Communicating Systems. New York: Springer, 2000: 59-74

[29]Cohen D M, Dalal S R, Fredman M L, et al. The AETG system: An approach to testing based on combinatorial design[J]. IEEE Trans on Software Engineering, 1997, 23(7): 437-444

[30]Tung Y W, Aldiwan W S. Automating test case generation for the new generation mission software system[C] //Proc of the Aerospace Conf. Piscataway, NJ: IEEE, 2000, 1: 431-437

[31]Czerwonka J. Pairwise testing in the real world: Practical extensions to test-case scenarios[EB/OL]. [2016-01-20]. https: //msdn.microsoft.com/en-us/library/cc150619.aspx

[32]Bryce R C, Colbourn C J. The density algorithm for pairwise interaction testing[J]. Software Testing Verification and Reliability, 2007, 17(3): 159-182

[33]Shi Liang, Nie Changhai, Xu Baowen. Pairwise test data generation based on solution space tree[J]. Chinese Journal of Computers, 2006, 29(6): 849-857 (in Chinese)(史亮, 聶長海, 徐寶文, 等. 基于解空間樹的組合測試數據生成[J]. 計算機學報, 2006, 29(6): 849-857)

[34]Lei Yu, Tai K C. In-parameter-order: A test generation strategy for pairwise testing[C] //Proc of the 3rd High-Assurance Systems Engineering Symp. Piscataway, NJ: IEEE, 1998: 254-261

[35]Lei Yu, Kacker R, Kuhn D R, et al. IPOG: A general strategy for t-way software testing[C] //Proc of the 14th Annual IEEE Int Conf and Workshops on the Engineering of Computer-Based Systems. Piscataway, NJ: IEEE, 2007: 549-556

[36]Shelton C P, Koopman P, DeVale K. Robustness testing of the Microsoft Win32 API[C] //Proc of the Int Conf on Dependable Systems and Networks. Piscataway, NJ: IEEE, 2000: 261-270

[37]Hoffman D, Strooper P. Tools and techniques for Java API testing[C] //Proc of the Software Engineering Conf. Piscataway, NJ: IEEE, 2000: 235-245

[38]Jorgensen A, Whittaker J A. An API testing method[C/OL] //Proc of the Int Conf on Software Testing Analysis & Review (STAREAST). [2016-01-20]. https: //www.cmcrossroads.com/sites/default/files/article/file/2014/Application%20Program %20Interface%20(API)%20Testing%20Method.pdf

[39]McCaffrey J D. API test automation in .NET[J]. MSDN Magazine, 2004, 19(11): 29-34

[40]Kim M, Nam J, Yeon J, et al. REMI: Defect prediction for efficient API testing[C] //Proc of the 10th Joint Meeting on Foundations of Software Engineering. New York: ACM, 2015: 990-993