Software testing method

Abstract

The application discloses a software testing method, and relates to the technical field of servers. The method comprises the following steps: generating and binding accurate environment parameters for a testing task, intelligently distributing the task to an optimal server for execution according to real-time server load, and introducing a multi-sub-strategy retry mechanism based on task execution: when the task fails, the system can dynamically select and switch to more reasonable environment parameters according to historical execution conditions and a preset task retry strategy, and re-distribute the task to the optimal server for execution in combination with the load states of the servers. In this way, double optimization of environment scheduling and resource scheduling is realized, invalid retries are reduced, and the testing efficiency of the software testing task and the resource utilization rate are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of servers, and particularly relates to a software testing method. BACKGROUND

[0002] With the increasing scale of software, automated testing has become a necessary means to ensure software quality. However, the automated testing method in the prior art has poor environmental adaptability and unbalanced resource scheduling when performing a software testing task, resulting in low testing efficiency. SUMMARY

[0003] The present application provides a software testing method, which can improve the testing efficiency of a software testing task.

[0004] In one aspect, the present application provides a software testing method, comprising:

[0005] generating a first environment parameter based on a software testing task, the first environment parameter indicating an execution environment of the software testing task;

[0006] allocating a first server for the software testing task from a plurality of servers based on load information of the plurality of servers, sending the software testing task and the first environment parameter to the first server, so that the first server executes the software testing task based on the first environment parameter;

[0007] determining a second environment parameter based on a task retry strategy in a case where a first failure result is received, the first failure result indicating that the execution of the software testing task based on the first environment parameter fails, the second environment parameter indicating an execution environment of re-executing the software testing task, the task retry strategy indicating an execution condition of the software testing task and a plurality of sub-strategies included, determining an environment parameter required for re-executing the software testing task, and the environment parameters corresponding to different sub-strategies being determined in different manners;

[0008] allocating a second server for the software testing task from the plurality of servers based on the load information of the plurality of servers, sending the software testing task and the second environment parameter to the second server, so that the second server executes the software testing task based on the second environment parameter.

[0009] In another aspect, the present application provides an electronic device, comprising:

[0010] a memory configured to store a computer program;

[0011] a processor configured to execute the computer program to implement the steps of the above software testing method.

[0012] In another aspect, the present application provides a computer readable storage medium, and the computer readable storage medium stores a computer program, wherein the computer program is executed by a processor to implement the steps of the software testing method.

[0013] In another aspect, the present application provides a computer program product, comprising a computer program, wherein the computer program is executed by a processor to implement the steps of the software testing method.

[0014] The software testing method provided by the embodiments of the present application generates and binds accurate environment parameters for a test task, intelligently allocates the task to an optimal server for execution according to real-time server load, and introduces a multi-sub-strategy retry mechanism based on task execution: when the task fails, the system can dynamically select and switch to more reasonable environment parameters according to historical execution conditions and a preset task retry strategy, and re-allocate the task to an optimal server for execution in combination with the load status of each server. In this way, dual optimization of environment scheduling and resource scheduling is achieved, invalid retries are reduced, and the test efficiency and resource utilization of the software test task are improved. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0016] Figure 1 The application scenario of the software testing method provided by the embodiments of the present application is shown in the figure.

[0017] Figure 2 The flowchart of the software testing method provided by the embodiments of the present application is shown in the figure. Figure 1 ;

[0018] Figure 3 The flowchart of the software testing method provided by the embodiments of the present application is shown in the figure. Figure 2 ;

[0019] Figure 4 The flowchart of the software testing method provided by the embodiments of the present application is shown in the figure. Figure 3 ;

[0020] Figure 1 The multi-server cooperative software testing system provided by the embodiments of the present application is shown in the figure. Figure 1 ;

[0021] Figure 1 The flowchart of generating environment parameters provided by the embodiments of the present application is shown in the figure. Figure 1 ;

[0022] Figure 1 Flow diagram of the task retry strategy-based retry provided by the embodiments of the present application Figure 2 ;

[0023] Figure 2 Flow diagram of the task retry strategy-based retry provided by the embodiments of the present application Figure 1 ;

[0024] Figure 1 Structure diagram of the software testing device provided by the embodiments of the present application Figure 1 ;

[0025] Figure 1 Structure diagram of the electronic device provided by the present application. DETAILED DESCRIPTION

[0026] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0027] It should be noted that, in the description of the present application, the terms “comprise”, “contain” or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. The terms “first”, “second” and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0028] With the increasing scale of software, automated testing has become a necessary means to ensure software quality. However, the automated testing method in the prior art has problems of poor environment adaptability, unbalanced resource scheduling and the like when performing a software testing task, resulting in low testing efficiency. In order to solve the problem of low testing efficiency, the present application provides a software testing method, which generates and binds accurate environment parameters for a testing task, intelligently allocates the task to an optimal server for execution according to real-time server load, and introduces a multi-sub-strategy retry mechanism based on task execution: when the task fails, the system can dynamically select and switch to more reasonable environment parameters according to historical execution and preset task retry strategies, and re-allocate the task to the optimal server for execution in combination with the load status of each server. In this way, dual optimization of environment scheduling and resource scheduling is achieved, invalid retries are reduced, and the testing efficiency and resource utilization of the software testing task are improved. In order to enable those skilled in the art to better understand the present application scheme, the present application will be further described in detail below in combination with the drawings and specific embodiments. In combination with the specific application environment architecture or specific hardware architecture on which the software testing method depends, the specific application environment architecture or specific hardware architecture is described here.

[0029] Figure 1 The application scenario of the software testing method provided by the embodiment of the present application is shown in the figure. Figure 1 As shown, the software testing system includes a scheduling server 101 and a plurality of servers 102, and a communication connection is established between the scheduling server 101 and each server 102. The scheduling server 101 can receive a software testing task to be allocated, generate corresponding environment parameters based on the software testing task, and allocate the software testing task and the environment parameters to the servers 102 in combination with the load rates of the servers 102, so that each server 102 executes each software testing task based on the environment parameters. Moreover, the scheduling server 101 will also return a failure result after the server 102 fails to execute the software testing task. Then, the scheduling server 101 starts a task retry mechanism for the failed software testing task, initiates a retry of the software testing task based on a task retry strategy, and re-distributes the servers 102 to execute the software testing task according to the load rates of the servers 102.

[0030] Figure 1 The flowchart of the software testing method provided by the embodiment of the present application is shown in the figure. Figure 2 As shown in the figure, Figure 2 The method includes the following steps.

[0031] S201, generating a first environment parameter based on a software testing task, the first environment parameter indicating an execution environment of the software testing task.

[0032] In the embodiments of the present application, in order to ensure the smooth progress of the software test task, an execution environment needs to be specified for the software test task, so that after being allocated to a certain server according to the load condition of each server, the server can execute the software test task according to the specified execution environment, so as to ensure the load balancing of each server. At the same time, considering that the software test task may fail to execute, a task retry strategy is preset, so that after the software test task fails, the software test task is re-executed in the manner indicated by the task retry strategy, so as to ensure the smooth progress of the software test task. The software test task can also be referred to as a test case, which is a standardized description containing test input, execution condition and expected result designed for verifying a certain specific software function or requirement. In automated testing, the software test task is implemented as a script or code segment that can be executed by a test framework. The execution environment is the environment required for executing the software test task, and the first environment parameter can include at least one dimension parameter to describe the execution environment of the software test task. For example, the first environment parameter includes an operating system type, a browser type or a network type, the operating system type indicates which type of operating system is used to execute the software test task, the browser type indicates which browser is used to execute the software test task, and the network type indicates which network is used to execute the software test task.

[0033] S202, based on the load information of the plurality of servers, allocating a first server for the software test task from the plurality of servers, and sending the software test task and the first environment parameter to the first server, so that the first server executes the software test task based on the first environment parameter.

[0034] In the embodiments of the present application, in the software test system, in addition to the scheduling server, there are a plurality of servers, which can also be referred to as execution servers, and the plurality of servers are used to execute the software test task. After receiving the software test task, the scheduling server will allocate it to a certain server for execution. Considering that the number of software test tasks allocated to different servers may be different, which will cause the busy degree of different servers to be different, therefore, when allocating the software test task to the plurality of servers, the load condition of the plurality of servers needs to be considered to ensure the load balancing of the plurality of servers. The load information is used to describe the load condition of the server, and can also reflect the busy degree of the server. The load information can be identified by multiple dimensions of information, for example, the load information includes at least one of processor usage and memory usage, and both the processor usage and the memory usage can be expressed in percentage. The first server is any server in the plurality of servers, or is the server with the lowest load rate in the plurality of servers.

[0035] S203, in a case where the first failure result is received, determining a second environment parameter based on a task retry strategy, the first failure result indicating that the software test task is executed based on the first environment parameter fails, the second environment parameter indicating an execution environment for re-executing the software test task, the task retry strategy indicating an execution condition of the software test task and a plurality of sub-strategies included, and determining an environment parameter required for re-executing the software test task, and the environment parameter determined by different sub-strategies is different.

[0036] In the embodiment of the present application, the first failure result is a test result returned by the first server. The first failure result indicates that the first server fails to execute the software test task based on the first environment parameter. In order to ensure that the software test task can be successfully performed, the task retry strategy is set in advance, so as to determine the environment parameter required for the software test task to retry according to the task retry strategy, based on the execution condition of the software test task and a plurality of environment parameter determination manners, and then re-allocate the server to execute. The second environment parameter can be the same as or different from the first environment parameter. The second environment parameter can include at least one dimension parameter to describe the execution environment of the software test task, for example, the second environment parameter includes the operating system type, the browser type or the network type. Taking the first environment parameter and the second environment parameter both including the operating system type, the browser type and the network type as an example, if the first environment parameter is the same as the second environment parameter, the operating system type, the browser type and the network type in the first environment parameter and the second environment parameter are the same; if the first environment parameter is different from the second environment parameter, at least one of the operating system type, the browser type and the network type included in the first environment parameter and the second environment parameter is different. The execution condition of the software test task refers to whether the software test task is successfully executed, the number of executions or retries, etc. The task retry strategy includes a plurality of sub-strategies, each sub-strategy corresponds to an environment parameter determination manner, and the environment parameter determination manners corresponding to different sub-strategies are different. In the embodiment of the present application, the task retry strategy is equivalent to a multi-dimensional retry mechanism.

[0037] S204, based on the load information of the plurality of servers, allocating a second server for the software test task from the plurality of servers, and sending the software test task and the second environment parameter to the second server, so that the second server executes the software test task based on the second environment parameter.

[0038] In the embodiment of the application, since the software test task fails to be executed, the server needs to be re-assigned to the software test task so as to ensure the load balancing of each server as much as possible. Therefore, the second server is re-assigned to the software test task in combination with the load information of each server, so that the second server executes the software test task according to the new environment parameter, thereby realizing the retry of the software test task. The second server is any one of the plurality of servers, or is the server with the lowest load rate among the plurality of servers. The second server can be the same as or different from the first server.

[0039] The software test method provided in the embodiment of the application generates and binds accurate environment parameters for a test task, intelligently assigns the task to an optimal server for execution according to real-time server load, and introduces a multi-sub-strategy retry mechanism based on task execution. When the task fails, the system can dynamically select and switch to more reasonable environment parameters according to historical execution and a preset task retry strategy, and re-assign the task to an optimal server for execution in combination with the load state of each server. In this way, the dual optimization of environment scheduling and resource scheduling is realized, invalid retries are reduced, and the test efficiency and resource utilization of the software test task are improved.

[0040] On the basis of the above Figure 1 In the embodiment of the application, the priority of the software test task is considered when the server is assigned to the software test task, and the task retry strategy includes three different sub-strategies, i.e., a first sub-strategy, a second sub-strategy and a third sub-strategy. The software test task is retried in combination with the three sub-strategies, and the specific process is described in the following embodiments. Figure 2 The flow of the software test method provided in the embodiment of the application is shown in Figure 2 As shown in Figure 2 For example, the method is executed by a scheduling server, and the method includes the following steps.

[0041] S301, generating a first environment parameter based on a software test task, the first environment parameter indicating an execution environment of the software test task, and the first environment parameter including an operating system type, a browser type and a network type.

[0042] In the embodiments of the present application, whether the software testing task can be tested successfully is affected by the execution environment, such as the type of operating system, the type of browser and the type of network. Therefore, the first environment parameter including the type of operating system, the type of browser and the type of network is generated to fully consider the influence of the environment difference on the test result, so as to ensure the smooth progress of the subsequent software testing task. It should be noted that the embodiments of the present application are described by taking the first environment parameter including the type of operating system, the type of browser and the type of network as an example, and in another embodiment, the first environment parameter can also be represented in other ways.

[0043] S302, obtaining the priority of the software testing task.

[0044] The priority of the software testing task is used to indicate the importance of the software testing task, and can also reflect the order of executing the software testing task by the server. The priority can be represented in any form, for example, the priority is represented in the form of a numerical value.

[0045] In a possible implementation manner, the step S302 includes: obtaining the business weight corresponding to the software testing task, the historical pass rate and the environment parameter failure rate. The business weight indicates the importance of the business to which the software testing task belongs. The historical pass rate indicates the success rate of the software testing task in the historical execution process. The environment parameter failure rate indicates the failure rate of the historical execution of the software testing task under the first environment parameter. The business weight, the historical pass rate and the environment parameter failure rate are processed by weighted summation to obtain the priority of the software testing task. In the embodiments of the present application, the business weight can reflect the importance of the business. The success rate of the software testing task in the historical execution process and the failure rate of the environment parameter generated for the software testing task both affect the importance of the software testing task. Therefore, the priority of the software testing task is obtained based on the business weight, the historical pass rate and the environment parameter failure rate to ensure the accuracy of the priority of the software testing task.

[0046] Optionally, the priority of the software testing task satisfies the following relationship:

[0047]

[0048] wherein, is used to indicate the priority of the software testing task, is the business weight, is the historical pass rate, is the environment parameter failure rate, are weight parameters respectively, and ; for example, are 0.5, 0.3 and 0.2 respectively.

[0049] S303, allocating a first server for the software test task from the plurality of servers based on the load information of the plurality of servers and the priority of the software test task.

[0050] In the embodiments of the present application, for the servers capable of processing software test tasks, some servers can only process software test tasks with low priorities, therefore, when allocating servers for software test tasks, the priorities of the software test tasks are also considered, so that the first server allocated for a software test task can execute the software test task with the priority, and the accuracy of task allocation is ensured. For example, the plurality of servers include a master server cluster and a secondary server cluster, and the priorities include 1 to 10, the master server cluster can process software test tasks with priorities of 6 to 10, and the secondary server cluster can process software test tasks with priorities of 1 to 5, if the priority of the current software test task to be allocated is 6, a server is allocated for the software test task from the master server cluster.

[0051] In a possible implementation manner, the load information includes at least one of a processor usage rate and a memory usage rate, and the step S303 includes: determining servers capable of processing the priority from the plurality of servers based on the priority of the software test task; determining load rates of the servers capable of processing the priority based on the load information of the servers capable of processing the priority; and determining a server with the lowest load rate from the servers capable of processing the priority as the first server based on the load rates of the servers capable of processing the priority.

[0052] In the embodiments of the present application, it is considered that the priorities of software test tasks capable of being processed by different servers can be different, therefore, for the current software test task to be allocated, the servers capable of processing the priority of the software test task are first screened based on the priority of the software test task, and then the load rates of the screened servers are determined according to the load information of the screened servers, and a server with the lowest load rate is selected to be allocated to the software test task, so that the accuracy of software test task allocation is ensured, and the loads of the servers are balanced as much as possible, and the performance of the servers is ensured. The load rate of a server can also be referred to as a load factor of the server, and can reflect the load of the server, and the load rate can be expressed in a numerical form; the processor usage rate and the memory usage rate can be expressed in a numerical form, for example, the processor usage rate and the memory usage rate are expressed in a percentage form.

[0053] Optionally, the scheduling server stores indication information of each server, the indication information being capable of indicating the priority that can be processed by each server, and the scheduling server filters the servers capable of processing the software test task based on the indication information and the priority of the software test task. Optionally, the load information comprises processor usage and memory usage, and the process of determining the load rate comprises: weighted sum of the processor usage and the memory usage to obtain the load rate of the server. In the embodiments of the present application, since the processor and memory resources are occupied during the execution of the task by the server, the weighted sum of the processor usage and the memory usage is adopted to determine the load rate, so as to ensure that the load rate can accurately reflect the load condition of each server, and the accuracy of the load rate is ensured.

[0054] Optionally, the load rate of the server satisfies the following relationship:

[0055]

[0056] wherein, is used to represent the load rate of the server, is used to represent the processor usage, is used to represent the memory usage, 0.6 is the weight of the processor usage, and 0.4 is the weight of the memory usage. In the embodiments of the present application, the weight coefficients in the load rate formula are optimized by grid search, and it is confirmed that the combination of 0.6 / 0.4 makes the task allocation balance best (variance <0.15). In the embodiments of the present application, when the load rate of the server is less than 0.5, the server can actively take a new software test task from the task pool of the scheduling server, or the scheduling server can allocate a new software test task to the server; when the load rate of the server is not less than 0.5, the scheduling server suspends the allocation of a new software test task to the server until the load rate of the server is less than 0.5.

[0057] S304, the software test task, the first environment parameter and the priority of the software test task are sent to the first server, so that the first server executes the software test task based on the first environment parameter, and the first server is used to execute the received software test task in the order from high to low according to the priority.

[0058] In the embodiment of the present application, after the first server is assigned to the software test task, the first server is not only sent the software test task, but also the first environment parameter and the priority of the software test task. Considering that the first server not only receives the software test task, but also possibly receives other tasks, since each task has a priority, the first server can execute each received task based on the order from high to low priority, and at the same time, when executing the software test task, it is executed based on the first environment parameter of the software test task, ensuring the smooth progress of the software test task.

[0059] In the embodiment of the present application, the scheduling server and each server have a communication connection established therebetween, so it can interact with each server based on the communication link with each server. That is, the scheduling server can send the software test task, the first environment parameter and the priority of the software test task to the first server based on the communication link with the first server.

[0060] It should be noted that the present application is described by taking the priority of the software test task as an example to determine the first server, and in another embodiment, without performing the above steps S302-S304, other ways are adopted to assign the first server to the software test task based on the load information of the plurality of servers, and send the software test task and the first environment parameter to the first server.

[0061] S305, in the case of receiving the first failure result, determining the second environment parameter based on the task retry strategy, the first failure result indicating that the execution of the software test task based on the first environment parameter fails, the second environment parameter indicating the execution environment of the re-execution of the software test task, the task retry strategy indicating the execution condition of the software test task and including the first sub-strategy, the second sub-strategy and the third sub-strategy, determining the environment parameter required for re-executing the software test task, and the environment parameter corresponding to different sub-strategies is determined in different ways.

[0062] In the embodiments of the present application, the task retry strategy includes three sub-strategies, i.e., a first sub-strategy, a second sub-strategy, and a third sub-strategy. The first sub-strategy indicates that the first environment parameter is determined as the environment parameter required for re-executing the software test task. If the second environment parameter is determined according to the first sub-strategy, it is equivalent to re-executing the software test task based on the original environment parameter. The second sub-strategy indicates that the environment parameter different from the first environment parameter in network type is determined as the environment parameter required for re-executing the software test task. If the second environment parameter is determined according to the second sub-strategy, it is equivalent to re-executing the software test task after switching the network type in the first environment parameter. The third sub-strategy indicates that the environment parameter different from the first environment parameter in operating system type or browser type is determined as the environment parameter required for re-executing the software test task. If the second environment parameter is determined according to the third sub-strategy, it is equivalent to re-executing the software test task after switching the operating system type or the browser type in the first environment parameter.

[0063] In a possible implementation manner, the process of determining the second environment parameter includes any of the following:

[0064] The first item: when the first failure result is received, the first environment parameter is determined as the second environment parameter based on the first sub-strategy. In the embodiments of the present application, the first sub-strategy, the second sub-strategy, and the third sub-strategy in the task retry strategy are different dimensions of the task retry strategy. The task retry strategy indicates the triggering time of each sub-strategy, and the triggering times of different sub-strategies are different. The triggering time of the first sub-strategy is the first execution failure of the software test task. When the first failure result is received, it indicates that the first execution of the software test task fails, which is equivalent to triggering the first sub-strategy. Then, the original environment parameter is taken as the environment parameter required for re-executing the software test task based on the first sub-strategy, so as to exclude the occasional interference in the test execution process and avoid the additional overhead and time consumption caused by directly switching the environment.

[0065] The second item is: when the first failure result and the second failure result are received, a second environment parameter containing a different network type from the first environment parameter is determined based on a second sub-strategy, and the second failure result indicates that the software test task is failed according to the first sub-strategy. In the embodiment of the present application, the triggering time of the second sub-strategy is that the software test task is failed based on the first sub-strategy. When the first failure result and the second failure result are received, it indicates that the software test task has been re-executed according to the indication of the first sub-strategy, and the test result is still failure, which is equivalent to triggering the second sub-strategy. The network type in the original environment parameter is adjusted based on the second sub-strategy to isolate and verify whether the network type is the root cause of the failure of the software test task, which can quickly identify defects existing in a specific network type, ensure the stability and user experience consistency of the software in different network types, and enhance the robustness of the product.

[0066] The third item is: when the first failure result, the second failure result and the third failure result are received, a second environment parameter containing a different browser type or a different operating system type from the first environment parameter is determined based on a third sub-strategy, and the third failure result indicates that the software test task is failed according to the second sub-strategy.

[0067] In the embodiment of the present application, the triggering time of the third sub-strategy is that the software test task is failed based on the second sub-strategy. When the first failure result, the second failure result and the third failure result are received, it indicates that the software test task has been re-executed according to the indication of the first sub-strategy and the sub-strategy, and the test result is still failure, which is equivalent to triggering the third sub-strategy. The browser type or the operating system type in the original environment parameter is retried based on the third sub-strategy to exclude the platform-specific problem of the operating system or the browser, which can effectively expose the defects of the software, significantly improve the coverage and depth of cross-platform testing through automatic environment switching, and further improve the test efficiency.

[0068] In a possible implementation manner, when the second environment parameter is determined according to the second sub-strategy, considering that the network types are various, each network type is switched in sequence to determine the environment parameter to ensure that the software test task can be retried in each network type if the software test task is failed. That is, the manner of determining the second environment parameter according to the second sub-strategy includes the following two manners.

[0069] The first approach: Upon receiving both a first failure result and a second failure result, based on the second sub-strategy, the first third environment parameter is determined as the second environment parameter. This third environment parameter differs from the network type in the first environment parameter. In this embodiment, since multiple network types exist, switching the network type in the first environment parameter can yield multiple third environment parameters. The browser type and operating system type in both the first and multiple third environment parameters are the same; the only difference is the included network type. The first third environment parameter is any environment parameter that includes a different network type than the first environment parameter. For example, if the original environment parameter's network type is Wi-Fi, then it switches to 5G / 4G; if the original environment parameter's network type is a mobile network, then it switches to a different operator's network.

[0070] The second approach: When the first failure result, the second failure result, and the (i-1)th fourth failure result are received, based on the second sub-strategy, the i-th third environment parameter is determined as the second environment parameter, and the (i-1)th fourth failure result indicates that the software testing task failed to be executed based on the (i-1)th third environment parameter. The network types in different third environment parameters are different, where i is a positive integer greater than 1 and less than P, and P is the number of network types. In this embodiment, since there are multiple network types, when changing the network type in the first environment parameter according to the second sub-strategy, the network type in the first environment parameter is first switched to another network type to obtain a new environment parameter. Then, according to the above steps S303-S304, the software test task and the new environment parameter are sent to other servers for execution. If the server still returns a failure result, that is, if the first fourth failure result is received, the network type in the environment parameter will be switched again, and the above steps S303-S304 will be sent to other servers for execution. If the server still returns a failure result, that is, if the second fourth failure result is received, the network type in the environment parameter will be switched again. This process continues until the software test task is successfully executed or the software test task has been executed based on environment parameters including each network type.

[0071] Optionally, taking the number of network types as P for example, the process of determining the second environment parameter based on the third sub-strategy includes: when the first failure result, the second failure result and the P-1th fourth failure result are received, determining the second environment parameter including different operating system types or different browser types based on the third sub-strategy. In the embodiment of the present application, when the network type is switched to retry the execution of the software test task for the first environment parameter, if the retry is performed based on each network type, when the P-1th fourth failure result is received, it is equivalent to receiving the third failure result, and then the environment parameter is updated based on the third sub-strategy, so as to ensure the accuracy of the timing of triggering the third sub-strategy, ensure the accuracy of updating the environment parameter, and further ensure the smooth progress of the subsequent software test task.

[0072] In a possible implementation manner, when the second environment parameter is determined according to the third sub-strategy, considering that the types of operating system types or browser types are more, the operating system types or browser types are switched in sequence to determine the environment parameter, so as to ensure that the software test task can be retried under each operating system type or browser type when the software test task fails. That is, the manner of determining the second environment parameter according to the third sub-strategy includes the following two manners.

[0073] The first manner: when the first failure result, the second failure result and the third failure result are received, the 1st fourth environment parameter is determined as the second environment parameter based on the third sub-strategy, and the fourth environment parameter is different from the operating system type or the browser type in the first environment parameter. In the embodiment of the present application, since there are multiple operating system types or multiple browser types, when the operating system type or the browser type in the environment parameter is switched, multiple fourth environment parameters can be obtained, and the browser type or the operating system type in the first environment parameter and the multiple fourth environment parameters are different. The 1st fourth environment parameter is any environment parameter including different browser types or different operating system types from the first environment parameter.

[0074] The second: when the first failure result, the second failure result, the third failure result and the jth fifth failure result are received, the j+1th fourth environment parameter is determined as the second environment parameter, the jth fifth failure result indicates that the software test task based on the jth fourth environment parameter fails, the operating system type or the browser type in different fourth environment parameters is different, and j is a positive integer. In the embodiment of the application, since there are multiple operating system types or multiple browser types, when the operating system type or the browser type in the environment parameter is replaced according to the third sub-strategy, the operating system type or the browser type in the environment parameter is switched first to obtain a new environment parameter, and then the software test task and the new environment parameter are sent to other servers for execution according to the steps S303-S304. If the failure result returned by the server is still received, that is, if the first fifth failure result is received, the operating system type or the browser type in the environment parameter is switched again, and then the software test task and the new environment parameter are sent to other servers for execution according to the steps S303-S304. If the failure result returned by the server is still received, that is, if the second fifth failure result is received, the operating system type or the browser type in the environment parameter is switched again, and the subsequent is the same. Until the software test task is executed successfully or has been executed based on the environment parameters including each operating system type or each browser type.

[0075] It should be noted that the embodiments of the present application are described by taking the above examples of determining the second environment parameter according to any one of the three sub-strategies respectively, and in another embodiment, in the process of testing a certain software testing task, the software testing task is first allocated to a certain server to execute according to the above steps S301-S304. If the software testing task fails to execute for the first time, a new environment parameter is determined based on the first sub-strategy, and then the software testing task is re-allocated to a certain server to execute. If the software testing task still fails to execute based on the first sub-strategy, a new environment parameter is determined based on the second sub-strategy, and then the software testing task is re-allocated to a certain server to execute; and in the process of executing the software testing task based on the second sub-strategy, since there are multiple network types, the software testing task may be executed once for each network type. If the software testing task still fails to execute based on the second sub-strategy, a new environment parameter is determined based on the third sub-strategy, and then the software testing task is re-allocated to a certain server to execute; and in the process of executing the software testing task based on the third sub-strategy, since there are multiple operating system types or browser types, the software testing task may be executed based on multiple environment parameters obtained by combining each operating system type or each browser type. Moreover, in the process of retrying the software testing task, if the software testing task is executed successfully based on any sub-strategy, subsequent retries are terminated. For example, three-dimensional retry execution of the software testing task is as follows: after the software testing task fails to execute under the first environment parameter: first-dimensional retry is performed: the environment is kept unchanged, and the software testing task is retried after resetting the browser session; if the first-dimensional retry fails, second-dimensional retry is performed: switching to a network type, and retrying 3 times (with an interval of 2 seconds); if the second-dimensional retry fails, third-dimensional retry is performed: if it still fails, switching to a browser type or an operating system type to execute.

[0076] It should be noted that the embodiments of the present application are described by taking the above examples of determining the second environment parameter according to any one of the three sub-strategies respectively, and in another embodiment, in another embodiment, the task retry strategy indicates the environment parameters required to re-execute the software testing task based on the execution of the software testing task and the multiple sub-strategies included.

[0077] S306, based on the load information of the multiple servers and the priority of the software testing task, a second server is allocated to the software testing task from the multiple servers, and the software testing task, the second environment parameter and the priority of the software testing task are sent to the second server, so that the second server executes the software testing task based on the second environment parameter, and the second server is used to execute the received software testing task in order from high to low according to the priority.

[0078] It should be noted that the step S306 is the same as the steps S303-S304 described above, and will not be repeated here. The embodiment of the application is based on the priority to allocate the second server as an example for description, and in another embodiment, the step S306 described above is not required to be performed, and other ways are adopted to allocate the second server for the software test task based on the load information of the plurality of servers, to send the software test task and the second environment parameter to the second server, so that the second server executes the software test task based on the second environment parameter. The software test method provided by the embodiment of the application generates and binds accurate environment parameters for the test task, intelligently allocates the task to the optimal server for execution according to the real-time server load, and at the same time, introduces a multi-sub-policy retry mechanism based on the task execution situation: when the task fails, the system can dynamically select and switch to more reasonable environment parameters according to the historical execution situation and the preset task retry policy, and at the same time, re-allocate the task to the optimal server for execution in combination with the load state of each server. In this way, double optimization of environment scheduling and resource scheduling is realized, invalid retries are reduced, and the test efficiency and resource utilization of the software test task are improved.

[0079] Based on the embodiment shown in the above Figure 2 In the embodiment of the application, based on the task identifier of the software test task, a plurality of environment parameters are generated first, so as to select the environment parameters for executing the software test task subsequently, and in the process of selecting the environment parameters, the test identifier corresponding to the environment parameters is also considered, so as to ensure that the software test task is executed only once based on each environment parameter. The specific process is described in detail in the following embodiment. Figure 2 Flowchart of the software test method provided by the embodiment of the application Figure 2 As shown in the above Figure 2 Taking the method executed by the scheduling server as an example, the method comprises the following steps.

[0080] S401, based on the task identifier of the software test task, a plurality of environment parameters are generated, and the plurality of environment parameters comprise a first environment parameter, and the first environment parameter indicates the execution environment of the software test task.

[0081] In the embodiment of the application, at least one operating system type, at least one browser type and at least one network type are set in the scheduling server, then for the task identifier of the software test task, the operating system type, the browser type and the network type can be combined, and a plurality of environment parameters can be obtained, so as to fully consider the influence of the operating system type, the browser type, the network type and various combinations on the software test task, to ensure that the software test task can be executed smoothly subsequently. In the embodiment of the application, any environment parameter in the plurality of environment parameters can be determined as the first environment parameter.

[0082] In a possible implementation manner, the plurality of environment parameters can constitute an environment parameter matrix corresponding to the software test task, and the environment parameter matrix satisfies the following relationship:

[0083]

[0084] wherein, is used to represent an environment adoption number matrix, represents the kth operating system type, represents the mth browser type, represents the nth network type, is the number of operating system types, is the number of browser types, is the number of network types.

[0085] S402, generating a first test identifier according to the first environment parameter and the task identifier of the software test task, and storing the first test identifier.

[0086] In the embodiment of the application, the first test identifier is generated based on the first environment parameter and the task identifier of the software test task, to ensure the uniqueness of the first test identifier, and the first test identifier is stored, so that the environment parameters can be deduplicated based on the test identifier in the future, and it is determined that the software test task is executed only once based on each environment parameter. The task identifier can be represented in any form, for example, the task identifier is represented in the name or number of the software test task. The network type, the browser type and the operating system type in the first environment parameter can be represented in any form, for example, the network type, the browser type and the operating system type are represented in the name or code thereof. The first test identifier can be represented in any form, for example, the first test identifier can be represented in the form of a hash value.

[0087] In a possible implementation manner, the first test identifier satisfies the following relationship:

[0088]

[0089] wherein, is used to represent the first test identifier; is used to represent a hash algorithm, for example, a SHA-256 hash algorithm; is used to represent the task identifier of the software test task, is used to represent the operating system type, is used to represent the browser type, is used to represent the network type.

[0090] For example, the task identifier of the input software test task is automatically generate a plurality of environment parameters, the plurality of environment parameters being represented as E = { (Win11, Chrome 108, WiFi), (macOS13, Firefox 110, 5G),...}, taking (Win11, Chrome 108, WiFi) as a first environment parameter as an example, a first test identifier is calculated, that is, an environment fingerprint is calculated: the first test identifier can be represented as The first test identifier is stored in Redis for deduplication.

[0091] S403, based on the load information of the plurality of servers, a first server is allocated to the software test task from the plurality of servers, and the software test task and the first environment parameter are sent to the first server, so that the first server executes the software test task based on the first environment parameter.

[0092] It should be noted that this step is the same as step S202 described above, and will not be described here.

[0093] S404, in the case where the first failure result is received, a second environment parameter is determined from the plurality of environment parameters based on a task retry strategy, the first failure result indicating that the execution of the software test task based on the first environment parameter fails, the second environment parameter indicating an execution environment for re-executing the software test task, the task retry strategy indicating an execution condition of the software test task and including a first sub-strategy, a second sub-strategy and a third sub-strategy, and the environment parameter required for re-executing the software test task is determined, and the environment parameter determination manners corresponding to different sub-strategies are different.

[0094] In the embodiments of the present application, the task retry strategy includes three sub-strategies, namely, a first sub-strategy, a second sub-strategy and a third sub-strategy; wherein the first sub-strategy indicates that the first environment parameter is determined as the environment parameter required for re-executing the software test task; if the second environment parameter is determined according to the first sub-strategy, it is equivalent to re-executing the software test task based on the original environment parameter subsequently. The second sub-strategy indicates that the environment parameter including a different network type from the first environment parameter is determined as the environment parameter required for re-executing the software test task; if the second environment parameter is determined according to the second sub-strategy, it is equivalent to re-executing the software test task after switching the network type in the first environment parameter. The third sub-strategy indicates that the environment parameter including a different operating system type or a different browser type from the first environment parameter is determined as the environment parameter required for re-executing the software test task; if the second environment parameter is determined according to the third sub-strategy, it is equivalent to re-executing the software test task after switching the operating system type or the browser type in the first environment parameter.

[0095] In a possible implementation, the step S404 includes: screening out invalid environment parameters from the plurality of environment parameters based on test history data, the history data indicating historical execution of the software test task; and determining the second environment parameter from the remaining environment parameters after the screening out based on the task retry strategy. In the embodiment of the present application, the invalid environment parameters are screened out from the plurality of environment parameters based on the test history data, so that the second environment parameter can be determined from the remaining environment parameters after the screening out based on the task retry strategy, which avoids the interference of the invalid environment parameters and ensures the accuracy of the second environment parameter, thereby ensuring the smooth progress of the subsequent software test task and further ensuring the test efficiency.

[0096] It should be noted that the embodiment of the present application is described by taking the example of generating the plurality of environment parameters first and then selecting the environment parameters for the software test task, and in another embodiment, the steps S401 and S404 are not performed, but other manners are adopted to generate the first environment parameter based on the software test task and determine the second environment parameter for the software test task based on the task retry strategy.

[0097] It should be noted that the embodiment of the present application is described by taking the example of the task retry strategy including the first sub-strategy, the second sub-strategy and the third sub-strategy, and in another embodiment, the task retry strategy indicates the execution of the software test task and the plurality of sub-strategies included, and determines the environment parameter required for re-executing the software test task.

[0098] S405, based on the load information of the plurality of servers, assigning the second server for the software test task from the plurality of servers.

[0099] It should be noted that the step S405 is the same as the step S204 described above, and will not be described here.

[0100] S406, in a case where the second environment parameter is determined based on the second sub-strategy or the third sub-strategy, generating a second test identifier based on the second environment parameter and a task identifier of the software test task.

[0101] In the embodiment of the present application, in a case where the second environment parameter is determined based on the second sub-strategy or the third sub-strategy, the second environment parameter is different from the first environment parameter, and therefore, in order to ensure that the software test task is executed only once based on the same environment parameter, a second test identifier is generated based on the second environment parameter and the task identifier of the software test task, so as to be checked based on the stored test identifier, thereby ensuring that the software test task is executed only once based on the same environment parameter.

[0102] S407, querying from the stored test identifier based on the second test identifier.

[0103] The stored test identifier includes the first test identifier or other test identifiers.

[0104] S408, in the case where the second test identifier is not queried, sending the software test task and the second environment parameter to the second server, so that the second server executes the software test task based on the second environment parameter.

[0105] In the embodiment of the present application, the second test identifier is not queried, which means that the software test task will be executed based on the second environment parameter. Therefore, the software test task can be executed based on the second environment parameter in the future. Therefore, the software test task and the second environment parameter are sent to the second server so that the second server executes them. It should be noted that the present application is described by using the test identifier to verify the environment parameter as an example. In another embodiment, the above steps S402 and S406-S408 are not executed, and other ways are adopted to send the software test task and the second environment parameter to the second server so that the second server executes the software test task based on the second environment parameter.

[0106] The software test method provided by the embodiment of the present application generates and binds accurate environment parameters for test tasks, intelligently distributes tasks to optimal servers for execution according to real-time server load, introduces a multi-sub-policy retry mechanism based on task execution: when a task fails, the system can dynamically select and switch to more reasonable environment parameters according to historical execution and preset task retry policies, and re-distribute tasks to optimal servers for execution in combination with the load status of each server. In this way, double optimization of environment scheduling and resource scheduling is realized, invalid retries are reduced, and the test efficiency and resource utilization of the software test task are improved. Moreover, the test identifier is determined by means of hash calculation, which can ensure the uniqueness of the test identifier and the accuracy of the test.

[0107] In the above Figure 2Based on the illustrated embodiments, in this application embodiment, the scheduling server can also employ a task stealing mechanism and a task migration mechanism to schedule software testing tasks allocated to different servers, thereby balancing the load rate of each server. Regarding the task stealing mechanism, low-load servers can be controlled to steal software testing tasks from the task queues of high-load servers, reducing the number of tasks in the high-load server's task queue and lowering its load rate. Regarding the task migration mechanism, when a server is continuously overloaded for more than a preset duration, the server is controlled to migrate a preset proportion of software testing tasks in its task queue to idle servers, so that the idle servers can execute the received software testing tasks. The preset duration is arbitrary, for example, 5 minutes, and the preset proportion is arbitrary, for example, 50%. For example, when the load rate of server A is L=0.4 (processor 35%, memory 55%), it actively retrieves 5 high-priority use cases (priority > 0.8) from the task pool; when the load rate of server B is L=0.6, load protection is triggered, new task allocation is suspended, and the task theft mechanism is activated to migrate 20% of the tasks to server C.

[0108] In the above Figure 2 Based on the illustrated embodiments, in this application embodiment, if the software test task still fails to execute according to the above-described task retry strategy, an environment parameter stability heatmap will be generated based on the test identifier and historical test data corresponding to the software test task. This heatmap will represent the failure rate of different combinations of environment parameters, allowing for a visual representation of the environment parameter stability heatmap for easy viewing by users. For example, the generated environment parameter stability heatmap shows that browser type 1 has a failure rate as high as 42% under operating system type 2. It is recommended that subsequent tests prioritize verifying environment parameters that include browser type 1 under operating system type 2. The three-dimensional retry mechanism improves the pass rate by 67% and reduces the average execution time by 31%.

[0109] Based on the embodiments shown above, this application also provides a multi-server collaborative software testing system. Figure 1 A schematic diagram of a multi-server collaborative software testing system provided in this application embodiment. Figure 2 ,like Figure 1As shown, it comprises: an environment matrix generation module, a dynamic scheduling engine, a three-dimensional retry execution module, and an intelligent report generation module. The environment matrix generation module is configured to dynamically construct and manage a set of test environment parameters. The dynamic scheduling engine includes a priority calculation unit, a load monitoring unit, and a task allocation unit. The priority calculation unit is used to calculate the priority of software testing tasks. The load monitoring unit is used to collect the processor usage and memory usage of the server in real time. The load monitoring unit collects data at a period of 5 seconds and triggers an alarm when the processor usage is > 80% or the memory usage is > 75%. The task allocation unit is used to allocate tasks based on the load state of the server. The three-dimensional retry execution module includes an environment reset unit and a retry control unit. The environment reset unit is used to switch the network type, browser type, or operating system type in the environment parameters. The retry control unit triggers multi-dimensional retries in a predetermined order, i.e., retries based on multiple sub-strategies in the task retry strategy in a predetermined order. The three-dimensional retry execution module also includes an environment dependency analysis unit and a retry path optimization unit. The environment dependency analysis unit is used to automatically skip invalid environment parameter retries based on test history data. The retry path optimization unit is used to prioritize switching the environment dimension with the highest failure rate for software testing tasks that have failed multiple times. The three-dimensional retry execution module integrates the Selenium Grid (an execution tool) environment switching function and supports quickly rebuilding the operating system or browser container through Docker (a containerization platform). The intelligent report generation module is used to generate a visual test report with environment combination analysis. The dynamic scheduling engine is used to implement a task stealing mechanism and a task migration mechanism. The task stealing mechanism refers to a low-load server actively stealing tasks from the task queue of a high-load server. The task migration mechanism refers to automatically migrating 50% of the tasks of a server to an idle server when the server is continuously overloaded for more than 5 minutes.

[0110] In one possible implementation, the environment matrix generation module is deployed on a central scheduling server, has an environment combination database built-in, and stores environment parameters composed of operating system types, browser types, and network types. In one possible implementation, the priority calculation unit is configured with weight coefficients of a = 0.5, b = 0.3, and g = 0.2, and obtains real-time data from a test management platform. The load monitoring unit is used to collect server indicators through Prometheus (a system monitoring and alarm toolkit) and calculate the load rate L (the weight of the processor usage is 0.6 and the weight of the memory usage is 0.4).

[0111] It should be noted that the software testing system provided by the embodiments of the present application is only described by taking the above multiple modules as an example, and in another embodiment, the software testing system comprises a scheduling server and multiple servers, and the environment matrix generation module, the dynamic scheduling engine, the three-dimensional retry execution module, and the intelligent report generation module are all deployed in the scheduling server.

[0112] On the basis of the above-mentioned embodiments, the application further provides a flow diagram for generating environment parameters Figure 2 As shown in the figure, the method comprises the following steps: Figure 2 S601, inputting a software testing task; S602, reading environment configuration parameters; S603, judging whether it is cross-border testing; if yes, executing step S604; if no, executing step S605; S604, adding cross-border network types; S605, configuring local network types; S606, generating environment parameters; S607, calculating a testing identifier (i.e. environment fingerprint) based on the software testing task and the environment parameters; S608, generating an environment parameter matrix; and S609, outputting a task queue with the testing identifier.

[0113] On the basis of the above-mentioned embodiments, the application further provides a flow diagram for retrying based on a task retry strategy Figure 2 As shown in the figure, the method comprises the following steps: Figure 2 S701, obtaining a software testing task to be distributed; S702, calculating the priority of the software testing task; S703, detecting the load rate of a server cluster; S704, if the load rate of each server is not less than 0.5, detecting an overloaded server; S705, judging whether there is a server that has been overloaded for 5 minutes continuously; if yes, executing step S706; if no, executing step S707; S706, migrating 50% of the software testing tasks in the task queue of the server that has been overloaded for 5 minutes continuously to an idle server; S707, adding the software testing task to a waiting queue to wait for the load rate of the server to be lower than 0.5 before distributing the software testing task to the server; S708, if there is a server with a load rate lower than 0.5, distributing the software testing task to the server with the lowest load rate; S709, executing the software testing task by the server; S710, judging whether the software testing task is executed completely; if no, executing step S711; if yes, executing step S712; S711, marking the task as a failed execution; S712, updating the load rate of the server; S713, if the task stealing mechanism is triggered, judging whether there is a high-load server; S714, if there is a high-load server, stealing the software testing task from the high-load server; S715, if there is no high-load server, waiting for a new task.

[0114] On the basis of the above-mentioned embodiments, the application further provides a flow diagram for retrying based on a task retry strategy Figure 2 As shown in the figure, the method comprises the following steps: Figure 2As shown, taking the main server executing as an example, the method comprises: S801, if the software test task fails during execution of the assigned software test task, the main server sends a failure result to the retry control unit. S802, after receiving the failure result, the retry control unit requests the first dimension retry (original environment parameters) from the environment reset unit. S803, after resetting the environment parameters, the environment reset unit sends the reset environment parameters to the retry control unit. S804, the retry control unit sends the reset environment parameters to the main server to make the main server re-execute the software test task. S805, if the main server executes successfully, it sends a success result to the retry control unit, and if the main server fails, it sends a failure result to the retry control unit. S806, if the execution fails, the retry control unit requests the second dimension retry (switching network type) from the environment reset unit. S807, after resetting the environment parameters, the environment reset unit sends the reset environment parameters to the retry control unit. S808, the retry control unit sends the reset environment parameters to the main server to make the main server re-execute the software test task. S809, if the main server executes successfully, it sends a success result to the retry control unit, and if the main server fails, it sends a failure result to the retry control unit. S810, if the execution fails, the retry control unit requests the third dimension retry (switching operating system type or browser type) from the environment reset unit. S811, after resetting the environment parameters, the environment reset unit sends the reset environment parameters to the retry control unit. S812, the retry control unit sends the reset environment parameters to the main server to make the main server re-execute the software test task. S813, the main server will subsequently return the final execution result.

[0115] In the scheme provided by the embodiment of the application, a multi-dimensional environment parameter matrix is constructed and a unique environment fingerprint is generated, so that each software test task is executed under a unique environment parameter, and redundancy or omission is avoided. In cooperation with a three-dimensional retry mechanism, the system can accurately identify errors caused by network, operating system or browser differences, and effectively improve the accuracy of test results and cross-platform environment coverage. By using a dynamic scheduling engine, in combination with real-time load monitoring and task priority calculation, the master and auxiliary servers are cooperatively allocated tasks. By introducing a task stealing and migration mechanism, the server cluster load is balanced, resource idling or congestion is effectively avoided, the overall server utilization is improved, and the test cycle is significantly shortened. Through the binding mechanism of failed software test tasks and environment fingerprints, in combination with an intelligent report generation module, the system can automatically attribute the error occurrence to the environment dimension, and generate an environment stability heat map. This method not only improves the defect detection rate, but also speeds up the problem positioning and repair efficiency, avoiding the cumbersome process of traditional manual analysis. Moreover, combination testing of multiple network types and operating systems and browsers is supported, which is suitable for real complex cross-regional and cross-device scenarios. The test strategy can be dynamically adjusted to cope with overseas user experience differences and regional network instability problems, improve the global adaptation capability of software, and ensure comprehensive testing and efficient use of system resources, so as to improve the testing accuracy and efficiency.

[0116] Figure 2 Structure of the software testing device provided by the embodiment of the application Figure 2 As shown in Figure 2 , the device comprises:

[0117] The generating module 901 is configured to generate a first environment parameter based on a software test task, the first environment parameter indicating an execution environment of the software test task.

[0118] The sending module 902 is configured to allocate a first server for the software test task from a plurality of servers based on load information of the plurality of servers, and send the software test task and the first environment parameter to the first server, so that the first server executes the software test task based on the first environment parameter.

[0119] The determining module 903 is configured to determine a second environment parameter based on a task retry strategy in the case of receiving a first failure result, the first failure result indicating that the execution of the software test task based on the first environment parameter fails, the second environment parameter indicating an execution environment of re-executing the software test task, the task retry strategy indicating an execution condition of the software test task and a plurality of sub-strategies included, determining the environment parameter required for re-executing the software test task, and the environment parameter determined by different sub-strategies being different.

[0120] The sending module 902 is further configured to assign a second server for the software test task from the plurality of servers based on the load information of the plurality of servers, and send the software test task and the second environment parameter to the second server, so that the second server executes the software test task based on the second environment parameter.

[0121] In another possible implementation, the first environment parameter comprises an operating system type, a browser type and a network type; the plurality of sub-strategies comprises a first sub-strategy, a second sub-strategy and a third sub-strategy; the first sub-strategy indicates that the first environment parameter is determined as an environment parameter required for re-executing the software test task; the second sub-strategy indicates that an environment parameter comprising a different network type from the first environment parameter is determined as an environment parameter required for re-executing the software test task; and the third sub-strategy indicates that an environment parameter comprising a different operating system type or a different browser type from the first environment parameter is determined as an environment parameter required for re-executing the software test task.

[0122] The description of the features in the embodiments of the software testing apparatus provided by the present application can be referred to the related description of the embodiments of the software testing method, which will not be repeated here.

[0123] Figure 2 The structure schematic diagram of the electronic device provided by the present application is shown in the figure. Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 Figure 2 As shown in the figure, the electronic device provided by the present application comprises at least one processor 1001 and a memory 1002. Optionally, the device further comprises a communication component 1003. The processor 1001, the memory 1002 and the communication component 1003 are connected through a bus. In the specific implementation process, the at least one processor 1001 executes the computer execution instructions stored in the memory 1002, so that the at least one processor 1001 executes the above-mentioned software testing method embodiments. The specific implementation process of the processor 1001 can be referred to the above-mentioned method embodiments, which has similar implementation principles and technical effects, and will not be repeated here.

[0124] In the above-mentioned embodiments, it should be understood that the processor can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC) and the like. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor and the like. The steps of the method disclosed in the application can be directly embodied as hardware processor execution, or executed by a combination of hardware and software modules in the processor.

[0125] The memory can include a random access memory (RAM) and can also include a non-volatile memory (NVM), such as at least one disk memory. The bus can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application does not limit to only one bus or one type of bus.

[0126] Embodiments of the present application further provide a computer readable storage medium, which stores a computer program. The computer program is configured to execute the steps of any of the above software testing method embodiments when running. In an example embodiment, the above computer readable storage medium can include, but is not limited to, a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various computer program storage media.

[0127] Embodiments of the present application further provide a computer program product, which includes a computer program. The computer program is executed by a processor to implement the steps of any of the above software testing method embodiments. Embodiments of the present application further provide another computer program product, which includes a non-volatile computer readable storage medium. The non-volatile computer readable storage medium stores a computer program. The computer program is executed by a processor to implement the steps of any of the above software testing method embodiments.

[0128] The skilled person can further realize that the units and algorithm steps of the examples described in connection with the embodiments disclosed herein can be realized in electronic hardware, computer software, or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been described in general terms in the above description. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0129] The above describes in detail the software testing method, device, equipment and storage medium provided by the present application. The principles and implementation modes of the present application are described by applying specific examples, and the above description of the embodiments is only used to help understand the method of the present application and its core idea. It should be pointed out that, for those skilled in the art, without departing from the principles of the present application, the present application can be improved and modified in several ways, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A software testing method characterized by, The method comprises: generating a first environment parameter based on a software test task, the first environment parameter indicating an execution environment of the software test task; the software test task being a test case; allocating a first server for the software test task from a plurality of servers based on load information of the plurality of servers, sending the software test task and the first environment parameter to the first server, so that the first server executes the software test task based on the first environment parameter; the first server being a server with the lowest load rate among the plurality of servers; in a case where a first failure result is received, determining a second environment parameter based on a task retry strategy, the first failure result indicating that the execution of the software test task based on the first environment parameter fails, the second environment parameter indicating an execution environment for re-executing the software test task, the task retry strategy indicating that the environment parameter required for re-executing the software test task is determined based on the execution of the software test task and a plurality of sub-strategies included, and different sub-strategies correspond to different environment parameter determination manners; allocating a second server for the software test task from the plurality of servers based on the load information of the plurality of servers, sending the software test task and the second environment parameter to the second server, so that the second server executes the software test task based on the second environment parameter; the second server being a server with the lowest load rate among the plurality of servers; the first environment parameter comprises an operating system type, a browser type and a network type; the plurality of sub-strategies comprises a first sub-strategy, a second sub-strategy and a third sub-strategy; wherein the first sub-strategy indicates that the first environment parameter is determined as the environment parameter required for re-executing the software test task; the second sub-strategy indicates that an environment parameter including a different network type from the first environment parameter is determined as the environment parameter required for re-executing the software test task; and the third sub-strategy indicates that an environment parameter including a different operating system type or a different browser type from the first environment parameter is determined as the environment parameter required for re-executing the software test task; the determining of the second environment parameter based on the task retry strategy in a case where the first failure result is received comprises any one of the following: when the first failure result is received, the first environment parameter is determined as the second environment parameter based on the first sub-strategy; when the first failure result and a second failure result are received, the second environment parameter including a different network type from the first environment parameter is determined based on the second sub-strategy, the second failure result indicating that the execution of the software test task according to the first sub-strategy fails; when the first failure result, the second failure result and a third failure result are received, the second environment parameter including a different operating system type or a different browser type from the first environment parameter is determined based on the third sub-strategy, the third failure result indicating that the execution of the software test task according to the second sub-strategy fails.

2. The method of claim 1, wherein, Before the assigning the first server for the software test task from the plurality of servers based on the load information of the plurality of servers, the method further comprises: obtaining a priority of the software test task; the assigning the first server for the software test task from the plurality of servers based on the load information of the plurality of servers comprises: assigning the first server for the software test task from the plurality of servers based on the load information of the plurality of servers and the priority of the software test task; the method further comprises: sending the priority of the software test task to the first server, and the first server is configured to execute the received software test task in a descending order of priority.

3. The method of claim 2, wherein, the obtaining the priority of the software test task comprises: obtaining a business weight, a historical pass rate and an environment parameter failure rate corresponding to the software test task, the business weight indicating an importance of a business to which the software test task belongs, the historical pass rate indicating a success rate of the software test task in a historical execution process, and the environment parameter failure rate indicating a failure rate of the software test task in a historical execution under the first environment parameter; performing weighted sum processing on the business weight, the historical pass rate and the environment parameter failure rate to obtain the priority of the software test task.

4. The method of claim 2, wherein, The load information comprises at least one of a processor usage rate and a memory usage rate; the assigning the first server for the software test task from the plurality of servers based on the load information of the plurality of servers and the priority of the software test task comprises: determining a server capable of processing the priority from the plurality of servers based on the priority of the software test task; determining a load rate of the server capable of processing the priority based on the load information of the server capable of processing the priority; determining the server with the lowest load rate from the servers capable of processing the priority as the first server based on the load rate of the server capable of processing the priority.

5. The method of claim 1, wherein, The determining the second environment parameter containing a different network type from the first environment parameter based on the second sub-strategy when the first failure result and the second failure result are received comprises any of the following: determining a first third environment parameter as the second environment parameter based on the second sub-strategy when the first failure result and the second failure result are received, the third environment parameter being different from the network type in the first environment parameter; determining an i-th third environment parameter as the second environment parameter based on the second sub-strategy when the first failure result, the second failure result and an i-1-th fourth failure result are received, the i-1-th fourth failure result indicating that the software test task fails to be executed based on an i-1-th third environment parameter, the different third environment parameters being different in network type, i being a positive integer greater than 1 and less than P, and P being a number of network types.

6. The method of claim 5, wherein, The determining, when the first failure result, the second failure result and the third failure result are received, the second environment parameter including a different operating system type or a different browser type from the first environment parameter based on the third sub-strategy includes: The determining, when the first failure result, the second failure result and the P-1th fourth failure result are received, the second environment parameter including a different operating system type or a different browser type from the first environment parameter based on the third sub-strategy.

7. The method of claim 1, wherein, The determining, when the first failure result, the second failure result and the third failure result are received, the second environment parameter including a different operating system type or a different browser type from the first environment parameter based on the third sub-strategy includes at least one of: The determining, when the first failure result, the second failure result and the third failure result are received, the first fourth environment parameter as the second environment parameter based on the third sub-strategy, the fourth environment parameter being different from the operating system type or the browser type in the first environment parameter; The determining, when the first failure result, the second failure result, the third failure result and the jth fifth failure result are received, the j+1th fourth environment parameter as the second environment parameter, the jth fifth failure result indicating that the software testing task based on the jth fourth environment parameter fails, the different fourth environment parameters being different in the operating system type or the browser type, and j being a positive integer.

8. The method of claim 1, wherein, The method further includes, before the sending, to the first server, the software testing task and the first environment parameter: Generating a first test identifier according to the first environment parameter and a task identifier of the software testing task, and storing the first test identifier; The method further includes, before the sending, to the second server, the software testing task and the second environment parameter: Generating a second test identifier according to the second environment parameter and the task identifier of the software testing task in a case where the second environment parameter is determined based on the second sub-strategy or the third sub-strategy; Querying from the stored test identifiers based on the second test identifier; The sending, to the second server, the software testing task and the second environment parameter includes: In a case where the second test identifier is not queried, sending, to the second server, the software testing task and the second environment parameter.

9. The method according to any one of claims 1 to 8, characterized in that, The generating, based on the software testing task, the first environment parameter includes: Generating a plurality of environment parameters based on a task identifier of the software testing task, the plurality of environment parameters including the first environment parameter; The determining, based on the task retry strategy, the second environment parameter for the software testing task includes: Determining the second environment parameter from the plurality of environment parameters based on the task retry strategy.

10. The method of claim 9, wherein, The method further includes, before the determining, based on the task retry strategy, the second environment parameter from the plurality of environment parameters: screening out invalid environment parameters from the plurality of environment parameters based on test historical data, the historical data indicating a case of historically performing a software test task; the determining the second environment parameter from the plurality of environment parameters based on the task retry strategy comprises: the determining the second environment parameter from the plurality of environment parameters based on the task retry strategy comprises: the determining the second environment parameter from the plurality of environment parameters based on the task retry strategy comprises: the determining the second environment parameter from the plurality of environment parameters based on the task retry strategy comprises: the determining the second environment parameter from the plurality of environment parameters based on the task retry strategy comprises: the determining the second environment parameter from the plurality of environment parameters based on the task retry strategy comprises: the determining the second environment parameter from the plurality of environment parameters based on the task retry strategy comprises: the determining

Images