CN101482815B

CN101482815B - 生成软件系统的测试用例的方法和设备

Info

Publication number: CN101482815B
Application number: CN200810002615.2A
Authority: CN
Inventors: 谈华芳; N·M·米特苏莫里; 朱俊; 李中杰; 刘鹤辉
Original assignee: International Business Machines Corp
Current assignee: IBM China Co Ltd
Priority date: 2008-01-10
Filing date: 2008-01-10
Publication date: 2013-08-07
Anticipated expiration: 2028-01-10
Also published as: CN101482815A; US20090183143A1

Abstract

本发明公开了一种生成软件系统的测试用例的方法和设备，所述方法包括步骤：跟踪用户请求以得到与每个服务和/或组件调用相关的IT事件；基于IT事件中的关联信息形成IT事务；基于预定的关联规则关联所述IT事务以形成业务事务；以及从业务事务中抽取与所述业务事务对应的业务事务模式。所述方法还包括基于生成的业务事务模式生成软件系统的测试用例。

Description

生成软件系统的测试用例的方法和设备

技术领域

本发明一般涉及数据处理领域，以及更具体地，本发明涉及一种用于使用运行时跟踪来生成业务模式以及业务级别测试用例的方法和设备。

背景技术

长期以来，一直认为软件测试是系统开发活动的一个重要的并具有挑战性的部分。面向服务架构(SOA)的出现对软件测试提出了新的要求。SOA是一种粗粒度、松耦合的服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。在SOA中，服务之间通过简单、精确定义的接口进行通信，而并不涉及底层编程接口和通信模型。

基于SOA的软件测试与传统的软件编程环境相比，SOA主要存在以下特征：1)软件系统本质上是分布式的，这就要求针对不同的开发配置来确保服务质量(QoS)；2)系统通过替换单独的服务、或者通过添加新的服务来执行适应性的行为。

在传统软件测试中，需要结合使用单元测试、集成测试、系统测试和回归测试来确保所开发的系统完成了所期望的功能性。在面向服务的系统中，尽管同样可以使用适用于传统系统的各种测试方法，然而，对于SOA系统来说，SOA的动态性和适应性特征使得大多数测试技术并不能直接应用于测试服务和面向服务的系统。例如，大多数传统的测试方法假设，开发人员总是能够精确地识别出在给定调用点所调取的实际代码片段；或者，如同在面相对象的编程语言中，开发人员已知多态组件的所有的(有限的)绑定。这些假设对于SOA并不适用。在SOA中表现出的是，在开放的市场环境中实时发现服务、并且稍后绑定。

采用SOA之后，除了系统架构的改变，还在建立系统的过程之中引入了许多变化。SOA系统并非一次构建，而是需要多轮迭代来达到令人满意的质量。每轮迭代包括三个步骤：建立一个版本、对该版本进行测试、以及将该测试后的版本部署至生产环境。

SOA系统的动态性和适应性特征使得开发人员难以预知所有的使用配置，因而测试人员很难在第一轮迭代时设计出能够覆盖所有使用情形的测试用例集合。但是，使用情形的覆盖对于保证达到期望的用户质量水平非常重要。因而，针对未覆盖的实际使用情形来生成补充测试集合是确保SOA系统达到预期质量水平的关键。在下一轮迭代中，将向当前的测试集合加入在实际使用情形中存在但并不包含在当前测试集合中的测试用例。由此，如何发现未覆盖的实际使用情况并且将其补充到测试用例的集合之中，这成为了针对SOA的软件测试技术的研究重点。

一种可能的解决方案是，调节运行时跟踪信息以发现未覆盖的使用情形，并且然后针对未覆盖的使用情形来生成测试用例以补充测试集合。然而，在此存在以下挑战：1)如何从运行时跟踪信息来生成有意义的使用情形；2)如何控制测试用例的数量。从测试人员的角度看来，使用情形应该是用户与系统进行的有意义的交互序列。因而，需要一种方法来将用户与系统的交互相互关联。同时，由于测试人员不可能覆盖实际发生的所有情况，所以在覆盖使用情形的同时还需要控制测试用例的数量。

从上述分析中可知，在SOA系统的软件测试中，需要某些机制来定义使用情形的覆盖标准、并且降低测试用例的数量。

例如，AmberPoint提供了一种SOA运行时管理方案，其跨过不同的环境捕获网络服务(web service)消息，以便创建理想的阶段运行环境，创建实际响应来验证功能性，提供模仿实际分布的理想装载测试和容量计划情形，以及模拟集合或者部门直接控制以外的生产服务。然而，AmberPoint并不关心应用级别的业务使用情形，而是只关心网络服务自身。

另外，IBM的Tivoli ITCAM提供了运行时监控功能。Tivoli ITCAM针对一个用户请求跟踪服务/组件交互，这种针对一个用户请求的一组服务/组件交互称作IT事务。然而，Tivoli ITCAM并不提供用于形成业务事务的能力，以便形成对于业务级别的测试人员有意义的业务事务的功能性。

目前，现有技术中还不存在使用运行时跟踪来生成业务事务模式的方法，也不存在使用运行时跟踪来生成测试用例的方案。

发明内容

本发明的一个目的是通过运行时跟踪使用情形来生成业务事务模式。

本发明的另一个目的是通过运行时跟踪使用情形来生成业务级别测试用例，以便在下一轮迭代中最大限度地覆盖所有使用情形。

本发明的另一个目的是通过使用运行时跟踪而针对未覆盖使用情形来生成业务级别测试用例。该方法用于解决如何针对测试用例进行补充，以便在下一轮迭代中最大限度地覆盖所有使用情形。

根据本发明的一方面，提供一种用于生成软件系统的测试用例的方法，包括步骤：跟踪用户请求以得到与每个服务和/或组件调用相关的IT事件；基于IT事件中的关联信息形成IT事务；基于预定的关联规则关联所述IT事务以形成业务事务；以及从业务事务中抽取与所述业务事务对应的业务事务模式。

根据本发明的另一方面，本发明的方法还包括基于获得的业务事务模式生成软件系统的测试用例。

根据本发明的另一方面，提供一种用于生成软件系统的测试用例的设备。该设备包括：用于跟踪用户请求以得到与每个服务和/或组件调用相关的IT事件的装置；用于基于IT事件中的关联信息形成IT事务的装置；用于基于预定的关联规则关联所述IT事务以形成业务事务的装置；以及用于从业务事务模式中抽取与所述业务事务对应的业务事务模式的装置。

根据本发明的另一方面，本发明的设备还包括用于基于获得的业务事务模式生成软件系统的测试用例的装置。

附图说明

参考以下结合附图的详细说明，本发明的特征、优点以及其他方面将变得更加明显，在附图中：

图1示出了根据本发明的一个实施方式的用于生成业务级别测试用例的方法的高级概念图；

图2示出了根据本发明的一个实施方式的生成IT事务和业务事务的示意图；

图3示出了根据本发明的一个实施方式的生成业务事务模式的示意图；

图4示出了是根据本发明的生成业务事务和业务事务模式的一个实例；

图5示出了根据本发明的一个实施方式的用于生成业务级别测试用例的设备的高级框图；

图6示出了根据本发明的一个实施方式的用于生成业务级别测试用例的方法的流程图；

图7示出了根据本发明的另一实施方式的用于生成业务级别测试用例的方法的高级概念图；

图8示出了根据本发明的另一实施方式的用于生成业务级别测试用例的设备的高级框图；以及

图9示出了根据本发明的另一实施方式的用于生成业务级别测试用例的方法的流程图。

应当理解，在全部附图中，相同的参考标记表示相同的部件。

具体实施方式

为了清楚起见，首先对本发明中所使用的术语作以解释。

IT事件：计算机操作的记录，记录操作的上下文，包括所调取的服务、操作、参数值以及其他相关性信息。

IT事务：用户与机器进行的交互所引发的系统的一系列IT事件的集合，其开始于用户在浏览器界面上或者其他用户界面上点击按钮发送请求，并结束于在浏览器页面上或者其他用户界面上显示用户所请求的数据。

业务事务：完成一个有意义的业务活动(诸如，订货、购物、预订机票等等)的一组IT事务的组合。

业务事务模式：从业务事务中抽取的具有共同特征的业务事务的模版。

下面参考附图详细说明根据本发明的各个实施方式。

参考图1，其中示出了根据本发明的一个实施方式的用于生成业务级别测试用例的方法的高级概念图。

图1所示的方法包括两个跟踪流程，其一是针对生产阶段进行跟踪，而另一个是针对测试阶段进行跟踪。该方法从两条跟踪流程中分别抽取出两个业务事务模式集合。接着，将两个业务事务模式集合进行比较以发现未覆盖的业务事务模式集合。最后，针对未覆盖业务事务模式来生成相关的测试用例，并且将其补充至当前测试用例的集合中，以供下一轮测试使用。

具体地，如图1所示，测试环境110是测试人员对软件系统进行测试的测试环境。而生产环境120是用户在实际使用软件系统时所处的环境。

在开始第一轮测试之前，测试人员首先通过传统方法来生成用于第一轮测试的测试用例。在生产环境120中，通过正常生产使用122并对待测试软件系统进行生产跟踪124来形成基于生产环境的业务事务模式集合126，在此用符号“Y”来表示。在测试环境110中，针对测试用例112来进行测试跟踪114，以形成基于测试环境的业务事务模式集合116，在此用符号“X”来表示。

然后，在框132中，针对当前一轮测试，通过将基于测试环境的业务事务模式集合(X)116与基于生产环境的业务事务模式集合(Y)126进行比较来执行覆盖分析，即，计算(X/Y)×100％。

接着，在框134中，使用根据业务事务模式集合(Y)126与业务事务模式集合(X)116比较所得出的未覆盖业务事务模式集合(Y-X)，来对当前测试用例进行补充，然后执行下一轮回归测试。

下面将参考图2和图3详细描述根据本发明的用于生成业务事务模式的方法。

图2示出了根据本发明的一个实施方式的生成IT事务和业务事务的示意图。通常，在生成业务事务的过程中，涉及呈现层212、业务层214、服务层216和组件层218。如图2中的实线所示，在呈现层212处，通过用户交互UI1来调用资源A3，并且在这一过程中，分别涉及了业务层214中的资源B4、服务层216中的资源P5、组件层218中的资源E3。将这一系列资源进行关联以形成IT事务1221。同样，如图2中的虚线所示，通过用户交互UI4来调用资源A4，并且在这一过程中，分别涉及了业务层214中的资源B3、服务层216中的资源P2、组件层218中的资源E1。将这一系列资源进行关联以形成IT事务2222。通过分析发现，IT事务1221和IT事务2222两者根据设定的关联规则可以关联在一起，例如，具有相同的BPID(业务流程实例号)。这样，将IT事务1221和IT事务2222彼此关联以形成业务事务1232。

图3示出了根据本发明的一个实施方式的生成业务事务模式的示意图。如图3所示，分别从组件级别310、IT事务级别320以及业务事务级别330这三个级别示出了生成业务事务模式。

组件级别310包括三个组件C1，C2和C3，分别产生IT事件1311至IT事件6316。在IT事务级别320中，通过对用户请求进行跟踪，发现了上述IT事件1-3。从上文的定义中可知，IT事务是用户与机器进行交互的所引发的系统的一系列IT事件的集合，也就是一系列IT事件。其开始于用户在浏览器上发送请求，并结束于在浏览器页面上显示用户所请求的数据。每一个IT事件含有它当前的关联因子，如果它有前序的IT事件，则包含该前序事件的关联因子，称为父关联因子。根据关联因子之间的父子关系，可以把一组IT事件关联起来形成一个IT事务。这样，由IT事件1-3组成了IT事务1322和由IT事件4-6组成了IT事务2324。每一个IT事务在形成时，会把它对应的IT事件中的与关联规则相关的属性值提取出来，形成该IT事务的特征值。根据每个IT事务对应的特征值和关联规则，可以把一组IT事务关联形成业务事务。

如在业务事务级别330中所示，根据关联规则(例如流程实例ID或任务实例ID)，将IT事务1322与IT事务2324进行关联，可以形成与业务事务1332。

如在业务事务模式级别340中所示，将业务事务1中的IT事件都提取出来以形成业务事务1的业务事务模式。

应当理解，操作记录中的IT事件的数量是非常多。如果通过IT事件的任意组合生成测试用例，则测试用例数量过多，并且很多测试用例实际上没有含义。通过以上方式提取业务事务模式则可以找到IT事件有业务含义的组合。这样，通过这种方法查找到底IT事件组合能够用于生成有业务含义的测试用例，特别是生成以前未测试过的而实际应用中用到的情形。

下面将结合图4，详细说明如何形成业务事务模式。

首先，在中间件层加入跟踪代码来监视发生的IT事件。即，在待测试系统中的执行流程以及创建和完成任务的代码处加入监视代码。然后，根据预先设定的关联规则(在这里，假设当前的关联规则是根据TASK ID(任务ID)、BPID(业务流程实例ID)来进行关联)和业务事务的定义，记录以下IT事件的发生：

1)每个组件的调用，其中所述组件例如是JSP、Business Process、Web Service、EJB和SCA组件；

2)每个流程的启动和停止；

3)每个任务的创建、执行和完成。

每个IT事件都包含当前事件的上下文，即，上一个IT事件的关联因子(称为父亲关联因子)和当前IT事件的关联因子。在线程的上下文中保存当前线程发生的关联因子。当请求跨线程时，将当前的关联因子通过请求消息进行传递。

然后，在记录下所有的IT事件之后，根据关联因子把一组IT事件关联起来形成一个IT事务。具体地，首先找出没有父亲关联因子的事件，然后根据关联因子的传递关系(即，当前事件的父亲关联因子等于前一个事件的当前关联因子)将一组IT事件进行关联。一旦已经将一组IT事件关联成为一个IT事务，则将当前与该IT事务相关的IT事件中出现的BPID和TASK ID提取出来作为当前IT事务的一个特征值。

一旦形成所有IT事务，则根据关联规则来关联IT事务以形成业务事务。例如，如果IT事务对应的BPID或者TASK ID相等，则将其进行关联以形成业务事务。

一旦确定业务事务，则根据业务事务和IT事务、以及IT事务和IT事件的关系，提取所有的IT事件并形成一个调用序列作为该业务事务的业务事务模式。

如图4所示，以预订旅游行程为例来具体说明如何生成业务事务模式。在本例中，首先由客户发出预订旅游行程请求412。此时启动预订旅游行程流程422。接着，信用卡公司创建检查信用卡的任务414，并由工作人员完成该任务。然后，调用预定汽车组件432来订车、调用预定航班组件434来订机票、并调用预订酒店流程424来订酒店。该预订酒店的流程424继而调用酒店信息中心436组件来获取可用的酒店，并生成选择酒店的任务418。一旦用户完成选择酒店的任务，则预订酒店的流程424将调用相应的酒店组件(例如，酒店1组件442、酒店2组件444、酒店n组件446中的一个)来预订房间。最后告知客户预定结果416。

在如图4中所示的预订旅游行程的整个过程中，系统将生成如表1所示的IT事件。

表1

ID

描述

父关联

当前关联

特征值

		因子ID	因子ID
					1	启动预订旅游行程流程	Null	1	travelBookingBPID，
2	创建检查信用卡任务	1	2	creditcardTaskID，
					3	完成检查信用卡任务	Null	3	creditcardTaskID，
4	调用预定汽车组件	3	4
					5	调用预定航班组件	3	5
6	启动预订酒店流程	3	6	hotelReservationBPID
					7	调用酒店信息中心组件	6	7
8	创建选择酒店的任务	6	8	selectHotelTaskID
					9	完成选择酒店的任务	Null	9	selectHotelTaskID
1 0	调用酒店组件	9	10

根据表1中所示的对应关系，将1和2关联成为IT事务1，该IT事务1具有creditcardTaskID、travelBookingBPID的特征值；将3、4、5、6、7、8关联成为IT事务2，该IT事务2具有creditcardTaskID、hotelReservationBPID和selectHotelTaskID的特征值；并将9、10关联成IT事务3，该IT事务3具有selectHotelTaskID特征值。现在，得到如表2所示的三个IT事务。

表2

IT事务ID	特征值
		IT事务1	creditcardTaskID，travelBookingBPID
IT事务2	creditcardTaskID，hotelReservationBPID和selectHotelTaskID
		IT事务3	selectHotelTaskID

假设，当前的关联规则如下：

规则1：如果一个业务事务中包含的所有IT事务的特征值BPID或者TASK ID和某个待关联的IT事务中包含的BPID或者TASK ID相同，则把这个待关联的IT事务与该业务事务相关联；

规则2：如果不能将某个IT事务与已有的业务事务相关联，则生成一个新的业务事务，把该IT事务与这个新生成的业务事务相关联。

最初，当前系统中没有业务事务，因此将生成一个新的业务事务1，并把IT事务1关联到业务事务1中。此时业务事务1包含IT事务1，因为IT事务1和IT事务2包含相同的TASK ID：creditcardTaskID，所以将IT事务2与业务事务1相关联。此时，业务事务1中包含IT事务1和IT事务2。因为IT事务2和IT事务3包含相同的TASK ID：selectHotelTaskID，所以将IT事务3关联到业务事务1。由于并无其他可以关联的IT事务，则业务事务1的生成完成。

业务事务1为：IT事务1→IT事务2→IT事务3。

把每一个IT事务中对应的IT事件抽取出来形成对应于业务事务1的业务事务模式：

启动预订旅游行程流程→创建检查信用卡任务→完成检查信用卡任务→调用预定汽车组件→调用预定航班组件→启动预订酒店流程→调用酒店信息中心组件→创建选择酒店的任务→完成选择酒店的任务→调用酒店组件。

下面将结合图5详细描述根据本发明的一个实施方式的用于生成业务级别测试用例的设备。图5示出了根据本发明的一个实施方式的用于生成业务级别测试用例的设备500的高级框图。

该设备500包括以下四个模块：跟踪模块510、业务事务模式生成模块520、业务事务模式比较模块530以及测试用例生成模块540。

跟踪模块510可以跟踪每个用户请求，以生成与每个服务/组件调用相关的IT事件521，其中事件记录所调取的服务、操作、参数值以及相关性信息，所述相关性信息帮助将所有相关的服务调用事件与请求关联在一起。此后，跟踪模块510向业务事务模式生成模块520传送得到的IT事件521。

业务事务模式生成模块520可以对从跟踪模块510接收的IT事件521进行分析，将所接收IT事件521进行关联，并且从中得到具有实际业务含义的业务事务模式。

业务事务模式生成模块520可以包括IT事务关联器523、业务事务关联器524、以及业务事务模式抽取器525，并且还包括用于将IT事务进行关联的关联规则522。关联规则522以逻辑表达式的方式定义了根据服务调用参数的值和上下文信息将一组IT事务彼此关联。诸如，如果两个IT事务都服务于同一个业务流程实例，则将其进行关联。例如，通过TASK ID(任务ID)、BPID(Business Process Instance ID)进行关联。

首先，IT事务关联器523对从跟踪模块510接收的IT事件521进行组织，以便根据IT事件521中的关联信息来按照图2和3所示的方法形成IT事务。

然后，业务事务关联器524根据预定的关联规则522，按照图2和3所示的方法将一组IT事务彼此关联以形成业务事务，并将所形成的业务事务作为输出传送至业务事务模式抽取器525。

在建立业务事务模式期间，业务事务模式抽取器525从业务事务中抽取业务事务模式。例如抽取该业务事务所涉及的所有IT事件作为它的业务事务模式。业务事务模式抽取器525将所抽取的业务事务模式作为整个业务事务模式生成模块520的输出而发送至业务事务模式比较模块530。

如图5中所示，业务事务比较模块530可以包括业务事务模式比较器531，并且还可以包括业务事务模式集合532。业务事务模式集合532可以涉及两个部分，分别是业务事务模式集合(X)533，其中包含基于测试环境所生成的业务事务模式集合(用“X”表示)；以及业务事务模式集合(Y)534，其中包含基于生产环境所生成的业务事务模式集合(用“Y”表示)。

业务事务模式比较器531可以将基于测试环境的业务事务模式集合(X)533和基于生产环境的业务事务模式集合(Y)534进行比较以发现其中的差异。然后，业务事务模式比较器531将比较结果传送至测试用例生成模块540。

测试用例生成模块540可以包括测试用例生成器541，其从业务事务比较模块530接收来自业务事务模式比较器531的比较结果，即，未覆盖的业务事务模式集合(Y-X)542，并针对该集合中的每个业务事务模式来生成测试用例543。

最后，将所生成的测试用例543补充至本轮迭代所使用的测试用例集合之中，并将新的测试用例集合用于下一轮迭代。

图6示出了根据本发明的一个实施方式的用于生成业务级别测试用例的方法的流程图。

首先，在步骤S602中，跟踪模块510对用户请求进行跟踪，并将所获得的IT事件521发送至业务事务模式生成模块520。

然后，在步骤S604中，业务事务模式生成模块520中的IT事务关联器523对接收的IT事件521进行关联以形成IT事务。

接着，在步骤S606中，业务事务关联器524根据预定的关联规则将所输入的IT事务进行关联以形成业务事务，并将其输出至业务事务模式抽取器525。

然后，在步骤S608中，业务事务模式抽取器525从业务事务中抽取业务事务模式。例如抽取该业务事务所涉及的所有IT事件作为它的业务事务模式。接着将所抽取的业务事务模式输入至业务事务模式比较模块530。

然后，在步骤S610中，业务事务模式比较器531将基于测试环境的业务事务模式集合(X)533和基于生产环境的业务事务模式集合(Y)534进行比较以发现其中的差异，并将来自业务事务模式比较器531的结果传送至测试用例生成模块540。

然后，在步骤S612中，测试用例生成模块540从业务事务比较模块530接收来自业务事务模式比较器531的比较结果，并针对未覆盖的业务事务模式集合(Y-X)542，来生成测试用例543，并将其补充至当前使用的测试用例集合中。

图7示出了根据本发明的另一实施方式的用于生成业务级别测试用例的方法的高级概念图。

根据本发明的另一实施方式与一个实施方式类似，不同之处在于针对生产阶段进行跟踪以直接生成测试用例，然后使用所生成的测试用例来替换现有的测试用例，其中不需要针对测试阶段进行跟踪。

具体地，如图7所示，测试环境710是测试人员对软件系统进行测试的测试环境。而生产环境720是用户在实际使用软件系统时所处的环境。

在开始第一轮测试之前，测试人员首先通过传统方法来生成用于第一轮测试的测试用例。在生产环境720中，通过正常生产使用722并对待测试软件系统进行生产跟踪724来形成基于生产环境的业务事务模式集合726，在此用符号“Y”来表示。

然后，在框732中，针对当前一轮回归测试，使用基于生产环境的业务事务模式集合(Y)726中的业务事务模式生成的测试用例覆盖现有的测试用例，然后执行下一轮回归测试。

图8示出了根据本发明的另一实施方式的用于生成业务级别测试用例的设备500’的高级框图。

图8的设备500’与图5的设备500的不同处于在于，利用测试用例生成模块540’代替了图5的设备中的业务模块比较模块530和测试用例生成模块540，而其他部件与图5相似，在此省略对其的详细描述。

如图8所示，测试用例生成模块540’可以包括测试用例生成器541’，其从业务事务生成模块520接收基于生产环境的业务事务模式542’，并使用基于生产环境的业务事务模式生成的测试用例543覆盖现有的测试用例，然后执行下一轮回归测试。

图9的方法与图6的方法的不同处于在于，利用步骤S610’代替了步骤S610和S612，其他步骤与图6相似，在此省略对其的详细描述。

具体地，在步骤S610’处，测试用例生成模块540’从业务事务生成模块520接收基于生产环境的业务事务模式542’，并使用基于生产环境的业务事务模式生成的测试用例543覆盖现有的测试用例，然后执行下一轮回归测试。

与现有技术相比，本方法具有多个优点。首先，基于运行时跟踪，通过发现未覆盖的实际使用情形来实现SOA架构级别的灰盒测试。这在设计业务级别测试用例中，改进了测试人员的生产效率。这种生产效率的提高将导致节约成本并降低项目周期。其次，本方法并不需要特殊的跟踪机制，其中可以使用能够捕获服务/组件调用的通用跟踪器，而不必针对待测试的不同应用来构造不同的跟踪器。

本发明可以以硬件、软件、固件以及它们的组合来实现。本领域技术人员应该认识到，也可以在供任何合适数据处理系统使用的信号承载介质上所设置的计算机程序产品中实现本发明。这种信号承载介质可以是传输介质或用于机器可读信息的可记录介质，包括磁介质、光介质或其他合适介质。可记录介质的例子包括：硬盘驱动器中的磁盘或软盘、用于光驱的光盘、磁带，以及本领域技术人员所能想到的其他介质。本领域技术人员应该认识到，具有合适编程装置的任何通信终端都将能够执行如程序产品中体现的本发明方法的步骤。

从上述描述应该理解，在不脱离本发明精神的情况下，可以对本发明各实施方式进行修改和变更。本说明书中的描述仅仅是用于说明性的，而不应被认为是限制性的。本发明的范围仅受权利要求书的限制。

Claims

1.一种用于生成软件系统的测试用例的方法，包括步骤：

跟踪用户请求以得到与每个服务和/或组件调用相关的IT事件；

基于IT事件中的关联信息形成IT事务；

基于预定的关联规则关联所述IT事务以形成业务事务；以及

从业务事务中抽取与所述业务事务对应的业务事务模式。

2.根据权利要求1所述的方法，其中所述预定的关联规则规定根据IT事务所包含的IT事件中的服务和/或组件调用参数的值和上下文信息将一组IT事务彼此关联。

3.根据权利要求1所述的方法，包括步骤：

基于生成的业务事务模式生成软件系统的测试用例。

4.根据权利要求3所述的方法，其中：

分别在测试环境和生产环境下生成基于测试环境的业务事务模式集合和基于生产环境的业务事务模式集合；

通过将基于测试环境的业务事务模式集合与基于生产环境的业务事务模式集合进行比较获得未覆盖的业务事务模式集合；以及

基于所述未覆盖的业务事务模式集合中的每一个业务事务模式生成软件系统的测试用例并将其添加到测试用例集合中。

5.根据权利要求3所述的方法，其中：

在生产环境下生成基于生产环境的业务事务模式集合；以及

用基于生产环境的业务事务模式集合中的每一个业务事务模式生成的测试用例覆盖当前使用的测试用例集合。

6.根据权利要求3所述的方法，其中所述软件系统是基于面向服务的架构。

7.一种用于生成软件系统的测试用例的设备，包括：

用于跟踪用户请求以得到与每个服务和/或组件调用相关的IT事件的装置；

用于基于IT事件中的关联信息形成IT事务的装置；

用于基于预定的关联规则关联所述IT事务以形成业务事务的装置；以及

用于从业务事务模式中抽取与所述业务事务对应的业务事务模式的装置。

8.根据权利要求7所述的设备，其中所述预定的关联规则规定根据IT事务所包含的IT事件中的服务和/或组件调用参数的值和上下文信息将一组IT事务彼此关联。

9.根据权利要求7所述的设备，进一步包括：

用于基于生成的业务事务模式生成软件系统的测试用例的装置。

10.根据权利要求9所述的设备，其中：

分别在测试环境和生产环境下生成基于测试环境的业务事务模式集合和基于生产环境的业务事务模式集合，所述用于基于生成的业务事务模式生成软件系统的测试用例的装置进一步包括：

用于通过将基于测试环境的业务事务模式集合与基于生产环境的业务事务模式集合进行比较获得未覆盖的业务事务模式集合的装置；以及

用于基于未覆盖的业务事务模式集合中的每一个业务事务模式生成软件系统的测试用例并将其添加到测试用例集合的装置。

11.根据权利要求9所述的设备，其中：

在生产环境下生成基于生产环境的业务事务模式；

所述生成软件系统的测试用例的装置进一步包括用于用基于生产环境的业务事务模式集合中的每一个业务事务模式生成的测试用例覆盖当前使用的测试用例集合的装置。

12.根据权利要求9所述的设备，其中所述软件系统是基于面向服务的架构。