A distributed test resource scheduling method

Abstract

The application discloses a distributed test resource scheduling method, comprising the following steps: receiving test task request information sent by at least one task node; S2: obtaining resource types required by test tasks according to the received test task request information, and acquiring working state queue information of at least one resource node meeting the resource type condition; S3: performing resource scheduling according to the test task request information and the working state queue information, generating a scheduling result in such a manner that each test task to be processed in the task node is sequentially completed and the total time is the shortest, and allocating resource nodes according to the scheduling result; sending the scheduling result to the task node, and sending at least one working request to the resource nodes allocated according to the scheduling result. Through priority scheduling, the application can still stably run various tasks when the task queue is long, and effectively guarantees the execution efficiency of the test system when long tasks and short tasks are alternately executed.

Description

Technical Field

[0001] This invention belongs to the field of computer testing, and in particular relates to a distributed test resource scheduling method. Background Technology

[0002] A distributed testing platform breaks down a multi-step or multi-module test task or test case into many smaller parts, which are then distributed to multiple computers for parallel processing. During resource scheduling, the scheduling computer typically allocates resources based on the tasks required to be executed.

[0003] For distributed testing, existing resource scheduling methods typically allocate resource nodes to each request by estimating their processing capabilities. However, test tasks inherently require sequential resource usage. Allocating resources solely based on node processing capacity can prevent tasks from completing in the shortest possible time, resulting in inefficient scheduling of the entire distributed testing system. Furthermore, the varying processing times of different resources, coupled with sequential resource usage, can easily cause bottlenecks in resource node processing. Therefore, existing technologies often suffer from inefficient resource allocation, leading to decreased resource utilization. Summary of the Invention

[0004] The technical objective of this invention is to provide a distributed test resource scheduling method to solve the problem of low test resource utilization.

[0005] To solve the above problems, the technical solution of the present invention is as follows:

[0006] A distributed test resource scheduling method includes the following steps:

[0007] S1: Receive test task request information sent by at least one task node, wherein the test task request information indicates that there is at least one test task to be processed in the corresponding task node, and the test task request information includes at least the type of resource to be used by the test task and the resource usage time information.

[0008] S2: Obtain the resource type required by the test task based on the received test task request information, and obtain the working status queue information of at least one resource node that meets the resource type conditions.

[0009] S3: Perform resource scheduling based on test task request information and work status queue information. Generate scheduling results by completing each test task to be processed in the task node in sequence with the shortest total time, and allocate resource nodes according to the scheduling results; that is, send the scheduling results to the task nodes and send at least one work request to the resource nodes allocated according to the scheduling results.

[0010] More preferably, before step S1 is executed, the following steps are also included:

[0011] S01: Establish communication between the task node and the scheduling node through a request communication method, and send communication establishment information from the scheduling node to the task node;

[0012] S02: After receiving the communication establishment information, send a test task request information to the scheduling node;

[0013] S03: After receiving the test task request information, the scheduling node sends a test task reception confirmation message to the task node with which communication has been established.

[0014] More preferably, while performing step S03, the following steps are also included:

[0015] Whenever the scheduling node receives a test task request, it generates a timestamp for the corresponding information.

[0016] Based on the order of the timestamps corresponding to the received test task request information, a test task request queue is established in the scheduling node.

[0017] Upon receiving each test task request message, update the test task in the message to the test task request queue.

[0018] Step S2 specifically includes the following steps:

[0019] Status request information is sent to all resource nodes at fixed time intervals. The status request information includes a timestamp.

[0020] After a resource node receives a status request, it feeds back the resource node status information of each resource node to the scheduling node. The resource node status information includes the timestamp corresponding to the status request information, the current work information of the corresponding resource node, and the remaining time of its work.

[0021] After receiving the resource node status information, the scheduling node forms the resource node's working status queue information based on the timestamp in the resource node status information.

[0022] Specifically, step S3 includes the following steps:

[0023] Establish a resource node scheduling table, including the work status queue information of the resource nodes in the two most recent times;

[0024] When sending a status request message, compare the work status queue information of the resource node under the two most recent time nodes to confirm whether the work was completed when the resource node went offline;

[0025] The test tasks to be processed are allocated to each resource node according to the scheduling results.

[0026] Specifically, the test task request information carries the task request set {M} of the task node.1}, task request set {M 1 The data structure model of} is:

[0027] Where: num1 is the sequence number of the task request. For a set of resource requirements;

[0028] Resource demand set The data structure model is as follows:

[0029] Where: num2 represents the current resource demand in the resource demand set. In the sequence, RS represents the resource requirement type, and PR represents the preceding resource requirement in the resource requirement set. The sequence number in the list; if the current resource has no preceding resource requirement, this value is 0.

[0030] Specifically, the test task request queue {M 2 The data structure model of} is:

[0031] Where: TID is the ID number of the current test task, and time is the timestamp when the scheduling node receives the test task request information. For a set of resource requirements;

[0032] Resource demand set The data structure model is as follows:

[0033] Where: num3 represents the current resource demand in the resource demand set. In the sequence, RS represents the resource requirement type, and PR represents the preceding resource requirement in the resource requirement set. The sequence number in the resource is 0 if there is no preceding resource requirement for the current resource. Node is the sequence number of the working resource node. Status is the resource requirement status, including three statuses: pending, satisfied, and completed. pr is the priority of the resource requirement.

[0034] Specifically, the data structure model of the resource node scheduling table {T} is T{RS',Node,Status{L},Status{C}};

[0035] Where RS' is the resource node type, Node is the working resource node sequence number, Status{L} and Status{C} are the resource node status information of the previous and current cycles, respectively, and its data structure is Status{WorkNum,StartTime}.

[0036] Where WorkNum is the work sequence number and StartTime is the work start time, which is the timestamp corresponding to the receipt of the test task request information.

[0037] Specifically, after receiving the resource node status information, the status of the corresponding node in the resource node scheduling table is updated according to the sequence number of the resource node.

[0038] Specifically, compare the resource node status information of the previous session with that of the current session. If there is work in the previous session but no work in the current session, then the resource requirement corresponding to the work is considered to be completed, and the status of the resource requirement set in the test task request queue is updated to complete.

[0039] If there was work in the previous test and no resource node status information was received in the current test, it is considered that the resource requirement corresponding to the work cannot be completed, and the status of the resource requirement set in the test task request queue is updated to pending satisfaction.

[0040] If there is work in both the previous and current sessions, compare the work sequence numbers of the two sessions. If they match, it is considered that the assigned work is being completed. If they do not match, it is considered that the resource requirement corresponding to the work in the previous session has been completed, and the status of the resource requirement set in the test task request queue is updated to "completed". The resource requirement corresponding to the work in the current session has been satisfied, and the status of the resource requirement set in the test task request queue is updated to "satisfied".

[0041] If there was no work in the previous test but there is work in the current test, then the resource requirements corresponding to the work in the current test are considered to have been met, and the status of the resource requirement set in the test task request queue is updated to be met.

[0042] Iterate through the resource requirements set in the test task request queue that are in the pending state and assign priority based on the number of their preceding resource requirements.

[0043] Sort all resource requests in a pending state with a priority of non-zero in descending order of priority. If the priorities are the same, sort them according to their sequence number. Assign resource nodes to resource requests according to the sorting order, and assign resource nodes that are currently not in use. If a resource request is not assigned a resource node, increment its priority by 1.

[0044] Because the present invention adopts the above technical solution, it has the following advantages and positive effects compared with the prior art:

[0045] Compared with existing technologies, this invention provides a distributed test resource scheduling method. By prioritizing the scheduling, the method ensures that even when the task queue is long, the various tasks can still run stably, effectively guaranteeing the execution efficiency of the test system when long strings of tasks and short tasks are executed alternately. Attached Figure Description

[0046] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention.

[0047] Figure 1 This is a flowchart illustrating a distributed test resource scheduling method according to the present invention.

[0048] Figure 2 This is a schematic diagram of the distributed testing system of the present invention. Detailed Implementation

[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the specific implementation methods of the present invention will be described below with reference to the accompanying drawings. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without any creative effort.

[0050] To keep the drawings concise, only the parts relevant to the invention are shown schematically in each figure, and they do not represent the actual structure of the product. Furthermore, for ease of understanding, in some figures, only one of components with the same structure or function is shown schematically, or only one is labeled. In this document, "one" can mean not only "only one" but also "more than one".

[0051] The following detailed description, in conjunction with the accompanying drawings and specific embodiments, provides a further detailed explanation of the distributed test resource scheduling method proposed in this invention. The advantages and features of this invention will become clearer from the following description and claims.

[0052] Example

[0053] See Figure 1 and Figure 2 This embodiment provides a distributed test resource scheduling method, including the following steps:

[0054] First, before step S1 is executed, the task node establishes communication with the scheduling node via a request communication method. After the communication is established, the scheduling node sends a communication establishment message to the task node. Next, after receiving the communication establishment message, the task node sends a test task request message to the scheduling node. After the scheduling node receives the test task request message, it sends a test task reception confirmation message to the task node that established the communication.

[0055] In step S1, when the scheduling node receives a test task request message, it generates a timestamp for the corresponding message. The test task request message indicates that there is at least one pending test task in the corresponding task node, and it includes at least the type of resource the test task needs to use and the resource usage time information. Based on the order of the received test task request messages and their corresponding timestamps, a test task request queue is established in the scheduling node. That is, each time a test task request message is received, the test task in the message is updated in the test task request queue.

[0056] The test task request information carries the task request set {M} of the task node. 1}, task request set {M 1 The data structure model of} is:

[0057] Where: num1 is the sequence number of the task request. This is a set of resource requirements.

[0058] Resource demand set The data structure model is as follows:

[0059] Where: num2 represents the current resource demand in the resource demand set. In the sequence, RS represents the resource requirement type, and PR represents the preceding resource requirement in the resource requirement set. The sequence number in the list; if the current resource has no preceding resource requirement, this value is 0.

[0060] Among them, the test task request queue {M 2 The data structure model of} is:

[0061] Where: TID is the ID number of the current test task, and time is the timestamp when the scheduling node receives the test task request information. This is a set of resource requirements.

[0062] Resource demand set The data structure model is as follows:

[0063] Where: num3 represents the current resource demand in the resource demand set. In the sequence, RS represents the resource requirement type, and PR represents the preceding resource requirement in the resource requirement set. The sequence number in the resource is 0 if there is no preceding resource requirement for the current resource. Node is the sequence number of the working resource node. Status is the resource requirement status, including three statuses: pending, satisfied, and completed. pr is the priority of the resource requirement.

[0064] Then, proceeding to step S2, the resource type required for the test task is obtained based on the received test task request information, and the working status queue information of at least one resource node that meets the resource type conditions is acquired. Specifically, the scheduling node sends status request information to all resource nodes at fixed time intervals, and the status request information includes a timestamp. After receiving the status request information, the resource nodes report their resource node status information to the scheduling node. The resource node status information includes the timestamp corresponding to the status request information, as well as the current work information and remaining work time of the corresponding resource node. After receiving the resource node status information, the scheduling node forms the working status queue information of the resource nodes based on the timestamp in the resource node status information. Subsequently, the scheduling node sends the status request information again and updates the resource node scheduling table managed by the scheduling node based on the most recently received resource node status information.

[0065] Next, in step S3: resource scheduling is performed based on the previously obtained test task request information and work status queue information. The scheduling result is generated so that each test task to be processed in the task node is completed in sequence and the total time is the shortest. Resource nodes are allocated according to the scheduling result; that is, the scheduling result is sent to the task node and at least one work request is sent to the resource node allocated according to the scheduling result.

[0066] Specifically: A resource node scheduling table is established, including the work status queue information of the resource nodes for the two most recent times. When sending a status request message, the work status queue information of the resource nodes at the two most recent time points is compared to confirm whether the work was completed when the resource node went offline. The test tasks to be processed are allocated to each resource node according to the scheduling results. The work status is determined by updating the corresponding node status in the resource node scheduling table based on the resource node sequence number after receiving the resource node status message.

[0067] The specific method for updating the status of the corresponding node is as follows:

[0068] Compare the resource node status information of the previous test with that of the current test. If there is work in the previous test but no work in the current test, then the resource requirement corresponding to the work is considered to be completed, and the status of the resource requirement set in the test task request queue is updated to complete.

[0069] If there was work in the previous test and no resource node status information was received in the current test, it is assumed that the resource requirement corresponding to the work cannot be completed, and the status of the resource requirement set in the test task request queue is updated to pending satisfaction.

[0070] If there is work in both the previous and current sessions, compare the work sequence numbers of the two sessions. If they match, it is considered that the assigned work is being completed. If they do not match, it is considered that the resource requirement corresponding to the work in the previous session has been completed, and the status of the resource requirement set in the test task request queue is updated to "completed". The resource requirement corresponding to the work in the current session has been satisfied, and the status of the resource requirement set in the test task request queue is updated to "satisfied".

[0071] If there was no work in the previous test but there is work in the current test, then the resource requirements corresponding to the work in the current test are considered to have been met, and the status of the resource requirement set in the test task request queue is updated to be met.

[0072] Traverse the resource requirement set in the test task request queue that is in the pending state and assign priority according to the number of preceding resource requirements. For example, if the resource requirement sequence is {RQ1, RQ2, ..., RQN}, then RQ1 is considered to have a priority of N, and RQ2 to RQN have a priority of 0. If RQ1 is completed, then the priority of RQ2 is updated to N-1.

[0073] Sort all pending resource requests with a non-zero priority in descending order of priority. If priorities are the same, sort them by their sequence number. Assign resource nodes to resource requests according to the sorting order, assigning resource nodes that are currently not in use. If a resource request is not assigned a resource node, increment its priority by 1.

[0074] The data structure model of the resource node scheduling table {T} is T{RS',Node,Status{L},Status{C}}.

[0075] Where RS' is the resource node type, Node is the working resource node sequence number, Status{L} and Status{C} are the resource node status information of the previous and current cycles, respectively, and its data structure is Status{WorkNum,StartTime}.

[0076] Where WorkNum is the work sequence number and StartTime is the work start time, which is the timestamp corresponding to the receipt of the test task request information.

[0077] For better options, please refer to the following: Figure 2 This is a schematic diagram of the structure of the distributed testing system involved in this embodiment, wherein there can be N task nodes and resource nodes, and 1 scheduling node.

[0078] The scheduling node receives the test task request information from the task node as shown in the table below.

[0079]

[0080]

[0081] The scheduling node receives the status of the resource nodes and generates a resource node scheduling table, as shown in the table below.

[0082]

[0083] Based on the test task request information, priorities are assigned as shown in the table below.

[0084]

[0085] According to the scheduling table, the resource node tasks and update priorities are allocated as shown in the table below.

[0086]

[0087] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings, but the present invention is not limited to the above embodiments. Even if various changes are made to the present invention, if these changes fall within the scope of the claims of the present invention and their equivalents, they shall still fall within the protection scope of the present invention.

Claims

1. A distributed test resource scheduling method, characterized in that, Includes the following steps: S1: Receive test task request information sent by at least one task node, wherein the test task request information indicates that there is at least one test task to be processed in the corresponding task node, and the test task request information includes at least the type of resource to be used by the test task and the resource usage time information. S2: Obtain the resource type required for the test task based on the received test task request information, and obtain the working status queue information of at least one resource node that meets the resource type conditions. S3: Perform resource scheduling based on the test task request information and the work status queue information, generate a scheduling result so that each test task to be processed in the task node is completed in sequence and the total time is the shortest, and allocate resource nodes according to the scheduling result; that is, send the scheduling result to the task node and send at least one work request to the resource node allocated according to the scheduling result. Step S3 specifically includes the following steps: Establish a resource node scheduling table, including the work status queue information of the resource nodes in the two most recent times; When sending the status request information, compare the work status queue information of the resource node under the two most recent time nodes to confirm whether the work has been completed when the resource node goes offline; The test tasks to be processed are allocated to each resource node according to the scheduling results; Among them, the resource node scheduling table The data structure model is ； in, For resource node type, The resource node number for the task. and These are the resource node status information for the previous and current sessions, respectively, and their data structure is as follows: ; in, For work sequence number, The start time of the task is the timestamp corresponding to the receipt of the test task request information; Upon receiving the resource node status information, the status of the corresponding node in the resource node scheduling table is updated according to the sequence number of the resource node. Specifically, the resource node status information of the previous test and the current test is compared. If there is work in the previous test and no work in the current test, the resource requirement corresponding to the work is considered to be completed, and the status of the resource requirement set in the test task request queue is updated to complete. If there was work in the previous test and no resource node status information was received in the current test, it is considered that the resource requirement corresponding to the work cannot be completed, and the status of the resource requirement set in the test task request queue is updated to pending satisfaction. If there is work in both the previous and current sessions, compare the work sequence numbers of the two sessions. If they match, it is considered that the assigned work is being completed; if they do not match, it is considered that the resource requirement corresponding to the work in the previous session is completed, and the status of the resource requirement set in the test task request queue is updated to "completed". The resource requirement corresponding to the work in the current session is satisfied, and the status of the resource requirement set in the test task request queue is updated to "satisfied". If there was no work in the previous test and there is work in the current test, then the resource requirements corresponding to the work in the current test are considered to have been met, and the status of the resource requirement set in the test task request queue is updated to "met".

2. The distributed test resource scheduling method according to claim 1, characterized in that, Before step S1 is performed, the following steps are also included: S01: Establish communication between the task node and the scheduling node through a request communication method, and send communication establishment information from the scheduling node to the task node; S02: After receiving the communication establishment information, send the test task request information to the scheduling node; S03: After receiving the test task request information, the scheduling node sends a test task reception confirmation message to the task node that established communication.

3. The distributed test resource scheduling method according to claim 2, characterized in that, While performing step S03, the following steps are also included: Whenever the scheduling node receives the test task request information, it generates a timestamp for the corresponding information; Based on the order of the timestamps corresponding to the received test task request information, a test task request queue is established in the scheduling node.

4. The distributed test resource scheduling method according to claim 3, characterized in that, Upon receiving each test task request message, the test task in the message is updated in the test task request queue.

5. The distributed test resource scheduling method according to claim 1, characterized in that, Step S2 specifically includes the following steps: Status request information is sent to all resource nodes at fixed time intervals, and the status request information includes a timestamp. After a resource node receives the status request information, it feeds back the resource node status information of each resource node to the scheduling node. The resource node status information includes the timestamp corresponding to the status request information, the current work information of the corresponding resource node, and the remaining work time. After receiving the resource node status information, the scheduling node forms the working status queue information of the resource node based on the timestamp in the resource node status information.

6. The distributed test resource scheduling method according to any one of claims 1 to 5, characterized in that, The test task request information carries a set of task requests for the task nodes. The task request set The data structure model is as follows: ; in: This is the sequence number of the task request. For a set of resource requirements; The set of resource requirements The data structure model is as follows: ; in: The current resource requirements are in the set of resource requirements. The serial number in For resource demand type, For the preceding resource requirements in the resource requirement set The sequence number in the list; if the current resource has no preceding resource requirement, this value is 0.

7. The distributed test resource scheduling method according to claim 3 or 4, characterized in that, The test task request queue The data structure model is as follows: ; in: For the current test task Number, The timestamp is the time when the scheduling node receives the test task request information. For a set of resource requirements; The set of resource requirements The data structure model is as follows: ； in: The current resource requirements are in the set of resource requirements. The serial number in For resource demand type, For the preceding resource requirements in the resource requirement set The sequence number in the list; if the current resource has no preceding resource requirement, this value is 0. This refers to the sequence number of the resource node being worked on. Resource demand status is categorized into three states: pending, satisfied, and completed. Prioritize resource needs.

8. The distributed test resource scheduling method according to claim 7, characterized in that, It also includes: traversing the resource requirements in the resource requirement set in the test task request queue that are in a state of pending satisfaction, and assigning priority according to the number of their preceding resource requirements; Sort all resource requests in a pending state with a priority of non-zero in descending order of priority. If the priorities are the same, sort them according to their sequence number. Assign resource nodes to resource requests according to the sorting order, and assign resource nodes that are currently not in use. If a resource request is not assigned a resource node, increment its priority by 1.

Images