Test method and device, computer equipment and readable storage medium

Abstract

The invention relates to a test method and device, computer equipment and a readable storage medium. The method comprises the steps of obtaining at least one to-be-tested sub-task corresponding to a to-be-tested task; wherein the test cases in different to-be-tested subtasks are mutually decoupled; adding the to-be-tested sub-tasks to a task queue; and executing each to-be-tested sub-task in the task queue in parallel through at least two task execution modules. By adopting the method, the test efficiency is improved, and the publishing efficiency, the software quality and the software reliability of the to-be-published software with different to-be-tested tasks are further improved.

Description

Technical Field

[0001] The present application relates to the field of testing, and in particular to a testing method, apparatus, computer device and readable storage medium. Background Art

[0002] With the continuous development of computer technology, the scale and complexity of software systems have gradually increased to enrich the functions of software systems. In order to ensure the quality and interactive friendliness of software systems, performance testing of software systems is usually required before the software systems are launched or updated.

[0003] The traditional software testing process is usually executed in a serial manner, resulting in low testing efficiency and failure to meet the requirements of rapid iteration and continuous integration. Summary of the invention

[0004] Based on this, it is necessary to provide a testing method, apparatus, computer device and readable storage medium that can improve testing efficiency in response to the above technical problems.

[0005] In a first aspect, the present application provides a testing method, comprising:

[0006] Obtain at least one subtask to be tested corresponding to the task to be tested; wherein the test cases in different subtasks to be tested are decoupled from each other;

[0007] Add each subtask to be tested to the task queue;

[0008] Each subtask to be tested in the task queue is executed in parallel by at least two task execution modules.

[0009] In one embodiment, at least two task execution modules are used to execute each to-be-tested subtask in the task queue in parallel, including:

[0010] Selecting a target distribution strategy from at least two task distribution strategies;

[0011] Based on the target distribution strategy, the subtasks to be tested in the task queue are distributed to each task execution module, and the distributed subtasks to be tested are executed in parallel by different task execution modules.

[0012] In one of the embodiments, a target distribution strategy is selected from at least two task distribution strategies, including: obtaining task attribute information and context information of the task to be tested; determining matching degree data between the task to be tested and each task distribution strategy based on the task attribute information and the context information; and selecting a target distribution strategy from each task distribution strategy based on the matching degree data of each task distribution strategy.

[0013] In one of the embodiments, the matching degree data between the task to be tested and each task distribution strategy is determined based on the task attribute information and the context information, including: determining a first matching score between the task to be tested and the corresponding task distribution strategy based on the matching between the task attribute information and each task distribution strategy; determining a second matching score between the task to be tested and the corresponding task distribution strategy based on the matching between the context information and each task distribution strategy; and taking the weighted sum of the first matching score and the corresponding second matching score of the task distribution strategy as the matching degree data of the corresponding task distribution strategy.

[0014] In one of the embodiments, the method further includes: obtaining the historical usage frequency of each task distribution strategy for similar tasks used to execute the task to be tested; determining the matching weight of the corresponding task distribution strategy based on the historical usage frequency; and updating the matching degree data of the corresponding task distribution strategy based on the matching weight.

[0015] In one of the embodiments, after distributing the subtasks to be tested in the task queue to each task execution module based on the target distribution strategy, and executing the distributed subtasks to be tested in parallel through different task execution modules, the method also includes: obtaining test performance data of each subtask to be tested distributed based on the target distribution strategy; determining whether the target distribution strategy is valid based on the test performance data; if the target distribution strategy is invalid, reselecting a new target distribution strategy from at least two task distribution strategies.

[0016] In one embodiment, each subtask to be tested is added to a task queue, including: determining task concurrency parameters based on system resources and network conditions of a system that carries the task queue, and adding each subtask to be tested to the task queue based on the task concurrency parameters; and / or, determining an execution order of the corresponding subtask to be tested based on the priority of each subtask to be tested, and adding the corresponding subtask to be tested to the task queue in sequence according to each execution order.

[0017] In a second aspect, the present application also provides a testing device, comprising:

[0018] An acquisition module, used to acquire at least one subtask to be tested corresponding to the task to be tested; wherein the test cases in different subtasks to be tested are decoupled from each other;

[0019] Add a module to add each subtask to be tested to the task queue;

[0020] At least two task execution modules are used to execute the subtasks to be tested in the task queue in parallel.

[0021] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0022] Obtain at least one subtask to be tested corresponding to the task to be tested; wherein the test cases in different subtasks to be tested are decoupled from each other;

[0023] Add each subtask to be tested to the task queue;

[0024] Each subtask to be tested in the task queue is executed in parallel by at least two task execution modules.

[0025] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the following steps are implemented:

[0026] Obtain at least one subtask to be tested corresponding to the task to be tested; wherein the test cases in different subtasks to be tested are decoupled from each other;

[0027] Add each subtask to be tested to the task queue;

[0028] Each subtask to be tested in the task queue is executed in parallel by at least two task execution modules.

[0029] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0030] Obtain at least one subtask to be tested corresponding to the task to be tested; wherein the test cases in different subtasks to be tested are decoupled from each other;

[0031] Add each subtask to be tested to the task queue;

[0032] Each subtask to be tested in the task queue is executed in parallel by at least two task execution modules.

[0033] The above-mentioned test method, device, computer equipment and readable storage medium, by splitting the task to be tested into at least one mutually decoupled subtask to be tested, and introducing a task queue to manage the execution order of different subtasks to be tested, each subtask to be tested in the task queue is executed in parallel by at least two task execution modules, without waiting for the execution result of the previous subtask to be tested, thereby improving the test efficiency. In addition, the test cases of each subtask to be tested corresponding to the task to be tested are mutually decoupled, so that the execution processes of different subtasks to be tested do not affect each other, and on the basis of improving the test efficiency, the accuracy and rationality of the test results are guaranteed. Further, since the above-mentioned parallel execution mode can quickly complete the execution of a large number of subtasks to be tested, the release cycle of the software to be released corresponding to the task to be tested is accelerated. In addition, since the parallel execution process allows the different functions and interfaces of the software to be released to be tested to be tested at the same time, the coverage of the test is improved, and the problems and defects of the software can be discovered and repaired in time, which helps to improve the quality and reliability of the software to be released. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0035] Figure 1 A schematic diagram of a test method in one embodiment;

[0036] Figure 2 A schematic diagram of a flow chart of parallel execution steps of subtasks to be tested in one embodiment;

[0037] Figure 3 A schematic diagram of a process of adding steps to a queue of a subtask to be tested in one embodiment;

[0038] Figure 4 A schematic flow chart of steps for adding a queue of subtasks to be tested in another embodiment;

[0039] Figure 5A is a block diagram of a test system in one embodiment;

[0040] Figure 5B A schematic flow chart of a testing method in another embodiment;

[0041] Figure 6 is a structural block diagram of a testing device in one embodiment;

[0042] Figure 7 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0043] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0044] In an exemplary embodiment, Figure 1 As shown, a test method is provided. This embodiment uses the method applied to a terminal as an example. It can be understood that the method can also be applied to a server, and can also be applied to a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0045] S110, obtaining at least one subtask to be tested corresponding to the task to be tested; wherein test cases in different subtasks to be tested are decoupled from each other.

[0046] The task to be tested may be a test task for any software system to be tested, for example, it may be a test task for testing different functional interfaces of the TSP (Telematics Service Provider) cloud platform system corresponding to the vehicle service. The TSP cloud platform may include functional service interfaces such as user login, adding devices, device list query, device details query, adding vehicles, vehicle list query, vehicle details query, vehicle control authority query, and log query.

[0047] The subtasks to be tested can be understood as the subtasks of the mutual structure of the test cases obtained by splitting the task to be tested.

[0048] Exemplarily, a complete test case for the task to be tested can be obtained; according to the dependency relationship between at least one test case contained in the complete test case, different test cases are decoupled and split to obtain independent test cases that are not coupled with each other. It is worth noting that the independent test case here may include only one test case, or may include at least two test cases that have a dependency relationship with each other. Among them, the complete test case can be written by a technician based on a preset framework. Exemplarily, the complete test case may include at least one of a public method, a configuration file, a test case, and test data. Among them, the public method may include at least one of a data acquisition method (such as a get() method), a data transmission method (such as a post() method), an assertion, a database connection method, and a file reading method. The configuration file usually contains the environment configuration data required to be relied on during the running of the test case. The test case can be understood as a code block obtained by combining the test command line according to a certain data processing logic. The test data can be understood as the parameter data required during the execution of the test case, and may include at least one of a formal parameter and an actual parameter. Among them, the preset framework can be set or adjusted by the technician according to actual needs, and this application does not make any limitation on this.

[0049] Among them, the subtask to be tested may include a test case, and accordingly, by running the test case, the corresponding subtask to be tested is executed. In an optional embodiment, the subtask to be tested may also include at least one of a subtask identifier, a task identifier, an execution instruction, data and parameters, and a timeout setting. Among them, the subtask identifier is used to distinguish different subtasks to be tested; the task identifier is used to uniquely characterize the task to be tested to which the subtask to be tested belongs; the execution instruction is used to trigger the execution of the test case of the subtask to be tested; the data and parameters can be understood as the data and parameters required to be relied on, used or processed by the test case execution process of the subtask to be tested; the timeout setting may include the expected execution time of the test case of the subtask to be tested and the timeout intervention measures. If the test time exceeds the expected execution time, the timeout intervention measures are executed. Exemplarily, the timeout intervention measures may be outputting a timeout reminder, making a timeout mark, interrupting the execution of the test case, or terminating the execution of the test case.

[0050] It is worth noting that the subtask to be tested is set in a format that can be executed independently, which facilitates the subsequent distribution and execution of the task.

[0051] In order to ensure that the subtask to be tested can be executed smoothly, before encapsulating the subtask to be tested, it is also necessary to detect whether the test case under the subtask to be tested has a dependent condition; if so, prepare the dependent condition; when the preparation is completed, execute the encapsulation of the corresponding subtask to be tested. Among them, the dependent condition may include at least one of the software version and environment configuration, etc., and this application does not make any limitation on this.

[0052] In order to avoid the situation where the subtask to be tested cannot correctly reflect the requirements of the original test case due to the influence of the task encapsulation process and to ensure that the subtask to be tested can achieve the expected test results, it is also possible to run a test on the encapsulated subtask to be tested after encapsulating it. If the test passes, the verification of the subtask to be tested passes.

[0053] S120, adding each subtask to be tested to a task queue.

[0054] Among them, the task queue is used to store different subtasks to be tested in order to avoid the occurrence of omissions of subtasks to be tested. Optionally, the bearing device of the task queue can have a persistence function, so as to ensure that in the case of a failure of the bearing device of the task queue, the subqueues to be tested in the task queue will not be lost. It is worth noting that the bearing device of the task queue can be the same as or different from the computing device that executes the test method, and this application does not make any limitation on this.

[0055] Exemplarily, the task queue may adopt a regular queue, a priority queue or a fair queue, etc., and this application does not impose any limitation on this. Among them, the regular queue follows the first-in-first-out principle; the priority queue follows the principle that the elements with higher priority (corresponding to the subtasks to be tested in this application) are first out, and in the case of the same priority, the arrangement order of the corresponding elements in the task queue is comprehensively considered; the fair queue may include at least one subqueue, and the elements in different subqueues (corresponding to the subtasks to be tested in this application) are taken out fairly.

[0056] It should be noted that the order of adding different subtasks to be tested can be determined based on the properties of each subtask to be tested and the association relationship between different subtasks to be tested, and this application does not impose any restrictions on this. Among them, the own properties can include at least one of the test function category, code volume and computational complexity. The association relationship between different subtasks to be tested can be a data inheritance relationship. For example, if the input data corresponding to subtask A to be tested is the output data of task B to be tested, then task B to be tested is added to the task queue before subtask A to be tested.

[0057] S130, executing the subtasks to be tested in the task queue in parallel by at least two task execution modules.

[0058] The different task execution modules can be understood as mutually independent data processing units that independently process the subtasks to be tested. Exemplarily, the different task execution modules can be mutually independent container resources or thread resources allocated in the test system.

[0059] Optionally, each subtask to be tested in the task queue can be sent to different task execution modules respectively according to a certain task distribution mechanism, and the corresponding task execution module can process the received subtask to be tested. Or optionally, each task execution module can pull the subtask to be tested from the task queue when it is idle, and independently execute the pulled subtask to be tested. Wherein, the task distribution mechanism can be implemented by adopting at least one traditional distribution strategy, and the present application does not make any limitation to this.

[0060] It is worth noting that when a task execution module fails to execute a subtask to be tested, the corresponding subtask to be tested can be executed again by retrying; if the number of retries is greater than the preset number threshold, the task execution failure can be directly marked. Or further, the subtask to be tested that failed to execute can be added back to the task queue, or added to the task failure queue, for subsequent remedial processing. Among them, the preset number threshold can be set or adjusted by the technician according to needs or experience, and this application does not make any limitation on this.

[0061] Exemplarily, after the task execution module obtains the subtask to be tested, it will run the test cases in the subtask to be tested based on the test data in the subtask to be tested to execute the corresponding subtask to be tested. It is worth noting that the process of executing the subtask to be tested may include at least one of the operations of calling an API (Application Programming Interface), running a script, and simulating user operations, and this application does not impose any restrictions on this. It is worth noting that in the process of running the test case, the task execution module will strictly follow the instruction steps of the test case to avoid errors in the execution process, and will capture any relevant output results during the execution process for archiving or subsequent use.

[0062] It is worth noting that in order to ensure that each task execution module can successfully execute the task to be tested, it is necessary to set the environment variables of the task execution module in advance as needed, connect to the required external resources, and prepare to execute the task.

[0063] In an optional embodiment, the task execution results of each task execution module can be added to the execution log for archiving. Further, the task execution results in the execution log can be analyzed and summarized according to different dimensions to obtain a test report.

[0064] Exemplarily, the data to be analyzed can be generated based on at least one of the test case identification, execution time and execution result (pass, fail, error or skip, etc.) and execution log of the test case; the data to be analyzed is statistically analyzed according to at least one dimension such as pass rate, failure rate and average execution time to obtain statistical data; the analysis results are classified and compared according to dimensions such as test case group, affiliated functional module and execution environment to obtain comparative data; the statistical data and comparative data are used to generate chart data in a specified format; and a test report including at least one of the statistical data, comparative data and chart data is generated. Among them, the test report can be in the format of HTML (HyperText Markup Language), PDF, Markdown (a lightweight markup language), etc., and this application does not make any limitation on this.

[0065] Furthermore, in order to facilitate relevant technical personnel to grasp the test situation in a timely manner, the relevant technical personnel can be notified that the test report has been generated, or the test report can be directly sent to the relevant technical task for review and use. Exemplarily, the notification reminder can be sent to the technical personnel by at least one of email, SMS and system notification.

[0066] The embodiment of the present application is to split the task to be tested into at least one mutually decoupled subtask to be tested, and introduce a task queue to manage the execution order of different subtasks to be tested, and execute each subtask to be tested in the task queue in parallel by at least two task execution modules, without waiting for the execution result of the previous subtask to be tested, thereby improving the test efficiency. In addition, the test cases of each subtask to be tested corresponding to the task to be tested are mutually decoupled, so that the execution processes of different subtasks to be tested do not affect each other, and on the basis of improving the test efficiency, the accuracy and rationality of the test result are guaranteed. Further, because the above-mentioned parallel execution mode can quickly complete the execution of a large number of subtasks to be tested, the release cycle of the corresponding software of the task to be tested is accelerated. In addition, because the parallel execution process allows the different functions and interfaces of the software to be released to be tested at the same time, the coverage rate of the test is improved, and the problems and defects of the software can be found and repaired in time, which helps to improve the quality and reliability of the software to be released.

[0067] On the basis of the technical solutions of the above-mentioned embodiments, the present application further provides an optional embodiment. In this optional embodiment, the steps of parallel execution of the subtasks to be tested in S130 are refined.

[0068] See also Figure 2 The parallel execution steps of the subtasks to be tested are shown as follows:

[0069] S210: Select a target distribution strategy from at least two task distribution strategies.

[0070] The task distribution strategy is used to distribute the subtasks to be tested in the task queue to different task execution modules for processing. In an optional embodiment, the task distribution strategy may include at least one of a round robin strategy, a least connections strategy, a random selection strategy, a performance priority strategy, a weighted distribution strategy, a priority-based distribution strategy, a resource-demand matching strategy, etc.

[0071] Exemplarily, the polling strategy first adds different subtasks to be tested to the task queue, and organizes each subtask to be tested according to the first-in-first-out principle; uses a distributor to manage the allocation of each subtask to be tested; the distributor can point to a subtask to be tested in the task queue at any given time point; when the distributor points to the first subtask to be tested in the task queue, the subtask to be tested is assigned to a task execution module for task execution; when the subtask to be tested executed by any task execution module is completed, the distributor moves to the next subtask to be tested in the task queue.

[0072] The target distribution strategy can be understood as the task distribution strategy actually adopted to distribute the tasks to be tested in the task queue to different task execution modules during this test.

[0073] In an optional embodiment, task attribute information and context information of the task to be tested may be obtained; based on the task attribute information and context information, the matching degree data between the task to be tested and each task distribution strategy may be determined; based on the matching degree data of each task distribution strategy, a target distribution strategy may be selected from each task distribution strategy.

[0074] Among them, the task attribute information may include at least one of the task identification of the task to be tested, the task type of the task to be tested, the priority, the estimated execution time, the dependency relationship between different subtasks to be tested in the task to be tested, the maximum number of executions and the allowed number of failures, etc.

[0075] The context information is used to characterize the environmental factors on which the execution of the task to be tested depends, and may include at least one of the running state of the task processing unit, the system load of the system carried by the task processing unit, resource availability, and time factors.

[0076] In an optional embodiment, the task attribute information can be feature encoded to obtain task feature data; and the context information can be feature encoded to obtain context feature data; the task feature data and context feature data can be feature fused to obtain fused feature data; the fused feature data can be input into a trained distribution strategy prediction model to obtain a distribution strategy prediction result; and the task distribution strategy corresponding to the distribution strategy prediction result can be used as the target distribution strategy.

[0077] The feature encoding may be at least one of one hot encoding and word-to-word vector encoding (Word2Vec), and the present application does not impose any limitation thereto. The feature fusion may be implemented by splicing fusion or other traditional fusion methods.

[0078] Among them, the distribution strategy prediction model can use the sample task feature data corresponding to the task attribute information of each sample task, and the sample context feature data corresponding to the context information of each sample task as input data; and use the standard distribution strategy corresponding to the sample task as label data to train the pre-constructed distribution strategy prediction model. It is worth noting that the model structure of the distribution strategy prediction model can be constructed using at least one traditional machine learning model or deep learning model, and this application does not impose any restrictions on the specific structure of the model. In addition, model training can adopt traditional model training methods, and this application does not impose any restrictions on this.

[0079] In another optional embodiment, a first matching score between the task to be tested and the corresponding task distribution measurement can be determined based on the matching between the task attribute information and each task distribution strategy; a second matching score between the task to be tested and the corresponding task distribution strategy can be determined based on the matching between the context information and each task distribution strategy; and a weighted sum of the first matching score and the corresponding second matching score of the task distribution strategy is used as the matching degree data of the corresponding task distribution strategy.

[0080] Exemplarily, matching scores between different reference task attributes and different task distribution strategies can be pre-constructed to obtain a first corresponding relationship; based on the first corresponding relationship, a first matching score between task attribute information and each task distribution strategy can be determined; matching scores between different reference contexts and different task distribution strategies can be pre-constructed to obtain a second corresponding relationship; based on the second corresponding relationship, a second matching score between context information and each task distribution strategy can be determined; for the same task distribution strategy, based on the pre-set distribution weights between the task attribute information and the context information, a weighted sum is performed on the first matching score and the second matching score of the task distribution strategy to obtain the matching degree data of the task distribution strategy.

[0081] Among them, the first corresponding relationship and the second corresponding relationship can be set by technical personnel based on experience or through a large number of experiments; the allocation weight between task attribute information and context information can be set by technical personnel based on experience or through a large number of experiments, or determined based on the number of attributes of the task attribute information and the number of information categories of the context information, and this application does not impose any limitations on this.

[0082] It should be noted that the first matching score is used to numerically quantify the adaptability between the task attribute information and the task distribution strategy (for example, the adaptability to the urgency and complexity of the task); the second matching score is used to numerically quantify the compatibility between the context information and the task distribution strategy (for example, the compatibility with the queue length, the idle state of the task processing unit, and other execution environments). Therefore, the matching degree score determined based on the first matching score and the second matching score can measure the fit between each task distribution strategy and the task to be tested from multiple dimensions. Therefore, selecting a target distribution strategy from different task distribution strategies based on the matching degree score improves the rationality and accuracy of the selected target distribution strategy, thereby helping to improve test efficiency.

[0083] It is worth noting that the historical execution status of similar tasks to the test task by different task distribution strategies can fully reflect the adaptation between the task distribution strategy and the task to be tested. Therefore, the historical execution status of similar tasks to the test task by introducing the task distribution strategy can also be used to assist in the selection of the target distribution strategy.

[0084] In an optional embodiment, the historical usage frequency of each task distribution strategy applied to similar tasks to the task to be tested may be obtained; a matching weight may be determined based on the historical usage frequency; and the matching degree data of the corresponding task distribution strategy may be updated based on the matching weight.

[0085] The similar tasks of the task to be tested may be other tasks of the same task type as the task to be tested. Alternatively, they may be other tasks whose similarity between the task description data is greater than a preset similarity threshold. The preset similarity threshold may be set by a technician according to needs or experience, or may be repeatedly determined through a large number of experiments, and this application does not impose any limitation on this.

[0086] Exemplarily, the matching weight of the corresponding task distribution strategy can be calculated based on the preset function according to the historical usage frequency corresponding to the task distribution strategy. The preset function is an increasing function with the historical usage frequency as the independent variable and the matching weight as the dependent variable. The preset function can be determined by the technician based on experience or a large number of experiments, and this application does not make any limitation on this.

[0087] Exemplarily, the matching weight of the task distribution strategy is directly used to weight the matching degree data of the corresponding task distribution strategy to update the matching degree data.

[0088] It can be understood that by introducing the task distribution strategy and applying it to the historical usage frequency of similar tasks to the task to be tested, the matching weight is determined, and the matching degree data of the corresponding task distribution strategy is updated according to the determined matching weight, so that the update result can fully consider the historical usage of the task distribution strategy, improve the rationality and accuracy of the matching degree data, and thus help to improve the accuracy and rationality of the selected target distribution strategy.

[0089] In a specific implementation, the task distribution strategies may be sorted according to the matching degree data; and the task distribution strategy corresponding to the higher (eg, highest) matching degree data is used as the target distribution strategy.

[0090] The above method introduces the task attribute information and context information of the task to be tested, determines the matching degree data between different task distribution strategies and the task to be tested, and selects the target distribution strategy based on the matching degree data, so that the selected target distribution strategy can fully consider the influence of the task attribute information and context information, thereby improving the rationality and accuracy of the selected target distribution strategy.

[0091] S220 , based on the target distribution strategy, distribute the subtasks to be tested in the task queue to each task execution module, and execute the distributed subtasks to be tested in parallel through different task execution modules.

[0092] It is worth noting that the distribution parameters corresponding to different task distribution strategies may be the same or different, and this application does not make any limitation on this. In the process of distributing the subtasks to be tested in the task queue to each task execution module based on the target distribution strategy, the distribution parameters of the task can also be dynamically adjusted. Among them, the distribution parameters may include at least one of the distribution rate and the number of concurrent tasks.

[0093] The embodiment of the present application selects a target distribution strategy from at least two task distribution strategies, instead of mechanically adopting a fixed task distribution strategy, to distribute the subtasks to be tested in the task queue to different task execution modules, and executes the distributed subtasks to be tested in parallel by different task execution modules, thereby improving the flexibility of the distribution process of the subtasks to be tested, being able to adapt to changing development and deployment environments, and further improving the universality of the testing method provided by the present application.

[0094] On the basis of the technical solutions of the above-mentioned embodiments, in order to further improve the rationality and accuracy of the selected target distribution strategy, it is also possible to distribute the subtasks to be tested in the task queue to each task execution module based on the target distribution strategy, and after the distributed subtasks to be tested are executed in parallel by different task execution modules, introduce test performance data, and reversely verify the effectiveness of the target distribution strategy based on the test performance data. If it is determined that the target distribution strategy is invalid, reselect a suitable target distribution strategy to continue the task distribution operation.

[0095] In an optional embodiment, test performance data of each subtask to be tested is obtained based on the target distribution strategy; whether the target distribution strategy is valid is determined based on the test performance data; if the target distribution strategy is invalid, a new target distribution strategy is reselected from at least two task distribution strategies.

[0096] The test performance data is used to numerically quantify the test performance of the entire test process by distributing tasks based on the target distribution strategy. Exemplarily, the test performance data may include the task execution status of each subtask to be tested, the task execution efficiency, task execution accuracy, task execution error rate or resource occupancy of each task execution module, and the queue length of the task queue.

[0097] Optionally, the task completion rate can be determined based on the number of subtasks to be tested that are completed and failed to be executed within a preset time period; the queue growth rate can be determined based on the number of unexecuted subtasks to be processed in the task queue or the waiting time, and the growth frequency of subtasks to be tested in the task queue; the resource utilization rate can be determined based on the occupancy of resources such as the CPU (Central Processing Unit) and memory corresponding to each task execution module; and whether the target distribution strategy is effective can be determined based on at least one of the task completion rate, queue growth rate, and resource utilization rate.

[0098] Or optionally, based on a preset evaluation function, the effective evaluation value of the corresponding task distribution strategy can be calculated according to the test performance data corresponding to the task distribution strategy. The independent variables corresponding to the preset evaluation function include positive test performance indicators and negative test performance indicators. Correspondingly, the preset evaluation function is an increasing function of the positive performance indicator and a decreasing function of the negative performance indicator. The positive test performance indicator is used to characterize an indicator with a good index value; the negative test performance indicator is used to characterize an indicator with a bad index value. The preset evaluation function can be determined by a technician based on experience or a large number of experiments, and this application does not impose any restrictions on this.

[0099] Furthermore, if the target distribution strategy is invalid, a task distribution strategy corresponding to higher (eg, highest) matching degree data is reselected from the remaining task distribution strategies as a new target distribution strategy.

[0100] On the basis of the technical solutions of the above-mentioned embodiments, the present application further provides an optional embodiment. In this optional embodiment, the step of adding the queue of the subtask to be tested in S120 is refined.

[0101] See also Figure 3 The steps for adding a queue to the subtask to be tested are shown as follows:

[0102] S310, determining task concurrency parameters according to system resources and network conditions corresponding to the system carrying the task queue.

[0103] The task concurrency parameter is used to characterize the control parameter for distributing the subtasks to be tested from the task queue, and may include at least one of the task distribution rate and the number of concurrent tasks.

[0104] The system resources may include at least one of the number of processing cores, the capacity of the running memory, and the capacity of the storage space. The network status is used to characterize the network performance of the bearer system. Exemplarily, a mapping relationship between different system resources and network status and the number of concurrent tasks may be preset; accordingly, based on the mapping relationship, the system resources and network status of the system bearer resources of the task queue are searched for the corresponding task concurrency parameters.

[0105] For example, taking the task 1 concurrency parameter including the number of concurrent tasks as an example, if the hosting system is an 8-core 16G server, the number of concurrent tasks can be set to 4-6 to fully utilize CPU resources and avoid performance degradation caused by excessive competition.

[0106] It is worth noting that the system resources and network status corresponding to the system carrying the task queue can be obtained in real time or periodically, and the task concurrency parameters can be dynamically adjusted according to the acquired data, so as to achieve the purpose of continuously optimizing the test process.

[0107] Optionally, dynamically adjusting the task concurrency parameters may include adjusting at least one of the number of concurrent tasks and the task distribution rate.

[0108] S320, adding each subtask to be tested to a task queue according to the task concurrency parameter.

[0109] For example, based on the task concurrency parameters, the number of subtasks to be tested added to the task queue per unit time can be strictly controlled, thereby avoiding the blocking of the task queue or the freezing of the system carrying the task execution module.

[0110] The embodiment of the present application, by introducing the corresponding system resources and network conditions of the carrying system of the task queue, determines the task concurrency parameter, and based on the task concurrency parameter, strictly controls the process of adding the subtask to be tested to the task queue, avoids congestion in the task queue and jams in the carrying system of the task execution module, and affects the test process, thereby ensuring the orderly and smooth execution of the test process. Meanwhile, this flexible adjustment elastic mechanism ensures that the test efficiency is maximized under limited hardware resources, and avoids the generation of resource waste, and can keep the stability of the carrying system of the task execution module under high load. In addition, the above-mentioned flexible adjustment elastic mechanism can also adapt to the changeable development and deployment environment, and further improves the universality of the test method provided by the present application.

[0111] On the basis of the technical solutions of the above-mentioned embodiments, the present application further provides an optional embodiment. In this optional embodiment, the step of adding the queue of the subtask to be tested in S120 is refined.

[0112] See also Figure 4 The steps for adding a queue to the subtask to be tested are shown as follows:

[0113] S410: Determine the execution order of the corresponding subtasks to be tested according to the priority of each subtask to be tested.

[0114] S420, adding corresponding subtasks to be tested to the task queue in sequence according to the execution order.

[0115] The priority of the subtask to be tested can be determined based on at least one of the historical success rate and priority level of the subtask to be tested, etc. The priority level can be set by technicians based on experience or needs, or determined repeatedly through a large number of experiments, and this application does not impose any limitation on this.

[0116] It is worth noting that the priorities of different subtasks to be tested may be the same or different, and this application does not impose any limitation on this.

[0117] Among them, the priority of the subtask to be tested represents the importance of the subtask to be tested. If the priority of the subtask to be tested is higher, it means that the subtask to be tested is more important. Then, the execution order of the subtasks to be tested can be determined in order from high to low priority, and the subtasks to be tested with higher priorities are added to the task queue first. If the priority of the subtask to be tested is lower, it means that the subtask to be tested is more important. Then, the execution order of the subtasks to be tested can be determined in order from low to high priority, and the subtasks to be tested with lower priorities are added to the task queue first.

[0118] The embodiment of the present application introduces the priority of the subtask to be tested to affect the order in which the subtask to be tested is added to the task queue, thereby ensuring that important subtasks to be tested are processed first and improving the flexibility of the execution process of the subtask to be tested.

[0119] Based on the technical solutions of the above embodiments, the present application also provides an optional embodiment. In this optional embodiment, Figure 5A The test system block diagram shown in Figure 3 details the test process.

[0120] See also Figure 5B A test method is shown, comprising:

[0121] S501, obtaining the task to be tested;

[0122] S502, encapsulating the task to be tested into at least two subtasks to be tested that are decoupled from the test case through a task encapsulation module; wherein the subtask to be tested includes the test case;

[0123] S503, determine whether each subtask to be tested meets the corresponding pre-dependency condition; if so, execute S504; otherwise, re-execute S502;

[0124] S504, storing each subtask to be tested in the task queue according to the pre-configured access information of the task queue;

[0125] The access information may include queue address and authentication information, etc.

[0126] S505, dynamically adjusting the task distribution rate and concurrent quantity according to the preset concurrency strategy through the task distribution module;

[0127] S506, adjusting the position of the subtask to be tested in the task queue by the task distribution module in combination with the priority of the subtask to be tested;

[0128] S507, each task execution module obtains the subtask to be tested from the task queue;

[0129] S508, each task execution module executes the acquired test cases of the subtasks to be tested in parallel, and captures the execution results;

[0130] S509, determine whether the task execution is successful; if so, execute S510; otherwise, execute S511;

[0131] S510, record the execution result; continue to execute S512;

[0132] S511, re-execute the subtask to be tested; or directly mark the subtask to be tested as failed, and add it to the task queue again;

[0133] S512, generating a test report according to the execution result through the data processing module.

[0134] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0135] Based on the same inventive concept, the embodiment of the present application also provides a test device for implementing the test method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more test device embodiments provided below can refer to the limitations on the test method above, and will not be repeated here.

[0136] In an exemplary embodiment, Figure 6 As shown, a testing device is provided, including: an acquisition module 610, an adding module 620 and at least two task execution modules 630;

[0137] An acquisition module 610 is used to acquire at least one subtask to be tested corresponding to the task to be tested; wherein the test cases in different subtasks to be tested are decoupled from each other;

[0138] An adding module 620 is used to add each subtask to be tested to a task queue;

[0139] At least two task execution modules 630 are used to execute the subtasks to be tested in the task queue in parallel.

[0140] In one embodiment, the device also includes a task distribution module, which is used to select a target distribution strategy from at least two task distribution strategies, and based on the target distribution strategy, distribute the subtasks to be tested in the task queue to each task execution module; each task execution module 630 is used to execute the distributed subtasks to be tested in parallel.

[0141] In one of the embodiments, the task distribution module is specifically used to: obtain task attribute information and context information of the task to be tested; determine the matching degree data between the task to be tested and each task distribution strategy based on the task attribute information and context information; and select a target distribution strategy from each task distribution strategy based on the matching degree data of each task distribution strategy.

[0142] In one of the embodiments, the task distribution module is specifically used to: determine a first matching score between the task to be tested and the corresponding task distribution strategy based on the matching between task attribute information and each task distribution strategy; determine a second matching score between the task to be tested and the corresponding task distribution strategy based on the matching between context information and each task distribution strategy; and use the weighted sum of the first matching score and the corresponding second matching score of the task distribution strategy as the matching degree data of the corresponding task distribution strategy.

[0143] In one of the embodiments, the task distribution module is also used to: obtain the historical usage frequency of each task distribution strategy for similar tasks used to execute the task to be tested; determine the matching weight of the corresponding task distribution strategy based on the historical usage frequency; and update the matching degree data of the corresponding task distribution strategy based on the matching weight.

[0144] In one of the embodiments, the task distribution module is also used to: distribute the subtasks to be tested in the task queue to each task execution module based on the target distribution strategy, and after the distributed subtasks to be tested are executed in parallel by different task execution modules, obtain the test performance data of each subtask to be tested distributed based on the target distribution strategy; determine whether the target distribution strategy is valid based on the test performance data; if the target distribution strategy is invalid, reselect a new target distribution strategy from at least two task distribution strategies.

[0145] In one embodiment, the adding module 620 is specifically used to: determine the task concurrency parameters according to the system resources and network conditions corresponding to the carrying system of the task queue, and add each subtask to be tested to the task queue according to the task concurrency parameters; and / or, determine the execution order of the corresponding subtasks to be tested according to the priority of each subtask to be tested, and add the corresponding subtasks to be tested to the task queue in sequence according to each execution order.

[0146] Each module in the above-mentioned test device can be implemented in whole or in part by software, hardware and a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each module above.

[0147] In an exemplary embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as shown in FIG. Figure 7 As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, near field communication (NFC) or other technologies. When the computer program is executed by the processor, a test method is implemented. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

[0148] Those skilled in the art will understand that Figure 7 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0149] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

[0150] Obtain at least one subtask to be tested corresponding to the task to be tested; wherein the test cases in different subtasks to be tested are decoupled from each other;

[0151] Add each of the subtasks to be tested to the task queue;

[0152] Each subtask to be tested in the task queue is executed in parallel by at least two task execution modules.

[0153] In one embodiment, when the processor executes the computer program, the following steps are also implemented: selecting a target distribution strategy from at least two task distribution strategies; based on the target distribution strategy, distributing the subtasks to be tested in the task queue to each of the task execution modules, and executing the distributed subtasks to be tested in parallel through different task execution modules.

[0154] In one embodiment, when the processor executes the computer program, the following steps are also implemented: obtaining task attribute information and context information of the task to be tested; determining the matching degree data between the task to be tested and each of the task distribution strategies based on the task attribute information and context information; and selecting the target distribution strategy from each of the task distribution strategies based on the matching degree data of each of the task distribution strategies.

[0155] In one embodiment, when the processor executes the computer program, the following steps are also implemented: determining a first matching score between the task to be tested and the corresponding task distribution strategy based on the matching between the task attribute information and each of the task distribution strategies; determining a second matching score between the task to be tested and the corresponding task distribution strategy based on the matching between the context information and each of the task distribution strategies; and using the weighted sum of the first matching score and the corresponding second matching score of the task distribution strategy as the matching degree data of the corresponding task distribution strategy.

[0156] In one embodiment, when the processor executes the computer program, the following steps are also implemented: obtaining the historical usage frequency of each task distribution strategy applied to similar tasks for executing the task to be tested; determining the matching weight of the corresponding task distribution strategy based on the historical usage frequency; and updating the matching degree data of the corresponding task distribution strategy based on the matching weight.

[0157] In one embodiment, when the processor executes the computer program, the following steps are also implemented: obtaining test performance data of each subtask to be tested based on the target distribution strategy; determining whether the target distribution strategy is valid based on the test performance data; if the target distribution strategy is invalid, reselecting a new target distribution strategy from at least two task distribution strategies.

[0158] In one embodiment, the processor also implements the following steps when executing the computer program: determining the task concurrency parameters according to the system resources and network conditions corresponding to the carrying system of the task queue, and adding each of the subtasks to be tested to the task queue according to the task concurrency parameters; and / or determining the execution order of the corresponding subtasks to be tested according to the priority of each of the subtasks to be tested, and adding the corresponding subtasks to be tested to the task queue in sequence according to each execution order.

[0159] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0160] Obtain at least one subtask to be tested corresponding to the task to be tested; wherein the test cases in different subtasks to be tested are decoupled from each other;

[0161] Add each of the subtasks to be tested to the task queue;

[0162] Each subtask to be tested in the task queue is executed in parallel by at least two task execution modules.

[0163] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: selecting a target distribution strategy from at least two task distribution strategies; based on the target distribution strategy, distributing the subtasks to be tested in the task queue to each of the task execution modules, and executing the distributed subtasks to be tested in parallel through different task execution modules.

[0164] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: obtaining task attribute information and context information of the task to be tested; determining the matching degree data between the task to be tested and each of the task distribution strategies based on the task attribute information and context information; and selecting the target distribution strategy from each of the task distribution strategies based on the matching degree data of each of the task distribution strategies.

[0165] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: determining a first matching score between the task to be tested and the corresponding task distribution strategy based on the matching between the task attribute information and each of the task distribution strategies; determining a second matching score between the task to be tested and the corresponding task distribution strategy based on the matching between the context information and each of the task distribution strategies; and using the weighted sum of the first matching score and the corresponding second matching score of the task distribution strategy as the matching degree data of the corresponding task distribution strategy.

[0166] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: obtaining the historical usage frequency of each task distribution strategy for similar tasks used to execute the task to be tested; determining the matching weight of the corresponding task distribution strategy based on the historical usage frequency; and updating the matching degree data of the corresponding task distribution strategy based on the matching weight.

[0167] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: obtaining test performance data of each subtask to be tested based on the target distribution strategy; determining whether the target distribution strategy is valid based on the test performance data; if the target distribution strategy is invalid, reselecting a new target distribution strategy from at least two task distribution strategies.

[0168] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: determining the task concurrency parameters according to the system resources and network conditions corresponding to the carrying system of the task queue, and adding each of the subtasks to be tested to the task queue according to the task concurrency parameters; and / or determining the execution order of the corresponding subtasks to be tested according to the priority of each of the subtasks to be tested, and adding the corresponding subtasks to be tested to the task queue in sequence according to each execution order.

[0169] In one embodiment, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the following steps:

[0170] Obtain at least one subtask to be tested corresponding to the task to be tested; wherein the test cases in different subtasks to be tested are decoupled from each other;

[0171] Add each of the subtasks to be tested to the task queue;

[0172] Each subtask to be tested in the task queue is executed in parallel by at least two task execution modules.

[0173] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: selecting a target distribution strategy from at least two task distribution strategies; based on the target distribution strategy, distributing the subtasks to be tested in the task queue to each of the task execution modules, and executing the distributed subtasks to be tested in parallel through different task execution modules.

[0174] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: obtaining task attribute information and context information of the task to be tested; determining the matching degree data between the task to be tested and each of the task distribution strategies based on the task attribute information and context information; and selecting the target distribution strategy from each of the task distribution strategies based on the matching degree data of each of the task distribution strategies.

[0175] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: determining a first matching score between the task to be tested and the corresponding task distribution strategy based on the matching between the task attribute information and each of the task distribution strategies; determining a second matching score between the task to be tested and the corresponding task distribution strategy based on the matching between the context information and each of the task distribution strategies; and using the weighted sum of the first matching score and the corresponding second matching score of the task distribution strategy as the matching degree data of the corresponding task distribution strategy.

[0176] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: obtaining the historical usage frequency of each task distribution strategy for similar tasks used to execute the task to be tested; determining the matching weight of the corresponding task distribution strategy based on the historical usage frequency; and updating the matching degree data of the corresponding task distribution strategy based on the matching weight.

[0177] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: obtaining test performance data of each subtask to be tested based on the target distribution strategy; determining whether the target distribution strategy is valid based on the test performance data; if the target distribution strategy is invalid, reselecting a new target distribution strategy from at least two task distribution strategies.

[0178] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: determining the task concurrency parameters according to the system resources and network conditions corresponding to the carrying system of the task queue, and adding each of the subtasks to be tested to the task queue according to the task concurrency parameters; and / or determining the execution order of the corresponding subtasks to be tested according to the priority of each of the subtasks to be tested, and adding the corresponding subtasks to be tested to the task queue in sequence according to each execution order.

[0179] It should be noted that 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, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0180] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0181] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0182] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A testing method, characterized in that: include: Obtain at least one subtask to be tested corresponding to the task to be tested; wherein the test cases in different subtasks to be tested are decoupled from each other; Add each of the subtasks to be tested to the task queue; Each subtask to be tested in the task queue is executed in parallel by at least two task execution modules.

2. The method according to claim 1, characterized in that The step of executing each to-be-tested subtask in the task queue in parallel by at least two task execution modules includes: Selecting a target distribution strategy from at least two task distribution strategies; Based on the target distribution strategy, the subtasks to be tested in the task queue are distributed to each of the task execution modules, and the distributed subtasks to be tested are executed in parallel by different task execution modules.

3. The method according to claim 2, characterized in that The step of selecting a target distribution strategy from at least two task distribution strategies includes: Obtaining task attribute information and context information of the task to be tested; Determining the matching degree data between the task to be tested and each of the task distribution strategies according to the task attribute information and the context information; The target distribution strategy is selected from the task distribution strategies according to the matching degree data of the task distribution strategies.

4. The method according to claim 3, characterized in that The determining, based on the task attribute information and the context information, the matching degree data between the task to be tested and each of the task distribution strategies comprises: Determine a first matching score between the task to be tested and the corresponding task distribution strategy according to the matching between the task attribute information and each of the task distribution strategies; Determining a second matching score between the task to be tested and the corresponding task distribution strategy according to a matching condition between the context information and each of the task distribution strategies; The weighted sum of the first matching score and the corresponding second matching score of the task distribution strategy is used as the matching degree data of the corresponding task distribution strategy.

5. The method according to claim 3, characterized in that: The method further comprises: Obtaining the historical usage frequency of each of the task distribution strategies for executing similar tasks to the task to be tested; Determining a matching weight of a corresponding task allocation strategy according to the historical usage frequency; According to the matching weight, the matching degree data of the corresponding task distribution strategy is updated.

6. The method according to claim 2, characterized in that After distributing the subtasks to be tested in the task queue to each of the task execution modules based on the target distribution strategy, and executing the distributed subtasks to be tested in parallel by different task execution modules, the method further includes: Obtaining test performance data of each subtask to be tested distributed based on the target distribution strategy; Determining whether the target distribution strategy is effective according to the test performance data; If the target distribution strategy is invalid, a new target distribution strategy is reselected from at least two task distribution strategies.

7. The method according to any one of claims 1 to 6, characterized in that: The step of adding each of the subtasks to be tested to the task queue includes: Determine task concurrency parameters according to system resources and network conditions corresponding to the carrying system of the task queue, and add each of the subtasks to be tested to the task queue according to the task concurrency parameters; and / or, According to the priority of each of the subtasks to be tested, the execution order of the corresponding subtasks to be tested is determined, and according to each of the execution orders, the corresponding subtasks to be tested are sequentially added to the task queue.

8. A testing device, characterized in that: include: An acquisition module, used to acquire at least one subtask to be tested corresponding to the task to be tested; wherein the test cases in different subtasks to be tested are decoupled from each other; An adding module, used for adding each of the subtasks to be tested to a task queue; At least two task execution modules are used to execute the subtasks to be tested in the task queue in parallel.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images