CN111352845A - 一种测试序列场景生成方法及装置 - Google Patents

Abstract

本发明公开了一种测试序列场景生成方法及装置，其中方法为：获取待测试软件的全量测试序列有向图和配置信息；确定所述全量测试序列有向图的各测试序列生成有向子图；针对所述各测试序列有向子图中每个测试序列有向子图，根据所述测试序列有向子图及在所述配置信息中对应的子配置信息，生成所述测试序列有向子图的测试序列场景。上述方法应用于金融科技(Fintech)时，确定所述全量测试序列有向图的各测试序列生成有向子图后，可以生成指示应用程序接口的调用顺序、调用资源及约束关系的测试序列场景，从而可以复用全量测试序列有向图和配置信息，提升了应用软件的测试序列场景的效率。

Description

一种测试序列场景生成方法及装置

技术领域

本发明涉及金融科技(Fintech)领域和计算机软件领域，尤其涉及一种测试序列场景生成方法及装置。

背景技术

随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，但由于金融行业的安全性、实时性要求，也对技术提出的更高的要求。应用软件对外提供了大量应用程序接口，可以通过对应用程序接口调用来实现应用软件的相关功能，应用软件在上线之前，要在不同测试序列场景下对应用软件进行测试。一个测试序列场景即为一组多个应用程序接口组成的序列。

目前的方法中，只能依次生成各测试序列场景，即每次都需要手动填写各应用程序接口的测试序列，然后为各应用程序接口填充相应的数据，以及建立各应用程序接口之间的参数关联。当生成下一个测试序列场景时，需要重新按照上述过程生成，导致目前生成应用软件的测试序列场景时效率低下。

发明内容

本发明提供一种测试序列场景生成方法及装置，解决了现有技术中目前生成应用软件的测试序列场景时效率低下的问题。

第一方面，本发明提供一种测试序列场景生成方法，包括：获取待测试软件的全量测试序列有向图和配置信息；所述全量测试序列有向图包括多个节点和多条边；所述多个节点中每个节点都与所述待测试软件的各应用程序接口中一个应用程序接口唯一映射；所述多条边指示了所述各应用程序接口之间的调用顺序；所述配置信息中定义了所述各应用程序接口的调用资源及所述调用资源之间的约束关系；确定所述全量测试序列有向图的各测试序列生成有向子图；针对所述各测试序列有向子图中每个测试序列有向子图，根据所述测试序列有向子图及在所述配置信息中对应的子配置信息，生成所述测试序列有向子图的测试序列场景；从而通过所述测试序列有向子图指示出了所述测试序列场景中的应用程序接口及调用顺序，以及通过所述子配置关系指示出所述测试序列场景中的应用程序接口的调用资源及所述调用资源之间的约束关系。

上述方法中，获取了待测试软件的全量测试序列有向图和配置信息；能够通过所述全量测试序列有向图中多个节点中每个节点都与所述待测试软件的各应用程序接口中一个应用程序接口建立唯一映射的映射关系，以及通过多条边指示了所述各应用程序接口之间的调用顺序，且所述配置信息中定义了所述各应用程序接口的调用资源及所述调用资源之间的约束关系；因此，确定所述全量测试序列有向图的各测试序列生成有向子图后，能够针对每个测试序列有向子图，根据所述测试序列有向子图及在所述配置信息中对应的子配置信息，生成可以指示应用程序接口的调用顺序、调用资源及约束关系的测试序列场景，从而可以复用全量测试序列有向图和配置信息，提升了应用软件的测试序列场景的效率。

一种可选实施方式中，所述各测试序列有向子图的测试序列场景包括断言测试预测场景；所述断言测试预测场景中的应用程序接口中包括测试断言语句；所述测试断言语句用于指示所述应用程序接口的执行状态。

上述方法中，所述各测试序列有向子图的测试序列场景包括断言测试预测场景，断言测试预测场景中的应用程序接口中的测试断言语句用于指示所述应用程序接口的执行状态，从而通过测试断言语句，可以更清楚地反应测试序列场景的测试结果。

一种可选实施方式中，在所述断言测试序列场景下的测试过程中，若确定所述测试断言语句指示的应用程序接口执行状态为执行失败，则直接确定所述断言测试序列场景下的测试失败，并退出所述断言测试序列场景下的测试。

上述方法中，在所述断言测试序列场景下的测试过程中，并不是一直测试到最后才确定所述断言测试序列场景下的测试失败，而是当确定所述测试断言语句指示的应用程序接口执行状态为执行失败，便直接确定所述断言测试序列场景下的测试失败，提前退出所述断言测试序列场景下的测试，从而节约了测试结果输出的时间。

一种可选实施方式中，若确定所述断言测试序列场景下所有的测试断言语句所指示的应用程序接口的执行状态为执行成功，则确定所述断言测试序列场景下的测试成功。

上述方式下，在确定所述断言测试序列场景下所有的测试断言语句所指示的应用程序接口的执行状态为执行成功，才确定所述断言测试序列场景下的测试成功，从而通过测试断言语句进一步验证，增加了断言测试序列场景下测试的健壮性。

一种可选实施方式中，所述各应用程序接口包括：第一操作接口和第二操作接口；所述第二操作接口的调用输入资源为所述第一操作接口的调用输出资源；在所述第一操作接口的测试断言指示所述第一操作接口测试成功之前，所述第一操作接口的调用输出资源在所述第二操作接口侧的执行状态为锁定状态，在所述第一操作接口的测试断言指示所述第一操作接口测试成功之后，所述第一操作接口的调用输出资源在所述第二操作接口侧的执行状态为可用状态。

上述方式下，所述第二操作接口的调用输入资源为所述第一操作接口的调用输出资源；在所述第一操作接口的测试断言指示所述第一操作接口测试成功之前，所述第一操作接口的调用输出资源在所述第二操作接口侧的执行状态为锁定状态，通过对调用输出资源进行了约束，在指示所述第一操作接口测试成功之后才为可用状态，从而增加了测试过程中对调用资源的保护。

一种可选实施方式中，所述确定所述全量测试序列有向图的各测试序列生成有向子图，包括：针对所述各测试序列生成有向子图的每个生成有向子图的起始节点，执行以下步骤：获取目标节点；所述目标节点初始为所述起始节点；若所述目标节点无后续节点，将按所述起始节点遍历至所述目标节点的遍历路径指示的所有边和节点，作为一个测试序列生成有向子图；若所述目标节点有至少一个后续节点，则将所述至少一个后续节点中的后续节点作为所述目标节点，并返回所述获取目标节点的步骤。

上述方法下，获取目标节点后，若所述目标节点无后续节点，将按起始节点遍历至所述目标节点的遍历路径指示的所有边和节点，作为一个测试序列生成有向子图，若所述目标节点有至少一个后续节点，则将所述至少一个后续节点中的后续节点作为所述目标节点，并返回所述获取目标节点的步骤，从而可以一轮遍历到最终的应用程序接口对应的目标节点，给出了一种生成完整的测试序列生成有向子图的方法。

一种可选实施方式中，所述各测试序列生成有向子图的每个生成有向子图的起始节点为所述全量测试序列有向图中入度为0的节点；所述生成有向子图中每个节点的出度均小于2。

上述方法下，所述各测试序列生成有向子图的每个生成有向子图的起始节点为所述全量测试序列有向图中入度为0的节点，从而每个生成有向子图的初始节点对应的应用程序接口无约束调用资源，且生成有向子图中每个节点的出度均小于2，从而使得测试序列有向子图每个节点的后续节点只有一个，每个应用程序接口测试后只确定测试一个应用程序接口，保证了测试序列有向子图的测试序列场景的测试稳定性。

第二方面，本发明提供一种测试序列场景生成装置，包括：获取模块，用于获取待测试软件的全量测试序列有向图和配置信息；所述全量测试序列有向图包括多个节点和多条边；所述多个节点中每个节点都与所述待测试软件的各应用程序接口中一个应用程序接口唯一映射；所述多条边指示了所述各应用程序接口之间的调用顺序；所述配置信息中定义了所述各应用程序接口的调用资源及所述调用资源之间的约束关系；处理模块，用于确定所述全量测试序列有向图的各测试序列生成有向子图；针对所述各测试序列有向子图中每个测试序列有向子图，根据所述测试序列有向子图及在所述配置信息中对应的子配置信息，生成所述测试序列有向子图的测试序列场景；从而通过所述测试序列有向子图指示出了所述测试序列场景中的应用程序接口及调用顺序，以及通过所述子配置关系指示出所述测试序列场景中的应用程序接口的调用资源及所述调用资源之间的约束关系。

一种可选实施方式中，所述各测试序列有向子图的测试序列场景包括断言测试预测场景；所述断言测试预测场景中的应用程序接口中包括测试断言语句；所述测试断言语句用于指示所述应用程序接口的执行状态。

一种可选实施方式中，在所述断言测试序列场景下的测试过程中，若确定所述测试断言语句指示的应用程序接口执行状态为执行失败，则直接确定所述断言测试序列场景下的测试失败，并退出所述断言测试序列场景下的测试。

一种可选实施方式中，若确定所述断言测试序列场景下所有的测试断言语句所指示的应用程序接口的执行状态为执行成功，则确定所述断言测试序列场景下的测试成功。

一种可选实施方式中，所述各应用程序接口包括：第一操作接口和第二操作接口；所述第二操作接口的调用输入资源为所述第一操作接口的调用输出资源；在所述第一操作接口的测试断言指示所述第一操作接口测试成功之前，所述第一操作接口的调用输出资源在所述第二操作接口侧的执行状态为锁定状态，在所述第一操作接口的测试断言指示所述第一操作接口测试成功之后，所述第一操作接口的调用输出资源在所述第二操作接口侧的执行状态为可用状态。

一种可选实施方式中，所述处理模块具体用于：针对所述各测试序列生成有向子图的每个生成有向子图的起始节点，执行以下步骤：获取目标节点；所述目标节点初始为所述起始节点；若所述目标节点无后续节点，将按所述起始节点遍历至所述目标节点的遍历路径指示的所有边和节点，作为一个测试序列生成有向子图；若所述目标节点有至少一个后续节点，则将所述至少一个后续节点中的后续节点作为所述目标节点，并返回所述获取目标节点的步骤。

一种可选实施方式中，所述各测试序列生成有向子图的每个生成有向子图的起始节点为所述全量测试序列有向图中入度为0的节点；所述生成有向子图中每个节点的出度均小于2。

上述第二方面及第二方面各个的有益效果，可以参考上述第一方面及第一方面各个的有益效果，这里不再赘述。

第三方面，本发明提供一种计算机设备，包括程序或指令，当所述程序或指令被执行时，用以执行上述第一方面及第一方面各个可选的方法。

第四方面，本发明提供一种存储介质，包括程序或指令，当所述程序或指令被执行时，用以执行上述第一方面及第一方面各个可选的方法。

附图说明

图1为本申请实施例提供的一种测试序列场景生成方法的步骤流程示意图；

图2为本申请实施例提供的一种测试序列场景生成方法中全量测试序列有向图的示意图；

图3为本申请实施例提供的一种测试序列场景生成方法中测试序列有向子图的示意图；

图4为本申请实施例提供的一种测试序列场景生成方法中测试序列有向子图的示意图；

图5为本申请实施例提供的一种测试序列场景生成方法中测试序列有向子图的示意图；

图6为本申请实施例提供的一种测试序列场景生成装置的结构示意图。

具体实施方式

为了更好的理解上述技术方案，下面将结合说明书附图及具体的实施方式对上述技术方案进行详细的说明，应当理解本申请实施例以及实施例中的具体特征是对本申请技术方案的详细的说明，而不是对本申请技术方案的限定，在不冲突的情况下，本申请实施例以及实施例中的技术特征可以相互结合。

下面首先列出本申请实施例中名词的释义。

应用程序接口(application programming interface，API)：API是软件服务对外提供的应用程序编程接口，通常使用多种方式调用，如网页(Web)方式调用。软件服务之间基于接口耦合，对于接口数据、功能的正确理解和调用是服务集成质量的基础。因此，对于API的测试必不可少。

被测服务：需要测试的软件服务。

API规约：描述了API调用规则等调用信息的文档。

测试生成：API通过调用请求(如超文本传输协议(HyperText TransferProtocol,HTTP)请求)进行调用，在API测试时，通常根据API规约，填写参数的取值，构造调用请求(如HTTP请求)发送给被测服务。

测试序列场景：多个API序列组成的一组测试。

在金融机构(银行机构、保险机构或证券机构)在进行业务(如银行的贷款业务、存款业务等)运转过程中，可以通过对金融机构的应用软件的应用程序接口调用来实现用于软件的相关功能，金融软件在上线之前，要在不同测试序列场景下对应用软件进行测试。

在软件测试中，单个应用程序接口的测试结果一般是不好验证的。蜕变测试中提出了在测试结果不易验证时的另一种解决方案。在蜕变测试中，可以利用应用程序接口本身的特性，或者应用程序接口执行后，通过后续操作来验证应用程序接口是否实现了预期的目标。举例来说，删除接口执行后，只通过一个返回的删除状态码，不能证明要删除的对象确实被删除了。可以进一步对比删除接口前后，查询接口的结果，举例来说，在删除接口执行前，要删除的对象仍在，如果查询接口执行两次后，要删除的对象不在了，则提升了删除接口测试通过的概率。如果查询接口执行两次后，要删除的对象没有从对象列表中移除，便说明查询接口和删除接口出现了问题，可以进一步排查具体问题。显然，通过一系列应用程序接口的测试序列场景来测试软件，可以更好的验证接口的准确性。

现有技术只能依次生成各测试序列场景，每当生成一个测试序列场景时，都需要重复生成过程，导致目前生成应用软件的测试序列场景时效率低下。这种情况不符合银行等金融机构的需求，无法保证金融机构各项业务的高效运转。

为此，如图1所示，本申请提供一种测试序列场景生成方法。

步骤101：获取待测试软件的全量测试序列有向图和配置信息。

步骤102：确定所述全量测试序列有向图的各测试序列生成有向子图。

步骤103：针对所述各测试序列有向子图中每个测试序列有向子图，根据所述测试序列有向子图及在所述配置信息中对应的子配置信息，生成所述测试序列有向子图的测试序列场景。

步骤101中的所述全量测试序列有向图包括多个节点和多条边，全量测试序列有向图用于产生各测试序列生成有向子图。所述多个节点中每个节点都与所述待测试软件的各应用程序接口中一个应用程序接口唯一映射；所述多条边指示了所述各应用程序接口之间的调用顺序。

具体来说，全量测试序列有向图的定义如下：

Scenario∶＝<Nodes,Edges>

其中，Nodes中定义了全量测试序列有向图中的各节点，Edges表示各应用程序接口之间可能的调用顺序。

一个测试序列场景可以定义如下：

ScenarioList∶＝<Spec,Actions,DataSets>

其中：Spec为API规约；Actions描述为操作的集合；DataSets∶＝{<data_name,data_value>}用于接口间数据的传递；需要说明的是，调用一个应用程序接口可以执行Actions中一个或多个操作。

Action的定义如下，对应其中一个操作:

Action∶＝<ID,Name,Inputs,Outputs>；

其中，ID表示操作的标识，用于确认操作的顺序；name表示操作的应用程序接口的名称，需要在Spec中定义；Inputs表示执行该操作前的额外输入，覆盖默认的输入；Outputs表示执行该操作后，需要输出到DataSets的参数。在测试过程中，测试系统可以依次执行测试序列场景中的操作。

另外，配置信息中定义了所述各应用程序接口的调用资源及所述调用资源之间的约束关系，也就是对应于全量测试序列有向图中每个节点的描述信息，可以包括每个应用程序接口需要的额外输入以及输出的信息。

需要说明的是，所述各测试序列有向子图的测试序列场景可以包括断言测试预测场景；所述断言测试预测场景中的应用程序接口中包括测试断言语句；所述测试断言语句用于指示所述应用程序接口的执行状态。

也就是说，对于任一个应用程序接口，都可以设置测试断言语句，从而更面地在测试过程中表征应用程序接口的执行状态。其中，执行状态包括但不限于：执行成功和执行失败。还可以根据具体应用场景设置执行状态，如执行正常、执行异常等。

所述测试断言语句的作用可以包括以下两种：

第一种：

在所述断言测试序列场景下的测试过程中，若确定所述测试断言语句指示的应用程序接口执行状态为执行失败，则直接确定所述断言测试序列场景下的测试失败，并退出所述断言测试序列场景下的测试。

举例来说，断言测试序列场景一中涉及的接口依次为：接口A1、接口A2、接口A3、接口A4。接口A2中设置了断言测试语句，且在接口A2的测试的过程中，A2中的断言测试语句指示的应用程序接口执行状态为执行失败，则直接确定断言测试序列场景一的测试失败。

第二种：

在所述断言测试序列场景下的测试过程中，若确定所述断言测试序列场景下所有的测试断言语句所指示的应用程序接口的执行状态为执行成功，则确定所述断言测试序列场景下的测试成功。

举例来说，断言测试序列场景二中涉及的接口依次为：接口B1、接口B2、接口B3、接口B4、接口B5。接口B2和接口B5中设置了断言测试语句，若在断言测试序列场景二测试过程中，接口B2和接口B5均测试成功，则确定断言测试序列场景二的测试成功。

基于测试断言语句，在一种可选实施方式中，所述各应用程序接口包括：第一操作接口和第二操作接口；所述第二操作接口的调用输入资源为所述第一操作接口的调用输出资源；在所述第一操作接口的测试断言指示所述第一操作接口测试成功之前，所述第一操作接口的调用输出资源在所述第二操作接口侧的执行状态为锁定状态，在所述第一操作接口的测试断言指示所述第一操作接口测试成功之后，所述第一操作接口的调用输出资源在所述第二操作接口侧的执行状态为可用状态。

下面结合图2，详细描述全量测试序列有向图以及配置信息。

需要说明的是，下面列举的只是各应用程序接口的配置信息，并没有列出每个应用程序接口执行的具体功能操作，而测试序列场景中Action中的操作可能是实现了这些具体功能的操作，也可能是配置信息的相关操作。在下列配置信息中，ResourceName；ResourceList为局部变量，作用范围是每个应用程序接口；env-ResourceName；env-ResourceList为全局变量，作用范围是各应用程序接口。下面配置信息以图2示出的5个应用程序接口举例说明，具体包括：创建接口(Create)、查询接口一(Read1)、删除接口(Delete)、更新接口(Update)和查询接口二(Read2)。

Create：

ActionCreate＝<ID＝0,Name＝’Create’,Inputs＝[],Outputs＝[<ResourceName,’equal’,env-ResourceName>]；

Outputs＝[<ResourceName,’equal’,env-ResourceName>]

其中，Outputs中的项含义为，将Create操作中的参数ResourceName写入环境参数env-ResourceName中，并且环境参数env-ResourceName的值等于Create操作中ResourceName的值。

需要说明的是，Create这个应用程序接口执行了具体功能函数Create(){}实际上Create(){}执行过程中就把ResourceName这条资源添加到了资源列表ResourceList中，然后把ResourceName这条资源传给Read1，像将Create中的ResourceList传递给Read1中的ResourceList并没有在配置信息中列出来。

Read1：

ActionRead1＝<ID＝1,Name＝’Read’,

Inputs＝[<Assert1,’assert_in’,[Resource-Name,ResourceList]>]],

Outputs＝[<ResourceList,’equal’,env-ResourceList>]

其中，Inputs项指接收Create传递的ResourceName这条资源，并根据ResourceName查看前一步生成的Resource是否在响应的ResourceList中，即创建操作是否成功完成(也就是create(){}执行是否正常)；Inputs项指将Read操作中的参数ResourceList写入环境参数env-ResourceList中，并且环境参数env-ResourceList的值等于Read操作中ResourceList的值。

Delete：

ActionUpdate＝<ID＝2,Name＝’Update’,

Inputs＝[<ResourceName,’equal’,env-ResourceName>,

<Assert2,’assert_ResourceNotExistException’,

[Resource-Name,env-ResourceList]>],

Outputs＝[<ResourceName,’remove’,env-ResourceList>]

其中，Inputs项的含义为，在参数ResourceName生成时，去寻找环境参数env-ResourceName，并通过等于的方式赋值给参数ResourceName；还增加了一项断言，如果被更新的对象不在资源列表中，那么应当响应的异常抛出；Outputs项的含义为，根据请求参数ResourceName，将环境参数env-ResourceList中对应项移除。

需要说明的是，env-ResourceName是要被删除的资源，也是之前Create创建并在Read1中查询到的资源，通过将env–ResourceName赋值给ResourceName即告诉Delete要删什么资源，首先查一查是不是在env-ResourceList列表中，如果不在，那么删除就无从谈起，在的话才能进行删。即用ResourceName的值(实际上就是env–ResourceName的值)将env-ResourceList中对应项(env–ResourceName移除)。

Update：

ActionDelete＝<ID＝3,Name＝’Delete’,

Inputs＝[<ResourceName,’equal’,env-ResourceName>],

Outputs＝[<ResourceDetail,’update’,env-ResourceList>]

其中，Inputs项的含义为，在参数ResourceName生成时，去寻找环境参数env-ResourceName，并通过等于的方式赋值给参数ResourceName；Outputs项的含义为，根据请求参数ResourceDetail，更新环境参数env-ResourceList中对应项的值。类似Delete，只不过之后一步是用ResourceDetail替换env-ResourceName中资源名为ResourceName的具体资源信息

Read2：

ActionRead2＝<ID＝4,Name＝’Read’,

Inputs＝[<Assert3,’assert_equal’,[ResourceList,env-ResourceList]>],Outputs＝[]

其中，Inputs中的项含义为，增加等于断言，判断响应参数ResourceList与环境参数env-ResourceList是否相等。这一步就是再次验证，就是无论是删除接口调用后，还是更新接口调用后，将目前的ResourceList与实际的ResourceList对比，看是否一致。

以上接口构成了场景中的Nodes，场景中的边包括：<Create,Read1>,<Read1,Update>,<Read1,Delete>,<Delete,Update>,<Delete,Read2>,<Update,Read2>。

需要说明的是，图2示出的矩形节点和实线才属于全量测试序列有向图，矩形节点对应于应用程序接口，实线对应于应用程序接口的调用舒心。而虚线框和椭圆，只是各应用程序接口调用资源转移或约束的形象表示，并不属于全量测试序列有向图。

步骤102的一种具体可选实施方式可以为：

针对所述各测试序列生成有向子图的每个生成有向子图的起始节点，执行以下步骤：获取目标节点；所述目标节点初始为所述起始节点；若所述目标节点无后续节点，将按所述起始节点遍历至所述目标节点的遍历路径指示的所有边和节点，作为一个测试序列生成有向子图；若所述目标节点有至少一个后续节点，则将所述至少一个后续节点中的后续节点作为所述目标节点，并返回所述获取目标节点的步骤。

举例来说，起始节点对应于Create，则第一次遍历时，目标节点对应于Create，后续节点仅有一个Read1；第二次遍历时，目标节点对应于Read1，后续节点有Delete和Update；第三次遍历时，如果后续节点选择Delete对应于目标节点，则第四次遍历时，后续节点仅有一个Read2。那么生成的测试序列生成有向子图为<<Create，Read1，Delete，Read2；<Create，Read1>，<Read1，Delete>，<Delete，Read2>>。

需要说明的是，在上述可选实施方式中的一种可能实施中：

所述各测试序列生成有向子图的每个生成有向子图的起始节点为所述全量测试序列有向图中入度为0的节点；所述生成有向子图中每个节点的出度均小于2。举例来说，每个生成有向子图的起始节点均为Create；子图中也不会出现同时选择Delete和Update为目标节点的情况，即节点后不分叉。

下面结合图3～图5为各测试序列生成有向子图的实例。

图3示出测试序列生成有向子图中，创建完资源后，进行查询操作，根据断言查看新创建的资源是否在资源列表中；图4示出测试序列生成有向子图中，创建完资源后，进行查询操作，根据断言查看新创建的资源是否在资源列表中，若是，则更新资源列表，并在查询接口二中再次断言测试，确定资源列表是否符合预期；图5示出测试序列生成有向子图中，创建完资源后，进行查询操作，根据断言查看新创建的资源是否在资源列表中，若是，则将资源从资源列表中删除，并在查询接口二中再次断言测试，确定资源列表是否符合预期。

通过步骤103，能够通过所述测试序列有向子图指示出了所述测试序列场景中的应用程序接口及调用顺序，以及通过所述子配置关系指示出所述测试序列场景中的应用程序接口的调用资源及所述调用资源之间的约束关系。

如图6所示，本发明提供一种测试序列场景生成装置，包括：获取模块601，用于获取待测试软件的全量测试序列有向图和配置信息；所述全量测试序列有向图包括多个节点和多条边；所述多个节点中每个节点都与所述待测试软件的各应用程序接口中一个应用程序接口唯一映射；所述多条边指示了所述各应用程序接口之间的调用顺序；所述配置信息中定义了所述各应用程序接口的调用资源及所述调用资源之间的约束关系；处理模块602，用于确定所述全量测试序列有向图的各测试序列生成有向子图；针对所述各测试序列有向子图中每个测试序列有向子图，根据所述测试序列有向子图及在所述配置信息中对应的子配置信息，生成所述测试序列有向子图的测试序列场景；从而通过所述测试序列有向子图指示出了所述测试序列场景中的应用程序接口及调用顺序，以及通过所述子配置关系指示出所述测试序列场景中的应用程序接口的调用资源及所述调用资源之间的约束关系。

一种可选实施方式中，所述各测试序列有向子图的测试序列场景包括断言测试预测场景；所述断言测试预测场景中的应用程序接口中包括测试断言语句；所述测试断言语句用于指示所述应用程序接口的执行状态。

一种可选实施方式中，在所述断言测试序列场景下的测试过程中，若确定所述测试断言语句指示的应用程序接口执行状态为执行失败，则直接确定所述断言测试序列场景下的测试失败，并退出所述断言测试序列场景下的测试。

一种可选实施方式中，若确定所述断言测试序列场景下所有的测试断言语句所指示的应用程序接口的执行状态为执行成功，则确定所述断言测试序列场景下的测试成功。

一种可选实施方式中，所述各应用程序接口包括：第一操作接口和第二操作接口；所述第二操作接口的调用输入资源为所述第一操作接口的调用输出资源；在所述第一操作接口的测试断言指示所述第一操作接口测试成功之前，所述第一操作接口的调用输出资源在所述第二操作接口侧的执行状态为锁定状态，在所述第一操作接口的测试断言指示所述第一操作接口测试成功之后，所述第一操作接口的调用输出资源在所述第二操作接口侧的执行状态为可用状态。

一种可选实施方式中，所述处理模块602具体用于：针对所述各测试序列生成有向子图的每个生成有向子图的起始节点，执行以下步骤：获取目标节点；所述目标节点初始为所述起始节点；若所述目标节点无后续节点，将按所述起始节点遍历至所述目标节点的遍历路径指示的所有边和节点，作为一个测试序列生成有向子图；若所述目标节点有至少一个后续节点，则将所述至少一个后续节点中的后续节点作为所述目标节点，并返回所述获取目标节点的步骤。

一种可选实施方式中，所述各测试序列生成有向子图的每个生成有向子图的起始节点为所述全量测试序列有向图中入度为0的节点；所述生成有向子图中每个节点的出度均小于2。

本申请实施例提供一种计算机设备，包括程序或指令，当所述程序或指令被执行时，用以执行本申请实施例提供的一种测试序列场景生成方法及任一可选方法。

本申请实施例提供一种存储介质，包括程序或指令，当所述程序或指令被执行时，用以执行本申请实施例提供的一种测试序列场景生成方法及任一可选方法。

最后应说明的是：本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种测试序列场景生成方法，其特征在于，包括：

获取待测试软件的全量测试序列有向图和配置信息；所述全量测试序列有向图包括多个节点和多条边；所述多个节点中每个节点都与所述待测试软件的各应用程序接口中一个应用程序接口唯一映射；所述多条边指示了所述各应用程序接口之间的调用顺序；所述配置信息中定义了所述各应用程序接口的调用资源及所述调用资源之间的约束关系；

确定所述全量测试序列有向图的各测试序列生成有向子图；

针对所述各测试序列有向子图中每个测试序列有向子图，根据所述测试序列有向子图及在所述配置信息中对应的子配置信息，生成所述测试序列有向子图的测试序列场景；从而通过所述测试序列有向子图指示出了所述测试序列场景中的应用程序接口及调用顺序，以及通过所述子配置关系指示出所述测试序列场景中的应用程序接口的调用资源及所述调用资源之间的约束关系。

2.如权利要求1所述的方法，其特征在于，所述各测试序列有向子图的测试序列场景包括断言测试预测场景；所述断言测试预测场景中的应用程序接口中包括测试断言语句；所述测试断言语句用于指示所述应用程序接口的执行状态。

3.如权利要求2所述的方法，其特征在于，在所述断言测试序列场景下的测试过程中，若确定所述测试断言语句指示的应用程序接口执行状态为执行失败，则直接确定所述断言测试序列场景下的测试失败，并退出所述断言测试序列场景下的测试。

4.如权利要求2所述的方法，其特征在于，若确定所述断言测试序列场景下所有的测试断言语句所指示的应用程序接口的执行状态为执行成功，则确定所述断言测试序列场景下的测试成功。

5.如权利要求2所述的方法，其特征在于，所述各应用程序接口包括：第一操作接口和第二操作接口；所述第二操作接口的调用输入资源为所述第一操作接口的调用输出资源；

在所述第一操作接口的测试断言指示所述第一操作接口测试成功之前，所述第一操作接口的调用输出资源在所述第二操作接口侧的执行状态为锁定状态，在所述第一操作接口的测试断言指示所述第一操作接口测试成功之后，所述第一操作接口的调用输出资源在所述第二操作接口侧的执行状态为可用状态。

6.如权利要求1-5任一项所述的方法，其特征在于，所述确定所述全量测试序列有向图的各测试序列生成有向子图，包括：

针对所述各测试序列生成有向子图的每个生成有向子图的起始节点，执行以下步骤：

获取目标节点；所述目标节点初始为所述起始节点；

若所述目标节点无后续节点，将按所述起始节点遍历至所述目标节点的遍历路径指示的所有边和节点，作为一个测试序列生成有向子图；若所述目标节点有至少一个后续节点，则将所述至少一个后续节点中的后续节点作为所述目标节点，并返回所述获取目标节点的步骤。

7.如权利要求6所述的方法，其特征在于，所述各测试序列生成有向子图的每个生成有向子图的起始节点为所述全量测试序列有向图中入度为0的节点；所述生成有向子图中每个节点的出度均小于2。

8.一种测试序列场景生成装置，其特征在于，包括：

获取模块，用于获取待测试软件的全量测试序列有向图和配置信息；所述全量测试序列有向图包括多个节点和多条边；所述多个节点中每个节点都与所述待测试软件的各应用程序接口中一个应用程序接口唯一映射；所述多条边指示了所述各应用程序接口之间的调用顺序；所述配置信息中定义了所述各应用程序接口的调用资源及所述调用资源之间的约束关系；

处理模块，用于确定所述全量测试序列有向图的各测试序列生成有向子图；针对所述各测试序列有向子图中每个测试序列有向子图，根据所述测试序列有向子图及在所述配置信息中对应的子配置信息，生成所述测试序列有向子图的测试序列场景；从而通过所述测试序列有向子图指示出了所述测试序列场景中的应用程序接口及调用顺序，以及通过所述子配置关系指示出所述测试序列场景中的应用程序接口的调用资源及所述调用资源之间的约束关系。

9.一种计算机设备，其特征在于，包括程序或指令，当所述程序或指令被执行时，如权利要求1至7中任意一项所述的方法被执行。

10.一种存储介质，其特征在于，包括程序或指令，当所述程序或指令被执行时，如权利要求1至7中任意一项所述的方法被执行。

Images