CN106874172A - 测试用例生成装置及方法 - Google Patents

Abstract

本发明提供了一种规则流的测试用例生成装置及方法，其中，所述规则流包括一个或多个规则组节点。所述装置包括：转换单元，其被配置成用于将规则流转换成若干执行序列的数据流；获取单元，其被配置成用于根据所述执行序列的数据流，获取用于生成测试用例的实例信息；以及生成单元，其被配置成用于根据所述实例信息，生成测试用例。本发明的测试用例生成装置及方法，可以通过将规则流转化为反映节点之间的输入/输出关系的数据流，再比较数据流中每个节点的输入实例与该节点的前驱节点的输出实例或者同一节点的输入实例和输出实例，来得到生成测试用例所期望的实例的信息，从而有效地实现在BRMS中自动生成测试用例。

Description

测试用例生成装置及方法

技术领域

本发明涉及数据处理的领域，具体涉及为多个业务规则生成测试实例的方法和装置。

背景技术

在业务规则管理系统(Business Rule Management System，BRMS)中，业务逻辑是通过规则的形式来表示的。BRMS使得用户可以通过修改规则而不是修改代码来改变业务逻辑。由于业务规则相对于代码来说更便于业务专家理解和修改，因此BRMS相对于传统软件来说更加灵活。通过将实例(facts)与规则的条件进行模式匹配，BRMS规则引擎可以找出满足条件的实例和相应的规则，并在解决冲突后执行规则。

传统的针对业务规则的测试用例生成方法并不适用于规则流的测试用例生成。传统的业务规则测试用例生成方法生成的测试用例是用以覆盖每条规则的。然而对于规则流(rule flow)，却没有一种方法可以自动地生成测试用例。一条规则流指定了几组规则之间的执行顺序。为了确保这个规则流的执行效果与预想的一样，需要通过测试用例来对其进行测试。然而，由于人工编写的测试用例需要花费大量时间，而且也达不到理想的覆盖率，因此，生成针对规则流的测试用例是非常有必要的。

发明内容

在鉴于现有技术的上述状况，本发明的目的之一在于提供一种规则流的测试用例生成装置及方法以解决现有技术中的问题。

根据本发明的一方面，提供了一种规则流的测试用例生成装置，其中，所述规则流包括一个或多个规则组节点，所述装置包括：转换单元，其被配置成用于将规则流转换成若干执行序列的数据流；获取单元，其被配置成用于根据所述执行序列的数据流，获取用于生成测试用例的实例信息；以及生成单元，其被配置成用于根据所述实例信息，生成测试用例。

根据本发明的另一方面，还提供了一种信息处理设备，包括：存储器，用于存储程序指令；以及处理器，所述处理器被配置成执行所存储的指令以：将规则流转换成若干执行序列的数据流，其中，所述规则流包括一个或多个规则组节点；根据所述执行序列的数据流，获取用于生成测试用例的实例信息；以及根据所述实例信息，生成测试用例。

根据本发明的又一方面，还提供了一种规则流的测试用例生成方法，其中，所述规则流包括一个或多个规则组节点，所述方法包括：将规则流转换成若干执行序列的数据流；根据所述执行序列的数据流，获取用于生成测试用例的实例信息；以及根据所述实例信息，生成测试用例。

根据本发明的其它方面，本发明的实施例还提供了计算机可读介质形式的计算机程序产品，其上记录有用于实现上述方法的计算机程序代码。

根据本发明实施例的方法和装置，通过将规则流转化为反映节点之间的输入/输出关系的数据流，从而有效地实现在BRMS中自动生成测试用例。

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

附图说明

本发明可以通过参考下文中结合附图所给出的描述而得到更好的理解，其中在所有附图中使用了相同或相似的附图标记来表示相同或者相似的部件，其中

图1是根据本发明第一实施例的测试用例生成装置10的框图；

图2示例性地示出了一个订单处理的规则流；

图3是示出了根据图2中的规则流的执行序列1得到的数据流的示意图；

图4是根据本发明的第二实施例的测试用例生成装置40的结构框图；

图5示例性地示出了一个猜数字的规则流；

图6示例性地示出了规则组“猜”内部的规则的所有可能的执行顺序；

图7是示出了根据图5所示的规则流的执行序列1得到的数据流的示意图；

图8是根据本发明的一个实施例的测试用例生成方法80的流程图；

图9示是根据本发明的另一个实施例的测试用例生成方法90的流程图；

图10示例性的示出了一个报税处理的规则流；

图11示例性地示出了规则组“获取报税项”内部的规则的所有可能的执行顺序；

图12是示出了根据图10所示的规则流的执行序列1得到的数据流的示意图；以及

图13是其中可以实现根据本发明的实施例的方法和/或装置的通用个人计算机的示例性结构的框图。

具体实施方式

下面参照附图来说明本发明的实施例。在本发明的一个附图或一种实施例中描述的元素和特征可以与一个或更多个其它附图或实施例中示出的元素和特征相结合。应当注意，为了清楚的目的，附图和说明中省略了与本发明无关的、本领域普通技术人员已知的部件和处理的表示和描述。

本领域技术人员可以理解，本发明中的“第一”、“第二”等术语仅用于区别不同单元、模块或步骤等，既不代表任何特定技术含义，也不表示它们之间的必然逻辑顺序，也不体现其所限定的不同单元、模块或步骤的重要性程度。

为了生成规则流的测试用例，需要获取规则流执行过程所期望的实例，然后基于这些实例生成测试用例。本发明的发明人发现：在规则流中，后继节点期望的实例可能是前驱节点输出的实例。因此，如果可以获取节点之间实例的输入输出关系，就可以简化生成测试用例所需的信息。

图1是根据本发明第一实施例的规则流的测试用例生成装置10的框图。如图1所述，所述装置10包括：转换单元11，其被配置成用于将规则流转换成若干执行序列的数据流，其中规则流包括一个或多个规则组节点；获取单元12，其被配置成用于根据所述执行序列的数据流，获取用于生成测试用例的实例信息；生成单元13，其被配置成用于根据所述实例信息，生成测试用例。

转换单元11首先将规则流转换成表示所有可能的执行路径的序列，在下文中这样的可能的执行路径的序列被称为执行序列。

在一个规则流中可能包括各种类型不同的节点，包括但不限于，开始节点、结束节点、规则组节点、动作节点、决策节点、分支节点、合并节点。不同类型的节点的作用不同。

例如，分支节点可以将当前规则流拆分成若干条子规则流并行运行，而合并节点则可以将若干条子规则流合并为一条规则流。

分支节点、合并节点均包括三种类型：XOR、OR、AND。XOR型表示每次只能选择多条分支中的其中一条执行，OR型表示可以选择多条分支同时执行，AND型表示所有分支都必须同时执行。

规则组节点与具体的规则组绑定，与某个规则组绑定之后，规则流在运行时流转到这个节点后，就会执行与之绑定的规则组。

图2示例性地示出了一个订单处理的规则流。在这个订单处理的规则流中，可以根据订单中的购买数量确定所给予的折扣。

在图2所示的规则流中，除了一个开始节点和结束节点，还包括一个类型为AND的分支节点订单_分支order_split，一个类型为AND的合并节点订单_合并order_join，三个规则组节点“订单类型”create_model、“检查订单”check_order、“批准订单”approve_order)。

其中，规则组节点“订单类型”设置了两条规则“订单类型1”create_model_1和“订单类型2”create_model_2，即，当购买数量在0至50之间，打9折；当购买数量在50至100之间，打7折。一个用drools规则语言写成的规则组“订单类型”的示例如下。

规则组节点“订单检查”同样设置了两条规则“订单检查1”check_order_1和“订单检查2”check_order_2，即，当购买数量小于等于0或者购买数量大于100时订单无效(invalid)，当购买数量大于0且购买数量小于等于100时订单有效(valid)。一个用drools规则语言写成的规则组“订单检查”的示例如下。

规则组节点“批准订单”仅有一条规则“批准订单”approve_order，根据订单有效情况及折扣信息批准订单。一个用drools规则语言写成的规则“批准订单”的示例如下。

由于分支节点的类型为AND，所以它的两个分支“订单类型”和“订单检查”必须同时执行。因此，转换单元11将图2中所示的规则流转化得到如下执行序列：

1.开始->订单_分支->订单类型->订单检查->订单_合并->批准订单->结束。

2.开始->订单_分支->订单检查->订单类型->订单_合并->批准订单->结束。

随后，转换单元11需要将上述执行序列转换成反映实例的输入输出关系的数据流。

具体地，以执行序列1为例，转换单元11可以按照执行序列1中的顺序，将执行序列1中节点的期望输入和输出排列起来，并建立其联系，从而得到对应的数据流。

针对规则组节点，转换单元11可以该节点所包含的规则替换该节点。

类似地，转换单元11可以将执行序列2转换成对应的数据流。

获取单元12，其被配置成用于根据所述执行序列的数据流，获取用于生成测试用例的实例信息。

在将执行序列转换成对应的数据流之后，获取单元12可以根据数据流中实例的输入输出关系，对于每一个输入和输出，在其前驱节点或者同一条规则的条件部分寻找相同类型的输入或输出，获取在执行序列的数据流中没有来源的实例的信息，从而得到生成测试用例的实例信息。

图3是示出了根据图2中的规则流的执行序列1得到的数据流的示意图。在下文中，将参照图3详细地说明获取单元12的操作。

例如，针对规则组节点中的每条规则，获取单元12可以从规则的条件部分抽取出其期望的实例(即规则流的各节点期望输入的实例)，并从动作部分得到其输出的实例，并通过比较每个节点的输入实例与该节点的前驱节点的输出实例，来得到需要包含在测试用例中的实例以及实例的各个属性的取值。

具体地，参照上文所述的规则组“订单类型”、“订单检查”和“批准订单”的drools语言的示例，规则组“订单类型”包括两条规则“订单类型1”和“订单类型2”，其条件部分(when引导的部分)没有期望的实例，而其动作部分(then引导的部分)的输出的示例均为记录“订单类型”，即Insert OrderModel，如图3中所示。规则组“订单检查”包括两条规则“订单检查1”和“订单检查2”，其条件部分期望的实例为“订单”，而其动作部分的输出的示例均为将订单的状态设定为有效或无效，即修改“订单”Modify Order。规则组“批准订单”包括一条规则，其条件部分期望的实例为“订单”、“订单类型”，其动作部分的输出的示例为批准该订单的折扣信息，即修改“订单”Modify Order。

从数据流中可以看出，部分节点的期望的实例可以从其前驱节点的输出实例获取，例如，规则“订单检查2”期望的实例“订单”是规则“订单检查1”输出的被修改状态的实例“订单”，即由其前驱节点的相同类型输出提供；同时，规则“订单检查2”的输出是其输入的被修改状态的实例“订单”，即由同一条规则的条件部分的输入提供。

针对分支节点，需要提取分支节点的约束属性，即选择不同的分支时所满足的条件。而在本实施例中，分支节点的类型为AND，其不包括约束属性。

图3中的黑色箭头表示实例的输入输出关系，如图3所示，除规则“检查订单1”的期望的实例“订单”(输入)之外，其余节点的期望的实例均可以在其前驱节点或者同一条规则的条件部分寻找相同类型的输入或输出。这样，剩余的没有来源的期望的实例“订单”即是生成测试用例所需的实例信息，这样的实例信息在图3中用圆圈所示。

在获取单元12获取了生成测试用例所需的实例信息的情况下，生成单元13根据实例信息生成测试用例。

基于实例信息生成测试用例的方法是已有技术，在一个可能的示例中，例如可以利用PICT(Pairwise Independent Combinatorial Testingtool，成对独立组合测试工具)生成最终的测试用例，在此不再赘述。

根据本发明的一个实施例的测试用例生成装置10，可以通过将规则流转化为反映节点之间的输入/输出关系的数据流，再比较数据流中每个节点的输入实例与该节点的前驱节点的输出实例或者同一节点的输入实例和输出实例，来得到生成测试用例所期望的实例的信息，从而有效地实现在BRMS中自动生成测试用例。

在一个可能的实施例中，转换单元11还包括过滤模块(图中未示出)。过滤模块可以被配置成过滤对实例的输入和输出不具备约束作用的节点。

被过滤的节点例如可以是开始节点、结束节点以及合并节点等。此外，对于不包括诸如记录和/或修改等语句的动作节点，由于这样的节点不会对实例的输入输出关系起约束作用，因此可以将其过滤。经过滤的执行序列中通常只包括规则组节点、包含诸如记录和/或修改等语句的动作节点以及分支节点等。

通过将对实例的输入输出关系不起约束作用的节点去除，可以简化所获取的数据流。

上面以与订单处理相关的过程为例描述了根据本发明的测试用例生成装置10的构成。需要强调指出，测试用例生成装置10实质上执行的是一种数据处理过程。具体而言，就测试用例生成装置10所处理的对象来说，其中与订单处理相关的规则流是包含相关数据及其数据之间的相互关系的数据或者信息集合。其中的规则流中所包括的开始节点、结束节点、规则组节点、动作节点、决策节点、分支节点、合并节点等，一方面体现了各节点中的数据内容的类型，另一方面也指明了各节点之间的数据之间的相互关系。在这里所谓的“规则流”也只是为了凸显其所包含的各种数据之间是具有特定关系之义，而非通常意义上所述的这种规则流是人为设定的。实际上，对于不同的事件，就会基于事件的客观性质而产生相应的规则流，也即，数据或信息集合。这种事件可以是本示例中所言的订单处理事件，也可以是其他任何事件，只要这些事件符合上述特性，即，包含了各种与客观事件本身性质相关的数据或信息集合即可。就测试用例生成装置10的各个组成部件的构成而言，转换单元11将规则流转换成若干执行序列的数据流，获取单元12根据所述执行序列的数据流，获取用于生成测试用例的实例信息，生成单元13根据所述实例信息，生成测试用例。容易理解，这些组成部件所执行的都是典型的数据处理操作，并且能够获得有益的技术效果，如上所言，可以通过将规则流转化为反映节点之间的输入/输出关系的数据流，再比较数据流中每个节点的输入实例与该节点的前驱节点的输出实例或者同一节点的输入实例和输出实例，来得到生成测试用例所期望的实例的信息，从而有效地实现在BRMS中自动生成测试用例。据此，测试用例的生成过程的效率和精确度得到提升。

图4是根据本发明的第二实施例的测试用例生成装置40的结构框图。在本实施例中，针对规则流的执行序列中的每个规则组节点，通过判断其内部的规则的各种可能的执行顺序的约束是否可以被满足，来得到可行的执行序列。

如图4所示，在本实施例中转换单元41包括：遍历模块411，其被配置成用于从所述规则流的开始节点开始，遍历所述规则流的各节点，以便将所述规则流转换成若干执行序列；确定模块412，其被配置成基于规则组节点内部的规则之间的约束条件，来确定所述一个或多个规则组节点的规则执行顺序；生成模块413，其被配置成在所述执行序列中，采用所确定的一个或多个规则组节点的规则执行顺序替换相应的一个或多个规则组节点，以便生成所述执行序列的数据流。

图5示例性地示出了一个猜数字的规则流。在下文中，以图5所示的猜数字的规则流为例，详细地说明转换单元41的操作。在这个猜数字的规则流中，允许用户在规则允许的次数内猜一个预先生成的随机数，并在猜的过程中告知用户猜测结果是正确、偏大还是偏小。这个过程一直持续，直到用户猜出正确数字或者达到最大的猜测次数。

在图5所示的规则流中，除了一个开始节点和结束节点，还包括三个合并节点“再猜_合并”More guesses Join、“无法再猜_合并”No moreguesses Join和“不正确的猜”Incorrect Guess，两个分支节点“猜对？”Guess correct？和“再猜？”More Guesses？，三个规则组节点“猜”Guess、“猜错”Guess incorrect和“无法再猜”No more Guesses以及三个动作节点“猜对”Guess Correct、“太高”Too High和“太低”Too Low。

由于在本实施例中的分支节点的类型为XOR，即每次只能选择多条分支中的其中一条执行。因此，为了获取该规则流可能的执行序列，需要对该规则流进行遍历。

遍历模块411被配置成用于从所述规则流的开始节点开始，遍历所述规则流的各节点，以便将所述规则流转换成若干执行序列。

遍历的方式例如可以是基于深度优先的，也可以是基于广度优先的。

在本实施例中，采用基于深度优先的遍历方法，遍历的一个原则是避免在执行序列中出现环路，也即当遍历到的节点已经在执行序列中出现的情况下，结束遍历。

以下算法是以C语言为例的一个基于深度优先进行遍历的示例，借助该算法可以将给定的规则流转换成执行路径序列。

在对图5中的规则流进行遍历之后，可以生成以下5个执行路径序列。

1.开始->再猜_合并->猜->猜对？->猜对->无法再猜_合并->结束。

2.开始->再猜_合并->猜->猜对？->太低->不正确的猜->猜错->再猜？。

3.开始->再猜_合并->猜->猜对？->太高>不正确的猜->猜错->再猜？。

4.开始->再猜_合并->猜->猜对？->太低->不正确的猜->猜错->再猜？->无法再猜->无法再猜_合并->结束。

5.开始->再猜_合并->猜->猜对？->太高->不正确的猜->猜错->再猜？->无法再猜->无法再猜_合并->结束。

以上五个执行序列是最基本的执行序列，可以通过它们来构建更复杂的执行序列。那些不以结束节点结尾的执行序列，诸如执行序列2、3，可以被连接到其他执行序列以创建更多的补充执行序列。例如，执行序列2可以被连接到执行序列1的“再猜_合并”节点，然后得到以下执行序列：开始->再猜_合并->猜->猜对？->太低->不正确的猜->猜错->再猜？->再猜_合并->猜->猜对？->猜对->无法再猜_合并->结束。然而，由于这些补充执行序列并不会增加测试用例的覆盖率，所以它们的存在不会影响生成测试用例。在生成测试用例时，只需考虑覆盖最基本的执行序列。

在本实施例中，针对这些执行序列中的每个规则组节点，确定模块412可以通过判断其内部的规则的各种可能的执行顺序的约束是否可以被满足，来得到每个规则组节点内部的规则的可行的执行序列。

例如，针对图5所示的规则流中的规则组“猜”，其内部包括三个规则，分别是：“让用户猜”Get user Guess、“记录所猜最大数字”Recordthe biggest Guess、“记录所猜最小数字”Record the smallest Guess。

规则“让用户猜”产生随机数，并且用户猜的次数小于预先设定的允许的次数，并且用户当前轮还没有猜，那么提示用户这个随机数所处的范围，并让用户猜一个数字，同时记录该数字。一个用drools规则语言写成的规则“让用户猜”的示例如下。

可以看出，规则“让用户猜”，期望的输入实例为：“随机数”RandomNumber、“游戏规则”GameRules，“游戏”Game，同时，输出实例为：修改“游戏”Modify Game，记录“猜”Insert Guess。

规则“记录所猜最大数字”在用户猜测的数字大于其之前所猜测的最大数字的情况下，将用户猜测的最大数字替换为这次猜测的数字。一个用drools规则语言写成的规则“记录所猜最大数字”的示例如下。

可以看出，规则“记录所猜最大数字”，期望的输入实例为：“猜”和“游戏”，同时，输出实例为：修改“游戏”。

规则“记录所猜最小数字”在用户猜测的数字小于其之前所猜测的最小数字的情况下，将用户猜测的最小数字替换为这次猜测的数字。一个用drools规则语言写成的规则“记录所猜最小数字”的示例如下。

可以看出，规则“记录所猜最小数字”，期望的输入实例为：“猜”和“游戏”，同时，输出实例为：修改“游戏”。

图6示例性地示出了规则组“猜”内部的规则的所有可能的执行顺序。如图6所示，规则组“猜”内部的三条规则共有六种可能的执行顺序。

在本例中，通过对这些执行顺序的约束进行检查，发现，只有两种执行顺序是可行的，如图6的框中所示。这是因为，规则“让用户猜”要求工作内存中不存在“猜”类的实例，而规则“记录所猜最小数字”或“记录所猜最大数字”则要求必须创建或插入一个“猜”类的实例到工作内存中。也就是说，规则之间的约束条件要求规则“让用户猜”必须要在规则“记录所猜最小数字”和“记录所猜最大数字”之前执行。因此，其他四个执行顺序是不可行的。

生成模块413被配置成在所述执行序列中，采用所确定的一个或多个规则组节点的规则执行顺序替换相应的一个或多个规则组节点，以便生成所述执行序列的数据流。

在基于规则之间的约束条件获取了可行的执行序列后，生成模块413可以用该规则组的可行的执行序列替换执行序列中的规则组节点。

例如，对于如上所述的执行序列1，通过将所确定的可行的执行序列“让用户猜->记录所猜最大数字->记录所猜最小数字”替换执行序列1中的规则组节点“猜”，可以得到以下执行序列。

1’.开始->再猜_合并->让用户猜->记录所猜最大数字->记录所猜最小数字->猜对？->猜对->无法再猜_合并->结束。

如上文所述，可以进一步配置过滤单元(图中未示出)过滤掉执行序列1’中对实例的输入输出关系不起约束作用的节点，之后可以得到以下执行序列。

1”.让用户猜->记录所猜最大数字->记录所猜最小数字->猜对？。

随后，按照最终的执行序列1”中的顺序，将这些期望输入和输出排列起来。在其前驱节点或者同一条规则的条件部分寻找相同类型的输入或输出，同时考虑到分支节点的约束条件，最终得到对应的数据流，如图7所示。图7是示出了根据如图5所示的规则流的执行序列1”得到的数据流的示意图。

在获取了执行序列对应的数据流的情况下，获取单元42可以根据数据流的顺序，获取在所述执行序列的数据流中没有来源的实例的信息，从而得到生成测试用例的实例信息。图7中的黑色箭头表示实例的输入输出关系，如图7所示，除规则“让用户猜”的期望的实例“随机数”、“游戏规则”和“游戏”之外，其余的实例均可以在其前驱节点或者同一条规则的条件部分寻找相同类型的输入或输出。这样，剩余的没有来源的期望的实例“随机数”、“游戏规则”和“游戏”即是生成测试用例所需的实例信息，这样的实例信息在图7中用圆圈所示。

最后，生成单元43根据实例信息生成测试用例。可以利用如上所述的PICT生成最终的测试用例。

可以参照第一实施例中配置获取单元42和生成单元43，其更多细节在此不再赘述。

根据本发明第二实施例的测试用例生成装置40，能够基于规则组节点内部的规则之间的约束条件检测出不可行的执行序列，从而可以降低在自动生成测试用例时的计算量，从而降低系统处理负荷，提高数据处理效率。

在此需要指出，本例中描述的根据本发明的测试用例生成装置40实质上执行的也是一种数据处理过程。所处理的对象与猜数字过程所涉及的规则流相关，即，处理对象实际上是一种与特定事件相关的数据或信息集合。所谓的“猜数字”过程，本质上是一种用于确定预定的数值或参数等的数据处理过程。而且，如上所言，测试用例生成装置40进行的这种数据处理可以降低在自动生成测试用例时的计算量，降低系统处理负荷，提高数据处理效率。

以上结合附图描述了根据本发明的测试用例生成装置的各实施例，在此过程中事实上也描述了一种测试用例生成方法。下面结合图8和图9对该方法予以简要描述，其中的细节可参见前文对测试用例生成装置的描述。

图8是根据本发明的一个实施例的测试用例生成方法80的流程图。该方法开始于步骤S81，包括如下步骤：步骤S82，将规则流转换成若干执行序列的数据流，其中，所述规则流包括一个或多个规则组节点；步骤S83，根据所述执行序列的数据流，获取用于生成测试用例的实例信息；以及步骤S84，根据所述实例信息，生成测试用例。例如，可以通过结合图1至图3描述的根据第一实施例的测试用例生成10执行的过程来实现，具体细节在此不再赘述。

在一个可能的示例中，所述实例信息包括在所述执行序列的数据流中没有来源的实例的信息。

在一个可能的实施例中，将规则流转换成若干执行序列的数据流的步骤S82包括过滤对实例的输入和输出不具备约束作用的节点的步骤。

图9示是根据本发明的另一个实施例的测试用例生成方法90的流程图，图10示例性的示出了一个报税处理的规则流。下面，将结合图9和图10来描述根据本发明另一个实施例的测试用例生成方法90。

该方法开始于步骤S91，包括：步骤S92，从所述规则流的开始节点开始，遍历所述规则流的各节点，以便将所述规则流转换成若干执行序列，其中，所述规则流包括一个或多个规则组节点；步骤S93，基于规则组节点内部的规则之间的约束条件，来确定所述一个或多个规则组节点的规则执行顺序；步骤S94，在所述执行序列中，采用所确定的一个或多个规则组节点的规则执行顺序替换相应的一个或多个规则组节点，以便生成所述执行序列的数据流；步骤S95，根据所述执行序列的数据流，获取用于生成测试用例的实例信息；以及，步骤S96，根据所述实例信息，生成测试用例。

在图10所示的规则流中，除了一个开始节点和结束节点，还包括三个类型为XOR的合并节点“存在未报税项_合并”、“正常处理完毕_合并”和“报税完毕_合并”，两个类型为XOR的分支节点“分类处理_分支”和“存在未报税项_分支”，三个规则组节点“获取报税项”、“正常处理完毕”和“无未报税项”以及三个动作节点“1类正常”、“2类正常”和“非正常”。

由于在本实施例中的分支节点的类型为XOR，即每次只能选择多条分支中的其中一条执行。因此，为了获取该规则流可能的执行序列，在步骤S92，需要对该规则流进行遍历。

在一个可能的示例中，在步骤S92中，所述遍历基于深度优先的原则。

在一个可能的示例中，在步骤S92中，在对所述规则流进行遍历时，当遍历到的节点已经出现在执行序列中或者遍历到所述规则流的结束节点时，生成所述执行序列。

可以采用上文结合第二实施例描述的遍历算法的示例对图10所示的规则流进行遍历，在此不再赘述。

在对图10中的规则流进行遍历之后，可以生成以下5个执行路径序列。

1.开始->存在未报税项_合并->获取报税项->分类处理_分支->非正常->报税完毕_合并->结束。

2.开始->存在未报税项_合并->获取报税项->分类处理_分支->1类正常->正常处理完毕_合并->正常处理完毕->存在未报税项_分支。

3.开始->存在未报税项_合并->获取报税项->分类处理_分支->2类正常>正常处理完毕_合并->正常处理完毕->存在未报税项_分支。

4.开始->存在未报税项_合并->获取报税项->分类处理_分支->1类正常->正常处理完毕_合并->正常处理完毕->存在未报税项_分支->无未报税项->报税完毕_合并->结束。

5.开始->存在未报税项_合并->获取报税项->分类处理_分支->2类正常->正常处理完毕_合并->正常处理完毕->存在未报税项_分支->无未报税项->报税完毕_合并->结束。

例如，针对图10所示的规则流中的规则组节点获取报税项，其内部包括四个规则，分别是：获取一个报税项、记录1类正常报税项数目、记录2类正常报税项数目和记录非正常报税项数目。

接着，在步骤S93，基于规则组节点内部的规则之间的约束条件，获取了获取报税项规则组内部的规则所有可能的可行执行顺序。在本实施例中，由于规则组节点“获取报税项”包括4条规则，因而共有24条可能的执行序列。由于约束条件的限制，在这24条可能的执行序列中，有18条执行序列是不可行的，仅有6条执行序列是可行的，如图11所示。

在一个可能的示例中，在步骤S93中，约束条件包括规则组节点内部的规则之间实例的输入和输出的相互关系。

接着，在步骤S94，采用所确定的一个或多个规则组节点的规则执行顺序替换相应的一个或多个规则组节点，生成所述执行序列的数据流。

例如，对于如上所述的执行序列1，通过将所确定的可行的执行序列“获取一个报税项->记录1类正常报税项数目->记录2类正常报税项数目->记录非正常报税项数目”替换执行序列1中的规则组节点“获取报税项”，我们可以得到以下执行序列1’。

1’.开始->存在未报税项_合并->获取一个报税项->记录1类正常报税项数目->记录2类正常报税项数目->记录非正常报税项数目->分类处理_分支->非正常->报税完毕_合并->结束。

在一个可能的实施例中，在步骤S94之后，所述方法还包括过滤数据流中对实例的输入和输出不具备约束作用的节点的步骤。例如，可以通过结合图4至图7描述的根据第二实施例的过滤单元执行的过程来实现，具体细节在此不再赘述。

具体地，在进一步过滤掉执行序列1’中对实例的输入输出关系不起约束作用的节点之后，可以得到以下执行序列1”。

1”.获取一个报税项->记录1类正常报税项数目->记录2类正常报税项数目->记录非正常报税项数目->分类处理_分支。

接着，在步骤S95中，根据所述执行序列的数据流，获取用于生成测试用例的实例信息。

按照最终的执行序列1”中的顺序，将这些期望输入和输出排列起来。在其前驱节点或者同一条规则的条件部分寻找相同类型的输入或输出，同时考虑到分支节点的约束条件，最终得到对应的数据流，如图12所示。

在一个可能的示例中，在步骤S95中，所述实例信息包括在所述执行序列的数据流中没有来源的实例的信息。这样的信息在图12中用圆圈所示。

最后，在步骤S96，根据所述实例信息，生成测试用例。例如，可以通过结合图4至图7描述的根据第二实施例的生成单元执行的过程来实现，具体细节在此不再赘述。

容易理解，本例中描述的报税处理的规则流实质上是一种与特定事件(报税)相关的数据或信息集合，根据本发明本实施例的测试用例生成方法执行的也是一种数据处理过程，也即，本质上是一种用于确定预定的数值或参数(在本例中是与报税项相关的数值或参数)与预定条件的符合程度(在本例中是指报税项是否完成)的数据处理过程。类似地，这种数据处理过程可以降低在自动生成测试用例时的计算量，降低系统处理负荷，提高数据处理效率。

此外，本发明的实施例涉实际上还涉及了一种信息处理设备(例如计算机)，其包括：存储器，用于存储程序指令；以及，处理器，该处理器被配置成执行所存储的指令以便可以实现如上参照图1至图7描述的测试用例生成装置的各功能部件所具有的功能，或者执行如上参照图8至图12描述的测试用例方法的操作步骤。

在本申请的装置、方法等实施例中，显然，各部件(单元、子单元、模块、子模块等)或各步骤是可以分解、组合和/或分解后重新组合的。这些分解和/或重新组合应视为本申请的等效方案。同时，在上面对本申请具体实施例的描述中，针对一种实施例描述和/或示出的特征可以以相同或类似的方式在一个或更多个其它实施例中使用，与其它实施例中的特征相组合，或替代其它实施例中的特征。

以上结合具体实施例描述了本发明的基本原理，但是，需要指出的是，对本领域的普通技术人员而言，能够理解本发明的方法和装置的全部或者任何步骤或者部件，可以在任何计算装置(包括处理器、存储介质等)或者计算装置的网络中，以硬件、固件、软件或者它们的组合加以实现，这是本领域普通技术人员在阅读了本发明的说明的情况下运用他们的基本编程技能就能实现的。

因此，本发明的目的还可以通过在任何计算装置上运行一个程序或者一组程序来实现。计算装置可以是公知的通用装置。因此，本发明的目的也可以仅仅通过提供包含实现方法或者装置的程序代码的程序产品来实现。也就是说，这样的程序产品也构成本发明，并且存储有这样的程序产品的存储介质也构成本发明。显然，存储介质可以是任何公知的存储介质或者将来所开发出来的任何存储介质。

在通过软件和/或固件实现本发明的实施例的情况下，从存储介质或网络向具有专用硬件结构的计算机，例如图13所示的通用计算机1300安装构成该软件的程序，该计算机在安装有各种程序时，能够执行各种功能等等。

在图13中，中央处理单元(CPU)1301根据只读存储器(ROM)1302中存储的程序或从存储部分1308加载到随机存取存储器(RAM)1303的程序执行各种处理。在RAM 1303中，也根据需要存储当CPU 1301执行各种处理等等时所需的数据。CPU 1301、ROM 1302和RAM 1303经由总线1304彼此链路。输入/输出接口1305也链路到总线1304。

下述部件链路到输入/输出接口1305：输入部分1306(包括键盘、鼠标等等)、输出部分1307(包括显示器，比如阴极射线管(CRT)、液晶显示器(LCD)等，和扬声器等)、存储部分1308(包括硬盘等)、通信部分1309(包括网络接口卡比如LAN卡、调制解调器等)。通信部分1309经由网络比如因特网执行通信处理。根据需要，驱动器1310也可链路到输入/输出接口1305。可拆卸介质1311比如磁盘、光盘、磁光盘、半导体存储器等等根据需要被安装在驱动器1310上，使得从中读出的计算机程序根据需要被安装到存储部分1308中。

在通过软件实现上述系列处理的情况下，从网络比如因特网或存储介质比如可拆卸介质1311安装构成软件的程序。

本领域的技术人员应当理解，这种存储介质不局限于图8所示的其中存储有程序、与设备相分离地分发以向用户提供程序的可拆卸介质1311。可拆卸介质1311的例子包含磁盘(包含软盘(注册商标))、光盘(包含光盘只读存储器(CD-ROM)和数字通用盘(DVD))、磁光盘(包含迷你盘(MD)(注册商标))和半导体存储器。或者，存储介质可以是ROM 1302、存储部分1308中包含的硬盘等等，其中存有程序，并且与包含它们的设备一起被分发给用户。

本发明还提出一种存储有机器可读取的指令代码的程序产品。指令代码由机器读取并执行时，可执行上述根据本发明实施例的方法。

相应地，用于承载上述存储有机器可读取的指令代码的程序产品的存储介质也包括在本发明的公开中。存储介质包括但不限于软盘、光盘、磁光盘、存储卡、存储棒等等。

最后，还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。此外，在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

通过上述的描述，本发明的实施例提供了以下的技术方案，但不限于此。

附记1.一种规则流的测试用例生成装置，其中，所述规则流包括一个或多个规则组节点，所述装置包括：

转换单元，其被配置成用于将规则流转换成若干执行序列的数据流；

获取单元，其被配置成用于根据所述执行序列的数据流，获取用于生成测试用例的实例信息；以及

生成单元，其被配置成用于根据所述实例信息，生成测试用例。

附记2.根据附记1所述的装置，其中，所述转换单元包括：

遍历模块，其被配置成用于从所述规则流的开始节点开始，遍历所述规则流的各节点，以便将所述规则流转换成若干执行序列；

确定模块，其被配置成基于规则组节点内部的规则之间的约束条件，来确定所述一个或多个规则组节点的规则执行顺序；

生成模块，其被配置成在所述执行序列中，采用所确定的一个或多个规则组节点的规则执行顺序替换相应的一个或多个规则组节点，以便生成所述执行序列的数据流。

附记3.根据附记2所述的装置，其中，所述遍历基于深度优先的原则。

附记4.根据附记2或3所述的装置，其中，在对所述规则流进行遍历时，当遍历到的节点已经出现在执行序列中或者遍历到所述规则流的结束节点时，生成所述执行序列。

附记5.根据附记2所述的装置，其中，所述约束条件包括规则组节点内部的规则之间实例的输入和输出的相互关系。

附记6.根据附记2所述的装置，其中，所述转换单元还包括过滤模块，其被配置成过滤对实例的输入和输出不具备约束作用的节点。

附记7.根据附记1所述的装置，其中，所述实例信息包括在所述执行序列的数据流中没有来源的实例的信息。

附记8.一种信息处理设备，包括：

存储器，用于存储程序指令；以及

处理器，所述处理器被配置成执行所存储的指令以：

将规则流转换成若干执行序列的数据流，其中，所述规则流包括一个或多个规则组节点；

根据所述执行序列的数据流，获取用于生成测试用例的实例信息；

根据所述实例信息，生成测试用例。

附记9.一种测试用例生成方法，其中，所述规则流包括一个或多个规则组节点，包括：

将规则流转换成若干执行序列的数据流；

根据所述执行序列的数据流，获取用于生成测试用例的实例信息；以及

根据所述实例信息，生成测试用例。

附记10.根据附记9所述的方法，其中，将规则流转换成若干执行序列的数据流包括：

从所述规则流的开始节点开始，遍历所述规则流的各节点，以便将所述规则流转换成若干执行序列；

基于规则组节点内部的规则之间的约束条件，来确定所述一个或多个规则组节点的规则执行顺序；

在所述执行序列中，采用所确定的一个或多个规则组节点的规则执行顺序替换相应的一个或多个规则组节点，以便生成所述执行序列的数据流。

附加11.根据附记10的方法，其中，所述遍历基于深度优先的原则。

附记12.根据附记10或11所述的方法，其中，在对所述规则流进行遍历时，当遍历到的节点已经出现在执行序列中或者遍历到所述规则流的结束节点时，生成所述执行序列。

附记13.根据附记10所述的方法，其中，所述约束条件包括规则组节点内部的规则之间实例的输入和输出的相互关系。

附记14.根据附记10所述的方法，其中，将规则流转换成若干执行序列的数据流还包括：过滤数据流中对实例的输入和输出不具备约束作用的节点。

附记15.根据附记9所述的方法，其中，所述实例信息包括在所述执行序列的数据流中没有来源的实例的信息。

以上实施例仅用于说明本发明，而并非对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本发明的范畴，本发明的专利保护范围应由权利要求限定。

Claims (9)

1.一种规则流的测试用例生成装置，其中，所述规则流包括一个或多个规则组节点，所述装置包括：

转换单元，其被配置成用于将规则流转换成若干执行序列的数据流；

获取单元，其被配置成用于根据所述执行序列的数据流，获取用于生成测试用例的实例信息；以及

生成单元，其被配置成用于根据所述实例信息，生成测试用例。

2.根据权利要求1所述的装置，其中，所述转换单元包括：

遍历模块，其被配置成用于从所述规则流的开始节点开始，遍历所述规则流的各节点，以便将所述规则流转换成若干执行序列；

确定模块，其被配置成基于规则组节点内部的规则之间的约束条件，来确定所述一个或多个规则组节点的规则执行顺序；

生成模块，其被配置成在所述执行序列中，采用所确定的一个或多个规则组节点的规则执行顺序替换相应的一个或多个规则组节点，以便生成所述执行序列的数据流。

3.根据权利要求2所述的装置，其中，所述遍历基于深度优先的原则。

4.根据权利要求2或3所述的装置，其中，在对所述规则流进行遍历时，当遍历到的节点已经出现在执行序列中或者遍历到所述规则流的结束节点时，生成所述执行序列。

5.根据权利要求2所述的装置，其中，所述约束条件包括规则组节点内部的规则之间实例的输入和输出的相互关系。

6.根据权利要求2所述的装置，其中，所述转换单元还包括过滤模块，其被配置成过滤对实例的输入和输出不具备约束作用的节点。

7.根据权利要求1所述的装置，其中，所述实例信息包括在所述执行序列的数据流中没有来源的实例的信息。

8.一种信息处理设备，包括：

存储器，用于存储程序指令；以及

处理器，所述处理器被配置成执行所存储的指令以：

将规则流转换成若干执行序列的数据流，其中，所述规则流包括一个或多个规则组节点；

根据所述执行序列的数据流，获取用于生成测试用例的实例信息；以及

根据所述实例信息，生成测试用例。

9.一种规则流的测试用例生成方法，其中，所述规则流包括一个或多个规则组节点，所述方法包括：

将规则流转换成若干执行序列的数据流；

根据所述执行序列的数据流，获取用于生成测试用例的实例信息；以及

根据所述实例信息，生成测试用例。