Firewall test task processing method and device, electronic equipment

Abstract

The present invention discloses a method and device for processing a firewall test task, and an electronic device. The method includes: obtaining the total number of test scripts contained in a target test task; determining the expected running time of the target test task based on the total number of scripts; calculating the required number of each type of test resources according to the expected running time of the target test task; scheduling available test resources based on the required number of each type of test resources and the remaining resources in the total test resource pool to execute the target test task. The present invention solves the technical problem in the related art that the test resources of each test task cannot be reasonably allocated when the number of test resources is limited and there are many test tasks waiting to be run.

Description

Technical Field

[0001] The present invention relates to the field of network resource allocation, and in particular to a method and device for processing a firewall test task, and an electronic device. Background Art

[0002] With the opening of the network security market, more and more companies have joined the ranks of network security software and hardware development, and various types of firewalls have begun to appear on the market. Firewall devices can build a protective barrier inside the network and at the gateway exit to protect user data and information security. In the current wave of big data, it has become an indispensable infrastructure. Therefore, it is necessary to implement automated testing of firewalls.

[0003] Figure 1 It is a schematic diagram of an automated test task and test resources in the prior art, such as Figure 1 As shown, multiple test tasks submitted by web users are all collected into the automated task queue, in which the test tasks are sorted; then for each test task, the test resources in the total test resource pool can be called to execute the test.

[0004] When scheduling test resources, it is necessary to consider the timeliness of a single task and the parallelism of multiple tasks. The timeliness of a single task refers to ensuring that a single test task can be completed at the fastest speed; the parallelism of multiple tasks refers to maximizing the parallelism of test tasks in the test task queue.

[0005] In order to quickly respond to customers' customized needs, network communication product companies will pull out multiple code branches and perform rapid functional iterations. Testers need to submit automated regression tests for each branch. At the same time, after R&D codes some requirements or faults, they also need to submit automated tests for regression verification tests. Therefore, there will be multiple test tasks waiting in the automated test task queue for scheduling and processing. However, the number of devices in the test resource pool for automated testing is limited. How to balance the timeliness of a single task and the parallelism of multiple tasks has become a problem that automated testing needs to solve.

[0006] Figure 2 It is an optional resource allocation diagram in the prior art that considers the timeliness of a single task and the parallelism of multiple tasks respectively, such as Figure 2 As shown, it includes two solutions:

[0007] Solution 1: Considering the parallelism of multiple tasks, the existing test resources ( Figure 2 A portion of the device 1, device 2, device 3 and device 4 are assigned to task 1 ( Figure 2 In the example, user A's task: 5000 scripts are used as a schematic illustration), and a portion is allocated to task 2 ( Figure 2 In the example of user B's task: 5000 scripts), a portion is allocated to task 3 ( Figure 2 In the figure, user C's task: 1 script is used as a schematic illustration), and so on, thereby ensuring the parallelism of multiple tasks.

[0008] Solution 2: If the timeliness of a single task is considered, all test resources are allocated to Task 1. After Task 1 is completed, the resources are released and allocated to Task 2, and so on, to ensure that a single task is completed in the fastest time.

[0009] However, both of the above solutions have obvious problems: for solution 1 that considers multi-task parallelism, it may cause each task to run for a long time; for solution 2 that considers single-task timeliness, allocating all devices to a single task may cause idleness and waste of device resources. Therefore, whether it is solution 1 or solution 2, they essentially need to solve a problem: how to reasonably schedule the test resources required for each test task.

[0010] At the same time, in the existing task scheduling process, the priorities of different tasks also need to be considered. For high-priority test tasks, the currently running tasks are usually forced to terminate to grab resources for the high-priority tasks to run. However, the existing way of grabbing resources by priority tasks will cause the operation of at least one test task to be interrupted and cannot be completed smoothly.

[0011] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0012] The embodiments of the present invention provide a method and device for processing firewall test tasks, and an electronic device, so as to at least solve the technical problem in the related art that when the number of test resources is limited and there are many test tasks waiting to be run, the test resources of each test task cannot be reasonably allocated.

[0013] According to one aspect of an embodiment of the present invention, a method for processing a firewall test task is provided, including: obtaining the total number of test scripts included in a target test task; determining an expected running time of the target test task based on the total number of scripts; calculating the required number of each type of test resources according to the expected running time of the target test task; and scheduling available test resources to execute the target test task based on the required number of each type of test resources and the remaining resources in a total test resource pool.

[0014] In this solution, a solution based on the expected running time is adopted to evaluate the resources required for the task. The required quantity of each type of test resources is calculated according to the expected running time, taking into account the timeliness of a single task and the parallelism of multiple tasks.

[0015] Optionally, the step of calculating the required quantity of each type of test resources according to the expected running time of the target test task includes: calculating the execution time of each test script according to the expected running time and the total number of scripts; splitting the target test task into multiple test subtasks based on a preset task splitting strategy and multiple topology networking types, wherein each test subtask contains at least one test script; sorting all the test scripts according to each topology networking type to obtain multiple script sorting results; splicing the test scripts into each of the test subtasks in turn according to the script sorting results; determining the maximum required quantity of each test subtask for various types of test resources based on the required quantity of test resources for each test script; and determining the required quantity of each type of test resource for the target test task by accumulating the maximum required quantity of each test subtask for various types of test resources.

[0016] Optionally, the step of scheduling available test resources based on the demand quantity of each type of test resources and the remaining resources in the total test resource pool includes: when the number of remaining resources in the total test resource pool is less than the demand quantity of the test resources, sending resource shortage information to the user terminal, wherein the resource shortage information includes at least: the expected running time of the target test task, the type of lacking test resources and the number of resource shortages; receiving an allowable extension instruction fed back by the user terminal, and based on the allowable extension instruction, amplifying the expected running time by a specified multiple to obtain the deferred execution time; based on the deferred execution time, recalculating the demand quantity of each type of test resources, and scheduling available test resources based on the demand quantity of each type of test resources and the remaining resources in the total test resource pool.

[0017] Optionally, the step of scheduling available test resources based on the required quantity of each type of test resources and the remaining resources in the total test resource pool includes: if all known test resources in the total test resource pool are not occupied by other test tasks, and the quantity of all known test resources is less than the required quantity of test resources, a resource pointing instruction is sent, wherein the resource pointing instruction is used to call all known test resources in the total test resource pool for the target test task.

[0018] Optionally, the step of scheduling available test resources based on the demand quantity of each type of test resources and the remaining resources in the total test resource pool includes: calculating the shortage quantity of each type of test resources based on the demand quantity of each type of test resources and the remaining resources in the total test resource pool, when the task priority of the target test task is higher than that of other test tasks and it is confirmed that the target test task has resource preemption authority; borrowing test resources equal to the shortage quantity from the currently running test tasks, and recording the borrowing information in the target database; using the remaining resources in the total test resource pool and the borrowed test resources as the available test resources; and scheduling the available test resources.

[0019] Optionally, the step of borrowing test resources equal to the lacking quantity from the currently running test task includes: obtaining the topological networking of each test subtask in the currently running test task, and sorting the test subtasks based on the number of firewall resources in the topological networking to obtain a subtask sorting result; traversing the subtask sorting results, starting from the first test subtask, and accumulating the test resources occupied by each of the test subtasks; when the accumulated number of resources reaches the lacking quantity, stopping the traversal operation, and borrowing the test resources of the test subtasks involved in the traversal operation in turn.

[0020] Optionally, the borrowing information includes: a task identifier of the borrowed test task currently running, an identifier of a test subtask, an identifier of the target test task, a borrowing identifier, and borrowing device information.

[0021] Optionally, after taking the remaining resources and borrowed test resources in the total test resource pool as the available test resources, it also includes: controlling each test subtask in the currently running test task to perform a self-check operation in the target database after each test script is run, wherein the self-check operation is used to check whether the test subtask needs to lend the test resources; if the self-check operation indicates that the test subtask needs to lend the test resources, the remaining unexecuted test script is split into an independent subtask, and the occupied test resource equipment is released back to the total test resource pool.

[0022] Optionally, after splitting the remaining unexecuted test scripts into an independent subtask, it also includes: when the independent subtask has no available test resources, performing a waiting operation; when it is detected that the borrowed test resources have been returned, controlling the independent subtask to schedule the test resources and execute the independent subtask.

[0023] According to another aspect of an embodiment of the present invention, a device for processing a firewall test task is also provided, including: an acquisition unit, used to acquire the total number of scripts of the test scripts included in the target test task; a determination unit, used to determine the expected running time of the target test task based on the total number of scripts; a calculation unit, used to calculate the required number of each type of test resources according to the expected running time of the target test task; and a scheduling unit, used to schedule available test resources to execute the target test task based on the required number of each type of test resources and the remaining resources in the total test resource pool.

[0024] Optionally, the calculation unit includes: a first calculation module, used to calculate the execution time of each of the test scripts according to the expected running time and the total number of scripts; a first splitting module, used to split the target test task into multiple test subtasks based on a preset task splitting strategy and multiple topology networking types, wherein each of the test subtasks contains at least one test script; a first sorting module, used to sort all the test scripts according to each topology networking type to obtain multiple script sorting results; a first splicing module, used to splice the test scripts into each of the test subtasks in turn according to the script sorting results; a first determination module, used to determine the maximum number of test resources required by each test subtask for various types based on the number of test resources required by each test script; a first accumulation module, used to accumulate the maximum number of test resources required by each test subtask for various types to determine the number of test resources required by the target test task for each type.

[0025] Optionally, the scheduling unit includes: a first sending module, used to send resource shortage information to the user terminal when the number of remaining resources in the total test resource pool is less than the required number of test resources, wherein the resource shortage information includes at least: the expected running time of the target test task, the type of lacking test resources and the number of resource shortages; a first receiving module, used to receive the allowable extension instruction feedback from the user terminal, and based on the allowable extension instruction, amplify the expected running time by a specified multiple to obtain the deferred execution time; a second calculation module, used to recalculate the required number of each type of test resources based on the deferred execution time, and schedule the available test resources based on the required number of each type of test resources and the remaining resources in the total test resource pool.

[0026] Optionally, the scheduling unit also includes: a second sending module, which is used to send a resource pointing instruction when all known test resources in the total test resource pool are not occupied by other test tasks and the number of all known test resources is less than the required number of test resources, wherein the resource pointing instruction is used to call all known test resources in the total test resource pool for the target test task.

[0027] Optionally, the scheduling unit also includes: a third calculation module, used to calculate the shortage quantity of each type of test resources based on the required quantity of each type of test resources and the remaining resources in the total test resource pool, when the task priority of the target test task is higher than that of other test tasks and it is confirmed that the target test task has the resource preemption authority; a first borrowing module, used to borrow test resources equal to the shortage quantity from the currently running test task, and record the borrowing information into the target database; a first scheduling module, used to use the remaining resources and borrowed test resources in the total test resource pool as the available test resources; and schedule the available test resources.

[0028] Optionally, the first borrowing module includes: a first sorting submodule, used to obtain the topological networking of each test subtask in the currently running test task, and sort the test subtasks based on the number of firewall resources in the topological networking to obtain a subtask sorting result; a first accumulation submodule, used to traverse the subtask sorting results, starting from the first test subtask, and accumulate the test resources occupied by each of the test subtasks; a first borrowing submodule, used to stop the traversal operation when the accumulated number of resources reaches the shortage number, and borrow the test resources of the test subtasks involved in the traversal operation in turn.

[0029] Optionally, the borrowing information includes: a task identifier of the borrowed test task currently running, an identifier of a test subtask, an identifier of the target test task, a borrowing identifier, and borrowing device information.

[0030] Optionally, the processing device for the firewall test task also includes: a first self-check module, which is used to control each test subtask in the currently running test task to perform a self-check operation in the target database after the remaining resources and borrowed test resources in the total test resource pool are used as the available test resources, each time a test script is run, wherein the self-check operation is used to check whether the test subtask needs to lend the test resources; and a second splitting module, which is used to split the remaining unexecuted test script into an independent subtask and release the occupied test resource equipment back to the total test resource pool when the self-check operation indicates that the test subtask needs to lend the test resources.

[0031] Optionally, the processing device for the firewall test task also includes: a first waiting module, used to perform a waiting operation when the independent subtask has no available test resources; a first execution module, used to control the independent subtask to schedule the test resources and execute the independent subtask when it is detected that the borrowed test resources have been returned.

[0032] According to another aspect of an embodiment of the present invention, there is also provided an electronic device, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute a processing method for a firewall test task described above by executing the executable instructions.

[0033] In the present invention, the total number of scripts of the test scripts included in the target test task is first obtained, and based on the total number of scripts, the expected running time of the target test task is determined. According to the expected running time of the target test task, the required number of test resources of each type is calculated, and based on the required number of test resources of each type and the remaining resources in the total test resource pool, the available test resources are scheduled to execute the target test task. In the present invention, the required test resources are evaluated based on the expected running time, which can ensure that a single task is completed within the expected time and that multiple test tasks can be run in parallel, thereby solving the technical problem in the related art that the test resources of each test task cannot be reasonably allocated when the number of test resources is limited and there are many test tasks waiting to be run.

[0034] In the present invention, the expected running time of the test task can be configured in two ways: real-time configuration and user tolerance setting, thereby ensuring the flexibility of the expected running time.

[0035] In the present invention, the task priority is processed by splitting the subtasks, so as to achieve the technical effect of quickly processing the test tasks with higher priorities without terminating the existing running tasks. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0037] Figure 1 It is a schematic diagram of an automated test task and test resources in the prior art;

[0038] Figure 2 It is an optional resource allocation diagram in the prior art that considers single-task timeliness and multi-task parallelism respectively;

[0039] Figure 3is a flowchart of an optional method for processing a firewall test task according to an embodiment of the present invention;

[0040] Figure 4 is a schematic diagram of an optional borrowing of test resources according to an embodiment of the present invention;

[0041] Figure 5 is a schematic diagram of an optional subtask splitting when resource borrowing occurs according to an embodiment of the present invention

[0042] Figure 6 is a schematic diagram of an optional device for processing a firewall test task according to an embodiment of the present invention;

[0043] Figure 7 The present invention is a hardware structure block diagram of an electronic device (or mobile device) according to a method for processing a firewall test task in an embodiment of the present invention. DETAILED DESCRIPTION

[0044] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0045] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0046] To facilitate those skilled in the art to understand the present invention, some terms or nouns involved in the embodiments of the present invention are explained below:

[0047] Test resources: Firewall product automation testing usually requires two test resources: a firewall and a test client PC (the operating system it runs is not limited to, such as Windows / Linux). After the test PC and the firewall are networked, the test PC is operated to build network communication traffic between the two test PCs, and the traffic is made to flow through the firewall product to implement the firewall verification function.

[0048] Test networking is based on different test resource components to perform test tasks. Test networking situations are complex and include but are not limited to: clients (e.g., PCs), routers, firewall devices (including multiple interfaces, Firewall), Internet, etc. Under different test networking, the number of test resources required for each category is different. For example, Network 1: 3 firewalls and 2 test PCs are required; Network 2: 4 firewalls are required.

[0049] Test scripts, when writing scripts for automated testing, each test script will be written based on a specific test network. In the script, Telnet (referring to Telnet protocol, which is the standard protocol and main method for Internet remote login services), ssh and other methods are used to operate the target test resources to achieve traffic construction, firewall operation, firewall information viewing, etc., thereby achieving the test objectives.

[0050] SSH (Secure Shell) is a security protocol based on the application layer. The use of SSH protocol can effectively prevent information leakage during remote management.

[0051] Device Under Test, referred to as DUT.

[0052] The present invention can be applied to various firewall automated testing systems / software / products, especially to realize multi-concurrent automated testing of firewalls. When multiple test tasks exist at the same time and test resources are limited, the test resources can be effectively allocated to ensure the timeliness and parallelism of tasks. At the same time, high-priority tasks can preempt test resources without interrupting currently running tasks.

[0053] The method and device for processing firewall test tasks provided by the present invention can be implemented in a firewall product testing scenario. The firewall automated testing process involved in the present invention involves technical concepts including but not limited to: test resources (such as firewalls and test PCs), test networking, test scripts, test tasks, etc.

[0054] The present invention is described in detail below in conjunction with various embodiments.

[0055] Embodiment 1

[0056] According to an embodiment of the present invention, an embodiment of a method for processing a firewall testing task is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0057] Figure 3 FIG. 1 is a flow chart of an optional method for processing a firewall test task according to an embodiment of the present invention. Figure 3 As shown, the method comprises the following steps:

[0058] Step S302, obtaining the total number of test scripts included in the target test task;

[0059] Step S304, determining the expected running time of the target test task based on the total number of scripts;

[0060] Step S306, calculating the required quantity of each type of test resources according to the expected running time of the target test task;

[0061] Step S308: based on the required quantity of each type of test resources and the remaining resources in the total test resource pool, available test resources are scheduled to execute the target test task.

[0062] Through the above steps, the total number of scripts of the test scripts included in the target test task can be obtained; based on the total number of scripts, the expected running time of the target test task is determined; according to the expected running time of the target test task, the required number of test resources of each type is calculated; based on the required number of test resources of each type and the remaining resources in the total test resource pool, the available test resources are scheduled to execute the target test task. In this embodiment, the required resources can be evaluated based on the expected running time, which can ensure that a single task is completed within the expected time and that multiple test tasks can be run in parallel, thereby solving the technical problem in the related art that the test resources of each test task cannot be reasonably allocated when the number of test resources is limited and there are many test tasks waiting to be run.

[0063] The following is a detailed description of each of the above implementation steps.

[0064] Step S302, obtaining the total number of test scripts included in the target test task.

[0065] The test tasks involved in this embodiment may refer to firewall automation test tasks. In order to cope with various current network attacks, firewall devices are used to build a protection barrier inside the network and at the gateway exit to protect user data and information security and provide a better user experience. It has become an indispensable infrastructure for all enterprises. In this case, automated test tasks are needed to ensure that the firewall device can quickly return to the old functions while the functions are rapidly iterating, and the old functions will not decline.

[0066] It should be noted that the test tasks in this embodiment can be issued through user terminals / user webs / enterprise terminals, etc. The number of test tasks can be multiple, and the test tasks can be issued at different time points. After the system receives the test tasks, all test tasks are stored in the form of task queues, and then the test resources in the test resource pool are called to execute each test task separately.

[0067] It should be noted that the test task in this embodiment may include multiple test scripts. This embodiment does not limit the number of scripts included in each test task. For example, Task 1 includes 5000 scripts, Task 2 includes 3000 scripts, and Task 3 includes 100 scripts. The test scripts defined by a test task may include different test networks (topologies), and the number of test scripts and running time under each test network are different.

[0068] In this embodiment, in the test script, the target test resources can be operated by telent, ssh, etc. to achieve traffic construction, firewall operation, firewall information viewing, etc., so as to achieve the test objectives. The type and quantity of device resources required for each test script to run are different, and the running time of each test script may vary greatly. Some scripts can be completed within one minute, while others take half an hour or even more.

[0069] Step S304: determining the expected running time of the target test task based on the total number of scripts.

[0070] Estimate an expected completion time based on the total number of scripts included in each pre-submitted test task, for example:

[0071] If the number of scripts is >5000, it is expected to be completed within 10 hours;

[0072] 4000<number of scripts≤5000, then the run is expected to be completed within 8 hours;

[0073] 2000<number of scripts≤4000, then the run is expected to be completed within 6 hours;

[0074] If the number of scripts is ≤ 2000, the script is expected to be completed within 4 hours.

[0075] In this embodiment, the total number of scripts and the expected duration are used as the configurations that need to be read when calculating the required number of test resources each time a test task is scheduled. The total number of scripts and the expected duration are loaded into the database and then adjusted in real time as needed. When the total number of available test resources is large, the expected running time can be reduced, otherwise it can be increased.

[0076] Step S306: Calculate the required quantity of each type of test resources according to the expected running time of the target test task.

[0077] In an embodiment of the present invention, the required quantity of each type of test resources can be calculated by the expected running time of the target test task of the test task. Optionally, the step of calculating the required quantity of each type of test resources according to the expected running time of the target test task includes: calculating the execution time of each test script according to the expected running time and the total number of scripts; splitting the target test task into multiple test subtasks based on a preset task splitting strategy and multiple topology networking types, wherein each test subtask contains at least one test script; sorting all test scripts according to each topology networking type to obtain multiple script sorting results; splicing the test scripts into each test subtask in turn according to the script sorting results; determining the maximum required quantity of each test subtask for various types of test resources based on the required quantity of each test script for test resources; and determining the required quantity of each type of test resource for the target test task by accumulating the maximum required quantity of each test subtask for various types of test resources.

[0078] When calculating the required number of test resources, the task can be pre-decomposed by the expected running time. For each test script in the test task, there is a running time information (corresponding to the above calculation of the execution time of each test script), which records the time required for the test script to complete the operation. A single test task is split. During the splitting process, it is necessary to determine the preset task splitting strategy and the topological networking type of the test task. After the task splitting is completed, the split test scripts are sorted based on each topological networking type.

[0079] For example: Network type 1: script 1_1, script 1_2, script 1_3...script 1_n1;

[0080] Network type 2: script 2_1, script 2_2, script 2_3...script 2_n2; ......

[0082] Network type n: script n_1, script n_2, script n_3...script n_nn.

[0083] Then, according to the expected running time of the evaluation, the above test scripts are spliced ​​into the subtasks in order (corresponding to the above script sorting results, the test scripts are spliced ​​into each test subtask in order), ensuring that the running time of each subtask is approximately equal to the expected running time.

[0084] It should be noted that, in this embodiment, after the test scripts are spliced ​​into each test subtask, based on the above script test networking sequencing, the scripts in each test subtask are composed as follows:

[0085] sub_task1 (test subtask 1): script 1_1, script 1_2, script 1_3, script 2_1, script 2_2;

[0086] sub_task2 (test subtask 2): script 2_3...script 2_n2; ......

[0088] sub_taskn (test subtask n): script 3_7, script 3_8, script 3_9...script mn.

[0089] Each test subtask contains a varying number of test scripts and may contain test scripts of various topology networking types, but the total running time of the test scripts is approximately equal to the expected running time.

[0090] According to the test resources required by the test scripts in each test subtask, obtain the maximum number of resources required (corresponding to the above determination of the maximum number of test resources required by each test subtask for various types). For example, sub_task1 contains two networking topologies, one networking type requires 4 firewalls and 2 Linux PCs; the other networking type requires 3 firewalls and 1 Linux PC. The maximum number of resources required for sub_task1 is the largest one, which is 4 firewalls and 2 Linux PCs. The resource requirements of other test subtasks are calculated in the same way. Add up the maximum number of resources required for each test subtask to get the total number of resources required for the total task.

[0091] Step S308: based on the required quantity of each type of test resources and the remaining resources in the total test resource pool, available test resources are scheduled to execute the target test task.

[0092] This embodiment can schedule available test resources to execute various test tasks according to the required number of test resources and the remaining resources in the total test resource pool.

[0093] In the process of scheduling test resources, this embodiment provides a tolerance setting scheme. In an embodiment of the present invention, based on the demand quantity of each type of test resources and the remaining resources in the total test resource pool, the step of scheduling available test resources includes: when the number of remaining resources in the total test resource pool is less than the demand quantity of test resources, sending resource shortage information to the user terminal, wherein the resource shortage information includes at least: the expected running time of the target test task, the type of test resources lacking, and the number of resource shortages; receiving the allowable extension instruction fed back by the user terminal, and based on the allowable extension instruction, amplifying the expected running time by a specified multiple to obtain the extended execution time; based on the extended execution time, recalculating the demand quantity of each type of test resources, and scheduling available test resources based on the demand quantity of each type of test resources and the remaining resources in the total test resource pool.

[0094] In the process of providing the tolerance setting scheme, when the remaining test resources in the total test resource pool cannot meet the demand, feedback can be given to the user terminal, and the user terminal confirms whether to accept the expected operation time to be enlarged to n times of the original expected time (in this embodiment, the enlargement multiple can be configured by itself, without limitation, for example, 2 times, 4 times). If the user terminal sends an instruction to allow extension, the expected operation time is adjusted and the resource number is re-evaluated.

[0095] In an embodiment of the present invention, the step of scheduling available test resources based on the required number of test resources of each type and the remaining resources in the total test resource pool also includes: if all known test resources in the total test resource pool are not occupied by other test tasks and the number of all known test resources is less than the required number of test resources, a resource pointing instruction is sent, wherein the resource pointing instruction is used to call all known test resources in the total test resource pool for the target test task.

[0096] In the process of providing a tolerance setting plan, if all devices in the total test resource pool are not occupied by other tasks, but the test resources still cannot meet the needs of the current task (corresponding to the above-mentioned that all known test resources in the total test resource pool are not occupied by other test tasks, and the number of all known test resources is less than the required number of test resources), then all test resources are directly applied for this test (corresponding to the above-mentioned call of all known test resources in the total test resource pool for the target test task).

[0097] Through the above implementation steps, the resources required for the task can be evaluated based on the expected running time, so as to achieve a balance between the timeliness and parallelism of the task.

[0098] The following describes how to handle task priorities.

[0099] Under normal circumstances, test tasks are scheduled and processed in sequence in the order of first-in, first-out. However, for some urgent test projects, it is necessary to complete the scheduled test as much as possible. The task priority of this test task is higher. At this time, the default priority of the task added to the test task queue is 1. For urgent projects, the test task priority corresponding to the project can be marked as 0 (this embodiment does not limit the priority setting method, and it can be identified by numbers, letters, symbols, etc., which can be defined by yourself). The scheduling module prioritizes tasks with a priority of 0 to evaluate and allocate the required resources.

[0100] In an embodiment of the present invention, the step of scheduling available test resources based on the demand quantity of each type of test resources and the remaining resources in the total test resource pool also includes: when the task priority of the target test task is higher than that of other test tasks and it is confirmed that the target test task has resource preemption authority, calculating the shortage quantity of each type of test resources based on the demand quantity of each type of test resources and the remaining resources in the total test resource pool; borrowing test resources equal to the shortage quantity from the currently running test tasks, and recording the borrowing information in the target database; using the remaining resources in the total test resource pool and the borrowed test resources as available test resources; and scheduling the available test resources.

[0101] In this embodiment, a test task is called a parent task. Since the test networks that the test scripts rely on are different, they are classified and assigned to different test subtasks according to the different topological networks used by the scripts in the script set to be tested. A test subtask contains a series of test scripts with the same topological network. Each test subtask, as an independent running unit, will be assigned the test equipment required for its operation in the subsequent deployment and operation process, and automatically form a network.

[0102] When a high-priority task is scheduled, if the number of remaining test resources is insufficient, resource borrowing and preemption processing is required. In this embodiment, the test subtask is the smallest unit that occupies test resources during task operation. When a high-priority task needs to temporarily preempt and borrow resources, it should be borrowed from the running test subtask.

[0103] By evaluating the test resources required by the current high-priority test task, the number of test resources that are still missing is determined, and based on the missing number of test resources, they are borrowed from the running test subtasks.

[0104] The step of borrowing the same number of test resources as the lacking number from the currently running test task includes: obtaining the topological networking of each test subtask in the currently running test task, and sorting the test subtasks based on the number of firewall resources in the topological networking to obtain the subtask sorting result; traversing the subtask sorting result, starting from the first test subtask, and accumulating the test resources occupied by each test subtask; when the accumulated number of resources reaches the lacking number, stopping the traversal operation, and borrowing the test resources of the test subtasks involved in the traversal operation in turn.

[0105] In the borrowing process, firstly, the test resources required for the current high-priority test task are evaluated based on the above steps, and the number of test resources required for each type is obtained, such as: x DUTs, y Linux PCs, and z Windows PCs. Then, the remaining test resources DUT m, linux PC n, and windows PC k in the total test resource pool are removed to obtain the number of test resources still missing, DUT xm, linux PC yn, and windows PC zk. If all three values ​​are 0, it means that the remaining test resources have met the test requirements and no additional processing is required. The high-priority task can run normally. Otherwise, resource borrowing is required.

[0106] Figure 4 is a schematic diagram of an optional borrowing test resource according to an embodiment of the present invention, such as Figure 4 As shown, it includes: checking whether one's own resources need to be lent; if so, starting the borrowing process; if not, judging whether there are still scripts to be run, if so, continuing to run the next script, if not, returning the currently occupied test resources to the parent task resource pool; for the borrowing process, it includes: splitting the subsequent unrun scripts to form new subtasks; returning the currently occupied test resources to the total resource pool; then marking the test resources as lent in the corresponding resource table; and ending the run.

[0107] By obtaining the test networking (topology) of the test subtasks under each currently running parent task (corresponding to the target test task in this embodiment), the firewall resources can be sorted from most to least. These running subtasks are traversed, and the test resources occupied by them are accumulated and counted (corresponding to the above-mentioned traversal subtask sorting result, starting from the first test subtask, the test resources occupied by each test subtask are accumulated). When the required number of resources is reached, the traversal is stopped (corresponding to the above-mentioned stop of the traversal operation when the accumulated number of resources reaches the shortage number).

[0108] This embodiment does not limit the specific resource sorting method. The specific sorting parameters and reference attributes can be set by yourself. It is preferred to sort by the number of resources from most to least, so as to ensure that the number of running test tasks affected is as small as possible. For example, if 6 firewall devices are still missing, through the above sorting, only subtask 1 and subtask 2 need to lend test resources.

[0109] After finding the test subtask that needs to borrow test resources, it is necessary to record the borrowing situation in the database. The borrowing information includes: the task identifier of the currently running test task being borrowed, the identifier of the test subtask, the identifier of the target test task, the borrowing identifier, and the borrowing device information. For example, the fields in the database table are described as follows: parent task id (corresponding to the task identifier of the currently running test task being borrowed): the parent task id corresponding to the subtask of the resource to be lent; subtask id (corresponding to the identifier of the test subtask): the subtask id of the resource to be lent; target task id (corresponding to the identifier of the target test task): to which test task id the resource will be lent (i.e. the corresponding high-priority test task); lending mark: whether the lending has been completed; lending device information: record the unique identifier of the lent device to facilitate subsequent return operations.

[0110] The following table 1 schematically illustrates a subtask lending test resource marking table:

[0111] Table 1: Subtask loan test resource tag table

[0112]

[0113] Through the above method, the resource information that needs to be borrowed is confirmed, ensuring that high-priority test tasks can be completed as soon as possible by preempting the borrowed test resources.

[0114] In an embodiment of the present invention, after the remaining resources and borrowed test resources in the total test resource pool are used as available test resources, it also includes: controlling each test subtask in the currently running test task to perform a self-check operation in the target database after running a test script, wherein the self-check operation is used to check whether the test subtask needs to lend test resources; when the self-check operation indicates that the test subtask needs to lend test resources, the remaining unexecuted test script is split into an independent subtask, and the occupied test resource equipment is released back to the total test resource pool.

[0115] It should be noted that when each test subtask is running, it is necessary to check each time a test script is run. This embodiment illustrates that it is necessary to check in the database to inquire whether it needs to lend test resources. That is, in Table 1, whether there is a record with a subtask id of itself and a loan mark of 0; if so, split the remaining unexecuted test script into an independent subtask (corresponding to the above splitting the remaining unexecuted test script into an independent subtask), release the occupied test equipment back to the total test resource pool (corresponding to the above releasing the occupied test resource equipment back to the total test resource pool), and after lending the test resources, the loaned test resource mark table can be updated, the loan mark is 1, and the current test subtask is finished.

[0116] Figure 5 is a schematic diagram of an optional subtask splitting when resource borrowing occurs according to an embodiment of the present invention, such as Figure 5 As shown, for subtasks 1-4, when subtask 2 ends, subtask 4 starts. At the same time, a borrowing occurs in the middle of subtask 3, and the script after task 3 is intercepted to form subtask 3.1, waiting for subsequent scheduling.

[0117] After the above process, the test resources required by the high-priority task will be quickly released back to the total test resource pool, thereby ensuring that it can run quickly. After the high-priority task is completed, it is necessary to check the loaned test resource mark table to check whether the parent task of the subtask with the loan mark 1 has finished running; if not, return the corresponding test equipment to the target test task.

[0118] In this embodiment, the number of resources required for each test task can be evaluated according to the expected duration (the number of resources for each task is the maximum set of resources required for each subtask under it), so it is possible that even after some test resources are borrowed, the remaining scripts can still run smoothly. That is, when the borrowed resources are only a subset of the current task resources, by splitting the subtasks, the test subtasks of the current borrowed resources are still not affected and can continue to run.

[0119] In an embodiment of the present invention, after splitting the remaining unexecuted test script into an independent subtask, it also includes: when the independent subtask has no available test resources, performing a waiting operation; when it is detected that the borrowed test resources have been returned, controlling the independent subtask to schedule the test resources and execute the independent subtask.

[0120] It should be noted that, in the process of scheduling resources to each subtask, when there are no test resources available but there are still unrunning subtasks, the parent task corresponding to the borrowed subtask (i.e., the test task relative to each subtask, which is illustrated in this embodiment with the target test task) does not exit but continues to wait until the high-priority task is completed and the resources are returned, and all subtasks can be scheduled to run and then run.

[0121] Through the above implementation, the scheme of task priority processing by splitting subtasks during operation does not need to terminate the currently running task. When the borrowed resources are only a subset of the current task resources, even the current task of borrowing resources may not be affected at all.

[0122] After each parent task is completed, it is necessary to delete the loan records of all subtasks under its name in the subtask loan test resource tag table.

[0123] Through the above implementation, it is achieved that high-priority tasks seize test resources at the fastest speed, and at the same time, the existing running test tasks are not suspended, but the running time is longer than the expected running time.

[0124] The present invention is described below in conjunction with another optional embodiment.

[0125] Embodiment 2

[0126] This embodiment provides a device for processing a firewall test task. The implementation units included in the device for processing a firewall test task correspond to the implementation steps in the first embodiment.

[0127] Figure 6 is a schematic diagram of an optional device for processing a firewall test task according to an embodiment of the present invention, such as Figure 6 As shown, it includes: an acquisition unit 61, a determination unit 63, a calculation unit 65, and a scheduling unit 67, wherein:

[0128] The acquisition unit 61 is used to acquire the total number of test scripts included in the target test task.

[0129] The test tasks involved in this embodiment may refer to firewall automation test tasks. In order to cope with various current network attacks, firewall devices are used to build a protection barrier inside the network and at the gateway exit to protect user data and information security and provide a better user experience. It has become an indispensable infrastructure for all enterprises. In this case, automated test tasks are needed to ensure that the firewall device can quickly return to the old functions while the functions are rapidly iterating, and the old functions will not decline.

[0130] It should be noted that the test tasks in this embodiment can be issued through user terminals / user webs / enterprise terminals, etc. The number of test tasks can be multiple, and the test tasks can be issued at different time points. After the system receives the test tasks, all test tasks are stored in the form of task queues, and then the test resources in the test resource pool are called to execute each test task separately.

[0131] It should be noted that the test task in this embodiment may include multiple test scripts, and this embodiment does not limit the number of scripts included in each test task. The test scripts defined by a test task may include different test networks (topologies), and the number and running time of test scripts under each test network are different.

[0132] In this embodiment, in the test script, the target test resources can be operated by telent, ssh, etc. to achieve traffic construction, firewall operation, firewall information viewing, etc., so as to achieve the test objectives. The type and quantity of device resources required for each test script to run are different, and the running time of each test script may vary greatly. Some scripts can be completed within one minute, while others take half an hour or even more.

[0133] The determination unit 63 is used to determine the expected running time of the target test task based on the total number of scripts.

[0134] Estimate an expected completion time based on the total number of scripts included in each pre-submitted test task.

[0135] In this embodiment, the total number of scripts and the expected duration are used as the configurations that need to be read when calculating the required number of test resources each time a test task is scheduled. The total number of scripts and the expected duration are loaded into the database and then adjusted in real time as needed. When the total number of available test resources is large, the expected running time can be reduced, otherwise it can be increased.

[0136] A calculation unit 65, configured to calculate the required quantity of each type of test resources according to the expected running time of the target test task;

[0137] The scheduling unit 67 is used to schedule available test resources to execute target test tasks based on the required quantity of each type of test resources and the remaining resources in the total test resource pool.

[0138] The processing device for the above-mentioned firewall test task can first obtain the total number of scripts of the test scripts included in the target test task through the acquisition unit 61, and then determine the expected running time of the target test task based on the total number of scripts through the determination unit 63, calculate the required number of each type of test resources according to the expected running time of the target test task through the calculation unit 65, and schedule the available test resources based on the required number of each type of test resources and the remaining resources in the total test resource pool through the scheduling unit 67 to execute the target test task. In this embodiment, the required resources are evaluated based on the expected running time, which can ensure that a single task is completed within the expected time and that multiple test tasks can be run in parallel, thereby solving the technical problem in the related art that the test resources of each test task cannot be reasonably allocated when the number of test resources is limited and there are many test tasks waiting to be run.

[0139] Optionally, the calculation unit includes: a first calculation module, used to calculate the execution time of each test script according to the expected running time and the total number of scripts; a first splitting module, used to split the target test task into multiple test sub-tasks based on a preset task splitting strategy and multiple topology networking types, wherein each test sub-task contains at least one test script; a first sorting module, used to sort all test scripts according to each topology networking type to obtain multiple script sorting results; a first splicing module, used to splice the test scripts into each test sub-task in turn according to the script sorting results; a first determination module, used to determine the maximum number of test resources required by each test sub-task for various types of test resources based on the number of test resources required by each test script; a first accumulation module, used to accumulate the maximum number of test resources required by each test sub-task for various types of test resources, and determine the number of test resources required by the target test task for each type.

[0140] When calculating the required number of test resources, the task can be pre-decomposed by the expected running time. For each test script in the test task, there is a running time information (corresponding to the above calculation of the execution time of each test script), which records the time required for the test script to complete the operation. A single test task is split. During the splitting process, it is necessary to determine the preset task splitting strategy and the topological networking type of the test task. After the task splitting is completed, the split test scripts are sorted based on each topological networking type.

[0141] Then, according to the expected running time of the evaluation, the above test scripts are spliced ​​into the subtasks in order (corresponding to the above script sorting results, the test scripts are spliced ​​into each test subtask in order), ensuring that the running time of each subtask is approximately equal to the expected running time.

[0142] It should be noted that, in this embodiment, after the test scripts are spliced ​​into each test subtask, based on the above script test networking sequencing, the scripts in each test subtask are composed as follows:

[0143] sub_task1 (test subtask 1): script 1_1, script 1_2, script 1_3, script 2_1, script 2_2;

[0144] sub_task2 (test subtask 2): script 2_3...script 2_n2; ......

[0146] sub_taskn (test subtask n): script 3_7, script 3_8, script 3_9...script mn.

[0147] According to the test resources required by the test scripts in each test subtask, obtain the maximum number of resources required (corresponding to the above determination of the maximum number of test resources required by each test subtask for various types). For example, sub_task1 contains two networking topologies, one networking type requires 4 firewalls and 2 Linux PCs; the other networking type requires 3 firewalls and 1 Linux PC. The maximum number of resources required for sub_task1 is the largest one, which is 4 firewalls and 2 Linux PCs. The resource requirements of other test subtasks are calculated in the same way. Add up the maximum number of resources required for each test subtask to get the total number of resources required for the total task.

[0148] Optionally, the scheduling unit includes: a first sending module, used to send resource shortage information to the user terminal when the number of remaining resources in the total test resource pool is less than the required number of test resources, wherein the resource shortage information includes at least: the expected running time of the target test task, the type of lacking test resources and the number of resource shortages; a first receiving module, used to receive the allowable extension instruction feedback from the user terminal, and based on the allowable extension instruction, amplify the expected running time by a specified multiple to obtain the deferred execution time; a second calculation module, used to recalculate the required number of each type of test resources based on the deferred execution time, and schedule the available test resources based on the required number of each type of test resources and the remaining resources in the total test resource pool.

[0149] Optionally, the scheduling unit also includes: a second sending module, which is used to send a resource pointing instruction when all known test resources in the total test resource pool are not occupied by other test tasks and the number of all known test resources is less than the required number of test resources, wherein the resource pointing instruction is used to call all known test resources in the total test resource pool for the target test task.

[0150] In the process of providing the tolerance setting scheme, when the remaining test resources in the total test resource pool cannot meet the demand, feedback can be given to the user terminal, and the user terminal confirms whether to accept the expected operation time to be enlarged to n times of the original expected time (in this embodiment, the enlargement multiple can be configured by itself, without limitation, for example, 2 times, 4 times). If the user terminal sends an instruction to allow extension, the expected operation time is adjusted and the resource number is re-evaluated.

[0151] In the process of providing a tolerance setting plan, if all devices in the total test resource pool are not occupied by other tasks, but the test resources still cannot meet the needs of the current task (corresponding to the above-mentioned that all known test resources in the total test resource pool are not occupied by other test tasks, and the number of all known test resources is less than the required number of test resources), then all test resources are directly applied for this test (corresponding to the above-mentioned call of all known test resources in the total test resource pool for the target test task).

[0152] Under normal circumstances, test tasks are scheduled and processed in sequence in the order of first-in, first-out. However, for some urgent test projects, it is necessary to complete the scheduled test as much as possible. The task priority of this test task is higher. At this time, the default priority of the task added to the test task queue is 1. For urgent projects, the test task priority corresponding to the project can be marked as 0 (this embodiment does not limit the priority setting method, and it can be identified by numbers, letters, symbols, etc., which can be defined by yourself). The scheduling module prioritizes tasks with a priority of 0 to evaluate and allocate the required resources.

[0153] Optionally, the scheduling unit also includes: a third calculation module, used to calculate the shortage quantity of each type of test resources based on the demand quantity of each type of test resources and the remaining resources in the total test resource pool when the task priority of the target test task is higher than that of other test tasks and it is confirmed that the target test task has the resource preemption authority; a first borrowing module, used to borrow test resources equal to the shortage quantity from the currently running test task, and record the borrowing information in the target database; a first scheduling module, used to use the remaining resources in the total test resource pool and the borrowed test resources as available test resources; and schedule the available test resources.

[0154] Optionally, the first borrowing module includes: a first sorting submodule, used to obtain the topological networking of each test subtask in the currently running test task, and sort the test subtasks based on the number of firewall resources in the topological networking to obtain the subtask sorting results; a first accumulation submodule, used to traverse the subtask sorting results, starting from the first test subtask, and accumulate the test resources occupied by each test subtask; the first borrowing submodule, used to stop the traversal operation when the accumulated number of resources reaches the shortage number, and borrow the test resources of the test subtasks involved in the traversal operation in turn.

[0155] In this embodiment, a test task is called a parent task. Since the test networks that the test scripts rely on are different, they are classified and assigned to different test subtasks according to the different topological networks used by the scripts in the script set to be tested. A test subtask contains a series of test scripts with the same topological network. Each test subtask, as an independent running unit, will be assigned the test equipment required for its operation in the subsequent deployment and operation process, and automatically form a network.

[0156] When a high-priority task is scheduled, if the number of remaining test resources is insufficient, resource borrowing and preemption processing is required. In this embodiment, the test subtask is the smallest unit that occupies test resources during task operation. When a high-priority task needs to temporarily preempt and borrow resources, it should be borrowed from the running test subtask.

[0157] By evaluating the test resources required by the current high-priority test task, the number of test resources that are still missing is determined, and based on the missing number of test resources, they are borrowed from the running test subtasks.

[0158] Optionally, the borrowing information includes: a task identifier of the borrowed test task currently running, an identifier of a test subtask, an identifier of a target test task, a borrowing identifier, and borrowing device information.

[0159] Optionally, the processing device for the firewall test task also includes: a first self-check module, which is used to control each test subtask in the currently running test task to perform a self-check operation in the target database after the remaining resources and borrowed test resources in the total test resource pool are used as available test resources, wherein the self-check operation is used to check whether the test subtask needs to lend test resources; and a second splitting module, which is used to split the remaining unexecuted test script into an independent subtask and release the occupied test resource equipment back to the total test resource pool when the self-check operation indicates that the test subtask needs to lend test resources.

[0160] By obtaining the test networking (topology) of the test subtasks under each currently running parent task (corresponding to the target test task in this embodiment), the firewall resources can be sorted from most to least. These running subtasks are traversed, and the test resources occupied by them are accumulated and counted (corresponding to the above-mentioned traversal subtask sorting result, starting from the first test subtask, the test resources occupied by each test subtask are accumulated). When the required number of resources is reached, the traversal is stopped (corresponding to the above-mentioned stop of the traversal operation when the accumulated number of resources reaches the shortage number).

[0161] Optionally, the processing device for the firewall test task also includes: a first waiting module, used to perform a waiting operation when the independent subtask has no available test resources; a first execution module, used to control the independent subtask to schedule test resources and execute the independent subtask when it is detected that the borrowed test resources have been returned.

[0162] The processing device for the above-mentioned firewall test task may also include a processor and a memory. The above-mentioned acquisition unit 61, determination unit 63, calculation unit 65, scheduling unit 67, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to realize the corresponding functions.

[0163] The processor includes a kernel, which retrieves the corresponding program unit from the memory. One or more kernels can be set to schedule available test resources and execute target test tasks based on the required number of each type of test resources and the remaining resources in the total test resource pool by adjusting kernel parameters.

[0164] The above-mentioned memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one storage chip.

[0165] According to another aspect of an embodiment of the present invention, an electronic device is also provided, including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute any one of the above-mentioned firewall test task processing methods by executing the executable instructions.

[0166] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to perform a processing method for any of the above-mentioned firewall test tasks.

[0167] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing a program that initializes the following method steps: obtaining the total number of test scripts included in the target test task; determining the expected running time of the target test task based on the total number of scripts; calculating the required number of each type of test resources based on the expected running time of the target test task; and scheduling available test resources to execute the target test task based on the required number of each type of test resources and the remaining resources in the total test resource pool.

[0168] Figure 7 1 is a hardware structure block diagram of an electronic device (or mobile device) according to a method for processing a firewall test task according to an embodiment of the present invention. Figure 7 As shown, the electronic device may include one or more (shown as 702a, 702b, ..., 702n in the figure) processors 702 (the processor 702 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 704 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a keyboard, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 7 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 7 More or fewer components as shown, or with Figure 7 The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages and disadvantages of the embodiments.

[0169] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0170] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0171] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0172] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0173] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0174] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0175] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for processing a firewall test task, characterized in that: include: Get the total number of test scripts included in the target test task; Determining the expected running time of the target test task based on the total number of scripts; Calculate the required quantity of each type of test resources according to the expected running time of the target test task; Based on the required quantity of each type of the test resources and the remaining resources in the total test resource pool, scheduling available test resources to execute the target test task; The step of scheduling available test resources based on the demand quantity of each type of test resources and the remaining resources in the total test resource pool includes: when the task priority of the target test task is higher than that of other test tasks and it is confirmed that the target test task has resource preemption authority, the shortage quantity of each type of test resources is calculated based on the demand quantity of each type of test resources and the remaining resources in the total test resource pool; borrowing test resources equal to the shortage quantity from the currently running test tasks, and recording the borrowing information in the target database; using the remaining resources in the total test resource pool and the borrowed test resources as the available test resources; scheduling the available test resources; After taking the remaining resources and borrowed test resources in the total test resource pool as the available test resources, each test subtask in the currently running test task is controlled to perform a self-check operation in the target database after running each test script, wherein the self-check operation is used to check whether the test subtask needs to lend the test resources; if the self-check operation indicates that the test subtask needs to lend the test resources, the remaining unexecuted test script is split into an independent subtask, and the occupied test resource equipment is released back to the total test resource pool.

2. The processing method according to claim 1, characterized in that: The step of calculating the required quantity of each type of test resource according to the expected running time of the target test task comprises: Calculate the execution time of each of the test scripts according to the expected running time and the total number of the scripts; Based on a preset task splitting strategy and multiple topology networking types, split the target test task into multiple test subtasks, wherein each of the test subtasks includes at least one test script; Sorting all the test scripts according to each topology networking type to obtain multiple script sorting results; According to the script sorting result, the test scripts are sequentially spliced ​​into each of the test subtasks; Based on the number of test resources required by each of the test scripts, determine the maximum number of test resources required by each of the test subtasks for various types of test resources; The maximum required quantity of each of the test subtasks for various types of test resources is accumulated to determine the required quantity of each type of test resource for the target test task.

3. The processing method according to claim 1, characterized in that: The step of scheduling available test resources based on the required quantity of each type of the test resources and the remaining resources in the total test resource pool comprises: In the case where the number of remaining resources in the total test resource pool is less than the required number of test resources, sending resource shortage information to the user terminal, wherein the resource shortage information at least includes: the expected running time of the target test task, the type of the shortage test resources and the number of shortage resources; receiving a delay-allowing instruction fed back by the user terminal, and based on the delay-allowing instruction, amplifying the expected running time by a specified multiple to obtain a delayed execution time; Based on the deferred execution duration, the required quantity of each type of test resources is recalculated, and based on the required quantity of each type of test resources and the remaining resources in the total test resource pool, the available test resources are scheduled.

4. The processing method according to claim 1, characterized in that: The step of scheduling available test resources based on the required quantity of each type of the test resources and the remaining resources in the total test resource pool comprises: If all known test resources in the total test resource pool are not occupied by other test tasks, and the number of all known test resources is less than the required number of test resources, a resource pointing instruction is sent, wherein the resource pointing instruction is used to call all known test resources in the total test resource pool for the target test task.

5. The processing method according to claim 1, characterized in that: The step of borrowing the same number of test resources as the shortage from the currently running test task comprises: Obtaining the topological networking of each test subtask in the currently running test task, and sorting the test subtasks based on the number of firewall resources in the topological networking to obtain a subtask sorting result; Traversing the subtask sorting results, starting from the first test subtask, and accumulating the test resources occupied by each of the test subtasks; When the accumulated resource quantity reaches the shortage quantity, the traversal operation is stopped, and the test resources of the test subtasks involved in the traversal operation are borrowed in sequence.

6. The processing method according to claim 1, characterized in that: After splitting the remaining unexecuted test scripts into an independent subtask, it also includes: When there are no available test resources for the independent subtask, a waiting operation is performed; When it is detected that the borrowed test resources have been returned, the independent subtask is controlled to schedule the test resources and execute the independent subtask.

7. A device for processing a firewall test task, characterized in that: include: An acquisition unit, used for acquiring the total number of test scripts included in a target test task; A determination unit, configured to determine an expected running time of the target test task based on the total number of scripts; A calculation unit, configured to calculate the required quantity of each type of test resources according to the expected running time of the target test task; A scheduling unit, configured to schedule available test resources to execute the target test task based on the required quantity of each type of the test resources and the remaining resources in the total test resource pool; The scheduling unit includes: a third calculation module, used to calculate the shortage quantity of each type of the test resources based on the demand quantity of each type of the test resources and the remaining resources in the total test resource pool, when the task priority of the target test task is higher than that of other test tasks and it is confirmed that the target test task has the resource preemption authority; a first borrowing module, used to borrow the same test resources as the shortage quantity from the currently running test task, and record the borrowing information in the target database; a first scheduling module, used to use the remaining resources in the total test resource pool and the borrowed test resources as the available test resources; and schedule the available test resources; The processing device for firewall test tasks also includes: a first self-check module, which is used to control each test subtask in the currently running test task to perform a self-check operation in the target database after the remaining resources and borrowed test resources in the total test resource pool are used as the available test resources, wherein the self-check operation is used to check whether the test subtask needs to lend the test resources; and a second splitting module, which is used to split the remaining unexecuted test script into an independent subtask when the self-check operation indicates that the test subtask needs to lend the test resources, and release the occupied test resource equipment back to the total test resource pool.

8. The processing device according to claim 7, characterized in that The computing unit comprises: A first calculation module, used to calculate the execution time of each of the test scripts according to the expected running time and the total number of the scripts; A first splitting module is used to split the target test task into multiple test subtasks based on a preset task splitting strategy and multiple topology networking types, wherein each of the test subtasks includes at least one test script; A first sorting module is used to sort all the test scripts according to each topology networking type to obtain multiple script sorting results; A first splicing module, used for splicing the test scripts into each of the test subtasks in sequence according to the script sorting results; A first determination module is used to determine the maximum number of test resources required by each test subtask for various types of test resources based on the number of test resources required by each test script; The first accumulation module is used to accumulate the maximum required quantity of each of the test subtasks for various types of test resources, and determine the required quantity of each type of test resource for the target test task.

9. The processing device according to claim 7, characterized in that The scheduling unit comprises: A first sending module is used to send resource shortage information to a user terminal when the number of remaining resources in the total test resource pool is less than the required number of test resources, wherein the resource shortage information at least includes: the expected running time of the target test task, the type of the shortage test resources and the number of shortage resources; A first receiving module is configured to receive an instruction to allow extension fed back by the user terminal, and based on the instruction to allow extension, amplify the expected running time by a specified multiple to obtain the extended execution time; The second calculation module is used to recalculate the required quantity of each type of test resources based on the deferred execution duration, and schedule the available test resources based on the required quantity of each type of test resources and the remaining resources in the total test resource pool.

10. The processing device according to claim 7, characterized in that The scheduling unit also includes: The second sending module is used to send a resource pointing instruction when all known test resources in the total test resource pool are not occupied by other test tasks and the number of all known test resources is less than the required number of test resources, wherein the resource pointing instruction is used to call all known test resources in the total test resource pool for the target test task.

11. The processing device according to claim 7, characterized in that The first borrowing module comprises: The first sorting submodule is used to obtain the topological networking of each test subtask in the currently running test task, and sort the test subtasks based on the number of firewall resources in the topological networking to obtain a subtask sorting result; A first accumulation submodule, used for traversing the subtask sorting results, starting from the first test subtask, and accumulating the test resources occupied by each of the test subtasks; The first borrowing submodule is used to stop the traversal operation when the accumulated resource quantity reaches the shortage quantity, and to borrow the test resources of the test subtasks involved in the traversal operation in sequence.

12. The processing device according to claim 7, characterized in that The processing device for the firewall test task also includes: A first waiting module, used for performing a waiting operation when there are no available test resources for the independent subtask; The first execution module is used to control the independent subtask to schedule the test resource and execute the independent subtask when it is detected that the borrowed test resource has been returned.

13. An electronic device, characterized in that: include: processor; as well as A memory, configured to store executable instructions of the processor; Wherein, the processor is configured to execute the method for processing the firewall test task as described in any one of claims 1 to 6 by executing the executable instructions.

Images