Web服务业务流程的单元测试的方法和设备

摘要

本发明提供一种Web服务业务流程的单元测试方法，其中将被测试流程及其伙伴流程的WSDL元素映射为面向对象的语言(OO)中的等效元素，然后基于面向对象的单元测试框架进行测试。在该方法中，将被测试流程及其伙伴流程的Web服务接口映射为等效的OO接口，根据伙伴流程的OO接口生成伙伴桩，为伙伴桩定义绑定和服务端口信息，形成包含描述被测试流程与其伙伴流程之间的服务调用的测试逻辑的测试例，其中利用伙伴流程的OO接口的模拟对象对伙伴流程的服务进行仿真，并执行测试例，其中伙伴桩及其相关的模拟对象共同实现相应的伙伴流程的服务。本发明还提供相应的测试设备和计算机程序产品。根据本发明，可以以规范、统一、高效的方式对Web服务业务流程进行单元测试。

说明书

技术领域

本发明涉及计算机程序的测试，更具体地，涉及在Web服务业务流程编程语言中规定的自动化业务流程的单元测试的方法和设备。

背景技术

在过去的十年中，商业界和政府部门越来越关注利用IT技术来对业务流程(business process)进行描述、自动化和管理。业务流程是一个组织内业务价值的基本单元。

Web服务业务流程执行语言(BPEL4WS，简称为BPEL)是用于Web服务合成的业务流程编程语言的一个例子。其他这类编程语言包括：BPMN，WfXML，XPDL，XLANG，WSFL等。这些语言均通过合成Web服务来描述业务流程。一般来说，一个业务流程是关于该流程与其伙伴流程(partner process，PP)的交互来定义的。一个伙伴流程可以向该流程提供服务，从该流程请求服务，或者参与与该流程的双向交互。

任务关键(mission-critical)的业务解决方案需要综合的测试，以确保其准确可靠的运行。一种常见的策略是对该解决方案进行几个阶段的测试，如单元测试、集成测试和系统测试。单元测试验证单个模块(类、组件、流程等)的功能。集成测试验证几个模块的共同的功能。系统测试则通过穿越用户接口(如果有的话)将整个解决方案作为一个黑盒来测试。系统测试是很常见的，因为它几乎是产品发布前防止致命错误的最后保障，并且在传统的软件开发中是强制性的。通常，越晚发现错误，则对它进行修补的费用越高。另一方面，可以自动进行单元测试，从而使得回归(regression)测试可行并且有效，确保了新增加的功能不会影响旧的部分，并且有助于控制质量风险。因此，近年来在软件工程实践中越来越重视单元测试。JUnit是这种趋势中最为著名的实例。围绕/基于JUnit及其原理，已经针对Java，EJB，Servlet，.Net和其他类型的编程技术提出并实现了很多单元测试框架和工具。单元测试工具已经成为集成开发环境(IDE)的必不可少的部分，并作为提高产率和质量的手段受到程序开发人员的欢迎。

业务流程单元测试将单个的流程作为被测试单元(unit under test)，并通过将该流程与其伙伴流程隔离来对该流程的内部逻辑进行彻底的测试。其中，对伙伴流程进行仿真而不采用真实的伙伴流程，原因是：1)在单元测试阶段，一些独立的伙伴流程仍在开发中因而不可用；2)一些伙伴流程由其他企业开发(有可能是在完全不同的开发环境中开发)和管理，通常不能获得这些伙伴流程的源代码和相关的软件模块并建立用于测试的运行环境；3)即使已经具有了某些/全部伙伴流程，仿真的伙伴流程仍然是优选的，因为它们可以产生更多的交互场景而花费较小的精力，因为对被测试流程的应答是虚构的而不是按照真实的业务逻辑-调用其他业务流程、访问数据库或与人交互-来计算的。

在当前的产业实践中，业务流程测试集中在系统测试，例如IBM公司的Rational Functional Tester；而单元测试尚未引起任何注意。业务流程单元测试方法和工具的缺乏，造成了以下缺点：1)流程很少被孤立地测试，由于它们是互相依赖的，因而很难在一个流程的伙伴流程没有准备好的时候运行该流程；2)在通过对其伙伴流程进行仿真来孤立地测试一个流程的极少的情况下，这些伙伴流程是以特定、主观和不完整的方式编写的，为了不同的测试目的和测试例，必须重新绑定服务并重新启动服务器(这是非常耗时的任务)；另外，将测试逻辑分布到多个流程中不利于简单的测试维护和使用；3)测试执行是人工完成的而没有任何工具支持，这不利于实现自动回归测试。

现有的单元测试框架是为面向对象(OO)的编程语言设计的，不能直接应用于测试业务流程，因为后者是面向过程的而不涉及类的概念。另外，并发和同步是业务流程测试的基本要求，而在现有的框架中不能得到支持。为了实现业务流程单元测试，需要对现有的框架进行修改和扩展。

尽管前面所述的那些业务流程编程语言是Web服务编排语言，Web服务测试，例如Optimyz公司的WebServiceTester，Parasoft公司的SOAPtest方法和工具总的来说不适用于业务流程的测试。Web服务测试将被测试单元作为一个黑盒来对待，仅需要利用其接口定义，而不考虑其内部实现方式。在Web服务测试中，测试例对客户进行仿真，发送请求消息并检查响应消息。但是，在业务流程测试中，这种在测试例和被测试单元之间的简单的消息交换是不够的。业务流程单元测试将被测试单元作为一个白盒来对待，其中的内部实现逻辑是需要使用的。一个业务流程通常有很多伙伴，该流程按照业务逻辑与这些伙伴多次交互。为了测试这样一个流程，必须对所有伙伴进行仿真，并且应用一个能够规定流程间的通用的复杂交互的完整的测试逻辑。因此，业务流程单元测试例会更加复杂，通常由被测试单元的多个被仿真的伙伴流程构成。

发明内容

本发明的目的是克服现有技术中的缺陷，提供一种以规范、统一、高效的方式对Web服务业务流程编程语言中规定的业务流程进行单元测试的方法。

本发明的另一个目的是在Web服务业务流程的单元测试中简化测试例的编写。

本发明的另一个目的是提供一种Web服务业务流程的单元测试的设备和计算机程序产品。

为实现上述目的，根据本发明的一个方面，提供一种Web服务业务流程的单元测试方法，该方法包括以下步骤：将被测试流程及其伙伴流程的Web服务描述语言(WSDL)元素映射为面向对象的语言(OO)中的等效元素；和基于面向对象的单元测试框架对所述被测试流程进行测试。

在上述方法中的映射步骤中，将被测试流程及其伙伴流程的每个Web服务接口映射为等效的OO接口；并且所述的基于面向对象的单元测试框架进行测试的步骤可以包括以下步骤：根据所述映射步骤中得到的伙伴流程的OO接口生成伙伴桩；为生成的伙伴桩定义WSDL绑定和服务端口信息；形成包含描述被测试流程与其伙伴流程之间的服务调用的测试逻辑的测试例，其中，利用伙伴流程的OO接口的模拟对象来对伙伴流程的服务进行仿真；和执行所述测试例，其中所述伙伴桩及其相关的模拟对象共同实现相应的伙伴流程的服务。

在上述方法中的形成测试例的步骤中，可以通过服务代理实现从伙伴流程对被测试流程的服务调用。

在上述方法中的形成测试例的步骤中，可以自动地生成所述测试例的骨架，并且在所述骨架的基础上完成所述测试例。另外，形成测试例的步骤可以以图形化的方式完成。

根据本发明的另一个方面，提供一种Web服务业务流程的单元测试设备，该设备包括：将被测试流程及其伙伴流程的Web服务描述语言(WSDL)元素映射为面向对象的语言(OO)中的等效元素的装置；和基于面向对象的单元测试框架对所述被测试流程进行测试的装置。

根据本发明的另一个方面，提供一种计算机程序及其存储介质，所述程序包含用于执行上面所述的方法的代码。

本发明在业务流程单元测试中具有下列优点。

1)该方法使得能够进行自动回归测试。通过将所有所需的测试逻辑和数据封装在单元测试例中将流程测试过程自动化。每当修改被测试流程时，其测试例可以被重新运行(在可能的修改后)以检测由于修改引起的可能的功能错误。这样，为业务流程重构提供了便利。

2)该方法不依赖于伙伴流程的可用性。该方法提供了一种对伙伴流程进行仿真而无需知道其内部业务逻辑的简单的方法。这样，可以比较容易地以孤立的方式测试单个流程。

3)该方法简化了测试例的编写。大多数开发人员熟悉各种流行的单元测试框架和相关的OO编程语言中的一种。该方法允许以OO风格对流程的交互进行编程。利用该方法，程序开发人员不再需要关心测试中的XML文档操作、接口、绑定和服务细节。对于那些不熟悉在该测试工具中所选择的OO语言的业务流程编程员，可视化的测试例编辑器可以帮助他们克服障碍。

4)该方法加速了测试执行。具体地，该方法允许“一次部署，多次测试”。被测试流程仅被部署一次来运行所有与该流程相关的测试例。相比之下，利用桩流程(stub process)来仿真伙伴流程的那些现有的方法中，对桩流程的任何修改都要求流程重新部署以及服务器重新启动。

附图说明

从下面结合附图对本发明优选实施例的描述，本领域的技术人员可以更清楚地理解本发明的进一步目的、特征和优点，其中：

图1说明了在根据本发明的业务流程单元测试方法中，业务流程的WSDL描述与面向对象的语言的描述之间的关系；

图2示出了根据本发明的业务流程单元测试方法的流程图；

图3示出了根据本发明的业务流程单元测试工具的体系结构；

图4示出了作为本发明运行实例的购买流程的示意图；

图5示出了在作为本发明运行实例的购买流程与其伙伴流程提供的接口的示意图；

图6A为业务流程合成模型，以抽象的方式表示出了被测试业务流程与其伙伴流程之间的交互；

图6B为根据本发明的、对图6A中所示的业务流程进行单元测试的业务流程单元测试模型。

图7A示出了业务流程内的同步；

图7B示出了业务流程间的同步；

图8出了在JUnit测试运行程序中运行业务流程测试例的屏幕显示。

具体实施方式

在本申请中，使用BPEL流程作为例子来描述本发明。但是，本领域的技术人员可以理解，该例子仅仅是用于说明的目的而非用于限制。本发明同样可以应用于其他Web服务业务流程编程语言中的业务流程的单元测试。

由业务流程提供的Web服务接口在WSDL(Web Service DescriptionLanguage，Web服务描述语言)文件中、并且优选地在XSD语言文件中描述。图1中示出了典型的WSDL文件的结构。WSDL文件包含下列元素：类型(type)、消息(message)、端口类型(portType)、绑定(binding)和服务(service)。“端口类型”聚集了一组可以被服务请求方调用的操作，“类型”和“消息”定义提供操作的数据模型。“绑定”为一个特定的端口类型给出协议和数据格式规范，而“服务”则声明了与所定义的绑定相关的寻址信息。

本发明的核心思想是：将利用Web服务调用的流程交互转换为利用方法调用的类协作(class collaboration)，然后在业务流程领域应用面向对象的测试技术。

图2中示出了根据本发明一个优选实施例的业务流程单元测试方法20的流程图。

该方法20在步骤201开始。在该步骤中，将被测试流程(Processunder test，PUT)及其伙伴流程的关键的WSDL元素映射为面向对象(OO)的语言中的等效元素。该步骤的目的是将有关流程的每个Web服务接口定义映射为等效的OO表示。所述的映射包括两部分：将Web服务接口(图1中用A表示)映射为OO接口/类(图1中用C表示)，以及将Web服务类型和消息映射为OO数据类型类(data type class)。OO数据类型类将被用于定义OO测试程序中的测试数据。OO接口/类将被用于产生接口/类的OO模拟对象(图1中用E表示)，后面将对其进行说明。每个WSDL操作(图1中用B表示)将具有包含在适当的OO接口/类(C)中的对应的OO方法(图1中用D表示)。WSDL中的操作“输入”与OO方法中的“输入”相对应，WSDL中的操作“输出”与OO方法中的“输出”相对应，而WSDL中的操作“故障(fault)”与OO方法中的“异常(exception)”相对应。

接下来，在步骤202，根据图1中所示的OO接口/类(C)生成“伙伴桩(partner stub)”。一个伙伴桩类(图1中用F表示)实现/继承步骤201中导出的接口/类(C)。具体地说，伙伴桩动态地获得对服务进行仿真的模拟对象(E)，并调用模拟对象(E)的对应方法(D)，收集返回值(如果不为空)，并返回该值。以这种方式，伙伴桩实际上是真实服务提供者实现的模拟对象(E)的简单的包装。模拟对象的确切行为可以在测试例中动态地定义，这将在下文中详细地描述。这些伙伴桩是无状态的(stateless)并且与测试行为无关，并且可以根据在步骤201中得出的接口/类(C)自动生成。伙伴桩的地址将在对应的WSDL服务定义中引用，使得Web服务操作(B)的调用将去往正确伙伴桩(F)的正确的方法(D)。通过这种方式，一个伙伴桩及其相关的模拟对象共同实现一个仿真的伙伴流程。该伙伴桩实现一个简单的转发(relay)逻辑并且是在测试执行之前生成的静态部分，而模拟对象将定义测试逻辑并且是将在测试执行过程中生成的动态部分。这与当前使用的桩流程的区别在于，桩流程包含真实的测试逻辑，并被直接连接到被测试流程，因此必须编写并维护大量的桩流程，并为每个测试场景重新部署和重新启动这些流程。在本发明中，通过将责任分配到一个伙伴桩和一个模拟对象上，可以获得利用单个伙伴桩动态地改变测试逻辑而不需重新部署和重新启动的好处。

然后，在步骤203，定义测试特定的(test-specific)WSDL绑定和服务端点。伙伴流程的原始的WSDL绑定和服务端点可能是不同的：SOAP，JMS，EJB等。对于单元测试，所有的伙伴流程将被仿真为本地服务。因此选择一个更有效的绑定。本地OO语言绑定，例如Java绑定(WSIF，Web Service Invocation Framework)是优选的，只要开发环境支持这种绑定。如果没有这种支持，则可以利用另一种绑定，例如SOAP绑定。这样，WSDL服务定义应当将其端点设置为适当的伙伴桩(F)的地址。

接下来，在步骤204，基于面向对象的单元测试框架形成测试例。一个测试例定义被测试流程的一个执行路径并包含用来实现特定测试目的的所有测试逻辑。测试逻辑可以人工编写。在一个优选实施例中，测试逻辑也可以(半)自动地生成。具体地说，可以先通过一个测试生成器生成测试例的骨架，然后再完成测试例的编写。为了完整地测试一个业务流程，在测试逻辑表示中，以下的两种能力a)和b)是必不可少的。

a)测试逻辑表示应该能够描述两个方向的服务调用。一个方向是从PUT到伙伴流程，即，PUT调用由伙伴流程提供的服务。另一个方向是从伙伴流程到PUT，即，伙伴流程调用由PUT提供的服务。

对于从PUT到伙伴流程的调用，可以用模拟对象来对调用的流程进行仿真。为此，在本发明的方法中，利用了MockObjects项目(MO)。MockObjects是一种用于建立面向对象的软件的测试优先的开发过程以及一个支持该过程的通用单元测试框架，其中，将一系列预期的方法调用连同预定义的返回值记录在接口/类模拟对象(mock object)上。利用这种方法，可以在模拟对象中设定预期的请求消息和响应消息，其随后将被用来验证实际的请求消息并用预定的响应消息进行响应。接口/类的模拟实现作为模仿真实实现的外部行为的虚拟的实现，它也观察其他对象如何与其方法进行交互并对实际行为与预设的预期行为进行比较。当发生不一致时，模拟实现将产生一个报告。这样，MockObjects通过被测试单元的协作类来测试该被测试单元。

EasyMock(EM)是MockObjects的一种实现，并具有用于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[0])；  (5)

         control.verify()；                                           (6)

    }

}

EasyMock的使用分四个步骤：创建、记录、重放(replay)和验证。首先，需要创建模拟实现(mock implementation)，其包括目标接口/类的MockControl对象(1)和模拟对象(2)。MockControl对象(1)控制其相关的模拟对象(2)的行为。然后记录对模拟对象的预期方法调用并设置可能的返回值或异常(3)。在replay()方法(4)中激活模拟对象，MockControl对象开始重放记录的场景。然后操作ClassUnderTest(5)，假定其协作类已经实现。最后，调用verify()方法来检查是否有差别。

另一方面，对于从伙伴流程到PUT的调用，情况则有所不同，因为PUT是真实的，因而不需要被仿真。但是，仍然必须定义发送给PUT的请求消息以及来自PUT的预期的响应消息。可以采用几种不同的方法实现该步骤。根据本发明的一个优选实施例，利用模拟对象来存储调用信息，但需要引入一个服务代理。该服务代理将利用在一个模拟对象中定义的请求和预期的响应来调用PUT服务并验证实际的响应。这需要对通常的MockObjects实现进行修改。该方法的优点是，测试者可以具有利用模拟对象编写两个方向的测试逻辑的统一的视角，而不是针对一个方向利用模拟对象而针对另一方向利用另一组API。

b)测试逻辑表示必须能够描述被测试业务流程中的并发行为和同步约束。利用MockObjects，有几种方法可以支持该能力。根据本发明的一个优选实施例，利用MockObjects当前的功能并对其进行扩展来描述这种复杂的顺序关系，如下文中将要说明的。

接下来，在步骤205中执行测试例。在测试例执行前，部署该被测试流程PUT并且启动应用服务器。随着测试的执行以及在测试之后，记录的测试逻辑被重放和验证。意外的行为被报告给用户。然后，与任何现有的测试方法一样，测试人员对测试结果进行分析并采取相应的处理。

前面结合图1和图2所描述的根据本发明的业务流程单元测试方法20可以以多种编程语言实现、平台、体系结构实现。图3中示出了根据本发明一个实施例的业务流程单元测试工具30的体系结构，该体系结构反映了该单元测试工具30的核心功能。

图3示出了构成单元测试工具的主要组件(component)以及在这些组件之间流动的软件产物(artifacts)。其中方形框表示软件产物，椭圆形框表示组件，菱形框表示可能需要人工参与的任务，被虚线包围的框则表示可选的组件和软件产物。如图3所示，这些组件和软件产物被组织为与业务流程单元测试中的四个基本阶段即准备阶段、设计阶段、执行阶段和分析阶段对应的四个组。具体地说，在准备阶段中，包括组件WS2OO转换器312和伙伴桩生成器314，分别用于根据PUT源311生成OO接口/类315和伙伴桩317。在本发明的一个优选实施例中，该测试工具30还包括测试生成器313，该测试生成器313将PUT流程脚本311作为输入，并自动产生一组测试例骨架316，这些测试例骨架316包含骨干测试逻辑和所需的数据约束。这些测试例骨架316将在设计阶段完成。在设计阶段，用户编写一组可执行的测试例324(从头开始编写，或者基于上述骨架316)。在编写过程中，可以利用由标记321总地表示的一些现有的单元测试框架如xUnit(“xUnit”是用于Java的JUnit、用于.Net的NUnit等的通称)和MockObjects。为了将这些框架321应用到根据本发明的业务流程测试，需要功能扩展，如下文中将详细描述的。在本发明的一个优选实施例中，该测试工具30还包括一个测试例编辑器323，以允许进行图形化测试例创作。在执行阶段，该测试工具30包括具有可能扩展的xUnit运行程序或其他能够执行xUnit测试例的测试例执行器组件331，该组件331用来来执行测试例324，并产生包括测试报告和日志文件的测试结果332。在执行阶段收集的该测试结果332然后在分析阶段被评估，以形成修改的计划343。可选地，该测试工具30还包括一个日志阅览器组件341来对测试执行轨迹进行可视化显示。

该工具30可以被实现为用于业务流程开发的IDE中的一个插件，或者作为独立于业务流程IDE的单独工具。

为了使本领域技术人员进一步理解本发明，下面将BPEL规范中介绍的购买流程作为本发明的运行实例进行说明。图4中示出了该流程在IBM公司的WSADIE(Websphere工作室应用开发集成版)中的实现方式。图4是该流程脚本的图形形式。

该购买流程如下面所述进行。当从顾客接到定单时，该购买流程与三个伙伴流程-装运、开发票和调度相通信来进行工作。它同时发起三项任务：请求装运、计算定单的价格、为该定单调度生产和装运。尽管一些处理可以同时进行，在这三个任务之间存在控制和数据相关性。具体来讲，需要装运价格来最终完成价格计算，需要装运日期来完成调度。当这三项任务完成时，可以进行开发票处理，并将发票发送给用户。

由该购买流程及其伙伴流程提供的接口在WSDL文档中定义为端口类型。图5中示出了其图形化表示。购买流程提供了三种端口类型：购买(Purchasing)、装运回调(ShippingCallback)和发票回调(InvoiceCallback)，每个端口类型具有一个操作。每个伙伴流程，装运、开发票和调度，分别提供一个端口类型：装运服务(ShippingService)、计算价格服务(ComputePriceService)和调度服务(SchedulingServiece)。

以下结合图6A和图6B描述根据本发明的基本测试模型。

被测试的业务流程-购买流程，与三个伙伴流程-装运、开发票和调度进行交互，每个伙伴流程又与其他的伙伴流程交互，从而形成一个流程网络。图6A抽象地表示出这个合成模型。被测试流程被简略地表示为PUT，其伙伴流程被简略地表示为PP。从单个流程的角度来看，它并不关心其伙伴是如何实现的，因为它通过在WSDL注释中规定的该伙伴的Web服务接口与每个伙伴进行交互。因此，伙伴可以是一个简单的无状态Web服务，或者是对几个Web服务/流程进行编排并将一个或几个Web服务接口暴露给调用方流程的复杂流程。将一个伙伴处理为通用的流程使得该方法适用于通用的测试例。

两个流程间的对话关系在伙伴链路中定义。每个伙伴链路定义两个“角色”名称，并列出每个角色在该对话中向另一个角色提供的Web服务接口。图6 A中利用箭头线来连接两个流程，表示服务调用/消息从源流向目标。例如，箭头线①表示从伙伴流程PP1对被测试流程PUT的服务的调用，箭头线④则表示从被测试流程PUT对伙伴流程PP1的服务的调用，依此类推。

图6B示出了根据本发明的、针对图6A中的流程合成模型的单元测试模型。该模型使用用于每个伙伴流程(PPi)的测试流程(TPi，i＝1，2，3)来仿真其行为。事实上，TPi仅描述了一个方向的交互，即，PUT调用伙伴PPi的服务。至于相反方向的交互，即伙伴PPi调用PUT的服务，在根据本发明的单元测试方法和工具中是通过服务代理601来完成的。原本发生在PPi中的PUT服务调用被委派给服务代理601，以便在测试逻辑中执行。这是由于模拟对象仅能描述调入(call-in)，而无法描述调出(call-out)。因此，根据本发明，提供了一个特殊的测试流程，称为“TP0”，其描述了对PUT的预期的服务调用及其预期的响应。服务代理使用该请求和响应，以便实际调用PUT并验证实际响应。

下面结合图7A和图7B描述在根据本发明的业务流程单元测试中的并发和同步。

在通常的流程行为及其与其他流程的交互中，服务调用遵循用编程控制结构表示的特定的顺序。BPEL定义了下列控制结构：sequence，flow，while和switch，等等。

因此，在对真实流程进行仿真的测试流程中，需要类似的控制结构来表示原始的活动。在业务流程单元测试中，一条测试逻辑应当仅描述PUT的一个执行路径，而复杂的行为如迭代和分支应该尽可能避免。但是，并发和同步是对执行路径施加的常见的排序约束，因而是不可避免的，必须在测试行为描述中支持。在图6B中，同步用虚线表示。该图中仅示出了测试流程之间的同步。实际上，测试流程内部也会发生同步。图7示出了这两种情况。图7A示出了流程内的同步，其中op1，op3，op6是并发的活动，op1必须在op4之前被调用；op5必须在op2和op4之后被调用。图7B示出了流程TP1与TP2之间的同步，其中op1必须在op5之前被调用。

利用这样的同步能力，图6A中所示的服务交互排序在如图6B所示的测试逻辑中得到了支持。例如，逻辑“首先调用PUT服务，然后调用TP3服务”得到了支持。

下面将对图3中示出的测试工具体系结构300的组件的具体实现方式进行说明。

1、WS2OO转换器

该WS2OO转换器组件312用于将WSDL映射为面向对象的语言的描述(例如Java，C#)。有关流程的每个Web服务接口将被映射为OO等效接口或类；而Web服务类型和消息映射为OO数据类型类。这里所说的“有关流程”是指图6A中所示出的那些流程，包括PUT及其中间伙伴流程。

WS2OO转换器的一种示例性实现方式，例如，WS2Java可以基于两种Java规范：JAX-RPC和JAXB。JAX-RPC规定如何将一个wsdl:portType元素映射为Java接口，其包括从相应的wsdl:portType的wsdl:operation子元素映射的Java方法。wsdl:input和wsdl:output消息被映射为Java方法参数或返回类型，而wsdl:fault消息被映射为Java异常(exception)。另外，将XML方案类型映射为Java在JAXB2.0中描述。

存在几种可用来进行WS2OO映射的程序，包括Microsoft公司的WSDL2Java，WSDL2C，和WSDL.exe，以及PocketSOAP实用套件。但是，本领域的技术人员可以理解，在实现一个测试工具时，有可能需要使该实现方式适应特定的业务流程编程语言的IDE和所使用的MockObjects实现方式。

下面的代码给出了作为本发明运行实例的如图5所示的购买流程的装运服务端口类型的映射的例子。

<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) throws

java.lang.Exception；

}

该映射的接口被用于两个目的：生成伙伴桩，以及用于生成模拟实现(mock implementation)。

2、伙伴桩生成器

伙伴桩是Web服务接口的一种实现。在运行中，可以通过调用伙伴桩来完成Web服务调用。这个关系在wsdl:binding和wsdl:service部分定义。对于购买流程的例子和一个伙伴桩ShippingServiceStub，绑定和服务信息在下面的代码示出。

<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元素规定ShippingServiceStub是服务端点。注意，在部署被测试流程以对其进行测试时，绑定和服务信息应该取代原先的信息。

伙伴桩并不真实地实现服务逻辑，而是将调用转送(relay)至同一web服务接口的模拟对象，然后将返回值传递给原始调用方，如加亮语句所示。简言之，被测试流程PUT在运行中实际调用的是模拟实现。为隐藏该复杂性，可以自动地生成伙伴桩并对用户隐藏。

3、EasyMock的使用和扩展

模拟对象的创建、记录和验证：映射的OO接口/类被用于创建模拟实现(模拟控制和模拟对象)。然后，在一个测试例中，在每个模拟对象上记录预期对应的伙伴流程将从PUT接收的方法调用的序列，并预先规定返回值。如果PUT在运行期间发出一个错误的调用(包括具有错误参数的方法调用，错误的调用号和顺序)，MockObjects的验证机制将报告该错误。

PUT或者伙伴流程的每个端口类型(定义web服务接口)具有一个模拟实现。因此，一个流程可以对应于几个模拟对象，其中的每一个针对一种端口类型。对于购买流程的例子，将有六个模拟对象：三个用于PUT(购买、发票回调和装运回调)，另外的每一个模拟对象用于每个伙伴流程-装运服务、计算价格服务和调度服务。

PUT和伙伴流程的差别：一个流程的一个模拟对象设置对该流程的预期的调用以及可能的返回值，并在运行中验证该预期的调用伴随着正确的参数而发生。例如，假设mockShip是ShippingService的模拟对象，利用mockShip.requestShipping(shipRequest)来设置具有参数(shipRequest)的requestShipping的预期调用，并利用setReturn Value(“Shipping Service”，shipInfo)来设置调用的返回值(shipinfo)。因此，这里利用模拟对象来对一个并不存在的伙伴流程所提供的服务进行仿真，即，何时请求一个服务，以及响应是什么。PUT在运行中将通过伙伴桩的转送来调用伙伴流程的模拟对象。

但是，对PUT的模拟对象的处理是不同的。利用针对真实存在的PUT的模拟对象不是用来仿真其行为，而是告诉服务代理对该PUT进行调用并检查该调用的可能返回值是否正确。在购买流程的例子中，例如，mockPurchasing是PUT购买接口的模拟对象。下面第一个语句告诉服务代理，应当调用具有规定参数的sendPurchaseOrder操作，而第二个语句则告诉服务代理检查PUT应当返回invoice作为响应。

mockPurchasing.sendPurchaseOrder(po，customerInfo)；

setReturn Value(“Purchasing”，invoice)。

服务代理代表在实际运行中进行服务调用的相关伙伴流程来完成上述操作，因为MockObject框架不允许模拟对象中的向外调用行为。当服务代理调用PUT时也调用模拟对象。这是表达测试逻辑的统一方式，使得所有交互被MockObjects内置验证功能验证，无论它是从PUT到伙伴流程还是相反。为了避免模拟对象语义上的混淆，根据本发明的一个优选实施例，可以在编写测试例时，也将PUT处理为不存在的流程。

模拟对象的修改：为了区分这两种类型的模拟对象，在测试工具的实现方式中必须采用适当的方法，例如，采用一个配置文件，来从伙伴流程的模拟对象中识别PUT服务的模拟对象。需要对MockObjects进行修改来向服务代理通知特定的模拟对象和相关的方法调用。

实现服务代理：服务代理与PUT之间的接口可能是不同的。在一个优选实施例中，利用由应用服务器提供的BPEL引擎API来调用PUT服务。

测试行为的支持：MockObjects可以提供一些灵活的行为描述和验证机制。例如，EasyMock具有三种类型的MockControl。其中一种普通的控制不检查预期方法调用的顺序。另一种较为严格的控制将检查预期方法调用的顺序。对于这两种控制类型，对模拟对象的意外的方法调用将导致AssertionFailedError。剩下的一种是上述普通控制的较松散的版本，它不检查预期方法调用的顺序，而意外的方法调用将返回一个空值(0，null，false)。

并发：这些预设的和特殊的MockControl类型可以用来表示两种基本的控制逻辑/方法调用排序：序列和随机(未排序)。以购买流程为例。如果希望从PUT到另一流程的几个服务调用按规定的顺序发生，可以采用严格的MockControl来生成该流程的模拟实现。除了序列和随机以外，还有一般的控制逻辑如alternative(switch)，定时器操作(开始定时器，超时)，以及并发(现有的MockObjects实现可能尚不支持)。理想的是，业务流程的测试需要MockObjects实现来支持一般的控制逻辑。一种可能的MockObjects实现可以利用UML活动或状态机(可以简化或扩展)作为模拟对象的行为模型。实际上，MockObjects实现应该支持并发和同步逻辑。为此，需要对现有的MockObjects实现进行扩展。根据本发明的一个优选实施例，采用的扩展方式是允许测试者通过采用指定方法m1，m2等的API syncMethods(m1，m2)来指定这几个方法的连续关系。

于是，对于图7A中所示的流程内并发和同步，该逻辑可以如下表示：利用普通的MockControl来生成模拟实现，使得方法调用为未排序的，然后通过利用例如下面所示的syncMethods()API来指定排序约束：

syncMethods(op1，op2，op5)

syncMethods(op3，op4，op5)

syncMethods(op1，op4)

对于图6B中所示的流程间并发和同步，该逻辑可以如下表示：利用严格的MockControl来为TP1和TP2生成模拟实现，从而检查对于每个模拟实现的方法调用是否被正确排序，例如op1先于op2先于op3，然后利用syncMethods(op1，op5)来指定TP1与TP2之间的同步。注意，不同的模拟对象在运行中是独立调用的，因而它们的行为是纯并发的，除非在它们之间置入了明确的同步。

MockObjects的另一种使用方式是对于所有伙伴流程使用单个模拟实现，而对于PUT使用单一的一个模拟实现。在MockObjects实现支持在一个模拟实现中对多个接口/类进行仿真的情况下，该方式可行。具体地，可以简单地对EasyMock进行扩展(修改CreateControl()API)来实现该目的。MockObjects的这种使用方式的优点在于，在测试例中需要管理和操作的模拟实现的数目较少。

4、测试生成器

在本发明中，测试生成器是一个可选的组件，其提供了一个高级的功能-从BPEL流程脚本生成测试例。这个功能是期望的，因为人工测试例设计是费时的，需要人工检查流程以识别不同的执行场景，并编写测试逻辑来表示这些场景。期望测试生成功能自动地找到执行场景并生成对应的测试逻辑，从而节约大量的测试设计时间，同时提高测试的完整性。本领域技术人员可以理解，测试生成也可以是部分自动化的，并作为一种辅助工具。例如，测试生成器可以用来生成测试例骨架，供测试人员在控制逻辑和数据值方面对其进行审查和改进。

5、测试例编辑器

该组件被用来提供可视化编辑支持以简化测试例设计。可能的编辑样式包括标准UML注释的序列范例和活动范例(可能简化或扩展)。测试人员绘制范例，然后这些范例被转换成所选择的OO编程语言的测试代码。

与OO编程代码相比，图形化编辑的优点是直观、易学，对于不熟悉OO编程语言的BPEL程序员尤其有用。这样，可以对BPEL程序员隐藏OO测试代码。

6、测试执行器

BPEL单元测试例可以用xUnit运行程序运行。例如，JUnit提供了文本和图形运行程序。图8示出了在JUnit测试运行程序中运行BPEL的屏幕显示。

7、日志阅览器

在执行测试后，测试结果集中在测试报告和日志文件中。测试报告例如可以采用xUnit“故障”报告的形式，而日志文件可以是运行PUT的应用服务器的日志文件或测试工具的日志文件。从这些信息可以重建事件轨迹，并且可以找到PUT代码中的故障原因。日志阅览器可以将事件轨迹以序列范例的形式可视化地显示。这有助于测试人员跟踪调查交互的细节并识别故障点。根据测试分析，可以得到PUT代码或/和测试例的修改计划。

本领域的技术人员可以理解，以上描述的根据本发明的测试工具中的各个组件可以由软件、硬件、固件或者其结合来实现。

另外，根据本发明的单元测试方法可以作为计算机程序实现在计算机可读介质上。这些介质包括但不限于光盘、磁盘、磁光盘、半导体存储器。

以上已经结合优选实施例对本发明的用于业务流程编程语言中的自动化流程的单元测试方法和工具进行了说明。本领域技术人员很清楚，这些实施例仅仅是用于说明的目的而非对本发明的限制。在不偏离本发明的精神和范围的情况下可以对这些实施例作出各种修改。