Software testing method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a software testing method and device, electronic equipment, a storage medium and a product, and relates to the field of software testing. For example, the method can be used for software corresponding to the field of distributed databases, and the method comprises the steps that a target program is obtained, the target program comprises a to-be-tested program and an error injection function of the to-be-tested program, and the error injection function is used for triggering at least one exception when the to-be-tested program is subjected to load testing; the to-be-tested program comprises a program code used for processing the exception triggered by the error injection function; executing the test task through the target program to perform load test on the to-be-tested program; and respectively obtaining the number of started coroutines before and after the target program executes the test task, and judging whether the coroutine leakage test of the to-be-tested program is successful or not. According to the embodiment of the invention, the coroutine leakage test of the to-be-tested program under the scene that a large number of abnormities exist in the high load is realized.

Description

Technical Field

[0001] The present application relates to the fields of computer technology and software testing technology. Specifically, the present application relates to a software testing method, device, electronic equipment and computer storage medium. Background Art

[0002] Software testing is the process of ensuring that software products meet expected quality standards. It involves verifying whether the functionality, performance, security, usability and other aspects of the software meet design requirements and user needs.

[0003] Goroutine leakage refers to the situation in which the created goroutine in the Go program is not terminated correctly, causing the goroutine to occupy system resources all the time, which can lead to resource exhaustion and even system crash. In software testing, whether there will be a goroutine leak when the program is running is called a goroutine leak test. Coroutine leakage testing is a very important part of software testing. The existing technology has poor detection effect when performing goroutine leakage testing and cannot effectively detect the hidden dangers of goroutine leakage in the program. Summary of the invention

[0004] The embodiments of the present application provide a software testing method, device, electronic device, computer-readable storage medium, and computer program product, which can solve the problem of poor effect of coroutine leakage testing in software testing in the prior art. The technical solution is as follows: According to a first aspect of an embodiment of the present application, a software testing method is provided, the method comprising: Obtain a target program, wherein the target program includes a program to be tested and an error injection function of the program to be tested, wherein the error injection function is used to trigger at least one exception when the program to be tested is subjected to a load test; and the program to be tested includes a program code for processing the exception triggered by the error injection function; Executing a test task through the target program to perform a load test on the program to be tested; After the target program completes executing the test task, obtaining a first number of coroutines started by the target program; Whether the coroutine leakage test of the program to be tested is successful is determined based on the first number and the second number, wherein the second number is the number of coroutines started by the target program obtained before the target program executes the test task.

[0005] According to a second aspect of an embodiment of the present application, a software testing device is provided, the device comprising: A target program acquisition module, used for the target program including a program to be tested and an error injection function of the program to be tested, wherein the error injection function is used to trigger at least one exception when the program to be tested is subjected to a load test; the program to be tested includes a program code for processing the exception triggered by the error injection function; A quantity acquisition module is used to execute the test task through the target program to perform a load test on the program to be tested; after the target program completes the execution of the test task, obtain the second quantity of the coroutines started by the target program; A judgment module is used to judge whether the coroutine leakage test of the program to be tested is successful based on a first number and a second number, wherein the second number is the number of coroutines started by the target program obtained before the target program executes the test task.

[0006] According to a third aspect of an embodiment of the present application, an electronic device is provided, which includes a memory, a processor, and a computer program stored in the memory, and when the processor executes the program, the steps of the method provided in the first aspect are implemented.

[0007] According to a fourth aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method provided in the first aspect are implemented.

[0008] According to the fifth aspect of the embodiment of the present application, a computer program product is provided, which includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. When a processor of a computer device reads the computer instructions from the computer-readable storage medium, the processor executes the computer instructions, so that the computer device executes the steps of implementing the method provided in the first aspect.

[0009] The beneficial effects of the technical solution provided in the embodiment of the present application are as follows: the target program in the embodiment of the present application includes a program to be tested and an error injection function of the program to be tested. Since a well-running software or program generates a large number of exceptions during a high-load process, the number of coroutines corresponding to the software or program remains basically unchanged before and after the load test is performed. Therefore, by using the target program to perform the test task, it is used to simulate the scenario in which the program to be tested handles a large number of exceptions during the load test. By obtaining the second number of coroutines started by the target program before the target program executes the test task, and the first number of coroutines started by the target program after the target program executes the test task, the difference in the number of coroutines started by the target program before and after the test task is obtained, thereby determining whether the program to be tested has a coroutine leakage problem during the load test. If the program to be tested has a coroutine leakage problem during the load test, the coroutine leakage test of the program to be tested fails. If the program to be tested does not have a coroutine leakage problem during the load test, the coroutine leakage test of the program to be tested succeeds. The embodiment of the present application implements a coroutine leakage test in a scenario where a large number of exceptions occur during the high-load processing task of the program under test, so that the successfully tested program under test will not have the problem of coroutine leakage when it is actually used even if a large number of exceptions need to be processed. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in describing the embodiments of the present application.

[0011] Figure 1 A schematic diagram of a system architecture for implementing software testing provided in an embodiment of the present application; Figure 2 A flowchart of a software testing method provided in an embodiment of the present application; Figure 3 A code example diagram of an error injection function provided in an embodiment of the present application; Figure 4 A code example diagram of simulating exception handling provided in an embodiment of the present application; Figure 5 A schematic diagram of coroutine information before executing a load task provided in an embodiment of the present application; Figure 6 A schematic diagram of a coroutine information after a load task is completed provided in an embodiment of the present application; Figure 7 A schematic diagram of the structure of a software testing device provided in an embodiment of the present application; Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0012] The embodiments of the present application are described below in conjunction with the drawings in the present application. It should be understood that the implementation methods described below in conjunction with the drawings are exemplary descriptions for explaining the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions of the embodiments of the present application.

[0013] It will be understood by those skilled in the art that, unless specifically stated, the singular forms "one", "said", and "the" used herein may also include plural forms. It should be further understood that the terms "including" and "comprising" used in the embodiments of the present application refer to that the corresponding features can be implemented as the presented features, information, data, steps, operations, elements and / or components, but do not exclude the implementation as other features, information, data, steps, operations, elements, components and / or combinations thereof supported by the technical field. It should be understood that when we say that an element is "connected" or "coupled" to another element, the one element may be directly connected or coupled to the other element, or it may refer to that the one element and the other element establish a connection relationship through an intermediate element. In addition, the "connection" or "coupling" used herein may include wireless connection or wireless coupling. The term "and / or" used herein indicates at least one of the items defined by the term, for example, "A and / or B" may be implemented as "A", or as "B", or as "A and B".

[0014] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0015] First, several terms involved in this application are introduced and explained: Goroutine refers to a lightweight execution thread running in the background, called a Go coroutine, which is a key component for implementing concurrency in the Go language.

[0016] Goroutine leak refers to the situation in which, for some reason, the created Goroutines in the Go program are not terminated correctly, causing them to occupy system resources (such as memory) all the time. These leaked Goroutines will continue to run until the end of the program. If not handled, it may cause memory exhaustion, program performance degradation, or even system crash.

[0017] The software testing method, device, electronic device, computer-readable storage medium and computer program product provided in this application are intended to solve the technical problem of poor coroutine leakage testing effect in software testing in the prior art.

[0018] The following describes several exemplary embodiments to illustrate the technical solutions of the embodiments of the present application and the technical effects produced by the technical solutions of the present application. It should be noted that the following embodiments can refer to, draw on or combine with each other, and the same terms, similar features and similar implementation steps in different embodiments will not be described repeatedly.

[0019] Figure 1 A schematic diagram of the system architecture for implementing software testing provided in an embodiment of the present application, wherein terminal 101 can be used to provide an operation page for the tester, obtain the target program input by the tester, and in response to the tester clicking a run button on the operation page, terminal 101 sends the target program to server 102. Terminal 101 responds to the tester's request to obtain a first quantity by sending a request to server 102. After receiving the request, server 102 sends the first number of coroutines started by the target program to terminal 101.

[0020] After the tester obtains the first quantity through terminal 101, he instructs terminal 101 to execute the test task through the target program on the operation page of terminal 101. Terminal 101 responds to the instruction and sends the relevant information of the test task to server 102. After server 102 obtains the test task, it executes the test task based on the target program. The test task is used to load test the program to be tested. After server 102 completes the test task through the target program, it sends the completion information to terminal 101 and displays it in terminal 101. After receiving the completion information, the terminal can accept the operator's instruction to send a request to obtain the second quantity to server 102, or it can automatically send a request to obtain the second quantity to server 102 after receiving the completion information. After receiving the request, server 102 sends the second quantity of the coroutine that has been started by the target program to terminal 101.

[0021] The terminal 101 determines whether there is a coroutine leak in the program to be tested at this time according to the first number and the second number. If there is a coroutine leak, the coroutine leak test fails; if there is no coroutine leak, the coroutine leak test succeeds.

[0022] Those skilled in the art will appreciate that the number of the above terminals may be more or less. For example, the above terminal may be only one, or the above terminals may be dozens or hundreds, or more. The embodiment of the present application does not limit the number of terminals and device types.

[0023] In some embodiments, the server 102 is an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Server 102 is used to provide background services for applications that support image acquisition. In some embodiments, server 102 undertakes the main computing work and terminal 101 undertakes the secondary computing work; or, server 102 undertakes the secondary computing work and terminal 101 undertakes the main computing work; or, server 102 and terminal 101 use a distributed computing architecture for collaborative computing.

[0024] For example, the software testing method in the embodiment of the present application can be completed by a server. The following describes the solution in the embodiment of the present application with the server as the execution subject.

[0025] The present application provides a method for software testing, such as Figure 2 As shown, the method includes S201-S204.

[0026] S201. Obtain a target program, wherein the target program includes a program to be tested and an error injection function of the program to be tested, wherein the error injection function is used to trigger at least one exception when the program to be tested is subjected to a load test; and the program to be tested includes program code for processing the exception triggered by the error injection function.

[0027] In an embodiment of the present application, the program to be tested may be all programs corresponding to a software system, or may be a program corresponding to a specific functional module in the software system. The software test in an embodiment of the present application may be a coroutine leakage test for the entire software system, or may be a coroutine leakage test for a specific functional module in the software system.

[0028] In an embodiment of the present application, the program to be tested includes a program code for handling exceptions, and the error injection function in the target program is used to trigger at least one exception when the program to be tested is load tested, and the program code in the program to be tested can handle the exception triggered by the error injection function. When acquiring the target program, the error injection function can be determined based on the exception that the program code in the program to be tested can handle. For example, the program to be tested includes a program code for handling network exceptions, and the error injection function is used to trigger the network exception. In this field, the process of triggering the corresponding exception by the error injection function is also called error injection.

[0029] As an optional embodiment, the error injection function can be some error injection tools. For example, the Linux kernel provides a function "Fault-injection" for fault injection, which can simulate various abnormal scenarios such as memory allocation failure and disk IO error; Ferrari is a tool that automatically injects errors in real time based on software traps, which can be injected into system memory, registers, etc.

[0030] The target program including the program to be tested and the error injection function can be understood as the code in the target program being the source code of the program to be tested and the code of the error injection function.

[0031] In an embodiment of the present application, there may be multiple program codes for handling exceptions in the target program, and each program code may be used to handle one or more exceptions. In addition, it should be understood that some program codes are set to handle arbitrary exceptions. For example, the program code is "skip this execution if an exception is encountered". In this case, the error injection function can be an error injection function used to trigger any exception.

[0032] In the embodiment of the present application, the error injection function is determined based on the exceptions related to the program code in the program to be tested, thereby ensuring that the exceptions encountered when the program to be tested is load tested can be handled by the corresponding program code.

[0033] S202: Execute the test task through the target program to perform load testing on the program to be tested.

[0034] In the embodiment of the present application, the purpose of executing the test task on the target program is to perform a load test on the program to be tested. The load test on the program to be tested is to perform the load task through the program to be tested. A general benchmark test or any load test simulating a real scene can be used to perform a load test on the program to be tested. As an optional embodiment, the corresponding load test can be selected according to the function of the program to be tested.

[0035] It should be understood that, for a good program, even if it handles a large number of exceptions under high load, the number of coroutines started by the program remains basically unchanged before and after the load test. Therefore, in the embodiment of the present application, an exception is triggered when the program to be tested is subjected to a load test, so that when the program to be tested has a coroutine leakage problem, after the load test of the program to be tested is completed, multiple coroutines will not be correctly terminated, thereby further determining that the program to be tested has a coroutine leakage problem.

[0036] S203: After the target program completes executing the test task, obtain a first number of coroutines started by the target program.

[0037] S204. Determine whether the coroutine leakage test of the program to be tested is successful based on the first number and the second number, where the second number is the number of coroutines started by the target program obtained before the target program executes the test task.

[0038] In the embodiment of the present application, the target program completes the test task, indicating that the load test of the program to be tested is completed. At this time, if there is a problem code in the source code of the program to be tested that will cause the coroutine to leak, there will be multiple coroutines that are not normally closed. Therefore, by obtaining the first number of coroutines started by the target program at this time, the first number of coroutines started here is the number of coroutines in the target program that are in the open state, and the first number is also the number of coroutines in the open state corresponding to the program to be tested. The first number can be obtained through some monitoring tools or by accessing the log records of the target program.

[0039] In order to determine how many of the first number of coroutines are coroutines that are not closed after the target program executes the test task, the second number of coroutines that have been started by the target program before the target program executes the test task can be obtained in advance. The target program can be started so that it is in a running state, and the target program can also be compiled before starting the target program.

[0040] After the target program is started, the target program is in a running state, and the target program in the running state will also start the corresponding coroutine, such as the coroutine corresponding to the main function. The second number of coroutines started by the target program can be obtained through some monitoring tools or by accessing the log records of the target program. It should be understood that when the target program executes the test task, the target program is also in a running state. If there is no code in the source code of the program to be tested that will cause program leakage, the first number of coroutines started after the target program executes the test task should be similar to the second number before the target program executes the test task.

[0041] Therefore, in the embodiment of the present application, by analyzing the first number and the second number, it is determined whether there is code in the program to be tested that causes coroutine leakage. If there is code in the program to be tested that causes coroutine leakage, the coroutine leakage detection of the program to be tested fails; if there is no code in the program to be tested that causes coroutine leakage, the coroutine leakage detection of the program to be tested succeeds.

[0042] It should be understood that in modern software development, especially in systems built with the Go language, coroutine leaks are a common problem that can lead to significant performance degradation and resource waste. In the exception handling of a program, developers tend to focus on the control flow of the exception itself and may neglect the management of resource lifecycles. In this case, resource management and release operations can easily be forgotten or ignored, leading to resource (especially coroutine) leaks. These leaks not only increase the system's resource usage, but can also cause more serious system failures due to resource exhaustion. Existing coroutine leak detection tools mainly monitor the regular coroutine lifecycle. These tools are often unable to effectively identify and prevent leaks caused by improper exception handling, especially in complex systems and high-concurrency environments.

[0043] Therefore, in an embodiment of the present application, a target program is obtained to obtain a program to be tested and an error injection function of the program to be tested. Since a well-running software or program will basically remain unchanged before and after the load test even if a large number of exceptions are generated during a high load process, the number of coroutines corresponding to the software or program remains unchanged. Therefore, the test task is performed using the target program to simulate the scenario in which the program to be tested handles a large number of exceptions during the load test.

[0044] By obtaining the second number of coroutines started by the target program before the target program executes the test task and the first number of coroutines started by the target program after the target program executes the test task, the difference in the number of coroutines started by the target program before and after the test task is obtained, thereby determining whether a coroutine leakage problem occurs in the program to be tested during the load test. If a coroutine leakage problem occurs in the program to be tested during the load test, the coroutine leakage test of the program to be tested fails; if no coroutine leakage problem occurs in the program to be tested during the load test, the coroutine leakage test of the program to be tested succeeds.

[0045] The embodiment of the present application implements a coroutine leakage test in a scenario where a large number of exceptions occur during the high-load processing task of the program under test, so that the successfully tested program under test will not have the problem of coroutine leakage when it is actually used even if a large number of exceptions need to be processed.

[0046] As an optional embodiment of the present application, running the target program and obtaining a first number of coroutines started by the target program includes: Obtaining first stack information after the target program completes the test task, and obtaining a first quantity from the first stack information; The second number is obtained from the second stack information before the target program executes the test task.

[0047] In an embodiment of the present application, the stack information includes the number of started coroutines, and the corresponding number of started coroutines can be obtained by obtaining the stack information of the target program before and after the target program executes the test task.

[0048] After the target program completes executing the test task, first stack information corresponding to the target program is obtained, and the number of started coroutines in the first stack information is used as the first number.

[0049] Before the target program executes the test task, the method further includes obtaining first stack information corresponding to the target program, and taking the number of started coroutines in the first stack information as the first number; In the embodiment of the present application, the number of started coroutines is determined by obtaining stack information, the operation is simple, and the efficiency of obtaining the first number and the second number is high.

[0050] As an optional embodiment of the present application, the target program also includes a performance analysis tool, and the performance analysis tool is used to monitor the stack information of the target program; Get the first stack information after the target program completes the test task, including: After the target program completes the test task, obtaining first stack information by accessing the port of the performance analysis tool; The second stack information is obtained by accessing the port of the performance analysis tool before the target program executes the test task.

[0051] In an embodiment of the present application, a performance analysis tool is used to monitor stack information. Different programming languages ​​may correspond to different performance analysis tools. Taking the Go language as an example, the performance analysis tool may be pprof.

[0052] The performance analysis tool can be imported into the target program through the performance analysis toolkit. The performance analysis tool monitors the stack information through the port of the performance analysis tool. The stack information monitored by the performance analysis tool can be obtained by accessing the port of the performance analysis tool. For example, the port can be in the form of "localhost:6060".

[0053] In the embodiment of the present application, the port of the performance analysis tool can be an http interface. In this case, the performance analysis tool provides an online service, and the performance data and stack information can be obtained by accessing the http interface provided by pprof. Therefore, in the embodiment of the present application, when the target program is running, the port of the performance analysis tool can be accessed to obtain the first stack information and the second stack information.

[0054] In the embodiment of the present application, by setting a performance analysis tool in the target program, the stack information monitored by the performance analysis tool can be obtained by accessing the port corresponding to the performance analysis tool, thereby improving the efficiency of obtaining the stack information and the accuracy of real-time performance.

[0055] As an optional embodiment of the present application, the stack information further includes a coroutine identifier of the started coroutine; If the coroutine leakage test of the program to be tested fails, the software testing method further includes: Acquire the coroutine identifier of each first coroutine started by the target program from the first stack information, and acquire the coroutine identifier of each second coroutine started by the target program from the second stack information; Compare the coroutine identifiers of each first coroutine with the coroutine identifiers of each second coroutine to obtain different coroutine identifiers; According to the coroutine identifier of the difference, the reason why the coroutine leakage test of the program to be tested fails is determined.

[0056] In the embodiment of the present application, the stack information includes not only the number of started coroutines, but also the coroutine identifiers of the started coroutines. Therefore, in the stack information obtained using the performance analysis tool, not only the number of started coroutines can be determined, but also the coroutines that have been started at the current moment, that is, the coroutines that have not been closed, can be determined.

[0057] In an embodiment of the present application, if it is determined that the coroutine leakage test of the program to be tested has failed after analyzing the difference between the first number and the second number, it can be further determined which code errors exist in the program to be tested, which cause the problem of coroutine leakage, based on the stack information. Each first coroutine can be determined by obtaining the coroutine identifier of each first coroutine that has been started by the target program from the first stack information, and each second coroutine can be determined by obtaining the coroutine identifier of each second coroutine that has been started by the target program through the second stack information. The difference coroutine identifier is obtained by comparing the coroutine identifier of each first coroutine with the coroutine identifier of each second coroutine, which is used to obtain the different coroutines in each first coroutine and each second coroutine, so that according to the corresponding code in the target program corresponding to the coroutine, it should be understood that the code in the target program corresponding to the coroutine, that is, the code in the program to be tested corresponding to the coroutine, can determine the code with problems in the program to be tested, that is, determine the reason for the failure of the coroutine leakage test of the program to be tested.

[0058] In the embodiment of the present application, when a coroutine leakage test of the program to be tested fails, a different coroutine identifier is obtained by acquiring and comparing the coroutine identifier of the first coroutine and the coroutine identifier of the second coroutine that have been started by the target program. This can solve the problem of accurately locating the code position of the coroutine leakage when it is determined that the program to be tested has a coroutine leakage problem, and determine the reason for the failure of the coroutine leakage test of the program to be tested.

[0059] As an optional embodiment of the present application, judging whether the coroutine leakage test of the program to be tested is successful according to the first quantity and the second quantity includes: Determine a ratio of a first difference value to a second quantity, and use the ratio as a reference value, wherein the first difference value is a difference between the first quantity and the second quantity; If the reference value is greater than a preset threshold, it is determined that the coroutine leakage test of the program to be tested fails; If the reference value is less than or equal to the preset threshold, it is determined that the coroutine leakage test of the program to be tested is successful.

[0060] In the embodiment of the present application, the following formula can be used to determine whether the coroutine leakage test of the program to be tested is successful:

[0061] in, is the second quantity, is the first quantity, is the first difference between the second number and the first number. It should be understood that the difference between the second number and the first number is caused by the problem of coroutine leakage after the program to be tested is loaded. At this time, the first number is generally greater than the second number. Therefore, the difference between the second number and the first number in the embodiment of the present application can be simplified to , the ratio of the first difference to the second quantity is recorded as .

[0062] pass Compare with the preset threshold to determine whether the coroutine leakage test of the program to be tested is successful. The preset threshold can be 10%. >10%, it is determined that the coroutine leakage test of the program to be tested has failed. When the value is 10%, it is determined that the coroutine leakage test of the program to be tested is successful. As an optional embodiment, the corresponding threshold value can be determined according to the function of the program to be tested, and the threshold values ​​corresponding to the programs to be tested with different functions can be different.

[0063] In the embodiment of the present application, a relative method of comparing differences is provided by analyzing the size of the difference between the second quantity and the first quantity through the ratio of the first difference to the second quantity. Compared with the absolute method of comparing differences such as direct difference, this method is not affected by the size of the quantity and can more accurately reflect the degree of difference between the second quantity and the first quantity.

[0064] As an optional embodiment, a threshold can be set for the first difference, that is, when the first difference is greater than a preset threshold, it is determined that the coroutine leakage test of the program to be tested has failed; if the first difference is less than or equal to the preset threshold, it can be determined that the coroutine leakage test of the program to be tested has failed; in addition, whether the coroutine leakage test is successful can also be determined based on the ratio of the first number to the second number.

[0065] As an optional embodiment provided in the embodiment of the present application, obtaining the target program includes: Acquire an initial program for testing, wherein the initial program includes a program to be tested; Performing an error injection function detection on the initial program, the error injection function detection is used to detect whether the initial program includes an error injection function; If it is detected that the initial program includes an error injection function, generating the target program according to the initial program; If the program to be tested does not include an error injection function, then in response to a write operation, an error injection function corresponding to the write operation is acquired, and a target program is generated according to the initial program and the error injection function.

[0066] In an embodiment of the present application, the target program can be obtained by acquiring an initial program. The initial program can be a program pre-written by a tester, and the initial program includes a program to be tested, and the initial program may include an error injection function corresponding to the program to be tested. It should be understood that when the tester writes the program to be tested, in order to test the program code for handling exceptions in the program to be tested, a corresponding error injection function may be written for the program to be tested. In this case, the initial program obtained already includes the error injection function.

[0067] In an embodiment of the present application, after obtaining the initial program, an error injection function detection is performed on the initial program. It can be detected whether the initial program already includes the error injection function by detecting whether there are keywords related to the error injection function in the initial program, where the keyword of the error injection function can be "Inject" or "Failpoint". If it is detected that the initial program includes the error injection function, the target program can be generated based on the initial program.

[0068] If it is not detected that the initial program includes an error injection function, the initial program is the program to be tested. The server can output the detection result that the error injection function is not detected, and provide the tester with a page for writing the error injection function. The tester can write the error injection function. The server responds to the tester's write operation and obtains the error injection function, thereby obtaining the target program by obtaining the initial program and the error injection function.

[0069] In an embodiment of the present application, generating a target program may also include, if the initial program includes an error injection function, then the target program can be generated based on the initial program and a performance analysis tool; if the initial program does not include an error injection function, then the target program can be generated based on the initial program, the error injection function and the performance analysis tool.

[0070] It should be understood that in order to distinguish the programs corresponding to different codes, the embodiments of the present application propose a target program, an initial program and a program to be tested, wherein the code in the program to be tested is the code that needs to be tested, and in some application scenarios, such as testing the handling of exceptions by the program to be tested, the code of the error injection function may also be added to the code of the program to be tested, and in the embodiments of the present application, the program with the code of the test program and the code of the error injection function added is used as the initial program. Load testing the program to be tested can also be called load testing the initial program, and can also be called load testing the target program.

[0071] As an optional embodiment, if an error injection function is detected, the number of corresponding exceptions of the error injection function can be further detected. If the number of corresponding exceptions of the error injection function is less than the number of exceptions corresponding to the program code, the error injection function written by the tester can also be obtained so that the error injection function can reach all exceptions corresponding to the program code.

[0072] In the embodiments of the present application, an error injection function is detected on the initial program to determine whether the initial program includes the error injection function, so as to solve the problem of low efficiency in manually determining whether the initial program includes the error injection function. At the same time, the solution provided by the present application can not only perform anomaly detection on the program to be tested in the initial program that does not include the error injection function, but also perform anomaly detection on the program to be tested in the initial program that has been pre-processed by the tester, thereby improving the efficiency of obtaining the target program and expanding the usage scenarios.

[0073] As an optional embodiment of the present application, any error injection function includes an exception identifier and a first instruction, where the first instruction is used to indicate an exception corresponding to the exception identifier that is triggered; The exception corresponding to the exception identifier in the error injection function corresponding to the write operation is an exception among at least one exception that the program code is used to trigger.

[0074] In an embodiment of the present application, the error injection tool is Failpoint, and the error injection function corresponding to the Failpoint tool is composed of an exception identifier and a first instruction, wherein the first instruction may be the error injection instruction "Inject" in Failpoint, and the first instruction is used to instruct the server to trigger an exception corresponding to the exception identifier when executing the code of the error injection function. Generating an error injection function may also include setting a first parameter of the exception identifier in the test environment corresponding to the target program after writing the first instruction and the exception identifier, and the first parameter is used to indicate the triggering of the corresponding exception. For example, the environment variable FAILPOINT=some-error=return(true) may be set, wherein true is the first parameter. In the technical field of this invention, setting the first parameter to true is also referred to as activating the error injection function, which is used to instruct the server to trigger the corresponding exception when executing the error injection function, and in this example, the exception named some-error is activated. Therefore, the error injection function in the embodiment of the present application will trigger the corresponding exception when the program to be tested is subjected to load testing. In this field, setting the exception identifier as the first parameter may also be referred to as activating the exception.

[0075] As an optional embodiment, the target program may also include functions consisting of a first instruction and an exception identifier, but these functions are not set with a first parameter, that is, the corresponding exception is not activated. When these functions need to be triggered, the first parameter can be set for the function in the test environment of the target program to convert the function into an error injection function. It should be noted that if the initial program includes a function consisting of a first instruction and an exception identifier, the function will also be detected when the error injection function is detected. At this time, the tester can convert the function into an error injection function by modifying the test environment.

[0076] In an embodiment of the present application, when the initial program does not include an error injection function, the tester can determine the location of the error injection function in the target program according to the program to be tested, and write at least one error injection function at that location. The error injection function written includes a first instruction and an exception identifier, and the exception corresponding to the exception identifier in the error injection function written is an exception in at least one exception that the program code is used to handle.

[0077] As an optional embodiment, in order to generate more exceptions and test more program codes of the program to be tested, error injection functions corresponding to all exceptions that the program code can handle can be generated, and these error injection functions can be activated by setting the first parameter, or one or more error injection functions can be activated.

[0078] As an optional embodiment, the error injection tool can also be the Fault-injection of the Linux kernel, and the functions in the tool can be directly used as error injection functions, for example, the fail_make_request function is used to inject disk IO errors; the error injection tool can also be Orchestra, which is a script-driven error injector mainly used to evaluate and verify the fault tolerance and timing characteristics of distributed protocols. The error injection tool writes the error injection function by importing the tool in the initial program and editing the corresponding configuration file to specify the exception.

[0079] As an optional embodiment of the present application, in response to the write operation, the method also includes: Obtaining a keyword in a program code for handling at least one exception in the program to be tested, the keyword being used to indicate the exception that the program code is used to handle; Determine the exception corresponding to the keyword and display the exception identifier corresponding to the exception so that the tester can write the error injection function according to the exception identifier.

[0080] The embodiments of the present application can analyze the exception identifiers of the exceptions corresponding to the program codes in the program to be tested, thereby avoiding the problem of low efficiency in manually reading the target program and determining the exceptions corresponding to the program codes.

[0081] In order to more clearly illustrate the software testing solution provided by the embodiment of the present application, a complete embodiment of the present application is given, including: S1. Error injection preparation: Generally, large-scale software systems such as databases, big data, WebServer, etc., the main task of this type of software is to execute various loads. The load can be understood as a task that the user needs the software system to complete. This task can be large or small. A smaller one may be just querying a piece of data, while a larger one may be a batch process that takes hours or even days to run.

[0082] One application scenario of the embodiment of the present application can be a large software system implemented in Go language. This software will use (possibly a large number of) Goroutines to run the load, and it is these Goroutines that may leak. In the embodiment of the present application, Failpoints are used for error injection. For software systems that already include Failpoints, these Failpoints can be used directly. For software systems that do not include Failpoints, Failpoints can be defined and implemented by testers. For code examples of defining and implementing Failpoints, see Figure 3 , Figure 3 This is a code example diagram of an error injection function provided in an embodiment of the present application. Figure 3The first instruction "Inject" and the exception flag "panic" are shown in FIG. The exception corresponding to the exception flag is an exception that terminates the program, and the exception is recorded as "force-db-error"; In the test environment, activate a specific failpoint by setting environment variables or configuration files. For example, you can set the environment variable FAILPOINT=force-db-error=return(true) before starting the test to activate the error simulation named "force-db-error".

[0083] S2. Perform load testing: Select a load for the test, for example, you can choose to use a common benchmark or any load that simulates a real-world scenario; Execute the load test; S3. Record execution information: Use performance analysis tools such as pprof in the Go language to record the number and status of Goroutines before and after the load test to obtain accurate performance data for subsequent analysis; S4. Comparison and analysis of results: Set a preset threshold, such as 10%, which represents the percentage difference between the number of Goroutines before and after the load test. If the number of Goroutines after the load test exceeds the given threshold compared to before the load test, it is considered that there is a risk of Goroutine leakage and further analysis is required. Otherwise, the process ends and the system is considered to have no risk of Goroutine leakage.

[0084] S5. Analyze abnormal Goroutine: Determine normal residue and leakage, analyze whether the residual Goroutine after the load test is the normal operation delay residue, if not, it is considered to be a leakage; locate the cause of the leakage, and locate the specific cause and location of the leakage through stack information and log analysis.

[0085] The following is an example of a complete embodiment of the present application. Figure 4 , Figure 4 A code example diagram of simulating exception handling provided in an embodiment of the present application, Figure 4 The code example simulates a scenario where a Goroutine leak occurs in the exception handling part: S1. Get the target program: The target program can be Figure 4As shown in the figure, the simulateTask function simulates the execution of the actual task. It simulates the delay of task processing through time.Sleep. Under normal circumstances, a true signal is sent to the donechannel when the task ends, indicating successful completion. If an exception occurs during execution, the recover mechanism captures the exception but deliberately does not send any signal to the donechannel. This design simulates a scenario of improper error handling, that is, failure to clean up or release resources when an exception occurs, causing the caller (processRequest function) to wait forever for these unsent signals.

[0086] Failpoint is used in the simulateTask function for error injection. When the task id is an even number, an exception will be triggered. That is, when the coroutine id is an even number, an exception will be triggered.

[0087] The processRequest function handles a specific request. It starts three concurrent simulateTask tasks to handle some work and receives the completion status of each task through donechannel. At the same time, it immediately sends the processed request result back to the calling function through respChan. It is important that processRequest tries to wait for the end signal of all tasks. If a simulateTask does not send a signal due to an exception, this will cause processRequest to block forever while waiting for that signal.

[0088] The handleRequest function is used to receive the user's request and process the request through an independent Goroutine calling processRequest. It does not wait for all operations of processRequest to complete, but only relies on respChan to obtain the processing results. It can be seen that even if processRequest is blocked due to the failure of a simulateTask, handleRequest can still continue to execute and return the processing results.

[0089] The main function starts an HTTP service for accessing pprof, so that in subsequent steps you can access the pprof port through a browser to obtain the stack information monitored by pprof.

[0090] The main function contains a loop for continuously receiving and processing user requests. Each request is processed by handleRequest and the result is returned to the user. It should be noted that the target program in the embodiment of the present application is the target program that enables the error injection function.

[0091] S2. To demonstrate the technical effect of the software testing method provided in the embodiment of the present application, the failpoint is not enabled, that is, the error injection function is not activated, that is, no error injection is performed, the code is compiled and the program is executed; S3. Select the load test to continuously send requests to the program for a period of time, a total of 1000 times; S4. Use the command curl http: / / localhost:6060 / debug / pprof / Goroutine\?debug\=1 to capture Goroutine information before and after the load test: The Goroutine information before the load test is roughly as follows Figure 5 As shown, Figure 5 A schematic diagram of the coroutine information before performing a load test provided in an embodiment of the present application; Goroutine information after the load Figure 5 same; S5. Because no error injection was performed and no exceptions occurred during program execution, the Goroutine conditions before and after the load test were exactly the same, and potential Goroutine leakage issues were not detected. That is, the error injection function was not used, and the coroutine leakage issue of the program under test could not be detected. S6. Enable Failpoint by setting the environment variable export GO_FAILPOINTS = 'main / force -error =panic ("simulated error")' and re-execute the program; S7, execute the same load test as S3; S8. Use the same method as S4 to capture Goroutine information before and after the load test. Goroutine information before load testing and Figure 5 same; The Goroutine information after the load test is roughly as follows Figure 6 As shown, Figure 6 A schematic diagram of a coroutine information after a load task is completed provided in an embodiment of the present application; S9. It can be seen that after the error injection, the number of Goroutines after the load is 1002, which is much higher than the 2 before the load test. At this time, it is determined that a Goroutine leak has occurred; S10. Observe the stack information and find that all the extra Goroutines after the load are located in the function handleRequest. Further analysis of the code shows that the coroutine does not receive the expected number of end signals and waits forever. Further analysis shows that it is caused by the exception handling part in simulateTask not sending signals correctly. At this point, the leakage problem is located.

[0092] In the above examples, by simulating the use of the error injection function and not using the error injection function, the coroutine leakage detection of the program to be tested after the load test can be seen that during the load test, error injection can detect coroutine leakage, while without error injection, coroutine leakage cannot be detected. Therefore, the software testing method provided in the embodiment of the present application can simulate complex error handling scenarios and can more accurately test potential coroutine leakage risks, so that the program to be tested is safer when put into actual applications.

[0093] The present application embodiment provides a software testing device, such as Figure 7 As shown, the software testing device may include: a target program acquisition module 701, a quantity acquisition module 702 and a judgment module 703, wherein: The target program acquisition module 701 is used for the target program including the program to be tested and the error injection function of the program to be tested, the error injection function is used to trigger at least one exception when the program to be tested is subjected to load testing; the program to be tested includes program code for processing the exception triggered by the error injection function; The number acquisition module 702 is used to execute the test task through the target program to perform a load test on the program to be tested; after the target program completes the execution of the test task, the first number of the coroutines started by the target program is acquired; The judgment module 703 is used to judge whether the coroutine leakage test of the program to be tested is successful according to the first number and the second number, where the second number is the number of coroutines started by the target program obtained before the target program executes the test task.

[0094] As an optional embodiment of the present application, the quantity acquisition module 702, when acquiring the first quantity of the coroutines started by the target program, is specifically used to: Obtaining first stack information after the target program completes the test task, and obtaining the first quantity from the first stack information; The second quantity is obtained by the quantity obtaining module from the second stack information before the target program executes the test task.

[0095] As an optional embodiment of the present application, the target program further includes a performance analysis tool, and the performance analysis tool is used to monitor the stack information of the target program through a port when the target program is running; When the quantity acquisition module 702 is used to acquire the first stack information of the target program, it is specifically used to: After the target program completes the test task, acquiring the first stack information by accessing the port of the performance analysis tool; The second stack information is obtained by the quantity acquisition module by accessing the port of the performance analysis tool before the target program executes the test task.

[0096] As an optional embodiment, the stack information further includes a coroutine identifier of the started coroutine; if the coroutine leakage test of the program to be tested fails, the judgment module 703 is further used to: Acquire the coroutine identifier of each first coroutine started by the target program from the first stack information, and acquire the coroutine identifier of each second coroutine started by the target program from the second stack information; Compare the coroutine identifiers of each first coroutine with the coroutine identifiers of each second coroutine to obtain different coroutine identifiers; According to the different coroutine identifiers, determine the reason why the coroutine leakage test of the program to be tested fails.

[0097] As an optional embodiment of the present application, when the judgment module 703 is used to judge whether the coroutine leakage test of the program to be tested is successful according to the first number and the second number, it is specifically used to: Determine a ratio of a first difference value to a second quantity, and use the ratio as a reference value, wherein the first difference value is a difference between the first quantity and the second quantity; If the reference value is greater than the preset threshold, it is determined that the coroutine leakage test of the program to be tested has failed; If the reference value is less than or equal to the preset threshold, it is determined that the coroutine leakage test of the program to be tested is successful.

[0098] As an optional embodiment of the present application, when the target program acquisition module 701 is used to acquire the target program, it is specifically used to: Acquire an initial program for testing, wherein the initial program includes a program to be tested; Performing an error injection function detection on the initial program, the error injection function detection is used to detect whether the initial program includes an error injection function; If it is detected that the initial program includes an error injection function, a target program is generated according to the initial program; If the program to be tested does not include an error injection function, then in response to a write operation, an error injection function corresponding to the write operation is acquired, and the target program is generated according to the initial program and the error injection function.

[0099] As an optional embodiment of the present application, any error injection function includes an exception identifier and a first instruction, and the first instruction is used to indicate an exception corresponding to the triggering of the exception identifier; The exception corresponding to the exception identifier in the error injection function corresponding to the write operation is an exception among at least one exception that the program code is used to trigger.

[0100] The device of the embodiments of the present application can execute the method provided by the embodiments of the present application, and the implementation principles are similar. The actions performed by each module in the device of each embodiment of the present application correspond to the steps in the method of each embodiment of the present application. For the detailed functional description of each module of the device, please refer to the description in the corresponding method shown in the previous text, which will not be repeated here.

[0101] In an embodiment of the present application, an electronic device is provided, including a memory, a processor and a computer program stored in the memory, and the processor executes the above-mentioned computer program to implement the steps of the software testing method, which can be realized compared with the related art: the target program in the embodiment of the present application includes a program to be tested and an error injection function of the program to be tested. Since a well-running software or program generates a large number of exceptions during a high load process, the number of coroutines corresponding to the software or program remains basically unchanged before and after the load test is performed, so by using the target program to perform the test task, it is used to simulate the scene of the program to be tested handling a large number of exceptions during the load test. By obtaining the second number of coroutines started by the target program before the target program executes the test task, and the first number of coroutines started by the target program after the target program executes the test task, the difference in the number of coroutines started by the target program before and after the test task is obtained, so as to determine whether the program to be tested has a coroutine leakage problem during the load test, if the program to be tested has a coroutine leakage problem during the load test, the coroutine leakage test of the program to be tested fails, and if the program to be tested does not have a coroutine leakage problem during the load test, the coroutine leakage test of the program to be tested succeeds. The embodiment of the present application implements a coroutine leakage test in a scenario where a large number of exceptions occur during the high-load processing task of the program under test, so that the successfully tested program under test will not have the problem of coroutine leakage when it is actually used even if a large number of exceptions need to be processed.

[0102] In an alternative embodiment, an electronic device is provided, such as Figure 8 As shown, Figure 8The electronic device 4000 shown includes: a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, such as through a bus 4002. Optionally, the electronic device 4000 may also include a transceiver 4004, which may be used for data interaction between the electronic device and other electronic devices, such as data transmission and / or data reception. It should be noted that in actual applications, the transceiver 4004 is not limited to one, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present application.

[0103] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0104] The bus 4002 may include a path to transmit information between the above components. The bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus 4002 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0105] The memory 4003 may be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, optical disk storage (including compressed optical disk, laser disk, optical disk, digital versatile disk, Blu-ray disk, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium that can be used to carry or store computer programs and can be read by a computer, without limitation herein.

[0106] The memory 4003 is used to store the computer program for executing the embodiment of the present application, and the execution is controlled by the processor 4001. The processor 4001 is used to execute the computer program stored in the memory 4003 to implement the steps shown in the above method embodiment.

[0107] Among them, electronic devices may include but are not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 8 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0108] The embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps and corresponding contents of the aforementioned method embodiment can be implemented. Compared with the prior art, it can be realized that the target program in the embodiment of the present application includes a program to be tested and an error injection function of the program to be tested. Since a well-running software or program generates a large number of exceptions during a high load process, the number of coroutines corresponding to the software or program remains basically unchanged before and after the load test is performed, so by using the target program to perform the test task, it is used to simulate the scenario of the program to be tested handling a large number of exceptions during the load test. By obtaining the second number of coroutines started by the target program before the target program executes the test task, and the first number of coroutines started by the target program after the target program executes the test task, the difference in the number of coroutines started by the target program before and after the test task is obtained, so as to determine whether the program to be tested has a coroutine leakage problem during the load test, if the program to be tested has a coroutine leakage problem during the load test, the coroutine leakage test of the program to be tested fails, and if the program to be tested does not have a coroutine leakage problem during the load test, the coroutine leakage test of the program to be tested succeeds. The embodiment of the present application implements a coroutine leakage test in a scenario where a large number of exceptions occur during the high-load processing task of the program under test, so that the successfully tested program under test will not have the problem of coroutine leakage when it is actually used even if a large number of exceptions need to be processed.

[0109] It should be noted that the computer-readable medium mentioned above in the present disclosure may be a computer-readable signal medium or a computer-readable medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer readable signal media may also be any computer readable medium other than computer readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0110] The embodiment of the present application also provides a computer program product, including a computer program, which can implement the steps and corresponding contents of the aforementioned method embodiment when executed by a processor. Compared with the prior art, it can be realized that the target program in the embodiment of the present application includes a program to be tested and an error injection function of the program to be tested. Since a well-running software or program generates a large number of exceptions during a high load process, the number of coroutines corresponding to the software or program remains basically unchanged before and after the load test is performed, so by using the target program to perform the test task, it is used to simulate the scenario of the program to be tested handling a large number of exceptions during the load test. By obtaining the second number of coroutines started by the target program before the target program executes the test task, and the first number of coroutines started by the target program after the target program executes the test task, the difference in the number of coroutines started by the target program before and after the test task is obtained, so as to determine whether the program to be tested has a coroutine leakage problem during the load test, if the program to be tested has a coroutine leakage problem during the load test, the coroutine leakage test of the program to be tested fails, and if the program to be tested does not have a coroutine leakage problem during the load test, the coroutine leakage test of the program to be tested succeeds. The embodiment of the present application implements a coroutine leakage test in a scenario where a large number of exceptions occur during the high-load processing task of the program under test, so that the successfully tested program under test will not have the problem of coroutine leakage when it is actually used even if a large number of exceptions need to be processed.

[0111] The terms "first", "second", "third", "fourth", "1", "2", etc. (if any) in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than that shown or described in the drawings.

[0112] It should be understood that, although each operation step is indicated by arrows in the flowchart of the embodiment of the present application, the implementation order of these steps is not limited to the order indicated by the arrows. Unless clearly stated herein, in some implementation scenarios of the embodiment of the present application, the implementation steps in each flowchart can be performed in other orders according to demand. In addition, some or all of the steps in each flowchart may include multiple sub-steps or multiple stages based on actual implementation scenarios. Some or all of these sub-steps or stages may be executed at the same time, and each sub-step or stage in these sub-steps or stages may also be executed at different times respectively. In different scenarios of execution time, the execution order of these sub-steps or stages may be flexibly configured according to demand, and the embodiment of the present application does not limit this.

[0113] The above is only an optional implementation method for some implementation scenarios of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the technical concept of the solution of the present application, other similar implementation methods based on the technical ideas of the present application are also within the protection scope of the embodiments of the present application.

Claims

1. A software testing method, characterized in that: include: Obtain a target program, wherein the target program includes a program to be tested and an error injection function of the program to be tested, wherein the error injection function is used to trigger at least one exception when the program to be tested is subjected to a load test; and the program to be tested includes a program code for processing the exception triggered by the error injection function; Executing a test task through the target program to perform a load test on the program to be tested; After the target program completes executing the test task, obtaining a first number of coroutines started by the target program; Whether the coroutine leakage test of the program to be tested is successful is determined based on the first number and the second number, wherein the second number is the number of coroutines started by the target program obtained before the target program executes the test task.

2. The method according to claim 1, characterized in that The obtaining a first number of coroutines started by the target program includes: Obtaining first stack information after the target program completes the test task, and obtaining the first quantity from the first stack information; The second number is obtained from second stack information before the target program executes the test task.

3. The method according to claim 2, characterized in that The target program also includes a performance analysis tool, and the performance analysis tool is used to monitor the stack information of the target program; The obtaining of the first stack information after the target program completes the test task includes: After the target program completes the test task, acquiring the first stack information by accessing the port of the performance analysis tool; The second stack information is obtained by accessing the port of the performance analysis tool before the target program executes the test task.

4. The method according to claim 3, characterized in that The stack information also includes the coroutine identifier of the started coroutine; If the coroutine leakage test of the program to be tested fails, the method further includes: Acquire the coroutine identifier of each first coroutine started by the target program from the first stack information, and acquire the coroutine identifier of each second coroutine started by the target program from the second stack information; Compare the coroutine identifiers of each first coroutine with the coroutine identifiers of each second coroutine to obtain different coroutine identifiers; The reason why the coroutine leakage test of the program to be tested fails is determined according to the coroutine identifier of the difference.

5. The method according to any one of claims 1 to 4, characterized in that: The step of judging whether the coroutine leakage test of the program to be tested is successful according to the first number and the second number includes: Determine a ratio of a first difference value to the second number, and use the ratio as a reference value, wherein the first difference value is the difference between the first number and the second number; If the reference value is greater than a preset threshold, it is determined that the coroutine leakage test of the program to be tested fails; If the reference value is less than or equal to the preset threshold, it is determined that the coroutine leakage test of the program to be tested is successful.

6. The method according to claim 1 or 2, characterized in that: The obtaining of the target program comprises: Acquire an initial program for testing, wherein the initial program includes a program to be tested; Performing an error injection function detection on the initial program, wherein the error injection function detection is used to detect whether the initial program includes an error injection function; If it is detected that the initial program includes an error injection function, generating the target program according to the initial program; If the program to be tested does not include an error injection function, then in response to a write operation, an error injection function corresponding to the write operation is acquired, and the target program is generated according to the initial program and the error injection function.

7. The method according to claim 6, characterized in that Any error injection function includes an exception identifier and a first instruction, wherein the first instruction is used to indicate an exception corresponding to the triggering exception identifier; The exception corresponding to the exception identifier in the error injection function corresponding to the write operation is an exception among at least one exception that the program code is used to trigger.

8. A software testing device, characterized in that: include: A target program acquisition module, used for the target program including a program to be tested and an error injection function of the program to be tested, wherein the error injection function is used to trigger at least one exception when the program to be tested is subjected to a load test; the program to be tested includes a program code for processing the exception triggered by the error injection function; A quantity acquisition module is used to execute the test task through the target program to perform a load test on the program to be tested; after the target program completes the execution of the test task, obtain the first quantity of the coroutines started by the target program; A judgment module is used to judge whether the coroutine leakage test of the program to be tested is successful based on the first number and the second number, where the second number is the number of coroutines started by the target program obtained before the target program executes the test task.

9. An electronic device comprising a memory, a processor and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 7.

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

11. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images