CN101286131B

CN101286131B - 服务测试方法和服务测试系统

Info

Publication number: CN101286131B
Application number: CN2007100917754A
Authority: CN
Inventors: 李中杰; 朱俊; 黄鹤远; 李实恭
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2007-04-09
Filing date: 2007-04-09
Publication date: 2010-06-09
Anticipated expiration: 2027-04-09
Also published as: CN101286131A; US20090007073A1; US8677327B2

Abstract

本发明提供了一种用于利用模拟体surrogate进行服务测试的方法和系统。所述服务测试方法包括步骤：根据需要模拟的服务的服务描述，为所述需要模拟的服务生成服务特定的模拟体；将所生成的服务特定的模拟体部署到运行时系统上；参考所生成的服务特定的模拟体，规定测试例，其中所述测试例包括测试配置；以及根据测试配置，在运行时系统上对所部署的模拟体的配置选项进行设置。在根据本发明的服务测试方法和系统中，可以对模拟体的参数进行动态配置，并不需要重新编译和部署，从而减少了设计和生成模拟对象的负担。

Description

服务测试方法和服务测试系统

技术领域

本发明总体上涉及软件测试领域，并且尤其涉及在面向服务的软件开发过程中利用模拟工具进行服务测试的技术。

背景技术

软件测试是计算机软件开发过程的一个重要组成部分，用来确认一个软件程序的质量或性能是否符合软件开发之前所提出的一些要求。软件测试是在将软件投入实际运行之前进行的对软件需求分析、设计规格说明和编码的检查，是软件质量保证的关键步骤。软件测试是为了发现错误而执行程序的过程。软件测试可以分为单元测试(unittest)和集成测试(integration test)，其中单元测试是对软件设计的最小单位、即模块进行的测试，而集成测试是对整个软件系统进行的测试，在按设计要求把通过单元测试的各个模块组装在一起之后，进行集成测试以便发现与接口有关的各种错误。

当今，面向服务的软件开发工作有两个重要的特征：分布式的，以及基于团体的(community-based)。这使得需要对尚未开发完成的实际服务进行模拟。设想在服务的单元&集成测试过程中的这样一个典型场景，其中，某些服务还没有实现，或者尽管实现了某些服务，但是它们存在于远程地点处，因此不能很容易地在本地对其进行配置和使用，在这种情况下就需要对这些实际服务进行模拟了。

服务模拟至少可以包括以下两个方面：功能方面和非功能方面。在功能方面，需要模拟实际服务对不同请求的响应，即对服务是否能够实现或完成预定功能进行模拟。在非功能方面，需要对服务的诸如性能、可用性、安全性、响应时间等之类的属性进行模拟。

在此需要说明的是，在本文中的服务可以指软件开发过程中具有预定功能的模块、进程等。

服务模拟的关键之处在于：为要测试(单元测试或集成测试)的实际服务提供准实际性的(quasi-realistic)执行环境。由于每个服务都需要处理各种使用场景(其中至少包括正常情况和异常情况)，以便对这些不同的场景进行测试，所以所模拟的服务应当易于在行为方面做出改变(即，具有多样性)，从而使得它们能够模拟出真实世界中所发生的各种不同场景。

下面的表1列出了依照当前的现有技术在实际的软件测试过程中使用的常用模拟方法(遵循面向对象的术语)。

表1

方法	特征	在测试过程中如何使用
方法	特征	在测试过程中如何使用	stub	-是存储在文件系统中的实际类的静态的简化实现方式，在调用时返回对特定请求的特定响应。-stub可以调用其它类的方法。-在stub实现方式&测试例中，测试逻辑(调用序列&输入-输出映射)是硬编码的。	-测试例(test case)独立于stub，测试例使用象stub的实际类。-为了模拟对象的不同行为，需要多个stub，或者需要针对不同的测试例修改stub。
mock	-它的行为可以通过可编程的方式来加以规定，包括输入-输出映射&调用排序。-mock提供了用于检验先前在测试例中设置的调用序列&输入-输出(映射)的内置工具。-mock对象不能调用其它对象的方法。	-测试例动态地创建和使用mock对象。	stub

“stub”用于表示对多个复合代码(complex code)的功能进行模拟的临时的和简单的程序代码。stub和实际的实现具有相同的方法定义，因此方法调用者可以用相同的方式使用它们。可以在http://blog. interface21.com/main/2007/01/15/unit-testing-with-stubs-and-mocks/中找到实际的类“Collaborator”和其stub的一个例子。stub是实际代码逻辑的简化的和部分的实现，通常情况下它仅仅描述了用于特定输入消息的输出消息。

“mock”(可参见http://www.easymock.org/)用于表示使用预先定义的应用编程接口(API)的一种特殊类型的模拟机制。首先，mock对象是在运行时创建的，并且它们的行为也是如此(即，对于什么样的请求，产生什么样的响应)。其次，mock提供了用于测试验证的内置机制。

有关mock和stub的单元测试的更多细节，也可参见：http://blog. interface21.com/main/2007/01/15/unit-testing-with-stubs-and-mocks/。

简单来说，mock与stub之间的主要区别在于：与其中检验逻辑必须是硬编码的stub相比，mock预先定义了使测试逻辑编写更为容易的检验(断言)工具。

但是，stub和mock在行为方面都不具有多样性。stub是实际对象的简化实现方式，并且在行为方面没有足够的多样性。复杂的测试逻辑通常需要许多stub以及许多模拟代码，并且难以对其进行管理。在特定的测试例中，mock的行为也是固定的，其代表特定的测试序列。

此外，利用stub和mock，都不能很容易地对服务的非功能方面进行模拟。换句话说，它们都没有被设计为处理非功能模拟。

此外，mock还具有下述不利之处：mock对象不能在外部调用方法，这使得它不适合于用在其中要求mock对象启动对其它对象的调用的集成测试过程中。

发明内容

在下文中给出了关于本发明的简要概述，以便提供关于本发明的某些方面的基本理解。应当理解，这个概述并不是关于本发明的穷举性概述。它并不是意图确定本发明的关键或重要部分，也不是意图限定本发明的范围。其目的仅仅是以简化的形式给出某些概念，以此作为稍后论述的更详细描述的前序。

本发明的目的之一在于，提供一种被称为“模拟体”、即surrogate的模拟工具对服务进行模拟，从而克服以上所述的利用stub和mock进行模拟时所存在的问题。

本发明的另一目的在于，提供一种在对面向服务的软件开发过程中利用模拟体surrogate对服务进行模拟从而进行服务测试的测试系统和相应的测试方法，其能够解决现有技术中所存在的上述问题。

本发明的再一个目的是提供相应的计算机程序、计算机程序产品和计算机可读存储介质。

为了实现上述目的，根据本发明的一个方面，提供了一种用于利用模拟体进行服务测试的方法，包括以下步骤：根据需要模拟的服务的服务描述，为所述需要模拟的服务生成服务特定的模拟体；将所生成的服务特定的模拟体部署到运行时系统上；参考所生成的服务特定的模拟体，规定测试例，其中所述测试例包括测试配置；以及根据测试配置，在运行时系统上对所部署的模拟体的配置选项进行设置。

根据本发明的另一个方面，还提供了一种用于利用模拟体进行服务测试的系统，包括：模拟体生成器，根据需要模拟的服务的服务描述，为所述需要模拟的服务生成服务特定的模拟体；部署器，用于将所生成的服务特定的模拟体部署到运行时系统上；规定装置，用于参考所生成的服务特定的模拟体，规定测试例，所述测试例包括测试配置；以及设置装置，用于根据测试配置，在运行时系统上对所部署的模拟体的配置选项进行设置。

依据本发明的其它方面，还提供了相应的计算机程序、计算机可读存储介质和计算机程序产品。

本发明的一个优点在于，根据本发明提供的模拟体surrogate可以在运行时进行动态配置，并且优选地还可以具有以下几个功能中的一个或几个功能，所述功能包括但不局限于：功能模拟、非功能模拟、统计功能和日志记录功能。也就是说，模拟体surrogate可以提供比sub和/或mock方法更多的功能。

本发明的又一个优点在于，在根据本发明的服务测试方法和服务测试系统中，对于一个尚未开发完成的需要模拟的服务而言，只需要生成一个服务特定的模拟体surrogate并将其部署到运行时系统中，并且参考所生成的模拟体surrogate的配置信息编写测试例，然后在测试例的执行过程中对模拟体surrogate的参数进行设置或赋值，从而生成具体的模拟体surrogate。也就是说，在根据本发明所执行的测试过程中，不需要象在stub和/或mock方法中那样为某一个要模拟的服务生成多个模拟对象，而是可以对模拟体surrogate的参数进行动态配置，并不需要重新编译和部署，从而减少了设计和生成模拟对象的负担。

本发明的另外一个优点在于，模拟体surrogate可用于支持多种测试场景，包括服务单元测试和服务集成测试，而mock方法仅用于单元测试中模拟被测试对象的外部交互。

通过以下结合附图对本发明的最佳实施例的详细说明，本发明的这些以及其他优点将更加明显。

附图说明

本发明可以通过参考下文中结合附图所进行的描述而得到更好的理解，其中在所有附图中使用了相同或相似的附图标记来表示相同或者相似的部件。所述附图连同下面的详细说明一起包含在本说明书中并且形成本说明书的一部分，而且用来进一步举例说明本发明的优选实施例和解释本发明的原理和优点。在附图中：

图1(a)和(b)分别示出了现有技术中一个典型的服务单元测试场景和服务集成测试场景；

图2示出了根据本发明一个实施例的模拟体surrogate的示例性实现方式；

图3示出了根据本发明一个实施例、使用模拟体surrogate进行服务模拟的服务测试方法的流程图；

图4示出了根据本发明一个实施例、使用模拟体surrogate进行服务模拟的服务测试系统的示意性方框图；以及

图5示出了在本发明的一个实施例中使用的要进行测试的示例性应用。

本领域的技术人员应当理解，附图中的元件仅仅是为了简单和清楚起见而示出的，而且不一定是按比例绘制的。例如，附图中某些元件的尺寸可能相对于其他元件放大了，以便有助于提高对本发明实施例的理解。

具体实施方式

在下文中将结合附图对本发明的示范性实施例进行描述。为了清楚和简明起见，在说明书中并未描述实际实施方式的所有特征。然而，应该了解，在开发任何这种实际实施例的过程中必须做出很多特定于实施方式的决定，以便实现开发人员的具体目标，例如符合那些与系统及业务相关的限制条件，其中这些限制条件会随着实施方式的不同而改变。此外，还应该理解，虽然开发工作有可能是非常复杂和费时的，但对得益于本公开的本领域技术人员来说，这种开发工作仅仅是例行的任务。

在此，还需要说明的一点是，为了避免因不必要的细节而模糊了本发明，在附图中仅仅示出了与根据本发明的方案密切相关的装置结构和/或处理步骤，而省略了与本发明关系不大的其他细节。

图1中的(a)和(b)分别示出了一个典型的服务单元测试场景和服务集成测试场景。如图1所示，在面向服务的软件开发过程中，存在两种常见的测试场景：对单个服务的测试(即，服务单元测试)；以及对多个服务的集成测试(即，服务集成测试)。对于上述这两种场景而言，都可以进行性能测试。对服务单元测试来说，可以测试单个服务的性能；而对服务集成测试来说，可以集成地测试多个实际服务的综合性能。

在图1中，用带阴影线的方框表示已经开发完成了的服务(即，软件测试中的一个模块)，例如，图1(a)中的服务S2、图1(b)中的服务S1和S3，而用不带阴影线的方框表示尚未开发完成的服务，例如，图1(a)中的服务S1、S3和S4以及图1(b)中的服务S2。

在软件测试情况下，在对已经开发完成了的服务(即，实际服务)进行测试的过程中需要对尚未开发完成的服务进行模拟。具体来说，如图1(a)所示，对实际服务S2的单元测试要求对服务S1、S3和S4进行模拟。这个模拟应当能够产生不同的输入以便与服务S2进行交互。此外，如图1(b)所示，对实际服务S1、S3的集成测试要求对服务S2进行模拟。在接收到来自服务S1的调用时，服务S2将调用服务S3。

下面结合图2对模拟体surrogate进行进一步的具体说明。

图2示出了根据本发明一个实施例的模拟体surrogate的示例性实现方式。

根据本发明的模拟体surrogate可以由测试人员根据需要进行动态配置。优选地，本发明中的模拟体surrogate还可以具有以下优点中的一种或多种：(1)具有内置的多样性，可以很容易地进行功能行为模拟；(2)可以进行NFR(non-functional requirement，非功能需求)仿真/断言；(3)具有统计以及日志记录的功能。

如图2所示，在模拟体surrogate中使用了四个阶段来分别实现功能模拟、非功能模拟、统计功能和日志记录功能，其中虚线框表示在每个阶段中所需要的配置信息。

但是，需要说明的一点是，虽然图2中分四个阶段示出了模拟体surrogate在四个方面的主要功能，但是它并不意味着模拟体surrogate需要同时具备这四个主要功能，或者在实际的软件测试过程中需要同时使用这四个主要功能，而且也不一定意味着这四个主要功能之间的实际执行顺序，测试人员完全可以根据实际需要以适当的顺序选择使用其中的某些或全部功能。

概括来说，模拟体surrogate可以在以下几个性能方面对stub和mock对象进行了扩展：

(1)模拟体surrogate可以具有内置的行为规范方法集。测试人员可以利用单个模拟体编写大量具有不同测试目的的测试例，而不需要编写或生成多个模拟体。然而，在利用stub和/或mock的情况下，由于它们的行为是固定的，所以对于不同的测试目的需要有很多的stub和/或mock对象。

(2)可以利用模拟体surrogate对实际服务的非功能方面进行仿真/断言。在服务的NFR测试过程中使用模拟体是非常有用的。

(3)可以对诸如“调用次数”之类的数据或参数进行统计，也是模拟体surrogate中的内置功能之一。统计信息可以用来获得特定服务的使用模式，然后基于该使用模式对模拟体或实际服务行为进行调整。例如，如果发现模拟体的某一特定服务操作被调用得最为频繁，则需要对这种操作的性能进行优化。模拟体surrogate还支持日志记录功能，从而使得能够收集测试追踪以便用于以后的分析。

(4)模拟体surrogate的所有上述这些能力都是可配置的，即，可以通过动态配置来使用同一模拟体规定不同的测试逻辑。这种可配置性是在生成模拟体时内置的。测试人员不需要人工地对这种可配置性进行编码。模拟体可以被存储在文件系统中，并且可以与服务发布一起进行分配，并且可以进行其它诸如运行时服务使用统计&日志记录之类的测试相关活动。

在此，需要强调的一点是，模拟体surrogate的上述这几个方面的性能不一定是同时存在的。

可见，模拟体surrogate是一种有价值的、允许分布式的、基于团体的服务的开发和测试的方法。

模拟体surrogate是一种特别针对软件测试而提出的新的模拟工具。它的关键特征包括以下特征中的一个或者多个：具有多样性的功能行为，进行NFR仿真，进行统计，和进行日志记录。此外，所有这些能力都是可配置的，并且不是必须硬编码的。利用上述这些特征，模拟体可以用在各种类型的测试过程(包括功能的、非功能的)中，并且极大地降低了开发和管理大量stub和mock所需的测试努力。

服务提供商可以把模拟体分发作为用于服务使用者的实际服务的测试版本，以便在他们自己的开发环境下评估实际服务的功能和非功能方面是否可以满足要求。因此，与stub和mock相比，模拟体surrogate并不是用后可扔型的，而是在以后的关键性服务开发场景中可以被重新使用。

下面将分别针对模拟体surrogate的几个主要功能进行进一步说明。

假定服务的定义遵循下述这种结构：

-Service1

-Interface1

Output Operation1(Input)

Output Operation2(Input)

-Interface2

功能模拟

对于模拟体surrogate的功能模拟方面，下面仅仅描述了作为参考实现方式的两种行为模拟机制：输入/输出映射表(IOTable)和有限状态机(FSM)。

对于每个接口的每个操作，可以有几个这种输入/输出映射表，并且由测试例决定使用其中的哪一个。

表2 输入/输出映射表

每条复杂的消息可以被扩展为允许用户设置每个字段的评价模式。用于整条消息的“随机”模式等于用于该信息的每个字段的“随机”模式。

表3 有限状态机(FSM)

	Self.Interface1.operation2.input1	Self.Interface1.operation2.input2
	Self.Interface1.operation2.input1	Self.Interface1.operation2.input2	1	Action＝Service_x.interface_y.operation_z.input_1，Next_state＝2	Action＝..，Next_state＝...
2	Action＝Service_x.interface_y.operation-z.input_1，Next_state＝2	Action＝..，Next_state＝...	1		Action＝..，Next_state＝...
2		Action＝..，Next_state＝...	3	Action＝Self.Interface1.operation2.FaultOutput1，Next_state＝ExceptionState	Action＝..，Next_state＝...

在表3中，行表示状态，列表示输入。矩阵中的元素表示在被调用时服务操作的动作：启动另一个调用，以及转变到下一个状态。

表3的第二列表明：在状态1下接收到对Self.Interface1.operation2.input1的调用时，会调用Service_x.interface_y.operation_z.input_1，并且转变到状态2；在状态2下接收到Self.Interface1.operation2.input1的调用时，会调用Self.Interface1.operation2.input1的调用时，会调用Service_x.interface_y.operation_z.input_1，并保持在状态2下；在状态3下接收到Self.Interface1.operation2.input1的调用时，会返回Self.Interface1.operation2.FaultOutput1，并转变到状态ExceptionState(异常状态)。

在表3的第三列中示出了各个状态对于另外一个输Self.Interface1.operation2.input2的转变情况，其与第二列所示的情况是相类似的，因此，为了避免重复，在此就不再详述了。

在此，需要说明的是，并不是所有的服务都可以用FSM进行定义。FSM的优点在于，它提供了一种描述服务行为的简单方式，但并不是一般的方式。一般性和简单性往往是一对矛盾的目标。

非功能模拟

在此仅仅描述了一种用于规定非功能模拟要求的机制——性能表，即PerfTable。

表4 性能表(PerfTable)

统计功能

在此仅仅描述了一种用于规定统计要求的机制——方法调用统计。

表5 方法调用统计

编号	Interface_x.Operation_y	过滤条件
编号	Interface_x.Operation_y	过滤条件	1	Operation1(操作1)	一些可能的过滤条件：输入参数的内容模式，输出参数的内容模式，调用者

其中，对统计的过滤规定了何时将会触发统计动作。表5只是列出了一些可能的过滤条件：输入参数的内容模式，输出参数的内容模式，调用者。如当对Operation1设置过滤条件“调用者＝Service1”时，表示只有当Service1发起Operation1调用时才会做统计。

日志记录功能

在此仅仅描述了一种用于规定日志记录要求的机制——方法调用日志记录。

表6 方法调用日志记录

编号	Interface_x.Operation_y	日志记录级别
编号	Interface_x.Operation_y	日志记录级别	1	Operation1(操作1)	错误/警告/信息/调试

其中，日志中的级别用于规定详细级别，例如，“错误”级别表示只对该操作调用过程中发生的错误进行日志。

以上仅仅是对模拟体surrogate的功能的几种常用实现方式进行了描述，但是本领域技术人员应当明白，也可以采用其它的方式来实现模拟体surrogate的相关功能。

下面结合图3至5对根据本发明使用模拟体surrogate对服务进行模拟从而进行服务测试的服务测试方法和服务测试系统进行说明。

图3示出了根据本发明的一个实施例、使用模拟体surrogate进行服务测试的服务测试方法300的流程图；图4示出了根据本发明一个实施例、使用模拟体surrogate进行服务测试的服务测试系统400的示意性方框图；而图5示出了在本发明的一个实施例中使用的要进行测试的示例性应用。

如图4所示，服务测试系统400主要包括：服务描述410，模拟体surrogate生成器420，测试例430，部署器440，自动测试引擎450，运行时系统460。其中，运行时系统460进一步包括模拟体surrogate运行体470和模拟引擎480。

当然，根据实际情况的不同，服务测试系统400或者运行时系统460中可能还包括其他的组件，但是由于它们与本发明的关系不大，因此为了简单起见，在图4中并未示出这些组件。

服务描述410规定了要模拟的服务的诸如功能接口等之类的功能方面、以及诸如响应时间等之类的非功能方面。服务描述可以由测试人员根据实际需要利用现有的技术来自动编写或规定。

模拟体生成器420使用服务描述410作为输入，为要模拟的服务生成服务特定的模拟体。所生成的服务特定的模拟体继承了模拟体基类(即BasicSurrogate类)的功能，该模拟体基类提供了与模拟引擎进行通信并且模拟服务的行为的能力。除此之外，服务特定的模拟体还包括服务特定的代码，诸如用于模拟功能接口的代码。模拟体基类是模拟体开发包中预先实现的一个类，它提供了与模拟引擎进行通信并且模拟服务行为的基本能力，并且封装了相应的细节。模拟体生成器420根据服务描述生成服务特定的模拟体，其继承了模拟体基类，并且给出了服务描述中指定的接口的实现框架(具体的处理逻辑，将通过访问输入输出数据表进行模拟)，以及其他选择支持的特性，如响应时间等。

在执行测试例之前，由部署器440将所生成的服务特定的模拟体surrogate部署到运行时系统460上，从而在运行时系统460上产生模拟体surrogate运行体470。

测试例430中一般包括两个部分：TestConfiguration(测试配置)和TestBehavior(测试行为)。其中，测试配置规定了模拟体surrogate的配置选项，而测试行为则规定了测试例的执行路径。利用测试行为中所定义的每条测试路径，对模拟体surrogate的每个配置选项进行测试。其中，一个序列(Sequence)是一条要执行的路径，并且一个序列可以包括多个子序列(sub sequence)。此外，测试人员可以使用并发(parallel)或其它运算符来控制序列之间的时间关系。

对于模拟体surrogate而言，测试人员可以通过使用外部配置信息(ECI)来规定用于诸如功能、性能、统计分析等之类的特定格式。

此外，需要说明的一点是，在一个测试例中，对于相同的模拟体surrogate，可以有多个配置选项。

测试例430在执行前被部署到自动测试引擎450上，并且自动测试引擎450对运行时系统460上的模拟引擎480进行运行时配置。运行时配置可以包括功能方面(例如，输入输出数据对应表)和非功能方面(例如，响应时间的延迟)等。

模拟引擎480依据服务特定的模拟体surrogate的配置，对服务的功能方面和/或非功能方面的行为进行模拟。此外，模拟引擎还可以根据请求动态地改变模拟体surrogate运行体470的配置，从而在测试例的执行过程中为要模拟的服务生成具体的模拟体surrogate。

关于图4所示的服务测试系统400中的各个组件如何具体操作，在下文中将结合图3所示的服务测试方法300的流程图和图5所示的示例性应用进行进一步描述。

如图3所示，服务测试方法300在步骤S305中开始。然后，在步骤S310中，测试人员根据实际需要为测试过程中需要模拟的服务规定(或编写)服务描述，并且输入到图4所示的模拟体surrogate生成器420中。根据测试目的的不同，服务描述可以包括需要模拟的服务的功能方面、非功能方面、统计功能、日志记录功能、和/或它们的任意组合。

在步骤S315，由surrogate生成器420使用服务描述作为输入，生成相应的服务特定的模拟体surrogate。根据服务描述，surrogate生成器将生成服务特定的模拟体，其继承了模拟体基类，并且给出了服务描述中指定的接口的实现框架(具体的处理逻辑，将通过访问输入输出数据表进行模拟)，以及其他选择支持的特性，如响应时间等。

在步骤S320，由图4所示的部署器440针对不可用的服务(即，需要模拟的服务)向运行时系统460(如图4所示)部署所生成的服务特定的模拟体surrogate。

在步骤S325，测试人员根据实际情况，参考所生成的服务特定的模拟体surrogate，规定(或编写)测试例，在测试例中包括模拟体surrogate的测试配置和测试行为。

在步骤S330，将所规定的测试例部署到图4所示的自动测试引擎450上，并且在其上开始执行测试例。

在步骤S335，自动测试引擎450查找要测试的模拟体surrogate配置选项，并且通过模拟引擎480设置模拟体surrogate的配置。

接下来，在步骤S340，自动测试引擎450沿着测试例430的测试行为中所定义的测试路径执行测试行为。

然后，服务测试方法300的处理进行到步骤S345，判断是否有多个要测试的模拟体surrogate配置选项。

如果在步骤S345中确定还存在更多的要测试的模拟体surrogate配置选项，则处理流程会转回到步骤S335，由自动测试引擎450针对下一配置选项重复上述步骤S335和S340的处理过程。

如果在步骤S345中确定没有更多的要测试的模拟体surrogate配置选项，则处理流程会进行到步骤S350，自动测试引擎450结束测试例的执行，即，结束方法300的处理过程。

以上结合图3所示的流程图对根据本发明一个实施例的服务测试方法300的处理过程进行了描述，但是，应当明白，上述处理过程仅仅是示例性的，而且其中各个步骤间的执行顺序也仅仅是示例性的。在实际的测试过程中，根据实际情况的不同，可以对测试方法中的各个步骤及其执行先后顺序加以调整。例如，可以对步骤S320和S325的顺序加以调整，先执行步骤S325然后再执行步骤S320。

下面结合图5中所示的、在本发明的一个实施例中使用的要测试的示例性应用，通过举例对上述服务测试方法300和服务测试系统400的应用情况进行进一步的说明。

如图5所示，要测试的示例性应用的关键组成部分是Purchase(购买)进程。在图5中还示出了由Purchase进程和与其合作的进程所提供的接口。Purchase进程提供了三个接口：Purchasing、ShippingCallback和InvoiceCallback，并且每个接口都具有一个操作，分别为sendPurchaseOrder()、sendSchedule()和sendInvoice()。与Purchase进程合作的三个进程Ship、Invoice和Schedule也分别提供了一个接口，即，ShippingService、ComputePriceService和SchedulingService接口，并且ShippingService接口具有requestShipping()操作，ComputePriceService接口具有initiatePriceCalculation()操作和sendShippingPrice()操作，而SchedulingService接口具有requestProductionScheduling()操作和sendShippingSchedule()两个操作。

Purchase进程运行如下。在接收到来自客户的购买订单后，该Purchase进程和与其合作的三个进程Ship、Invoice和Schedule进程进行通信，以便完成其工作。它同时启动三个任务：请求发货，计算订单的价格，以及为订单的生产和发货制定计划。虽然其中的某些处理过程可以同时进行，但是这三个任务之间存在一定的控制和数据依赖性。特别是，需要知道发货价格才能最终完成价格计算，并且需要知道发货日期才能完成计划的制定。当这三个任务完成时，可以执行Invoice进程，以便将帐单发送给客户。

假定Ship进程将ShippingService接口定义如下：

public interface ShippingService{

public ShippingInfo requestShipping(ShippingRequest shippingRequest)

throws java.lang.Exception；

}

假定测试目标是对Purchase进程进行服务单元测试。此外，还假定Ship、Invoice和Schedule进程尚未被构建，因此，在测试过程中需要使用模拟体surrogate来对这三个进程进行模拟。

图4所示的测试系统400利用结合图3所描述的测试方法300，为Ship进程所生成的服务特定的模拟体surrogate如下所示：

public class ShipSurrogate implements ShippingService extends BasicSurrogate

{

public ShippingInfo requestShipping(ShippingRequest shippingRequest){

IOTable iot；

SurrogateConfiguration sc＝getConfiguration()；

iot＝loadIOTable(sc)；

ShippingInfo shipInfo＝(ShippingInfo)iot.getOperationReturn

(“requestShipping(ShippingRequest)”，shippingRequest)

Return(shipInfo)；

}catch(Exceptione){

thow(e)；

}

其中，getConfiguration()、loadIOTable()和getOperationReturn()这三个API可以作为函数在surrogate基类(即，BasicSurrogate)中实现，任何扩展的模拟体surrogate都可以使用它们来执行基本任务。getConfiguration()用于设置当前模拟体surrogate的配置文件，loadIOTable()用于把配置信息加载到运行时系统的存储器中，而getOperation Return()用于查找输入/输出表IOTable，以便获得具有给定参数的给定操作的响应值。

在测试过程中，为每个不可用的服务(即，尚未开发完成的进程)生成这样的模拟体surrogate，以便在随后运行的测试例中使用，模拟与Purchase进程相互作用的各个不可用服务。

下面给出了一个基于以上所定义的格式的具体测试例。使用下述这个测试例对Purchase进程进行单元测试。

<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>

</Surrogates>

</Option>

</Surrogates>

</Option>

</TestConfiguration>

<event name＝＂customerSendPO＂sourceComponent＝＂Customer＂

targetComponent＝＂Purchase＂interface＝＂purchasing＂operation＝＂sendPurchaseOrder＂

direction＝＂request＂data＝′PurchaseOrderRequest-data-reference′/>

<event name＝＂requestShipping＂sourceComponent＝＂Purchase＂targetComponent＝＂Ship＂

interface＝＂ShippingService＂operation＝＂requestShipping＂direction＝＂request＂

data＝′RequestShipping-data-reference′/>

<event name＝＂getShippingInfo＂sourceComponent＝＂Purchase＂

targetComponent＝＂Shipping＂interface＝＂ShippingService＂operation＝＂requestShipping＂

direction＝＂response＂data＝′ShippingInfo-data-reference′/>

</sequence>

<event name＝＂initPriceCalc＂sourceComponent＝＂Purchase＂targetComponent＝＂Invoice＂

interface＝＂ComputePriceService＂operation＝＂initiatePriceCalculation＂direction＝＂request＂

data＝′PurchaseOrderRequest-data-reference′/>

<event name＝＂sendShippingPrice＂sourceComponent＝＂Purchase＂

targetComponent＝＂Invoice＂interface＝＂ComputePriceService＂operation＝＂sendShippingPrice＂

direction＝＂request＂data＝′ShipInfo-data-reference′/>

<event name＝＂getInvoice＂sourceComponent＝＂Purchase＂targetComponent＝＂Invoice＂

interface＝＂ComputePriceService＂operation＝＂sendShippingPrice＂direction＝＂response＂

data＝′Invoice-data-reference′/>

</sequence>

<event name＝＂requestScheduling＂sourceComponent＝＂Purchase＂

targetComponent＝＂Schedule＂interface＝＂SchedulingService＂

operation＝＂requestProductionScheduling＂direction＝＂request＂

data＝′PurchaseOrderRequest-data-reference′/>

</sequence>

</parallel>

<event name＝＂customerGetInvoice＂sourceComponent＝＂Customer＂

direction＝＂response＂data＝′Invoice-data-reference′/>

</sequence>

</TestBehavior>

</TestCase>

这个测试例包含的<TestConfiguration>说明使用了3个模拟体surrogate，即，shipper、invoicer和scheduler，并且用function属性指出了各个模拟体surrogate使用的配置数据(后面会给出示例)。同一个模拟体surrogate的多组配置数据体现在多个<option>中，在测试运行时，对每组配置分别运行一次，提高了测试的覆盖率。

这个测试例包含的<TestBehavior>部分描述了测试序列。其中的每个<event>是一个service调用或者返回。<sequence>表示了顺序执行逻辑，<parallel>表示并发执行逻辑。在本例中，第一个event表示Customer发起对Purchase部件提供的sendPurchaseOrder()的调用，接下来，Purchase会并发的调用Ship，Invoice和Schedule这三个部件的服务，之后返回响应给Customer。简单的说，本测试例描述了一个完整的采购过程。

上述测试例用到的模拟体surrogate的功能配置如下所述。表7表示requestShipping()在接收到RequestShipping-data-reference引用的数据时，返回一个固定的值ShippingInfo-data-reference。表8表示initiatePriceCalculation()在接收到PurchaseOrderRequest-data-reference时不必返回任何值，因为这是一个单向的调用。其它表的含义显然。

表7 shipper_ECI_01的输入/输出表

(操作为“requestShipping”)

表8 invoicer_ECI_01的输入/输出表

(操作为“initiatePriceCalculation”)

表9 invoicer_ECI_01的输入/输出表

(操作为“sendShippingPrice”)

表10 scheduler_ECI_01的输入/输出表

(操作为“requestProductionScheduling”)

其中，在表8和表10中的“--”表示：无预期返回值，这是因为，上述调用为单向调用，因此不需要提供返回值。

在执行测试时，自动测试引擎450对测试例进行解析，并且从中读取测试配置和测试行为信息。然后，它通过使用API(例如，setConfiguration(字符串名称))，来使用测试配置信息对模拟体surrogate进行配置，然后逐个地执行在测试行为中规定的事件。测试引擎通过杠杆作用影响(leverage)运行时监控能力，以便获取服务之间的实际调用。如果在测试过程中发现了不一致(discrepancy)，则测试引擎将会停止执行测试过程，并且向测试人员发信号通知出现错误。

需要说明的是，以上仅仅是一个单元测试例，在集成测试例中可以使用相同的测试行为。例如，如果Ship进程是一个已经开发了的真实的组件，则对Purchase和Ship进程的服务集成测试将仅仅使用模拟体surrogate对Invoice和Schedule进程进行模拟。

虽然以上结合附图描述了根据本发明一个实施例的测试方法和测试系统，但是上述描述仅仅是示例性的而非限制性的，本领域技术人员完全可以在不背离本发明的范围的情况下根据需要对其进行修改或变化。

此外，显然，根据本发明的上述方法的各个操作过程也可以以存储在各种机器可读的存储介质中的计算机可执行程序的方式实现。

而且，本发明的目的也可以通过下述方式实现：将存储有上述可执行程序代码的存储介质直接或者间接地提供给系统或设备，并且该系统或设备中的计算机或者中央处理单元(CPU)读出并执行上述程序代码。

此时，只要该系统或者设备具有执行程序的功能，则本发明的实施方式不局限于程序，并且该程序也可以是任意的形式，例如，目标程序、解释器执行的程序或者提供给操作系统的脚本程序等。

上述这些机器可读存储介质包括但不限于：各种存储器和存储单元，半导体设备，磁盘单元例如光、磁和磁光盘，以及其它适于存储信息的介质等。

另外，客户计算机通过连接到因特网上的相应网站，并且将依据本发明的计算机程序代码下载和安装到计算机中然后执行该程序，也可以实现本发明。

最后，还需要说明的是，在本文中，诸如左和右、第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上虽然结合附图详细描述了本发明的实施例，但是应当明白，上面所描述的实施方式只是用于说明本发明，而并不构成对本发明的限制。对于本领域的技术人员来说，可以对上述实施方式作出各种修改和变更而不背离本发明的实质和范围。因此，本发明的范围仅由所附权利要求及其等效含义来限定。

Claims

1.一种用于利用模拟体进行服务测试配置的方法，包括以下步骤：

根据需要模拟的服务的服务描述，为所述需要模拟的服务生成服务特定的模拟体，所述模拟体可以通过动态配置规定不同的测试逻辑并且所述服务描述可以包括要模拟的服务的下列各项的一项或多项：功能方面、非功能方面、统计功能及日志记录功能；

将所生成的服务特定的模拟体部署到运行时系统上；

参考所生成的服务特定的模拟体，规定测试例，其中所述测试例包括测试配置；以及

根据测试配置，在运行时系统上对所部署的模拟体的配置选项进行设置。

2.根据权利要求1所述的服务测试配置的方法，还包括步骤：在运行时系统上对需要模拟的服务进行模拟，并执行所述测试例中规定的测试行为。

3.根据权利要求1所述的服务测试配置的方法，还包括步骤：为需要模拟的一个或多个服务规定服务描述。

4.根据权利要求2所述的服务测试方法，还包括步骤：

判断是否还存在更多的模拟体配置选项需要模拟；

如果确定还存在更多的模拟体配置选项需要模拟，则重复所述对模拟体的配置选项进行设置的步骤、所述执行测试行为的步骤和所述判断步骤，直到没有更多要模拟的模拟体配置选项为止。

5.根据权利要求1所述的服务测试配置的方法，其中，服务特定的模拟体继承了模拟体基类的功能。

6.根据权利要求1所述的服务测试配置的方法，其中，所述非功能方面包括服务的可用性、性能、安全性和响应时间中的一个或多个。

7.根据权利要求1到5中任何一项权利要求所述的服务测试配置的方法，可用于进行服务单元测试和/或服务集成测试。

8.根据权利要求1到5中任何一项权利要求所述的服务测试配置的方法，其中，服务是软件开发过程中具有预定功能的模块或进程。

9.一种用于利用模拟体进行服务测试配置的系统，包括：

模拟体生成器，根据需要模拟的服务的服务描述，为所述需要模拟的服务生成服务特定的模拟体，所述模拟体可以通过动态配置规定不同的测试逻辑并且所述服务描述可以包括要模拟的服务的下列各项的一项或多项：功能方面、非功能方面、统计功能及日志记录功能；

部署器，用于将所生成的服务特定的模拟体部署到运行时系统上；

规定装置，用于参考所生成的服务特定的模拟体，规定测试例，所述测试例包括测试配置；以及

设置装置，用于根据测试配置，在运行时系统上对所部署的模拟体的配置选项进行设置。

10.根据权利要求9所述的服务测试配置的系统，进一步包括：运行时系统，用于在其上对要模拟的服务进行模拟，并执行所述测试例中规定的测试行为。

11.根据权利要求10所述的服务测试配置的系统，其中，所述运行时系统包括模拟体运行体和模拟引擎，其中模拟体运行体是因向运行时系统部署模拟体而生成的，而模拟引擎用于对模拟体运行体的配置进行设置，对要模拟的服务进行模拟并且执行测试行为。

12.根据权利要求9所述的服务测试配置的系统，其中，服务特定的模拟体继承了模拟体基类的功能。

13.根据权利要求9所述的服务测试配置的系统，其中，所述非功能方面包括服务的可用性、性能、安全性和响应时间中的一个或多个。

14.根据权利要求9到12中任何一项权利要求所述的服务测试配置的系统，可用于进行服务单元测试和/或服务集成测试。

15.根据权利要求9到12中任何一项权利要求所述的服务测试配置的系统，其中，服务是软件开发过程中具有预定功能的模块或进程。