一种功能测试案例的生成方法及装置

摘要

本申请公开的一种功能测试案例的生成方法和装置，获取测试规则信息、测试要素、以及测试要素对应的测试要素取值，然后针对测试规则信息生成对应的第一案例，再将获取的每一测试要素取值作为目标测试要素取值，与生成的第一案例包括的测试要素取值进行匹配，如果匹配失败，则利用未匹配成功的目标测试要素取值生成对应的第二案例，最后将第一案例和第二案例进行合并去重，生成案例列表。相比原来测试人员逐条编写案例，减少了案例的设计时间，进而提高了效率。

说明书

技术领域

本申请涉及功能测试领域，更具体地说，涉及一种功能测试案例的生成方法及装置。

背景技术

功能测试是根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为，以确定他们是否满足设计需求。功能测试是为了确保程序以期望的方式运行，而按功能要求对软件进行的测试，通过对一个系统的所有特性和功能都进行测试确保符合需求和规范。功能测试也叫黑盒测试或数据驱动测试，只需考虑需要测试的各个功能，不需要考虑整个软件的内部结构以及代码，在程序接口进行测试，检测程序是否能在接收正确的输入数据而产生正确的输出结果。

一般的，测试人员根据需求人为的设计出来功能测试案例，输入数据在预期结果和实际结果之间进行测评。测试案例是指对软件产品进行测试数据、预期结果等信息进行描述的文档。人为的设计功能测试案例，需要测试人员逐条编写，过程复杂繁琐，花费的时间较长，效率低下。

发明内容

有鉴于此，本申请提出一种功能测试案例的生成方法及装置，欲实现自动生成功能测试案例，减少功能测试案例的设计时间，提高效率的目的。

为了实现上述目的，现提出的方案如下：

一种功能测试案例的生成方法，包括：

获取测试规则信息、测试要素、以及所述测试要素对应的测试要素取值；

针对所述测试规则信息生成对应的第一案例；

将获取的每一所述测试要素取值作为目标测试要素取值，与所述第一案例包括的测试要素取值进行匹配，如果匹配失败，则利用未匹配成功的目标测试要素取值生成对应的第二案例；

将所述第一案例和所述第二案例进行合并去重，生成案例列表。

优选的，所述测试规则信息包括：

约束规则信息和逻辑规则信息，所述约束规则信息包括不同所述测试要素对应的测试要素取值之间的对应关系，所述逻辑规则信息包括一个所述测试要素对应的N个测试要素取值与另一个所述测试要素对应的M个测试要素取值之间的组合关系，N和M为正整数。

优选的，所述针对所述测试规则信息生成对应的第一案例，包括：

根据所述逻辑规则信息包括的所述组合关系确定第一测试要素的第一取值组合；

判断所述第一测试要素对应的测试要素取值是否存在所述约束规则信息中，如果存在，则确定与所述第一测试测试要素对应的测试要素取值存在对应关系的第二测试要素对应的测试要素取值；

针对未确定测试要素取值的第三测试要素，选取所述第三测试要素对应的测试要素取值形成第二取值组合，如果选取的测试要素取值存在所述约束规则信息中，则需要保障选取的测试要素取值对应的所述约束规则信息包含的其它测试要素对应的取值满足所述约束规则；

将所述第一取值组合、所述第二测试要素对应的测试要素取值和所述第二取值组合进行组合形成所述第一案例。

优选的，所述针对所述测试规则信息生成对应的第一案例，包括：

根据每一所述约束规则信息包括的对应关系确定第四测试要素对应的测试要素取值；

针对未确定测试要素取值的第五测试要素，选取所述第五测试要素对应的测试要素取值形成第三取值组合，如果选取的测试要素取值存在所述约束规则信息中，则需要保障选取的测试要素取值对应的所述约束规则信息包含 的其它测试要素对应的取值满足所述约束规则；

将所述第四测试要素对应的测试要素取值与所述第三取值组合进行组合形成所述第一案例。

优选的，所述利用未匹配成功的目标测试要素取值生成对应的第二案例，包括：

针对未确定测试要素取值的第六测试要素，选取所述第六测试要素对应的测试要素取值形成第三取值组合，如果选取的测试要素取值存在所述约束规则信息中，则需要保障选取的测试要素取值对应的所述约束规则信息包含的其它测试要素对应的取值满足所述约束规则；

将所述目标测试要素取值与所述第四取值组合进行组合形成所述第二案例。

一种功能测试案例的生成装置，包括：

规则获取单元，用于获取测试规则信息；

要素获取单元，用于获取测试要素、以及所述测试要素对应的测试要素取值；

第一案例生成单元，用于针对所述测试规则信息生成对应的第一案例；

第二案例生成单元，用于将获取的每一所述测试要素取值作为目标测试要素取值，与所述第一案例包括的测试要素取值进行匹配，如果匹配失败，则利用未匹配成功的目标测试要素取值生成对应的第二案例；

案例列表成成单元，用于将所述第一案例和所述第二案例进行合并去重，生成案例列表。

优选的，所述规则获取单元包括：

约束规则获取单元，用于获取约束规则信息，所述约束规则信息包括不同所述测试要素对应的测试要素取值之间的对应关系；

逻辑规则获取单元，用于获取逻辑规则信息，所述逻辑规则信息包括一个所述测试要素对应的N个测试要素取值与另一个所述测试要素对应的M个测试要素取值之间的组合关系，N和M为正整数。

优选的，所述第一案例生成单元包括：

第一测试要素的取值单元，用于根据所述逻辑规则信息包括的所述组合关系确定第一测试要素的第一取值组合；

第二测试要素的取值单元，用于判断所述第一测试要素对应的测试要素取值是否存在所述约束规则信息中，如果存在，则确定与所述第一测试要素对应的测试要素取值存在对应关系的第二测试要素对应的测试要素取值；

第三测试要素的取值单元，用于针对未确定测试要素取值的第三测试要素，选取所述第三测试要素对应的测试要素取值形成第二取值组合，如果选取的测试要素取值存在所述约束规则信息中，则需要保障选取的测试要素取值对应的所述约束规则信息包含的其它测试要素对应的取值满足所述约束规则；

案例生成第一子单元，用于将所述第一取值组合、所述第二测试要素对应的测试要素取值和所述第二取值组合进行组合形成所述第一案例。

优选的，所述第一案例生成单元包括：

第四测试要素的取值单元，用于根据所述约束规则信息包括的对应关系确定第四测试要素对应的测试要素取值；

第五测试要素的取值单元，用于针对未确定测试要素取值的第五测试要素，选取所述第五测试要素对应的测试要素取值形成第三取值组合，如果选取的测试要素取值存在所述约束规则信息中，则需要保障选取的测试要素取值对应的所述约束规则信息包含的其它测试要素对应的取值满足所述约束规则；

案例生成第二子单元，用于将所述第四测试要素对应的测试要素取值与所述第三取值组合进行组合形成所述第一案例。

优选的，所述第二案例生成单元包括：

第六测试要素的取值单元，用于针对未确定测试要素取值的第六测试要素，选取所述第六测试要素对应的测试要素取值形成第三取值组合，如果选取的测试要素取值存在所述约束规则信息中，则需要保障选取的测试要素取 值对应的所述约束规则信息包含的其它测试要素对应的取值满足所述约束规则；

第二案例生成子单元，用于将所述目标测试要素取值与所述第四取值组合进行组合形成所述第二案例。

从上述的技术方案可以看出，本申请公开的功能测试案例的生成方法和装置，获取测试规则信息、测试要素、以及测试要素对应的测试要素取值，然后针对测试规则信息生成对应的第一案例，再将获取的每一测试要素取值作为目标测试要素取值，与生成的第一案例包括的测试要素取值进行匹配，如果匹配失败，则针对未匹配成功的目标测试要素取值生成对应的第二案例，最后将第一案例和第二案例进行合并去重，生成案例列表。相比原来测试人员逐条编写案例，减少了案例的设计时间，进而提高了效率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本实施例公开的一种功能测试案例的生成方法的流程图；

图2为本实施例公开的一种针对逻辑规则信息生成案例的方法的流程图；

图3为本实施例公开的一种针对约束规则信息生成案例的方法的流程图；

图4为本实施例公开的一种针对测试要素取值生成案例的方法的流程图；

图5为本实施例公开的一种功能测试案例的生成装置的示意图；

图6为本实施例公开的一种第一案例生成单元的示意图；

图7为本实施例公开的另一种第一案例生成单元的示意图；

图8为本实施例公开的一种第二案例生成单元的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请公开的功能测试案例的生成方法和装置，实现根据测试规则、测试要素、以及测试要素对应的测试要素取值，自动生成功能测试案例，不需要测试人员人工逐条编写案例，减少了功能测试案例的设计时间，提高了效率。

本实施例公开一种功能测试案例的生成方法，参见图1所示，包括：

步骤S11：获取测试规则信息、测试要素、以及测试要素对应的测试要素取值。

要素就是系统功能的基本单元，规则就是要素间的关联关系，描述多个要素之间的关联性，体现业务规则中多个要素的约束或者组合。

步骤S12：针对测试规则信息生成对应的第一案例。

步骤S13：将获取的每一测试要素取值作为目标测试要素取值，与第一案例包括的测试要素取值进行匹配，如果匹配失败，则利用未匹配成功的目标测试要素取值生成对应的第二案例。

步骤S14：将第一案例和第二案例进行合并去重，生成案例列表。

本实施例公开的功能测试案例的生成方法，根据测试规则、测试要素、以及测试要素对应的测试要素取值，自动生成功能测试案例，不需要测试人员人工逐条编写案例，减少了功能测试案例的设计时间，提高了效率。本方法将测试案例编写依据的业务规则划分为测试要素和测试规则部分，以预先定义好的标准来表达着两部分内容，然后通过功能测试案例的生成方法，自动生成功能测试案例。预先进行的标准化定义，保存了功能测试案例生成过程中的中间资产，使得功能测试案例更加容易评审。实现功能测试案例设计的标准化，实现功能测试案例设计思维具体化，实现功能测试案例生产自动化，以及业务规则公式化。

测试规则信息包括：约束规则信息和逻辑规则信息，约束规则信息包括不同测试要素对应的测试要素取值之间的对应关系，逻辑规则信息包括一个测试要素对应的N个测试要素取值与另一个测试要素对应的M个测试要素取值之间的组合关系。例如约束规则信息“C:凭单(交易类别)凭单(支取方式)”表示在交易类别(测试要素)取值为凭单(测试要素取值)时，支取方式只能取值凭单。逻辑规则信息“凭单(交易类别)协议+浮动+牌告(利率信息)”代表生成的案例会将利率方式的“协议、浮动、牌告”这三个取值与交易类别的“凭单”这个取值组合起来生成“凭单 协议”、“凭单 浮动”、“凭单 牌告”三种取值组合。

本实施例公开一种针对逻辑规则信息生成案例的方法，参见图2所示，包括：

步骤S21：根据逻辑规则信息包括的组合关系确定第一测试要素的第一取值组合。

逻辑规则信息包括一个测试要素对应的N个测试要素取值与另一个测试要素对应的M个测试要素取值之间的组合关系。例如，逻辑规则信息“凭单(交易类别)协议+浮动+牌告(利率方式)”代表生成的案例会将利率方式的“协议、浮动、牌告”这三个取值与交易类别的“凭单”这个取值组合起来生成“凭单 协议”、“凭单 浮动”、“凭单 牌告”三种组合取值。即根据逻辑规则信息“凭单协议+浮动+牌告”，可以确定第一测试要素交易类别和利率方式的第一取值组合“凭单 协议”、“凭单 浮动”和“凭单 牌告”三个取值组合。

步骤S22：判断第一测试要素取值是否存在约束规则信息中，如果存在，则确定与第一测试要素对应的测试要素取值存在对应关系的第二测试要素对应的测试要素取值。

确定“凭单 协议”、“凭单 浮动”、“凭单 牌告”三种组合取值后，判断交易类别的取值“凭单”和利率方式的取值“协议”、“浮动” 和“牌告”是否存在约束规则信息中。判断出交易类别的取值“凭单”存在约束约束规则信息“C:凭单 凭单”中，即交易类别取值为凭单时，支取方式只能取值凭单，因此，确定与交易类别的取值“凭单”存在对应关系的支取方式取值为“凭单”。即确定第二测试要素(支取方式)对应的测试要素取值为“凭单”。

步骤S23：针对未确定测试要素取值的第三测试要素，选取第三测试要素对应的测试要素取值形成第二取值组合，如果选取的测试要素取值存在约束规则信息中，则需要保障选取的测试要素取值对应的约束规则信息包含的其它测试要素对应的取值满足所述约束规则。

执行步骤S21和S22后，支取方式、交易类别和利率信息的取值都已经确定，执行步骤S23对于其他还未确定测试要素取值的测试要素，从每个测试要素对应全部测试要素取值中任意选取一个测试要素取值形成取值组合，例如如果还未确定测试要素取值的测试要素为测试要素A和测试要素B，其中测试要素A对应的测试要素取值为A1和A2，从中任意选取一个测试要素取值A1，测试要素B对应的取值为B1和B2，从中任意选取一个测试要素取值B2，形成一个包含测试要素B对应的测试要素取值A1，以及测试要素A对应的测试要素取值B2，的取值组合。如果选取的测试要素取值A1存在某个约束规则信息E中(测试要素A对应的测试要素取值为A1时，测试要素B对应的测试要素取值只能为B1)，则需要保障选取的测试要素取值A1对应的约束规则信息E包含的其它测试要素B对应的测试要素取值满足所述约束规则，由于此时测试要素B选取的测试要素取值是B2，因此，需要选取测试要素B的测试要素取值为B1。也可以是先确定任意一个测试要素的取值，例如，选取测试要素A的任意一个测试要素取值A1，判断选取的测试要素取值A1是否存在约束规则信息中，如果存在某个约束规则信息E中(测试要素A对应的测试要素取值为A1时，测试要素B对应的测试要素取值只能为B1)，则确定与选取的测试要素取值A1存在对应关系的测试要素B的测试要素取值B1；如果不存在，则继续从剩下的未确定测试要素取值的测试要素中，选出 一个测试要素B确定其测试要素取值，直到将所有的测试要素的测试要素取值都确定下来。

步骤S24：将第一取值组合、第二测试要素对应的测试要素取值和第二取值组合进行组合形成第一案例。

本实施例公开一种针对约束规则信息生成案例的方法，参见图3所示，包括：

步骤S31：根据每一约束规则信息包括的对应关系确定第四测试要素对应的测试要素取值。

约束规则信息包括不同测试要素对应的测试要素取值之间的对应关系，例如根据约束规则信息“C:凭单 凭单”确定交易类别取值为凭单，支取方式取值凭单。即第四测试要素交易类别和支取方式的测试要素取值分别为凭单和凭单。

步骤S32：针对未确定测试要素取值的第五测试要素，选取第五测试要素对应的测试要素取值形成第三取值组合，如果选取的测试要素取值存在约束规则信息中，则需要保障选取的测试要素取值对应的约束规则信息包含的其它测试要素对应的取值满足所述约束规则。

步骤S33：将第四测试要素取值与第三取值组合进行组合形成第一案例。

本实施例公开一种针对测试要素取值生成案例的方法，参见图4所示，包括：

步骤S41：针对未确定测试要素取值的第六测试要素，选取第六测试要素对应的测试要素取值形成第三取值组合，如果选取的测试要素取值存在约束规则信息中，则需要保障选取的测试要素取值对应的约束规则信息包含的其它测试要素对应的取值满足约束规则；

步骤S42：将目标测试要素取值与第四取值组合进行组合形成所述第二案例。

本实施例公开一种功能测试案例的生成装置，参见图5所示，包括：

规则获取单元11，用于获取测试规则信息。

要素获取单元12，用于获取测试要素、以及测试要素对应的测试要素取值。

第一案例生成单元13，用于针对测试规则信息生成对应的第一案例。

第二案例生成单元14，用于将获取的每一测试要素取值作为目标测试要素取值，与第一案例包括的测试要素取值进行匹配，如果匹配失败，则利用未匹配成功的目标测试要素取值生成对应的第二案例。

案例列表成成单元15，用于将第一案例和第二案例进行合并去重，生成案例列表。

本实施例公开的功能测试案例的生成装置，根据测试规则、测试要素、以及测试要素对应的测试要素取值，自动生成功能测试案例，不需要测试人员人工逐条编写案例，减少了功能测试案例的设计时间，提高了效率。将测试案例编写依据的业务规则划分为测试要素和测试规则部分，以预先定义好的标准来表达着两部分内容，然后通过功能测试案例的生成装置，自动生成功能测试案例。预先进行的标准化定义，保存了功能测试案例生成过程中的中间资产，使得功能测试案例更加容易评审。实现功能测试案例设计的标准化，实现功能测试案例设计思维具体化，实现功能测试案例生产自动化，以及业务规则公式化。

优选的，规则获取单元11包括：约束规则获取单元，用于获取约束规则信息，约束规则信息包括不同测试要素对应的测试要素取值之间的对应关系；逻辑规则获取单元，用于获取逻辑规则信息，逻辑规则信息包括一个测试要素对应的N个测试要素取值与另一个测试要素对应的M个测试要素取值之间的组合关系。

本实施例公开一种第一案例生成单元，参见图6所示，包括

第一测试要素的取值单元131，用于根据逻辑规则信息包括的组合关系确 定第一测试要素的第一取值组合。

第二测试要素的取值单元132，用于判断第一测试要素对应的测试要素取值是否存在约束规则信息中，如果存在，则确定与第一测试要素对应的测试要素取值存在对应关系的第二测试要素对应的测试要素取值。

第三测试要素的取值单元133，用于针对未确定测试要素取值的第三测试要素，选取第三测试要素对应的测试要素取值形成第二取值组合，如果选取的测试要素取值存在约束规则信息中，则需要保障选取的测试要素取值对应的约束规则信息包含的其它测试要素对应的取值满足约束规则。

案例生成第一子单元134，用于将第一取值组合、第二测试要素对应的测试要素取值和第二取值组合进行组合形成第一案例。

本实施例公开另一种第一案例生成单元，参见图7所示，包括：

第四测试要素的取值单元135，用于根据约束规则信息包括的对应关系确定第四测试要素对应的测试要素取值。

第五测试要素的取值单元136，用于针对未确定测试要素取值的第五测试要素，选取第五测试要素对应的测试要素取值形成第三取值组合，如果选取的测试要素取值存在约束规则信息中，则需要保障选取的测试要素取值对应的约束规则信息包含的其它测试要素对应的取值满足约束规则。

案例生成第二子单元137，用于将第四测试要素对应的测试要素取值与第三取值组合进行组合形成第一案例。

本实施例公开一种第二案例生成单元，参见图8所示，包括：

第六测试要素的取值单元141，用于针对未确定测试要素取值的第六测试要素，选取第六测试要素对应的测试要素取值形成第三取值组合，如果选取的测试要素取值存在约束规则信息中，则需要保障选取的测试要素取值对应的约束规则信息包含的其它测试要素对应的取值满足约束规则。

第二案例生成子单元142，用于将目标测试要素取值与第四取值组合进行 组合形成所述第二案例。

本实施例公开了功能测试案例自动生成的具体过程，下表为测试要素、测试要素对应的测试要素取值、以及测试规则信息。

测试要素，如“交易种类”，以及测试要素取值，如“凭单”、“不凭单”。测试规则包括测试要素之间的关联关系，如“C：凭单 凭单”，表示交易类别取值为凭单时，支取方式取值只能为凭单。“凭单协议+牌告+浮动”，表示交易类别取值为凭单，利率方式为协议、牌告或浮动，即“凭单 协议”、“凭单 牌告”、“凭单 浮动”，三种取值方式。

自动生成功能测试案例的过程为，规则获取单元和要素获取单元分别获取测试规则、测试要素、以及测试要素取值，即在上表中信息。

第一案例生成单元针对逻辑规则生成对应的案例。针对逻辑规则生成案例时，会判断逻辑规则包含的测试要素取值是否在其他约束规则中，如果在其他约束规则中，还需要将相应的其他的测试要素取值确定为约束规则中的取值，比如交易类别取值“凭单”，存在约束规则“C：凭单 凭单”中，因此支取方式取值都确定为“凭单”。

证件种类交易类别支取方式通兑标志机构信息利率方式空凭单凭单不通兑开户机构协议空凭单凭单通兑一级行内非开户机构牌告空凭单凭单通兑开户机构浮动

对于证件种类、通兑标志和机构信息三个未确定取值的测试要素，针对第一个案例的证件种类的取值选择为“空”，然后判断“空”不存在约束规则信息中，然后继续对下一测试要素“通兑标识”取值进行选取，选取的取值为“不通兑”，再然后判断“不通兑”存在约束规则“C：不通兑 开户机构”中，进而根据“C：不通兑 开户机构”确定“机构信息”的取值为“开户机构”。第二个案例和第三个案例的生成过程与第一个案例的生成过程类似，不再赘述。。

第一案例生成单元针对约束规则生成对应的案例。针对每一约束规则分别生成对应的正案例和反案例。正案例是为了验证软件产品可以正常地完成某项功能而不会报错。反案例是为了验证软件产品在遇到某种预先设定的不合规场景时，做出错误提示，并且不再进行后续的处理。

证件种类交易类别支取方式通兑标志机构信息利率方式有效非空凭单凭单通兑开户机构协议有效非空凭单凭印通兑开户机构协议有效非空凭单凭单不通兑开户机构协议有效非空凭单凭单不通兑一级行内非开户机构协议

上表中，第一个案例和第二个案例为针对约束规则“C：凭单 凭单”分别生成的正案例和反案例。第一个案例，首先根据约束规则“C：凭单 凭单”确定交易类别和支取方式的取值分别为“凭单”和“凭单”。对于未确定取值的证件种类、通兑标志、机构信息和利率方式，首选选取证件种类的取值为“有效非空”，然后判断“有效非空”不存在约束规则信息中，然后继续对下一测试要素“通兑标识”取值进行选取，选取的取值为“通兑”，再然后判断“通兑”不存在约束规则中，再对测试要素“机构信息”的取值进行 选取，选取的取值为“开户机构”，判断“开户机构”存在约束规则“C：不通兑开户机构”中，由于约束规则“C：不通兑 开户机构”表示的是通兑标识的取值为“不通兑”时，机构信息的取值只能为“开户机构”，因此，虽然“开户机构”存在约束规则信息中，但是，不影响“通兑标识”的取值，所以不用改变“通兑标识”的取值，进而继续对“利率信息”的取值进行选取，选取的取值为“协议”，判断“协议”不存在约束协议信息中。第二个案例与第一个案例的生成过程只有在根据约束规则“C：凭单 凭单”确定交易类别和支取方式的取值时存在不同，对支取方式的取值取非得到取值“凭印”，后续过程第一案例过程相同。而针对约束规则“C：不通兑 开户机构”生成第四个和第五个案例的过程类似，不再赘述。。第一案例生成单元针对逻辑规则生成对应的案例，以及针对约束规则生成对应的案例可以同时进行，也可以是一先一后，本申请对此不做限定。

判断所有测试要素的所有取值是否都在已经生成的第一案例中，针对未覆盖到的测试案例取值生成对应的第二案例。

证件种类交易类别支取方式通兑标志机构信息利率方式有效非空不凭单凭单通兑一级行内非开户机构协议空不凭单凭单印通兑一级行内非开户机构协议有效非空不凭单凭印不通兑开户机构牌告

例如交易类别取值“不凭单”并不在已经生成的第一案例中，上表中第一个案例为针对“不凭单”生成案例，第二个案例和第三个案例分别针对“凭单印”和“凭印”生成的案例。其生成过程与第一案例中的案例生成过程类似，在此不再赘述。。

将上述生成的所有第一案例和第二案例进行合并去重，得到案例列表。

对于装置实施例而言，由于其基本相应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方， 或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。