防火墙测试任务的处理方法及装置、电子设备与流程

1.本发明涉及网络资源分配领域，具体而言，涉及一种防火墙测试任务的处理方法及装置、电子设备。


背景技术：

2.随着网络安全市场的打开，越来越多的公司加入到网络安全软件、硬件开发行列中，市场上就开始出现各类防火墙，防火墙设备可以在网络内部和网关出口构建起保护屏障，用以保护用户资料及信息安全，在当前大数据浪潮下成为不可或缺的基础设施，因此，需要实现防火墙的自动化测试。
3.图1是现有技术中一种自动化测试任务与测试资源的示意图，如图1所示，对于web用户提交的多个测试任务，都汇入自动化任务队列中，在自动化任务队列中会对测试任务进行排序；然后对于各个测试任务，可以分别调用总测试资源池中的测试资源执行测试。
4.其中，在调度测试资源时，需要考虑单个任务时效性和多个任务的并行性，单个任务的时效性：是指保证单个测试任务能以最快的速度完成运行；多个任务的并行性：是指测试任务队列里的测试任务能最大化的并行。
5.网络通信产品公司为了快去响应客户定制化的需求，会拉取出多个代码分支，进行功能快速迭代，测试人员对于各个分支都需要提交自动化回归测试，同时，研发针对一些需求或者故障编码后，也需要提交自动化测试进行回归验证测试，因此，自动化测试任务队列中将会有多个测试任务排队等待调度处理，但是供自动化测试的测试资源池内的设备数量有限，如何兼顾单个任务的时效性和多个任务的并行性，就成为自动化测试需要解决的问题。
6.图2是现有技术中一种可选的分别考虑单任务时效性和多任务并行性的资源分配示意图，如图2所示，其包括两种方案：
7.方案1：考虑多个任务的并行性，则将现有的测试资源(图2中以设备1、设备2、设备3和设备4示意说明)中的一部分分配给任务1(图2中以用户a的任务：5000个脚本示意说明)，一部分分配给任务2(图2中以用户b的任务：5000个脚本示意说明)，一部分分配给任务3(图2中以用户c的任务：1个脚本示意说明)，以此类推，从而保证多个任务的并行性。
8.方案2：如果考虑单个任务的时效性，则将所有测试资源都分配给任务1，任务1运行完成后，再将资源释放出来，分配给任务2运行，以此类推，保证单个任务最快时间内运行完。
9.但是上述两种方案都存在明显的问题：对于考虑多任务并行性的方案1:可能会导致每个任务的运行时间都较长；对于考虑单任务时效性的方案2:将所有设备都分配给单个任务，可能会导致设备资源的闲置和浪费。因此，无论是方案1还是方案2，其本质上都需要解决一个问题：到底应当如何合理调度每个测试任务所需的测试资源。
10.同时，在现有的任务调度过程中，还需要考虑不同任务的优先级，对于高优先级的测试任务，通常会强制终止现在正在运行中的任务，抢夺资源给高优先级任务运行，但是现
有的优先级任务抢夺资源的方式，会导致至少一个测试任务的运行被中断，不能顺利完成。
11.针对上述的问题，目前尚未提出有效的解决方案。


技术实现要素：

12.本发明实施例提供了一种防火墙测试任务的处理方法及装置、电子设备，以至少解决相关技术中在测试资源数有限，而等待运行的测试任务很多的情况下，无法合理分配各个测试任务的测试资源的技术问题。
13.根据本发明实施例的一个方面，提供了一种防火墙测试任务的处理方法，包括：获取目标测试任务中包含的测试脚本的脚本总数量；基于所述脚本总数量，确定所述目标测试任务的预期运行时长；根据所述目标测试任务的预期运行时长，计算每种类型的测试资源的需求数量；基于每种类型的所述测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源，执行所述目标测试任务。
14.本方案中，采用基于预期运行时长来评估任务所需资源的方案，根据预期运行时长计算各类型测试资源的需求数量，兼顾单个任务的时效性和多个任务的并行性。
15.可选地，根据所述目标测试任务的预期运行时长，计算每种类型的测试资源的需求数量的步骤，包括：根据所述预期运行时长和所述脚本总数量，计算每个所述测试脚本的执行时长；基于预设任务拆分策略和多种拓扑组网类型，将所述目标测试任务拆分为多个测试子任务，其中，每个所述测试子任务包含至少一个所述测试脚本；将所有所述测试脚本按照各拓扑组网类型进行排序，得到多种脚本排序结果；按照所述脚本排序结果，依次将所述测试脚本拼接到各个所述测试子任务中；基于每个所述测试脚本对测试资源的需求数量，确定每个所述测试子任务对各种类型的测试资源的最大需求数量；累加每个所述测试子任务对各种类型的测试资源的最大需求数量，确定所述目标测试任务对每种类型的测试资源的需求数量。
16.可选地，基于每种类型的所述测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源的步骤，包括：在所述总测试资源池中的剩余资源的资源数量小于所述测试资源的需求数量的情况下，向用户终端发送资源缺乏信息，其中，所述资源缺乏信息至少包括：所述目标测试任务的预期运行时长、缺乏的测试资源类型和资源缺乏数量；接收所述用户终端反馈的允许延期指令，并基于所述允许延期指令，将所述预期运行时长放大指定倍数，得到延期执行时长；基于所述延期执行时长，重新计算每种类型的测试资源的需求数量，并基于每种类型的所述测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源。
17.可选地，基于每种类型的所述测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源的步骤，包括：在所述总测试资源池中所有已知测试资源未被其他测试任务占用，且所述所有已知测试资源的数量小于所述测试资源的需求数量，则发送资源指向指令，其中，所述资源指向指令用于调用所述总测试资源池中所有已知测试资源全部用于所述目标测试任务。
18.可选地，基于每种类型的所述测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源的步骤，包括：在所述目标测试任务的任务优先级高于其他测试任务，且确认所述目标测试任务拥有资源抢占权限的情况下，基于每种类型的所述测试资源
的需求数量和总测试资源池中的剩余资源，计算每种类型的所述测试资源的缺乏数量；从当前运行中的测试任务中借用与所述缺乏数量相同的测试资源，并将借用信息记录至目标数据库中；将所述总测试资源池中的剩余资源和借用的测试资源作为所述可用测试资源；调度所述可用测试资源。
19.可选地，从当前运行中的测试任务中借用与所述缺乏数量相同的测试资源的步骤，包括：获取当前运行中的测试任务中各个测试子任务的拓扑组网，并基于所述拓扑组网中的防火墙资源数量对测试子任务进行排序，得到子任务排序结果；遍历所述子任务排序结果，由第一个测试子任务开始，累加各个所述测试子任务占用的测试资源；在累加资源数量达到所述缺乏数量的情况下，停止遍历操作，并依次借用遍历操作涉及的所述测试子任务的测试资源。
20.可选地，所述借用信息包括：被借用的所述当前运行中的测试任务的任务标识、测试子任务的标识、所述目标测试任务的标识、借用标识、借用设备信息。
21.可选地，在将所述总测试资源池中的剩余资源和借用的测试资源作为所述可用测试资源之后，还包括：控制当前运行中的测试任务中各个测试子任务每运行完一个测试脚本，在所述目标数据库中进行自查操作，其中，所述自查操作用于检查所述测试子任务是否需要出借所述测试资源；在所述自查操作指示所述测试子任务需要出借所述测试资源的情况下，则将剩余未执行的测试脚本拆分出一个独立子任务，并将占用的测试资源设备释放回所述总测试资源池。
22.可选地，在将剩余未执行的测试脚本拆分出一个独立子任务之后，还包括：在所述独立子任务无可用测试资源的情况下，进行等待操作；在检测到借用的测试资源已归还的情况下，控制所述独立子任务调度所述测试资源，执行所述独立子任务。
23.根据本发明实施例的另一方面，还提供了一种防火墙测试任务的处理装置，包括：获取单元，用于获取目标测试任务中包含的测试脚本的脚本总数量；确定单元，用于基于所述脚本总数量，确定所述目标测试任务的预期运行时长；计算单元，用于根据所述目标测试任务的预期运行时长，计算每种类型的测试资源的需求数量；调度单元，用于基于每种类型的所述测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源，执行所述目标测试任务。
24.可选地，所述计算单元包括：第一计算模块，用于根据所述预期运行时长和所述脚本总数量，计算每个所述测试脚本的执行时长；第一拆分模块，用于基于预设任务拆分策略和多种拓扑组网类型，将所述目标测试任务拆分为多个测试子任务，其中，每个所述测试子任务包含至少一个所述测试脚本；第一排序模块，用于将所有所述测试脚本按照各拓扑组网类型进行排序，得到多种脚本排序结果；第一拼接模块，用于按照所述脚本排序结果，依次将所述测试脚本拼接到各个所述测试子任务中；第一确定模块，用于基于每个所述测试脚本对测试资源的需求数量，确定每个所述测试子任务对各种类型的测试资源的最大需求数量；第一累加模块，用于累加每个所述测试子任务对各种类型的测试资源的最大需求数量，确定所述目标测试任务对每种类型的测试资源的需求数量。
25.可选地，所述调度单元包括：第一发送模块，用于在所述总测试资源池中的剩余资源的资源数量小于所述测试资源的需求数量的情况下，向用户终端发送资源缺乏信息，其中，所述资源缺乏信息至少包括：所述目标测试任务的预期运行时长、缺乏的测试资源类型
和资源缺乏数量；第一接收模块，用于接收所述用户终端反馈的允许延期指令，并基于所述允许延期指令，将所述预期运行时长放大指定倍数，得到延期执行时长；第二计算模块，用于基于所述延期执行时长，重新计算每种类型的测试资源的需求数量，并基于每种类型的所述测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源。
26.可选地，所述调度单元还包括：第二发送模块，用于在所述总测试资源池中所有已知测试资源未被其他测试任务占用，且所述所有已知测试资源的数量小于所述测试资源的需求数量，则发送资源指向指令，其中，所述资源指向指令用于调用所述总测试资源池中所有已知测试资源全部用于所述目标测试任务。
27.可选地，所述调度单元还包括：第三计算模块，用于在所述目标测试任务的任务优先级高于其他测试任务，且确认所述目标测试任务拥有资源抢占权限的情况下，基于每种类型的所述测试资源的需求数量和总测试资源池中的剩余资源，计算每种类型的所述测试资源的缺乏数量；第一借用模块，用于从当前运行中的测试任务中借用与所述缺乏数量相同的测试资源，并将借用信息记录至目标数据库中；第一调度模块，用于将所述总测试资源池中的剩余资源和借用的测试资源作为所述可用测试资源；调度所述可用测试资源。
28.可选地，所述第一借用模块包括：第一排序子模块，用于获取当前运行中的测试任务中各个测试子任务的拓扑组网，并基于所述拓扑组网中的防火墙资源数量对测试子任务进行排序，得到子任务排序结果；第一累加子模块，用于遍历所述子任务排序结果，由第一个测试子任务开始，累加各个所述测试子任务占用的测试资源；第一借用子模块，用于在累加资源数量达到所述缺乏数量的情况下，停止遍历操作，并依次借用遍历操作涉及的所述测试子任务的测试资源。
29.可选地，所述借用信息包括：被借用的所述当前运行中的测试任务的任务标识、测试子任务的标识、所述目标测试任务的标识、借用标识、借用设备信息。
30.可选地，防火墙测试任务的处理装置还包括：第一自查模块，用于在将所述总测试资源池中的剩余资源和借用的测试资源作为所述可用测试资源之后，控制当前运行中的测试任务中各个测试子任务每运行完一个测试脚本，在所述目标数据库中进行自查操作，其中，所述自查操作用于检查所述测试子任务是否需要出借所述测试资源；第二拆分模块，用于在所述自查操作指示所述测试子任务需要出借所述测试资源的情况下，则将剩余未执行的测试脚本拆分出一个独立子任务，并将占用的测试资源设备释放回所述总测试资源池。
31.可选地，防火墙测试任务的处理装置还包括：第一等待模块，用于在所述独立子任务无可用测试资源的情况下，进行等待操作；第一执行模块，用于在检测到借用的测试资源已归还的情况下，控制所述独立子任务调度所述测试资源，执行所述独立子任务。
32.根据本发明实施例的另一方面，还提供了一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的防火墙测试任务的处理方法。
33.本发明中，先获取目标测试任务中包含的测试脚本的脚本总数量，基于脚本总数量，确定目标测试任务的预期运行时长，根据目标测试任务的预期运行时长，计算每种类型的测试资源的需求数量，基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源，执行目标测试任务。在本发明中，基于预期运行时长来评估所需测试资源，既能保证单个任务在预期时间内完成，又能保证多个测试任务得以并行，二者兼
顾，从而解决了相关技术中在测试资源数有限，而等待运行的测试任务很多的情况下，无法合理分配各个测试任务的测试资源的技术问题。
34.本发明中，可以通过实时配置和用户容忍设置两种方式进行测试任务预期运行时长的配置，从而保证了预期运行时长的灵活性。
35.本发明中，采用拆分子任务的方式，进行任务优先级处理，达到既能快速处理优先级较高的测试任务，同时不需要中止现有正在运行的任务的技术效果。
附图说明
36.此处所说明的附图用来提供对本发明的进一步理解，构成本技术的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
37.图1是现有技术中一种自动化测试任务与测试资源的示意图；
38.图2是现有技术中一种可选的分别考虑单任务时效性和多任务并行性的资源分配示意图；
39.图3是根据本发明实施例的一种可选的防火墙测试任务的处理方法的流程图；
40.图4是根据本发明实施例的一种可选的借用测试资源的示意图；
41.图5是根据本发明实施例的一种可选的在发生资源借用时进行子任务拆分的示意图
42.图6是根据本发明实施例的一种可选的防火墙测试任务的处理装置的示意图；
43.图7是根据本发明实施例的一种防火墙测试任务的处理方法的电子设备(或移动设备)的硬件结构框图。
具体实施方式
44.为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
45.需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
46.为便于本领域技术人员理解本发明，下面对本发明各实施例中涉及的部分术语或者名词做出解释：
47.测试资源，防火墙产品组建自动化测试通常需要防火墙和测试客户端pc(运行的操作系统不限定，例如windows/linux)两种测试资源，测试pc和防火墙完成组网后，通过操作测试pc，在两个测试pc之间构建网络通信流量，并使流量流经防火墙产品，实现防火墙的
验证功能。
48.测试组网，基于不同的测试资源组成，执行测试任务，测试组网情况纷繁复杂，包括但不限于：客户端(例如，pc机)、路由器、防火墙设备(包括多种接口，firewall)、因特网等。不同的测试组网下，各种类别的测试资源需求数不同，例如，组网1：需要3台防火墙和2台测试pc；组网2：需要4台防火墙。
49.测试脚本，自动化测试编写脚本时，每个测试脚本都将基于特定的测试组网来编写，在脚本中通过telnet(代指telnet协议，是internet远程登录服务的标准协议和主要方式),ssh等方式操作目标测试资源，实现流量构建，防火墙操作，防火墙信息查看等，从而实现测试目标。
50.ssh(secure shell)，是一种建立在应用层基础上的安全协议，利用ssh协议可以有效防止远程管理过程中的信息泄露问题。
51.被测设备，device under test，简称dut。
52.本发明可应用于各种防火墙自动化测试系统/软件/产品中，尤其是实现防火墙多并发自动化测试，能够在多个测试任务同时存在且测试资源有限时，有效分配测试资源，保证任务时效性和并行性，同时，可以在不中断当前正在运行任务的前提下，实现高优先级任务对测试资源的抢占。
53.本发明提供的防火墙测试任务的处理方法及装置，可以实施在防火墙产品测试场景下，本发明中涉及的防火墙自动化测试过程，涉及到的技术概念包括但不限于：测试资源(如防火墙和测试pc)、测试组网、测试脚本、测试任务等。
54.下面结合各个实施例对本发明进行详细说明。
55.实施例一
56.根据本发明实施例，提供了一种防火墙测试任务的处理方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
57.图3是根据本发明实施例的一种可选的防火墙测试任务的处理方法流程图，如图3所示，该方法包括如下步骤：
58.步骤s302，获取目标测试任务中包含的测试脚本的脚本总数量；
59.步骤s304，基于脚本总数量，确定目标测试任务的预期运行时长；
60.步骤s306，根据目标测试任务的预期运行时长，计算每种类型的测试资源的需求数量；
61.步骤s308，基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源，执行目标测试任务。
62.通过上述步骤，可以获取目标测试任务中包含的测试脚本的脚本总数量；基于脚本总数量，确定目标测试任务的预期运行时长；根据目标测试任务的预期运行时长，计算每种类型的测试资源的需求数量；基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源，执行目标测试任务。在该实施例中，可以基于预期运行时长来评估所需资源，既能保证单个任务在预期时间内完成，又能保证多个测试任务得以并行，二者兼顾，从而解决了相关技术中在测试资源数有限，而等待运行的测试任务很多的情况
下，无法合理分配各个测试任务的测试资源的技术问题。
63.下面结合上述各实施步骤来详细说明。
64.步骤s302，获取目标测试任务中包含的测试脚本的脚本总数量。
65.本实施例中涉及的测试任务可以是指防火墙自动化测试任务，为了应对当前各类网络攻击，通过防火墙设备在网络内部和网关出口构建起保护屏障，用以保护用户资料及信息安全，提供更好的使用体验，成为各企业不可或缺的基础设施，在此情况下，需要通过自动化测试任务来确保防火墙设备在功能快速迭代的情况下，做到快速回归，旧有功能不发生衰退。
66.需要说明的是，本实施例中的测试任务可以是通过用户终端/用户web/企业终端等下发的，该测试任务的数量可以为多个，不同时间点可以分别进行测试任务的下发，在系统接收到测试任务后，将所有的测试任务通过任务队列的方式存放，然后调用测试资源池中的测试资源分别执行各个测试任务。
67.需要说明的是，本实施例中的测试任务中可以包含多个测试脚本，本实施例对于每个测试任务所包含的脚本数量不做限定，例如，任务1包含脚本数：5000；任务2包含脚本数：3000，任务3包含脚本数：100个。一个测试任务圈定的测试脚本可能包含不同的测试组网(拓扑)，每种测试组网下的测试脚本数量和运行时长均不相同。
68.本实施例中，在测试脚本中，可以通过telent,ssh等方式操作目标测试资源，实现流量构建、防火墙操作、防火墙信息查看等，从而实现测试目标。每个测试脚本运行所需的设备资源类别和数量不同，每个测试脚本的运行时长可能差别很大，有些脚本在一分钟内可以完成运行，有些则要耗时半个小时甚至更多。
69.步骤s304，基于脚本总数量，确定目标测试任务的预期运行时长。
70.根据预先提交的每个测试任务中包含的脚本总数量，评估一个预期完成的运行时长，例如：
71.脚本数》5000，则预期需要在10小时内完成运行；
72.4000《脚本数≤5000，则预期需要在8小时内完成运行；
73.2000《脚本数≤4000，则预期需要在6小时内完成运行；
74.脚本数≤2000，则预期需要在4小时内完成运行。
75.本实施例中，脚本总数量和预期时长作为每次调度测试任务时，计算测试资源需求数量需要读取的配置，将该脚本总数量和预期时长载入数据库，然后按需实时调整，当总的可用测试资源数较多时，可以将预期运行时长调小，反之调大。
76.步骤s306，根据目标测试任务的预期运行时长，计算每种类型的测试资源的需求数量。
77.本发明实施例中，可以通过测试任务的目标测试任务的预期运行时长，计算每种类型的测试资源的需求数量，可选的，根据目标测试任务的预期运行时长，计算每种类型的测试资源的需求数量的步骤，包括：根据预期运行时长和脚本总数量，计算每个测试脚本的执行时长；基于预设任务拆分策略和多种拓扑组网类型，将目标测试任务拆分为多个测试子任务，其中，每个测试子任务包含至少一个测试脚本；将所有测试脚本按照各拓扑组网类型进行排序，得到多种脚本排序结果；按照脚本排序结果，依次将测试脚本拼接到各个测试子任务中；基于每个测试脚本对测试资源的需求数量，确定每个测试子任务对各种类型的
测试资源的最大需求数量；累加每个测试子任务对各种类型的测试资源的最大需求数量，确定目标测试任务对每种类型的测试资源的需求数量。
78.在计算测试资源的需求数量时，可以通过预期运行时长进行任务预拆解，对于测试任务中的每一个测试脚本，都有一个运行时长信息(对应于上述的计算每个测试脚本的执行时长)，该信息记录了测试脚本完成运行所需的时长，对单个测试任务进行拆分，在拆分过程中，需要确定预设任务拆分策略和测试任务的拓扑组网类型。在任务拆分完成后，将拆分后的测试脚本基于各拓扑组网类型进行排序。
79.例如：组网类型1：脚本1_1，脚本1_2，脚本1_3...脚本1_n1；
80.组网类型2：脚本2_1，脚本2_2，脚本2_3...脚本2_n2；
81.......
82.组网类型n：脚本n_1，脚本n_2，脚本n_3...脚本n_nn。
83.然后根据评估的预期运行时长，将上述测试脚本按顺序，依次拼接到子任务中(对应于上述的按照脚本排序结果，依次将测试脚本拼接到各个测试子任务中)，保证每个子任务运行时长约等于预期运行时长。
84.需要说明的是，本实施例在将测试脚本拼接到各个测试子任务后，基于上述脚本测试组网排序情况，各个测试子任务里的脚本组成为：
85.sub_task1(测试子任务1)：脚本1_1，脚本1_2，脚本1_3，脚本2_1，脚本2_2；
86.sub_task2(测试子任务2)：脚本2_3...脚本2_n2；
87.......
88.sub_taskn(测试子任务n)：脚本3_7，脚本3_8，脚本3_9...脚本m-n。
89.每个测试子任务包含数量不一的测试脚本，且可能包含多种拓扑组网类型的测试脚本，但测试脚本的运行时长总和约等于预期运行时长。
90.根据各个测试子任务中测试脚本所需要的测试资源情况，获取其所需要的最大资源数(对应于上述的确定每个测试子任务对各种类型的测试资源的最大需求数量)，例如，sub_task1中包含两种组网的拓扑，一种组网类型需要4台防火墙，2台linux pc；另一种组网类型需要3台防火墙，1台linux pc,则sub_task1所需最大资源数取最大的一种，是4台防火墙和2台linux pc，其他测试子任务的资源需求计算方法相同。将每个测试子任务所需的最大资源数相加即可得到总任务所需资源总和。
91.步骤s308，基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源，执行目标测试任务。
92.本实施例通过测试资源的需求数量和总测试资源池中的剩余资源，可以调度可用的测试资源，执行各个测试任务。
93.在调度测试资源过程中，本实施例提供了一种容忍度设置方案。在本发明实施例中，基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源的步骤，包括：在总测试资源池中的剩余资源的资源数量小于测试资源的需求数量的情况下，向用户终端发送资源缺乏信息，其中，资源缺乏信息至少包括：目标测试任务的预期运行时长、缺乏的测试资源类型和资源缺乏数量；接收用户终端反馈的允许延期指令，并基于允许延期指令，将预期运行时长放大指定倍数，得到延期执行时长；基于延期执行时长，重新计算每种类型的测试资源的需求数量，并基于每种类型的测试资源的需求数量和总测
试资源池中的剩余资源，调度可用测试资源。
94.在提供容忍度设置方案过程中，当总测试资源池中剩余的测试资源不能满足需求时，可向用户终端进行反馈，由用户终端确认是否接受将预期运行时长放大到原来预期时长的n倍(本实施例中，对于放大的倍数可自行配置，不做限定，例如，2倍、4倍)。如果用户终端发送允许延期指令，则将预期运行时长进行调整后，重新进行资源数评估。
95.在本发明实施例中，基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源的步骤，还包括：在总测试资源池中所有已知测试资源未被其他测试任务占用，且所有已知测试资源的数量小于测试资源的需求数量，则发送资源指向指令，其中，资源指向指令用于调用总测试资源池中所有已知测试资源全部用于目标测试任务。
96.在提供容忍度设置方案过程中，如果总测试资源池中所有设备都未被其它任务占用，但测试资源仍然不能满足当前任务的需求(对应于上述的在总测试资源池中所有已知测试资源未被其他测试任务占用，且所有已知测试资源的数量小于测试资源的需求数量)，则直接申请所有的测试资源进行本次测试(对应于上述的调用总测试资源池中所有已知测试资源全部用于目标测试任务)。
97.通过上述实施步骤，可以基于预期运行时长来评估任务所需资源，从而实现兼顾任务的时效性和并行性。
98.下面对于任务优先级的处理方式进行说明。
99.正常情况下，测试任务按先进先出的顺序依次调度处理，但对于一些紧急的测试项目，需要尽最大可能优先完成调度测试，该测试任务的任务优先级较高，此时对于测试任务队列中加进来的任务，默认优先级为1，对于紧急项目，可标记该项目对应的测试任务优先级为0(本实施例并不对优先级设置方式进行限定，可以通过数字进行标识，也可以通过字母、符号等进行标识，自行进行定义即可)，调度模块优先查找优先级为0的任务进行所需资源评估和分配。
100.在本发明实施例中，基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源的步骤，还包括：在目标测试任务的任务优先级高于其他测试任务，且确认目标测试任务拥有资源抢占权限的情况下，基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，计算每种类型的测试资源的缺乏数量；从当前运行中的测试任务中借用与缺乏数量相同的测试资源，并将借用信息记录至目标数据库中；将总测试资源池中的剩余资源和借用的测试资源作为可用测试资源；调度可用测试资源。
101.本实施例中，将一个测试任务称为父任务，由于测试脚本运行所依赖的测试组网存在差异，依据待测脚本集中的脚本所使用的拓扑组网不同，将它们归类分配到不同的测试子任务中，一个测试子任务包含一系列相同拓扑组网的测试脚本。每个测试子任务作为一个独立的运行单位，将会在后续调配运行的过程中被分配其运行所需要的测试设备，并自动组建网络。
102.在高优先级任务被调度时，当剩余测试资源数目不够时，需要进行资源借用，抢占处理。本实施例中，测试子任务作为任务运行中占用测试资源的最小单元，对于高优先级任务需要临时抢占借用资源时，应该是从正在运行中的测试子任务上进行借用。
103.通过对当前高优先级测试任务所需的测试资源评估，确定仍然缺少的测试资源数
量，基于该缺少的测试资源数量，从正在运行中的测试子任务借用。
104.从当前运行中的测试任务中借用与缺乏数量相同的测试资源的步骤，包括：获取当前运行中的测试任务中各个测试子任务的拓扑组网，并基于拓扑组网中的防火墙资源数量对测试子任务进行排序，得到子任务排序结果；遍历子任务排序结果，由第一个测试子任务开始，累加各个测试子任务占用的测试资源；在累加资源数量达到缺乏数量的情况下，停止遍历操作，并依次借用遍历操作涉及的测试子任务的测试资源。
105.在借用过程中，首先基于上述步骤完成对当前高优先级测试任务所需的测试资源评估，获取各类所需的测试资源数量，如：dut x个，linux pc y个，windows pc z个。然后去除总测试资源池中还剩余测试资源dut m个，linux pc n个，windows pc k个，得到仍然缺少的测试资源数量，dut x-m个，linux pc y-n个，windows pc z-k个。如果三个值均为0，表示剩余的测试资源已满足测试需求，无需作额外的处理，该高优先级任务正常运行即可，否则需要进行资源借用。
106.图4是根据本发明实施例的一种可选的借用测试资源的示意图，如图4所示，包括：检查自己的资源是否需要出借；若是，则启动借用流程；若否，判断是否还存在脚本待运行，若是，则继续运行下一个脚本，若否，则归还当前占用的测试资源父任务资源池；对于借用流程，包括：拆分后面未运行的脚本，组成新的子任务；归还当前占用的测试资源回总资源池；然后在相应的资源表中标记测试资源已借出；结束运行。
107.通过获取现在正在运行中的各个父任务(对应于本实施例中的目标测试任务)下的测试子任务的测试组网(拓扑)，可以按防火墙资源数由多到少排序。遍历这些运行中的子任务，将其占用的测试资源进行累加统计(对应于上述的遍历子任务排序结果，由第一个测试子任务开始，累加各个测试子任务占用的测试资源)，当达到所需资源数时，停止遍历(对应于上述的在累加资源数量达到缺乏数量的情况下，停止遍历操作)。
108.本实施例对于具体的资源排序方式不做限定，具体排序参数和参考属性可以自行设置，优选为按资源数由多到少排序，这样可以保证受到影响的已在运行中的测试任务的数目尽可能的少。例如：如果还缺少6台防火墙设备，则通过上述排序，只需要子任务1和子任务2两个个子任务借出测试资源即可。
109.在找到的需要借用测试资源的测试子任务后，需要在数据库中记录借用的情况。其中，借用信息包括：被借用的当前运行中的测试任务的任务标识、测试子任务的标识、目标测试任务的标识、借用标识、借用设备信息。例如，数据库表中的字段说明如下：父任务id(对应于被借用的当前运行中的测试任务的任务标识):待借出资源的子任务对应的父任务id；子任务id(对应于测试子任务的标识):待借出资源的子任务id；目标任务id(对应于目标测试任务的标识):资源将被借给哪个测试任务id(即对应的高优先级的测试任务)；借出标记：是否已完成借出；借出设备信息：记录借出设备的唯一标识，方便后续归还操作。
110.下面通过表1示意说明一种子任务借出测试资源标记表：
111.表1：子任务借出测试资源标记表
[0112][0113]
通过上述方式，确认需要借用的资源信息，保证了高优先级测试任务可通过抢占借用的测试资源，尽快完成运行。
[0114]
在本发明实施例中，在将总测试资源池中的剩余资源和借用的测试资源作为可用测试资源之后，还包括：控制当前运行中的测试任务中各个测试子任务每运行完一个测试脚本，在目标数据库中进行自查操作，其中，自查操作用于检查测试子任务是否需要出借测试资源；在自查操作指示测试子任务需要出借测试资源的情况下，则将剩余未执行的测试脚本拆分出一个独立子任务，并将占用的测试资源设备释放回总测试资源池。
[0115]
需要说明的是，各个测试子任务运行时，每运行完一个测试脚本，需要进行检查，本实施例中示意说明需要在数据库中检查，查询自己是否需要出借测试资源。即表1中，是否存在子任务id是自己，且借出标记为0的记录；如果存在，则将自己剩余未执行的测试脚本拆分出一个独立的子任务(对应于上述的将剩余未执行的测试脚本拆分出一个独立子任务)，将占用的测试设备释放回总测试资源池(对应于上述的将占用的测试资源设备释放回总测试资源池)，在借出测试资源后，可以更新借出测试资源标记表，借出标记为1，当前测试子任务运行结束。
[0116]
图5是根据本发明实施例的一种可选的在发生资源借用时进行子任务拆分的示意图，如图5所示，对于子任务1-4，其中，子任务2结束时，子任务4开始，同时，在子任务3中间部分发生借用，截取任务3后面的脚本，组成子任务3.1，等待后续调度。
[0117]
经过上述流程后，高优先级任务所需的测试资源将被快速释放回测试资源总池中。从而保证其快速得以运行。高优先级任务运行完成后，需要检查借出测试资源标记表，查询借出标记为1的子任务的父任务是否已经运行结束；如果没有，归还对应的测试设备给目标测试任务。
[0118]
本实施例中，可以按预期时长评估各个测试任务所需的资源数(每个任务的资源数是其下各个子任务所需资源的最大合集)，因此，有可能即便被借用了一些测试资源后，剩余脚本仍然可以顺利完成运行。即当被借用资源只是当前任务资源的子集时，通过拆分子任务的方式，当前被借用资源的测试子任务仍然不受任何影响，可以继续运行。
[0119]
在本发明实施例中，在将剩余未执行的测试脚本拆分出一个独立子任务之后，还包括：在独立子任务无可用测试资源的情况下，进行等待操作；在检测到借用的测试资源已归还的情况下，控制独立子任务调度测试资源，执行独立子任务。
[0120]
需要说明的是，本实施例对于发生借用的子任务对应的父任务(即相对于各个子任务的测试任务，本实施例以目标测试任务进行示意说明)在调度资源给各个子任务过程中，当出现没有任何测试资源可用，但还存在未运行的子任务时，不退出，而是继续等待。直至高优先级任务运行完成归还资源后，所有子任务均可得以调度运行，方才完成运行。
[0121]
通过上述实施方式，采用在运行中拆分子任务的方法进行任务优先级处理的方案，不需要中止现在正在运行中的任务，当被借用资源只是当前任务资源的子集时，甚至当前被借用资源的任务可能不受任何影响。
[0122]
每个父任务运行完成后，需要删除子任务借出测试资源标记表中自己名下的所有子任务的借出记录。
[0123]
通过上述实施方式，实现了高优先级任务以最快的速度抢占到测试资源，同时不中止现有正在运行中的测试任务，只是运行时长长于预期运行时长。
[0124]
下面结合另一种可选的实施例来说明本发明。
[0125]
实施例二
[0126]
本实施例提供了一种防火墙测试任务的处理装置，该防火墙测试任务的处理装置所包含的各个实施单元对应于实施例一中的各个实施步骤。
[0127]
图6是根据本发明实施例的一种可选的防火墙测试任务的处理装置的示意图，如图6所示，包括：获取单元61、确定单元63、计算单元65、调度单元67，其中，
[0128]
获取单元61，用于获取目标测试任务中包含的测试脚本的脚本总数量。
[0129]
本实施例中涉及的测试任务可以是指防火墙自动化测试任务，为了应对当前各类网络攻击，通过防火墙设备在网络内部和网关出口构建起保护屏障，用以保护用户资料及信息安全，提供更好的使用体验，成为各企业不可或缺的基础设施，在此情况下，需要通过自动化测试任务来确保防火墙设备在功能快速迭代的情况下，做到快速回归，旧有功能不发生衰退。
[0130]
需要说明的是，本实施例中的测试任务可以是通过用户终端/用户web/企业终端等下发的，该测试任务的数量可以为多个，不同时间点可以分别进行测试任务的下发，在系统接收到测试任务后，将所有的测试任务通过任务队列的方式存放，然后调用测试资源池中的测试资源分别执行各个测试任务。
[0131]
需要说明的是，本实施例中的测试任务中可以包含多个测试脚本，本实施例对于每个测试任务所包含的脚本数量不做限定。一个测试任务圈定的测试脚本可能包含不同的测试组网(拓扑)，每种测试组网下的测试脚本数量和运行时长均不相同。
[0132]
本实施例中，在测试脚本中，可以通过telent,ssh等方式操作目标测试资源，实现流量构建、防火墙操作、防火墙信息查看等，从而实现测试目标。每个测试脚本运行所需的设备资源类别和数量不同，每个测试脚本的运行时长可能差别很大，有些脚本在一分钟内可以完成运行，有些则要耗时半个小时甚至更多。
[0133]
确定单元63，用于基于脚本总数量，确定目标测试任务的预期运行时长。
[0134]
根据预先提交的每个测试任务中包含的脚本总数量，评估一个预期完成的运行时长。
[0135]
本实施例中，脚本总数量和预期时长作为每次调度测试任务时，计算测试资源需求数量需要读取的配置，将该脚本总数量和预期时长载入数据库，然后按需实时调整，当总
的可用测试资源数较多时，可以将预期运行时长调小，反之调大。
[0136]
计算单元65，用于根据目标测试任务的预期运行时长，计算每种类型的测试资源的需求数量；
[0137]
调度单元67，用于基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源，执行目标测试任务。
[0138]
上述防火墙测试任务的处理装置，可以先通过获取单元61获取目标测试任务中包含的测试脚本的脚本总数量，然后通过确定单元63基于脚本总数量，确定目标测试任务的预期运行时长，通过计算单元65根据目标测试任务的预期运行时长，计算每种类型的测试资源的需求数量，通过调度单元67基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源，执行目标测试任务。在本实施例中，基于预期运行时长来评估所需资源，既能保证单个任务在预期时间内完成，又能保证多个测试任务得以并行，二者兼顾，从而解决了相关技术中在测试资源数有限，而等待运行的测试任务很多的情况下，无法合理分配各个测试任务的测试资源的技术问题。
[0139]
可选地，计算单元包括：第一计算模块，用于根据预期运行时长和脚本总数量，计算每个测试脚本的执行时长；第一拆分模块，用于基于预设任务拆分策略和多种拓扑组网类型，将目标测试任务拆分为多个测试子任务，其中，每个测试子任务包含至少一个测试脚本；第一排序模块，用于将所有测试脚本按照各拓扑组网类型进行排序，得到多种脚本排序结果；第一拼接模块，用于按照脚本排序结果，依次将测试脚本拼接到各个测试子任务中；第一确定模块，用于基于每个测试脚本对测试资源的需求数量，确定每个测试子任务对各种类型的测试资源的最大需求数量；第一累加模块，用于累加每个测试子任务对各种类型的测试资源的最大需求数量，确定目标测试任务对每种类型的测试资源的需求数量。
[0140]
在计算测试资源的需求数量时，可以通过预期运行时长进行任务预拆解，对于测试任务中的每一个测试脚本，都有一个运行时长信息(对应于上述的计算每个测试脚本的执行时长)，该信息记录了测试脚本完成运行所需的时长，对单个测试任务进行拆分，在拆分过程中，需要确定预设任务拆分策略和测试任务的拓扑组网类型。在任务拆分完成后，将拆分后的测试脚本基于各拓扑组网类型进行排序。
[0141]
然后根据评估的预期运行时长，将上述测试脚本按顺序，依次拼接到子任务中(对应于上述的按照脚本排序结果，依次将测试脚本拼接到各个测试子任务中)，保证每个子任务运行时长约等于预期运行时长。
[0142]
需要说明的是，本实施例在将测试脚本拼接到各个测试子任务后，基于上述脚本测试组网排序情况，各个测试子任务里的脚本组成为：
[0143]
sub_task1(测试子任务1)：脚本1_1，脚本1_2，脚本1_3，脚本2_1，脚本2_2；
[0144]
sub_task2(测试子任务2)：脚本2_3...脚本2_n2；
[0145]
......
[0146]
sub_taskn(测试子任务n)：脚本3_7，脚本3_8，脚本3_9...脚本m-n。
[0147]
根据各个测试子任务中测试脚本所需要的测试资源情况，获取其所需要的最大资源数(对应于上述的确定每个测试子任务对各种类型的测试资源的最大需求数量)，例如，sub_task1中包含两种组网的拓扑，一种组网类型需要4台防火墙，2台linux pc；另一种组网类型需要3台防火墙，1台linux pc,则sub_task1所需最大资源数取最大的一种，是4台防
火墙和2台linux pc，其他测试子任务的资源需求计算方法相同。将每个测试子任务所需的最大资源数相加即可得到总任务所需资源总和。
[0148]
可选的，调度单元包括：第一发送模块，用于在总测试资源池中的剩余资源的资源数量小于测试资源的需求数量的情况下，向用户终端发送资源缺乏信息，其中，资源缺乏信息至少包括：目标测试任务的预期运行时长、缺乏的测试资源类型和资源缺乏数量；第一接收模块，用于接收用户终端反馈的允许延期指令，并基于允许延期指令，将预期运行时长放大指定倍数，得到延期执行时长；第二计算模块，用于基于延期执行时长，重新计算每种类型的测试资源的需求数量，并基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源。
[0149]
可选的，调度单元还包括：第二发送模块，用于在总测试资源池中所有已知测试资源未被其他测试任务占用，且所有已知测试资源的数量小于测试资源的需求数量，则发送资源指向指令，其中，资源指向指令用于调用总测试资源池中所有已知测试资源全部用于目标测试任务。
[0150]
在提供容忍度设置方案过程中，当总测试资源池中剩余的测试资源不能满足需求时，可向用户终端进行反馈，由用户终端确认是否接受将预期运行时长放大到原来预期时长的n倍(本实施例中，对于放大的倍数可自行配置，不做限定，例如，2倍、4倍)。如果用户终端发送允许延期指令，则将预期运行时长进行调整后，重新进行资源数评估。
[0151]
在提供容忍度设置方案过程中，如果总测试资源池中所有设备都未被其它任务占用，但测试资源仍然不能满足当前任务的需求(对应于上述的在总测试资源池中所有已知测试资源未被其他测试任务占用，且所有已知测试资源的数量小于测试资源的需求数量)，则直接申请所有的测试资源进行本次测试(对应于上述的调用总测试资源池中所有已知测试资源全部用于目标测试任务)。
[0152]
正常情况下，测试任务按先进先出的顺序依次调度处理，但对于一些紧急的测试项目，需要尽最大可能优先完成调度测试，该测试任务的任务优先级较高，此时对于测试任务队列中加进来的任务，默认优先级为1，对于紧急项目，可标记该项目对应的测试任务优先级为0(本实施例并不对优先级设置方式进行限定，可以通过数字进行标识，也可以通过字母、符号等进行标识，自行进行定义即可)，调度模块优先查找优先级为0的任务进行所需资源评估和分配。
[0153]
可选地，调度单元还包括：第三计算模块，用于在目标测试任务的任务优先级高于其他测试任务，且确认目标测试任务拥有资源抢占权限的情况下，基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，计算每种类型的测试资源的缺乏数量；第一借用模块，用于从当前运行中的测试任务中借用与缺乏数量相同的测试资源，并将借用信息记录至目标数据库中；第一调度模块，用于将总测试资源池中的剩余资源和借用的测试资源作为可用测试资源；调度可用测试资源。
[0154]
可选地，第一借用模块包括：第一排序子模块，用于获取当前运行中的测试任务中各个测试子任务的拓扑组网，并基于拓扑组网中的防火墙资源数量对测试子任务进行排序，得到子任务排序结果；第一累加子模块，用于遍历子任务排序结果，由第一个测试子任务开始，累加各个测试子任务占用的测试资源；第一借用子模块，用于在累加资源数量达到缺乏数量的情况下，停止遍历操作，并依次借用遍历操作涉及的测试子任务的测试资源。
[0155]
本实施例中，将一个测试任务称为父任务，由于测试脚本运行所依赖的测试组网存在差异，依据待测脚本集中的脚本所使用的拓扑组网不同，将它们归类分配到不同的测试子任务中，一个测试子任务包含一系列相同拓扑组网的测试脚本。每个测试子任务作为一个独立的运行单位，将会在后续调配运行的过程中被分配其运行所需要的测试设备，并自动组建网络。
[0156]
在高优先级任务被调度时，当剩余测试资源数目不够时，需要进行资源借用，抢占处理。本实施例中，测试子任务作为任务运行中占用测试资源的最小单元，对于高优先级任务需要临时抢占借用资源时，应该是从正在运行中的测试子任务上进行借用。
[0157]
通过对当前高优先级测试任务所需的测试资源评估，确定仍然缺少的测试资源数量，基于该缺少的测试资源数量，从正在运行中的测试子任务借用。
[0158]
可选地，借用信息包括：被借用的当前运行中的测试任务的任务标识、测试子任务的标识、目标测试任务的标识、借用标识、借用设备信息。
[0159]
可选地，防火墙测试任务的处理装置还包括：第一自查模块，用于在将总测试资源池中的剩余资源和借用的测试资源作为可用测试资源之后，控制当前运行中的测试任务中各个测试子任务每运行完一个测试脚本，在目标数据库中进行自查操作，其中，自查操作用于检查测试子任务是否需要出借测试资源；第二拆分模块，用于在自查操作指示测试子任务需要出借测试资源的情况下，则将剩余未执行的测试脚本拆分出一个独立子任务，并将占用的测试资源设备释放回总测试资源池。
[0160]
通过获取现在正在运行中的各个父任务(对应于本实施例中的目标测试任务)下的测试子任务的测试组网(拓扑)，可以按防火墙资源数由多到少排序。遍历这些运行中的子任务，将其占用的测试资源进行累加统计(对应于上述的遍历子任务排序结果，由第一个测试子任务开始，累加各个测试子任务占用的测试资源)，当达到所需资源数时，停止遍历(对应于上述的在累加资源数量达到缺乏数量的情况下，停止遍历操作)。
[0161]
可选地，防火墙测试任务的处理装置还包括：第一等待模块，用于在独立子任务无可用测试资源的情况下，进行等待操作；第一执行模块，用于在检测到借用的测试资源已归还的情况下，控制独立子任务调度测试资源，执行独立子任务。
[0162]
上述的防火墙测试任务的处理装置还可以包括处理器和存储器，上述获取单元61，确定单元63，计算单元65，调度单元67等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。
[0163]
上述处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源，执行目标测试任务。
[0164]
上述存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)，存储器包括至少一个存储芯片。
[0165]
根据本发明实施例的另一方面，还提供了一种电子设备，包括：处理器；以及存储器，用于存储处理器的可执行指令；其中，处理器配置为经由执行可执行指令来执行上述任意一项的防火墙测试任务的处理方法。
[0166]
根据本发明实施例的另一方面，还提供了一种计算机可读存储介质，计算机可读
存储介质包括存储的计算机程序，其中，在所述计算机程序运行时控制所述计算机可读存储介质所在设备执行上述任意一项的防火墙测试任务的处理方法。
[0167]
本技术还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有如下方法步骤的程序：获取目标测试任务中包含的测试脚本的脚本总数量；基于脚本总数量，确定目标测试任务的预期运行时长；根据目标测试任务的预期运行时长，计算每种类型的测试资源的需求数量；基于每种类型的测试资源的需求数量和总测试资源池中的剩余资源，调度可用测试资源，执行目标测试任务。
[0168]
图7是根据本发明实施例的一种防火墙测试任务的处理方法的电子设备(或移动设备)的硬件结构框图。如图7所示，电子设备可以包括一个或多个(图中采用702a、702b，
……
，702n来示出)处理器702(处理器702可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器704。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、键盘、电源和/或相机。本领域普通技术人员可以理解，图7所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，电子设备还可包括比图7中所示更多或者更少的组件，或者具有与图7所示不同的配置。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
[0169]
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
[0170]
在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
[0171]
在本技术所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
[0172]
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0173]
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0174]
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
[0175]
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。