Memory testing method and device, electronic equipment and storage medium

Abstract

The invention discloses a memory testing method and device, electronic equipment and a computer readable storage medium. The method comprises the following steps: acquiring memory object instances of a to-be-tested system in a no-load state to obtain a first memory object instance of the to-be-tested system in the no-load state; performing system pressurization on the to-be-tested system in the no-load state to obtain a first to-be-tested system in the full-load state, and operating the first to-be-tested system; in response to the fact that the operation duration of the first to-be-tested system reaches a duration threshold value, performing system decompression on the first to-be-tested system to obtain a second to-be-tested system in a no-load state; performing memory object instance collection on a second to-be-tested system to obtain a second memory object instance when the second to-be-tested system is in a no-load state; and based on the number of the first memory object instances and the number of the second memory object instances, performing memory testing on the to-be-tested system to obtain a test result.

Description

Technical Field

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

[0002] Memory leak refers to the situation where the memory space dynamically requested during program operation is not properly released after use, resulting in the continued occupation of memory space. This may cause the program to run slowly, the system to crash, or the program to not run properly. The purpose of memory leak testing is to identify and fix these memory management problems to ensure that the program can run efficiently and stably.

[0003] In the related art, the test for memory leak is usually performed by observing the state and trend of the memory for a long time and analyzing whether the memory exceeds a threshold or a maximum memory to determine whether the memory is leaked, which leads to low efficiency of memory testing. Summary of the invention

[0004] In order to solve the technical problems existing in the related art, the embodiments of the present application provide a memory testing method, device, electronic device and computer-readable storage medium.

[0005] To achieve the above purpose, the technical solution of the embodiment of the present application is implemented as follows:

[0006] In a first aspect, an embodiment of the present application provides a memory testing method, which is applied to an electronic device, and the method includes:

[0007] Collecting memory object instances of the system to be tested in a no-load state to obtain a first memory object instance when the system to be tested is in a no-load state;

[0008] Pressurizing the system to be tested in the no-load state to obtain a first system to be tested in a fully loaded state, and running the first system to be tested;

[0009] In response to the running time of the first system to be tested reaching a time threshold, decompressing the first system to be tested to obtain a second system to be tested in the no-load state;

[0010] Collecting memory object instances of the second system to be tested to obtain a second memory object instance when the second system to be tested is in the no-load state;

[0011] Based on the number of the first memory object instances and the number of the second memory object instances, a memory test is performed on the system to be tested to obtain a test result, where the test result is used to indicate whether there is a memory leak in the system to be tested.

[0012] In a second aspect, an embodiment of the present application provides a memory testing device, which is applied to an electronic device, including:

[0013] A first acquisition module, used for acquiring memory object instances of the system to be tested in a no-load state, to obtain a first memory object instance when the system to be tested is in a no-load state;

[0014] A pressurizing module, used for pressurizing the system to be tested in the no-load state to obtain a first system to be tested in a fully loaded state, and running the first system to be tested;

[0015] a decompression module, configured to, in response to the running time of the first system to be tested reaching a time threshold, decompress the first system to be tested to obtain a second system to be tested in the no-load state;

[0016] A second collection module, used for collecting memory object instances of the second system to be tested, and obtaining a second memory object instance when the second system to be tested is in the no-load state;

[0017] The test module is used to perform a memory test on the system to be tested based on the number of the first memory object instances and the number of the second memory object instances to obtain a test result, wherein the test result is used to indicate whether there is a memory leak in the system to be tested.

[0018] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor and a first memory for storing a computer program that can be run on the processor;

[0019] Wherein, when the processor is used to run the computer program, it executes the steps of the memory testing method on the electronic device side described in the embodiment of the present application.

[0020] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the memory testing method provided in the embodiment of the present application is implemented.

[0021] The memory test method, device, electronic device and computer-readable storage medium provided by the embodiment of the present application, by collecting memory object instances of the system to be tested in the no-load state, obtain the first memory object instance when the system to be tested is in the no-load state; the system to be tested in the no-load state is pressurized to obtain the first system to be tested in the full-load state, and the first system to be tested is run; in response to the running time of the first system to be tested reaching the time threshold, the first system to be tested is decompressed to obtain the second system to be tested in the no-load state; the memory object instance is collected for the second system to be tested to obtain the second memory object instance when the second system to be tested is in the no-load state; based on the number of the first memory object instance and the number of the second memory object instance, the system to be tested is tested for memory and the test result is obtained. In this way, when the system has no load or the load is very light (i.e., no-load state), the information of all memory object instances in the current system is collected to obtain the first memory object instance set. This set reflects the memory usage of the system when there is no load. Pressurize the system to simulate the highest load situation that may be encountered in actual operation, and obtain a system in a full-load state. Run the system in this state for a period of time to ensure that the system has gone through a complete life cycle, including memory allocation and recycling. When the system runs for a preset time threshold, stop the compression, let the system decompress and return to the no-load state, collect the memory object instance information at this time, and obtain the second memory object instance set. This set reflects the memory usage of the system when it returns to normal after high load. Compare the number of objects in the first memory object instance set and the second memory object instance set. If the number of objects in the second set is significantly more than the first set, this may indicate that there is a memory leak in the system during operation, because even after decompression under high load, there are still additional objects in the memory that have not been recycled. The collection of memory object instances in no-load and full-load states can be completed in one run, which reduces the test time and improves the test efficiency. By comparing the number of memory object instances in two different states, it is possible to quickly determine whether there is a memory leak without in-depth analysis of the life cycle of each object. By comparing the number of memory object instances in two states, it is possible to quickly determine whether there is a memory leak without in-depth analysis of the life cycle of each object, thereby effectively improving the efficiency of memory testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 A schematic diagram of a memory testing method according to an embodiment of the present application;

[0023] Figure 2 It is a schematic diagram of the principle of the memory testing method provided in the embodiment of the present application;

[0024] Figure 3 A schematic diagram of the composition structure of a memory testing device according to an embodiment of the present application;

[0025] Figure 4 A schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0026] The present application is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit this application.

[0028] In the existing technical solutions, the test methods for memory leaks are all to add the memory of the system under test, that is, by observing the state and trend of the memory for a long time, analyzing whether the memory exceeds the threshold or the maximum memory to determine whether the memory is leaked, which has high time and labor costs, and has certain requirements on the business capabilities and observation capabilities of the testers, and the final test result success rate and accuracy are not high. It also requires very high requirements for developers to locate the specific memory leak point and requires a lot of effort. Moreover, in the existing technical solutions, the memory is passively monitored, and the memory needs to be monitored continuously for a long time. This monitoring method may also affect the normal operation of the system under test. Due to the above problems in the existing methods, in the first aspect of the embodiment of the present application, through an automated testing device, the system under test can be automatically tested according to preset test conditions including pressure conditions, test times, memory object names, memory alarm thresholds, etc. Secondly, a memory test method is used to perform subtraction on the memory test, that is, the system memory is decomposed into memory objects, and the system under test is divided into two states: no load and full load and then no load. The number of instances of memory objects after each no load is collected and analyzed through the memory acquisition module, and the alarm threshold of the memory object is calculated and reported. Through this automated testing method, the memory objects of the system under test can be tested end-to-end, including presetting or importing the names of the memory objects to be analyzed, starting and stopping memory monitoring, memory data collection, memory object analysis, and memory object leakage alarm reporting, saving testers' testing time and energy.

[0029] Based on this, an embodiment of the present application provides a memory testing method, which is applied to electronic equipment. Figure 1 Schematic diagram of the memory testing method according to the embodiment of the present application. Figure 1 As shown, the memory testing method provided in the embodiment of the present application can be Figure 1 Steps 101 to 104 are shown to be implemented.

[0030] In step 101, memory object instances are collected from a system to be tested in a no-load state to obtain a first memory object instance when the system to be tested is in a no-load state.

[0031] In some embodiments, the main purpose of collecting memory object instances for the system under test in an unloaded state is to obtain a memory usage benchmark for the system without any load or user interaction. This benchmark will be used to compare with the memory usage of the system under load to detect memory leaks. Before testing, ensure that the system environment is clean and no other applications or services that may affect memory usage are running. Shut down all unnecessary background processes and services to simulate a real unloaded state. Determine which memory objects need to be monitored. This may include key data structures, object instances, or specific classes in the application. Select appropriate memory analysis tools that can provide detailed information about memory allocation, use, and release. For example, for Java applications, VisualVM or JProfiler can be used; for C++ applications, Valgrind can be used. Start the system under test and use the memory analysis tool to start monitoring memory usage. Allow the system to run for a while until memory usage stabilizes and ensure that all initialization processes are completed. After the system reaches a stable state, use the memory analysis tool to collect memory data. This may include memory snapshots, stack traces, or object instance counts. Analyze the collected memory data and identify and record the number of instances of preset memory objects. This typically involves an in-depth analysis of the objects in the memory snapshot to determine which objects are active and which objects may not have been released correctly. The number of memory object instances collected is recorded and used as a baseline for subsequent tests. This baseline value will be used to compare with the memory usage of the system under load. Testers can obtain the memory usage baseline of the system under test in an unloaded state, that is, the first memory object instance. This baseline is critical for detecting memory leaks because it provides a reference point for memory usage when there is no load, which can be used to detect whether memory usage increases abnormally when the load increases, thereby identifying possible memory leak problems.

[0032] In some embodiments, memory object instances are collected for the system to be tested in a no-load state to obtain a first memory object instance when the system to be tested is in a no-load state. The no-load state refers to a state in which the system is running with no or almost no load, that is, the system is running without any user interaction or business processing. In this state, the system's memory usage should be minimal because there is no additional data or process consuming memory resources. The system to be tested refers to a software system or application to be tested. In a memory leak test, the system to be tested is running in a no-load state in order to obtain memory usage when there is no load. A memory object instance refers to a specific instance of an object created in a program in memory. Each time an object is created, an instance is allocated in memory, and this instance contains all the properties of the object.

[0033] In some embodiments, the collection of memory object instances refers to the process of using a memory analysis tool to record and analyze all memory object instances in a program. This includes information such as the number, type, size, and life cycle of the objects. The first memory object instance refers to the initial memory object instance data collected in an unloaded state, which is used to establish a baseline for comparison with the memory usage of the system under load.

[0034] In step 102, the system to be tested in the no-load state is pressurized to obtain a first system to be tested in a full-load state, and the first system to be tested is operated.

[0035] In some embodiments, system stressing refers to applying pressure to the system to be tested by simulating user activities or business processes, which can be achieved through automated testing tools such as LoadRunner, JMeter or other custom scripts. According to the intended use of the system to be tested, simulate users logging in, browsing pages, performing transactions or other operations. These simulated activities can be executed concurrently to simulate the situation where multiple users use the system at the same time. The applied pressure can be gradually increased or suddenly, depending on the test purpose and load simulation strategy. The application of pressure should be able to reflect the maximum load that the system may face. During the stressing process, monitor the response time and resource usage of the system, including CPU, memory, and disk IO. Record the performance indicators of the system, such as response time, throughput, and error rate. Once the system reaches the predetermined full load state, that is, the system load reaches the upper limit specified by the design or test, continue to run the system for a period of time. Help testers observe the stability of the system under full load and detect potential performance bottlenecks. Collect and analyze the performance data of the system under full load. Compare the performance differences between the system under no load and full load to evaluate the scalability and responsiveness of the system. Testers can evaluate the performance of the system under test under high load and identify the system's performance bottlenecks and potential problems. This helps improve system design and improve system stability and reliability. In addition, running the system under full load can also help identify and deal with memory management issues such as memory leaks.

[0036] In some embodiments, an idle state refers to a state in which the system is running without load or with very low load, in which the usage of system resources (such as CPU, memory, disk, and network) is generally low because there is not enough user activity or data processing tasks to occupy these resources.

[0037] In some embodiments, the full load state refers to an operating state in which system resources are fully or nearly fully occupied. In this state, the system load has reached or is close to the upper limit of its design capacity, which is usually achieved through system stress test simulation.

[0038] In some embodiments, system load testing refers to the process of testing the performance and stability of a system by increasing its load, which usually involves using automated testing tools to simulate scenarios where a large number of users use the system simultaneously to observe the performance of the system under different loads.

[0039] In some embodiments, the system to be tested is initially in an unloaded state, that is, the system has very low or no load. By simulating user activities and increasing the load, the system gradually changes from an unloaded state to a fully loaded state. In the fully loaded state, the system continues to run in order to test its performance and stability under high load. This process helps to evaluate the system's maximum carrying capacity, response time, resource utilization, and whether there are performance bottlenecks or memory leaks.

[0040] In step 103, in response to the running time of the first system to be tested reaching a time threshold, the first system to be tested is decompressed to obtain a second system to be tested in the no-load state.

[0041] In some embodiments, the first system to be tested runs under full load for a period of time, and this length of time is called a duration threshold. The duration threshold is a pre-set running time, which is usually determined based on the test purpose and system characteristics. When the running time of the first system to be tested reaches the duration threshold, the system pressurization stops, and the process of simulating user activities and increasing the load ends. System unloading refers to reducing or completely stopping the load on the system so that the system returns to a pressure level less than the pressure threshold. After the system is unloaded, the first system to be tested is transformed into the second system to be tested. The second system to be tested is in a no-load state, that is, the load on the system is reduced or removed, and the resource utilization rate decreases.

[0042] In some embodiments, the above step 103 can also be implemented in the following manner: based on the second system to be tested in the no-load state, perform at least one of the system pressurization and the system decompression to obtain at least one third system to be tested in the no-load state; collect memory object instances for each of the third systems to be tested respectively, and obtain the third memory object instances when each of the third systems to be tested is in the no-load state.

[0043] In some embodiments, the second system to be tested refers to a system that is restored to a no-load state after the system is decompressed. This state is the initial state of the system after undergoing a high-load test and decompression, and is used for subsequent test cycles. The second system to be tested is pressurized again to simulate a high-load environment. This process is intended to repeat the behavior of the test system under high pressure and observe whether the system can operate stably. After pressurization for a predetermined period of time or reaching a predetermined load condition, pressurization is stopped to restore the system to a low-load state. System decompression (Unloading) is to reduce or completely stop the load on the system so that the system returns to a no-load state. After each system pressurization and decompression cycle is completed, the second system to be tested is transformed into a third system to be tested. The third system to be tested refers to a system that has undergone at least one pressurization and decompression process, and it may have undergone multiple such cycles. The collection of memory object instances for each third system to be tested involves using a memory analysis tool to record and monitor the number and type of memory objects in the system. The third memory object instance refers to the memory object data collected when each third system under test is in an unloaded state, and the data is used to analyze the memory usage of the system after multiple pressurization and decompression cycles to detect memory leaks or other memory management problems.

[0044] As an example, suppose that the system performance and memory management of an online shopping website are being tested. The system is initialized and in an idle state. There is no user access or order processing. Use a memory analysis tool to record the current memory usage as a baseline value. Use an automated testing tool (such as JMeter) to simulate multiple users accessing the website at the same time, performing operations such as searching, browsing products, and placing orders. Continue to pressurize until the system reaches a full load state, that is, the CPU and memory usage reach the set threshold. Stop the automated testing tool, and the simulated user access and order processing stop. The system gradually returns to an idle state and waits for a period of time to stabilize memory usage. After the system is decompressed, the third system to be tested is obtained, which has undergone a complete pressurization and decompression process. Use a memory analysis tool to record the current memory usage again. Collect memory object instances for the third system to be tested, and record the number of instances of different types of objects, such as product objects, user objects, and order objects. Obtain the third memory object instance, that is, the memory object data in the idle state after the third test cycle. Compare the third memory object instance with the initial baseline value to analyze the changes in memory usage. The memory stability of the system after the pressurization and decompression cycle can be evaluated. If the number of third memory object instances does not change significantly from the initial baseline value, the system performs well in memory management and there is no obvious memory leak. If an abnormal increase in the number of memory object instances is found, it may indicate that the system has a memory leak problem, which requires further investigation and repair, helping to ensure that the system can maintain good memory management capabilities after high load and long-term operation, thereby improving system stability and reliability.

[0045] In this way, by performing at least one system pressurization and system decompression based on the second system to be tested in the no-load state, at least one third system to be tested in the no-load state is obtained, and the memory object instance is collected for each third system to be tested to obtain the third memory object instance, which can effectively evaluate the memory management performance and stability of the system, and help ensure that the system can quickly return to a normal state after experiencing a high load, and that there is no abnormal increase in memory usage, thereby reducing the risk of memory leaks. In addition, by comparing the memory object instance data in different test cycles, potential memory leak problems can be identified and located, providing developers with valuable information so that they can fix these problems in a timely manner and improve system reliability and user experience.

[0046] In step 104, memory object instances are collected for the second system under test to obtain second memory object instances when the second system under test is in the no-load state.

[0047] In some embodiments, collecting memory object instances for the second system to be tested refers to the process of using a memory analysis tool to collect memory usage data of the system in an unloaded state. Determine the memory objects that need to be paid attention to, which may be key data structures, class instances or global variables in the system. Select a suitable memory analysis tool according to the programming language and operating environment of the system. For example, for Java applications, JProfiler or VisualVM may be used; for C / C++ applications, Valgrind may be used. Start the memory analysis tool and let the second system to be tested run for a long enough time until the memory usage is stable. After the system is stable, use the memory analysis tool to collect the current memory snapshot and record the number, type and size of each memory object instance. Extract data about the preset memory object instance from the collected memory snapshot. These data constitute the second memory object instance, which is the memory usage benchmark of the system in an unloaded state. Testers can understand the memory usage of the system under no load, which is crucial for subsequent performance testing and stress testing. If the number of memory object instances is found to increase abnormally in subsequent tests, it may be related to memory leaks. By comparing memory usage at different test stages, developers can locate and fix memory leaks, thereby improving system stability and performance.

[0048] In step 105, based on the number of the first memory object instances and the number of the second memory object instances, a memory test is performed on the system to be tested to obtain a test result.

[0049] In some embodiments, the test result is used to indicate whether there is a memory leak in the system to be tested.

[0050] In some embodiments, the number of first memory object instances refers to the memory usage benchmark of the system in a no-load state, that is, the number of memory object instances occupied by the system when there is no user interaction or business processing. The number of second memory object instances refers to the number of memory object instances when the system returns to a no-load state after the system has undergone a pressurization and decompression cycle. Compare the number of first memory object instances and the number of second memory object instances to determine whether there is a significant change in memory usage. If the number of second memory object instances is significantly greater than the number of first memory object instances, this may be a sign of a memory leak.

[0051] In some embodiments, the test results are used to indicate whether the system has a memory leak. If the number of memory object instances does not change significantly before and after the test, then it can be assumed that the system memory is well managed and no memory leaks are detected. If the number of memory object instances increases significantly, then there may be a memory leak that requires further investigation and repair. If the test results indicate a memory leak, the developer needs to analyze the system code to find out which parts may cause the memory leak. This may involve checking the code for object creation, object destruction, and resource release, as well as optimizing memory allocation strategies.

[0052] In some embodiments, the above step 105 can also be implemented in the following manner: determine the quantity difference between the quantity of the first memory object instances and the quantity of the second memory object instances; compare the quantity difference with a difference threshold to obtain a comparison result; when the comparison result indicates that the quantity difference is greater than or equal to the difference threshold, determine the test result as the existence of the memory leak in the system to be tested; when the comparison result indicates that the quantity difference is less than the difference threshold, determine the test result as the absence of the memory leak in the system to be tested.

[0053] In some embodiments, the difference between the number of first memory object instances and the number of second memory object instances is calculated. Difference = number of second memory object instances - number of first memory object instances; a difference threshold is set, and this threshold is predetermined based on factors such as system specifications, performance requirements, and historical data. The difference threshold can be a fixed value or a percentage relative to the number of first memory object instances. The calculated difference is compared with the difference threshold. If the difference is greater than or equal to the difference threshold, the comparison result indicates that the system may have a memory leak. If the difference is less than the difference threshold, the comparison result indicates that the system memory management is good and there is no memory leak. According to the comparison result, the test result is determined. If the difference is greater than or equal to the difference threshold, the test result is determined as a memory leak in the system. If the difference is less than the difference threshold, the test result is determined as no memory leak in the system.

[0054] As an example, a memory leak test is being conducted on an online game server. When the server is initialized and no players are connected, the memory analysis tool is used to collect memory usage data to obtain the number of first memory object instances. Assume that at this time, the server has 10,000 object instances occupying memory. The automated testing tool is used to simulate 1,000 players logging into the game at the same time, performing a series of operations (such as creating characters, exploring maps, participating in battles, etc.), and then disconnecting. After all players are disconnected, the server returns to an idle state, and the memory analysis tool is used again to collect memory usage data to obtain the number of second memory object instances. Assume that at this time, the server has 10,050 object instances occupying memory. Calculate the difference between the number of first memory object instances and the number of second memory object instances. Difference = number of second memory object instances - number of first memory object instances = 10,050 - 10,000 = 50. Set a difference threshold based on the specifications and performance requirements of the game server. For example, set the threshold to 100. Compare the calculated difference of 50 with the difference threshold of 100. The difference value 50 is less than the difference threshold value 100, so the comparison result indicates that the system memory management is good and there is no memory leak. According to the comparison result, it is determined that the test result is that there is no memory leak in the system.

[0055] In this way, by analyzing the difference between the number of instances of the first memory object and the number of instances of the second memory object, and comparing the difference with the difference threshold, a clear indication can be obtained to determine whether there is a memory leak in the system to be tested. A quantitative evaluation method is provided to help developers to promptly discover and solve potential memory leak problems. If the test results show that the difference in quantity is greater than or equal to the difference threshold, it can be determined that there is a memory leak in the system. At this time, the developer needs to further investigate and fix the problem to avoid the gradual decline of system performance over time. On the contrary, if the difference in quantity is less than the difference threshold, it can be determined that the system memory is well managed and there is no memory leak, which provides confidence for developers to focus on other performance optimization work. In short, this memory leak detection method helps to ensure that the system can maintain stability and reliability under high load and long-term operation, thereby improving the user experience.

[0056] In some embodiments, the above step 105 can be implemented as follows: based on the number of the first memory object instances, the number of the second memory object instances and the number of the third memory object instances, a memory test is performed on the system to be tested to obtain the test result.

[0057] In some embodiments, the third system to be tested includes an i-th reference system, where i is a positive integer not less than 1 and less than N, and N is used to indicate the total number of times the second system to be tested executes the system pressurization and the system depressurization.

[0058] In some embodiments, the above-mentioned second system to be tested in the no-load state, performing the system pressurization and the system decompression at least once to obtain at least one third system to be tested in the no-load state, can be achieved in the following way: performing the system pressurization and the system decompression on the second system to be tested in the no-load state to obtain the first reference system in the no-load state; traversing i to perform the following processing: performing the system pressurization and the system decompression on the i-th reference system in the no-load state to obtain the i+1-th reference system in the no-load state.

[0059] In some embodiments, starting from the second system to be tested in the no-load state, the system is pressurized to make the system reach the full-load state, and then the system is depressurized to restore the system to the no-load state. In this way, the first reference system, i.e., the 1st reference system, is obtained. Traverse all i values ​​from 1 to N-1, and perform the following steps for each i value: the i-th reference system in the no-load state is pressurized to make it reach the full-load state. The system is depressurized for the system in the full-load state to restore it to the no-load state, and the i+1th reference system is obtained. After each cycle, the memory object instances of the i-th reference system in the no-load state are collected, and the number and type of memory objects are recorded. By comparing the number of memory object instances collected in each cycle, the memory usage of the system can be analyzed. If it is found that the number of memory object instances in a certain cycle increases significantly, it may indicate that a memory leak occurs in the system in the cycle. According to the change in the number of memory object instances, it can be determined whether a memory leak occurs in the system. If the number of memory object instances in a certain cycle increases by more than a predetermined difference threshold, it can be considered that a memory leak occurs in the system in the cycle.

[0060] As an example, an online banking system is being stress-tested to ensure its stability and memory management capabilities under high load. The second system to be tested is in an unloaded state, that is, no users are performing any transaction operations. The second system to be tested is stress-tested to simulate a large number of user logins, account balance inquiries, transfers, and other operations. After the system is stress-tested, the system is depressurized to restore the system to an unloaded state. At this time, the first reference system, the first reference system, is obtained. N is set to 5, that is, 5 cycles of system stress-testing and depressurization are performed. The first reference system is stress-tested to simulate high-load operations. After the system is stress-tested, the system is depressurized to restore the system to an unloaded state. At this time, the second reference system is obtained. Repeat the above steps until the fifth reference system is obtained. At the end of each cycle, the memory object instances of the current reference system are collected. The number and type of memory object instances in each cycle are recorded. The number of memory object instances collected in each cycle is compared. If the number of memory object instances in a cycle is found to increase abnormally, this may indicate that the system has a memory leak in that cycle.

[0061] In this way, by performing a series of system pressurization and system decompression cycles and obtaining multiple reference systems, the performance and memory management capabilities of the system under test can be systematically evaluated. This method helps to identify and locate memory leaks and improve the stability and reliability of the system. In addition, by comparing the number of memory object instances between different reference systems, it is possible to more accurately determine whether the system has memory leaks, so that timely measures can be taken to repair them, which can help developers optimize memory allocation strategies, improve system performance and response speed under high load, and thus improve user experience and satisfaction.

[0062] In some embodiments, the system pressurization and the system decompression of the second system to be tested in the no-load state to obtain the first reference system in the no-load state can be achieved as follows: the system pressurization is performed on the second system to be tested in the no-load state to obtain the first candidate system in the full-load state, and the first candidate system is run; in response to the running time of the first candidate system reaching a time threshold, the system decompresses the first candidate system to obtain the first reference system in the no-load state.

[0063] In some embodiments, the system is pressurized on the second system to be tested in the no-load state, usually by simulating a high-load situation, such as simulating a large number of concurrent user requests or executing complex data processing tasks through an automated testing tool. After the system is pressurized, the system reaches a full-load state, and the system state obtained at this time is called the first candidate system. The first candidate system is run in a full-load state to observe its behavior and performance under pressure. According to the test objectives and system characteristics, a time threshold is set, which determines the maximum time that the first candidate system runs in a full-load state. When the running time of the first candidate system reaches the time threshold, the simulated high-load operation is stopped, and the system is decompressed, that is, user requests and data processing tasks are reduced or stopped, so that the system gradually returns to a no-load state. After the system is decompressed, the system returns to a no-load state, and the system state obtained at this time is called the first reference system. By simulating the high-load situation in the actual operating environment, the performance of the system under high pressure is evaluated, and the recovery ability of the system after the pressure is released is checked. In this way, it is possible to detect whether the system has performance bottlenecks, resource exhaustion or memory leaks, thereby ensuring that the system can maintain stability and reliability in actual operation.

[0064] As an example, an online e-commerce platform is being performance tested to ensure that it can operate normally during peak shopping hours. The second system to be tested is in an unloaded state, that is, no users are shopping. Use automated testing tools to simulate a large number of users logging into the platform at the same time to search for products, add products to the shopping cart, place orders, and so on, so as to stress the system. After a period of stress testing, the system reaches a full load state, and the state obtained at this time is called the first candidate system. Run the first candidate system in a full load state to observe its behavior and performance under high load. According to the test plan and system characteristics, set a duration threshold, for example, set it to 1 hour. When the running time of the first candidate system reaches 1 hour, stop the simulated high-load operation and decompress the system, that is, reduce or stop user requests and data processing tasks, and let the system gradually return to a no-load state. After the system is decompressed, the system returns to a no-load state, and the state obtained at this time is called the first reference system. Evaluate the performance of the e-commerce platform under high pressure and check the system's ability to recover after the pressure is relieved. If performance bottlenecks, resource exhaustion, or memory leaks are found in the system during the test, we need to optimize and repair them accordingly. If the system performs well under high load and can quickly return to normal state after the stress is relieved, the performance and stability of the system can be considered reliable.

[0065] In this way, by pressurizing and depressurizing the second system to be tested in a no-load state, the first reference system in a no-load state can be obtained. This testing method helps to simulate high-load conditions in a real environment and evaluate the performance and stability of the system. By controlling the running time of the first candidate system, the accuracy and reliability of the test can be ensured. When the running time of the first candidate system reaches the set time threshold, the system is decompressed to restore the system to a no-load state. In this way, an accurate first reference system can be obtained for subsequent performance analysis and optimization. It helps developers to discover and solve potential performance problems in a timely manner and improve the overall performance and user experience of the system. At the same time, by pressurizing and decompressing the system, the performance difference of the system under high load and low load conditions can be evaluated, providing a basis for further optimization of the system.

[0066] In some embodiments, the system pressurization and the system decompression of the i-th reference system in the no-load state to obtain the i+1-th reference system in the no-load state can be achieved as follows: the system pressurization of the i-th reference system in the no-load state to obtain the i+1-th candidate system in the full-load state, and running the i+1-th candidate system; in response to the running time of the i+1-th candidate system reaching a time threshold, the system decompressing the i+1-th candidate system to obtain the i+1-th reference system in the no-load state.

[0067] In some embodiments, for each reference system (the i-th reference system), a process of compression and decompression is performed to obtain a new reference system (the i+1-th reference system). For each i-th reference system in an unloaded state, a system compression operation is performed to simulate a high load situation, such as simulating a large number of user requests through an automated testing tool, executing complex data processing tasks, etc., so as to push the system to a full load state. After the system is compressed, the i+1-th candidate system in a full load state is obtained, which is a system state in a high load state. The i+1-th candidate system is run in a full load state to observe its behavior and performance under high pressure. According to the test objectives and system characteristics, a time threshold is set, for example, set to 30 minutes. When the running time of the i+1-th candidate system reaches the set time threshold (for example, 30 minutes), the simulated high load operation is stopped, and the system is decompressed, that is, user requests and data processing tasks are gradually reduced to restore the system to an unloaded state. After the system is decompressed, the system is restored to an unloaded state, and the state obtained at this time is called the i+1-th reference system. It can simulate the performance of the system under test under different load conditions and evaluate the stability, response speed and resource consumption of the system under high and low load conditions. If problems such as performance degradation or resource exhaustion are found in a certain cycle, further analysis and optimization can be carried out. In addition, by comparing the performance data of multiple reference systems, the performance bottleneck of the system can be identified and corresponding measures can be taken to improve the overall performance of the system and user experience.

[0068] As an example, suppose we are doing a performance test on an online ticket booking system to ensure that it can handle a large number of user requests during a major event. At the beginning of the test, the system is in an unloaded state, and no users are purchasing or querying ticket information. The i-th reference system is stressed, and the automated testing tool is used to simulate thousands of users logging into the system at the same time to perform operations such as searching for activities, selecting tickets, and submitting orders. After the system is stressed, the system reaches a full load state, and the state obtained at this time is called the i+1 candidate system. Run the i+1 candidate system in a fully loaded state to observe its behavior and performance under high load. According to the test plan and system characteristics, set a duration threshold, for example, set it to 1 hour. When the running time of the i+1 candidate system reaches 1 hour, stop the simulated high-load operation and decompress the system, that is, gradually reduce user requests and data processing tasks, and restore the system to an unloaded state. After the system is decompressed, the system returns to an unloaded state, and the state obtained at this time is called the i+1 reference system. The performance of the ticket booking system under different load conditions can be simulated to evaluate the stability, response speed and resource consumption of the system under high and low load conditions. If performance degradation or resource exhaustion is found in a certain cycle, further analysis and optimization can be carried out.

[0069] In this way, the process of pressurizing and depressurizing the i-th reference system under no-load conditions to obtain the i+1-th reference system can effectively evaluate and test the performance and stability of the system to be tested. System pressurization simulates a high-load environment, allowing us to observe the performance of the system under high pressure, such as response time, resource utilization, etc. System depressurization helps detect the system's ability to recover after the load is reduced, ensuring that the system can quickly return to normal. This cyclic test helps to discover and solve potential performance bottlenecks and resource exhaustion problems, and improve the overall performance and reliability of the system. By comparing the performance data of multiple reference systems, it is possible to identify system performance improvements and optimization space, providing a basis for subsequent development and improvement.

[0070] In some embodiments, the above-mentioned performing a memory test on the system to be tested based on the number of the first memory object instances, the number of the second memory object instances, and the number of the third memory object instances to obtain the test result can be implemented as follows: performing a memory test on the system to be tested based on the number of the first memory object instances and the number of the second memory object instances to obtain a first test result; performing a memory test on the system to be tested based on the number of the second memory object instances and the number of the third memory object instances to obtain a second test result; determining the test result based on the first test result and the second test result.

[0071] In some embodiments, the number of first memory object instances is collected, which is the number of memory objects recorded before the system is pressurized. The number of second memory object instances is collected, which is the number of memory objects recorded after the system is pressurized. The number of third memory object instances is collected, which is the number of memory objects recorded after the system is depressurized. Based on the number of first memory object instances and the number of second memory object instances, a first memory test is performed to evaluate the memory usage during the system pressurization process, and a first test result is obtained. Based on the number of second memory object instances and the number of third memory object instances, a second memory test is performed to evaluate the memory release during the system depressurization process, and a second test result is obtained. The first test result and the second test result are analyzed, and the change in the number of memory object instances before and after the system is pressurized, and the change in the number of memory object instances after the system is depressurized are compared. Based on the comparison result, it is determined whether there is a memory leak, that is, whether the number of memory object instances after the system is depressurized is significantly lower than the number after pressurization, and is not lower than the number before pressurization.

[0072] As an example, an online document editor is being tested for memory to ensure that it can efficiently manage memory when processing a large number of documents and user operations. The number of first memory object instances: When the system is started and there is no user activity, the number of memory objects in the current system is recorded. After the system is pressurized, that is, after the user starts editing a document, inserting a picture, adding a comment, etc., the current number of memory objects is recorded. After the system is depressurized, that is, when the user stops the operation and the system returns to an idle state, the number of memory objects is recorded again. The first test result is to compare the number of first memory object instances with the number of second memory object instances, and analyze the growth of memory objects during user operations to determine whether there is a memory leak. The second test result is to compare the number of second memory object instances with the number of third memory object instances, and analyze the reduction of memory objects after the system is depressurized to determine whether the system can effectively release memory that is no longer needed. If the number of first memory object instances and the number of second memory object instances grow too much, and the number of third memory object instances does not decrease to or close to the number of first memory object instances, this may indicate a memory leak. If the number of second memory object instances and the number of third memory object instances do not change much, this indicates that the system can effectively manage memory when processing user operations and can release memory after the operation is completed.

[0073] In this way, by performing memory testing on the system to be tested, the memory management capability of the system can be effectively evaluated. First, by comparing the number of first memory object instances with the number of second memory object instances, we can understand the memory usage of the system when processing user operations, thereby determining whether there is a memory leak. Then, by comparing the number of second memory object instances with the number of third memory object instances, we can evaluate the memory release of the system after decompression to ensure that the system can effectively recycle memory that is no longer needed. Based on the results of these two tests, we can comprehensively judge whether the system's memory management is efficient, whether there is a memory leak problem, and whether the system can release memory that is no longer needed in a timely manner.

[0074] In some embodiments, the third system to be tested includes an i-th reference system, where i is a positive integer not less than 1 and less than N, and N is used to indicate the total number of times the second system to be tested executes the system pressurization and the system decompression. The i-th reference system corresponds one-to-one to the third memory object instance, and the second test result includes the second test results of each of the i-th reference systems.

[0075] In some embodiments, the above-mentioned memory test of the system to be tested based on the number of the second memory object instances and the number of the third memory object instances to obtain the second test result can be achieved in the following manner: based on the number of the second memory object instances and the number of the third memory object instances of the first reference system, a memory test is performed on the system to be tested to obtain the second test result of the first reference system; traversing i to perform the following processing: based on the number of the third memory object instances of the first reference system and the number of the third memory object instances of the i-th reference system, a memory test is performed on the system to be tested to obtain the second test result of the i-th reference system.

[0076] In some embodiments, the third system to be tested includes multiple i-th reference systems, where i is an integer that increases from 1 to N-1. N represents the total number of times the system is pressurized and decompressed. The i-th reference system corresponds to the third memory object instance one-to-one, which means that each reference system corresponds to a specific number of memory object instances. The second test result is a set consisting of the second test results of each i-th reference system. Based on the number of second memory object instances and the number of third memory object instances of the first reference system, a memory test is performed on the system to be tested to obtain the second test result of the first reference system. Traverse each i-th reference system (starting from i=2), and based on the number of third memory object instances of the i-1th reference system and the number of third memory object instances of the current i-th reference system, a memory test is performed on the system to obtain the second test result of the i-th reference system. The purpose of the memory test is to determine the memory usage of the system when performing pressurization and decompression operations by comparing the number of memory object instances between different reference systems, so as to evaluate whether the system has memory leaks or other memory management problems.

[0077] As an example, an online gaming service is being performance tested to ensure that it can effectively manage memory when handling a large number of player logins and game operations. The third system to be tested includes multiple i-th reference systems, where i is an integer that increases from 1 to N-1. N represents the total number of times the system is pressurized and decompressed. The i-th reference system corresponds to the third memory object instance one-to-one, which means that each reference system corresponds to a specific number of memory object instances. The second test result is a set of second test results of each i-th reference system. Based on the number of second memory object instances and the number of third memory object instances of the first reference system, a memory test is performed on the system to be tested to obtain the second test result of the first reference system. Traverse each i-th reference system (starting from i=2), and based on the number of third memory object instances of the i-1th reference system and the number of third memory object instances of the current i-th reference system, a memory test is performed on the system to obtain the second test result of the i-th reference system. The purpose of the memory test is to determine the memory usage of the system when performing pressurization and decompression operations by comparing the number of memory object instances between different reference systems, so as to evaluate whether the system has memory leaks or other memory management problems.

[0078] In this way, by performing phased memory testing on the system under test, the system's memory management performance can be systematically evaluated and monitored. At each stage, we record the number of memory object instances, so that we can compare and analyze the system's memory usage under different loads, which helps to identify and solve memory leaks and ensure that the system can effectively allocate and reclaim memory when processing large amounts of data or user operations. In addition, by comparing the test results at different stages, we can evaluate whether the system's memory management strategy is effective and whether the system can maintain stability and reliability under different load conditions.

[0079] In some embodiments, determining the test result based on the first test result and the second test result can be achieved in the following manner: when the first test result indicates that the system to be tested has the memory leak, determining the first test result as the target test result; when the second test result indicates that the system to be tested does not have the memory leak, determining the second test result as the target test result; counting the number of the target test results, and when the number of the target test results is greater than a number threshold, determining the test result as the existence of the memory leak in the system to be tested; when the number of the target test results is less than or equal to the number threshold, determining the test result as the absence of the memory leak in the system to be tested.

[0080] In some embodiments, if the first test result (based on the number of memory object instances after the system is pressurized) indicates that the system has a memory leak, this means that the memory usage has not decreased accordingly during the process of increasing system pressure, indicating that the system has failed to effectively release memory that is no longer needed. If the second test result (based on the number of memory object instances after the system is depressurized) indicates that the system does not have a memory leak, this means that after the system pressure is reduced, the memory usage has decreased, indicating that the system can effectively recycle memory. According to the first test result and the second test result, determine the target test result. If the first test result indicates that there is a memory leak, it is used as the target test result; if the second test result indicates that there is no memory leak, it is used as the target test result. Count the number of target test results, that is, the number of test results indicating that there is or is not a memory leak in the system. Compare the number of target test results counted with a preset number threshold. If the number of target test results is greater than the number threshold, it can be determined that there is a memory leak in the system to be tested. If the number of target test results is less than or equal to the number threshold, it can be determined that there is no memory leak in the system to be tested.

[0081] As an example, an online trading platform is being tested for memory to ensure that it can effectively manage memory when processing a large number of trading requests. It is decided to conduct N tests, each of which includes two stages: system pressurization and decompression. In the first stage of each test, we simulate a large number of users performing trading operations at the same time, and record the number of memory object instances at this time as the first number of memory object instances. In the second stage of each test, we stop simulating user trading operations and record the number of memory object instances at this time as the third number of memory object instances. For each test, the first number of memory object instances and the third number of memory object instances are compared. If it is found that the number of the third number of memory object instances has not decreased significantly, it is considered that there is a memory leak in the system, and the first test result (the result indicating the existence of a memory leak) is determined as the target test result. If the number of the third number of memory object instances is significantly reduced, it indicates that there is no memory leak in the system, and the second test result (the result indicating the absence of a memory leak) is determined as the target test result. The number of target test results is counted, that is, the number of test results indicating the presence or absence of a memory leak. If the number of target test results is greater than the preset number threshold, for example, more than 50% of the test results indicate the presence of a memory leak, then we can determine that there is a memory leak in the system to be tested. If the number of target test results is less than or equal to the preset number threshold, then we can determine that there is no memory leak in the system under test.

[0082] In this way, the memory management efficiency of the system to be tested can be effectively evaluated. When the system has a memory leak, the first test result can capture this problem in time. By determining it as the target test result, it can ensure that the developer can take prompt action to repair it. When the system has no memory leak, the second test result can accurately reflect the memory usage of the system. By determining it as the target test result, unnecessary repair work can be avoided. By counting the number of target test results and comparing it with the preset number threshold, it is possible to scientifically determine whether the system has a memory leak and make a reasonable decision.

[0083] In some embodiments, after executing the above step 105, the following processing may also be performed: when the test result indicates that the system under test has a memory leak, the system under test is repaired to obtain a repaired system under test, and the repaired system under test does not have the memory leak.

[0084] In some embodiments, memory leaks in the system are identified by performing memory testing. The test results provide evidence that the system fails to properly release memory when processing certain operations, resulting in an abnormal increase in memory usage. Once a memory leak is confirmed, the development team will conduct an in-depth analysis of the system to determine the root cause of the leak. This may include reviewing the code, analyzing memory allocation and release patterns, using memory analysis tools, etc. Based on the analysis results, the developer will implement fixes. These measures may include changing code logic, optimizing data structures, fixing incorrect memory allocation and release calls, updating third-party libraries or components, etc. After the repair is completed, the system needs to be tested again to verify whether the memory leak problem has been resolved. This usually involves repeating the previous memory testing process to ensure that the system no longer exhibits memory leaks under the same operating conditions. If the repair is successful, the test results will show that there is no memory leak in the repaired system under test. This means that the system is now able to manage memory correctly during operation and there will be no unlimited growth in memory usage. The repaired system should be tested for a period of long-term operation to verify its stability and performance. This helps to ensure that the repair measures not only solve the known memory leak problem, but also do not introduce new problems.

[0085] As an example, an online banking system is being tested for memory to ensure that it can effectively manage memory when processing a large number of user transaction requests. During the memory test, we found that the system's memory usage continued to increase after processing a large number of user logins and transaction operations, and did not return to normal levels after the system was decompressed. The test results indicated a memory leak. The system's code was reviewed and a memory allocation problem was found that was not released in the user session management. Whenever a user logs in, the system allocates a piece of memory to store the user's session information, but after the user logs out, the system does not properly release this memory. The problem in the session management code was fixed to ensure that the allocated memory is properly released when the user logs out. After the fix was completed, the system was tested again. This test simulated the process of users logging in, performing transaction operations, and logging out. The test results showed that after the user logs out, the memory usage quickly returned to normal levels, and there was no continuous increase in memory. The memory usage of the repaired system under test remained stable when processing user logins and transaction operations, and there was no memory leak. The repaired system was deployed to the production environment and tested for a long period of time. The system performed stably, with no memory leaks or other performance issues.

[0086] In this way, resources are optimized and memory usage efficiency is improved, thereby reducing hardware resource consumption and upgrade costs. The stability and reliability of the system are enhanced, reducing the risk of system crashes and performance degradation caused by memory leaks, and improving user trust and satisfaction. The system's performance is improved, the response speed is accelerated, the user's transaction and operation experience is improved, and the market competitiveness is enhanced. The system's maintenance cost is reduced, the potential problems and failures caused by memory leaks are reduced, and the development and operation efficiency is improved. By fixing the memory leak, the system under test has achieved more efficient, stable and reliable operation.

[0087] In this way, by collecting memory object instances of the system to be tested in the no-load state, the first memory object instance of the system to be tested in the no-load state is obtained; the system to be tested in the no-load state is pressurized to obtain the first system to be tested in the full-load state, and the first system to be tested is run; in response to the running time of the first system to be tested reaching the time threshold, the first system to be tested is decompressed to obtain the second system to be tested in the no-load state; the memory object instance of the second system to be tested is collected to obtain the second memory object instance of the second system to be tested in the no-load state; based on the number of the first memory object instance and the number of the second memory object instance, the system to be tested is tested for memory and the test result is obtained. In this way, when the system has no load or the load is very light (i.e., no-load state), the information of all memory object instances in the current system is collected to obtain the first memory object instance set. This set reflects the memory usage of the system when there is no load. The system is pressurized to simulate the highest load situation that may be encountered in actual operation, and a system in the full-load state is obtained. The system is run for a period of time in this state to ensure that the system has gone through a complete life cycle, including memory allocation and recycling. When the system runs for a preset time threshold, stop the compression, let the system decompress and return to the no-load state, collect the memory object instance information at this time, and obtain the second memory object instance set. This set reflects the memory usage of the system when it returns to normal after high load. Compare the number of objects in the first memory object instance set and the second memory object instance set. If the number of objects in the second set is significantly more than the first set, this may indicate that there is a memory leak in the system during operation, because even after decompression under high load, there are still additional objects in the memory that have not been recycled. The collection of memory object instances in no-load and full-load states can be completed in one run, which reduces the test time and improves the test efficiency. By comparing the number of memory object instances in two different states, it is possible to quickly determine whether there is a memory leak without in-depth analysis of the life cycle of each object. By comparing the number of memory object instances in two states, it is possible to quickly determine whether there is a memory leak without in-depth analysis of the life cycle of each object, thereby effectively improving the efficiency of memory testing.

[0088] The present application is described below in conjunction with application examples.

[0089] By defining the test conditions, memory test objects and test times of the system under test, the state of the test system is divided into two states: no-load and no-load after full load; the memory of the system under test is decomposed into specific memory objects. According to the preset test times, the system under test is tested according to the test conditions. First, when the system is in the no-load state for the first time, the number of instances of the preset memory object is obtained through memory collection. Then, the test system is pressurized to the full-load state according to the test conditions. After a period of full load, the pressurization is stopped and restored to the no-load state. After the system is stable, the number of instances of the preset memory object is collected again. The system under test is repeatedly loaded and then no-loaded according to the preset test times, and the number of instances of the preset memory object after each no-load is collected. By comparing the number of instances of the memory objects collected before and after no-load, it is determined whether there is a possibility of leakage of the memory object. As a result, the time and manpower consumption of tests such as memory leaks can be reduced, and developers can be helped to locate specific leaked memory objects, which greatly reduces the technical difficulty of early warning and positioning of possible memory leaks.

[0090] In some embodiments, see Figure 3 , Figure 3 This is a schematic diagram of the memory testing method provided in the embodiment of the present application. Figure 3 The memory testing method provided in the embodiment of the present application can be Figure 3 Steps 201 to 204 are shown to be implemented.

[0091] In step 201, the test conditions of the system under test, the name of the memory object under test, the number of tests and the alarm threshold are defined.

[0092] Set test conditions for the system under test, connect to the system under test through Mock (virtual business object), and call the mock module to pressurize the system under test according to the test conditions so that the system under test reaches a full load state.

[0093] Set the number of tests for the system under test, where one test is a full load followed by an unloaded test. Repeatedly load the system under test with full load and then unload it according to the number of tests.

[0094] Set the name of the memory object that needs to be tested in the system under test. Use the memory acquisition module to perform memory acquisition on the preset memory object each time the system under test is unloaded, and obtain the number of instances of the memory object as the test indicator during the memory test. Compare the number of instances of the memory object collected each time with the previous one. If the latter is greater than the previous one, the counter is increased by 1, and the result k of the counter value / number of tests is calculated.

[0095] Define an alarm threshold for the system under test, where the alarm threshold is based on the comparison of the analysis results of the memory objects under the preset test conditions and test times of the system under test. If the result k is greater than the alarm threshold, it is considered that there is a risk of memory leak.

[0096] Use the preset alarm threshold as a reference to analyze whether there is a risk of system memory leakage.

[0097] In step 202, memory object data of the system under test is collected according to the test conditions and the test times.

[0098] In the memory recycling mechanism, GC (garbage collection) is performed every once in a while to release useless memory space. The objects recycled by GC are generally in the heap memory but not pointed to by the stack objects. These spaces are useless memory spaces in the system because they are not referenced, which is the so-called garbage memory. However, in a system with memory leaks, the leaked memory objects are always referenced by stack objects, so they will not be recycled by GC and will remain in the system until FullGC occurs, causing the system to restart.

[0099] Therefore, if there is a memory leak in the system, even if the system is restored to an unloaded state, the leaked memory objects will still exist in the system and will not be released.

[0100] The test is performed according to the test conditions and test times. Each time after full load and then no load, the memory collection module collects the number of instances of the preset object memory.

[0101] In step 203, the number of instances of the memory object after each unloading is analyzed to determine whether a memory object leak occurs.

[0102] Set the counter, the initial value of the counter is 0.

[0103] Compare the number of instances of the next memory object with the number of instances of the previous memory object. If it is greater than 0, the counter is increased by 1.

[0104] Subtract the last counter value from (number of tests - 1) to get the result k.

[0105] The result k is compared with the preset alarm threshold. If k is greater than the alarm threshold, it is determined that there is a risk of memory leak in this memory object.

[0106] In step 204, an alarm is reported based on the analysis result of the memory analysis module.

[0107] According to the analysis results, the leakage information of the memory object including the memory object name, the number of memory object instances, etc. is reported to the console module.

[0108] In some embodiments, the following provides a modular description of the present solution to facilitate a better understanding of the present solution. Figure 2 , Figure 2 It is a schematic diagram of the principle of the memory testing method provided in an embodiment of the present application, and the specific implementation method is as follows: a console module is used to provide an entry for collecting and analyzing system process functions. The functions provided by the console module are as follows: providing an entry for setting test conditions, for users to control the memory pressure of the system under test. Providing an entry for setting the number of tests, for users to set the number of automatic memory tests. Providing an entry for setting the alarm threshold of memory objects, for users to set the alarm threshold of the system. Providing an entry for batch setting the names of the memory objects of the system under test, for users to set the names of the memory objects under test of the system. Providing an interface for receiving memory leak risk alarms and specific leaking objects, for displaying memory test results to users.

[0109] In some embodiments, see Figure 2 , the console module provides an entry for importing the memory of the system under test object, which is used to improve the above functions. The Mock module is used to connect with the system under test, provide a scene that simulates the real working of the system under test, and make the system under test run normally by calling the external interface of the system under test. Provide an entry for receiving the call of the console module, so that the mock module can start pressurizing the system under test according to the requirements of the console module. In actual application, the above Mock module needs to be customized according to the system under test. The memory acquisition processing module, according to the preset memory object name, collects the collection of current memory objects for the system under test after no-load, and traverses all the collected memory objects to obtain the corresponding number of memory instances. And store the collected data in a Map with the memory instance name as key and the list of the number of memory objects at each no-load as value. According to the preset negotiated interface, an interface for opening the memory acquisition function is provided for the console module to call. After the collected memory data, it is reported to the memory analysis module according to the preset negotiated interface. The memory analysis module analyzes and compares the incoming memory information to obtain the memory test analysis results. The memory analysis operation includes: after receiving the data reported by the memory acquisition module, analyzing and comparing the instance quantity collection of each memory object in the Map.

[0110] In some embodiments, the memory analysis module starts a counter for each memory object, and the initial value of the counter is 0. The number of all memory instances of each memory object is compared and analyzed before and after. If the number of the next memory instance is greater than the number of the previous memory instance, the counter is increased by 1. After traversing all the memory instances of each memory object, the counter is divided by the number of tests to obtain the result k. Finally, k is compared with the alarm threshold.

[0111] In some embodiments, based on the analysis results, an alarm of the memory leak risk and data of each memory leak point including the name of the memory object, the number of memory object instances, etc. are reported to the console module.

[0112] The following is a detailed description of each step.

[0113] In some embodiments, the console module provides four interfaces for setting test conditions, test times, memory object names, and alarm thresholds according to input from the console interface.

[0114] Controller.setTestCondition(int level) is used to set the test condition, where level is the degree of pressure on the system under test. It can be set to multiple levels according to the actual situation. It is not recommended to set the level to a very large level, and 1 to 5 are recommended. If the value is set too large, the system under test may restart due to memory overflow before reaching full load during pressure. Controller.setTestTimes(int times) is used to set the number of tests, where times is the number of tests, and it is recommended to be between 1 and 100. If the value is set too large, the memory test time will be longer.

[0115] Controller.setMemoryObjects(List <string>memoryObjects) is used to set the name of the memory object of the system under test. There can be multiple memory objects under test. Controller.setWarningValue(doublewarningValue) is used to set the warning threshold. warningValue should be less than or equal to 1.

[0116] When the preset parameters are successfully set, the interface Controller.startMemory() is provided to start the initialization and memory test. The initialization function of Controller.startMemory() will call the memory acquisition module to collect the number of memory object instances in the first no-load condition according to memoryObjects and save it in Map <string,List <long>>MemoryObjectValue. Then, according to level and times, the Mock is called to perform stress testing on the system under test. The value of level is used to determine the number of threads to be opened, and the value of times is used to determine the number of times the Mock module is called. After each call, that is, when the system under test is unloaded, the memory collection module will be called to collect the number of memory object instances when it is unloaded, and add it to the Map <string,List <long>>MemoryObjectValue.

[0117] When the times loop is completed, the memory analysis module interface is called and the value of MemoryObjectValue is passed in for analysis by the memory analysis module.

[0118] At the same time, the console module also provides a callback function Controller.memoryWarningNotify(), which is used to receive the memory warning and memory leak object information MemoryWarningInfo uploaded by the memory analysis module. This information contains four members, namely bool bWarning and the memory object name String mObject, as well as the number of memory instances in the first unloaded state long lFirstInstances and the number of memory instances in the last load long lLastInstances. The Mock module provides an interface for the console module to call and perform a stress test on the system under test. Mock.startMock() is used to perform a stress test on the system under test, call the interface provided by the system under test, and call the interface combination according to the functional flow of the system under test to simulate the normal functional flow of the system under test and provide a real test scenario. The Mock module will be called multiple times by the console module according to the test conditions and the number of tests, but the Mock module itself is not aware of it. Memory acquisition module: provides an interface.

[0119] MemoryCollect.startMemoryCollect(List <string>memoryObjects),

[0120] For Controller.startMemory() to call.

[0121] MemoryCollect.startMemoryCollect(List <string>The jmap-histo pid of jmap is called in the memoryObjects) interface to obtain the number of instances of all memory objects currently in the system.

[0122] At the same time, the number of memory object instances obtained is obtained through the method:

[0123] MemoryCollect.histoToInstanceNum(List <string>memoryObjects), according to the collection of memory object names passed in, it traverses all the memory object instances obtained, and after finding them, stores the number and name of their memory object instances in Map<string,Long> MemoryObjectValue and returns it to Controller.startMemory() for storage in its own saved Map. The memory collection module will be called multiple times by the console module according to the number of tests, but the memory collection module itself is not aware of it.

[0124] Memory analysis module, providing interface:

[0125] MemoryAnalyse.handleTheMemory(Map <string,List <long>>MemoryObject, double warningValue, int times), for the console module to call. Among them,

[0126] MemoryAnalyse.handleTheMemory(Map <string,List <long>The interface >MemoryObject, double warningValue, int times) will traverse each member in the Map. Each traversal will start a counter counter for the current member, with the initial value of counter being 0. Before that, it will traverse and calculate all the memory instance data of each member.

[0127] Specifically, compare the latter number with the former number in each group of data. If the latter number is greater than the former number, increment count by 1. After the traversal, obtain the value of count. Then compare the result of count / times with warningValue. If count / times >= warningValue, it indicates that there may be a risk of memory leakage for this memory object. If count / times < warningValue, it means there is no memory leakage. Store the memory result, the memory object name, the number of the first memory instances, and the number of the last memory instances into the structure MemoryWarningInfo.

[0128] After the Map traversal is completed, a List will be obtained. <memorywarninginfo>WarningInfo. Finally, the callback interface provided by the console module is called to report the memory test results to the console module, including the name of each memory object, whether there is a memory leak alarm, the number of memory object instances in the first unloaded state, and the number of memory object instances in the last unloaded state.

[0129] After receiving the alarm and memory leak object, the console module will obtain the List <memorywarninginfo>WarningInfo is displayed on the console interface, and the memory test is completed.

[0130] In order to implement the memory testing method on the electronic device side of the embodiment of the present application, the embodiment of the present application also provides a memory testing device, Figure 3 The structure diagram of the memory test device according to the embodiment of the present application is shown in FIG. Figure 1 ,like Figure 3 As shown, the memory testing device includes: a first acquisition module 61, used to collect memory object instances of the system to be tested in a no-load state, and obtain a first memory object instance when the system to be tested is in a no-load state; a pressurization module 62, used to perform system pressurization on the system to be tested in the no-load state, obtain a first system to be tested in a full-load state, and run the first system to be tested; a decompression module 63, used to perform system decompression on the first system to be tested in response to the running time of the first system to be tested reaching a time threshold, and obtain a second system to be tested in the no-load state; a second acquisition module 64, used to collect memory object instances of the second system to be tested, and obtain a second memory object instance when the second system to be tested is in the no-load state; a testing module 65, used to perform a memory test on the system to be tested based on the number of the first memory object instances and the number of the second memory object instances, and obtain a test result, wherein the test result is used to indicate whether there is a memory leak in the system to be tested.

[0131] In some embodiments, the above-mentioned test module 65 is also used to determine the quantity difference between the number of the first memory object instances and the number of the second memory object instances; compare the quantity difference with the difference threshold to obtain a comparison result; when the comparison result indicates that the quantity difference is greater than or equal to the difference threshold, determine the test result as the existence of the memory leak in the system to be tested; when the comparison result indicates that the quantity difference is less than the difference threshold, determine the test result as the absence of the memory leak in the system to be tested.

[0132] In some embodiments, the above-mentioned test module 65 is also used to perform at least one system pressurization and system decompression based on the second system to be tested in the no-load state to obtain at least one third system to be tested in the no-load state; respectively collect memory object instances for each of the third systems to be tested to obtain a third memory object instance when each of the third systems to be tested is in the no-load state; the above-mentioned test module 65 is also used to perform a memory test on the system to be tested based on the number of the first memory object instances, the number of the second memory object instances and the number of the third memory object instances to obtain the test result.

[0133] In some embodiments, the third system to be tested includes an i-th reference system, where i is a positive integer not less than 1 and less than N, and N is used to indicate the total number of times the second system to be tested performs the system pressurization and the system decompression; the above-mentioned test module 65 is also used to perform the system pressurization and the system decompression on the second system to be tested in the no-load state to obtain the first reference system in the no-load state; traverse i to perform the following processing: perform the system pressurization and the system decompression on the i-th reference system in the no-load state to obtain the i+1-th reference system in the no-load state.

[0134] In some embodiments, the above-mentioned test module 65 is also used to pressurize the second system to be tested in the no-load state to obtain the first candidate system in the full-load state, and run the first candidate system; in response to the running time of the first candidate system reaching a time threshold, decompress the first candidate system to obtain the first reference system in the no-load state.

[0135] In some embodiments, the above-mentioned test module 65 is also used to pressurize the system of the i+1th reference system in the no-load state to obtain the i+1th candidate system in the full-load state, and run the i+1th candidate system; in response to the running time of the i+1th candidate system reaching a time threshold, decompress the i+1th candidate system to obtain the i+1th reference system in the no-load state.

[0136] In some embodiments, the above-mentioned test module 65 is also used to perform a memory test on the system to be tested based on the number of the first memory object instances and the number of the second memory object instances to obtain a first test result; perform a memory test on the system to be tested based on the number of the second memory object instances and the number of the third memory object instances to obtain a second test result; and determine the test result based on the first test result and the second test result.

[0137] In some embodiments, the third system to be tested includes an i-th reference system, i is a positive integer not less than 1 and less than N, and N is used to indicate the total number of times the second system to be tested executes the system pressurization and the system decompression, the i-th reference system corresponds one-to-one to the third memory object instance, and the second test result includes the second test result of each i-th reference system; the above-mentioned test module 65 is also used to perform a memory test on the system to be tested based on the number of the second memory object instances and the number of the third memory object instances of the first reference system, and obtain the second test result of the first reference system; traverse i to perform the following processing: based on the number of the third memory object instances of the first reference system and the number of the third memory object instances of the i-th reference system, perform a memory test on the system to be tested, and obtain the second test result of the i-th reference system.

[0138] In some embodiments, the above-mentioned test module 65 is also used to determine the first test result as the target test result when the first test result indicates that the system to be tested has the memory leak; determine the second test result as the target test result when the second test result indicates that the system to be tested does not have the memory leak; count the number of the target test results, and when the number of the target test results is greater than the number threshold, determine the test result as the existence of the memory leak in the system to be tested; when the number of the target test results is less than or equal to the number threshold, determine the test result as the absence of the memory leak in the system to be tested.

[0139] In some embodiments, the test module 65 is further configured to repair the system to be tested to obtain a repaired system to be tested when the test result indicates that the system to be tested has a memory leak, wherein the repaired system to be tested does not have the memory leak.

[0140] It should be noted that: the memory testing device provided in the above embodiment only uses the division of the above program modules as an example when performing memory testing. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device is divided into different program modules to complete all or part of the processing described above. In addition, the memory testing device provided in the above embodiment and the memory testing method embodiment on the electronic device side belong to the same concept. The specific implementation process is detailed in the memory testing method embodiment on the electronic device side, which will not be repeated here.

[0141] Based on the hardware implementation of the above program module, and in order to implement the memory testing method on the electronic device side of the embodiment of the present application, the embodiment of the present application also provides an electronic device, Figure 4 Schematic diagram of the hardware structure of the electronic device of the embodiment of the present application. Figure 4 As shown, the electronic device 80 includes:

[0142] The first communication interface 81 is capable of exchanging information with other devices (such as the second client);

[0143] The processor 82 is connected to the first communication interface 81 to implement information interaction with other devices (such as a second client) and is used to execute the memory testing method on the electronic device side provided above when running a computer program, and the computer program is stored in the first memory 83.

[0144] Specifically, the processor 82 is used to collect memory object instances of the system to be tested in a no-load state to obtain a first memory object instance when the system to be tested is in a no-load state; pressurize the system to be tested in the no-load state to obtain a first system to be tested in a full-load state, and run the first system to be tested;

[0145] The first communication interface 81 is used to, when the running time of the first system under test reaches a time threshold, decompress the first system under test to obtain a second system under test in the no-load state; collect memory object instances of the second system under test to obtain a second memory object instance when the second system under test is in the no-load state;

[0146] The processor 82 is further configured to perform a memory test on the system to be tested based on the number of the first memory object instances and the number of the second memory object instances to obtain a test result, wherein the test result is configured to indicate whether there is a memory leak in the system to be tested.

[0147] In one embodiment, the processor 82 is further used to perform at least one system pressurization and system decompression based on the second system to be tested in the no-load state to obtain at least one third system to be tested in the no-load state; and to collect memory object instances for each of the third systems to be tested respectively to obtain third memory object instances when each of the third systems to be tested is in the no-load state; and the above-mentioned test module 65 is also used to perform memory testing on the system to be tested based on the number of the first memory object instances, the number of the second memory object instances and the number of the third memory object instances to obtain the test result.

[0148] In one embodiment, the third system to be tested includes an i-th reference system, where i is a positive integer not less than 1 and less than N, and N is used to indicate the total number of times the second system to be tested performs the system pressurization and the system decompression; the processor 82 is further used to perform the system pressurization and the system decompression on the second system to be tested in the no-load state to obtain the first reference system in the no-load state; traverse i to perform the following processing: perform the system pressurization and the system decompression on the i-th reference system in the no-load state to obtain the i+1-th reference system in the no-load state.

[0149] In one embodiment, the processor 82 is further used to pressurize the second system to be tested in the no-load state to obtain a first candidate system in a full-load state, and run the first candidate system; in response to the running time of the first candidate system reaching a time threshold, decompress the first candidate system to obtain a first reference system in the no-load state.

[0150] In one embodiment, the processor 82 is further used to pressurize the i-th reference system in the no-load state to obtain the i+1-th candidate system in the full-load state, and run the i+1-th candidate system; in response to the running time of the i+1-th candidate system reaching a time threshold, decompress the i+1-th candidate system to obtain the i+1-th reference system in the no-load state.

[0151] In one embodiment, the first communication interface 81 is specifically used to: perform a memory test on the system to be tested based on the number of the first memory object instances and the number of the second memory object instances to obtain a first test result; perform a memory test on the system to be tested based on the number of the second memory object instances and the number of the third memory object instances to obtain a second test result; and determine the test result based on the first test result and the second test result.

[0152] In one embodiment, the third system to be tested includes an i-th reference system, i is a positive integer not less than 1 and less than N, and N is used to indicate the total number of times the second system to be tested executes the system pressurization and the system decompression, the i-th reference system corresponds one-to-one to the third memory object instance, and the second test result includes the second test result of each i-th reference system; the first communication interface 81 is specifically used to: perform a memory test on the system to be tested based on the number of the second memory object instances and the number of the third memory object instances of the first reference system, and obtain the second test result of the first reference system; traverse i to perform the following processing: perform a memory test on the system to be tested based on the number of the third memory object instances of the first reference system and the number of the third memory object instances of the i-th reference system, and obtain the second test result of the i-th reference system.

[0153] In one embodiment, the first communication interface 81 is specifically used to: when the first test result indicates that the system to be tested has the memory leak, determine the first test result as the target test result; when the second test result indicates that the system to be tested does not have the memory leak, determine the second test result as the target test result; count the number of the target test results, and when the number of the target test results is greater than a number threshold, determine the test result as the existence of the memory leak in the system to be tested; when the number of the target test results is less than or equal to the number threshold, determine the test result as the absence of the memory leak in the system to be tested.

[0154] In one embodiment, the first communication interface 81 is specifically used to: when the test result indicates that the system under test has a memory leak, repair the system under test to obtain a repaired system under test, wherein the repaired system under test does not have the memory leak.

[0155] It should be noted that the specific processing process of the first communication interface 81 and the processor 82 can be understood by referring to the memory testing method on the electronic device side.

[0156] Of course, in actual application, the various components in the electronic device 80 are coupled together through the first bus system 84. It is understandable that the first bus system 84 is used to realize the connection and communication between these components. In addition to the data bus, the first bus system 84 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 4 In the figure, various buses are labeled as a first bus system 84 .

[0157] The first memory 83 in the embodiment of the present application is used to store various types of data to support the operation of the electronic device 80. Examples of such data include: any computer program used to operate on the electronic device 80.

[0158] The memory test method on the electronic device side disclosed in the above embodiment of the present application can be applied to the processor 82, or implemented by the processor 82. The processor 82 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the memory test method on the electronic device side can be completed by the hardware integrated logic circuit or software instructions in the processor 82. The above-mentioned processor 82 may be a general processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor 82 can implement or execute the memory test methods, steps and logic block diagrams on the electronic device side disclosed in the embodiment of the present application. A general processor may be a microprocessor or any conventional processor, etc. In combination with the steps of the memory test method on the electronic device side disclosed in the embodiment of the present application, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium, which is located in the first memory 83. The processor 82 reads the information in the first memory 83 and completes the steps of the memory test method on the electronic device side in combination with its hardware.

[0159] In an exemplary embodiment, the electronic device 80 can be implemented by one or more application specific integrated circuits (ASIC), DSP, programmable logic device (PLD), complex programmable logic device (CPLD), field programmable gate array (FPGA), general processor, controller, microcontroller (MCU), microprocessor, or other electronic components to execute the aforementioned memory testing method on the electronic device side.

[0160] It can be understood that the memory (including the first memory 83) of the embodiment of the present application can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); the magnetic surface memory can be a disk memory or a tape memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM, SyncLink Dynamic Random Access Memory), and direct RAMbus random access memory (DRRAM, Direct Rambus Random Access Memory).The memories (including the first memory 83) described in the embodiments of the present application are intended to include but are not limited to these and any other suitable types of memories.

[0161] In an exemplary embodiment, the present application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, for example, including a first memory 83 storing a computer program, and the computer program can be executed by a processor 82 in an electronic device 80. The computer-readable storage medium can be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface storage, optical disk, or CD-ROM.

[0162] It should be noted that "first", "second", "third", etc. are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0163] In addition, the technical solutions described in the embodiments of the present application can be combined arbitrarily without conflict.

[0164] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.< / memorywarninginfo> < / memorywarninginfo> < / long> < / long> < / string> < / string> < / string> < / long> < / long> < / string>

Claims

1. A memory testing method, characterized in that: The method comprises: Collecting memory object instances of the system to be tested in a no-load state to obtain a first memory object instance when the system to be tested is in a no-load state; Pressurizing the system to be tested in the no-load state to obtain a first system to be tested in a fully loaded state, and running the first system to be tested; In response to the running time of the first system to be tested reaching a time threshold, decompressing the first system to be tested to obtain a second system to be tested in the no-load state; Collecting memory object instances of the second system to be tested to obtain a second memory object instance when the second system to be tested is in the no-load state; Based on the number of the first memory object instances and the number of the second memory object instances, a memory test is performed on the system to be tested to obtain a test result, where the test result is used to indicate whether there is a memory leak in the system to be tested.

2. The method according to claim 1, characterized in that The performing a memory test on the system to be tested based on the number of the first memory object instances and the number of the second memory object instances to obtain a test result includes: Determine a difference in quantity between the quantity of the first memory object instances and the quantity of the second memory object instances; Compare the quantity difference with a difference threshold to obtain a comparison result; When the comparison result indicates that the quantity difference is greater than or equal to the difference threshold, determining the test result as the existence of the memory leak in the system to be tested; When the comparison result indicates that the quantity difference is less than the difference threshold, the test result is determined as that the system to be tested does not have the memory leak.

3. The method according to claim 1, characterized in that After decompressing the first system to be tested to obtain the second system to be tested in the no-load state, the method further includes: Based on the second system to be tested in the no-load state, performing at least one system pressurization and system depressurization to obtain at least one third system to be tested in the no-load state; Collecting memory object instances for each of the third systems to be tested respectively, and obtaining third memory object instances when each of the third systems to be tested is in the no-load state; The performing a memory test on the system to be tested based on the number of the first memory object instances and the number of the second memory object instances to obtain a test result includes: Based on the number of the first memory object instances, the number of the second memory object instances, and the number of the third memory object instances, a memory test is performed on the system to be tested to obtain the test result.

4. The method according to claim 3, characterized in that The third system to be tested includes an i-th reference system, i is a positive integer not less than 1 and less than N, and N is used to indicate the total number of times the second system to be tested performs the system pressurization and the system depressurization; The method of pressurizing and depressurizing the system at least once based on the second system to be tested in the no-load state to obtain at least one third system to be tested in the no-load state comprises: Performing system pressurization and system depressurization on the second system to be tested in the no-load state to obtain a first reference system in the no-load state; Traverse i and perform the following processing: The system is pressurized and the system is depressurized for the i-th reference system in the no-load state to obtain an (i+1)-th reference system in the no-load state.

5. The method according to claim 4, characterized in that The step of pressurizing and depressurizing the second system to be tested in the no-load state to obtain a first reference system in the no-load state comprises: Pressurizing the second system to be tested in the no-load state to obtain a first candidate system in a fully loaded state, and operating the first candidate system; In response to the running time of the first candidate system reaching a time threshold, the first candidate system is decompressed to obtain a first reference system in the no-load state.

6. The method according to claim 4, characterized in that The step of pressurizing and depressurizing the i-th reference system in the no-load state to obtain the i+1-th reference system in the no-load state includes: Pressurizing the i-th reference system in the no-load state to obtain the i+1-th candidate system in the full-load state, and operating the i+1-th candidate system; In response to the operating time of the i+1th candidate system reaching a time threshold, the i+1th candidate system is decompressed to obtain the i+1th reference system in the no-load state.

7. The method according to claim 3, characterized in that The performing a memory test on the system to be tested based on the number of the first memory object instances, the number of the second memory object instances, and the number of the third memory object instances to obtain the test result includes: Based on the number of the first memory object instances and the number of the second memory object instances, performing a memory test on the system to be tested to obtain a first test result; Based on the number of the second memory object instances and the number of the third memory object instances, performing a memory test on the system to be tested to obtain a second test result; The test result is determined based on the first test result and the second test result.

8. The method according to claim 7, characterized in that The third system to be tested includes an i-th reference system, i is a positive integer not less than 1 and less than N, and N is used to indicate the total number of times the second system to be tested executes the system pressurization and the system decompression, the i-th reference system corresponds one-to-one to the third memory object instance, and the second test result includes the second test result of each of the i-th reference systems; The performing a memory test on the system to be tested based on the number of the second memory object instances and the number of the third memory object instances to obtain a second test result includes: Based on the number of the second memory object instances and the number of the third memory object instances of the first reference system, performing a memory test on the system to be tested to obtain a second test result of the first reference system; Traverse i and perform the following processing: Based on the number of the third memory object instances of the first reference system and the number of the third memory object instances of the i-th reference system, a memory test is performed on the system to be tested to obtain a second test result of the i-th reference system.

9. The method according to claim 7, characterized in that: The determining the test result based on the first test result and the second test result includes: When the first test result indicates that the system to be tested has the memory leak, determining the first test result as a target test result; When the second test result indicates that the system to be tested does not have the memory leak, determining the second test result as a target test result; Counting the number of the target test results, and when the number of the target test results is greater than a number threshold, determining the test result as indicating that the system to be tested has a memory leak; When the number of the target test results is less than or equal to the number threshold, the test result is determined as the memory leak does not exist in the system to be tested.

10. The method according to claim 1, characterized in that After performing a memory test on the system to be tested based on the number of the first memory object instances and the number of the second memory object instances and obtaining a test result, the method further includes: When the test result indicates that the system to be tested has a memory leak, the system to be tested is repaired to obtain a repaired system to be tested, and the repaired system to be tested does not have the memory leak.

11. A memory testing device, characterized in that: include: A first acquisition module, used for acquiring memory object instances of the system to be tested in a no-load state, to obtain a first memory object instance when the system to be tested is in a no-load state; A pressurizing module, used for pressurizing the system to be tested in the no-load state to obtain a first system to be tested in a fully loaded state, and running the first system to be tested; a decompression module, configured to, in response to the running time of the first system to be tested reaching a time threshold, decompress the first system to be tested to obtain a second system to be tested in the no-load state; A second collection module, used for collecting memory object instances of the second system to be tested, and obtaining a second memory object instance when the second system to be tested is in the no-load state; The test module is used to perform a memory test on the system to be tested based on the number of the first memory object instances and the number of the second memory object instances to obtain a test result, wherein the test result is used to indicate whether there is a memory leak in the system to be tested.

12. An electronic device, characterized in that: include: a processor and a first memory for storing a computer program executable on said processor; Wherein, when the processor is used to run the computer program, it executes the steps of the method described in any one of claims 1 to 10.

13. 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 10 are implemented.

Images