Test task scheduling methods, equipment, storage media and program products

Abstract

This application provides a test task scheduling method, device, storage medium, and program product. In this embodiment, a test task is decomposed into multiple subtasks, and a task allocation node assigns these subtasks to multiple scheduling nodes. This allows multiple scheduling nodes to perform parallel resource scheduling on the multiple subtasks, achieving one-stop scheduling of test tasks. This embodiment, by dividing a test task into multiple subtasks and having multiple scheduling nodes perform parallel resource scheduling on these subtasks, improves concurrent processing capabilities and helps increase the execution efficiency of concurrent test tasks compared to processing multiple test tasks in parallel.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to a test task scheduling method, device, storage medium, and program product. Background Technology

[0002] With the rapid development of information technology, the complexity and scale of software systems are also increasing. This change not only places higher demands on the software development process but also significantly increases the difficulty of software quality assurance. As a key part of the software development lifecycle, software testing has seen a substantial increase in workload. However, traditional test task scheduling methods, often implemented through polling and synchronous waiting, are no longer sufficient to meet the efficiency requirements of today's high-concurrency, large-scale test tasks. Summary of the Invention

[0003] This application provides a test task scheduling method, device, storage medium, and program product to improve the execution efficiency of concurrent test tasks.

[0004] This application provides a test task scheduling method applicable to any scheduling node in a distributed scheduling system. The method includes:

[0005] Obtain test tasks;

[0006] Based on the configuration information of the test task, the test task is broken down into multiple sub-tasks;

[0007] The multiple subtasks are sent to the task allocation node so that the task allocation node can allocate the multiple subtasks to multiple scheduling nodes for parallel resource scheduling.

[0008] Optionally, the method further includes:

[0009] For at least one target subtask obtained, the resource allocation strategy and resource specification information corresponding to the target test task are obtained from the configuration information of the target test task to which any target subtask belongs.

[0010] Based on the resource allocation strategy and resource specification information corresponding to the target test task, resources are allocated to the at least one target sub-task to obtain the resource allocation information of the at least one target sub-task.

[0011] Based on the resource allocation information and task priority in the configuration information of the target test task, the at least one target subtask is scheduled to the resources allocated to each of the at least one target subtask, so as to use the resources allocated to each of the at least one target subtask to execute the test cases corresponding to each of the at least one target subtask.

[0012] This application also provides an electronic device and a distributed scheduling system, including: multiple scheduling nodes and task allocation nodes;

[0013] The plurality of scheduling nodes are used to execute the steps in the above test task scheduling method;

[0014] The task allocation node is used to allocate the test task into multiple subtasks to the multiple scheduling nodes.

[0015] The multiple scheduling nodes are also used to perform parallel resource scheduling on the multiple subtasks.

[0016] This application also provides an electronic device, including: a memory and a processor; wherein the memory is used to store computer programs;

[0017] The processor is coupled to the memory and is used to execute the computer program to perform the steps in the above-described test task scheduling method.

[0018] This application also provides a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps in the above-described test task scheduling method.

[0019] This application also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the above-described test task scheduling method.

[0020] In this embodiment, the test task is decomposed into multiple subtasks, and the task allocation node assigns these subtasks to multiple scheduling nodes. This allows multiple scheduling nodes to perform parallel resource scheduling on the multiple subtasks, achieving one-stop scheduling of the test task. This embodiment, by splitting the test task into multiple subtasks and having multiple scheduling nodes perform parallel resource scheduling on these subtasks, improves concurrency processing capabilities compared to processing multiple test tasks in parallel, thus enhancing the execution efficiency of concurrent test tasks. Furthermore, since the configuration information of the test task contains the parameters and conditions set for its successful execution, task decomposition based on this configuration information ensures that each subtask is self-contained, reducing cross-task dependencies. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0022] Figure 1 This is a schematic diagram of the structure of the distributed scheduling system provided in the embodiments of this application;

[0023] Figure 2 This is a schematic diagram illustrating the test task creation method provided in the embodiments of this application;

[0024] Figure 3 This is a schematic diagram of the task scheduling process provided in an embodiment of this application;

[0025] Figure 4 This is a schematic diagram illustrating the test task breakdown principle provided in an embodiment of this application;

[0026] Figure 5 The chain representation provided in the embodiments of this application is intended to illustrate the concept.

[0027] Figure 6 A schematic diagram of the data structure for a subtask provided in an embodiment of this application;

[0028] Figure 7 This is a schematic diagram of a test task from the user's perspective, provided in an embodiment of this application.

[0029] Figure 8 This is a schematic diagram of a test task from the perspective of a scheduling node, provided in an embodiment of this application.

[0030] Figure 9 This is a schematic diagram of the exception handling process provided in the embodiments of this application;

[0031] Figure 10 A schematic diagram of the task processing process for the anti-starvation mechanism provided in this application embodiment;

[0032] Figure 11 A flowchart illustrating the test task scheduling method provided in an embodiment of this application;

[0033] Figure 12 A schematic diagram of the scheduling device provided in the embodiments of this application;

[0034] Figure 13 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0036] It should be noted that, in the case of user information involved in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0037] The terms or concepts involved in the embodiments of this application are explained below.

[0038] A test job is an execution unit that contains one or more test cases and consists of a series of test operations performed in a specific test environment.

[0039] Task decomposition: Break down one or more test tasks into subtasks that are easier to schedule and execute.

[0040] Subjob: A sub-task to be executed, which is split from a test task.

[0041] Resource allocation: Allocate specified resources such as machines or virtual instances to the test task.

[0042] Kafka: An open-source distributed stream processing platform widely used for real-time data stream transmission and processing.

[0043] Redis: An open-source, in-memory data structure store commonly used as a database, cache, and message broker.

[0044] A test suite is a group of test cases that are executed together to test specific functions or features of software.

[0045] Test case: An independent test instance designed to verify a specific function of a software system or its components.

[0046] Distributed scheduling engine (runner): A system used to manage and coordinate tasks or jobs executed on multiple computing nodes.

[0047] Execution step: A detailed execution step that is broken down from one or more subtasks. Each step is an independent executable script.

[0048] To improve the execution efficiency of concurrent test tasks, in some embodiments of this application, test tasks are decomposed into multiple subtasks, and task allocation nodes assign these subtasks to multiple scheduling nodes. This allows multiple scheduling nodes to perform parallel resource scheduling on multiple subtasks, achieving one-stop scheduling of test tasks. This embodiment, by splitting test tasks into multiple subtasks and having multiple scheduling nodes perform parallel resource scheduling on these subtasks, improves concurrent processing capabilities and helps increase the execution efficiency of concurrent test tasks compared to processing multiple test tasks in parallel. Furthermore, since the configuration information of a test task contains the parameters and conditions set for its successful execution, task decomposition based on this configuration information ensures that each subtask is self-contained, reducing cross-task dependencies.

[0049] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0050] It should be noted that the same reference numerals in the following figures and embodiments denote the same object or the same step. Therefore, once an object or step is defined in one figure or embodiment, it does not need to be discussed further in subsequent figures and embodiments.

[0051] Figure 1 This is a schematic diagram of the structure of a distributed scheduling system provided in an embodiment of this application. Figure 1 As shown, the distributed scheduling system includes: a test platform 10, multiple scheduling nodes 20, and task allocation nodes 30. In the embodiments of this application, "multiple" refers to two or more (including two).

[0052] In this embodiment, the testing platform 10 refers to a node or device that interacts with the user, providing a test task creation interface for the user to create test tasks through the interactive interface. Figure 2 As shown, the testing platform supports both single-task and multi-task creation. In some embodiments, such as Figure 2 As shown in the "Web Page," the test task creation interface provided by the test platform 10 can be implemented as a World Wide Web (Web) page. This Web page may include various configuration item controls, allowing users to configure the test task's configuration information. "Various" refers to two or more (including two). The test task's configuration information refers to the parameters and conditions set before executing the test task to ensure its successful execution. This may include, but is not limited to, some or all of the following: the test suite identifier, test suite configuration information, environment configuration information, and task priority.

[0053] The configuration information of the test suite refers to the parameters or conditions set for the successful execution of the test cases contained in the test suite. This may include, but is not limited to, the resource allocation strategy and resource specifications corresponding to the test suite. The resource allocation strategy refers to the strategy for allocating corresponding resources to the test suite. Specific resource allocation strategies will be described in the embodiments below and will not be elaborated upon here. Resource specifications refer to the resource requirements of the test suite, which can be used to specify the required resource size for the test suite. This may include, for example, the number of processor cores, memory size, and bandwidth size. Resource specifications may also include attribute requirements for the physical machine where the resources reside, such as machine type and architecture.

[0054] Environment configuration information refers to defining the environment in which the test task will run, and may include: whether to start the kernel, whether to restart the virtual instance or physical machine, the test task's global variables, and some or all of the package management tool (PM).

[0055] Users can configure test task information through various configuration controls on the web page. The test platform 10 can obtain the test task configuration information and create the test task based on it. Regarding the method of creating test tasks via the web page, such as... Figure 2 As shown, creation can be divided into two types: creation based on test task type and creation based on test task template. Creation based on test task type means that multiple test task types are pre-set, each corresponding to different configuration item controls. Users select the test task type, and the corresponding configuration item controls are provided. Creation based on test task template means that a template is provided to the user, which they can modify to create test tasks.

[0056] In other embodiments, the test platform 10 may provide an Application Programming Interface (API). For example... Figure 2 As shown in "API Creation," users can call the corresponding API through their terminal devices to provide test task configuration information to the test platform 10. The test platform 10 can obtain the test task configuration information and create test tasks based on it. There can be one or more test tasks. Alternatively, users can also call the corresponding API through their terminal devices to provide test plans. A test plan is a set of pre-arranged test tasks, including test task creation and execution. Accordingly, as... Figure 2As shown in "Test Plan Creation," the test platform 10 can create test tasks based on a test plan. One or more test tasks can be created based on the test plan. Following the above method, the test platform 10 can complete the creation of test tasks, corresponding to… Figure 1 and Figure 3 Step 1, "Test Task Creation".

[0057] Furthermore, such as Figure 3 As shown in step 2, "Storage," the test platform 10 can store the test task information in the database 40. The test task information refers to information describing the test task, which may include: the test task's name, identifier, and configuration information, etc. Accordingly, as... Figure 1 and Figure 3 As shown, the test platform 10 can also provide test task information to the scheduling node 20. The scheduling node 20 refers to the node that schedules the test tasks. The scheduling node 20 can be a single server device, a cloud-based server array, or a virtual machine (VM) running in a cloud-based server array. In addition, the scheduling node 20 can also refer to other computing devices with corresponding service capabilities, such as computer terminal devices (running service programs), etc.

[0058] like Figure 1 Step 2 "Test Task Sending" and Figure 3 As shown in step 2, "Storage," the test platform 10 can send the test task information to the task allocation node 30. The task allocation node 30 refers to the node that allocates tasks to the scheduling node. This scheduling node can be implemented as any computing device, or as... Figure 3 The distributed stream processing platform shown. Accordingly, as Figure 3 As shown in step 2, "Storage," the test platform 10 can write the test task information to a message queue provided by a distributed stream processing platform (such as Kafka). Further, as... Figure 1 and Figure 3 As shown in step 3, "Test Task Assignment," the task assignment node 30 can assign test tasks to the scheduling node 20. Specifically, the task assignment node 30 provides the scheduling node 20 with the test task information.

[0059] Specifically, the task allocation node can provide test task information to multiple scheduling nodes 20 according to a pre-set load balancing strategy. For example, the load balancing strategy can be a round-robin strategy. Accordingly, the task allocation node can send the test task information to each of the multiple scheduling nodes 20 sequentially, in a loop. Another example is a least-connections strategy. Accordingly, the task allocation node sends the current test task information to the scheduling node 20 with the fewest current test tasks. Yet another example is a source Internet Protocol (IP) hash strategy. Accordingly, the task allocation node can determine which scheduling node to send the test task information to based on the hash value of the IP address of the client that created the test task.

[0060] For a single scheduling node 20, the currently received test tasks can be one or more. "Multiple" refers to two or more (including two). For each currently received test task, the processing logic of the scheduling node 20 is the same. The following example uses any currently received test task A as an illustration.

[0061] For any test task A, such as Figure 1 Step 4 and Figure 3 As shown in step 4, "Test Task Decomposition," scheduling node 20 can decompose test task A into multiple subtasks. "Multiple" refers to two or more (including two). In this embodiment, the specific implementation of decomposing test task A into multiple subtasks is not limited. Figure 1 and Figure 3 In the test, one test task was broken down into subtasks 1-3; another test task was broken down into subtasks 4-5.

[0062] In some embodiments, test task A may include multiple test units, each performing a different test function. Accordingly, test task A can be decomposed into multiple subtasks based on the functions of its test units. Specifically, a test unit performing the same test function can be decomposed into a subtask, resulting in multiple subtasks.

[0063] In other embodiments, test task A can be broken down into multiple subtasks based on its configuration information. Since the configuration information of test task A contains the parameters and conditions set for the successful execution of the test task, splitting the task based on the configuration information ensures that each subtask is self-contained and reduces cross-task dependencies.

[0064] Specifically, the configuration information for a test task may include test suite information. This test suite information may include the test suite's identifier and / or configuration information. A test task may include one or more test suites. A test suite refers to a set of test instances used to complete a test task. Accordingly, test suite information can be obtained from the configuration information of test task A; and based on this information, test task A can be broken down into multiple subtasks. The test suite, as an independent unit, is used for task decomposition based on its information, which helps to build a clear and modular task structure, making test task management simpler.

[0065] In some embodiments, a single test suite can be decomposed into a subtask based on test suite information, resulting in multiple subtasks. Since different test suites can typically run in parallel, decomposing the same test suite into a subtask provides the conditions for the parallel execution of subsequent subtasks. In other embodiments, test task A comprises multiple test suites. Accordingly, configuration information for multiple test suites can be obtained from the test suite information; and based on this configuration information, the multiple test suites can be decomposed into multiple subtasks. This embodiment, by analyzing the specific configuration of each test suite, enables a more granular task decomposition of the test task, which helps improve the concurrency of subsequent subtask execution.

[0066] In some embodiments, a test suite may include a set of test instances. This set of test instances may be one or more. For an embodiment where a test suite includes multiple test cases, the configuration information of the test suite may include: resource allocation strategies corresponding to the multiple test cases and resource specification information corresponding to each of the multiple test cases. Accordingly, based on the configuration information of the test suite, the test cases contained in each of the multiple test suites can be determined from test task A; for any test suite B among the multiple test suites, the resource allocation strategy corresponding to the test cases contained in the test suite can be determined according to the resource allocation strategy corresponding to test suite B; test cases corresponding to the same resource allocation strategy under multiple test suites of test task A can be divided into the same subtask to decompose test task A into multiple subtasks. In this embodiment, dividing test cases with the same resource allocation strategy into the same subtask can, on the one hand, achieve a more granular task decomposition of the test task, which helps to further improve the concurrency of subsequent parallel execution of subtasks; on the other hand, the same subtask has the same resource allocation strategy, which facilitates subsequent resource allocation for the subtask.

[0067] In other embodiments, test cases corresponding to the same resource allocation strategy under the same test suite B can be divided into the same subtask. The same method can be used to decompose each test suite into tasks, thereby breaking down test task A into multiple subtasks. For example, as... Figure 4As shown, the test tasks include: Test Suite 1-3. Test Suite 1 includes test cases 1-1 to 1-4; Test Suite 2 includes test cases 2-1 to 2-3; Test Suite 3 includes test cases 3-1 to 3-3. The resource allocation strategies for test cases 1-1 to 1-4 in Test Suite 1 are different, therefore Test Suite 1-4 can be broken down into 4 sub-tasks, namely Sub-tasks 1-4. In Test Suite 2, test cases 2-1 and 2-2 have the same resource allocation strategy, while the resource allocation strategy for test case 2-3 is different from that of test cases 2-1 and 2-2. Therefore, Test Suite 2 can be broken down into 2 sub-tasks, namely, test cases 2-1 and 2-2 are assigned to the same sub-task 5, and test case 2-3 is assigned to a separate sub-task 6. In test suite 3, test cases 3-2 and 3-3 have the same resource allocation strategy, while test case 3-1 has a different resource allocation strategy. Therefore, test suite 3 can be broken down into two sub-tasks: test case 3-1 is assigned to sub-task 7, and test cases 3-2 and 3-3 are assigned to the same sub-task 5. Thus, Figure 4 The test task shown is broken down into 8 sub-tasks.

[0068] In this embodiment, different test suites for different test tasks belong to different subtasks; different resource allocation strategies for the same test suite also belong to different subtasks. This implementation divides test cases with the same resource allocation strategy within the same test suite into the same subtask. On the one hand, further splitting the same test suite allows for finer-grained task decomposition of test tasks, which helps to further improve the concurrency of subsequent subtask execution. On the other hand, having the same resource allocation strategy for the same subtask facilitates subsequent resource allocation for the subtask. Furthermore, this implementation, where different test suites belong to different subtasks, reduces the risk of resource contention between different test suites.

[0069] The test task decomposition method illustrated in the foregoing embodiments is merely illustrative and does not constitute a limitation. Using the same method, each test task can be decomposed into multiple sub-tasks. Decomposing a single test task into multiple sub-tasks provides conditions for the parallel execution of test tasks.

[0070] After breaking down the test task into multiple sub-tasks, such as Figure 1 Step 5 and Figure 3 As shown in step 5, "Subtask Sending," scheduling node 20 can send multiple subtasks corresponding to each test task to task allocation node 30. Further, as... Figure 1 Step 6 and Figure 3As shown in step 6, "Subtask Allocation," the task allocation node 30 can allocate multiple subtasks to multiple scheduling nodes 20. The task allocation node 30 can allocate multiple subtasks to multiple scheduling nodes 20 according to a preset load balancing strategy. For a description of the load balancing strategy, please refer to the relevant content in the foregoing embodiments, which will not be repeated here. Thus, as... Figure 1 Step 7 and Figure 3 As shown in step 7, "Subtask Resource Scheduling", multiple scheduling nodes 20 can perform resource scheduling on multiple subtasks in parallel, realizing parallel scheduling of multiple subtasks, which helps to improve the scheduling efficiency of test tasks, thereby helping to improve the execution efficiency of test tasks.

[0071] The following example, using any one of the multiple scheduling nodes 20, illustrates the specific implementation of how a scheduling node performs resource scheduling on subtasks. Any one of the multiple scheduling nodes 20 obtains a subtask (defined as a target subtask). The target subtask may be a subtask obtained by decomposing a test task in the aforementioned embodiments; it may also be a subtask decomposed from other test tasks allocated by the task allocation node, and is not limited thereto. There can be one or more target subtasks. "Multiple" refers to two or more (including two). The scheduling node can perform resource scheduling on the target subtask according to the configuration information of the test task to which the target subtask belongs. For ease of description and distinction, the test task to which the target subtask belongs is defined as the target test task. Specifically, the scheduling node 20 can allocate resources to the target subtask according to the resource configuration information of the target test task. The resources allocated to the subtask are determined by... Figure 1 The computing node 30 shown is provided. Specifically, the scheduling node 20 can allocate resources to the target subtasks according to the resource allocation strategy and resource specification information corresponding to the target test task. It can allocate appropriate resources to multiple subtasks of test task A to avoid resource waste or shortage.

[0072] The following describes the specific implementation method for allocating resources for target subtasks.

[0073] Implementation Method 1: The resource allocation strategy includes a configuration creation strategy. The configuration creation strategy refers to the strategy of creating virtual instances in real time based on resource requirements. A virtual instance refers to a virtualized computing resource created in a cloud computing environment; it is a runtime environment with complete hardware system functions, implemented through software simulation. A virtual instance can be a virtual machine, a container, or a container group (such as a Pod). Accordingly, when the resource allocation strategy includes a configuration creation strategy, the resource specification information of the target test task to which the target subtask belongs can be obtained. The resource specification information corresponding to a test task can be one type of resource specification information or include multiple types. Multiple types refer to two or more types (including two). For example, multiple test suites included in the test task may have the same or different resource specification information. Accordingly, at least one virtual instance can be created based on the resource specification information corresponding to each of the multiple test suites. Specifically, if multiple test suites have the same resource specification information, the scheduling method for the test task is scheduling by test task. Therefore, based on the same resource specification information corresponding to multiple test suites, a virtual instance with adapted resource specifications is created; and multiple subtasks of test task A are assigned to this virtual instance.

[0074] If multiple test suites have different resource specifications, for any given test suite, a virtual instance adapted to the resource specifications of that test suite can be created. Furthermore, the subtasks corresponding to that test suite can be assigned to that virtual instance. This scheduling method is per test suite. Correspondingly, the resource specifications of the target test suite corresponding to the target subtask can be obtained from the resource specifications of the target test task to which the target subtask belongs; and a virtual instance is created based on the resource specifications of the target test suite corresponding to the target subtask.

[0075] Specifically, it can be determined whether a virtual instance corresponding to the resource specifications has already been created for the target test task. If it has, the target subtask is assigned to the created virtual instance. If it has not yet been created, a virtual instance can be created based on the resource specifications of the target test suite, and the target subtask is assigned to the created virtual instance. By configuring the creation strategy, virtual instances suitable for the execution of subtasks can be created in real time according to the resource requirements of the test task, ensuring that the subtasks can execute smoothly.

[0076] Accordingly, when assigning multiple subtasks of a test task to virtual instances, for any test suite B, the subtasks corresponding to test suite B can be scheduled to the virtual instances adapted to the resource specifications of test suite B, based on the resource specifications of test suite B. In this embodiment, since each subtask is assigned to a virtual instance that matches its resource requirements, task queuing and waiting time caused by resource mismatch is reduced, improving execution efficiency. On the other hand, for embodiments where different test suites under the same test task specify different resource specifications, subtasks corresponding to different test suites can be assigned to different virtual instances by reasonably allocating resources, increasing concurrent processing capabilities and helping to improve testing efficiency.

[0077] Implementation Method 2: The resource allocation strategy includes an inherent virtual instance allocation strategy. An inherent virtual instance allocation strategy refers to a strategy for allocating corresponding virtual instances to test tasks from inherent virtual instances. In some embodiments, the inherent virtual instance allocation strategy may include: identifiers of virtual instances specified by each of the multiple test suites under test task A. The specified virtual instances may be special (SPEC) virtual instances, snapshot (SNAP) virtual instances, or tag-type (TAG) virtual instances, etc. Tag-type virtual instances refer to a method in a cloud computing environment where specific tags are assigned to virtual instances to facilitate the management and identification of these resources. Tags are user-defined metadata, typically attached to virtual instances in the form of key-value pairs, allowing users to classify, search, filter, and automate resource management based on these tags. Accordingly, when the resource allocation strategy corresponding to the test task is an inherent virtual instance allocation strategy, the target subtask can be allocated to the inherent virtual instance corresponding to the identifier of the virtual instance specified by the target test suite corresponding to the target subtask. In this embodiment, by specifying a specific virtual instance for each test suite, it can be ensured that each execution is performed in the same environment, which helps to guarantee the reliability and repeatability of the test results. On the other hand, each test suite has its own virtual instance, which can effectively avoid multiple test suites competing for the same resource, reducing resource contention and potential performance bottlenecks.

[0078] In other embodiments, the inherent virtual instance allocation strategy may include: resource specification information corresponding to the target test suite corresponding to the target subtask. Accordingly, when the resource allocation strategy corresponding to the test task is an inherent virtual instance allocation strategy, the target subtask can be allocated to an inherent virtual instance whose resource specification information matches that of the target test suite. Specifically, an inherent virtual instance whose resource specification information matches that of the target test suite can be randomly selected from the inherent virtual instances, and the target subtask can be allocated to that inherent virtual instance. This embodiment improves the execution efficiency and performance of subtasks by ensuring that each test suite runs on a virtual instance that meets its specific resource requirements, and helps to avoid resource waste caused by over-configuration or performance bottlenecks caused by under-configuration.

[0079] In some embodiments, the configuration information of the test task may further include: the task priority of the test task. Task priority refers to the priority at which the test task is executed. Accordingly, the scheduling node 20 may allocate resources to the target subtasks corresponding to each of the multiple test tasks in sequence according to their task priorities. For test tasks with the same task priority, resources may be allocated to their respective target subtasks according to their creation time. Specific resource allocation methods can be found in the relevant content of the foregoing embodiments and will not be repeated here.

[0080] After allocating resources to each target subtask, scheduling node 20 obtains the resource allocation information for each target subtask. This resource allocation information may include the identifier of the virtual instance to which the target subtask is allocated. Further, scheduling node 20 can schedule at least one target subtask to its allocated resources based on the received resource allocation information and the task priority of the target test task to which each target subtask belongs. In this way, the resources allocated to each target subtask can execute the test cases corresponding to that target subtask, thereby completing the test task and obtaining test results. In this embodiment, scheduling target subtasks based on their resource allocation information and task priority allows high-priority test tasks to be executed first. Once a high-priority task completes and releases its resources, low-priority tasks can immediately use those resources, improving overall resource utilization. Furthermore, multiple scheduling nodes concurrently executing the test task scheduling method provided in the aforementioned embodiment helps improve the execution efficiency of concurrent test tasks.

[0081] In this embodiment, for an implementation where a scheduling node receives only one target subtask, the scheduling node can directly schedule the target subtask to the resource allocated to it based on the resource allocation information of the target subtask. The following focuses on an example where the scheduling node receives multiple target subtasks, illustrating the specific implementation of scheduling at least one target subtask to the resource allocated to each of the at least one target subtasks based on the resource allocation information of at least one target subtask and the task priority of the target test task to which each target subtask belongs. In some embodiments, multiple target subtasks can be sequentially scheduled to the virtual instances to which they are allocated based on the task priority of the target test task to which each target subtask belongs. For example, for a first test task and a second test task with adjacent task priorities among multiple test tasks, the target subtasks of the first test task can be scheduled first to the virtual instances to which the target subtasks of the first test task are allocated; then, the target subtasks of the second test task can be scheduled to the virtual instances to which the target subtasks of the second test task are allocated. This implementation allows high-priority test tasks to be executed first. Once the high-priority tasks are completed and release resources, low-priority tasks can immediately use these resources, thus improving overall resource utilization.

[0082] In other embodiments, target subtasks assigned to the same virtual instance can be determined based on the identifiers of the virtual instances to which multiple target subtasks are assigned. Then, based on the task priorities of the target test tasks to which the target subtasks belong, the target subtasks assigned to the same virtual instance are sequentially scheduled onto that virtual instance (defined as a target virtual instance). A target virtual instance refers to the virtual instance to which the target subtasks assigned to the same virtual instance are assigned. This implementation allows subtasks on the same virtual instance to be sorted and scheduled based on the priorities of their respective test tasks. This means that even subtasks of different test tasks assigned to the same virtual instance can receive appropriate processing order based on their task priorities, providing finer-grained control. On the other hand, by managing task priorities at the individual virtual instance level, lower-priority tasks are executed only after higher-priority tasks are completed, which can more effectively reduce resource contention and help improve resource utilization efficiency.

[0083] In some embodiments, the execution order of target subtasks assigned to the same virtual instance can be determined according to the task priority of the test task to which each target subtask belongs; then, the target subtasks assigned to the same virtual instance can be scheduled to the target virtual instance in sequence according to the execution order of the target subtasks assigned to the same virtual instance.

[0084] In other embodiments, a linked list of target subtasks assigned to the same virtual instance can be created based on the execution order of those subtasks. A linked list is a basic data structure used to store and organize data. Unlike arrays, elements in a linked list are not stored in contiguous memory locations but are interconnected via pointers (references). Each element (often called a node) contains two parts: a data field and a pointer field pointing to the next node. Accordingly, based on the execution order of subtasks assigned to the same virtual instance, the linked list stores the subtasks assigned to the target virtual instance and pointers to the next subtask of each subtask, thus obtaining a linked list of subtasks assigned to that target virtual instance. For example, as... Figure 5 As shown, in linked list 1, subtasks 1, 4, and 10 are assigned to the same virtual instance 1. In linked list 1, subtask 1 points to subtask 4, and subtask 4 points to subtask 10. In linked list 2, subtasks 2 and 5 are assigned to the same virtual instance 2. In linked list 2, subtask 2 points to subtask 5. In linked list 3, subtasks 3 and 8 are assigned to the same virtual instance 3. In linked list 3, subtask 3 points to subtask 8.

[0085] The name of the linked list can be the identifier of the corresponding virtual instance. Figure 5 The diagram uses the linked list name as an example of the identifier of a virtual instance under the workspace. In this embodiment, the workspace is divided according to the computing nodes where the virtual instances are located by the user. The user can only use the computing nodes under their own workspace to execute test tasks. That is, the virtual instances allocated to the test tasks provided to the user are virtual instances deployed on the computing nodes under the user's own workspace.

[0086] Furthermore, based on this linked list, target subtasks assigned to the same virtual instance can be sequentially scheduled to the target virtual instance. Organizing and managing subtasks within the same virtual instance using a linked list makes each subtask and its execution order readily apparent, facilitating the tracking and management of task status on each virtual instance.

[0087] In some embodiments, the linked list can be stored in a memory-based data structure storage system (such as Redis). Furthermore, when the corresponding virtual instance is idle, the linked list can be read from the memory-based data structure storage system, and the target subtasks assigned to the same virtual instance can be scheduled sequentially onto the target virtual instances according to their order in the linked list. Since the linked list is stored in a memory-based data structure storage system, reading the linked list from memory improves the efficiency of linked list retrieval, thereby helping to improve the efficiency of subsequent task scheduling.

[0088] In some embodiments, such as Figure 3As shown in step 7, "Subtask Data Cache," subtask data can also be stored in a memory-based data structure storage system 50. For example, Figure 6 As shown, subtask data may include: subtask identifier, creation time, latest modification time, whether it has been deleted, the identifier of the test task to which the subtask belongs, the resource specifications and resource allocation strategy corresponding to the subtask, the completion status of the subtask, the mode and type of the virtual instance allocated to the subtask, the environment configuration information of the subtask, and the completion time of the subtask. The mode of the virtual instance allocated to the subtask can be single-machine mode or cluster mode. The type of virtual instance can be internal network machine type or elastic machine type. Internal network machine type refers to a compute node deployed in the user's internal network. Elastic machine type refers to a compute node deployed in the public cloud.

[0089] In some embodiments of this application, when scheduling subtasks assigned to the same virtual instance according to the task priority of the test task to which each target subtask belongs, for any currently scheduled target subtask D, such as Figure 3 As shown in step 6, "Subtask Splitting," the target subtask D can be split into multiple steps based on the resource allocation strategy corresponding to the target subtask D and the environment configuration information of the test task to which the target subtask D belongs. Each step can be encapsulated as an independent executable script.

[0090] Specifically, if the resource allocation strategy corresponding to target subtask D is a configuration creation strategy, then the first step of target subtask D is determined to be creating a virtual instance. Afterwards, other steps of target subtask D can be determined based on the environment configuration information of the test task to which target subtask D belongs. Optionally, the environment configuration items of the test task to which target subtask D belongs can be determined based on the environment configuration information; then, other steps of target subtask D can be determined based on the logical order between the environment configuration items. Environment configuration items may include one or more of the following: machine reinstallation configuration items, kernel reinstallation configuration items, machine restart configuration items, global variable configuration items, PM installation configuration items, script execution configuration items, console configuration items, and monitoring configuration items.

[0091] For example, assuming that the environment configuration items of the test task to which the target subtask D belongs include: machine reinstallation configuration item, kernel reinstallation configuration item, machine restart configuration item, global variable configuration item, PM installation configuration item, script execution configuration item, console configuration item, and monitoring configuration item, then the other steps of the target subtask D include: (1) Machine reinstallation configuration item: reinstall the operating system; (2) Kernel reinstallation configuration item: install the released kernel; (3) Machine restart configuration item: whether to enable the machine restart switch; (4) Global variable configuration item: global variable configuration of the test task; (5) Install PM and select the installation time; (6) Script execution configuration item: enable the script function; (7) Console configuration item: enable the console function at the test case level; (8) Monitoring configuration item: enable the monitoring function at the test case level; (9) Execute the test cases of subtask D. Among them, the other steps included in subtask D can be flexibly selected according to whether the corresponding configuration items are set.

[0092] If the resource allocation strategy corresponding to target subtask D is the inherent virtual instance allocation strategy, then target subtask D is split into multiple steps based on the environment configuration information of the test task to which target subtask D belongs. For a detailed implementation of splitting target subtask D into multiple steps based on the environment configuration information of the test task to which target subtask D belongs, please refer to the aforementioned section on determining the specific content of the environment configuration items of the test task to which target subtask D belongs.

[0093] In some embodiments, information about the multiple steps included in a subtask can also be written into a subtask data structure. For example... Figure 6 As shown, subtask data may also include: the number of steps contained in the subtask and the specific steps.

[0094] Furthermore, based on the sequential order of the steps, multiple steps can be scheduled to the same virtual instance, thereby scheduling the target subtask D onto that target virtual instance. Breaking the subtask into multiple steps makes the entire execution flow more transparent, facilitating the tracking and management of the status and progress of each step. If a specific step fails, the problem can be more easily located, and targeted measures can be taken to resolve it without affecting the normal execution of other steps.

[0095] Specifically, multiple steps can be sent to the task allocation node. For example, multiple steps can be sent to task allocation node 30, such as a distributed stream processing platform (e.g., Kafka). The task allocation node (e.g., the distributed stream processing platform) can write the multiple steps into a message queue. The task allocation node (e.g., the distributed stream processing platform) can distribute the multiple steps to multiple scheduling nodes according to a preset load balancing strategy, thereby achieving load balancing among the scheduling nodes. The task allocation node (e.g., the distributed stream processing platform) can sequentially trigger multiple scheduling nodes to schedule the allocated steps according to the order of the multiple steps of the target subtask D, so that the multiple scheduling nodes sequentially schedule the multiple steps to the virtual instance assigned to the target subtask D.

[0096] Specifically, when any scheduling node among multiple scheduling nodes schedules multiple steps of the target subtask D sequentially to the target virtual instance according to their order, it can respond to a triggering operation from the distributed stream processing platform to schedule step X, assigned to it, to the virtual instance to which target subtask D is assigned. After scheduling step X to the virtual instance to which target subtask D is assigned, the scheduling node can send a completion message to the distributed stream processing platform. The task allocation node (such as the distributed stream processing platform) can respond to the completion message and trigger the scheduling node for the next step assigned to step X. The scheduling node for the next step assigned to step X can respond to the triggering operation from the task allocation node (such as the distributed stream processing platform) to schedule the next step of step X assigned to it to the virtual instance to which target subtask D is assigned, and so on, until all multiple steps of target subtask D have been scheduled. This embodiment achieves load balancing of scheduling nodes by distributing multiple steps of the same target subtask to multiple scheduling nodes through the distributed stream processing platform.

[0097] Scheduling node 20 schedules each subtask to its assigned resource. The resources allocated to each subtask (such as virtual instances like virtual machines) can then execute the corresponding test cases, thereby testing the test object corresponding to the test task. During test task execution, the user and the scheduling node can perceive the execution status of the test task from different perspectives. For example... Figure 7 As shown, from the user's perspective, what the user can perceive is the execution status of each test suite under the test task and the execution status of each test case under the test suite. The execution status of the test suite and the execution status of the test cases can include: successful execution, failed, running, paused, and skipped.

[0098] like Figure 8As shown, from the perspective of the scheduling node, the test task is broken down into multiple subtasks, and the test cases corresponding to these subtasks are executed. The scheduling node can be aware of the execution status of these subtasks. During the execution of the test cases corresponding to the target subtask in the virtual instance, the execution status of the target subtask can be monitored. Specifically, the execution status of multiple steps contained in the target subtask can be monitored and recorded, such as the execution status of each step of the target subtask. The scheduling node 20 can obtain the execution status of the target subtask. If the execution status of the target subtask is abnormal, it determines the other test cases (defined as target test cases) that the test cases corresponding to the target subtask depend on. Furthermore, the scheduling node 20 can reallocate resources for the abnormal target subtask and the subtasks corresponding to the target test cases, and schedule the subtasks corresponding to the target test cases and the abnormal target subtasks sequentially to their respective reallocated resources. The reallocated resources corresponding to the abnormal target subtasks and the subtasks corresponding to the target test cases can be used to execute the target test cases and the test cases corresponding to the abnormal target subtasks, thereby realizing the recovery of failed test cases. Specifically, the target test case is executed first, followed by the test cases corresponding to the target subtasks that encountered exceptions. Since the test cases for the subtasks that encountered exceptions depend on the target test case, executing the target test case first, and then the test cases for the subtasks that encountered exceptions, ensures that the test cases for the subtasks that encountered exceptions can execute smoothly. This embodiment can leverage the real-time monitoring mechanism of monitoring tools to capture subtasks that encounter execution errors and to recover from them, thus ensuring test availability and reliability.

[0099] For example, such as Figure 9 As shown, the test task is broken down into subtasks 1-3. Subtasks 1 and 3 use the same virtual instance 1; subtask 2 uses a different virtual instance 2. A monitoring tool can monitor the execution status of the subtasks in real time. This monitoring tool can be deployed on the virtual instance. If an abnormality is detected in the execution status of subtask 2, Figure 9Taking the exception of subtask 2 as an example of a timeout in fetching test case code causing an exception in subtask 2, the scheduling node can be notified to save the current state of subtask 2. The scheduling node can reschedule resources for subtask 2 in the event of an exception. Specifically, the target test case that the test case corresponding to subtask 2 depends on can be determined, and resources can be rescheduled for the subtasks corresponding to the target test case and subtask 2. Then, the subtask corresponding to the target test case can be sent to its allocated resources to execute the target test case; subsequently, subtask 2 can be sent to its allocated resources to execute, thereby achieving automatic recovery of subtask 2. In this embodiment, to prevent subtasks from "starving" due to long waiting times for scheduling, an anti-starvation mechanism is proposed. Subtask "starvation" refers to the situation where some subtasks, due to resource contention or other scheduling strategies, cannot obtain the necessary resources for a long time, resulting in these subtasks remaining in a waiting state and unable to be executed. Specifically, as shown... Figure 10 As indicated by "Timing," the waiting time for any of the aforementioned target subtasks D can be timed. Specifically, after the test task is broken down into multiple subtasks, the waiting time for each subtask can be timed separately. Furthermore, as... Figure 10 As shown, if target subtask D is not scheduled after a set waiting time, the system checks whether the resources allocated to target subtask D are idle. If the resources allocated to target subtask D are idle, target subtask D is scheduled to the allocated resources to execute the corresponding test cases. If the resources allocated to target subtask D are occupied, target subtask D is written to a designated message queue and awaits scheduling. To distinguish it from the message queues provided by the aforementioned distributed stream processing platform, in the following embodiments of this application, the message queues provided by the distributed stream processing platform are defined as the first message queue; and the queue used to store "starved" subtasks is defined as the second message queue.

[0100] To prevent subtasks in the second message queue from starving, the usage status of resources allocated to each subtask of the aforementioned test tasks can be monitored. If idle resources are detected among the resources allocated to the subtasks of the test tasks, a subtask whose allocated resources match the idle resources is searched from the second message queue. Matching the allocated resources with the idle resources specifically means that the resource specifications of the idle resources are the same as the resource specifications allocated to the subtask. Furthermore, the target subtask matching the idle resources can be scheduled to the idle resources. The idle resources can then be used to execute the test cases corresponding to the desired subtasks. This embodiment effectively prevents some subtasks from "starving" due to prolonged lack of scheduling. On the other hand, by dynamically monitoring the resource usage status and promptly scheduling waiting subtasks when idle resources are detected, the overall resource utilization rate is improved, and resource waste is reduced.

[0101] In addition to the scheduling system described above, this application also provides a test task scheduling method. The test task scheduling method provided in this application will be described below from the perspective of the scheduling node.

[0102] Figure 11 This is a flowchart illustrating the test task scheduling method provided in an embodiment of this application. This method is primarily applicable to any scheduling node in a distributed scheduling system. Figure 11 As shown, the test task scheduling method mainly includes the following steps:

[0103] 1101. Obtain the test task.

[0104] 1102. Based on the configuration information of the test task, break down the test task into multiple sub-tasks.

[0105] 1103. Send multiple subtasks to the task allocation node so that the task allocation node can distribute the multiple subtasks to multiple scheduling nodes for parallel resource scheduling.

[0106] In some embodiments of this application, test tasks can be created by users through a testing platform. For specific implementation details regarding the creation of test tasks through a testing platform, please refer to the relevant content of the foregoing system embodiments, which will not be repeated here. Test tasks acquired by the scheduling node can be assigned by the task allocation node. For specific implementation details regarding the task allocation node assigning test tasks to the scheduling node, please refer to the relevant content of the foregoing system embodiments, which will not be repeated here.

[0107] The test task obtained in step 1101 can be one or more. "Multiple" means two or more (including two). For each currently received test task, the scheduling node processes it using the same logic. The following example illustrates this process using any currently received test task.

[0108] For any test task, it can be broken down into multiple subtasks. "Multiple" refers to two or more (including two). In this application's embodiments, the specific implementation method for breaking down a test task into multiple subtasks is not limited.

[0109] In some embodiments, a test task may include multiple test units, each performing a different test function. Accordingly, the test task can be broken down into multiple sub-tasks based on the function of the test units. Specifically, a test unit performing the same test function can be broken down into a sub-task, resulting in multiple sub-tasks.

[0110] In other embodiments, in step 1102, the test task can be broken down into multiple subtasks based on the test task's configuration information. Since the test task's configuration information contains the parameters and conditions set for the test task to execute smoothly, splitting the task based on the test task's configuration information can ensure that each subtask is self-contained and reduce cross-task dependencies.

[0111] Specifically, the configuration information for a test task may include test suite information. This test suite information may include the test suite's identifier and / or configuration information. A test task may include one or more test suites. A test suite refers to a set of test instances used to complete a test task. Accordingly, test suite information can be obtained from the test task's configuration information; and based on this information, the test task can be broken down into multiple sub-tasks. The test suite, as an independent unit, is used for task decomposition based on its information, which helps to build a clear and modular task structure, making test task management simpler.

[0112] In some embodiments, a single test suite can be decomposed into a subtask based on test suite information, resulting in multiple subtasks. Since different test suites can typically run in parallel, decomposing the same test suite into a subtask provides the conditions for the parallel execution of subsequent subtasks. In other embodiments, a test task comprises multiple test suites. Accordingly, configuration information for multiple test suites can be obtained from the test suite information; and based on this configuration information, the multiple test suites can be decomposed into multiple subtasks. This embodiment, by analyzing the specific configuration of each test suite, enables a more granular task decomposition of the test task, which helps improve the concurrency of subsequent subtask execution.

[0113] In some embodiments, a test suite may include a set of test instances. This set of test instances may be one or more. For an embodiment where a test suite includes multiple test cases, the configuration information of the test suite may include: resource allocation strategies corresponding to the multiple test cases and resource specification information corresponding to each of the multiple test cases. Accordingly, based on the configuration information of the test suite, the test cases contained in each of the multiple test suites can be determined from the test task; for any test suite B among the multiple test suites, the resource allocation strategy corresponding to the test cases contained in the test suite is determined according to the resource allocation strategy corresponding to test suite B; test cases corresponding to the same resource allocation strategy under multiple test suites of test task A can be divided into the same subtask to decompose test task A into multiple subtasks. In this embodiment, dividing test cases with the same resource allocation strategy into the same subtask can, on the one hand, achieve a more granular task decomposition of the test task, which helps to further improve the concurrency of subsequent parallel execution of subtasks; on the other hand, the same subtask has the same resource allocation strategy, which facilitates subsequent resource allocation for the subtask.

[0114] In other embodiments, test cases corresponding to the same resource allocation strategy under the same test suite B can be divided into the same subtask. The same method can be used to decompose each test suite into tasks, thereby breaking down test task A into multiple subtasks.

[0115] In this embodiment, different test suites for different test tasks belong to different subtasks; different resource allocation strategies for the same test suite also belong to different subtasks. This implementation divides test cases with the same resource allocation strategy within the same test suite into the same subtask. On the one hand, further splitting the same test suite allows for finer-grained task decomposition of test tasks, which helps to further improve the concurrency of subsequent subtask execution. On the other hand, having the same resource allocation strategy for the same subtask facilitates subsequent resource allocation for the subtask. Furthermore, this implementation, where different test suites belong to different subtasks, reduces the risk of resource contention between different test suites.

[0116] The test task decomposition method illustrated in the foregoing embodiments is merely illustrative and does not constitute a limitation. Using the same method, each test task can be decomposed into multiple sub-tasks. Decomposing a single test task into multiple sub-tasks provides conditions for the parallel execution of test tasks.

[0117] After breaking down the test task into multiple subtasks, in step 1103, each test task can send its corresponding multiple subtasks to the task allocation node. Furthermore, the task allocation node can distribute these multiple subtasks to multiple scheduling nodes. The task allocation node can distribute the multiple subtasks to multiple scheduling nodes according to a preset load balancing strategy. A description of the load balancing strategy can be found in the relevant content of the foregoing embodiments, and will not be repeated here. In this way, multiple scheduling nodes can perform resource scheduling on multiple subtasks in parallel, achieving parallel scheduling of multiple subtasks, which helps improve the scheduling efficiency of the test task, thereby helping to improve the execution efficiency of the test task.

[0118] The following example, using any one of multiple scheduling nodes, illustrates a specific implementation method for resource scheduling of subtasks by a scheduling node. Any one of the multiple scheduling nodes acquires a subtask (defined as a target subtask). There can be one or more target subtasks. "Multiple" refers to two or more (including two). The scheduling node can perform resource scheduling on the target subtask based on the configuration information of the test task to which the target subtask belongs. For ease of description and distinction, the test task to which the target subtask belongs is defined as the target test task. Specifically, resources can be allocated to the target subtask based on the resource configuration information of the target test task. Specifically, resources can be allocated to the target subtask based on the resource allocation strategy and resource specification information corresponding to the target test task. Appropriate resources can be allocated to multiple subtasks of test task A, avoiding resource waste or insufficiency.

[0119] The following describes the specific implementation method for allocating resources for target subtasks.

[0120] Implementation Method 1: The resource allocation strategy includes a configuration creation strategy. The configuration creation strategy refers to a strategy for creating virtual instances in real time based on resource requirements. Accordingly, when the resource allocation strategy includes a configuration creation strategy, the resource specification information of the target test task to which the target subtask belongs can be obtained. The resource specification information corresponding to a test task can be one type of resource specification information or can include multiple types of resource specification information. Multiple types refer to two or more types (including two). For example, multiple test suites included in a test task may have the same or different resource specification information. Accordingly, at least one virtual instance can be created based on the resource specification information corresponding to each of the multiple test suites. Specifically, if multiple test suites have the same resource specification information, the scheduling method for this test task is scheduling by test task. Therefore, based on the same resource specification information corresponding to multiple test suites, a virtual instance with adapted resource specifications is created; and multiple subtasks of test task A are assigned to this virtual instance.

[0121] If multiple test suites have different resource specifications, for any given test suite, a virtual instance adapted to the resource specifications of that test suite can be created. Furthermore, the subtasks corresponding to that test suite can be assigned to that virtual instance. This scheduling method is per test suite. Correspondingly, the resource specifications of the target test suite corresponding to the target subtask can be obtained from the resource specifications of the target test task to which the target subtask belongs; and a virtual instance is created based on the resource specifications of the target test suite corresponding to the target subtask.

[0122] Specifically, it can be determined whether a virtual instance corresponding to the resource specifications has already been created for the target test task. If it has, the target subtask is assigned to the created virtual instance. If it has not yet been created, a virtual instance can be created based on the resource specifications of the target test suite, and the target subtask is assigned to the created virtual instance. By configuring the creation strategy, virtual instances suitable for the execution of subtasks can be created in real time according to the resource requirements of the test task, ensuring that the subtasks can execute smoothly.

[0123] Accordingly, when assigning multiple subtasks of a test task to virtual instances, for any test suite B, the subtasks corresponding to test suite B can be scheduled to the virtual instances adapted to the resource specifications of test suite B, based on the resource specifications of test suite B. In this embodiment, since each subtask is assigned to a virtual instance that matches its resource requirements, task queuing and waiting time caused by resource mismatch is reduced, improving execution efficiency. On the other hand, for embodiments where different test suites under the same test task specify different resource specifications, subtasks corresponding to different test suites can be assigned to different virtual instances by reasonably allocating resources, increasing concurrent processing capabilities and helping to improve testing efficiency.

[0124] Implementation Method 2: The resource allocation strategy includes an inherent virtual instance allocation strategy. An inherent virtual instance allocation strategy refers to a strategy for allocating a corresponding virtual instance to a test task from inherent virtual instances. In some embodiments, the inherent virtual instance allocation strategy may include: the identifiers of virtual instances specified by each of the multiple test suites under the test task. Accordingly, when the resource allocation strategy corresponding to the test task is an inherent virtual instance allocation strategy, the target subtask can be allocated to the inherent virtual instance corresponding to the identifier of the virtual instance specified by the target test suite corresponding to the target subtask. In this embodiment, by specifying a specific virtual instance for each test suite, it can be ensured that each execution is performed in the same environment, which helps to guarantee the reliability and repeatability of the test results. On the other hand, each test suite has its own virtual instance, which can effectively avoid multiple test suites competing for the same resource, reducing resource contention and potential performance bottlenecks.

[0125] In other embodiments, the inherent virtual instance allocation strategy may include: resource specification information corresponding to the target test suite corresponding to the target subtask. Accordingly, when the resource allocation strategy corresponding to the test task is an inherent virtual instance allocation strategy, the target subtask can be allocated to an inherent virtual instance whose resource specification information matches that of the target test suite. Specifically, an inherent virtual instance whose resource specification information matches that of the target test suite can be randomly selected from the inherent virtual instances, and the target subtask can be allocated to that inherent virtual instance. This embodiment improves the execution efficiency and performance of subtasks by ensuring that each test suite runs on a virtual instance that meets its specific resource requirements, and helps to avoid resource waste caused by over-configuration or performance bottlenecks caused by under-configuration.

[0126] In some embodiments, the configuration information of a test task may further include: the task priority of the test task. Task priority refers to the priority at which the test task is executed. Accordingly, resources can be allocated to the target subtasks corresponding to each of the multiple test tasks in sequence according to their task priorities. For test tasks with the same task priority, resources can be allocated to their respective target subtasks according to their creation time. Specific resource allocation methods can be found in the relevant content of the foregoing embodiments and will not be repeated here.

[0127] After allocating resources to each target subtask, resource allocation information for each target subtask can be obtained. This resource allocation information may include the identifier of the virtual instance to which the target subtask is allocated. Further, based on the received resource allocation information of at least one target subtask and the task priority of the target test task to which each target subtask belongs, at least one target subtask can be scheduled onto the resources allocated to it. In this way, the resources allocated to each target subtask can execute the test cases corresponding to that target subtask, thereby completing the test task and obtaining test results. In this embodiment, scheduling target subtasks based on their resource allocation information and task priority allows high-priority test tasks to be executed first. Once a high-priority task completes and releases its resources, low-priority tasks can immediately use those resources, improving overall resource utilization. On the other hand, multiple scheduling nodes concurrently executing the test task scheduling method provided in the aforementioned embodiment helps improve the execution efficiency of concurrent test tasks.

[0128] In this embodiment, for an implementation where a scheduling node receives only one target subtask, the scheduling node can directly schedule the target subtask to the resources allocated to it based on the resource allocation information of the target subtask. The following focuses on an example where the scheduling node receives multiple target subtasks, illustrating the specific implementation of scheduling at least one target subtask to its allocated resources based on the resource allocation information of at least one target subtask and the task priority of the target test task to which each target subtask belongs. In some embodiments, multiple target subtasks can be sequentially scheduled to virtual instances to which they are allocated, based on the task priority of the target test task to which each target subtask belongs. This implementation allows high-priority test tasks to execute first, and low-priority tasks can immediately use these resources after the high-priority tasks complete and release them, improving overall resource utilization.

[0129] In other embodiments, target subtasks assigned to the same virtual instance can be determined based on the identifiers of the virtual instances to which multiple target subtasks are assigned. Then, based on the task priorities of the target test tasks to which the target subtasks belong, the target subtasks assigned to the same virtual instance can be scheduled sequentially onto the target virtual instance. A target virtual instance refers to the virtual instance to which the target subtasks assigned to the same virtual instance are assigned. This implementation allows subtasks on the same virtual instance to be sorted and scheduled based on the priorities of their respective test tasks. This means that even subtasks of different test tasks assigned to the same virtual instance can receive appropriate processing order according to their task priorities, providing finer-grained control. On the other hand, by managing task priorities at the individual virtual instance level, lower-priority tasks are executed only after higher-priority tasks are completed, which can more effectively reduce resource contention and help improve resource utilization efficiency.

[0130] In some embodiments, the execution order of target subtasks assigned to the same virtual instance can be determined according to the task priority of the test task to which each target subtask belongs; then, the target subtasks assigned to the same virtual instance can be scheduled to the target virtual instance in sequence according to the execution order of the target subtasks assigned to the same virtual instance.

[0131] In other embodiments, a linked list of target subtasks assigned to the same virtual instance can be established based on the execution order of the target subtasks assigned to the same virtual instance. The name of the linked list can be the identifier of the corresponding virtual instance. Furthermore, the target subtasks assigned to the same virtual instance can be sequentially scheduled to the target virtual instance based on this linked list. Organizing and managing subtasks of the same virtual instance using a linked list makes each subtask and its execution order readily apparent, facilitating the tracking and management of the task status on each virtual instance.

[0132] In some embodiments, the linked list can be stored in a memory-based data structure storage system (such as Redis). Furthermore, when the corresponding virtual instance is idle, the linked list can be read from the memory-based data structure storage system, and the target subtasks assigned to the same virtual instance can be scheduled sequentially onto the target virtual instances according to their order in the linked list. Since the linked list is stored in a memory-based data structure storage system, reading the linked list from memory improves the efficiency of linked list retrieval, thereby helping to improve the efficiency of subsequent task scheduling.

[0133] In some embodiments, subtask data may also be stored in a memory-based data structure storage system. For details regarding the content of the subtask data, please refer to the description of the foregoing system embodiments.

[0134] In some embodiments of this application, when scheduling subtasks assigned to the same virtual instance according to the task priority of the test task to which each target subtask belongs, for any currently scheduled target subtask D, the target subtask D can be divided into multiple steps according to the resource allocation strategy corresponding to the target subtask D and the environment configuration information of the test task to which the target subtask D belongs. Each step can be encapsulated as an independent executable script.

[0135] In some embodiments, information about the multiple steps included in a subtask may also be written into a subtask data structure. The subtask data may further include: the number of steps included in the subtask and the specific steps.

[0136] Furthermore, based on the sequential order of the steps, multiple steps can be scheduled to the same virtual instance, thereby scheduling the target subtask D to the target virtual instance. Breaking the subtask into multiple steps makes the entire execution flow more transparent, facilitating the tracking and management of the status and progress of each step. If a specific step fails, the problem can be more easily located, and targeted measures can be taken to resolve it without affecting the normal execution of other steps.

[0137] Specifically, multiple steps can be sent to the task allocation node. For example, multiple steps can be sent to the task allocation node, such as a distributed stream processing platform (e.g., Kafka). The task allocation node (e.g., the distributed stream processing platform) can write the multiple steps into a message queue. The task allocation node (e.g., the distributed stream processing platform) can distribute the multiple steps to multiple scheduling nodes according to a preset load balancing strategy, thereby achieving load balancing among the scheduling nodes. The task allocation node (e.g., the distributed stream processing platform) can sequentially trigger multiple scheduling nodes to schedule the allocated steps according to the order of the multiple steps of the target subtask D, so that the multiple scheduling nodes can sequentially schedule the multiple steps to the virtual instance assigned to the target subtask D.

[0138] Specifically, when any scheduling node among multiple scheduling nodes schedules multiple steps of the target subtask D sequentially to the same virtual instance according to their order, it can respond to a triggering operation from the distributed stream processing platform to schedule step X, assigned to it, to the virtual instance to which target subtask D is assigned. After scheduling step X to the virtual instance to which target subtask D is assigned, the scheduling node can send a completion message to the distributed stream processing platform. The task allocation node (such as the distributed stream processing platform) can respond to the completion message and trigger the scheduling node for the next step assigned to step X. The scheduling node for the next step assigned to step X can respond to the triggering operation from the task allocation node (such as the distributed stream processing platform) to schedule the next step of step X assigned to it to the virtual instance to which target subtask D is assigned, and so on, until all multiple steps of target subtask D have been scheduled. This embodiment achieves load balancing of scheduling nodes by distributing multiple steps of the same target subtask to multiple scheduling nodes through the distributed stream processing platform.

[0139] Furthermore, each subtask can be scheduled to the resources allocated to it. The resources allocated to each subtask (such as virtual instances like virtual machines) can execute the test cases corresponding to the subtask, thereby testing the test object corresponding to the test task. During the execution of the test cases corresponding to the target subtask in the virtual instance, the execution status of the target subtask can be monitored. Specifically, the execution status of multiple steps included in the target subtask can be monitored and recorded, such as the execution status of each step of the target subtask. Correspondingly, the execution status of the target subtask can be obtained. If the execution status of the target subtask is abnormal, other test cases (defined as target test cases) that the test cases corresponding to the target subtask depend on can be identified. Further, resources can be reallocated to the abnormal target subtask and the subtasks corresponding to the target test cases, and the subtasks corresponding to the target test cases and the abnormal target subtasks can be scheduled sequentially to their respective reallocated resources. The reallocated resources corresponding to the abnormal target subtasks and the subtasks corresponding to the target test cases can execute the target test cases and the test cases corresponding to the abnormal target subtasks, thereby recovering the failed test cases. Specifically, the target test case is executed first, followed by the test cases corresponding to the target subtasks that encountered exceptions. Since the test cases for the subtasks that encountered exceptions depend on the target test case, executing the target test case first, and then the test cases for the subtasks that encountered exceptions, ensures that the test cases for the subtasks that encountered exceptions can execute smoothly. This embodiment can leverage the real-time monitoring mechanism of monitoring tools to capture subtasks that encounter execution errors and to recover from them, thus ensuring test availability and reliability.

[0140] In this embodiment, to prevent subtasks from "starving" due to prolonged waiting for scheduling, an anti-starvation mechanism is proposed. Specifically, for any of the aforementioned target subtasks D, the waiting time of target subtask D can be timed. Specifically, after splitting the test task into multiple subtasks, the waiting time of each subtask can be timed separately. Further, if target subtask D is not scheduled after exceeding the set waiting time, it is checked whether the resources allocated to target subtask D are in an idle state. If the resources allocated to target subtask D are in an idle state, target subtask D is scheduled to the resources allocated to target subtask D to execute the test cases corresponding to target subtask D using the resources allocated to target subtask D. If the resources allocated to target subtask D are in an occupied state, target subtask D is written to a set second message queue to wait for scheduling.

[0141] To prevent subtasks in the second message queue from starving, the usage status of resources allocated to each subtask of the aforementioned test tasks can be monitored. If idle resources are detected among the resources allocated to the subtasks of the test tasks, a subtask whose allocated resources match the idle resources is searched from the second message queue. Matching the allocated resources with the idle resources specifically means that the resource specifications of the idle resources are the same as the resource specifications allocated to the subtask. Furthermore, the target subtask matching the idle resources can be scheduled to the idle resources. The idle resources can then be used to execute the test cases corresponding to the desired subtasks. This embodiment effectively prevents some subtasks from "starving" due to prolonged lack of scheduling. On the other hand, by dynamically monitoring the resource usage status and promptly scheduling waiting subtasks when idle resources are detected, the overall resource utilization rate is improved, and resource waste is reduced.

[0142] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 1101 and 1102 can be device A; or the execution subject of step 1101 can be device A, and the execution subject of step 1102 can be device B; and so on.

[0143] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 1101, 1102, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0144] Accordingly, embodiments of this application also provide a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause one or more processors to perform the steps in the test task scheduling method provided in the foregoing embodiments.

[0145] Computer-readable storage media include volatile or non-volatile or a combination thereof, and may be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital video disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transfer medium.

[0146] This application also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the test task scheduling method provided in the foregoing embodiments.

[0147] In the embodiments of this application, the specific implementation form of the computer program product is not limited. In some embodiments, the computer program product may be implemented as an application (APP), a mini-program, a computer-side client, a program module, a plug-in, an installation package, a software development kit (SDK), an image file of an optical disc (such as an ISO file), a plug-in, or software in the form of Software as a Service (SaaS), etc., but is not limited to these.

[0148] The computer program product should understand that each or a combination of the above-described method flow can be implemented by a computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above-described method embodiments.

[0149] Figure 12 This is a schematic diagram of the scheduling device provided in an embodiment of this application. Figure 12 As shown, the scheduling device may include a task receiving and decomposition module 12a. The task receiving and decomposition module 12a is used to execute steps 1101-1103 and specific implementations of steps 1101-1103 provided in the foregoing embodiments, including but not limited to: test task receiving, test task storage, and test task decomposition.

[0150] like Figure 12 As shown, the scheduling device may further include a resource allocation and task scheduling module 12b. The resource allocation and task scheduling module 12b is used for resource allocation, specifically executing the steps provided in the foregoing embodiments for allocating resources to the target subtask based on the resource configuration information of the target test task to which the target subtask belongs, and the specific implementation of these steps. The resource allocation and task scheduling module 12b is also used for task scheduling, specifically executing the steps provided in the foregoing embodiments for scheduling the target subtask to the resources allocated to it based on the resource allocation information and task priority in the configuration information of the target test task, and the specific implementation of these steps.

[0151] In some embodiments, the resource allocation and task scheduling module 12b can also obtain the status of the resources allocated to each subtask and update the status of each resource, i.e., "resource status update".

[0152] In some embodiments, the scheduling device may further include a task execution and monitoring module 12c. The task execution and monitoring module 12c is used to schedule resources to execute the assigned target sub-tasks and monitor the execution status of the sub-tasks.

[0153] In some embodiments, the scheduling device may further include an exception handling module 12d. The exception handling module 12d is used to perform recovery processing on subtasks that have been detected as having an exception. For details on how to perform recovery processing on subtasks that have an exception, please refer to the relevant content in the foregoing embodiments, which will not be repeated here.

[0154] Figure 13 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 13As shown, the electronic device includes a memory 13a and a processor 13b. The memory 13a is used to store computer programs and can be configured to store various other data to support operation on a computing platform. Examples of this data include instructions for any application or method used to operate on the electronic device, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0155] Processor 13b is coupled to memory 13a for executing computer programs to perform the steps in the test task scheduling methods provided in the foregoing embodiments. Specific implementation details of each step can be found in the relevant descriptions of the foregoing embodiments, and will not be repeated here.

[0156] In some alternative implementations, such as Figure 13 As shown, the electronic device may also include optional components such as a communication component 13c, a power supply component 13d, a display component 13e, and an audio component 13f. Figure 13 The diagram only shows some components and does not mean that the electronic device must contain them. Figure 13 The inclusion of all components does not imply that an electronic device can only include... Figure 13 The components shown.

[0157] in addition, Figure 13 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the form factor of the electronic device. The electronic device in this embodiment can be a desktop computer, laptop computer, mobile phone, or IoT device; it can also be a traditional server, cloud server, or server cluster, or other server equipment.

[0158] In this embodiment, the memory is used to store computer programs and can be configured to store various other data to support operation on its host device. The processor can execute the computer programs stored in the memory to implement corresponding control logic. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), electrically erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0159] In the embodiments of this application, the processor can be any hardware processing device capable of executing the above-described method logic. Optionally, the processor can be a central processing unit (CPU), a graphics processing unit (GPU), or a microcontroller unit (MCU); it can also be a programmable device such as a field-programmable gate array (FPGA), a programmable array logic (PAL), a general array logic (GAL), or a complex programmable logic device (CPLD); or it can be an advanced RISC machine (ARM) or a system on chip (SoC), etc., but is not limited thereto.

[0160] In this embodiment, the communication component is configured to facilitate wired or wireless communication between its host device and other devices. The device hosting the communication component can access wireless networks based on communication standards, such as 2G or 3G, 4G, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0161] In embodiments of this application, the display component may include a liquid crystal display (LCD) and a touch panel (TP). If the display component includes a touch panel, the display component can be implemented as a touchscreen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0162] In this embodiment, a power supply component is configured to provide power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component resides.

[0163] In embodiments of this application, the audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC), which is configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals. For example, in devices with voice interaction capabilities, voice interaction with the user can be achieved through the audio component.

[0164] It should be noted that the terms "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0165] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the aforementioned element.

[0166] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A test task scheduling method, applicable to any scheduling node in a distributed scheduling system, characterized in that, The method includes: Obtain a test task; the test task includes at least one test suite; Based on the configuration information of the test suite, the test suite is broken down into multiple sub-tasks; among them, test cases corresponding to the same resource allocation strategy under the same test suite are assigned to the same sub-task. The multiple subtasks are sent to the task allocation node so that the task allocation node can allocate the multiple subtasks to multiple scheduling nodes for parallel resource scheduling. For at least one target subtask that is assigned to the same virtual instance, the target subtasks assigned to the same virtual instance are scheduled to the target virtual instance in sequence according to the task priority of the test task to which each target subtask belongs; the target virtual instance refers to the virtual instance to which the target subtasks assigned to the same virtual instance are assigned. In the process of scheduling any target subtask currently scheduled in the target subtasks allocated to the same virtual instance to the target virtual instance, the target subtask is divided into multiple steps according to the resource allocation strategy corresponding to the target test suite corresponding to the target subtask and the environment configuration information of the target test task to which the target subtask belongs. Based on the sequential order of the multiple steps, the multiple steps are scheduled to the target virtual instance in turn, so as to schedule any target subtask to the target virtual instance.

2. The method according to claim 1, characterized in that, The test task includes multiple test suites; The method further includes: Obtain the resource allocation strategies corresponding to the multiple test suites from the configuration information of the test task; The step of breaking down the test suite into multiple sub-tasks based on the configuration information of each test suite includes: Based on the configuration information of the multiple test suites, the test cases contained in each of the multiple test suites are determined from the test tasks; For any test suite, the resource allocation strategy corresponding to the test cases contained in the test suite is determined according to the resource allocation strategy corresponding to the test suite. Test cases corresponding to the same resource allocation strategy under the same test suite are divided into the same subtask to obtain multiple subtasks corresponding to the test task.

3. The method according to claim 1 or 2, characterized in that, The method further includes: Obtain the resource allocation strategy and resource specification information corresponding to the target test task from the configuration information of the target test task to which the at least one target subtask belongs; Based on the resource allocation strategy and resource specification information corresponding to the target test task, resources are allocated to the at least one target sub-task to obtain the resource allocation information of the at least one target sub-task; the resource allocation information includes: the identifier of the virtual instance allocated to the target sub-task; The target subtasks assigned to the same virtual instance are determined based on the identifier of the virtual instance to which the at least one target subtask is assigned.

4. The method according to claim 3, characterized in that, The target test task to which any target subtask belongs includes at least one test suite; the target subtask corresponds to the target test suite in the target test task; The step of allocating resources to any target subtask according to the resource allocation strategy and resource specification information corresponding to the target test task includes: When the resource allocation strategy includes a configuration creation strategy, the resource specification information corresponding to the target test suite is obtained from the resource specification information corresponding to the target test task to which any target subtask belongs; Create a virtual instance based on the resource specifications of the target test suite; Assign any of the target subtasks to the virtual instance.

5. The method according to claim 3, characterized in that, The target test task to which any target subtask belongs includes at least one test suite, and the resource allocation strategy is an inherent virtual instance allocation strategy; any target subtask corresponds to a target test suite in the target test task; Based on the resource configuration information in the configuration information of the target test task to which each of the at least one target subtask belongs, resources are allocated to the at least one target subtask, including: The inherent virtual instance allocation strategy includes: the identifier of the virtual instance specified by each of the at least one test suite included in the target test task; for any target subtask, if the resource allocation strategy corresponding to the target test task to which the target subtask belongs is the inherent virtual instance allocation strategy, the target subtask is allocated to the inherent virtual instance corresponding to the identifier of the virtual instance specified by the target test suite. or, The inherent virtual instance allocation strategy includes: resource specification information corresponding to at least one test suite included in the target test task; when the resource allocation strategy corresponding to the target test task to which any target subtask belongs is the inherent virtual instance allocation strategy, the target subtask is allocated to an inherent virtual instance whose resource specification information is adapted to the target test suite.

6. The method according to claim 1 or 2, characterized in that, The step of scheduling the target subtasks assigned to the same virtual instance sequentially to the target virtual instance according to the task priority of the test task to which each target subtask belongs includes: The execution order of the target subtasks assigned to the same virtual instance is determined based on the task priority of the test task to which each target subtask belongs. Based on the execution order, establish a linked list of target subtasks assigned to the same virtual instance; According to the linked list, the target subtasks assigned to the same virtual instance are sequentially scheduled to the target virtual instance.

7. The method according to claim 6, characterized in that, Before sequentially scheduling the target subtasks assigned to the same virtual instance to the target virtual instance according to the linked list, the method further includes: The linked list is stored in a memory-based data structure storage system; When the target virtual instance is idle, the linked list is read from the data structure storage system.

8. The method according to claim 1 or 2, characterized in that, Before sequentially scheduling the multiple steps onto the target virtual instance according to their order, the method further includes: The multiple steps are sent to the corresponding task allocation node so that the task allocation node can allocate the multiple steps to the multiple scheduling nodes; For any one of the plurality of scheduling nodes, the step of sequentially scheduling the plurality of steps to the target virtual instance according to the order of the plurality of steps includes: In response to the triggering operation of the task allocation node, the step allocated by any scheduling node is scheduled to the target virtual instance; the task allocation node triggers the multiple scheduling nodes to perform resource scheduling for the multiple steps in the order of the multiple steps, so that the multiple scheduling nodes can schedule the multiple steps to the same virtual instance in the order of the multiple steps.

9. The method according to claim 1 or 2, characterized in that, Also includes: Get the execution status of any target subtask; If the execution status of any of the target subtasks is abnormal, then the target test case that the test case corresponding to any target subtask depends on is determined. The resources of any target subtask and the subtask corresponding to the target test case are rescheduled so that the rescheduled resources are used to execute the target test case and the test case corresponding to any target subtask in sequence.

10. The method according to claim 1 or 2, characterized in that, Also includes: For any target subtask, if the target subtask has not been scheduled after a set waiting time, then query whether the resources allocated to the target subtask are in an idle state. If the resources allocated to any of the target subtasks are occupied, write the target subtasks into the designated message queue. If it is detected that there are idle resources among the resources allocated to the subtasks of the multiple test tasks, the subtask whose allocated resources match the idle resources is searched from the message queue. The subtasks adapted to the idle resources are scheduled to the idle resources so as to execute the test cases corresponding to the subtasks adapted to the idle resources.

11. A distributed scheduling system, characterized in that, include: Multiple scheduling nodes and task allocation nodes; The plurality of scheduling nodes are used to execute the steps in the method according to any one of claims 1-10; The task allocation node is used to allocate the test task into multiple subtasks to the multiple scheduling nodes. The multiple scheduling nodes are also used to perform parallel resource scheduling on the multiple subtasks.

12. An electronic device, characterized in that, include: A memory and a processor; wherein the memory is used to store computer programs; The processor is coupled to the memory for executing the computer program to perform the steps of the method according to any one of claims 1-10.

13. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed by one or more processors, the one or more processors are caused to perform the steps of the method according to any one of claims 1-10.

14. A computer program product, characterized in that, Includes a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps of the method according to any one of claims 1-10.

Images