專利名稱：Web服務(wù)業(yè)務(wù)流程的單元測試的方法和設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及計算機程序的測試，更具體地，涉及在Web服務(wù)業(yè)務(wù)流程編程語言中規(guī)定的自動化業(yè)務(wù)流程的單元測試的方法和設(shè)備。
背景技術(shù)：
在過去的十年中，商業(yè)界和政府部門越來越關(guān)注利用IT技術(shù)來對業(yè)務(wù)流程(business process)進行描述、自動化和管理。業(yè)務(wù)流程是一個組織內(nèi)業(yè)務(wù)價值的基本單元。
Web服務(wù)業(yè)務(wù)流程執(zhí)行語言(BPEL4WS，簡稱為BPEL)是用于Web服務(wù)合成的業(yè)務(wù)流程編程語言的一個例子。其他這類編程語言包括BPMN，WfXML，XPDL，XLANG，WSFL等。這些語言均通過合成Web服務(wù)來描述業(yè)務(wù)流程。一般來說，一個業(yè)務(wù)流程是關(guān)于該流程與其伙伴流程(partner process，PP)的交互來定義的。一個伙伴流程可以向該流程提供服務(wù)，從該流程請求服務(wù)，或者參與與該流程的雙向交互。
任務(wù)關(guān)鍵(mission-critical)的業(yè)務(wù)解決方案需要綜合的測試，以確保其準確可靠的運行。一種常見的策略是對該解決方案進行幾個階段的測試，如單元測試、集成測試和系統(tǒng)測試。單元測試驗證單個模塊(類、組件、流程等)的功能。集成測試驗證幾個模塊的共同的功能。系統(tǒng)測試則通過穿越用戶接口(如果有的話)將整個解決方案作為一個黑盒來測試。系統(tǒng)測試是很常見的，因為它幾乎是產(chǎn)品發(fā)布前防止致命錯誤的最后保障，并且在傳統(tǒng)的軟件開發(fā)中是強制性的。通常，越晚發(fā)現(xiàn)錯誤，則對它進行修補的費用越高。另一方面，可以自動進行單元測試，從而使得回歸(regression)測試可行并且有效，確保了新增加的功能不會影響舊的部分，并且有助于控制質(zhì)量風(fēng)險。因此，近年來在軟件工程實踐中越來越重視單元測試。JUnit是這種趨勢中最為著名的實例。圍繞/基于JUnit及其原理，已經(jīng)針對Java，EJB，Servlet，.Net和其他類型的編程技術(shù)提出并實現(xiàn)了很多單元測試框架和工具。單元測試工具已經(jīng)成為集成開發(fā)環(huán)境(IDE)的必不可少的部分，并作為提高產(chǎn)率和質(zhì)量的手段受到程序開發(fā)人員的歡迎。
業(yè)務(wù)流程單元測試將單個的流程作為被測試單元(unit under test)，并通過將該流程與其伙伴流程隔離來對該流程的內(nèi)部邏輯進行徹底的測試。其中，對伙伴流程進行仿真而不采用真實的伙伴流程，原因是1)在單元測試階段，一些獨立的伙伴流程仍在開發(fā)中因而不可用；2)一些伙伴流程由其他企業(yè)開發(fā)(有可能是在完全不同的開發(fā)環(huán)境中開發(fā))和管理，通常不能獲得這些伙伴流程的源代碼和相關(guān)的軟件模塊并建立用于測試的運行環(huán)境；3)即使已經(jīng)具有了某些/全部伙伴流程，仿真的伙伴流程仍然是優(yōu)選的，因為它們可以產(chǎn)生更多的交互場景而花費較小的精力，因為對被測試流程的應(yīng)答是虛構(gòu)的而不是按照真實的業(yè)務(wù)邏輯-調(diào)用其他業(yè)務(wù)流程、訪問數(shù)據(jù)庫或與人交互-來計算的。
在當(dāng)前的產(chǎn)業(yè)實踐中，業(yè)務(wù)流程測試集中在系統(tǒng)測試，例如IBM公司的Rational Functional Tester；而單元測試尚未引起任何注意。業(yè)務(wù)流程單元測試方法和工具的缺乏，造成了以下缺點1)流程很少被孤立地測試，由于它們是互相依賴的，因而很難在一個流程的伙伴流程沒有準備好的時候運行該流程；2)在通過對其伙伴流程進行仿真來孤立地測試一個流程的極少的情況下，這些伙伴流程是以特定、主觀和不完整的方式編寫的，為了不同的測試目的和測試例，必須重新綁定服務(wù)并重新啟動服務(wù)器(這是非常耗時的任務(wù))；另外，將測試邏輯分布到多個流程中不利于簡單的測試維護和使用；3)測試執(zhí)行是人工完成的而沒有任何工具支持，這不利于實現(xiàn)自動回歸測試。
現(xiàn)有的單元測試框架是為面向?qū)ο?OO)的編程語言設(shè)計的，不能直接應(yīng)用于測試業(yè)務(wù)流程，因為后者是面向過程的而不涉及類的概念。另外，并發(fā)和同步是業(yè)務(wù)流程測試的基本要求，而在現(xiàn)有的框架中不能得到支持。為了實現(xiàn)業(yè)務(wù)流程單元測試，需要對現(xiàn)有的框架進行修改和擴展。
盡管前面所述的那些業(yè)務(wù)流程編程語言是Web服務(wù)編排語言，Web服務(wù)測試，例如Optimyz公司的WebServiceTester，Parasoft公司的SOAPtest方法和工具總的來說不適用于業(yè)務(wù)流程的測試。Web服務(wù)測試將被測試單元作為一個黑盒來對待，僅需要利用其接口定義，而不考慮其內(nèi)部實現(xiàn)方式。在Web服務(wù)測試中，測試例對客戶進行仿真，發(fā)送請求消息并檢查響應(yīng)消息。但是，在業(yè)務(wù)流程測試中，這種在測試例和被測試單元之間的簡單的消息交換是不夠的。業(yè)務(wù)流程單元測試將被測試單元作為一個白盒來對待，其中的內(nèi)部實現(xiàn)邏輯是需要使用的。一個業(yè)務(wù)流程通常有很多伙伴，該流程按照業(yè)務(wù)邏輯與這些伙伴多次交互。為了測試這樣一個流程，必須對所有伙伴進行仿真，并且應(yīng)用一個能夠規(guī)定流程間的通用的復(fù)雜交互的完整的測試邏輯。因此，業(yè)務(wù)流程單元測試例會更加復(fù)雜，通常由被測試單元的多個被仿真的伙伴流程構(gòu)成。

發(fā)明內(nèi)容
本發(fā)明的目的是克服現(xiàn)有技術(shù)中的缺陷，提供一種以規(guī)范、統(tǒng)一、高效的方式對Web服務(wù)業(yè)務(wù)流程編程語言中規(guī)定的業(yè)務(wù)流程進行單元測試的方法。
本發(fā)明的另一個目的是在Web服務(wù)業(yè)務(wù)流程的單元測試中簡化測試例的編寫。
本發(fā)明的另一個目的是提供一種Web服務(wù)業(yè)務(wù)流程的單元測試的設(shè)備和計算機程序產(chǎn)品。
為實現(xiàn)上述目的，根據(jù)本發(fā)明的一個方面，提供一種Web服務(wù)業(yè)務(wù)流程的單元測試方法，該方法包括以下步驟將被測試流程及其伙伴流程的Web服務(wù)描述語言(WSDL)元素映射為面向?qū)ο蟮恼Z言(OO)中的等效元素；和基于面向?qū)ο蟮膯卧獪y試框架對所述被測試流程進行測試。
在上述方法中的映射步驟中，將被測試流程及其伙伴流程的每個Web服務(wù)接口映射為等效的OO接口；并且所述的基于面向?qū)ο蟮膯卧獪y試框架進行測試的步驟可以包括以下步驟根據(jù)所述映射步驟中得到的伙伴流程的OO接口生成伙伴樁；為生成的伙伴樁定義WSDL綁定和服務(wù)端口信息；形成包含描述被測試流程與其伙伴流程之間的服務(wù)調(diào)用的測試邏輯的測試例，其中，利用伙伴流程的OO接口的模擬對象來對伙伴流程的服務(wù)進行仿真；和執(zhí)行所述測試例，其中所述伙伴樁及其相關(guān)的模擬對象共同實現(xiàn)相應(yīng)的伙伴流程的服務(wù)。
在上述方法中的形成測試例的步驟中，可以通過服務(wù)代理實現(xiàn)從伙伴流程對被測試流程的服務(wù)調(diào)用。
在上述方法中的形成測試例的步驟中，可以自動地生成所述測試例的骨架，并且在所述骨架的基礎(chǔ)上完成所述測試例。另外，形成測試例的步驟可以以圖形化的方式完成。
根據(jù)本發(fā)明的另一個方面，提供一種Web服務(wù)業(yè)務(wù)流程的單元測試設(shè)備，該設(shè)備包括將被測試流程及其伙伴流程的Web服務(wù)描述語言(WSDL)元素映射為面向?qū)ο蟮恼Z言(OO)中的等效元素的裝置；和基于面向?qū)ο蟮膯卧獪y試框架對所述被測試流程進行測試的裝置。
根據(jù)本發(fā)明的另一個方面，提供一種計算機程序及其存儲介質(zhì)，所述程序包含用于執(zhí)行上面所述的方法的代碼。
本發(fā)明在業(yè)務(wù)流程單元測試中具有下列優(yōu)點。
1)該方法使得能夠進行自動回歸測試。通過將所有所需的測試邏輯和數(shù)據(jù)封裝在單元測試例中將流程測試過程自動化。每當(dāng)修改被測試流程時，其測試例可以被重新運行(在可能的修改后)以檢測由于修改引起的可能的功能錯誤。這樣，為業(yè)務(wù)流程重構(gòu)提供了便利。
2)該方法不依賴于伙伴流程的可用性。該方法提供了一種對伙伴流程進行仿真而無需知道其內(nèi)部業(yè)務(wù)邏輯的簡單的方法。這樣，可以比較容易地以孤立的方式測試單個流程。
3)該方法簡化了測試例的編寫。大多數(shù)開發(fā)人員熟悉各種流行的單元測試框架和相關(guān)的OO編程語言中的一種。該方法允許以O(shè)O風(fēng)格對流程的交互進行編程。利用該方法，程序開發(fā)人員不再需要關(guān)心測試中的XML文檔操作、接口、綁定和服務(wù)細節(jié)。對于那些不熟悉在該測試工具中所選擇的OO語言的業(yè)務(wù)流程編程員，可視化的測試例編輯器可以幫助他們克服障礙。
4)該方法加速了測試執(zhí)行。具體地，該方法允許“一次部署，多次測試”。被測試流程僅被部署一次來運行所有與該流程相關(guān)的測試例。相比之下，利用樁流程(stub process)來仿真伙伴流程的那些現(xiàn)有的方法中，對樁流程的任何修改都要求流程重新部署以及服務(wù)器重新啟動。


從下面結(jié)合附圖對本發(fā)明優(yōu)選實施例的描述，本領(lǐng)域的技術(shù)人員可以更清楚地理解本發(fā)明的進一步目的、特征和優(yōu)點，其中圖1說明了在根據(jù)本發(fā)明的業(yè)務(wù)流程單元測試方法中，業(yè)務(wù)流程的WSDL描述與面向?qū)ο蟮恼Z言的描述之間的關(guān)系；圖2示出了根據(jù)本發(fā)明的業(yè)務(wù)流程單元測試方法的流程圖；圖3示出了根據(jù)本發(fā)明的業(yè)務(wù)流程單元測試工具的體系結(jié)構(gòu)；圖4示出了作為本發(fā)明運行實例的購買流程的示意圖；圖5示出了在作為本發(fā)明運行實例的購買流程與其伙伴流程提供的接口的示意圖；圖6A為業(yè)務(wù)流程合成模型，以抽象的方式表示出了被測試業(yè)務(wù)流程與其伙伴流程之間的交互；圖6B為根據(jù)本發(fā)明的、對圖6A中所示的業(yè)務(wù)流程進行單元測試的業(yè)務(wù)流程單元測試模型。
圖7A示出了業(yè)務(wù)流程內(nèi)的同步；圖7B示出了業(yè)務(wù)流程間的同步；圖8出了在JUnit測試運行程序中運行業(yè)務(wù)流程測試例的屏幕顯示。
具體實施例方式
在本申請中，使用BPEL流程作為例子來描述本發(fā)明。但是，本領(lǐng)域的技術(shù)人員可以理解，該例子僅僅是用于說明的目的而非用于限制。本發(fā)明同樣可以應(yīng)用于其他Web服務(wù)業(yè)務(wù)流程編程語言中的業(yè)務(wù)流程的單元測試。
由業(yè)務(wù)流程提供的Web服務(wù)接口在WSDL(Web Service DescriptionLanguage，Web服務(wù)描述語言)文件中、并且優(yōu)選地在XSD語言文件中描述。圖1中示出了典型的WSDL文件的結(jié)構(gòu)。WSDL文件包含下列元素類型(type)、消息(message)、端口類型(portType)、綁定(binding)和服務(wù)(service)。“端口類型”聚集了一組可以被服務(wù)請求方調(diào)用的操作，“類型”和“消息”定義提供操作的數(shù)據(jù)模型。“綁定”為一個特定的端口類型給出協(xié)議和數(shù)據(jù)格式規(guī)范，而“服務(wù)”則聲明了與所定義的綁定相關(guān)的尋址信息。
本發(fā)明的核心思想是將利用Web服務(wù)調(diào)用的流程交互轉(zhuǎn)換為利用方法調(diào)用的類協(xié)作(class collaboration)，然后在業(yè)務(wù)流程領(lǐng)域應(yīng)用面向?qū)ο蟮臏y試技術(shù)。
圖2中示出了根據(jù)本發(fā)明一個優(yōu)選實施例的業(yè)務(wù)流程單元測試方法20的流程圖。
該方法20在步驟201開始。在該步驟中，將被測試流程(Processunder test，PUT)及其伙伴流程的關(guān)鍵的WSDL元素映射為面向?qū)ο?OO)的語言中的等效元素。該步驟的目的是將有關(guān)流程的每個Web服務(wù)接口定義映射為等效的OO表示。所述的映射包括兩部分將Web服務(wù)接口(圖1中用A表示)映射為OO接口/類(圖1中用C表示)，以及將Web服務(wù)類型和消息映射為OO數(shù)據(jù)類型類(data type class)。OO數(shù)據(jù)類型類將被用于定義OO測試程序中的測試數(shù)據(jù)。OO接口/類將被用于產(chǎn)生接口/類的OO模擬對象(圖1中用E表示)，后面將對其進行說明。每個WSDL操作(圖1中用B表示)將具有包含在適當(dāng)?shù)腛O接口/類(C)中的對應(yīng)的OO方法(圖1中用D表示)。WSDL中的操作“輸入”與OO方法中的“輸入”相對應(yīng)，WSDL中的操作“輸出”與OO方法中的“輸出”相對應(yīng)，而WSDL中的操作“故障(fault)”與OO方法中的“異常(exception)”相對應(yīng)。
接下來，在步驟202，根據(jù)圖1中所示的OO接口/類(C)生成“伙伴樁(partner stub)”。一個伙伴樁類(圖1中用F表示)實現(xiàn)/繼承步驟201中導(dǎo)出的接口/類(C)。具體地說，伙伴樁動態(tài)地獲得對服務(wù)進行仿真的模擬對象(E)，并調(diào)用模擬對象(E)的對應(yīng)方法(D)，收集返回值(如果不為空)，并返回該值。以這種方式，伙伴樁實際上是真實服務(wù)提供者實現(xiàn)的模擬對象(E)的簡單的包裝。模擬對象的確切行為可以在測試例中動態(tài)地定義，這將在下文中詳細地描述。這些伙伴樁是無狀態(tài)的(stateless)并且與測試行為無關(guān)，并且可以根據(jù)在步驟201中得出的接口/類(C)自動生成。伙伴樁的地址將在對應(yīng)的WSDL服務(wù)定義中引用，使得Web服務(wù)操作(B)的調(diào)用將去往正確伙伴樁(F)的正確的方法(D)。通過這種方式，一個伙伴樁及其相關(guān)的模擬對象共同實現(xiàn)一個仿真的伙伴流程。該伙伴樁實現(xiàn)一個簡單的轉(zhuǎn)發(fā)(relay)邏輯并且是在測試執(zhí)行之前生成的靜態(tài)部分，而模擬對象將定義測試邏輯并且是將在測試執(zhí)行過程中生成的動態(tài)部分。這與當(dāng)前使用的樁流程的區(qū)別在于，樁流程包含真實的測試邏輯，并被直接連接到被測試流程，因此必須編寫并維護大量的樁流程，并為每個測試場景重新部署和重新啟動這些流程。在本發(fā)明中，通過將責(zé)任分配到一個伙伴樁和一個模擬對象上，可以獲得利用單個伙伴樁動態(tài)地改變測試邏輯而不需重新部署和重新啟動的好處。
然后，在步驟203，定義測試特定的(test-specific)WSDL綁定和服務(wù)端點。伙伴流程的原始的WSDL綁定和服務(wù)端點可能是不同的SOAP，JMS，EJB等。對于單元測試，所有的伙伴流程將被仿真為本地服務(wù)。因此選擇一個更有效的綁定。本地OO語言綁定，例如Java綁定(WSIF，Web Service Invocation Framework)是優(yōu)選的，只要開發(fā)環(huán)境支持這種綁定。如果沒有這種支持，則可以利用另一種綁定，例如SOAP綁定。這樣，WSDL服務(wù)定義應(yīng)當(dāng)將其端點設(shè)置為適當(dāng)?shù)幕锇闃?F)的地址。
接下來，在步驟204，基于面向?qū)ο蟮膯卧獪y試框架形成測試例。一個測試例定義被測試流程的一個執(zhí)行路徑并包含用來實現(xiàn)特定測試目的的所有測試邏輯。測試邏輯可以人工編寫。在一個優(yōu)選實施例中，測試邏輯也可以(半)自動地生成。具體地說，可以先通過一個測試生成器生成測試例的骨架，然后再完成測試例的編寫。為了完整地測試一個業(yè)務(wù)流程，在測試邏輯表示中，以下的兩種能力a)和b)是必不可少的。
a)測試邏輯表示應(yīng)該能夠描述兩個方向的服務(wù)調(diào)用。一個方向是從PUT到伙伴流程，即，PUT調(diào)用由伙伴流程提供的服務(wù)。另一個方向是從伙伴流程到PUT，即，伙伴流程調(diào)用由PUT提供的服務(wù)。
對于從PUT到伙伴流程的調(diào)用，可以用模擬對象來對調(diào)用的流程進行仿真。為此，在本發(fā)明的方法中，利用了MockObjects項目(MO)。MockObjects是一種用于建立面向?qū)ο蟮能浖臏y試優(yōu)先的開發(fā)過程以及一個支持該過程的通用單元測試框架，其中，將一系列預(yù)期的方法調(diào)用連同預(yù)定義的返回值記錄在接口/類模擬對象(mock object)上。利用這種方法，可以在模擬對象中設(shè)定預(yù)期的請求消息和響應(yīng)消息，其隨后將被用來驗證實際的請求消息并用預(yù)定的響應(yīng)消息進行響應(yīng)。接口/類的模擬實現(xiàn)作為模仿真實實現(xiàn)的外部行為的虛擬的實現(xiàn)，它也觀察其他對象如何與其方法進行交互并對實際行為與預(yù)設(shè)的預(yù)期行為進行比較。當(dāng)發(fā)生不一致時，模擬實現(xiàn)將產(chǎn)生一個報告。這樣，MockObjects通過被測試單元的協(xié)作類來測試該被測試單元。
EasyMock(EM)是MockObjects的一種實現(xiàn)，并具有用于Java和.Net的版本。下面的代碼段示出了其基本使用(利用Java版本)。
public class ClassUnderTest{public void addListener(Collaborator listener){//...
}public void addDocument(String title，byte[]document){//calls listener.documentAdded(title)；}}public interface Collaborator{void documentAdded(String title)；}-----------------------------------------package org.easymock.samples；import junit.framework.TestCase；import org.easymock.MockControl；public class ExampleTest extends TestCase{private ClassUnderTest classUnderTest；private MockControl control；private Collaborator mock；protected void setUp(){control＝MockControl.createControl(Collaborato r.class)；(1)mock＝(Collaborator)control.getMock()； (2)classUnderTest＝new ClassUnderTest()；classUnderTest.addListener(mock)；
}public void testAddDocument(){mock.documentAdded(″New Document″)； (3)control.replay()； (4)classUnderTest.addDocument(″New Document″，new byte
)； (5)control.verify()； (6)}}EasyMock的使用分四個步驟創(chuàng)建、記錄、重放(replay)和驗證。首先，需要創(chuàng)建模擬實現(xiàn)(mock implementation)，其包括目標接口/類的MockControl對象(1)和模擬對象(2)。MockControl對象(1)控制其相關(guān)的模擬對象(2)的行為。然后記錄對模擬對象的預(yù)期方法調(diào)用并設(shè)置可能的返回值或異常(3)。在replay()方法(4)中激活模擬對象，MockControl對象開始重放記錄的場景。然后操作ClassUnderTest(5)，假定其協(xié)作類已經(jīng)實現(xiàn)。最后，調(diào)用verify()方法來檢查是否有差別。
另一方面，對于從伙伴流程到PUT的調(diào)用，情況則有所不同，因為PUT是真實的，因而不需要被仿真。但是，仍然必須定義發(fā)送給PUT的請求消息以及來自PUT的預(yù)期的響應(yīng)消息?？梢圆捎脦追N不同的方法實現(xiàn)該步驟。根據(jù)本發(fā)明的一個優(yōu)選實施例，利用模擬對象來存儲調(diào)用信息，但需要引入一個服務(wù)代理。該服務(wù)代理將利用在一個模擬對象中定義的請求和預(yù)期的響應(yīng)來調(diào)用PUT服務(wù)并驗證實際的響應(yīng)。這需要對通常的MockObjects實現(xiàn)進行修改。該方法的優(yōu)點是，測試者可以具有利用模擬對象編寫兩個方向的測試邏輯的統(tǒng)一的視角，而不是針對一個方向利用模擬對象而針對另一方向利用另一組API。
b)測試邏輯表示必須能夠描述被測試業(yè)務(wù)流程中的并發(fā)行為和同步約束。利用MockObjects，有幾種方法可以支持該能力。根據(jù)本發(fā)明的一個優(yōu)選實施例，利用MockObjects當(dāng)前的功能并對其進行擴展來描述這種復(fù)雜的順序關(guān)系，如下文中將要說明的。
接下來，在步驟205中執(zhí)行測試例。在測試例執(zhí)行前，部署該被測試流程PUT并且啟動應(yīng)用服務(wù)器。隨著測試的執(zhí)行以及在測試之后，記錄的測試邏輯被重放和驗證。意外的行為被報告給用戶。然后，與任何現(xiàn)有的測試方法一樣，測試人員對測試結(jié)果進行分析并采取相應(yīng)的處理。
前面結(jié)合圖1和圖2所描述的根據(jù)本發(fā)明的業(yè)務(wù)流程單元測試方法20可以以多種編程語言實現(xiàn)、平臺、體系結(jié)構(gòu)實現(xiàn)。圖3中示出了根據(jù)本發(fā)明一個實施例的業(yè)務(wù)流程單元測試工具30的體系結(jié)構(gòu)，該體系結(jié)構(gòu)反映了該單元測試工具30的核心功能。
圖3示出了構(gòu)成單元測試工具的主要組件(component)以及在這些組件之間流動的軟件產(chǎn)物(artifacts)。其中方形框表示軟件產(chǎn)物，橢圓形框表示組件，菱形框表示可能需要人工參與的任務(wù)，被虛線包圍的框則表示可選的組件和軟件產(chǎn)物。如圖3所示，這些組件和軟件產(chǎn)物被組織為與業(yè)務(wù)流程單元測試中的四個基本階段即準備階段、設(shè)計階段、執(zhí)行階段和分析階段對應(yīng)的四個組。具體地說，在準備階段中，包括組件WS2OO轉(zhuǎn)換器312和伙伴樁生成器314，分別用于根據(jù)PUT源311生成OO接口/類315和伙伴樁317。在本發(fā)明的一個優(yōu)選實施例中，該測試工具30還包括測試生成器313，該測試生成器313將PUT流程腳本311作為輸入，并自動產(chǎn)生一組測試例骨架316，這些測試例骨架316包含骨干測試邏輯和所需的數(shù)據(jù)約束。這些測試例骨架316將在設(shè)計階段完成。在設(shè)計階段，用戶編寫一組可執(zhí)行的測試例324(從頭開始編寫，或者基于上述骨架316)。在編寫過程中，可以利用由標記321總地表示的一些現(xiàn)有的單元測試框架如xUnit(“xUnit”是用于Java的JUnit、用于.Net的NUnit等的通稱)和MockObjects。為了將這些框架321應(yīng)用到根據(jù)本發(fā)明的業(yè)務(wù)流程測試，需要功能擴展，如下文中將詳細描述的。在本發(fā)明的一個優(yōu)選實施例中，該測試工具30還包括一個測試例編輯器323，以允許進行圖形化測試例創(chuàng)作。在執(zhí)行階段，該測試工具30包括具有可能擴展的xUnit運行程序或其他能夠執(zhí)行xUnit測試例的測試例執(zhí)行器組件331，該組件331用來來執(zhí)行測試例324，并產(chǎn)生包括測試報告和日志文件的測試結(jié)果332。在執(zhí)行階段收集的該測試結(jié)果332然后在分析階段被評估，以形成修改的計劃343。可選地，該測試工具30還包括一個日志閱覽器組件341來對測試執(zhí)行軌跡進行可視化顯示。
該工具30可以被實現(xiàn)為用于業(yè)務(wù)流程開發(fā)的IDE中的一個插件，或者作為獨立于業(yè)務(wù)流程IDE的單獨工具。
為了使本領(lǐng)域技術(shù)人員進一步理解本發(fā)明，下面將BPEL規(guī)范中介紹的購買流程作為本發(fā)明的運行實例進行說明。圖4中示出了該流程在IBM公司的WSADIE(Websphere工作室應(yīng)用開發(fā)集成版)中的實現(xiàn)方式。圖4是該流程腳本的圖形形式。
該購買流程如下面所述進行。當(dāng)從顧客接到定單時，該購買流程與三個伙伴流程-裝運、開發(fā)票和調(diào)度相通信來進行工作。它同時發(fā)起三項任務(wù)請求裝運、計算定單的價格、為該定單調(diào)度生產(chǎn)和裝運。盡管一些處理可以同時進行，在這三個任務(wù)之間存在控制和數(shù)據(jù)相關(guān)性。具體來講，需要裝運價格來最終完成價格計算，需要裝運日期來完成調(diào)度。當(dāng)這三項任務(wù)完成時，可以進行開發(fā)票處理，并將發(fā)票發(fā)送給用戶。
由該購買流程及其伙伴流程提供的接口在WSDL文檔中定義為端口類型。圖5中示出了其圖形化表示。購買流程提供了三種端口類型購買(Purchasing)、裝運回調(diào)(ShippingCallback)和發(fā)票回調(diào)(InvoiceCallback)，每個端口類型具有一個操作。每個伙伴流程，裝運、開發(fā)票和調(diào)度，分別提供一個端口類型裝運服務(wù)(ShippingService)、計算價格服務(wù)(ComputePriceService)和調(diào)度服務(wù)(SchedulingServiece)。
以下結(jié)合圖6A和圖6B描述根據(jù)本發(fā)明的基本測試模型。
被測試的業(yè)務(wù)流程-購買流程，與三個伙伴流程-裝運、開發(fā)票和調(diào)度進行交互，每個伙伴流程又與其他的伙伴流程交互，從而形成一個流程網(wǎng)絡(luò)。圖6A抽象地表示出這個合成模型。被測試流程被簡略地表示為PUT，其伙伴流程被簡略地表示為PP。從單個流程的角度來看，它并不關(guān)心其伙伴是如何實現(xiàn)的，因為它通過在WSDL注釋中規(guī)定的該伙伴的Web服務(wù)接口與每個伙伴進行交互。因此，伙伴可以是一個簡單的無狀態(tài)Web服務(wù)，或者是對幾個Web服務(wù)/流程進行編排并將一個或幾個Web服務(wù)接口暴露給調(diào)用方流程的復(fù)雜流程。將一個伙伴處理為通用的流程使得該方法適用于通用的測試例。
兩個流程間的對話關(guān)系在伙伴鏈路中定義。每個伙伴鏈路定義兩個“角色”名稱，并列出每個角色在該對話中向另一個角色提供的Web服務(wù)接口。圖6 A中利用箭頭線來連接兩個流程，表示服務(wù)調(diào)用/消息從源流向目標。例如，箭頭線①表示從伙伴流程PP1對被測試流程PUT的服務(wù)的調(diào)用，箭頭線④則表示從被測試流程PUT對伙伴流程PP1的服務(wù)的調(diào)用，依此類推。
圖6B示出了根據(jù)本發(fā)明的、針對圖6A中的流程合成模型的單元測試模型。該模型使用用于每個伙伴流程(PPi)的測試流程(TPi，i＝1，2，3)來仿真其行為。事實上，TPi僅描述了一個方向的交互，即，PUT調(diào)用伙伴PPi的服務(wù)。至于相反方向的交互，即伙伴PPi調(diào)用PUT的服務(wù)，在根據(jù)本發(fā)明的單元測試方法和工具中是通過服務(wù)代理601來完成的。原本發(fā)生在PPi中的PUT服務(wù)調(diào)用被委派給服務(wù)代理601，以便在測試邏輯中執(zhí)行。這是由于模擬對象僅能描述調(diào)入(call-in)，而無法描述調(diào)出(call-out)。因此，根據(jù)本發(fā)明，提供了一個特殊的測試流程，稱為“TP0”，其描述了對PUT的預(yù)期的服務(wù)調(diào)用及其預(yù)期的響應(yīng)。服務(wù)代理使用該請求和響應(yīng)，以便實際調(diào)用PUT并驗證實際響應(yīng)。
下面結(jié)合圖7A和圖7B描述在根據(jù)本發(fā)明的業(yè)務(wù)流程單元測試中的并發(fā)和同步。
在通常的流程行為及其與其他流程的交互中，服務(wù)調(diào)用遵循用編程控制結(jié)構(gòu)表示的特定的順序。BPEL定義了下列控制結(jié)構(gòu)sequence，flow，while和switch，等等。
因此，在對真實流程進行仿真的測試流程中，需要類似的控制結(jié)構(gòu)來表示原始的活動。在業(yè)務(wù)流程單元測試中，一條測試邏輯應(yīng)當(dāng)僅描述PUT的一個執(zhí)行路徑，而復(fù)雜的行為如迭代和分支應(yīng)該盡可能避免。但是，并發(fā)和同步是對執(zhí)行路徑施加的常見的排序約束，因而是不可避免的，必須在測試行為描述中支持。在圖6B中，同步用虛線表示。該圖中僅示出了測試流程之間的同步。實際上，測試流程內(nèi)部也會發(fā)生同步。圖7示出了這兩種情況。圖7A示出了流程內(nèi)的同步，其中op1，op3，op6是并發(fā)的活動，op1必須在op4之前被調(diào)用；op5必須在op2和op4之后被調(diào)用。圖7B示出了流程TP1與TP2之間的同步，其中op1必須在op5之前被調(diào)用。
利用這樣的同步能力，圖6A中所示的服務(wù)交互排序在如圖6B所示的測試邏輯中得到了支持。例如，邏輯“首先調(diào)用PUT服務(wù)，然后調(diào)用TP3服務(wù)”得到了支持。
下面將對圖3中示出的測試工具體系結(jié)構(gòu)300的組件的具體實現(xiàn)方式進行說明。
1、WS2OO轉(zhuǎn)換器該WS2OO轉(zhuǎn)換器組件312用于將WSDL映射為面向?qū)ο蟮恼Z言的描述(例如Java，C#)。有關(guān)流程的每個Web服務(wù)接口將被映射為OO等效接口或類；而Web服務(wù)類型和消息映射為OO數(shù)據(jù)類型類。這里所說的“有關(guān)流程”是指圖6A中所示出的那些流程，包括PUT及其中間伙伴流程。
WS2OO轉(zhuǎn)換器的一種示例性實現(xiàn)方式，例如，WS2Java可以基于兩種Java規(guī)范JAX-RPC和JAXB。JAX-RPC規(guī)定如何將一個wsdl:portType元素映射為Java接口，其包括從相應(yīng)的wsdl:portType的wsdl:operation子元素映射的Java方法。wsdl:input和wsdl:output消息被映射為Java方法參數(shù)或返回類型，而wsdl:fault消息被映射為Java異常(exception)。另外，將XML方案類型映射為Java在JAXB2.0中描述。
存在幾種可用來進行WS2OO映射的程序，包括Microsoft公司的WSDL2Java，WSDL2C，和WSDL.exe，以及PocketSOAP實用套件。但是，本領(lǐng)域的技術(shù)人員可以理解，在實現(xiàn)一個測試工具時，有可能需要使該實現(xiàn)方式適應(yīng)特定的業(yè)務(wù)流程編程語言的IDE和所使用的MockObjects實現(xiàn)方式。
下面的代碼給出了作為本發(fā)明運行實例的如圖5所示的購買流程的裝運服務(wù)端口類型的映射的例子。
<portType name＝″ShippingService″>
<operation name＝″requestShipping″>
<input message＝″wsdl:ShippingRequest″/>
<output message＝″wsdl:ShippingInfo″/>
<fault message＝″wsdl:ShippingFault″name＝″fault″/>
</operation>
</portType>
public interface ShippingService{
public ShippingInfo requestShipping(ShippingRequest shippingRequest) throwsjava.lang.Exception；}該映射的接口被用于兩個目的生成伙伴樁，以及用于生成模擬實現(xiàn)(mock implementation)。
2、伙伴樁生成器伙伴樁是Web服務(wù)接口的一種實現(xiàn)。在運行中，可以通過調(diào)用伙伴樁來完成Web服務(wù)調(diào)用。這個關(guān)系在wsdl:binding和wsdl:service部分定義。對于購買流程的例子和一個伙伴樁ShippingServiceStub，綁定和服務(wù)信息在下面的代碼示出。
<binding name＝″ShippingServiceJavaBinding″type＝″ShippingService″>
<java:binding/>
<format:typeMapping encoding＝″Java″style＝″Java″>
…</format:typeMapping>
<operation name＝″requestShipping″>
<java:operation methodName＝″requestShipping″parameterOrder＝″shippingRequest″retumPart＝″shippingInfo″/>
<input/>
<output/>
<fault name＝″fault″/>
</operation>
</binding>
<service name＝″ShippingServiceJavaService″>
<port binding＝″ShippingServiceJavaBinding″name＝″ShippingServiceJavaPort″>
<java:address className＝″ShippingServiceStub″/>
</port>
</service>
其中加亮的java:address元素規(guī)定ShippingServiceStub是服務(wù)端點。注意，在部署被測試流程以對其進行測試時，綁定和服務(wù)信息應(yīng)該取代原先的信息。
伙伴樁并不真實地實現(xiàn)服務(wù)邏輯，而是將調(diào)用轉(zhuǎn)送(relay)至同一web服務(wù)接口的模擬對象，然后將返回值傳遞給原始調(diào)用方，如加亮語句所示。簡言之，被測試流程PUT在運行中實際調(diào)用的是模擬實現(xiàn)。為隱藏該復(fù)雜性，可以自動地生成伙伴樁并對用戶隱藏。
3、EasyMock的使用和擴展模擬對象的創(chuàng)建、記錄和驗證映射的OO接口/類被用于創(chuàng)建模擬實現(xiàn)(模擬控制和模擬對象)。然后，在一個測試例中，在每個模擬對象上記錄預(yù)期對應(yīng)的伙伴流程將從PUT接收的方法調(diào)用的序列，并預(yù)先規(guī)定返回值。如果PUT在運行期間發(fā)出一個錯誤的調(diào)用(包括具有錯誤參數(shù)的方法調(diào)用，錯誤的調(diào)用號和順序)，MockObjects的驗證機制將報告該錯誤。
PUT或者伙伴流程的每個端口類型(定義web服務(wù)接口)具有一個模擬實現(xiàn)。因此，一個流程可以對應(yīng)于幾個模擬對象，其中的每一個針對一種端口類型。對于購買流程的例子，將有六個模擬對象三個用于PUT(購買、發(fā)票回調(diào)和裝運回調(diào))，另外的每一個模擬對象用于每個伙伴流程-裝運服務(wù)、計算價格服務(wù)和調(diào)度服務(wù)。
PUT和伙伴流程的差別一個流程的一個模擬對象設(shè)置對該流程的預(yù)期的調(diào)用以及可能的返回值，并在運行中驗證該預(yù)期的調(diào)用伴隨著正確的參數(shù)而發(fā)生。例如，假設(shè)mockShip是ShippingService的模擬對象，利用mockShip.requestShipping(shipRequest)來設(shè)置具有參數(shù)(shipRequest)的requestShipping的預(yù)期調(diào)用，并利用setReturn Value(“Shipping Service”，shipInfo)來設(shè)置調(diào)用的返回值(shipinfo)。因此，這里利用模擬對象來對一個并不存在的伙伴流程所提供的服務(wù)進行仿真，即，何時請求一個服務(wù)，以及響應(yīng)是什么。PUT在運行中將通過伙伴樁的轉(zhuǎn)送來調(diào)用伙伴流程的模擬對象。
但是，對PUT的模擬對象的處理是不同的。利用針對真實存在的PUT的模擬對象不是用來仿真其行為，而是告訴服務(wù)代理對該PUT進行調(diào)用并檢查該調(diào)用的可能返回值是否正確。在購買流程的例子中，例如，mockPurchasing是PUT購買接口的模擬對象。下面第一個語句告訴服務(wù)代理，應(yīng)當(dāng)調(diào)用具有規(guī)定參數(shù)的sendPurchaseOrder操作，而第二個語句則告訴服務(wù)代理檢查PUT應(yīng)當(dāng)返回invoice作為響應(yīng)。
mockPurchasing.sendPurchaseOrder(po，customerInfo)；setReturn Value(“Purchasing”，invoice)。
服務(wù)代理代表在實際運行中進行服務(wù)調(diào)用的相關(guān)伙伴流程來完成上述操作，因為MockObject框架不允許模擬對象中的向外調(diào)用行為。當(dāng)服務(wù)代理調(diào)用PUT時也調(diào)用模擬對象。這是表達測試邏輯的統(tǒng)一方式，使得所有交互被MockObjects內(nèi)置驗證功能驗證，無論它是從PUT到伙伴流程還是相反。為了避免模擬對象語義上的混淆，根據(jù)本發(fā)明的一個優(yōu)選實施例，可以在編寫測試例時，也將PUT處理為不存在的流程。
模擬對象的修改為了區(qū)分這兩種類型的模擬對象，在測試工具的實現(xiàn)方式中必須采用適當(dāng)?shù)姆椒?，例如，采用一個配置文件，來從伙伴流程的模擬對象中識別PUT服務(wù)的模擬對象。需要對MockObjects進行修改來向服務(wù)代理通知特定的模擬對象和相關(guān)的方法調(diào)用。
實現(xiàn)服務(wù)代理服務(wù)代理與PUT之間的接口可能是不同的。在一個優(yōu)選實施例中，利用由應(yīng)用服務(wù)器提供的BPEL引擎API來調(diào)用PUT服務(wù)。
測試行為的支持MockObjects可以提供一些靈活的行為描述和驗證機制。例如，EasyMock具有三種類型的MockControl。其中一種普通的控制不檢查預(yù)期方法調(diào)用的順序。另一種較為嚴格的控制將檢查預(yù)期方法調(diào)用的順序。對于這兩種控制類型，對模擬對象的意外的方法調(diào)用將導(dǎo)致AssertionFailedError。剩下的一種是上述普通控制的較松散的版本，它不檢查預(yù)期方法調(diào)用的順序，而意外的方法調(diào)用將返回一個空值(0，null，false)。
并發(fā)這些預(yù)設(shè)的和特殊的MockControl類型可以用來表示兩種基本的控制邏輯/方法調(diào)用排序序列和隨機(未排序)。以購買流程為例。如果希望從PUT到另一流程的幾個服務(wù)調(diào)用按規(guī)定的順序發(fā)生，可以采用嚴格的MockControl來生成該流程的模擬實現(xiàn)。除了序列和隨機以外，還有一般的控制邏輯如alternative(switch)，定時器操作(開始定時器，超時)，以及并發(fā)(現(xiàn)有的MockObjects實現(xiàn)可能尚不支持)。理想的是，業(yè)務(wù)流程的測試需要MockObjects實現(xiàn)來支持一般的控制邏輯。一種可能的MockObjects實現(xiàn)可以利用UML活動或狀態(tài)機(可以簡化或擴展)作為模擬對象的行為模型。實際上，MockObjects實現(xiàn)應(yīng)該支持并發(fā)和同步邏輯。為此，需要對現(xiàn)有的MockObjects實現(xiàn)進行擴展。根據(jù)本發(fā)明的一個優(yōu)選實施例，采用的擴展方式是允許測試者通過采用指定方法m1，m2等的API syncMethods(m1，m2)來指定這幾個方法的連續(xù)關(guān)系。
于是，對于圖7A中所示的流程內(nèi)并發(fā)和同步，該邏輯可以如下表示利用普通的MockControl來生成模擬實現(xiàn)，使得方法調(diào)用為未排序的，然后通過利用例如下面所示的syncMethods()API來指定排序約束syncMethods(op1，op2，op5)syncMethods(op3，op4，op5)syncMethods(op1，op4)對于圖6B中所示的流程間并發(fā)和同步，該邏輯可以如下表示利用嚴格的MockControl來為TP1和TP2生成模擬實現(xiàn)，從而檢查對于每個模擬實現(xiàn)的方法調(diào)用是否被正確排序，例如op1先于op2先于op3，然后利用syncMethods(op1，op5)來指定TP1與TP2之間的同步。注意，不同的模擬對象在運行中是獨立調(diào)用的，因而它們的行為是純并發(fā)的，除非在它們之間置入了明確的同步。
MockObjects的另一種使用方式是對于所有伙伴流程使用單個模擬實現(xiàn)，而對于PUT使用單一的一個模擬實現(xiàn)。在MockObjects實現(xiàn)支持在一個模擬實現(xiàn)中對多個接口/類進行仿真的情況下，該方式可行。具體地，可以簡單地對EasyMock進行擴展(修改CreateControl()API)來實現(xiàn)該目的。MockObjects的這種使用方式的優(yōu)點在于，在測試例中需要管理和操作的模擬實現(xiàn)的數(shù)目較少。
4、測試生成器在本發(fā)明中，測試生成器是一個可選的組件，其提供了一個高級的功能-從BPEL流程腳本生成測試例。這個功能是期望的，因為人工測試例設(shè)計是費時的，需要人工檢查流程以識別不同的執(zhí)行場景，并編寫測試邏輯來表示這些場景。期望測試生成功能自動地找到執(zhí)行場景并生成對應(yīng)的測試邏輯，從而節(jié)約大量的測試設(shè)計時間，同時提高測試的完整性。本領(lǐng)域技術(shù)人員可以理解，測試生成也可以是部分自動化的，并作為一種輔助工具。例如，測試生成器可以用來生成測試例骨架，供測試人員在控制邏輯和數(shù)據(jù)值方面對其進行審查和改進。
5、測試例編輯器該組件被用來提供可視化編輯支持以簡化測試例設(shè)計?？赡艿木庉嫎邮桨藴蔝ML注釋的序列范例和活動范例(可能簡化或擴展)。測試人員繪制范例，然后這些范例被轉(zhuǎn)換成所選擇的OO編程語言的測試代碼。
與OO編程代碼相比，圖形化編輯的優(yōu)點是直觀、易學(xué)，對于不熟悉OO編程語言的BPEL程序員尤其有用。這樣，可以對BPEL程序員隱藏OO測試代碼。
6、測試執(zhí)行器BPEL單元測試例可以用xUnit運行程序運行。例如，JUnit提供了文本和圖形運行程序。圖8示出了在JUnit測試運行程序中運行BPEL的屏幕顯示。
7、日志閱覽器在執(zhí)行測試后，測試結(jié)果集中在測試報告和日志文件中。測試報告例如可以采用xUnit“故障”報告的形式，而日志文件可以是運行PUT的應(yīng)用服務(wù)器的日志文件或測試工具的日志文件。從這些信息可以重建事件軌跡，并且可以找到PUT代碼中的故障原因。日志閱覽器可以將事件軌跡以序列范例的形式可視化地顯示。這有助于測試人員跟蹤調(diào)查交互的細節(jié)并識別故障點。根據(jù)測試分析，可以得到PUT代碼或/和測試例的修改計劃。
本領(lǐng)域的技術(shù)人員可以理解，以上描述的根據(jù)本發(fā)明的測試工具中的各個組件可以由軟件、硬件、固件或者其結(jié)合來實現(xiàn)。
另外，根據(jù)本發(fā)明的單元測試方法可以作為計算機程序?qū)崿F(xiàn)在計算機可讀介質(zhì)上。這些介質(zhì)包括但不限于光盤、磁盤、磁光盤、半導(dǎo)體存儲器。
以上已經(jīng)結(jié)合優(yōu)選實施例對本發(fā)明的用于業(yè)務(wù)流程編程語言中的自動化流程的單元測試方法和工具進行了說明。本領(lǐng)域技術(shù)人員很清楚，這些實施例僅僅是用于說明的目的而非對本發(fā)明的限制。在不偏離本發(fā)明的精神和范圍的情況下可以對這些實施例作出各種修改。
權(quán)利要求
1.一種Web服務(wù)業(yè)務(wù)流程的單元測試方法，其特征在于包括以下步驟將被測試流程及其伙伴流程的Web服務(wù)描述語言(WSDL)元素映射為面向?qū)ο蟮恼Z言(OO)中的等效元素；和基于面向?qū)ο蟮膯卧獪y試框架對所述被測試流程進行測試。
2.如權(quán)利要求1所述的方法，其特征在于，所述的映射步驟包括將被測試流程及其伙伴流程的每個Web服務(wù)接口映射為等效的OO接口；并且所述的基于面向?qū)ο蟮膯卧獪y試框架進行測試的步驟包括根據(jù)所述映射步驟中得到的伙伴流程的OO接口生成伙伴樁；為生成的伙伴樁定義WSDL綁定和服務(wù)端口信息；形成包含描述被測試流程與其伙伴流程之間的服務(wù)調(diào)用的測試邏輯的測試例，其中，利用伙伴流程的OO接口的模擬對象來對伙伴流程的服務(wù)進行仿真；和執(zhí)行所述測試例，其中所述伙伴樁及其相關(guān)的模擬對象共同實現(xiàn)相應(yīng)的伙伴流程的服務(wù)。
3.如權(quán)利要求2所述的方法，其特征在于，所述WSDL綁定是所述映射步驟中采用的所述面向?qū)ο蟮恼Z言的綁定。
4.如權(quán)利要求2所述的方法，其特征在于，所述WSDL綁定是簡單對象訪問協(xié)議(SOAP)綁定。
5.如權(quán)利要求2所述的方法，其特征在于，在所述形成測試例的步驟中，從伙伴流程對被測試流程的服務(wù)調(diào)用是通過利用服務(wù)代理調(diào)用被測試流程的模擬對象而實現(xiàn)的。
6.如權(quán)利要求2所述的方法，其特征在于，所述測試邏輯支持所述業(yè)務(wù)流程中的并發(fā)和同步。
7.如權(quán)利要求2所述的方法，其特征在于，所述形成測試例的步驟包括自動地生成所述測試例的骨架；以及在所述骨架的基礎(chǔ)上完成所述測試例。
8.如權(quán)利要求2所述的方法，其特征在于，所述形成測試例的步驟是以圖形化的方式完成的。
9.如權(quán)利要求2所述的方法，其特征在于，所述Web服務(wù)業(yè)務(wù)流程包括下面所述的編程語言中規(guī)定的業(yè)務(wù)流程BPEL4WS、BPMN、WfXML、XPDL、XLANG、WSFL；并且所述面向?qū)ο蟮恼Z言包括Java、C#。
10.一種Web服務(wù)業(yè)務(wù)流程的單元測試設(shè)備，其特征在于包括將被測試流程及其伙伴流程的Web服務(wù)描述語言(WSDL)元素映射為面向?qū)ο蟮恼Z言(OO)中的等效元素的裝置；和基于面向?qū)ο蟮膯卧獪y試框架對所述被測試流程進行測試的裝置。
11.如權(quán)利要求10所述的設(shè)備，其中，所述映射裝置包含將被測試流程及其伙伴流程的每個Web服務(wù)接口映射為等效的OO接口的裝置；并且所述的基于面向?qū)ο蟮膯卧獪y試框架進行測試的裝置包括伙伴樁生成裝置，用于根據(jù)在所述映射裝置的所述映射操作中得到的伙伴流程的OO接口生成伙伴樁；定義裝置，用于為所述伙伴樁生成裝置生成的伙伴樁定義WSDL綁定和服務(wù)端口信息；測試例形成裝置，用于形成包含描述被測試流程與其伙伴流程之間的服務(wù)調(diào)用的測試邏輯的測試例，其中，利用伙伴流程的OO接口的模擬對象來對伙伴流程的服務(wù)進行仿真；和測試例執(zhí)行裝置，用于執(zhí)行所述測試例，其中所述伙伴樁及其相關(guān)的模擬對象共同實現(xiàn)相應(yīng)的伙伴流程的服務(wù)。
12.如權(quán)利要求11所述的設(shè)備，其特征在于，所述WSDL綁定是所述映射操作中采用的所述面向?qū)ο蟮恼Z言的綁定。
13.如權(quán)利要求11所述的設(shè)備，其特征在于，所述WSDL綁定是簡單對象訪問協(xié)議(SOAP)綁定。
14.如權(quán)利要求11所述的設(shè)備，其特征在于，在測試例形成裝置中，所述從伙伴流程對被測試流程的服務(wù)調(diào)用是通過利用服務(wù)代理調(diào)用被測試流程的模擬對象實現(xiàn)的。
15.如權(quán)利要求11所述的設(shè)備，其特征在于，所述測試邏輯支持所述業(yè)務(wù)流程中的并發(fā)和同步。
16.如權(quán)利要求11所述的設(shè)備，其特征在于，所述測試例形成裝置包括一個測試生成器，用于自動地生成所述測試例的骨架，所述測試例在所述骨架的基礎(chǔ)上完成。
17.如權(quán)利要求11所述的設(shè)備，其特征在于，所述測試例形成裝置包括一個測試例編輯器，用于以圖形化的方式完成測試例的形成。
18.一種計算機程序，包括用于執(zhí)行如權(quán)利要求1-9中任何一項所述的方法的程序代碼。
19.一種計算機可讀的存儲介質(zhì)，其上記錄了計算機程序代碼，當(dāng)所述代碼被執(zhí)行時，使計算機執(zhí)行如權(quán)利要求1-9中任何一項所述的方法。
全文摘要
本發(fā)明提供一種Web服務(wù)業(yè)務(wù)流程的單元測試方法，其中將被測試流程及其伙伴流程的WSDL元素映射為面向?qū)ο蟮恼Z言(OO)中的等效元素，然后基于面向?qū)ο蟮膯卧獪y試框架進行測試。在該方法中，將被測試流程及其伙伴流程的Web服務(wù)接口映射為等效的OO接口，根據(jù)伙伴流程的OO接口生成伙伴樁，為伙伴樁定義綁定和服務(wù)端口信息，形成包含描述被測試流程與其伙伴流程之間的服務(wù)調(diào)用的測試邏輯的測試例，其中利用伙伴流程的OO接口的模擬對象對伙伴流程的服務(wù)進行仿真，并執(zhí)行測試例，其中伙伴樁及其相關(guān)的模擬對象共同實現(xiàn)相應(yīng)的伙伴流程的服務(wù)。本發(fā)明還提供相應(yīng)的測試設(shè)備和計算機程序產(chǎn)品。根據(jù)本發(fā)明，可以以規(guī)范、統(tǒng)一、高效的方式對Web服務(wù)業(yè)務(wù)流程進行單元測試。
文檔編號G06F11/36GK101026503SQ20061005144
公開日2007年8月29日 申請日期2006年2月24日 優(yōu)先權(quán)日2006年2月24日
發(fā)明者李中杰, 孫偉, 杜彬 申請人:國際商業(yè)機器公司