An automated test scheduling method, apparatus, device and storage medium

Abstract

The application provides an automatic test scheduling method and device, equipment and a storage medium. A test task is acquired, a task description file is generated according to the test task and is stored in a scanning physical directory, when node load of at least one execution node meets a load condition, the test task is executed by the execution node using the task description file by scanning the scanning physical directory, and when the execution node meets the load condition, the test task is autonomously scanned instead of being passively received, so that even if the amount of test tasks increases sharply, the test task can still be executed without being blocked and affecting other test tasks. In the case of executing the test task, the execution state of the test task is determined, the task description file is dynamically moved to a corresponding pre-built physical directory according to the execution state, the task description file is dynamically stored in the scanning physical directory and the pre-built physical directory corresponding to the execution state, and the execution node is decoupled, so that even if the execution node fails at different time nodes during task execution, the test task is not lost.

Description

Technical Field

[0001] This application relates to the field of testing, and more particularly to an automated test scheduling method, apparatus, device, and storage medium. Background Technology

[0002] In automated testing within a continuous integration / continuous delivery (CI / CD) environment, task scheduling is a critical step. Existing mainstream testing frameworks (such as Jenkins) typically employ a centralized scheduling model, where a master node maintains a task queue in memory, responsible for receiving task requests, queuing them, and distributing tasks to execution nodes. This approach has the following drawbacks: all test tasks to be executed are stored together in the execution node's memory queue. If the execution node crashes, restarts, or experiences a network partition, all queued tasks in memory will be lost, leading to test interruption and difficulty in recovery. Furthermore, task generation and execution are tightly coupled within a single thread. When the number of test tasks surges, the execution node's scheduling thread may become overwhelmed and blocked, affecting the responsiveness of the entire CI / CD system and even preventing other build tasks from triggering correctly. Summary of the Invention

[0003] This application provides an automated test scheduling method, apparatus, device, and storage medium to solve at least one problem existing in related technologies. The technical solution is as follows: In a first aspect, embodiments of this application provide a method for automated test scheduling, including: Obtain test tasks; A task description file is generated based on the test task, and the task description file is stored in the scanned physical directory; When it is determined that the node load of at least one execution node meets the load condition, the physical directory to be scanned is scanned through the execution node, and the test task is executed using the task description file; When executing the test task, determine the execution status of the test task, and dynamically move the task description file to the corresponding pre-built physical directory according to the execution status.

[0004] In one implementation, generating a task description file based on the test task includes: Based on the test task, determine the test parameters required for the test task; The test parameters are serialized and encapsulated to generate a task description file in a specified format.

[0005] In one implementation, when it is determined that the node load of at least one execution node meets the load condition, scanning the physical directory through the execution node includes: Determine the load parameters of at least one of the execution nodes, and determine the node load of the corresponding execution node based on the load parameters, wherein the load parameters include at least one of CPU utilization, memory usage, and the number of available test devices; The node load is compared with the load conditions to determine the execution node that meets the load conditions; The physical directory is scanned by the execution node that meets the load conditions.

[0006] In one implementation, the step of scanning the physical directory through the execution node and executing the test task using the task description file includes: The execution node scans the physical directory to determine whether the task description file exists in the physical directory. When there is only one task description file, the test task is executed using the task description file. When there are multiple task description files, the task priority contained in the test parameters of each task description file is read, and the test task is executed using the task description file with the highest task priority.

[0007] In one embodiment, the method further includes: If the test parameters in the task description file contain a parent test task field, scan the completed physical directory corresponding to the completed execution status to see if there is a parent task description file corresponding to the parent test task field, and the pre-built physical directory includes the completed physical directory; If it exists, and the number of task description files is one, the test task is executed using the task description file; If it exists, and there are multiple task description files, the test task is executed using the task description file that has the parent task description file corresponding to the parent test task field and has the highest task priority.

[0008] In one implementation, dynamically moving the task description file to the corresponding pre-built physical directory based on the execution state includes: When the execution status is "Executing", the task description file is dynamically moved to the "Processing" directory; When the execution status is "execution completed", the task description file is dynamically moved from the processing directory to the completed physical directory; When the execution status is failure, the task description file is dynamically moved from the processing directory to the failure physical directory; The pre-built physical directory includes the processing directory, the completed physical directory, and the failed physical directory.

[0009] In one embodiment, the method further includes: Scan the failed physical directory; if the task description file exists, read the number of retries contained in the test parameters of the task description file. Based on the number of retries, the priority of the task is increased to obtain a new task description file, which is then stored in the scanned physical directory.

[0010] Secondly, embodiments of this application provide an automated test scheduling device, comprising: The acquisition module is used to acquire test tasks; The storage module is used to generate a task description file based on the test task and store the task description file in the scanned physical directory; An execution module is used to determine that when the node load of at least one execution node meets the load condition, scan the scanned physical directory through the execution node and execute the test task using the task description file; The moving module is used to determine the execution status of the test task when the test task is being executed, and dynamically move the task description file to the corresponding pre-built physical directory according to the execution status.

[0011] In one implementation, the execution module is further configured to: If the test parameters in the task description file contain the parent test task field, scan the completed physical directory corresponding to the completed execution status to see if there is a parent task description file corresponding to the parent test task field. The pre-built physical directory includes the completed physical directory. If it exists, and there is only one task description file, the test task will be executed using the task description file; If it exists, and there are multiple task description files, the test task will be executed using the parent task description file that corresponds to the parent test task field and has the highest task priority.

[0012] In one implementation, the execution module is further configured to: Scan the failed physical directories, and if a task description file exists, read the number of retries contained in the test parameters of the task description file; Based on the number of retries, the task priority is increased, a new task description file is obtained, and the new task description file is stored in the scanned physical directory.

[0013] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory, wherein the memory stores instructions that are loaded and executed by the processor to implement the methods in any of the above-described embodiments.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed, implements the methods in any of the above-described embodiments.

[0015] The beneficial effects of the above technical solution include at least the following: By acquiring test tasks, generating task description files based on the test tasks, and storing the task description files in the scanned physical directory, and determining that the node load of at least one execution node meets the load condition, the execution node scans the scanned physical directory and executes the test tasks using the task description files. The execution node autonomously scans and executes test tasks when it meets the load condition, rather than passively receiving them. Even if the number of test tasks surges, it can avoid blocking and affecting other test tasks. When executing test tasks, the execution status of the test tasks is determined. Based on the execution status, the task description files are dynamically moved to the corresponding pre-built physical directory. By dynamically storing the task description files in the scanned physical directory and the pre-built physical directory corresponding to the execution status, the task description files are decoupled from the execution nodes. Even if the execution node fails at different points in the execution of the task, the test tasks will not be lost.

[0016] The above overview is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, these aspects, embodiments, and features will become readily apparent from the accompanying drawings and the following detailed description. Attached Figure Description

[0017] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in this application and should not be construed as limiting the scope of this application.

[0018] Figure 1 This is a flowchart illustrating the steps of an embodiment of the automated test scheduling method of this application; Figure 2 This is a structural block diagram of an automated test scheduling device according to an embodiment of this application; Figure 3 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0019] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0020] Reference Figure 1 The flowchart illustrates an embodiment of an automated test scheduling method according to this application. The automated test scheduling method may include at least steps S100-S400: S100, Obtain test tasks.

[0021] S200. Generate a task description file based on the test task and store the task description file in the scan physical directory.

[0022] S300. When it is determined that the node load of at least one execution node meets the load condition, the execution node scans the physical directory and executes the test task using the task description file.

[0023] S400. When executing a test task, determine the execution status of the test task and dynamically move the task description file to the corresponding pre-built physical directory according to the execution status.

[0024] The technical solution of this application embodiment obtains test tasks, generates task description files based on the test tasks, and stores the task description files in a scanned physical directory. When it is determined that the node load of at least one execution node meets the load condition, the execution node scans the scanned physical directory and executes the test tasks using the task description files. The execution node autonomously scans and executes test tasks when it meets the load condition, rather than passively receiving them. Even if the number of test tasks surges, it can avoid blocking and affecting other test tasks. When executing test tasks, the execution status of the test tasks is determined. Based on the execution status, the task description files are dynamically moved to the corresponding pre-built physical directory. The task description files are dynamically stored in the scanned physical directory and the pre-built physical directory corresponding to the execution status, which is decoupled from the execution nodes. Even if the execution nodes fail at different time points during the execution of the task, the test tasks will not be lost.

[0025] It should be noted that the test object of the test task is not specifically limited, including but not limited to software, firmware, devices, etc. When a requirement to trigger testing is received for the object to be tested, a test task is generated based on the requirement, that is, a corresponding test task is obtained.

[0026] In one implementation, step S200 includes steps S210-S220: S210. Based on the test task, determine the test parameters required for the test task.

[0027] Optionally, after determining the test task, the system analyzes the test task to determine the required test parameters. It should be noted that the test parameters include, but are not limited to, the storage path, version number, board type, test case set to be executed, and test task ID of the object under test. The test case set to be executed is used to test the object under test. In some embodiments, the test parameters may also include task priority, parent test task field, and retry count.

[0028] S220. Serialize and encapsulate the test parameters to generate a task description file in the specified format.

[0029] Optionally, after determining all test parameters, the test parameters are serialized and encapsulated to generate a task description file in a specified format. This task description file is globally unique, and its filename may contain timestamps, hash codes, etc. The specified format may be JSON (JavaScript Object Notation), and in other embodiments, it may be other formats such as AML, XML, etc., without specific limitations.

[0030] In this embodiment, a Scan Directory and several pre-built physical directories are pre-constructed in the system, including but not limited to a Processing Directory, a Completed Directory, and a Failed Directory. These directories are used to store task description files corresponding to test tasks to be executed, test tasks being executed by execution nodes, completed test tasks, and failed test tasks, respectively. In some embodiments, the pre-built physical directories may further include a Suspended Physical Directory and a Cancelled Physical Directory, used to store task description files corresponding to temporarily suspended test tasks and canceled test tasks, respectively.

[0031] It should be noted that these different physical directories represent different stages of the test task lifecycle, thus being equivalent to "heterogeneous" physical directories. The system will atomically move the task description file between these directories based on the execution state of the test task. The transition of the task state does not depend on the database or memory markers. This mechanism ensures that the execution state is clear and persistent at any time. Even if the entire scheduling system crashes and restarts, the state of all test tasks can be restored without loss simply by using the directory where the task description file is located.

[0032] Optionally, after generating a task description file in a specified format, the task description file can be automatically stored in the scanned physical directory using atomic operations (such as the `mv` command). This allows the execution nodes to perform scans autonomously, rather than passively receiving and executing the task description file, thus preventing blockages. For example, a daemon process (Watcher) runs on each execution node. This daemon process no longer passively waits for the master node to dispatch tasks but actively and periodically scans the scanned physical directory to check for the presence of the task description file and determine whether a test task needs to be executed using the task description file.

[0033] It should be noted that physical directories include, but are not limited to, folders, block device partitions, buckets, and other objects with storage functions; specified formats include, but are not limited to, JSON, YAML, and XML; execution nodes include, but are not limited to, objects with data processing capabilities such as terminals, physical servers, and virtual machines, without specific limitations.

[0034] In one implementation, step S300, when it is determined that the node load of at least one execution node meets the load condition, scans the physical directory through the execution node, including steps S310-S330: S310. Determine the load parameters of at least one execution node, and determine the node load of the corresponding execution node based on the load parameters.

[0035] Optionally, the load parameters include at least one of CPU utilization, memory usage, and the number of available test devices. In some embodiments, network I / O and disk I / O may also be included. In this embodiment, before scanning the physical directory, the daemon process of the execution node can determine its own load parameters and determine the node load of the corresponding execution node based on the load parameters.

[0036] S320. Compare the node load with the load conditions to determine the execution node that meets the load conditions.

[0037] Optionally, CPU utilization, memory usage, and the number of available test devices can be used as node load, and then compared with the condition thresholds corresponding to CPU utilization, memory usage, and the number of available test devices, respectively. If all conditions are met, the execution node is considered to meet the load conditions. Alternatively, CPU utilization, memory usage, and the number of available test devices can be normalized, and then the normalization results and their corresponding weights can be used to obtain a weighted result. The weighted result is then compared with the condition thresholds. If the condition thresholds are met, the execution node is considered to meet the load conditions.

[0038] S330. Scan the physical directory by using the execution nodes that meet the load conditions.

[0039] Optionally, if only one execution node meets the load condition, then that execution node is used to scan the physical directory; if multiple execution nodes meet the load condition, then one execution node is randomly selected or the execution node with the lowest load represented by the weighted result is used to scan the physical directory.

[0040] In this embodiment of the application, step S300 involves scanning the physical directory by executing the node and performing a test task using the task description file, including steps S340-S360: S340. By executing the node to scan the physical directory, determine whether a task description file exists in the physical directory.

[0041] Optionally, the physical directory to be scanned is scanned through the execution nodes determined above, thereby determining whether a task description file exists in the physical directory to be scanned.

[0042] S350. When there is only one task description file, execute the test task using the task description file.

[0043] Optionally, if there is only one task description file, the test task can be executed directly using the task description file.

[0044] S360. When there are multiple task description files, read the task priority contained in the test parameters of each task description file, and use the task description file with the highest task priority to execute the test task.

[0045] Optionally, when there are multiple task description files, and assuming that the test parameters do not include the parent test task field and the number of retries, then: 1. If the test parameters include task priorities, then read the task priorities contained in the task description files and execute the test task using the task description file with the highest priority. If two or more task description files have the same task priority, then the test task can be executed using the task description file with the earlier timestamp, based on the timestamp contained in the filename.

[0046] 2. If the test parameters do not include task priority, then the test task can be executed using the task description file with the earlier timestamp, based on the timestamp contained in the task description file's filename.

[0047] In this embodiment of the application, steps S301-S303 are also included: S301. If the test parameters in the task description file contain the parent test task field, scan the completed physical directory corresponding to the completed execution status to see if there is a parent task description file corresponding to the parent test task field.

[0048] Optionally, if the test parameters in the task description file include a parent test task field (e.g., parent test task ID), it means that the test task corresponding to this task description file depends on the preceding test task, i.e., the parent test task. The current test task can only proceed after the parent test task is completed. Therefore, it is necessary to scan the completed physical directory corresponding to the completed tasks with the execution status "completed" to see if the parent task description file corresponding to the parent test task field exists. If not, it means that the parent test task has not yet been completed, and the task description file corresponding to the current test task will not be executed; other task description files will be executed first. If it exists, it means that the parent test task has been completed. Therefore, through the design of this physical directory and the mechanism of the parent test task field, the dependency problem of test tasks can be solved simply and quickly.

[0049] S302. If it exists, and there is only one task description file, execute the test task using the task description file.

[0050] Optionally, if a parent task description file corresponding to the parent test task field exists, and if the number of task description files in the scanned physical directory is one, the test task is executed using the task description file.

[0051] S303. If it exists, when there are multiple task description files, use the task description file with the highest priority that corresponds to the parent task description file of the parent test task field to execute the test task.

[0052] Optionally, assuming that there is no retry count in the test parameters, if there is a parent task description file corresponding to the parent test task field, and if there are multiple task description files, the test task is executed using the task description file with the highest priority that has a parent task description file corresponding to the parent test task field.

[0053] It should be noted that if the test parameters include a parent test task field, and there are multiple scan physical directories in the scan physical directory, if the case of step S360 is involved, that is, if there is a parent task description file corresponding to the parent test task field in the completed physical directory corresponding to the scan execution status of completion, then there are multiple task description files in the scan physical directory and all of them can be executed. In this case, the logic of S360 is followed to determine which one to use to execute the test task from each task description file.

[0054] In this embodiment of the application, when executing a test task, each execution node can automatically determine the execution status of the test task based on the progress of the test task.

[0055] In one implementation, step S400 involves dynamically moving the task description file to the corresponding pre-built physical directory based on the execution status, including steps S410-S430: S410. When the execution status is "running", dynamically move the task description file to the processing directory.

[0056] Optionally, when the execution status is "in execution", the execution node will dynamically move the task description file to the processing directory.

[0057] S420. When the execution status is "execution completed", the task description file is dynamically moved from the processing directory to the completed physical directory.

[0058] Optionally, when the execution status is "execution completed", the execution node will dynamically move the task description file from the processing directory to the completed physical directory.

[0059] S430. When the execution status is failure, dynamically move the task description file from the processing directory to the failure physical directory.

[0060] Optionally, when the execution status is failed, the execution node will dynamically move the task description file from the processing directory to the failed physical directory.

[0061] In one embodiment, the automated test scheduling method of this application may further include steps S510-S520: S510. Scan the failed physical directories. If a task description file exists, read the number of retries contained in the test parameters of the task description file.

[0062] Optionally, the execution node will periodically (e.g., at a preset time) scan the failed physical directory. If a task description file exists in the failed physical directory, it will read the number of retries contained in the test parameters of the task description file.

[0063] S520. Based on the number of retries, the task priority is increased to obtain a new task description file, which is then stored in the scanned physical directory.

[0064] Optionally, each time a task description file is added to the failed physical directory, the retry count (retry_count) is incremented by 1, and the task priority is increased based on the retry count. For example, for a task description file with a retry count greater than 0, its original task priority is increased by one level to obtain a new task priority for determining the new task description file. Alternatively, the task priority can be updated based on the specific size of the retry count, so that the larger the retry count, the higher the level increase from the original task priority, resulting in a new task priority for determining the new task description file. Finally, after obtaining the new task description file, it is stored again in the scanned physical directory for subsequent re-execution. Therefore, through the task priority mechanism and the task priority adjustment mechanism, "backpressure" control and intelligent scheduling based on resource availability are achieved.

[0065] The embodiments of this application can achieve at least the following effects: 1. Significantly improve system reliability: The queue, similar to test tasks, is persistently stored in the physical directory, which completely solves the problem of test task loss caused by scheduling node failure and achieves lossless recovery of task status; 2. Achieve complete decoupling and non-blocking: The generator of test tasks and the execution of test tasks (execution node) communicate asynchronously, are independent of each other, and do not block each other, thereby improving the overall throughput and responsiveness of the system and overcoming the drawback of centralized scheduling being prone to blocking.

[0066] 3. Supports flexible scheduling strategies: Based on task priority analysis, parent test task field dependency analysis, and retry count analysis of test parameters in the task description file, it can realize complex and dynamic scheduling logic, breaking the rigid limitations of FIFO queues.

[0067] 4. Achieve intelligent load balancing: Execution nodes actively scan and pull test tasks based on their own load, achieving natural load balancing and backpressure control, optimizing resource utilization, and avoiding blocking and affecting other test tasks even if the number of test tasks surges.

[0068] Reference Figure 2 The diagram shows a structural block diagram of an automated test scheduling device according to an embodiment of this application. The device may include: The acquisition module is used to acquire test tasks; The storage module is used to generate task description files based on test tasks and store the task description files in the scanned physical directory; The execution module is used to determine that when the node load of at least one execution node meets the load condition, it scans the physical directory of the execution node and executes the test task using the task description file. The move module is used to determine the execution status of a test task when it is being executed, and dynamically move the task description file to the corresponding pre-built physical directory based on the execution status.

[0069] In one implementation, the execution module is further configured to: If the test parameters in the task description file contain the parent test task field, scan the completed physical directory corresponding to the completed execution status to see if there is a parent task description file corresponding to the parent test task field. The pre-built physical directory includes the completed physical directory. If it exists, and there is only one task description file, the test task will be executed using the task description file; If it exists, and there are multiple task description files, the test task will be executed using the parent task description file that corresponds to the parent test task field and has the highest task priority.

[0070] In one implementation, the execution module is further configured to: Scan the failed physical directories, and if a task description file exists, read the number of retries contained in the test parameters of the task description file; Based on the number of retries, the task priority is increased, a new task description file is obtained, and the new task description file is stored in the scanned physical directory.

[0071] The functions of each module in the device of this application embodiment can be found in the corresponding description in the above method, and will not be repeated here.

[0072] Reference Figure 3 The diagram illustrates a structural block diagram of an electronic device according to an embodiment of this application. The electronic device includes a memory 310 and a processor 320. The memory 310 stores instructions that can be executed on the processor 320. The processor 320 loads and executes these instructions to implement the automated test scheduling method described in the above embodiment. The number of memories 310 and processors 320 can be one or more.

[0073] In one embodiment, the electronic device further includes a communication interface 330 for communicating with external devices and exchanging data. If the memory 310, processor 320, and communication interface 330 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0074] Optionally, in a specific implementation, if the memory 310, processor 320 and communication interface 330 are integrated on a single chip, the memory 310, processor 320 and communication interface 330 can communicate with each other through an internal interface.

[0075] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the automated test scheduling method provided in the above embodiments.

[0076] This application also provides a chip, which includes a processor for calling and executing instructions stored in a memory, causing a communication device on which the chip is installed to perform the method provided in this application.

[0077] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0078] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting the Advanced Reduced Instruction Set Computing (RISC) machine (ARM) architecture.

[0079] Further, optionally, the aforementioned memory may include read-only memory and random access memory, and may also include non-volatile random access memory. The memory may be volatile or non-volatile, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0080] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0081] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0082] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0083] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0084] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0085] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0086] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0087] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An automated test scheduling method, characterized in that, include: Obtain test tasks; A task description file is generated based on the test task, and the task description file is stored in the scanned physical directory; When it is determined that the node load of at least one execution node meets the load condition, the physical directory to be scanned is scanned through the execution node, and the test task is executed using the task description file; When executing the test task, determine the execution status of the test task, and dynamically move the task description file to the corresponding pre-built physical directory according to the execution status.

2. The automated test scheduling method according to claim 1, characterized in that: The step of generating a task description file based on the test task includes: Based on the test task, determine the test parameters required for the test task; The test parameters are serialized and encapsulated to generate a task description file in a specified format.

3. The automated test scheduling method according to claim 2, characterized in that: When it is determined that the node load of at least one execution node meets the load condition, scanning the physical directory through the execution node includes: Determine the load parameters of at least one of the execution nodes, and determine the node load of the corresponding execution node based on the load parameters, wherein the load parameters include at least one of CPU utilization, memory usage, and the number of available test devices; The node load is compared with the load conditions to determine the execution node that meets the load conditions; The physical directory is scanned by the execution node that meets the load conditions.

4. The automated test scheduling method according to claim 2 or 3, characterized in that: The step of scanning the physical directory through the execution node and executing the test task using the task description file includes: The execution node scans the physical directory to determine whether the task description file exists in the physical directory. When there is only one task description file, the test task is executed using the task description file. When there are multiple task description files, the task priority contained in the test parameters of each task description file is read, and the test task is executed using the task description file with the highest task priority.

5. The automated test scheduling method according to claim 4, characterized in that: The method further includes: If the test parameters in the task description file contain a parent test task field, scan the completed physical directory corresponding to the completed execution status to see if there is a parent task description file corresponding to the parent test task field. The pre-built physical directory includes the completed physical directory. If it exists, and the number of task description files is one, the test task is executed using the task description file; If it exists, and there are multiple task description files, the test task is executed using the task description file that has the parent task description file corresponding to the parent test task field and has the highest task priority.

6. The automated test scheduling method according to claim 4, characterized in that: The step of dynamically moving the task description file to the corresponding pre-built physical directory according to the execution status includes: When the execution status is "Executing", the task description file is dynamically moved to the "Processing" directory; When the execution status is "execution completed", the task description file is dynamically moved from the processing directory to the completed physical directory; When the execution status is failure, the task description file is dynamically moved from the processing directory to the failure physical directory; The pre-built physical directory includes the processing directory, the completed physical directory, and the failed physical directory.

7. The automated test scheduling method according to claim 6, characterized in that: The method further includes: Scan the failed physical directory; if the task description file exists, read the number of retries contained in the test parameters of the task description file. Based on the number of retries, the priority of the task is increased to obtain a new task description file, which is then stored in the scanned physical directory.

8. An automated test scheduling device, characterized in that, include: The acquisition module is used to acquire test tasks; The storage module is used to generate a task description file based on the test task and store the task description file in the scanned physical directory; An execution module is used to determine that when the node load of at least one execution node meets the load condition, scan the physical directory through the execution node and execute the test task using the task description file; The moving module is used to determine the execution status of the test task when the test task is being executed, and dynamically move the task description file to the corresponding pre-built physical directory according to the execution status.

9. An electronic device, characterized in that, include: A processor and a memory, wherein instructions are stored in the memory and loaded and executed by the processor to implement the method as claimed in any one of claims 1-7.

10. A computer-readable storage medium storing a computer program therein, which, when executed, implements the method as described in any one of claims 1-7.

Images