A self-detection method for script performance testing

Abstract

The present invention relates to the technical field of computer performance testing, and discloses a self-detection method for script performance testing, comprising: obtaining performance test parameters and asset server parameters of a device under test; configuring operation instructions for the asset server in the performance test parameters; running a script performance test file; causing a monitoring module and a package sending module on a performance test press to interact by running the script performance test file, and obtaining the interaction results between the monitoring module and the package sending module; calculating the resources consumed by the package sending module, and configuring and adding resources to the performance test press based on the total resource consumption of users; and recording the resource consumption of the performance test press. The present invention is used for a performance test press, so that the performance test press no longer needs to understand its own performance level in advance, directly simplifying the tester's workflow and the complexity of performance testing, improving the utilization rate of the performance test press, and lowering the threshold for performance testing.

Description

Technical Field

[0001] The present invention relates to the technical field of computer performance testing, and more specifically, to a self-detection method for script performance testing, which is used for a performance testing press, so that the performance testing press no longer needs to know its own performance level in advance, directly simplifies the tester's workflow and the complexity of performance testing, improves the utilization rate of the performance testing press, and lowers the threshold for performance testing. Background Art

[0002] The goal of any test is to generate valid data. In performance testing, to determine the capabilities of the target machine, the first step is to understand the simulation capabilities of the performance tester. The more clearly understood the performance tester's capabilities, the more accurate the data generated. Testers need to thoroughly investigate the performance tester. In large-scale performance testing, this thorough investigation is equivalent to conducting a performance test of the performance tester, which incurs additional workload. Sometimes, multiple scenarios are investigated. The entire performance tester performance investigation is no less complex than a single large-scale target machine performance test. This is why, after the performance tester investigation, companies generally solidify the hardware model of the performance tester. No matter how many scenarios are investigated, they are always limited. In relatively variable scenarios, the performance tester load is mostly estimated based on the tester's experience, which raises the performance tester's skill threshold. The tester's estimation method cannot effectively utilize the performance tester's capabilities. During the performance testing process, testers also need to continuously monitor the performance tester's resources to ensure its normal operation. In large-scale performance stress tests, dedicated performance testers will be assigned to complete this task. In addition, a common method also includes managing multiple performance test stressors on the server side. The performance test stressors return the test data to the server side, and the server side dynamically manages the number of performance test stressors. However, this method still requires knowing the preliminary performance data of the performance test stressors. For example, one performance test stressor simulates 1,000 users. If 5,000 users are online, the server side will open 5 performance test stressors A. If 2,000 users are online, the server side will close 3 performance test stressors.

[0003] Therefore, in order to solve the above problems, there is an urgent need for a self-detection process for the testing capability of a performance testing press, which can be used for the performance testing press, so that the performance testing press no longer needs to understand its own performance level in advance, directly simplifying the tester's workflow and the complexity of performance testing, thereby improving the utilization rate of the performance testing press and lowering the threshold for performance testing. Summary of the Invention

[0004] The purpose of the present invention is to provide a self-detection method for script performance testing, which is used for a performance testing press, so that the performance testing press no longer needs to know its own performance level in advance, directly simplifies the tester's workflow and the complexity of performance testing, improves the utilization rate of the performance testing press, and lowers the performance testing threshold.

[0005] The present invention is implemented by the following technical solution: a self-detection method for script performance testing, comprising the following steps:

[0006] Step S1. Obtain the performance test parameters and asset server parameters of the device under test, and configure the performance test parameters and asset server parameters on the performance test press;

[0007] Step S2. Configuring the operating instructions for the asset server in the performance test parameters; Step S3. Preset the script performance test file and run the script performance test file by reading the performance test parameters and the asset server parameters;

[0008] Step S4. By running the script performance test file, the monitoring module and the contract issuing module of the performance test press end interact to obtain the interaction results between the monitoring module and the contract issuing module;

[0009] Step S5. The performance test press calculates the resources consumed by the contract issuing module according to the interaction results, simulates the resource consumption of the total number of users based on the consumed resources, and configures and adds resources to the performance test press according to the resource consumption of the total number of users;

[0010] Step S6. The simulated user on the performance test press uses the device under test to operate the asset server through operation instructions, and the script performance test file records the resource consumption of the performance test press.

[0011] In this technical solution, testers need to conduct a thorough investigation of the performance test stressor. In large-scale performance testing, the thorough investigation is equivalent to doing a performance test of the performance test stressor, which will bring additional workload. Sometimes, performance investigations of performance test stressors in multiple scenarios will be conducted. The performance investigation of the entire performance test stressor is no less than a large-scale target machine performance test. This is why after the performance test stressor is investigated, general companies will solidify the hardware model of the performance test stressor. No matter how many scenarios are investigated, there are always a limited number of scenarios. In some relatively changing scenarios, most of the estimation of the performance test stressor load depends on the experience of testers, which increases the ability threshold of performance testers. The tester's estimation method cannot achieve effective utilization of the performance test stressor's capabilities. During the performance testing process, testers also need to continuously monitor the performance test stressor resource issues to ensure the normal operation of the performance test stressor. In large-scale performance stress testing, there will be dedicated performance testers to complete the performance test.

[0012] This technical solution provides a self-detection process for the testing capabilities of a performance tester, eliminating the need for the tester to know its own performance level in advance. By leveraging inter-process communication (IPC) and measuring message return times to determine the performance load of a single Python process, it automatically launches multiple dispatching programs (processes) to bypass the Python GIL. By separating the monitoring program from the dispatching program, the overall architecture bypasses the Python GIL and adapts to diverse performance testing scenarios.

[0013] In order to better implement the present invention, further, the performance test parameters in step S1 include:

[0014] The number of initiation threads, the pre-prepared performance test press IP address pool, the number of initiations each time, the initiation interval, the network address IP of the device under test, the protocol proxy port, the account number of the operation and maintenance asset, and the pre-prepared performance test press IP.

[0015] This technical solution configures the parameters of the performance test script file on the performance test press in order to be able to run the simulation program of the performance test script file.

[0016] In order to better implement the present invention, further, the asset server parameters in step S1 include:

[0017] The IP address, account, password, and port of the operation and maintenance asset.

[0018] This technical solution configures the parameters of the asset server on the performance test press in order to be able to run the simulation program of the performance test script file.

[0019] In order to better implement the present invention, further, step S3 includes:

[0020] Step S2.1. Enter the script performance test file name;

[0021] Step S2.2. Add parameters and configuration files after the script performance test file name;

[0022] Step S2.3 reads the additional parameters to determine the protocol name of the user to be simulated;

[0023] Step S2.4. Read the configuration file to obtain the performance test parameters of the device under test and the asset server parameters.

[0024] In this technical solution, the technician enters the script performance test file name through the Linux command terminal, adds the -P parameter followed by the protocol name of the user to be simulated, adds the config parameter, followed by the configuration file name, and presses Enter to start the script performance test file (program). The script performance test file (program) will first read the parameters after -p and then know what kind of protocol user needs to be simulated, and then read the data in the configuration file line by line. According to the parameters in the configuration file, the basic information of the device under test (IP and login account, etc.) and the basic information of the number of simulated protocol users, as well as the basic information of the operation and maintenance assets that the simulated protocol users need to connect to are determined.

[0025] In order to better implement the present invention, further, step S4 includes:

[0026] Step S4.1. The monitoring module interacts with the sending module to determine whether the user is abnormal by simulating the user's return information. When the sending module receives the return message, it notifies the monitoring module. If the monitoring module receives this message within the timer time, it resets the timer and determines that the user is normal. If the monitoring module does not receive this message, it determines that the user is abnormal and sends the abnormal user ID and the total number of simulated users at this time to the abnormal monitoring module submodule of the monitoring module;

[0027] Step S4.2. The abnormal monitoring module monitors and counts the abnormal user ID and the total number of simulated users at this time, obtains abnormal information, and sends the abnormal information to the abnormal user processing module submodule of the monitoring module;

[0028] Step S4.3. After receiving the abnormal user processing module, the sending module is notified to stop simulating the user online and clear the abnormal user according to the exception handling rules until the sending module receives the action of stopping the simulated user online and clearing the abnormal user;

[0029] Step S4.4. After the packet sending module starts to stop simulating users to go online and clear abnormal users, it informs the monitoring module of the current actual number of remaining threads;

[0030] Step S4.5. Record and obtain the above information.

[0031] In this technical solution, a packet-issuing program simulates user interaction with the device under test. When the simulated user and the device under test interact normally, the monitoring module is informed of the user's ID, and the monitoring program starts a timer for it (command interval + baseline value, which defaults to 100ms; network latency in intranet testing is generally less than 1ms). Each time the packet-issuing module sends a command (a packet-issuing module represents a thread, representing a simulated user), the device under test generally returns a result immediately. Upon receiving this response, the packet-issuing module immediately notifies the monitoring module. If the monitoring module receives this response within the timer, the timer is reset. If not, the monitoring module sends the abnormal user's ID and the total number of simulated users to the abnormality monitoring module.

[0032] The abnormal user monitoring module monitors and counts abnormal users. When an abnormal user ID is received, the total number of abnormal users is incremented by 1, the user ID is recorded, and the abnormal user ratio (the ratio of the total number of abnormal users to the total number of currently online users) is calculated. This ratio is compared with the abnormal user threshold. If the abnormal user threshold is not exceeded, the case is not processed. If the abnormal user threshold is exceeded, the abnormal user ID and the total number of simulated users are sent to the abnormal user processing module. The abnormal user processing module instructs the monitoring module to immediately notify the packet sending module to stop simulating users online and, based on the current load, to begin removing abnormal users. Upon receiving a response from the packet sending module indicating that the actions of stopping simulated users online and removing abnormal users have been initiated, the packet sending module begins stopping simulated users online and removing abnormal users, and then informs the monitoring module of the current number of remaining threads. The waiting recovery processing module instructs the packet sending module to kill excess simulated user threads according to the instructions sent by the monitoring module, and then informs the monitoring module of the current number of remaining threads. These threads represent normal communicating users.

[0033] In order to better implement the present invention, further, the exception handling rules in step S4.3 include:

[0034] The abnormal user processing module starts to remove abnormal online users according to the current load situation and removes abnormal users in descending order of abnormal user IDs.

[0035] In this technical solution, the monitoring module will immediately notify the package sending module to stop simulating user online. The abnormal online user ID will be recorded when the package sending program simulates the interaction between the user and the device under test. The online user ID number is automatically incremented (1, 2, 3, 4, 5, 6, 7...). When clearing abnormal users, they are cleared in descending order of their abnormal user IDs, with the largest ID number being cleared first. The monitoring module will immediately notify the package sending module to stop simulating user online.

[0036] In order to better implement the present invention, further, step S5 includes:

[0037] The performance test press is configured with resources based on the total resource consumption of users. Based on the resource consumption, it is determined whether a new performance test press needs to be deployed, and the simulated user is automatically put online.

[0038] In this technical solution, after the packet sending module kills the redundant simulated user threads according to the instructions sent by the monitoring module, it informs the monitoring module of the current actual number of remaining threads. These threads are all users communicating normally. Based on the number of threads, it is determined whether a new performance test stressor needs to be deployed, and the simulated user is automatically put online.

[0039] In order to better implement the present invention, step S5 further includes:

[0040] A performance test press is added according to the pre-prepared performance test press IP address pool.

[0041] In this technical solution, the various resources consumed by the packet sending module are calculated, mainly including CPU memory usage. The SFTP protocol simulation user will involve network traffic. These resource records are the resource consumption of the total number of simulated users of the current packet sending module.

[0042] In order to better implement the present invention, further, step S6 includes:

[0043] The number of online users is determined based on the number of initiating threads, and the simulated users on the performance test press are configured based on the number of online users.

[0044] In this technical solution, if the core number of the current performance test stressor does not meet the requirements for completing this performance test, if it is a single-machine test, the tester will be notified of how many users have not yet come online, and the tester will manually deploy a new performance test stressor. If there is a performance test stressor B to be used in this performance test stressor, the tester will inform another automatically deployed machine, and that machine will deploy the relevant stress test script on the performance test stressor B, and then automatically simulate the remaining 100 protocol users to go online. There are many ways to log in as a protocol user, such as logging in through ssh, telnet rdp rlogin sftp. The ssh protocol user means that the user logs in through the ssh protocol to operate. The windows remote login we often use is logged in through the rdp protocol.

[0045] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0046] (1) The technical solution provided by the present invention simplifies the workflow of testers, reduces the complexity of performance testing, and improves the utilization rate of performance testing presses;

[0047] (2) In the present invention, testers do not need to thoroughly understand the performance of the performance test press, nor do they need to fix the performance test press model. In addition, they can better utilize the performance test press resources in different scenarios, saving testing costs.

[0048] (3) The present invention lowers the technical threshold for testers, and can complete the test tasks without full-time performance testers (the program can automatically monitor local resources, and there is no need to conduct a thorough investigation of the performance test press, which greatly reduces the work tasks of testers, and there is no need to fix the performance test press model, further saving various hardware expenses and labor costs. For example, in external bidding tests, there is no need for full-time performance testers to be present for testing, nor is there a need to use a special performance test press, and accurate data can be obtained. The program can automatically detect the performance test press resources and maximize the use of the various hardware resources of the performance test press, because manual estimation cannot ultimately achieve the maximum utilization of resources, and no matter how much experience there is, it is not as accurate as computer monitoring. It is not limited to limited performance scenarios, and can obtain more accurate test data based on the customer's actual application scenario. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The present invention is further described in conjunction with the following drawings and embodiments, and all concepts and innovations of the present invention should be regarded as disclosed contents and the protection scope of the present invention.

[0050] Figure 1 This is a flow chart of a self-detection method for script performance testing provided by the present invention. DETAILED DESCRIPTION

[0051] Example 1:

[0052] A self-detection method for script performance testing in this embodiment, such as Figure 1 As shown, including:

[0053] Step S1. Obtain the performance test parameters and asset server parameters of the device under test, and configure the performance test parameters and asset server parameters on the performance test press;

[0054] Step S2. Configuring the operation instructions for the asset server in the performance test parameters;

[0055] Step S3. Preset the script performance test file and run the script performance test file by reading the performance test parameters and asset server parameters;

[0056] Step S4. By running the script performance test file, the monitoring module and the contract issuing module of the performance test press end interact to obtain the interaction results between the monitoring module and the contract issuing module;

[0057] Step S5. The performance test press calculates the resources consumed by the contract issuing module according to the interaction results, simulates the resource consumption of the total number of users based on the consumed resources, and configures and adds resources to the performance test press according to the resource consumption of the total number of users;

[0058] Step S6. The simulated user on the performance test press uses the device under test to operate the asset server through operation instructions, and the script performance test file records the resource consumption of the performance test press.

[0059] In this embodiment, the current performance test press still needs to know the preliminary performance data of the performance test press, such as 1 performance test press simulates 1000 users, and 5000 users are online. Server B will open 5 performance test presses A, and 2000 users are online, and server B will close 3 performance test presses A. In the general performance test process, the tester must first find out the performance test press capability and understand how many users the performance test press A can simulate at most. For example, performance test press A can simulate 100 ssh users, sending instructions every 10s, and 50 RDP users, operating every 10s, and then form a performance test press data table. In the future, performance testing is carried out, and the performance test press is unified as much as possible. In this way, there is no need to conduct a performance test on the performance test press each time the test is carried out, and relevant performance data can also be obtained. However, in the present invention, the tester does not need to conduct a performance test on the performance of the performance test press, nor does it need to fix the performance test press model, and can better utilize the performance test press resources in different scenarios, saving testing costs.

[0060] This embodiment provides a self-detection process for the testing capabilities of a performance testing machine, eliminating the need for the machine to know its own performance level in advance. By leveraging inter-process communication and message return duration to determine the performance load of a single Python process, the system automatically launches multiple packet-issuing programs (processes) to bypass the Python GIL. By separating the monitoring program from the packet-issuing program, the overall architecture bypasses the Python GIL and adapts to various performance testing scenarios.

[0061] Example 2:

[0062] This embodiment is further optimized based on the embodiment 1, and the parameters of the performance test script file are configured on the performance test press in order to be able to run the simulation program of the performance test script file.

[0063] The rest of this embodiment is the same as that of embodiment 1, so it will not be described again.

[0064] Example 3:

[0065] This embodiment is further optimized based on the first embodiment, and the parameters of the asset server are configured on the performance test press in order to be able to run the simulation program of the performance test script file.

[0066] The rest of this embodiment is the same as that of embodiment 1, so it will not be described again.

[0067] Example 4:

[0068] This embodiment is further optimized based on embodiment 1. The technician enters the script performance test file name through the Linux command terminal, adds the -P parameter followed by the protocol name of the user to be simulated, adds the config parameter, followed by the configuration file name, and presses Enter to start the script performance test file (program). The script performance test file (program) will first read the parameters after -p and then know what kind of protocol user needs to be simulated, and then read the data in the configuration file line by line. According to the parameters in the configuration file, the basic information of the device under test (IP and login account, etc.), the basic information of the number of simulated protocol users, and the basic information of the operation and maintenance assets that the simulated protocol users need to connect to are determined.

[0069] The rest of this embodiment is the same as that of embodiment 1, so it will not be described again.

[0070] Example 5:

[0071] This embodiment further optimizes any of the above embodiments 1-4. The packet sending program simulates the interaction between the user and the device under test. When the simulated user and the device under test interact normally, the user ID is notified to the monitoring module, and the monitoring program starts a timer for it (command time interval + reference value, the reference value defaults to 100ms, and the network delay in intranet testing is generally less than 1ms). Each time the packet sending module (a packet sending module represents a thread, representing a simulated user) sends a command, the device under test generally returns a result immediately. The packet sending module immediately notifies the monitoring module upon receiving the returned message. If the monitoring module receives this message within the timer period, the timer is reset. If not, the ID of the abnormal user and the total number of users currently simulated are sent to the abnormal monitoring module.

[0072] The abnormal user monitoring module monitors and counts abnormal users. When an abnormal user ID is received, the total number of abnormal users is incremented by 1, the user ID is recorded, and the abnormal user ratio (the ratio of the total number of abnormal users to the total number of currently online users) is calculated. This ratio is compared with the abnormal user threshold. If the abnormal user threshold is not exceeded, the case is not processed. If the abnormal user threshold is exceeded, the abnormal user ID and the total number of simulated users are sent to the abnormal user processing module. The abnormal user processing module instructs the monitoring module to immediately notify the packet sending module to stop simulating users online and, based on the current load, to begin removing abnormal users. Upon receiving a response from the packet sending module indicating that the actions of stopping simulated users online and removing abnormal users have been initiated, the packet sending module begins stopping simulated users online and removing abnormal users, and then informs the monitoring module of the current number of remaining threads. The waiting recovery processing module instructs the packet sending module to kill excess simulated user threads according to the instructions sent by the monitoring module, and then informs the monitoring module of the current number of remaining threads. These threads represent normal communicating users.

[0073] In this embodiment, the information recorded represents the completion of a single-server performance load test. If the single server can handle the performance test, the entire test is recorded. If it can only handle half of the test, only half of the test is recorded. The final number of users online on a single core, the total number of simulated users, and the resource usage of these simulated users on the host are obtained. This information is primarily used for test report generation, subsequent performance script tuning, configuration optimization, and general data collection.

[0074] The rest of this embodiment is the same as any of the above embodiments 1-4, so it will not be repeated here.

[0075] Example 6:

[0076] This embodiment is further optimized on the basis of embodiment 5. The current load condition in this embodiment includes the consumption of CPU internal training. Generally, a machine needs to maintain system stability, and the CPU consumption reaches up to 80%, which is considered to be fully loaded. In this embodiment, the monitoring module will immediately notify the packet sending module to stop simulating users to go online. The abnormal online user ID will start recording when the packet sending program simulates the interaction between the user and the tested device. The online user ID number is automatically incremented (1, 2, 3, 4, 5, 6, 7...). When clearing abnormal users, they will be cleared in descending order of their abnormal user IDs, with the largest ID number being cleared first. The monitoring module will immediately notify the packet sending module to stop simulating users to go online.

[0077] The rest of this embodiment is the same as that of Embodiment 5, so they will not be described in detail.

[0078] Example 7:

[0079] This embodiment is further optimized based on any one of Embodiments 1-6. After the packet sending module kills the redundant simulated user threads according to the instructions sent by the monitoring module, it informs the monitoring module of the current actual number of remaining threads. These threads are all users communicating normally. Based on the number of threads, it is determined whether a new performance test stressor needs to be deployed, and the simulated user is automatically put online.

[0080] The rest of this embodiment is the same as any of the above embodiments 1-6, so it will not be repeated here.

[0081] Example 8:

[0082] This embodiment further optimizes any one of Embodiments 1-7 and calculates the various resources consumed by the packet sending module, mainly including CPU memory usage. The SFTP protocol simulated user will involve network traffic. These resource records are the resource consumption of the total number of simulated users of the current packet sending module.

[0083] For example, in the current scenario, we can simulate 100 SSH protocol users coming online with a 10-second interval. With a single-core CPU utilization of 80% and memory usage of 10%, the simulation needs to simulate 300 SSH protocol users, requiring two additional cores to meet the performance simulation requirements. Therefore, the number of CPU cores required for this simulation is (4 = 3 packet sending programs + 1 monitoring program). At the beginning of the performance simulation, the program has already obtained basic information about the performance tester (the number of cores, memory size, and network bandwidth). If the current performance tester only has three cores, the monitoring program will know that the performance tester can only simulate 200 SSH users. Subsequently, it will only simulate users within the performance tester's capabilities. The remaining 100 protocol users will be notified to the tester. Automatic notification can be sent to testers through an internal email interface. In our case, this interface is used by Alibaba DingTalk. Automatic notification can also be configured to automatically send messages to relevant testers.

[0084] The rest of this embodiment is the same as any of the above embodiments 1-7, so it will not be repeated here.

[0085] Example 9:

[0086] This embodiment is further optimized based on any one of Embodiments 1-8. If the core number of the current performance test stressor does not meet the requirements for completing this performance test, if it is a stand-alone test, the tester will be notified of how many users are not online, and the tester will manually deploy a new performance test stressor. If there is a performance test stressor B to be used in this performance test stressor, the tester will inform another automatically deployed machine, and that machine will deploy the relevant stress test script on performance test stressor B, and then automatically simulate the remaining 100 protocol users to go online. There are many ways to log in as a protocol user, such as logging in through ssh, telnet rdp rlogin sftp. The ssh protocol user means that the user logs in through the ssh protocol to perform operations. The windows remote login we often use is performed through the rdp protocol.

[0087] The rest of this embodiment is the same as any of the above embodiments 1-8, so it will not be repeated here.

[0088] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any form. Any simple modification or equivalent change made to the above embodiment based on the technical essence of the present invention falls within the scope of protection of the present invention.

Claims

1. A self-detection method for script performance testing, characterized in that: The following steps are involved: Step S1. Obtain the performance test parameters and asset server parameters of the device under test, and configure the performance test parameters and asset server parameters on the performance test press; The performance test parameters in step S1 include: the number of initiation threads, the pre-prepared performance test press IP address pool, the number of initiations per time, the initiation interval, the network address IP of the device under test, the protocol proxy port, the account number of the operation and maintenance asset, and the pre-prepared performance test press IP; The asset server parameters in step S1 include: the IP address of the operation and maintenance asset, the account number of the operation and maintenance asset, the password of the operation and maintenance asset, and the port number of the operation and maintenance asset; Step S2. Configuring the operation instructions for the asset server in the performance test parameters; Step S3. Preset the script performance test file and run the script performance test file by reading the performance test parameters and asset server parameters; Step S4. By running the script performance test file, the monitoring module and the contract issuing module of the performance test press end interact to obtain the interaction results between the monitoring module and the contract issuing module; Step S5. The performance test press calculates the resources consumed by the packet sending module according to the interaction results, and simulates the total resource consumption of the user according to the consumed resources; Allocate resources for performance test machines based on the total resource consumption of users; determine whether to deploy new performance test machines based on resource consumption and automatically bring them online to simulate users; and add new performance test machines based on the pre-prepared performance test machine IP address pool. Step S6. The simulated user on the performance test press uses the device under test to operate the asset server through operation instructions, and the script performance test file records the resource consumption of the performance test press.

2. A self-detection method for script performance testing according to claim 1, characterized in that: The step S3 comprises: Step S2.

1. Enter the script performance test file name; Step S2.

2. Add parameters and configuration files after the script performance test file name; Step S2.

3. Read the additional parameters to determine the protocol name of the user to be simulated; Step S2.

4. Read the configuration file to obtain the performance test parameters of the device under test and the asset server parameters.

3. A self-detection method for script performance testing according to claim 1, characterized in that: The step S4 comprises: Step S4.

1. The monitoring module interacts with the sending module to determine whether the user is abnormal by simulating the user's return information. When the sending module receives the return message, it notifies the monitoring module. If the monitoring module receives this message within the timer time, it resets the timer and determines that the user is normal. If the monitoring module does not receive this message, it determines that the user is abnormal and sends the abnormal user ID and the total number of simulated users at this time to the abnormal monitoring module submodule of the monitoring module; Step S4.

2. The abnormal monitoring module monitors and counts the abnormal user ID and the total number of simulated users at this time, obtains abnormal information, and sends the abnormal information to the abnormal user processing module submodule of the monitoring module; Step S4.

3. After receiving the abnormal user processing module, the sending module is notified to stop simulating the user online and clear the abnormal user according to the exception handling rules until the sending module receives the action of stopping the simulated user online and clearing the abnormal user; Step S4.

4. After the packet sending module starts to stop simulating users to go online and clear abnormal users, it informs the monitoring module of the current actual number of remaining threads; Step S4.

5. Obtain the interaction results between the monitoring module and the packet sending module.

4. A self-detection method for script performance testing according to claim 3, characterized in that: The exception handling rules in step S4.3 include: the abnormal user processing module starts to remove abnormal online users according to the current load situation, and removes abnormal users in descending order of abnormal user IDs.

5. A self-detection method for script performance testing according to any one of claims 1 to 4, characterized in that: The step S6 includes: confirming the number of online users according to the number of initiated threads, and configuring simulated users on the performance test press according to the number of online users.

Images