CN112540914A - Execution method, execution device, server and storage medium for unit test - Google Patents

Abstract

The present application discloses a unit test execution method, execution device, server and storage medium, and relates to the field of deep learning. The specific implementation scheme is: obtaining a task queue; wherein the task queue includes multiple unit test tasks; performing task scheduling on multiple unit test tasks in the task queue to determine the target test task to be executed; querying the history of the target test task The execution information is used to determine the first device that fails to execute the target test task; and the second device other than the first device in the device set is scheduled to execute the target test task. Therefore, the method can effectively improve the execution efficiency of the unit test, improve the resource utilization rate, and improve the development efficiency of the developer.

Description

Unit test execution method, execution device, server and storage medium

technical field

The present application relates to the field of computers, in particular to the field of deep learning, and in particular to a unit test execution method, execution device, server and storage medium.

Background technique

During the development of large-scale software projects, in order to ensure software quality, developers will develop a large number of test programs to test whether the functions are normal, that is, unit tests. Under normal circumstances, the code volume of unit tests will account for more than 50% of the total code volume. As the project progresses, the number of unit tests will increase. Therefore, how to complete unit testing quickly and efficiently is very important.

SUMMARY OF THE INVENTION

The present application provides a unit test execution method, execution device, server and storage medium.

According to an aspect of the present application, a method for executing a unit test is provided, comprising:

Obtain a task queue; wherein, the task queue includes multiple unit test tasks;

performing task scheduling on a plurality of unit test tasks in the task queue to determine the target test task to be executed;

query the historical execution information of the target test task to determine the first device that fails to execute the target test task;

A second device other than the first device in the device set is scheduled to execute the target test task.

According to another aspect of the present application, a unit test execution device is provided, comprising:

an acquisition module for acquiring a task queue; wherein, the task queue includes a plurality of unit test tasks;

a scheduling module, configured to perform task scheduling on a plurality of unit test tasks in the task queue to determine the target test task to be executed;

a query module, configured to query the historical execution information of the target test task to determine the first device that fails to execute the target test task;

An execution module, configured to schedule a second device in the device set other than the first device to execute the target test task.

According to another aspect of the present application, a server is provided, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the above-described execution method.

According to another aspect of the present application, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause the computer to execute the above execution method.

Other effects of the above-mentioned optional manners will be described below with reference to specific embodiments.

Description of drawings

The accompanying drawings are used for better understanding of the present solution, and do not constitute a limitation to the present application. in:

1 is a schematic flowchart of a method for executing a unit test provided according to an embodiment of the present application;

2 is a schematic flowchart of a unit test execution method provided according to an embodiment of the present application;

3 is a schematic flowchart of a method for executing a unit test provided according to another embodiment of the present application;

4 is a schematic structural diagram of a unit test execution device provided according to an embodiment of the present application;

FIG. 5 is a block diagram of a server of a unit test execution method according to an embodiment of the present application.

Detailed ways

Exemplary embodiments of the present application are described below with reference to the accompanying drawings, which include various details of the embodiments of the present application to facilitate understanding, and should be considered as exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and constructions are omitted from the following description for clarity and conciseness.

The following describes the execution method, execution device, server, and storage medium of a unit test according to the embodiments of the present application with reference to the accompanying drawings.

Before describing the execution method of the unit test of the present application, the unit test will be described first.

During the development of large-scale software projects, in order to ensure software quality, developers will develop a large number of test programs to test whether the functions are normal, that is, unit tests. Especially in the open source community that is coordinated by many people, there are many developers and a huge amount of code. At this time, unit testing has become an important means to ensure software quality and an indispensable part of the continuous integration process.

Usually, the unit test code will account for more than 50% of the total code. As the project progresses, the number of unit tests will increase, and the time required to pass all unit tests will become longer and longer. If not controlled, inefficient unit testing will greatly restrict the development efficiency of developers.

In addition to the surge in the number of unit tests, some random errors that do not affect the correctness of the program are generated during the execution of unit tests. The reasons include: excessive concurrency, leading to memory overflow; insufficient disk space; network interruption; unfixed execution order of unit tests, etc. Although these errors will not affect the correctness of the program, they will cause the unit testing process to fail, which in turn causes the developer to re-execute the unit testing process. As the number of unit tests increases, more resources are required and the probability of random errors increases. This wastes a lot of hardware resources and valuable developer time.

To this end, the present application proposes a new unit test execution method, which can effectively improve the unit test execution efficiency, the resource utilization rate, and the developer's development efficiency.

FIG. 1 is a schematic flowchart of a method for executing a unit test according to an embodiment of the present application.

The unit test execution method of the embodiment of the present application may be executed by the unit test execution apparatus provided by the embodiment of the present application, and the apparatus may be configured in a server.

As shown in FIG. 1, the execution method of the unit test according to the embodiment of the present application includes:

Step S101, acquiring a task queue; wherein, the task queue includes a plurality of unit test tasks.

Understandably, each unit test task has a unit test name, commands that need to be executed, probability of random errors on the device, etc.

As an achievable way to obtain the task queue, the server first obtains the probability of random errors occurring on the device for each unit test task, and then, according to the probability of random errors occurring on the device for each unit test task, analyzes all unit test tasks. Sort to form the task queue. For example, a unit test with a high probability of random errors can be set higher priority, so that the unit test with a high probability of random errors will be executed first.

It should be noted that if there are multiple unit tests with the same probability of occurrence of random errors, the unit test tasks can be queued from high to low priority according to the sequence of program execution, so as to execute the unit test tasks in sequence.

Step S102: Perform task scheduling on a plurality of unit test tasks in the task queue to determine target test tasks to be executed.

That is, the server schedules a unit test task from the task queue, such as the unit test task with the highest priority, as the target test task to be executed.

Step S103, query the historical execution information of the target test task to determine the first device that fails to execute the target test task.

Wherein, the historical execution information may include the historical execution times and the first device that failed the historical task execution, that is, the device that has executed the target test task several times before executing the target test task this time and failed to execute the target test task.

In this embodiment, after determining the target test task to be executed, the server determines whether the target test task has failed to be executed, and if the execution fails, acquires the first device that failed to execute the target test task.

Step S104 , schedule the second device other than the first device in the device set to execute the target test task.

In this embodiment, in order to minimize the possibility of the target test task failing again, the server selects a new device (a second device other than the first device in the device set) to execute the target test task when re-executing the target test task Test tasks, namely failure retry mechanism and multi-machine parallel mechanism. Among them, the failure retry mechanism can reduce the probability of random errors in unit testing tasks, improve resource utilization, and improve the development efficiency of developers; the multi-machine parallel mechanism can improve the execution speed of unit testing, thereby improving unit testing. The execution efficiency improves the development efficiency of developers.

The unit test execution method of the embodiment of the present application first acquires a task queue including multiple unit test tasks, and performs task scheduling on the multiple unit test tasks in the task queue to determine the target test task to be executed, and then queries the target test task. The historical execution information of the test task is used to determine the first device that fails to execute the target test task, and finally the second device other than the first device in the device set is scheduled to execute the target test task. Therefore, the method can effectively improve the execution efficiency of the unit test, improve the resource utilization rate, and improve the development efficiency of the developer.

In order to shorten the time-consuming of unit testing, further improve the execution efficiency of unit testing, improve resource utilization, and improve the development efficiency of developers, in an example of this application, as shown in FIG. 2 , in the above step S104, a set of devices is scheduled After the second device other than the first device performs the target test task, it also includes:

Step S201, in the case that the second device fails to execute the target test task, update the number of failures in the historical execution information.

In this embodiment, after the server schedules the second device other than the first device in the device set to execute the target task, the second device executes the target test task, and if the second device fails to execute the target test task, the historical execution information The number of failures is superimposed by 1, that is, the number of failures in the historical execution information of the target test task is updated.

After updating the number of failures in the historical execution information of the target test task, determine the relationship between the number of failures after the update and the number of times threshold, and if the number of times of failure after the update is less than the number of times threshold, execute step S202; after the update If the number of failures is greater than or equal to the number threshold, step S203 is executed.

Wherein, in order to minimize the possibility that the unit test fails to be executed again, in this embodiment of the present application, the number of times threshold is less than or equal to the total number of devices in the device set. Specifically, if a target test task fails on a device, it may be a problem with the device itself, such as a network interruption. Due to the network interruption, it may not recover in a short time, then the target test task fails to execute again on this device. The probability will be higher than other devices. In order to minimize the possibility that the target test task fails to be executed again, a new device will be selected to execute the target test task when the target test task is re-executed. Therefore, in the embodiment of the present application, the number of times threshold is set to be less than or Equal to the total number of devices in the device collection.

Step S202, adding the target test task to the task queue, and adding the second device to the device list of failed devices in the historical execution information.

As an achievable way of adding the target test task to the task queue, it includes: configuring the priority of the target detection task according to the updated number of failures; adding the target test task to the corresponding position of the task queue according to the priority .

It should be noted that the relationship between the number of failures and the priority of the target test task may be acquired in advance and stored in the server. Assume that the maximum priority is 1, and the higher the value, the lower the priority. When the number of failures is 1, the priority of the target test task is the quotient obtained by dividing the number of unit test tasks included in the current task queue by 2 and then rounded up (you can also add or subtract the preset value based on the rounding, such as The value of 1) is roughly the position in the middle of the task queue; when the number of failures is 2, the priority of the target test task is the number of unit test tasks included in the current task queue, and the position at the end of the task queue has the lowest priority.

In this embodiment, when the second device in the device set, such as Host1, fails to execute for the first time, the server adds the second device, such as Host1, to the device list of the failed devices in the historical execution information, as the execution of the unit test The first device that fails the task, and adjust the priority of the failed unit test task, and adjust it to roughly the middle of the task queue; if the second device in the device set, such as Host2, fails to execute the second time, the first device The second device, such as Host2, is added to the device list of the failed device in the historical execution information, and it is also regarded as the first device that failed to execute the unit test, and the priority of the failed unit test task is adjusted to the end of the task team. In this way, tasks with different failure times can be arranged in different positions in the task queue, avoiding the concentration of wrong unit test tasks in the queue, and reducing the mutual interference between different unit test tasks.

As an achievable way to configure the priority of the target test task according to the updated number of failures, it includes: determining the corresponding priority value range according to the updated number of failures; within the priority value range, determining the target test task The priority of the task configuration.

It should be noted that the relationship between the number of failures and the value range of the priority can be preset and stored in the server. For example, when the number of failures is 1, the value of the priority can be in the range of 1 to the quotient obtained by dividing the number of unit test tasks included in the current task queue by 2 and rounding up (or adding or Subtract the value of the default value such as 1), roughly from the top of the task queue to a certain position in the middle; when the number of failures is 2, the value range of the priority can be obtained by dividing the number of unit test tasks included in the current task queue by 2 The value of the quotient is rounded up (or a preset value such as 1 can be added or subtracted on the basis of rounding) to the number of unit test tasks included in the current task queue, roughly from the middle of the task queue to a certain position at the end.

In this embodiment, when the second device in the device set fails to execute, the server adds the second device to the device list of the failed devices in the historical execution information as the first device, and obtains the corresponding priority value scope. On the basis of the maximum value of this value range, a random perturbation is added to make the priority fluctuate within a small range, thereby avoiding the continuous execution of several failed unit test tasks, which are distributed in consecutive positions in the task queue. For example, several unit test tasks that take up a lot of memory have failed due to continuous execution. When these unit test tasks are executed again, these unit test tasks should be dispersed as much as possible to avoid re-concentration. . Therefore, by dynamically adjusting the position of the target test tasks to be executed in the task queue, it is possible to make full use of the time of the unit test process, and to avoid the concentration of unit test tasks that have errors in the queue, and reduce the number of different unit test tasks as much as possible. mutual interference between them.

Step S203, delete the target test task.

That is to say, when the updated number of failures is greater than or equal to the number threshold, the server deletes the name of the target test task from the task queue.

The unit test execution method of the embodiment of the present application first acquires a task queue including multiple unit test tasks, and performs task scheduling on the multiple unit test tasks in the task queue to determine the target test task to be executed, and then queries the target test task. The historical execution information of the test task to determine the first device that failed to execute the target test task, and finally schedule the second device other than the first device in the device set to execute the target test task, in the case that the second device fails to execute the target test task , update the number of failures in the historical execution information, and if the updated number of failures is less than the number of times threshold, add the target test task to the task queue, and add the second device to the historical execution information. List; if the updated number of failures is greater than or equal to the number threshold, delete the target test task. Therefore, the method can shorten the time-consuming of the unit testing process, further improve the execution efficiency of the unit testing, improve the resource utilization rate, and improve the development efficiency of the developer.

To make the present application more clearly understood by those skilled in the art, FIG. 3 is a schematic flowchart of a unit test execution method provided according to another embodiment of the present application. As shown in Figure 3, the execution method of the unit test includes:

Step S301, initialize a unit test task list and a device list.

Step S302, adding the unit test task to the priority task queue.

Step S303, select a suitable device for the unit test task.

Step S304, judging whether the device is in the list of failed devices. If yes, go back to step S303; if no, go to step S305.

Step S305: Distribute the unit test task to the device.

Step S306, the unit test task is executed by the device.

Step S307, it is judged whether the unit test task is executed successfully. If yes, go to step S310; if not, go to step S308.

S308, determine whether the number of executions is greater than or equal to 3. If yes, go to step S310; if no, go to step S309.

S309 , adding the devices that fail to execute into the list of devices that fail to execute, and cyclically execute step S302 .

S310, remove the unit test task from the priority task queue.

S311, record the execution result of the unit test task.

Assuming that the number of unit test tasks included in the task queue is N _u , the number of device hosts is N _h , each device is independent of each other, the number of unit test failures and retries is N _t , and a random error occurs on the device for a unit test The probability is p. wherein, N _h ≥ N _h .

所有单元测试通过的耗时期望是：For the conventional unit test execution method (only one device, failure does not retry), the probability of unit test success is

The time-consuming expectation for all unit tests to pass is:

所有单元测试通过的耗时期望是：Among them, t _i represents the time it takes for the i-th unit test to be executed successfully once. Using the execution method of the unit test of this application (adding the failure retry mechanism), the probability of the success of the unit test link is

The time-consuming expectation for all unit tests to pass is:

Compared with the conventional unit test execution method, the expected time saving of the present application is ΔT=T ₁ −T ₂ .

由此可以得到单元测试环节成功的概率将从36.60％提升到99.99％，耗时期望从273.20min，缩短到100.01min，效率提升了63.4％。For example, Nu = 100, N _t = 3, _p = 0.01,

From this, it can be seen that the success probability of the unit test link will be increased from 36.60% to 99.99%, the time-consuming expectation will be shortened from 273.20min to 100.01min, and the efficiency will be increased by 63.4%.

To sum up, the unit test execution method of the present application can greatly reduce the probability of random errors occurring in the unit test process, shorten the task queuing time, shorten the execution time of the unit test, improve the execution efficiency of the unit test, and improve the resource utilization rate; Improve developers' development efficiency and speed up software iteration.

In order to implement the above embodiments, the embodiments of the present application further provide an execution device for unit testing.

FIG. 4 is a schematic structural diagram of a device for executing a unit test according to an embodiment of the present application.

As shown in FIG. 4 , the unit test execution apparatus 400 according to the embodiment of the present application includes an acquisition module 410 , a scheduling module 420 , a query module 430 and an execution module 440 .

Wherein, the obtaining module 410 is used to obtain the task queue; wherein, the task queue includes a plurality of unit test tasks;

a scheduling module 420, configured to perform task scheduling on a plurality of unit test tasks in the task queue to determine the target test task to be executed;

The query module 430 is configured to query the historical execution information of the target test task to determine the first device that fails to execute the target test task;

The execution module 440 is configured to schedule a second device other than the first device in the device set to execute the target test task.

In a possible implementation manner of the embodiment of the present application, the above-mentioned execution device 400 further includes:

an update module, configured to update the number of failures in the historical execution information when the second device fails to perform the target test task;

The adding module is used for adding the target test task to the task queue and adding the second device to the device list of the failed devices in the historical execution information when the updated number of failures is less than the number threshold.

In a possible implementation manner of the embodiment of the present application, adding a module includes:

The configuration unit is used to configure the priority of the target test task according to the updated number of failures;

Adding a unit is used to add the target test task to the corresponding position of the task queue according to the priority.

In a possible implementation manner of the embodiment of the present application, the configuration unit includes:

a first determination subunit, configured to determine the corresponding priority value range according to the updated number of failures;

The second determination subunit is configured to determine the priority of the target test task configuration within the range of the priority value.

In a possible implementation manner of the embodiment of the present application, the execution device 400 further includes:

The deletion module is used to delete the target test task when the number of failures after the update is greater than or equal to the threshold of the number of times.

In a possible implementation manner of the embodiment of the present application, the number of times threshold is less than or equal to the total number of devices in the device set.

It should be noted that the explanations of the foregoing embodiment of the unit test execution method are also applicable to the unit test execution apparatus of this embodiment, and thus are not repeated here.

According to the unit test execution device of the embodiment of the present application, the task queue is acquired through the acquisition module; wherein, the task queue includes a plurality of unit test tasks, and the scheduling module performs task scheduling on the plurality of unit test tasks in the task queue to determine For the target test task to be executed, the historical execution information of the target test task is inquired through the query module to determine the first device that fails to execute the target test task, and the second device other than the first device in the device set is scheduled by the execution module to execute the target test Task. Therefore, the device can shorten the time consumption of the unit testing process, improve the execution efficiency of the unit testing, improve the resource utilization rate, and improve the development efficiency of developers.

According to the embodiments of the present application, the present application further provides a server and a readable storage medium.

As shown in FIG. 5 , it is a block diagram of a server of a unit test execution method according to an embodiment of the present application. A server is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Servers may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are by way of example only, and are not intended to limit implementations of the application described and/or claimed herein.

As shown in FIG. 5, the server includes: one or more processors 501, memory 502, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are interconnected using different buses and may be mounted on a common motherboard or otherwise as desired. The processor may process instructions executed within the server, including instructions stored in or on memory to display graphical information of the GUI on an external input/output device, such as a display device coupled to the interface. In other embodiments, multiple processors and/or multiple buses may be used with multiple memories and multiple memories, if desired. Likewise, multiple servers may be connected, with each device providing some of the necessary operations (eg, as an array of servers, a group of blade servers, or a multiprocessor system). A processor 501 is taken as an example in FIG. 5 .

The memory 502 is the non-transitory computer-readable storage medium provided by the present application. Wherein, the memory stores instructions executable by at least one processor, so that the at least one processor executes the unit test execution method provided by the present application. The non-transitory computer-readable storage medium of the present application stores computer instructions, and the computer instructions are used to cause the computer to execute the execution method of the unit test provided by the present application.

As a non-transitory computer-readable storage medium, the memory 502 can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as program instructions/modules (for example, program instructions/modules corresponding to the execution method of the unit test in the embodiments of the present application). , the acquisition module 410, the scheduling module 420, the query module 430 and the execution module 440 shown in FIG. 4). The processor 501 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions and modules stored in the memory 502, that is, implementing the unit test execution method in the above method embodiments.

The memory 502 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to the use of the server of the execution method of the unit test Wait. Additionally, memory 502 may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 502 may optionally include memory located remotely relative to the processor 501, and these remote memories may be connected over a network to a server that executes the method of unit testing. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

The server for executing the method for unit testing may further include: an input device 503 and an output device 504 . The processor 501 , the memory 502 , the input device 503 and the output device 504 may be connected by a bus or in other ways, and the connection by a bus is taken as an example in FIG. 5 .

The input device 503 can receive input numerical or character information, and generate key signal input related to user settings and function control of the server of the execution method of the unit test, such as a touch screen, a keypad, a mouse, a trackpad, a touchpad, a pointing stick , one or more mouse buttons, trackballs, joysticks and other input devices. Output devices 504 may include display devices, auxiliary lighting devices (eg, LEDs), haptic feedback devices (eg, vibration motors), and the like. The display device may include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display, and a plasma display. In some implementations, the display device may be a touch screen.

Various implementations of the systems and techniques described herein can be implemented in digital electronic circuitry, integrated circuit systems, application specific ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include being implemented in one or more computer programs executable and/or interpretable on a programmable system including at least one programmable processor that The processor, which may be a special purpose or general-purpose programmable processor, may receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device an output device.

These computational programs (also referred to as programs, software, software applications, or codes) include machine instructions for programmable processors, and may be implemented using high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages calculation program. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or apparatus for providing machine instructions and/or data to a programmable processor ( For example, magnetic disks, optical disks, memories, programmable logic devices (PLDs)), including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide interaction with a user, the systems and techniques described herein may be implemented on a computer having a display device (eg, a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user ); and a keyboard and pointing device (eg, a mouse or trackball) through which a user can provide input to the computer. Other kinds of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (eg, visual feedback, auditory feedback, or tactile feedback); and can be in any form (including acoustic input, voice input, or tactile input) to receive input from the user.

The systems and techniques described herein may be implemented on a computing system that includes back-end components (eg, as a data server), or a computing system that includes middleware components (eg, an application server), or a computing system that includes front-end components (eg, a user's computer having a graphical user interface or web browser through which a user may interact with implementations of the systems and techniques described herein), or including such backend components, middleware components, Or any combination of front-end components in a computing system. The components of the system may be interconnected by any form or medium of digital data communication (eg, a communication network). Examples of communication networks include: Local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.

A computer system can include clients and servers. Clients and servers are generally remote from each other and usually interact through a communication network. The relationship of client and server arises by computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also known as a cloud computing server or a cloud host. It is a host product in the cloud computing service system to solve the traditional physical host and VPS service ("Virtual Private Server", or "VPS" for short). , there are the defects of difficult management and weak business expansion.

According to the technical solutions of the embodiments of the present application, which relate to the field of deep learning, the method can greatly reduce the probability of random errors occurring in the unit testing process, shorten the task queuing time, shorten the execution time of the unit testing, and improve the execution efficiency of the unit testing. , improve resource utilization, improve developer development efficiency, and speed up software iteration.

It should be understood that steps may be reordered, added or deleted using the various forms of flow shown above. For example, the steps described in the present application can be performed in parallel, sequentially or in different orders, and as long as the desired results of the technical solutions disclosed in the present application can be achieved, no limitation is imposed herein.

The above-mentioned specific embodiments do not constitute a limitation on the protection scope of the present application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principles of this application shall be included within the protection scope of this application.

Claims (14)

1. A method of performing a unit test, comprising:

acquiring a task queue; the task queue comprises a plurality of unit test tasks;

performing task scheduling on a plurality of unit test tasks in the task queue to determine a target test task to be executed;

querying historical execution information of the target test task to determine first equipment which fails to execute the target test task;

and scheduling second equipment in the equipment set except the first equipment to execute the target test task.

2. The execution method of claim 1, wherein, after scheduling a second device of the set of devices other than the first device to execute the target test task, further comprising:

updating the failure times in the historical execution information under the condition that the second equipment fails to execute the target test task;

and under the condition that the updated failure times are smaller than a time threshold value, adding the target test task into the task queue, and adding the second equipment into an equipment list of failed equipment executed in the historical execution information.

3. The execution method of claim 2, wherein said adding the target test task to the task queue comprises:

configuring the priority of the target test task according to the updated failure times;

and adding the target test task to a corresponding position of the task queue according to the priority.

4. The execution method of claim 3, wherein the configuring the priority of the target test task according to the updated number of failures comprises:

determining a corresponding priority value range according to the updated failure times;

and determining the priority of the target test task configuration within the priority value range.

5. The execution method of claim 2, wherein after the updating the number of failures in the historical execution information, further comprising:

and deleting the target test task under the condition that the updated failure times are greater than or equal to the time threshold.

6. The execution method of claim 2, wherein the threshold number of times is less than or equal to a total number of devices in the set of devices.

7. An apparatus for performing a unit test, comprising:

the acquisition module is used for acquiring the task queue; the task queue comprises a plurality of unit test tasks;

the scheduling module is used for performing task scheduling on the plurality of unit test tasks in the task queue so as to determine a target test task to be executed;

the query module is used for querying the historical execution information of the target test task so as to determine first equipment which fails to execute the target test task;

and the execution module is used for scheduling second equipment in the equipment set except the first equipment to execute the target test task.

8. The execution apparatus of claim 7, further comprising:

the updating module is used for updating the failure times in the historical execution information under the condition that the second equipment fails to execute the target test task;

and the adding module is used for adding the target test task into the task queue and adding the second equipment into an equipment list of the failed equipment executed in the historical execution information under the condition that the updated failure times are smaller than a time threshold.

9. The execution device of claim 8, wherein the adding module comprises:

the configuration unit is used for configuring the priority of the target test task according to the updated failure times;

and the adding unit is used for adding the target test task to the corresponding position of the task queue according to the priority.

10. The execution apparatus of claim 9, wherein the configuration unit comprises:

the first determining subunit is configured to determine a corresponding priority value range according to the updated failure times;

and the second determining subunit is used for determining the priority of the target test task configuration in the priority value range.

11. The execution apparatus of claim 8, further comprising:

and the deleting module is used for deleting the target test task under the condition that the updated failure times are greater than or equal to the time threshold.

12. The execution apparatus of claim 8, wherein the threshold number of times is less than or equal to a total number of devices in the set of devices.

13. A server, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any of claims 1-6.

14. A non-transitory computer readable storage medium storing computer instructions for causing a computer to perform the method of any one of claims 1-6.

Images