專利名稱：一種無需預期的Web服務測試方法
技術領域：
本發(fā)明涉及一種面向Web服務的測試方法，尤其涉及一種無需預期的Web服務測試方法，屬于Web服務測試領域。
背景技術：
SOA(Service Oriented Architecture)定義了 hternet 環(huán)境下松散耦合的、基于標準的、面向服務的應用程序開發(fā)模式。其中，服務提供者(Service Provider)通過 hternet發(fā)布服務的接口描述；服務代理(Service Registry)查詢符合需求的服務；服務使用者(Service Consumer)使用符合需求的服務。Web服務是SOA基于Web的實現(xiàn)，是一個平臺獨立的、松耦合的、自包含的、可編程的應用程序，Web服務的描述、訪問、檢索與發(fā)布基于標準XML(可擴展標記語言，全稱為Extensible Markup Language)技術以及一系列的Web技術標準。這些技術及標準有效地屏蔽了運行環(huán)境的異構(gòu)性，使得Web服務可以直接部署和運行于hternet之上。由于單個服務往往無法滿足實際需求，需要將多個服務協(xié)調(diào)與組織起來以支持某個業(yè)務過程，將多個服務組合起來形成復合服務的過程稱為服務組合。近年來，服務組合正成為hternet環(huán)境下應用程序的主流開發(fā)范型，采用上述服務組合構(gòu)造而成的軟件系統(tǒng)通常稱為SOA軟件系統(tǒng)。與傳統(tǒng)的軟件相比，SOA軟件系統(tǒng)具有如下幾個主要特點更高的松散程度S0A 軟件中參與組合的Web服務是一個更加獨立的計算單元、可以借助hternet直接進行訪問，Web服務之間的耦合度更低。定義與實現(xiàn)的徹底分離Web服務通常由定義與實現(xiàn)兩部分組成，定義與實現(xiàn)可以分散在不同文件中；Web服務可以采用不同的編程語言實現(xiàn)，而且 Web服務的實現(xiàn)與定義的綁定可以延遲到運行時刻。支持服務的發(fā)布、注冊和發(fā)現(xiàn)Web服務的開發(fā)與使用比任何傳統(tǒng)軟件更加獨立和開放。上述特點決定了 SOA軟件系統(tǒng)是一個松耦合系統(tǒng)，當這樣的系統(tǒng)實現(xiàn)一些非常重要的業(yè)務過程，如電子支付業(yè)務系統(tǒng)、決策與控制系統(tǒng)等，如何保證這類系統(tǒng)的正確性和可靠性，是SOA軟件開發(fā)必須解決的一個重要問題。軟件測試是廣泛使用的一種保證軟件正確性和可靠性的方法。由于Web服務的定義與實現(xiàn)的徹底分離，參與組合的Web服務可能來自不同的管理域，服務使用者無法訪問服務實現(xiàn)源代碼，白盒軟件測試方法不再適用于SOA軟件；由于Web服務面向動態(tài)、開放的環(huán)境，服務開發(fā)者無法預計服務的所有使用情況，因此只能進行有限的覆蓋測試，無法保證這些Web服務以松散耦合的方式組合成一個動態(tài)的分布式系統(tǒng)時還能可靠地工作。SOA軟件的新特點，使得SOA軟件的測試面臨新的問題與挑戰(zhàn)。圍繞著Web服務測試的已有研究工作側(cè)重研究Web服務測試數(shù)據(jù)的生成與選擇， 并且假設每個測試用例的期望輸出是可知的。然而，預期(Oracle)問題是長期困擾軟件測試的基本難題之一。所謂預期問題，是指在某些情況下測試人員無法確定程序執(zhí)行的期望結(jié)果或者很難構(gòu)造預期輸出結(jié)果。由于Web服務發(fā)布的動態(tài)性、運行的不確定性與不可控性(無法訪問服務的實現(xiàn)細節(jié))，Web服務的可測試性差，對任意給定的輸入確定相應的輸出是否正確更加困難。換言之，測試SOA軟件時，預期問題更加突出，當預期不存在時，已有測試方法用于測試面向Web服務的SOA軟件系統(tǒng)時其有效性將受到很大限制。針對Web服務測試的預期(Oracle)問題，目前不存在有效的解決方案。一種方法是，基于多版本編程思想假設有規(guī)格說明相同但實現(xiàn)不同的一組Web服務，采用一種表決算法將多數(shù)Web服務的輸出作為預期輸出。該方法無法應用于單個Web服務的測試，而且通過表決途徑產(chǎn)生的預期并不可靠。另一種方法是蛻變測試方法，蛻變測試方法通過檢查程序的多個執(zhí)行結(jié)果之間的關系來測定程序，因為無需構(gòu)造預期輸出，可有效解決預期問題。 現(xiàn)有針對SOA的蛻變測試方法，首先根據(jù)離線時通過測試的測試用例作為原始測試用例， 然后基于該原始測試用例構(gòu)造衍生測試用例，最后將該原始測試用例和衍生測試用例進行在線測試，判斷輸出結(jié)果是否滿足一定的蛻變關系，如不滿足則可斷定有錯誤；又因為原有的原始測試用例是通過測試的，所以當蛻變測試發(fā)現(xiàn)錯誤時，該錯誤是在在線模式下引入的。現(xiàn)有針對SOA的蛻變測試方法中原始測試用例由離線時通過測試的測試用例生成，在判斷測試用例是否通過測試時實際上使用了現(xiàn)有需要預期的方法，即通過判斷上述測試用例的輸出結(jié)果是否和預期一致來判斷測試用例是否通過測試；因此，現(xiàn)有針對SOA的蛻變測試方法包括離線測試時需要預期的方法和在線測試時無需預期的蛻變測試方法，是一種不徹底的無需預期的蛻變測試方法。

發(fā)明內(nèi)容
本發(fā)明要解決的技術問題是提供一種徹底的無需預期的Web服務測試方法。為解決上述技術問題，本發(fā)明采用如下技術方案本發(fā)明提供的無需預期的Web服務測試方法，包括如下步驟(1)、構(gòu)造基于Web服務描述的蛻變關系，所述蛻變關系為輸入關系R與輸出關系 Rf構(gòu)成的二元組，其中，所述輸入關系R定義了原始測試用例與衍生測試用例之間的關系， 所述輸出關系Rf定義了所述原始測試用例對應的輸出與所述衍生測試用例對應的輸出之間的關系；O)、生成衍生測試用例集合，所述衍生測試用例由原始測試用例基于所述輸入關系R生成，所述原始測試用例和所述衍生測試用例統(tǒng)稱測試用例；(3)、執(zhí)行客戶端驅(qū)動的所述測試用例，獲取Web服務操作執(zhí)行完畢后返回的執(zhí)行
結(jié)果；(4)、判定所述執(zhí)行結(jié)果是否滿足所述輸出關系Rf，如果不滿足，則判定所述Web 服務中存在缺陷。所述步驟(1)中基于Web服務描述的蛻變關系構(gòu)造的具體步驟為首先，分析Web 服務的描述，獲取W^eb服務的蛻變屬性規(guī)格說明(Metamorphic property specification), 然后再確定蛻變關系的集合。所述Web服務的描述包括蛻變屬性功能規(guī)格說明與接口信息；其中，所述接口信息包括名字、類型、消息、端口類型、綁定、端口與服務，所述端口類型包括一組操作，每個所述操作弓I用一個輸入消息與輸出消息。所述蛻變屬性包括多條蛻變關系。所述測試用例的格式依據(jù)所述接口信息確定。
所述原始測試用例由已有的測試用例生成方法產(chǎn)生。已有的所述測試用例生成方法包括特殊值選取方法、隨機值選取方法、等價類劃分方法和迭代測試方法。所述接口信息包括操作、輸入消息與輸出消息，原始測試用例與衍生測試用例的格式由輸入消息確定。所述步驟(3)中的客戶端驅(qū)動的Web服務測試執(zhí)行的具體方法是，開發(fā)Web服務的客戶端程序，將原始測試用例和衍生測試用例作為輸入消息運行被測Web服務，獲取相應的輸出消息，得到測試結(jié)果。


為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。圖1為本發(fā)明一個優(yōu)選實施例的原理圖。
具體實施例方式下面將結(jié)合本發(fā)明的附圖，對本發(fā)明的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例， 本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。如圖1所示，本發(fā)明提供的一個優(yōu)選實施例的原理圖，以下結(jié)合附圖和具體實施例對本發(fā)明進行詳細說明?！N無需預期的Web服務測試方法，如圖1所示，包括如下步驟(1)、基于Web服務描述的蛻變關系(Metamorphic Relation)構(gòu)造，所述蛻變關系為輸入關系R與輸出關系Rf構(gòu)成的二元組，其中，所述輸入關系R定義了原始測試用例與衍生測試用例之間的關系，所述輸出關系Rf定義了所述原始測試用例對應的輸出與所述衍生測試用例對應的輸出之間的關系；O)、基于蛻變關系的衍生測試用例集合生成，所述衍生測試用例由原始測試用例基于所述輸入關系R生成，所述原始測試用例和所述衍生測試用例統(tǒng)稱測試用例；(3)、客戶端驅(qū)動的Web服務測試執(zhí)行，獲取Web服務操作執(zhí)行完畢后返回的執(zhí)行
結(jié)果；0)、基于蛻變關系的測試結(jié)果判定，判定所述執(zhí)行結(jié)果是否滿足所述輸出關系 Rf，如果不滿足，則判定所述Web服務中存在缺陷。具體說明如下基于Web服務的描述，特別是Web服務的蛻變屬性功能規(guī)格說明，可以獲取蛻變屬性。所述蛻變屬性與Web服務實現(xiàn)的具體功能有關，包括多條蛻變關系。因此，蛻變關系的選取應采用實例分析的方法。在面向Web服務的SOA上下文中，由于無法訪問Web服務實現(xiàn)的源代碼，只能依據(jù)Web服務的功能規(guī)格說明的信息構(gòu)造蛻變關系。蛻變關系的選取影
5響蛻變測試的效率，存在一些選擇蛻變關系的指導方針，包括選取的蛻變關系(1)應盡可能覆蓋核心功能；( 盡可能使原始測試用例和衍生測試用例的執(zhí)行結(jié)果不滿足相應的蛻變關系的情形多出現(xiàn)，可以針對易于出錯的地方進行蛻變測試，比如在處理邊界上依據(jù)蛻變關系設計測試用例，這樣可以增強測試的效率。由于蛻變關系反映了當不同的輸入滿足某種關系R時、對應的輸出也應滿足某種關系Rf的特性因此一個蛻變關系可以分解為輸入關系R與輸出關系Rf構(gòu)成的二元組。其中，輸入關系R定義了原始測試用例與衍生測試用例之間的關系，輸出關系Rf定義了原始測試用例對應的輸出與衍生測試用例對應的輸出之間的關系。所述原始測試用例與所述衍生測試用例統(tǒng)稱為測試用例。運用上述蛻變關系獲取原則分析Web服務的描述，可以得到被測Web服務的一組蛻變關系{MR1，...，MRn}。針對每個蛻變關系MRi，可以產(chǎn)生一組測試用例集合。首先， 需要確定測試用例的格式。Web服務描述的接口信息通常由Web服務描述語言WSDL(Web Services Description Language的縮寫)提供，與測試相關的信息主要包括Web服務的操作、與每個操作相關的輸入消息與輸出消息。其中，原始測試用例與衍生測試用例的格式相同，由輸入消息確定。其次，對于原始測試用例而言，可以采用已有測試用例生成方法，如隨機值選取方法，等價類劃分方法等產(chǎn)生。所述原始測試用例可以在所述蛻變關系構(gòu)造前或者所述蛻變關系構(gòu)造后由現(xiàn)有測試用例生成方法單獨產(chǎn)生。原始測試用例集合的大小取決于測試預算或測試進度。最后，針對每個原始測試用例，依據(jù)所述蛻變關系MRi中的所述輸入關系Ri，改動原始測試用例得到相應的衍生測試用例。通過上述步驟產(chǎn)生的測試用例集合可以存放在一個獨立的文件中，也可以存放到被測Web服務的WSDL文件中。經(jīng)過上述步驟后，已經(jīng)生成了蛻變測試用例集合。為了測試Web服務，首先需要將被測Web部署到服務容器中，由容器負責管理其生命周期。然后按照WSDL描述的接口格式調(diào)用被測Web服務的操作。一般說來，Web服務實現(xiàn)一些業(yè)務邏輯，通常并不提供界面， 為此需要開發(fā)Web服務的客戶端程序(Client)。該程序?qū)⑸鲜霾襟E得到的測試用例(包括原始測試用例集合與衍生測試用例集合)作為輸入消息調(diào)用Web服務，然后等待Web服務操作執(zhí)行完畢后返回的輸出消息。測試實施時，可以采用人工的方式，也可以采用自動的方式。采用人工的測試方式時，測試人員通過客戶端程序逐個輸入測試用例，觀察測試結(jié)果； 采用自動的測試方式時，由程序自動地從測試用例集合的文件中提取測試用例，傳遞給客戶端程序，然后接受并存儲客戶端返回的測試結(jié)果。如果存在多條蛻變關系時，測試的組織可采用如下兩種方式(1)首先執(zhí)行一個原始測試用例，然后逐個執(zhí)行依據(jù)不同蛻變關系產(chǎn)生的衍生測試用例，執(zhí)行完全部測試用例后；選擇另外一個原始測試用例，重復上述過程；( 首先選擇一個蛻變關系，然后逐個執(zhí)行原始測試用例與衍生測試用例，執(zhí)行完全部測試用例后；再選擇另外一個蛻變關系，重復上述過程。借助上述步驟后，執(zhí)行測試用例集合中的所有測試用例，可以得到與測試用例相關的輸出結(jié)果。輸出結(jié)果的格式由操作相關的輸出消息確定。為了判定被測Web服務中是否存在缺陷，并不需要知道原始測試用例或衍生測試用例的正確輸出，而是比較原始測試用例與衍生測試用例的輸出結(jié)果是否滿足用于產(chǎn)生測試用例的蛻變關系。如果不滿足，則表明被測的Web服務中存在缺陷?？梢?，本發(fā)明的Web服務測試方法在測試用例的構(gòu)造階段和在線測試階段都無需預期，是一個徹底的無需預期的蛻變測試方法以下結(jié)合圖1，以測試采用Web服務實現(xiàn)的通用ATM (Automatic Teller Machine) 系統(tǒng)中轉(zhuǎn)帳功能為例，對本發(fā)明的技術方案進行詳細說明。ATM是由計算機控制的持卡人自我服務型的金融專用設備。通用ATM系統(tǒng)可適應不同銀行的需求，便于各銀行的業(yè)務擴展，支持的主要功能有用戶存款、取款、轉(zhuǎn)賬(包含跨行、異地)、修改密碼等。ATM系統(tǒng)支持的主要業(yè)務涉及財富的轉(zhuǎn)移，因此可靠性要求高。 以轉(zhuǎn)帳功能為例，如果系統(tǒng)實現(xiàn)中存在缺陷，則會直接造成用戶的經(jīng)濟損失。另外，轉(zhuǎn)賬功能在電子商務系統(tǒng)中廣泛使用，實現(xiàn)轉(zhuǎn)帳功能的Web服務可能來自第三方開發(fā)組織，如某個銀行、金融機構(gòu)、或軟件公司。在測試這樣的一個Web服務時，無法訪問Web服務實現(xiàn)的源代碼，因此白盒軟件測試方法不再適用。此外，由于Web服務發(fā)布的不確定性與運行的不可控性，Web服務的可測試性差，針對給定的輸入確定預期輸出更加困難。首先，依據(jù)通用ATM系統(tǒng)的規(guī)格說明分析蛻變屬性，獲取蛻變關系集合。不同銀行對轉(zhuǎn)帳業(yè)務有不同的限制與收費標準。例如，中國農(nóng)業(yè)銀行規(guī)定每次轉(zhuǎn)帳的最高額度為 50000元，還規(guī)定不同類型的轉(zhuǎn)帳業(yè)務有不同的收費標準(1)同城非跨行不收取手續(xù)費； (2)同城跨行手續(xù)費為轉(zhuǎn)賬金額的0. 5%，最低1元，最高50元；(3)異地不跨行手續(xù)費為轉(zhuǎn)賬金額的0. 5%，最低1元，最高50元；(4)異地跨行手續(xù)費為轉(zhuǎn)賬金額的1 %，最低1 元，最高50元。依據(jù)這些業(yè)務規(guī)則的描述，可以得知相應的系統(tǒng)實現(xiàn)中存在一些蛻變關系。 例如，對于同樣的轉(zhuǎn)帳額度，異地跨行轉(zhuǎn)帳收取的手續(xù)費一定大于等于其它三類轉(zhuǎn)帳類型； 對于同樣的轉(zhuǎn)帳額度，異地不跨行與同城跨行兩種不同類型的轉(zhuǎn)帳業(yè)務收取的手續(xù)費一定相同。采用Web服務實現(xiàn)通用ATM系統(tǒng)時，轉(zhuǎn)帳功能通常由一個接口實現(xiàn)。采用WSDL描述的轉(zhuǎn)帳接口如下
<wsdl: operation name="transfer"〉 <wsdl: input message="tns: transferRequest"X/wsdl: input〉 <wsdl: output message=" tns: transferResponse"X/wsdl: output〉 </wsdl: operation><xsd:element name="transferRequest“>
<xsd:sequence〉
<xsd: element name="from" type="xsd: string"X/xsd: element〉 <xsd: element name="to" type="xsd: string"X/xsd: element〉 <xsd: element name="amount" type="xsd: int"></xsd: element〉 <xsd: element name="mode" type="xsd: int"></xsd: element〉 </xsd:sequence〉 </xsd:complexType〉 </xsd:element〉 <xsd:element name="transferResponse" type="xsd: string"> </xsd: element〉其中，‘‘operation”定義了接口的名稱為‘‘transfer”，該操作的輸入消息為 “transf erRequest輸出消息為"transferResponse，，。輸入消；^ “ transfer Re quest “ 由轉(zhuǎn)出帳戶“ from”、轉(zhuǎn)入帳戶“ to ”、金額“amount ”和轉(zhuǎn)帳類型"mode ”組成。輸出消息 “transferResponse，，顯示帳戶的余額，表示為字符串“ string”。通過分析操作的接口描述，可以確定測試用例的數(shù)據(jù)格式。為了表達方便，轉(zhuǎn)賬接口的輸入消息用四元組<A，B, P，M>表示。其中，Α:表示轉(zhuǎn)出賬戶的賬號，用10位數(shù)字表示；B 表示轉(zhuǎn)入賬戶的賬號，用10位數(shù)字表示；P 表示A與B賬戶跨行與異地的情況，P = 0表示同城不跨行，P = 1表示同城跨行，P = 2表示異地不跨行，P = 3表示異地跨行；M 表示轉(zhuǎn)賬金額，單位為元，而且必須為整數(shù)。轉(zhuǎn)賬接口的輸出用二元組<ΔΑ，ΔΒ>表示，其中ΔΑ:表示轉(zhuǎn)賬前轉(zhuǎn)出賬戶的余額與轉(zhuǎn)賬后轉(zhuǎn)出賬戶的余額的差；ΔΒ:表示轉(zhuǎn)賬后轉(zhuǎn)入賬戶的余額與轉(zhuǎn)賬前轉(zhuǎn)入帳戶的余額的差。程序?qū)崿F(xiàn)正確的情況下，這樣的設計可以使得ΔΑ > 0且ΔΒ > 0。為了表述方便，將原始測試用例及其輸出表示為<Α，Β，Ρ，Μ>和<ΔΑ，ΔΒ>，衍生測試用例及其輸出表示為<Α' ,B' ,P' ,M' <ΔΑ' , ΔΒ' >。結(jié)合測試用例與輸出的格式，轉(zhuǎn)帳接口的一組蛻變關系描述如下蛻變關系1 若輸入滿足M' = 2Μ，則輸出滿足ΔΑ < ΔΑ' ^ 2ΔΑ ΔΒ'= 2ΔΒ。
蛻變關系2若輸入滿足P=1且P' = 2，則輸出滿足ΔΑ'-ΔΒ'=ΔΑ-ΔΒ。
蛻變關系3若輸入滿足P=0且P' Φ 0，則輸出滿足Δ A'-ΔΒ'> Ak-ΔΒ。
蛻變關系4若輸入滿足P=3且P' Φ 3，則輸出滿足Δ A'-ΔΒ'^ ΔΑ-ΔΒ。
蛻變關系5若輸入滿足M'>Μ，則輸出滿足ΔΑ' > ΔΑ且ΔΒ'> ΔΒ。 蛻變關系6:若輸入滿足A' =B且B' = A (即A、B交換)，則輸出滿足 ΔΑ ^ AB'。然后，產(chǎn)生測試用例集合，首先產(chǎn)生原始測試用例集合；然后依據(jù)蛻變關系再由原始測試用例集合產(chǎn)生衍生測試用例集合。關于原始測試用例集合，可以采用已有的測試用例生成方法產(chǎn)生，比如特殊值選取方法、隨機值選取方法和迭代測試方法等。由于特殊值選取方法和隨機值選取方法的生成效率較高，容易獲得，所以經(jīng)常使用它們產(chǎn)生原始測試用例。關于衍生測試用例集合，必須依據(jù)蛻變關系、對原始測試用例修改獲得。例如，采用隨機值選取得到測試用例Tl = (1000000000，2000000000，3，5000)，該測試用例表示轉(zhuǎn)出賬號為1000000000，轉(zhuǎn)入賬號為2000000000，轉(zhuǎn)賬金額為5000元，轉(zhuǎn)賬方式為異地且跨行。假設采用蛻變關系1 (即輸入滿足M' = 2M)進行測試，那么修改原始測試用例Tl可得到衍生測試用例Tl ‘ = (1000000000，2000000000，3，10000)。假設采用蛻變關系6 (即輸入滿足A' =B且B' =A)進行測試，那么修改原始測試用例Tl可得到衍生測試用例Tl'= (2000000000,1000000000，3，5000)。采用上述步驟，針對一條蛻變關系可以得到一對測試用例，即一個原始測試用例和一個衍生測試用例。為了盡可能多地檢測Web服務實現(xiàn)中潛藏的缺陷，需要產(chǎn)生多個測試用例。測試用例的數(shù)量取決于允許的測試成本與進度如果測試預算成本高、測試時間長，那么產(chǎn)生的測試用例數(shù)量可以多一些；否則應該少一些。另外，為了覆蓋被測Web服務的主要功能或行為，應選取多個蛻變關系進行測試。最終，依據(jù)不同的蛻變關系得到多組測試用例集合。為了測試轉(zhuǎn)帳接口的實現(xiàn)，必須將被測的Web服務部署到服務容器(如Tomcat) 中；此外，還需開發(fā)測試客戶端程序(如JSP界面)。通過JSP界面，將上述步驟得到的測試用例(包括原始測試用例集合與衍生測試用例集合)作為輸入消息調(diào)用Web服務，然后等待Web服務操作執(zhí)行完畢后返回的輸出消息。為了得到ΔΑ，只需在轉(zhuǎn)帳事務前(后)查詢轉(zhuǎn)出帳號A的余額。類似地，通過在轉(zhuǎn)帳事務后(前)查詢轉(zhuǎn)入帳號B的余額可以得到 ΔΒ。最后，通過判定測試輸出是否滿足蛻變關系，確定被測的Web服務中是否存在缺陷。測試結(jié)果的判定并不需要知道原始測試用例或衍生測試用例的正確輸出，而是比較原始測試用例與衍生測試用例的輸出結(jié)果是否滿足用于產(chǎn)生測試用例的蛻變關系。例如，假設采用蛻變關系1(即輸入滿足M' = 2M)進行測試，針對每一對原始測試用例與衍生測試用例的輸出，判定輸出是否滿足ΔΑ < ΔΑ' <2ΔΑ且ΔΒ' =2ΔΒ。如果存在某一對原始測試用例與衍生測試用例的輸出不滿足上述蛻變關系，則表明轉(zhuǎn)帳接口中存在缺陷。本發(fā)明針對Web服務可測試性差的特點，提出了預期不存在情形下一種面向Web 服務的有效測試方法。本發(fā)明利用被測試軟件中潛藏的蛻變屬性構(gòu)造蛻變關系，依據(jù)蛻變關系產(chǎn)生測試用例集合，客戶端運行測試用例后通過判定測試輸出是否滿足蛻變關系，確定被測的Web服務中是否存在缺陷。本發(fā)明提供了蛻變關系構(gòu)造與表示方法、基于蛻變關
9系的測試用例生成技術、客戶端驅(qū)動的Web服務測試執(zhí)行技術、基于蛻變關系的測試結(jié)果判定技術，是一個完整的、無需預期的Web服務測試方案。本發(fā)明可有效緩解Web服務測試時廣泛存在的預期問題，在不存在預期情形下仍能對Web服務進行有效測試，為增強Web服務的可靠性提供了有效的測試手段。作為本發(fā)明的另一個實施例，本發(fā)明的蛻變測試方法可以與面向Web服務的已有測試方法結(jié)合使用，提高已有測試方法在預期不存在情形下的適用性與有效性，對于保證大量采用Web服務實現(xiàn)的SOA軟件的可靠性具有十分重要的意義。以上所述，僅為本發(fā)明的具體實施方式
，但本發(fā)明的保護范圍并不局限于此，任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內(nèi)，可輕易想到變化或替換，都應涵蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范圍應以所述權利要求的保護范圍為準。
權利要求
1.一種無需預期的Web服務測試方法，其特征在于包括如下步驟(1)、構(gòu)造基于Web服務描述的蛻變關系，所述蛻變關系為輸入關系R與輸出關系Rf構(gòu)成的二元組，其中，所述輸入關系R定義了原始測試用例與衍生測試用例之間的關系，所述輸出關系Rf定義了所述原始測試用例對應的輸出與所述衍生測試用例對應的輸出之間的關系；(2)、生成衍生測試用例集合，所述衍生測試用例由原始測試用例基于所述輸入關系R 生成，所述原始測試用例和所述衍生測試用例統(tǒng)稱測試用例；(3)、執(zhí)行客戶端驅(qū)動的所述測試用例，獲取Web服務操作執(zhí)行完畢后返回的執(zhí)行結(jié)果；(4)、判定所述執(zhí)行結(jié)果是否滿足所述輸出關系Rf，如果不滿足，則判定所述Web服務中存在缺陷。
2.根據(jù)權利要求1所述的方法，其特征在于所述步驟(1)中基于Web服務描述的蛻變關系構(gòu)造的具體步驟為首先，分析Web服務的描述，獲取Web服務的蛻變屬性規(guī)格說明 (Metamorphic property specification),
3.根據(jù)權利要求2所述的方法，其特征在于所述Web服務的描述包括蛻變屬性功能規(guī)格說明與接口信息；其中，所述接口信息包括名字、類型、消息、端口類型、綁定、端口與服務，所述端口類型包括一組操作，每個所述操作引用一個輸入消息與輸出消息。
4.根據(jù)權利要求3所述的方法，其特征在于所述蛻變屬性包括多條蛻變關系。
5.根據(jù)權利要求4所述的方法，其特征在于所述測試用例的格式依據(jù)所述接口信息確定。
6.根據(jù)權利要求5所述的方法，其特征在于所述原始測試用例由已有的測試用例生成方法產(chǎn)生。
7.根據(jù)權利要求6所述的方法，其特征在于已有的所述測試用例生成方法包括特殊值選取方法、隨機值選取方法、等價類劃分方法和迭代測試方法。
8.根據(jù)權利要求7所述的方法，其特征在于所述接口信息包括操作、輸入消息與輸出消息，原始測試用例與衍生測試用例的格式由所述輸入消息確定。
9.根據(jù)權利要求1所述的方法，其特征在于所述步驟(3)中的客戶端驅(qū)動的Web服務測試執(zhí)行的具體方法是，開發(fā)Web服務的客戶端程序，將原始測試用例和衍生測試用例作為輸入消息運行被測Web服務，獲取相應的輸出消息，得到測試結(jié)果。
全文摘要
本發(fā)明公開了一種無需預期的Web服務測試方法，包括如下步驟(1)構(gòu)造基于Web服務描述的蛻變關系；(2)生成衍生測試用例集合，衍生測試用例集合由原始測試用例集合基于所述輸入關系R生成；原始測試用例集合和衍生測試用例集合構(gòu)成測試用例集合；(3)執(zhí)行客戶端驅(qū)動的測試用例，獲取Web服務的執(zhí)行結(jié)果；(4)判定執(zhí)行結(jié)果是否滿足輸出關系Rf，如果不滿足，則判定所述Web服務中存在缺陷。于是，通過比較原始測試用例與衍生測試用例的輸出結(jié)果是否滿足用于產(chǎn)生測試用例的蛻變關系，即可判斷Web服務中是否存在缺陷，提供了一種無需預期仍能對Web服務進行有效測試的方法，能有效增強Web服務的可靠性。
文檔編號H04L12/26GK102170378SQ20111010942
公開日2011年8月31日 申請日期2011年4月22日 優(yōu)先權日2011年4月22日
發(fā)明者孫昌愛 申請人:北京科技大學