首页> 中国专利> 一种面向复杂资源约束的测试任务调度方法

一种面向复杂资源约束的测试任务调度方法

摘要

本公开涉及一种面向复杂资源约束的测试任务调度方法,涉及自动化测试领域,其中,该方法,包括:根据预设的测试任务依赖关系连接目标系统的测试任务节点,以获取多个测试任务节点的目标有向无环图;根据目标有向无环图获取至少一个测试任务路径,并确定每个测试任务节点在对应测试任务路径中的节点顺序;根据测试资源约束条件和节点顺序依次确定至少一个测试任务路径中的每个测试任务节点的参考测试资源,并根据参考测试资源执行对应的测试脚本。由此,基于目标有向无环图进行测试任务的执行,可以实现测试任务的并行执行,提高了测试效率和对测试资源的利用率,且基于测试资源约束条件进行测试资源的匹配,提高了测试资源的选择可靠性和效率。

著录项

  • 公开/公告号CN113282402A

    专利类型发明专利

  • 公开/公告日2021-08-20

    原文格式PDF

  • 申请/专利号CN202110830206.7

  • 发明设计人 赵国亮;周启平;肖鹏;景涛;

    申请日2021-07-22

  • 分类号G06F9/48(20060101);G06F11/22(20060101);

  • 代理机构11710 北京开阳星知识产权代理有限公司;

  • 代理人王艳斌

  • 地址 100195 北京市海淀区闵庄路3号玉泉慧谷21号楼一层01室

  • 入库时间 2023-06-19 12:18:04

说明书

技术领域

本公开涉及自动化测试技术领域,尤其涉及一种面向复杂资源约束的测试任务调度方法。

背景技术

随着计算机技术的发展,基于云环境的集群资源调度成为普遍。通过云平台技术将各种资源作为测试资源组合在一起形成一个柔性的测试环境,可以为软件测试等提供统一的环境和工具。

相关技术中,为了满足测试需求进行测试资源调度的方式为:测试任务通常根据优先级排入同一队列,并且采用先来先服务或者轮询分时使用的方案分配测试资源并进行测试。

然而,上述测试方式使得测试任务等待时间过长,并且测试资源使用率过低。随着测试需求的不断增加,这种轮询分时等测试方式无论对测试资源的高效利用上还是测试效率上,限制性均较高。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题,公开提供了一种面向复杂资源约束的测试任务调度方法,基于目标有向无环图进行测试任务的执行,可以实现测试任务的并行执行,提高了测试效率和对测试资源的利用率,且基于测试资源约束条件进行测试资源的匹配,提高了测试资源的选择可靠性和效率。

本公开第一方面实施例提出了一种面向复杂资源约束的测试任务调度方法,包括以下步骤:

获取目标系统的多个测试任务节点的描述信息,其中,所述描述信息包括测试脚本、测试资源约束条件;根据预设的测试任务依赖关系连接对应的测试任务节点,以获取所述多个测试任务节点的目标有向无环图;根据所述目标有向无环图获取至少一个测试任务路径,并确定每个所述测试任务节点在对应测试任务路径中的节点顺序;在所述目标系统的多个测试资源中,根据所述测试资源约束条件和所述节点顺序依次确定所述至少一个测试任务路径中的每个测试任务节点的参考测试资源,并根据所述参考测试资源执行对应测试任务节点的测试脚本。

在本公开的一个可选实施例中,在所述根据预设的测试任务依赖关系连接对应的测试任务节点之前,包括:获取每个所述测试任务节点的测试脚本的输入接口类型和输出接口类型;若获取到所述输入接口类型为数据类型的至少一个第一测试任务节点,和所述输出接口类型为所述数据类型的至少一个第二测试任务节点,则确定每个所述第一测试任务节点的输入数据信息,和每个所述第二测试任务节点的输出数据信息;确定所述输入数据信息和所述输出数据信息一致的目标第一测试任务节点和目标第二测试任务节点,其中,所述目标第一测试任务节点和目标第二测试任务节点不同,设置所述目标第二测试任务节点和所述目标第一测试任务节点的前后测试任务依赖关系。

在本公开的一个可选实施例中,还包括:若获取到所述输入接口类型为控制类型的至少一个第三测试任务节点,和所述输出接口类型为所述控制类型的至少一个第四测试任务节点,则确定每个所述第三测试任务节点的输入信号信息,和每个所述第四测试任务节点的输出信号信息;确定所述输入信号信息和所述输出信号信息一致的目标第三测试任务节点和目标第四测试任务节点,其中,所述目标第三测试任务节点和目标第四测试任务节点不同,设置所述目标第三测试任务节点和所述目标第四测试任务节点的前后测试任务依赖关系。

在本公开的一个可选实施例中,所述根据所述测试资源约束条件和所述节点顺序依次确定所述至少一个测试任务路径中的每个测试任务节点的参考测试资源,包括:根据所述测试资源约束条件确定每个所述测试任务节点的测试资源类型和测试资源容量;在所述目标系统的多个测试资源中,确定满足所述测试资源类型和测试资源容量的至少一个候选测试资源;在所述至少一个候选测试资源中确定对应的测试任务节点的参考测试资源。

在本公开的一个可选实施例中,所述在所述至少一个候选测试资源中确定对应的测试任务节点的参考测试资源,包括:在所述至少一个候选测试资源中随机确定一个候选测试资源为对应的测试任务节点的参考测试资源。

在本公开的一个可选实施例中,所述根据所述参考测试资源执行对应测试任务节点的测试脚本,包括:若参考测试资源中的目标测试资源当前包含待执行的多个第五测试任务节点,则根据所述测试资源约束条件确定每个所述第五测试任务节点的执行优先级;根据所述执行优先级对所述多个第五测试任务节点排序获取排序结果,并根据所述排序结果和所述目标测试资源执行所述多个第五测试任务节点的测试脚本。

在本公开的一个可选实施例中,在所述根据所述执行优先级对所述多个第五测试任务节点排序获取排序结果之前,还包括:获取每个所述第五测试任务节点的测试资源容量;根据所述测试资源容量修正所述多个第五测试任务节点的排序结果。

在本公开的一个可选实施例中,在所述根据所述排序结果和所述目标测试资源执行所述多个第五测试任务节点的测试脚本时,还包括:确定所述目标测试资源中当前执行的当前测试脚本,根据所述当前测试脚本对应的第六测试任务节点的测试资源约束条件获取执行限制时长;获取所述当前测试脚本的实际执行时长;判断所述实际执行时长是否大于等于所述第六测试任务节点的执行限制时长;若大于等于所述执行限制时长,则中断执行所述第六测试任务节点的测试脚本并根据所述排序结果执行下一个测试脚本。

本公开第二方面实施例提出了一种面向复杂资源约束的测试任务调度装置,包括:第一获取模块,用于获取目标系统的多个测试任务节点的描述信息,其中,所述描述信息包括测试脚本、测试资源约束条件;第二获取模块,用于根据预设的测试任务依赖关系连接对应的测试任务节点,以获取所述多个测试任务节点的目标有向无环图;确定模块,用于根据所述目标有向无环图获取至少一个测试任务路径,并确定每个所述测试任务节点在对应测试任务路径中的节点顺序;测试模块,用于在所述目标系统的多个测试资源中,根据所述测试资源约束条件和所述节点顺序依次确定所述至少一个测试任务路径中的每个测试任务节点的参考测试资源,并根据所述参考测试资源执行对应测试任务节点的测试脚本。

在本公开的一个可选实施例中,还包括:依赖关系建立模块,用于:获取每个所述测试任务节点的测试脚本的输入接口类型和输出接口类型;若获取到所述输入接口类型为数据类型的至少一个第一测试任务节点,和所述输出接口类型为所述数据类型的至少一个第二测试任务节点,则确定每个所述第一测试任务节点的输入数据信息,和每个所述第二测试任务节点的输出数据信息;确定所述输入数据信息和所述输出数据信息一致的目标第一测试任务节点和目标第二测试任务节点,其中,所述目标第一测试任务节点和目标第二测试任务节点不同,设置所述目标第二测试任务节点和所述目标第一测试任务节点的前后测试任务依赖关系。

在本公开的一个可选实施例中,还包括:所述依赖关系建立模块,还用于:若获取到所述输入接口类型为控制类型的至少一个第三测试任务节点,和所述输出接口类型为所述控制类型的至少一个第四测试任务节点,则确定每个所述第三测试任务节点的输入信号信息,和每个所述第四测试任务节点的输出信号信息;确定所述输入信号信息和所述输出信号信息一致的目标第三测试任务节点和目标第四测试任务节点,其中,所述目标第三测试任务节点和目标第四测试任务节点不同,设置所述目标第三测试任务节点和所述目标第四测试任务节点的前后测试任务依赖关系。

在本公开的一个可选实施例中,所述测试模块,具体用于:根据所述测试资源约束条件确定每个所述测试任务节点的测试资源类型和测试资源容量;在所述目标系统的多个测试资源中,确定与所述测试资源类型和测试资源容量匹配的至少一个候选测试资源;在所述至少一个候选测试资源中确定对应的测试任务节点的参考测试资源。

在本公开的一个可选实施例中,所述测试模块,具体用于:在所述至少一个候选测试资源中随机确定一个候选测试资源为对应的测试任务节点的参考测试资源。

在本公开的一个可选实施例中,所述测试模块,具体用于:若所述参考测试资源中的目标测试资源当前包含待执行的多个第五测试任务节点,则根据所述测试资源约束条件确定每个所述第五测试任务节点的执行优先级;根据所述执行优先级对所述多个第五测试任务节点排序获取排序结果,并根据所述排序结果和所述目标测试资源执行所述多个第五测试任务节点的测试脚本。

在本公开的一个可选实施例中,还包括:修正模块,用于:获取每个所述第五测试任务节点的测试资源容量;根据所述测试资源容量修正所述多个第五测试任务节点的排序结果。

在本公开的一个可选实施例中,还包括:时长控制模块,用于:

确定所述目标测试资源中当前执行的当前测试脚本,根据所述当前测试脚本对应的第六测试任务节点的测试资源约束条件获取执行限制时长;获取所述当前测试脚本的实际执行时长;判断所述实际执行时长是否大于等于所述第六测试任务节点的执行限制时长;若大于等于所述执行限制时长,则中断执行所述第六测试任务节点的测试脚本并根据所述排序结果执行下一个测试脚本。

本公开第三方面实施例提出了一种电子设备,所述电子设备包括:处理器;用于存储所述处理器可执行指令的存储器;所述处理器,用于从所述存储器中读取所述可执行指令,并执行所述指令以实现上述第一方面实施例所描述的一种面向复杂资源约束的测试任务调度方法。

本公开实施例提供的技术方案与现有技术相比具有如下优点:

获取目标系统的多个测试任务节点的描述信息,其中,描述信息包括测试脚本、测试资源约束条件,根据预设的测试任务依赖关系连接对应的测试任务节点,以获取多个测试任务节点的目标有向无环图,进而,根据目标有向无环图获取至少一个测试任务路径,并确定每个测试任务节点在对应测试任务路径中的节点顺序,最后,在目标系统的多个测试资源中,根据测试资源约束条件和节点顺序依次确定至少一个测试任务路径中的每个测试任务节点的参考测试资源,并根据参考测试资源执行对应测试任务节点的测试脚本。由此,基于目标有向无环图进行测试任务的执行,可以实现测试任务的并行执行,提高了测试效率和对测试资源的利用率,且基于测试资源约束条件进行测试资源的匹配,提高了测试资源的选择可靠性和效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理。

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

图1为本公开实施例的一种面向复杂资源约束的测试任务调度方法的流程图;

图2为本公开实施例的一种有向无环图示意图;

图3为本公开实施例的另一种面向复杂资源约束的测试任务调度方法的流程图;

图4为本公开实施例的另一种面向复杂资源约束的测试任务调度方法的流程图;

图5为本公开实施例的另一种面向复杂资源约束的测试任务调度方法的流程图;

图6为本公开实施例的一种面向复杂资源约束的测试任务调度场景示意图;

图7为本公开实施例的一种面向复杂资源约束的测试任务调度装置的结构示意图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点,下面将对本公开的方案进行进一步描述。需要说明的是,在不冲突的情况下,本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开,但本公开还可以采用其他不同于在此描述的方式来实施;显然,说明书中的实施例只是本公开的一部分实施例,而不是全部的实施例。

基于上述背景技术可知,目前的测试需求除了单一的网页测试,可能还包括复杂系统的测试,复杂系统的测试量较大,需要的测试资源除了计算、存储、通信资源之外,还包括测试工具等,另外,复杂系统的测试需求包括多用户同时测试,多类型测试同时执行等。

然而测试资源的容量具有限制性,面向大量的并行测试任务需求,很难同时满足所有测试任务的并行执行。本公开实施例中,提供恰当的测试任务编排和测试执行调度算法,按照一定的目标将测试任务进行合理编排,并且在执行过程中将具体的测试执行活动调度到需要的资源,并在在执行完成后及时释放资源。

下面参考附图描述本申请实施例的面向复杂资源约束的测试任务调度方法,该面向复杂资源约束的测试任务调度方法的执行主体可以是测试云平台等。图1为本公开实施例的一种面向复杂资源约束的测试任务调度方法的流程图,如图1所示,该方法包括:

步骤101,获取目标系统的多个测试任务节点的描述信息,其中,描述信息包括测试脚本、测试资源约束条件。

在本实施例中,多个测试任务节点可以理解为目标系统的所有或部分测试任务,每个测试任务可以理解为对目标系统测试的一个基本单位,在本实施例中,针对测试任务获取对应的描述信息,其中,该描述信息可以是开发人员预先标定在XML文档中的,也可以是根据深度学习技术等总结得到的,该描述信息可以包括测试脚本、测试资源约束条件,其中,测试脚本可以为执行对应测试任务的测试代码,为了提高代码的利用率,该测试脚本可以为无参数的逻辑代码,在本公开的实施例中,为了提高测试脚本的生成效率,可以预先根据测试任务对应的一个或多个功能模块的测试用例,根据测试用例生成对应的测试脚本。

另外,描述信息中的测试资源约束条件用于限定测试任务执行时,所需要的测试资源的类型、测试资源的容量大小、测试的任务标识、对应的测试脚本标识等中的一种或多种,在一些可能的实施例中,测试资源约束条件的代码如下,其中,在该代码中“测试任务1”为该测试资源约束条件对应的测试任务标识、“Tools=IOZone”为测试任务需要的测试资源类型、“Memory=500M”为测试任务需要的测试资源容量:

测试任务1

Tools=IOZone

Memory =500M

步骤102,根据预设的测试任务依赖关系连接对应的测试任务节点,以获取多个测试任务节点的目标有向无环图。

由于在目标系统测试时,不同的测试任务可以有些是前后依赖执行的,有些是可以并行执行的,有的是可以单独执行的等,为了表述这种关系,通过获取预设的测试任务依赖关系,确定测试任务节点之间的连接关系,根据连接关系构建多个测试任务节点的目标有向无环图,这种测试任务依赖关系是测试任务调度的重要依据之一,对于一个测试任务节点,测试任务节点之间的依赖关系即一个测试任务节点的执行,可能影响到另一个测试任务节点的执行;一个测试任务节点的输出结果可能成为另外一个测试任务节点的输入。为了有效描述这依赖关系,并且开展任务调度,将测试任务节点之间的依赖关系描述为有向无环图。

举例而言,如图2所示,当多个测试任务节点为1-10时,根据预设的测试任务依赖关系,构建的目标有向无环图可以直观的获知各个测试任务节点的依赖关系,比如,测试任务节点1、5和7可以并行执行,三者没有依赖关系,测试任务节点2和3依赖于测试任务节点1的执行,是不可以和测试任务节点1并行执行的等。

步骤103,根据目标有向无环图获取至少一个测试任务路径,并确定每个测试任务节点在对应测试任务路径中的节点顺序。

在本实施例中,在目标有向无环图中构建了各个测试任务节点之间的连接关系,因为,按照连接关系由开始到结束构建至少一个测试任务路径,在测试任务路径构建完成后,可以获知各个测试任务节点在对应测试任务路径中的节点顺序,其中,每个测试任务路径可以包括一个或多个测试任务节点。

举例而言,当目标有向无环图包含测试任务节点1-6时,按照节点由开始到结束构建的测试任务路径包括“1-2-4”、“1-3”、和“5-6”,其中,测试任务节点1和5的节点顺序为“1”,测试任务节点2、3和6的节点顺序为“2”,测试任务节点1和5的节点顺序为“3”,对应的测试任务路径限制了,测试任务节点2、3需要在测试任务节点1执行完毕后才能执行等。

步骤104,在目标系统的多个测试资源中,根据测试资源约束条件和节点顺序依次确定至少一个测试任务路径中的每个测试任务节点的参考测试资源,并根据参考测试资源执行对应测试任务节点的测试脚本。

其中,目标系统的多个测试资源包括云测试平台上的集群测试资源,包括计算机等网络测试资源、测试工具(包括摄像头工具等)等工具资源。

在本实施例中,由于测试资源约束条件约束了每个测试任务节点所需要的测试资源的容量和测试资源类型等,因此,可以根据测试资源约束条件确定满足条件的参考测试资源。

在本公开的一个实施例中,如图3所示,根据测试资源约束条件和节点顺序依次确定至少一个测试任务路径中的每个测试任务节点的参考测试资源,包括:

步骤301,根据测试资源约束条件确定每个测试任务节点的测试资源类型和测试资源容量。

其中,测试资源容量表示所需要的测试资源的内存占用值、或者网速占用量、或者占用测试工具的时长等。

比如,若是测试资源类型为网络资源,在对应的测试资源容量为占用的网络流量;比如,若是测试资源类型为内存资源,则对应的测试资源容量为内存占用值等。

步骤302,在目标系统的多个测试资源中,确定与测试资源类型和测试资源容量匹配的至少一个候选测试资源。

在本实施例中,确定每个测试资源的测试资源类型,基于每个测试任务节点的测试资源类型确定匹配的测试资源后,进一步的,计算每个满足测试资源类型的测试资源的空闲资源和每个测试任务节点的测试资源容量的差值,若是该差值大于一定值,则确定对应的测试资源为候选测试资源。

步骤303,在至少一个候选测试资源中确定对应的测试任务节点的参考测试资源。

需要说明的是,在不同的应用场景中,在至少一个候选测试资源中确定对应的测试任务节点的参考测试资源的方式不同,示例如下:

在本公开的一个实施例中,可以在至少一个候选测试资源中随机确定一个候选测试资源为对应的测试任务节点的参考测试资源。

在本公开的另一个实施例中,可以按照每个候选测试资源的空闲资源由大到小的顺序排列,根据排列结果为对应的测试任务节点分配第一排序的测试资源。

需要强调的是,在确定每个测试任务节点的参考测试资源时,所有的测试任务路径可并行选择,比如,对测试任务节点1和5的参考测试资源的确定可以并行确定,由于对测试任务路径中的每个测试任务节点的参考测试资源时,是按照节点顺序选择并执行的,只有当具有依赖关系的上一个测试任务节点执行脚本后,进入下一个测试任务节点的测试资源选择和执行,保证了测试任务的顺利执行以及测试资源的充分利用。

进一步的,在确定对应的参考测试资源后,根据参考测试资源执行对应的测试任务节点的测试脚本,由此,一方面,根据节点顺序依次确定至少一个测试任务路径中的每个测试任务节点的参考测试资源并执行,考虑了测试任务节点之间的依赖关系,保证测试任务的执行可靠性,另一方面,在根据节点顺序控制执行时,不同测试任务路径的节点可以并行执行,大大提高了测试任务的执行效率,保证了测试资源的充分利用。

在实际执行过程中,由于为了提高测试脚本的重复使用率,测试脚本没有写入具体参数时,可以根据上一个测试任务节点的输出参数修改对应的测试脚本的对应参数后再执行。或者,可以将测试任务路径中所有测试脚本的代码组合拼接,整合生成整个测试脚本后,通过将测试任务节点的执行结果作为整个测试脚本的入参进行执行等。在本公开的一个实施例中,为了进一步提高测试效率,还可以基于云测试平台等收集分布式分布的测试资源中的测试结果,进行测试分析。

综上,本公开实施例的一种面向复杂资源约束的测试任务调度方法,获取目标系统的多个测试任务节点的描述信息,其中,描述信息包括测试脚本、测试资源约束条件,根据预设的测试任务依赖关系连接对应的测试任务节点,以获取多个测试任务节点的目标有向无环图,进而,根据目标有向无环图获取至少一个测试任务路径,并确定每个测试任务节点在对应测试任务路径中的节点顺序,最后,在目标系统的多个测试资源中,根据测试资源约束条件和节点顺序依次确定至少一个测试任务路径中的每个测试任务节点的参考测试资源,并根据参考测试资源执行对应测试任务节点的测试脚本。由此,基于目标有向无环图进行测试任务的执行,可以实现测试任务的并行执行,提高了测试效率和对测试资源的利用率,且基于测试资源约束条件进行测试资源的匹配,提高了测试资源的选择可靠性和效率。

需要说明的是,在不同的应用场景中,预设的测试任务依赖关系的确定方式不同,示例如下:

在本公开的一个实施例中,本实施例中的测试资源约束条件中,还包括当前测试任务节点所依赖的测试任务节点的测试任务标识,比如,若是测试任务节点1的测试资源约束条件中描述了依赖的测试任务节点2,则测试任务节点1的执行依赖于测试任务节点2的执行。由此,可以基于依赖的测试任务标识进行测试任务关系的确定。

在本公开的另一个实施例中,考虑到一个测试任务节点的输出结果可能成为另外一个测试任务节点的输入,因此可以根据测试脚本的输入和输出进行测试任务依赖关系的确定。

在本实施例中,如图4所示,在根据预设的测试任务依赖关系连接对应的测试任务节点之前,包括:

步骤401,获取每个测试任务节点的测试脚本的输入接口类型和输出接口类型。

在本实施例中,每个测试任务节点的测试脚本实际上可以看作是执行某个任务功能的一段代码,该代码包括输入接口类型和输出接口类型,其中,输入接口对应于输入参数的输出,输出接口对应于输入参数执行结果的输出。

步骤402,若获取到输入接口类型为数据类型的至少一个第一测试任务节点,和输出接口类型为数据类型的至少一个第二测试任务节点,则确定每个第一测试任务节点的输入数据信息,和每个第二测试任务节点的输出数据信息。

其中,数据类型可以理解为输入接口接收的输入参数为具体的数据,比如,当测试任务节点对应的测试脚本用于执行“对人脸区域进行特效添加”,则该测试任务节点的对应输入接口用于接收数据“人脸区域的位置坐标”等。

步骤403,确定输入数据信息和输出数据信息一致的目标第一测试任务节点和目标第二测试任务节点,其中,目标第一测试任务节点和目标第二测试任务节点不同,设置目标第二测试任务节点和目标第一测试任务节点的前后测试任务依赖关系。

在本实施例中,若是获取到的输入接口类型为数据类型的至少一个第一测试任务节点,和输出接口类型为数据类型的至少一个第二测试任务节点,则确定每个第一测试任务节点的输入数据信息,和每个第二测试任务节点的输出数据信息,该输入数据信息和输出数据信息包括输入或者数据的数据类型(浮点型、整数型等)和数据内容(年龄数据、身高数据等),由于互相有依赖关系的测试脚本的输出和输出必然一致,因此,可以确定输入数据信息和输出数据信息一致的目标第一测试任务节点和目标第二测试任务节点,其中,目标第一测试任务节点和目标第二测试任务节点不同,设置目标第二测试任务节点和目标第一测试任务节点的前后测试任务依赖关系。

继续以上述实施例为例,当目标第二测试任务节点对应的测试脚本用于执行“对人脸区域的位置识别”,则该测试任务节点的对应输出接口用于输出数据“人脸区域的位置坐标”,目标第一测试任务节点对应的测试脚本用于执行“对人脸区域进行特效添加”,则该测试任务节点的对应输入接口用于接收数据“人脸区域的位置坐标”,因此,可以设置目标第二测试任务节点和目标第一测试任务节点的前后测试任务节点的依赖关系。

进一步的,在本公开的一个实施例中,如图4所示,该方法还包括:

步骤404,若获取到输入接口类型为控制类型的至少一个第三测试任务节点,和输出接口类型为控制类型的至少一个第四测试任务节点,则确定每个第三测试任务节点的输入信号信息,和每个第四测试任务节点的输出信号信息。

其中,控制类型表示对应的输出参数或者输入参数为控制类的信号而非具体的数据,举例而言,当测试任务节点的测试代码用户执行“人脸微笑拍照”,则对应的输入接口用于接收“检测到人脸”的信号,因此,确定该测试脚本对应的输入接口类型为控制类。

步骤405,确定输入信号信息和输出信号信息一致的目标第三测试任务节点和目标第四测试任务节点,其中,目标第三测试任务节点和目标第四测试任务节点不同,设置目标第三测试任务节点和目标第四测试任务节点的前后测试任务依赖关系。

在本实施例中,若获取到输入接口类型为控制类型的至少一个第三测试任务节点,和输出接口类型为控制类型的至少一个第四测试任务节点,则确定每个第三测试任务节点的输入信号信息,和每个第四测试任务节点的输出信号信息。其中,输入信号信息和输出信号信息包括输入或者输出信号的信号内容等。

进而,确定输入信号信息和输出信号信息一致的目标第三测试任务节点和目标第四测试任务节点,其中,目标第三测试任务节点和目标第四测试任务节点不同,设置目标第三测试任务节点和目标第四测试任务节点的前后测试任务依赖关系。

举例而言,若目标第四测试任务节点的测试脚本对应的测试功能为“人脸微笑检测”的输出信号信息为“检测到人脸”或者“没有检测到人脸”,目标第三测试任务节点的测试脚本对应的测试任务为“人脸微笑拍照”,对应的输入信号信息为“检测到人脸”响应于该输入信号进行拍照。由此,对应的目标第四测试任务节点和目标第三测试任务节点具有测试业务依赖关系。

综上,本公开实施例的一种面向复杂资源约束的测试任务调度方法,根据测试任务节点之间的业务逻辑构建测试任务依赖关系,提高了基于测试任务依赖关系构建的目标有向无环图的可靠性,为测试任务的调度顺序的编排提供了技术支持。

基于上述实施例,在基于参考测试资源执行对应测试任务节点的测试脚本时,还可以对拥有同样的参考测试资源的测试任务节点构建队列,以队列的形式调度对应的测试脚本,进一步保证了系统测试的自动化执行的可靠性。

在本公开的一个实施例中,如图5所示,根据参考测试资源执行对应测试任务节点的测试脚本,包括:

步骤501,若参考测试资源中的目标测试资源当前包含待执行的多个第五测试任务节点,则根据测试资源约束条件确定每个第五测试任务节点的执行优先级。

容易理解的是,由于不同的测试任务路径的测试任务节点在分配对应的测试资源时,根据各自的节点顺序进行测试资源的分配,因此,可能不同的测试任务节点被分配到同一个参考测试资源中,为了对这种参考测试资源进行调度协调,若参考测试资源中的目标测试资源当前包含待执行的多个第五测试任务节点,则根据测试资源约束条件确定每个第五测试任务节点的执行优先级,比如,通过“Priority=10”表示对应的测试任务节点的执行优先级,

该执行优先级表示对应测试任务节点的任务紧急程度,通常可以根据经验数据标定等。

步骤502,根据执行优先级对多个第五测试任务节点排序获取排序结果,并根据排序结果和目标测试资源执行多个第五测试任务节点的测试脚本。

在本实施例中,根据执行优先级对多个第五测试任务节点排序获取排序结果,比如按照执行优先级由高到低的顺序执行多个第五测试任务节点。由此,当多个第五测试任务节点共用相同的目标测试资源时,根据执行优先级进行测试任务节点的排序,保证了较为重要的测试任务节点的测试任务优先执行。

然而,在一些可能的实施例中,若是执行优先级较高的第五测试任务节点所需要的测试资源容量较高,则可能会导致执行优先级较高的测试任务节点占用目标测试资源的时长较长,目标测试资源中的其他第五测试任务节点等待时长过长,因此,在本实施例中,为了兼顾其他测试任务路径的执行效率,还可以获取每个第五测试任务节点的测试资源容量,根据测试资源容量修正多个第五测试任务节点的排序结果。

在本实施例中,可以计算当前目标测试资源中所有的第五测试任务节点的测试资源容量的容量之和,计算每个第五测试任务节点的测试资源容量和容量之和的比值,按照该比值由小到大的顺序进行排序,根据测试资源容量修正多个第五测试任务节点的排序结果,可以为直接将上述排序结果替换为按照该比值由小到大的顺序进行排序的排序结果,也可以为比较每个第五测试任务节点的在按照该比值由小到大的顺序进行排序的第五排序序列号,和在根据执行优先级排序的第六排序序列号,若是第五排序序列号与第六排序序列号的差值大于一定值,则确定对应的第五测试任务节点的排序为第五排序序列号,其他测试任务节点的排序适应性修改。

在本实施例中,考虑到在一些场景中,能由于测试脚本执行错误等原因,导致测试脚本的执行时长较长,为了避免影响其他测试脚本的执行,在本公开的实施例中,测试资源约束条中还包括对应测试脚本的执行限制时长,比如,测试任务节点A在测试资源约束条件中包括“timeout=10minutes”,则表示对应的测试脚本的执行限制时长为10分钟。

在本实施例中,确定目标测试资源中当前执行的当前测试脚本,根据当前测试脚本对应的第六测试任务节点的测试资源约束条件获取执行限制时长,获取当前测试脚本的实际执行时长,判断实际执行时长是否大于等于第六测试任务节点的执行限制时长,若大于等于所述执行限制时长,则中断执行第六测试任务节点的测试脚本并根据排序结果执行下一个测试脚本。

在本实施例中,还可以将第六测试任务节点的测试脚本放在目标测试资源的队列尾部进行执行,如因为执行时长超时被中断预设次数,则报警通知有关技术人员处理。

为了使得本领域的技术人员更加清楚的了解,本公开实施例的一种面向复杂资源约束的测试任务调度方法,下面参照具体实施例进行说明,其中,在该实施例中的目标有向无环图如图6所示,包括测试任务节点1-10,其中,测试任务路径包括:“1-2-4”、“1-3”、“5-6”、“7-8-9”、“7-8-10”,若是测试任务节点1、5、7对应的参考测试资源均为计算机资源a,则计算测试任务节点1的测试资源容量和计算机资源a的比值为资源利用率t1,同样的,计算测试任务节点5的资源利用率t5,以及测试任务节点7的资源利用率t7,若是t1和t5相等,但是测试任务节点1的执行优先级大于测试任务节点5的执行优先级,若是测试任务节点7的执行优先级大于测试任务节点1、5的执行优先级,且测试任务节点7的测资源利用率t7小于t1和t5,则对测试任务节点1、5、7队列排列结果为测试任务节点7-测试任务节点1-测试任务节点5。

在本实施例中,测试任务节点7执行完毕后,开始根据测试节点7的执行结果触发测试任务节点8的执行,则测试任务节点1执行完毕后,开始根据测试节点1的执行结果触发测试任务节点2和3的执行,测试任务节点5执行完毕后,开始根据测试节点5的执行结果触发测试任务节点6的执行。

其中,如测试任务节点2、3、6、8中部分或者全部测试任务节点对应相同的目标测试资源,则可以根据上述方法结合测试资源容量和执行优先级对对应的测试任务节点进行排序,若是测试任务节点2、3、6、8对应的参考测试资源均不同,则在其依赖的测试任务节点执行完毕后,根据执行结果在对应的参考测试资源下执行对应的测试任务节点的测试脚本,实现了测试任务节点的并行执行。

进一步的,在测试任务节点3执行完毕后,则测试任务路径“1-3”对应的测试任务全部执行完毕,若是测试任务节点2执行完毕后,进一步对测试节点4进行参考资源的调度和执行等,依次类推,基于静态的目标有向无环图进行测试任务的执行顺序等的编排,基于执行优先级以及测试资源容量等动态的进行测试资源的弹性调度。

综上,本公开实施例的一种面向复杂资源约束的测试任务调度方法,综合考虑测试任务节点的执行优先级、等待时间和测试资源容量大小三种因素对测试任务节点在队列中的排序结果和选择结果的影响,进行测试资源的调度,通过采用以静态任务编排和动态测试任务调度为基础的双层测试调度方法,实现测试资源的弹性分配。

为了实现上述实施例,本公开还提出了一种面向复杂资源约束的测试任务调度装置。图7是根据本公开一个实施例的一种面向复杂资源约束的测试任务调度装置的结构示意图,如图7所示,该一种面向复杂资源约束的测试任务调度装置还包括:第一获取模块710、第二获取模块720、确定模块730和测试模块740,其中,

第一获取模块710,用于获取目标系统的多个测试任务节点的描述信息,其中,所述描述信息包括测试脚本、测试资源约束条件;

第二获取模块720,用于根据预设的测试任务依赖关系连接对应的测试任务节点,以获取所述多个测试任务节点的目标有向无环图;

确定模块730,用于根据所述目标有向无环图获取至少一个测试任务路径,并确定每个所述测试任务节点在对应测试任务路径中的节点顺序;

测试模块740,用于在所述目标系统的多个测试资源中,根据所述测试资源约束条件和所述节点顺序依次确定所述至少一个测试任务路径中的每个测试任务节点的参考测试资源,并根据所述参考测试资源执行对应测试任务节点的测试脚本。

需要说明的是,前述对一种面向复杂资源约束的测试任务调度方法的解释说明,也适用于本公开实施例的一种面向复杂资源约束的测试任务调度装置,其实现原理和技术效果类似,在此不再赘述。

为了实现上述实施例,本公开还提出了一种电子设备,电子设备包括:处理器;用于存储所述处理器可执行指令的存储器;所述处理器,用于从所述存储器中读取所述可执行指令,并执行所述指令以实现上述实施例所描述的一种面向复杂资源约束的测试任务调度方法。

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

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

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号