Abnormality detection method, device and computer equipment in performance test

Abstract

The application relates to an exception detection method and device in performance testing, a computer device, a storage medium and a computer program product. By sending a test message to a target execution device in a business system, the target execution device is instructed to obtain a test script based on a test identifier and start target performance testing. In the target performance testing, the running state information at the current time point is compared with the running state prediction information at the corresponding time point predicted based on a target long short-term memory model. If the comparison result represents that the running state information at the current time point is abnormal running state information, the corresponding running snapshot of the target execution device is collected and saved. Compared with the traditional method of determining whether retesting is needed for the exception after one stress test, the present application trains the target long short-term memory model to timely detect the abnormality of the test state at the corresponding time point when the target execution device executes the test, timely capture the corresponding running snapshot, and improve the efficiency of the exception detection.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to an anomaly detection method, apparatus, computer equipment, storage medium, and computer program product in performance testing. Background Technology

[0002] During the development of a business system, performance testing of its code is necessary. During performance testing, the system's performance may not meet expectations. In such cases, it's crucial to monitor and collect runtime information from the system during performance testing to analyze and improve performance anomalies. Currently, anomaly detection in performance testing typically involves performance testers conducting stress tests based on developer requirements, followed by the developers determining whether further anomaly detection is needed based on the stress test results. However, this method of stress testing first and then determining whether to repeat the testing based on the results leads to decreased efficiency in anomaly detection.

[0003] Therefore, current anomaly detection methods in performance testing suffer from low detection efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide an anomaly detection method, apparatus, computer equipment, computer-readable storage medium, and computer program product in performance testing that can improve detection efficiency in response to the above-mentioned technical problems.

[0005] Firstly, this application provides an anomaly detection method in performance testing, the method comprising:

[0006] Receive test instructions for target performance testing and determine the target execution device from multiple execution devices contained in the business system;

[0007] Send a corresponding test message to the target execution device. The test message carries a test identifier corresponding to the target performance test. The test message is used to instruct the target execution device to obtain the corresponding test script based on the test identifier and to execute the target performance test based on the test script.

[0008] The system acquires the current time-point running status information of the target execution device during the target performance test, and compares the current time-point running status information with the corresponding time-point running status prediction information; the corresponding time-point running status prediction information is obtained based on the target long short-term memory model and the model output when the test script is used as the model input; the target long short-term memory model is trained based on multiple historical test reports corresponding to the test script.

[0009] If the comparison result indicates that the operating status information at the current time point is abnormal operating status information, a running snapshot corresponding to the target execution device is collected and saved.

[0010] In one embodiment, determining the target execution device from a plurality of execution devices included in the business system includes:

[0011] Obtain the device status of each execution device in the business system;

[0012] The execution device whose device status is non-faulty and idle is identified as the target execution device.

[0013] In one embodiment, sending the corresponding test message to the target execution device includes:

[0014] Obtain the device identifier corresponding to the target execution device, and generate a test message of the execution type based on the device identifier and the test identifier corresponding to the target performance test;

[0015] The test message of the execution type is broadcast to each of the execution devices. The test message of the execution type is used to instruct each execution device that receives the test message to compare whether the device identifier is consistent with its own identifier. If they are consistent, the corresponding test script is obtained according to the test identifier, and the target performance test is executed based on the test script.

[0016] In one embodiment, the method further includes:

[0017] Obtain multiple historical test reports corresponding to the test script; the multiple historical test reports include multiple qualified running status information obtained from tests at multiple historical time points; the multiple historical time points represent multiple time points within a test cycle corresponding to the test script.

[0018] The multiple historical time points and the qualified operating status information corresponding to each historical time point are input into the long short-term memory model to be trained. The long short-term memory model to be trained outputs the operating status prediction information of each historical time point corresponding to the test script based on the multiple historical time points and the multiple qualified operating status information corresponding to the multiple historical time points.

[0019] Based on the similarity between the predicted operational status information at each historical time point and the qualified operational status information at each time point, the model parameters of the long short-term memory model to be trained are adjusted until the training conditions are met, thus obtaining the target long short-term memory model.

[0020] In one embodiment, inputting the plurality of historical time points and the qualified operating status information corresponding to each historical time point into the long short-term memory model to be trained includes:

[0021] For each historical test report, obtain at least one of the following data for each historical time point in the report: thread count, memory information, number of Transmission Control Protocol connections, response time, number of business processes processed per unit time, number of business processing failures, and request consumption time. This data will be used as the qualified operating status information for each historical time point.

[0022] The qualified operating status information corresponding to each historical time point is input into the Long Short-Term Memory (LSTM) model to be trained. Based on each historical time point and the qualified operating status information corresponding to each historical time point, the LSM model to be trained extracts the relationship between operating status features and time points, and outputs the operating status prediction information of each historical time point corresponding to the test script based on the relationship.

[0023] In one embodiment, comparing the current time point's running status information with the corresponding time point's running status prediction information includes:

[0024] Obtain the similarity between the current running status information and the running status prediction information of the corresponding time points output by the target long short-term memory model;

[0025] If the similarity corresponding to the current time point is detected to be less than a preset similarity threshold, the comparison result is determined to represent the operating status information of the current time point as abnormal operating status information.

[0026] In one embodiment, the step of collecting and saving a runtime snapshot corresponding to the target execution device includes:

[0027] A file capture message is sent to the target execution device; the file capture message contains capture frequency and file transfer station address information, and the file capture message is used to instruct the target execution device to capture the corresponding heap dump file and thread snapshot file according to the capture frequency, and send the heap dump file and the thread snapshot file to the file transfer station;

[0028] The heap dump file includes a memory stack snapshot of the target execution device when executing the test script; the thread snapshot file includes the execution stack of each thread corresponding to the processor when the target execution device executes the test script.

[0029] The file transfer station is used to save the heap dump file and the thread snapshot file to the database.

[0030] In one embodiment, the method further includes:

[0031] Obtain the heartbeat information of each target execution device, and determine whether each target execution device is faulty based on the heartbeat information;

[0032] After sending the corresponding test message to the target service execution device, the method further includes:

[0033] If it is determined that the target execution device has malfunctioned, a corresponding test cancellation message is generated based on the device identifier of the target service execution device and the test cancellation instruction;

[0034] The test cancellation message is sent to the target execution device, which instructs the target execution device to stop executing the target performance test if it determines that the device identifier matches its own identifier.

[0035] Secondly, this application provides an anomaly detection device for performance testing, the device comprising:

[0036] The determination module is used to receive test instructions for target performance testing and determine the target execution device from multiple execution devices contained in the business system;

[0037] A sending module is used to send a corresponding test message to the target execution device. The test message carries a test identifier corresponding to the target performance test. The test message is used to instruct the target execution device to obtain the corresponding test script based on the test identifier and to execute the target performance test based on the test script.

[0038] The detection module is used to acquire the current running status information of the target execution device during the target performance test, and compare the current running status information with the running status prediction information at the corresponding time point; the running status prediction information at the corresponding time point is obtained based on the target long short-term memory model and the model output when the test script is used as the model input; the target long short-term memory model is trained based on multiple historical test reports corresponding to the test script.

[0039] The acquisition module is used to acquire and save the corresponding operation snapshot of the target execution device if the comparison result indicates that the operation status information at the current time point is abnormal operation status information.

[0040] Thirdly, this application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0041] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0042] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0043] The anomaly detection methods, devices, computer equipment, storage media, and computer program products in the aforementioned performance testing work by sending test messages to the target execution device in the business system. The target execution device is instructed to obtain the test script based on the test identifier and start the target performance test. The current running status information during the target performance test is compared with the predicted running status information at the corresponding time point based on the target long short-term memory model. If the comparison result indicates that the current running status information is abnormal, a corresponding running snapshot of the target execution device is collected and saved. Compared to the traditional approach of determining whether retesting is needed for anomalies after a stress test, this solution, by training the target long short-term memory model, detects anomalies in the test status at corresponding time points during the target execution device's test execution, and then promptly captures the corresponding running snapshot, thus improving the efficiency of anomaly detection. Attached Figure Description

[0044] Figure 1 This is a diagram illustrating the application environment of an anomaly detection method in performance testing in one embodiment.

[0045] Figure 2 This is a flowchart illustrating an anomaly detection method in performance testing in one embodiment;

[0046] Figure 3 This is a flowchart illustrating the test message sending steps in one embodiment;

[0047] Figure 4 This is a flowchart illustrating the device determination step in one embodiment;

[0048] Figure 5 This is a flowchart illustrating the training steps in one embodiment;

[0049] Figure 6 This is a flowchart illustrating an anomaly detection method in performance testing in another embodiment;

[0050] Figure 7 This is a structural block diagram of an anomaly detection device in a performance test according to one embodiment;

[0051] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0053] The anomaly detection method in performance testing provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with business system 104 via a network. A data storage system can store data that business system 104 needs to process. The data storage system can be integrated into business system 104 or placed in the cloud or on other network servers. Terminal 102 can receive test instructions, identify the target execution device in business system 104, assemble the corresponding test message, and send it to the target execution device in business system 104. The target execution device then obtains the test script based on the test message and begins testing. Terminal 102 can determine whether the target execution device has experienced an anomaly based on the comparison between the running status information of the target execution device at various time points during the test and the corresponding predicted running status information, and collect corresponding snapshots when an anomaly occurs, thus achieving anomaly detection of the target execution device. Terminal 102 can be, but is not limited to, various personal computers and laptops. Business system 104 can be implemented using independent execution devices or a cluster of multiple execution devices.

[0054] In one embodiment, such as Figure 2 As shown, an anomaly detection method in performance testing is provided, which is then applied to... Figure 1 Taking the terminal in the example, the explanation includes the following steps:

[0055] Step S202: Receive test instructions for target performance testing, and determine the target execution device from multiple execution devices contained in the business system.

[0056] The business system can be a system corresponding to banking operations, such as a bank's transaction system. This system includes multiple execution devices, each used to perform business operations, such as executing bank transaction-related transactions. Target performance testing can be testing each execution device within the business system. Performance testing refers to using automated testing tools to simulate various normal, peak, and abnormal load conditions to test various performance indicators of the system. Load testing and stress testing both fall under performance testing. Load testing determines system performance under various workloads, primarily testing how system performance indicators change as the load gradually increases. Stress testing determines the maximum service level the system can provide by identifying system bottlenecks or unacceptable performance points.

[0057] Upon receiving a test command, the terminal can initiate a target performance test process, which involves performing the aforementioned target performance test on eligible execution devices within the business system. This test command can be either periodically triggered automatically or manually triggered by the user. After receiving the test command for the target performance test, the terminal can identify the target execution device from among multiple execution devices included in the business system. The target execution device can be any execution device that meets the test conditions.

[0058] The terminal can determine the target execution device from multiple execution devices based on the status of each execution device. For example, in some embodiments, the terminal can obtain the device status of each execution device in the business system and determine the execution device with a non-faulty and idle status as the target execution device. The execution device status includes idle, locked, faulty, and non-faulty states, so the terminal can use an idle and non-faulty execution device as the target execution device. Specifically, the terminal can be configured with applications corresponding to a stress testing platform and a task scheduling platform. If the user clicks the "Execute" button on the stress testing platform in the terminal to perform a stress test, the terminal obtains all currently non-faulty idle execution devices through the task scheduling platform, selects one as the target execution device, and assembles a specified execution task message format to send to the target execution device. Alternatively, the user can specify a specific execution device for testing. If the user selects a specific execution device to perform a stress test on the stress testing platform, the terminal can directly assemble an execution format message through the task scheduling platform, send it to the execution device, and perform the stress test. It should be noted that the aforementioned target execution devices can include multiple devices. The terminal can manage these machines through a task scheduling platform. During the selection of a target execution device, the state of the execution device needs to be changed. For example, the selected target execution device can be locked to prevent multiple uses. When the terminal receives an unlock message from the task execution device (i.e., the task execution device within the target execution device), it releases the lock on the target execution device and adds the device back to the select queue, meaning it can be selected as a test object again.

[0059] Step S204: Send the corresponding test message to the target execution device. The test message carries the test identifier corresponding to the target performance test. The test message is used to instruct the target execution device to obtain the corresponding test script based on the test identifier and execute the target performance test based on the test script.

[0060] The test message can be a message corresponding to the target execution device. Different execution devices can carry different device identifiers. Each test can also carry a corresponding test identifier, which corresponds to a case for this test. The case can include information such as the test process, the device being tested, and the test script. The terminal can generate test information based on the device identifiers of each execution device and the test identifier, and send the test message to the corresponding target execution device. The target execution device can receive the test message and, based on the test identifier in the test message, obtain the corresponding test script. The target execution device can then execute the target performance test based on the test script. The test script can be stored in a database, and the target execution device can retrieve the corresponding test script from the database based on the test identifier.

[0061] Step S206: Obtain the current time point's running status information during the target performance test performed by the target execution device, and compare the current time point's running status information with the corresponding time point's running status prediction information; the corresponding time point's running status prediction information is obtained based on the target long short-term memory model and the model output when the test script is used as the model input; the target long short-term memory model is trained based on multiple historical test reports corresponding to the test script.

[0062] The target execution device can perform the aforementioned target performance test based on a test script. For example, the target execution device is configured with an execution task device, which can then call JMeter to perform the target performance test based on the test script. JMeter is a stress testing tool developed by the Apache Software Foundation based on Java, used for stress testing software. After obtaining the test script, the target execution device can parse and process its JMX structure. A JMX script is an XML document that records information such as the thread group to be initiated and request information. The target execution device can parse the JMX results and, based on subsequent use, perform certain structural processing before calling JMeter to perform the aforementioned performance test. This structural processing of the JMX can be used to allow the target execution device to display each test step during the performance test based on the test script via a terminal; that is, after processing the JMX script, the target execution device can observe the test process of performing the target performance test through a terminal. During the execution of the target performance test, the target execution device will generate runtime status information at multiple time points. The terminal can obtain the current operating status information of the target execution device during the execution of the aforementioned target performance test. This operating status information can be obtained from the target execution device in real time. The terminal can compare the current operating status information with the predicted operating status information at the corresponding time point. The predicted operating status information at the corresponding time point can be obtained based on a target long short-term memory (LSTM) model. For example, the terminal can input the test script into the target LSTM model, which will then predict the operating status at each time point in the test based on the test script, thus obtaining predicted operating status information for multiple time points, which can be within a test cycle. The terminal can train the target LSTM model using multiple historical test reports corresponding to the aforementioned test script. For example, by inputting the operating status feature information at each time point from multiple historical test reports corresponding to the test script into the LSTM model to be trained, the LSTM model extracts the relationship between time and operating status features, ultimately obtaining a target LSTM model capable of predicting the operating status at each time point in the test corresponding to the aforementioned test script.

[0063] Step S208: If the comparison result indicates that the current time point's running status information is abnormal running status information, collect the running snapshot corresponding to the target execution device and save the running snapshot.

[0064] The terminal can compare the current running status information with the predicted running status information at the corresponding time point to obtain a comparison result. Based on this comparison result, the terminal can determine whether the current running status information of the target execution device is abnormal, and upon detecting abnormal running status information, initiate the process of collecting a running snapshot of the target execution device. Running snapshots can include various types, such as HeapDump files and JavaCore files. After collecting the running snapshot, the terminal can store it, for example, in a database. The HeapDump file is a binary file that saves the object usage in the JVM (Java Virtual Machine) heap at a specific moment; it is a snapshot of the Java stack at a specified time, a kind of image file. The JavaCore file mainly saves the running position of each thread of the Java application at a specific moment, i.e., which class, method, and line the JVM is executing. It is a text file; opening it reveals the execution stack of each thread, displayed as a stack trace. Analyzing the JavaCore file can reveal whether the application is stuck at a certain point or whether prolonged unresponsiveness is causing system crashes. The JVM (Java Virtual Machine) has its own complete hardware architecture, such as a processor, stack, and registers, and also has a corresponding instruction set. It should be noted that in some embodiments, the terminal can only initiate the process of collecting the aforementioned runtime snapshots when it detects abnormal runtime status information at a preset number of time points. After the test, the terminal can also generate a test report based on the execution process of the target execution device, the runtime status information at each time point, and the aforementioned runtime snapshots, and can display the test report. For example, the user can input the corresponding identifier for the test report in the terminal, allowing the terminal to retrieve the corresponding test report from the database and display it.

[0065] In the aforementioned anomaly detection method for performance testing, a test message is sent to the target execution device in the business system. The target execution device is instructed to obtain the test script based on the test identifier and start the target performance test. The current running status information during the target performance test is compared with the predicted running status information at the corresponding time point based on the target long short-term memory model. If the comparison result indicates that the current running status information is abnormal, a corresponding running snapshot of the target execution device is collected and saved. Compared to the traditional method of determining whether retesting is needed for anomalies after a stress test, this solution, by training the target long short-term memory model, detects anomalies in the test status at corresponding time points during the test execution process on the target execution device, and then promptly captures the corresponding running snapshot, thus improving the efficiency of anomaly detection.

[0066] In one embodiment, sending a corresponding test message to the target execution device includes: obtaining the device identifier corresponding to the target execution device; generating an execution type test message based on the device identifier and the test identifier corresponding to the target performance test; broadcasting the execution type test message to each execution device, wherein the execution type test message is used to instruct each execution device that receives the test message to compare whether the device identifier is consistent with its own identifier; if consistent, obtaining the corresponding test script based on the test identifier; and executing the target performance test based on the test script.

[0067] In this embodiment, the execution device in the aforementioned business system may further include a device identifier. Since there are multiple execution devices in the business system, the terminal needs to send the test message to the corresponding target execution device using the device identifier. For example, such as... Figure 3 As shown, Figure 3 This is a flowchart illustrating the test message sending steps in one embodiment. The terminal can be configured with a stress testing platform and a task execution status judgment platform, etc. Testers can initiate test requests through the stress testing platform, and the task execution status judgment platform can also send corresponding requests based on the status of the target execution device, such as sending a request to capture a runtime snapshot file. The terminal can generate corresponding messages based on these requests and broadcast them to the aforementioned execution devices. The terminal can obtain the device identifier of the target execution device, and generate an execution-type test message based on the device identifier and the test identifier corresponding to the target performance test, and broadcast the execution-type test message to each execution device. Thus, each execution device in the aforementioned business system will receive the broadcast test message and compare the device identifier in the test message with its own device identifier. If the comparison matches, it indicates that the test message was sent to the local machine. At this time, the target execution device can obtain the corresponding test script based on the test identifier in the test message and execute the target performance test based on the test script.

[0068] The aforementioned execution type indicates that when the execution device receives a test message of this type and determines that it is a message sent to the local machine, it initiates the target performance test process. The terminal can also generate other types of test messages and broadcast them to the target execution devices. For example, in one embodiment, the terminal can also obtain the heartbeat information of each target execution device and determine whether each target execution device is faulty based on the heartbeat information. If the terminal determines that a target execution device is faulty after sending the corresponding test message to the target service execution device, the terminal can generate a corresponding test cancellation message based on the device identifier of the target execution device and the test cancellation instruction. After receiving the test cancellation message, the target execution device can check whether the device identifier in the test cancellation message matches its own device identifier, and stop executing the target performance test if a match is detected. Additionally, the terminal can also generate a message corresponding to the collection of a runtime snapshot file based on the aforementioned device identifier, enabling the target execution device to collect the corresponding runtime snapshot when it determines that the device identifier matches its own identifier.

[0069] Specifically, for execution-type test messages, if the tester simply clicks the "Execute" button on the terminal to perform the target performance test, the terminal can obtain all non-faulty idle devices in the current business system, select one, and assemble a test message based on the user's needs, combining the device identifier and test identifier, through the aforementioned task scheduling platform, and broadcast it to the execution task devices of each execution device in the aforementioned business system. If the tester selects a specific target execution device to perform the target performance test on the terminal, the terminal can directly assemble the corresponding test message through the task scheduling platform and send it to the target execution device. Additionally, for cancellation-type test cancellation messages, the tester can click the "Stop Execution" button on the terminal, allowing the terminal to generate a corresponding test cancellation message based on the device identifier of the target execution device to be cancelled, and broadcast it to the target execution device. Stop the target performance test. Additionally, the terminal can receive self-check information about the target execution device's status. The target execution device uploads its own running status information every two minutes. If the terminal detects that the target execution device has not uploaded its running status information within two consecutive heartbeat intervals, the terminal can send the aforementioned test cancellation message through the task scheduling platform, causing the target execution device to terminate the target performance test and release the target execution device. For capture-type messages, when abnormal running status information is detected, the terminal can generate a corresponding capture message based on the device identifier of the abnormal target execution device and broadcast it to the business system. Upon receiving the capture message, the target execution device will capture the aforementioned javacore and heapdump files at a certain frequency through the task execution device and send them to a designated location to prevent file loss due to container restarts.

[0070] Specifically, such as Figure 4 As shown, Figure 4 This is a flowchart illustrating the device determination steps in one embodiment. Each execution device in the aforementioned business system is configured with an execution task device and a cloud container for the JMeter environment. When an execution device receives messages of various types sent by the terminal, it can first determine whether the device identifier in the message is its own identifier. If so, the device enters the message category determination process and executes the corresponding process based on the message category. If the execution device determines that the identifier is not its own, it can terminate the message without further processing. If a target execution device detects that the message type is execution, it can query the test case parsing results stored in the database based on the test identifier in the message, obtain the parsed JMX structure, and thus obtain the test script. After processing the JMX structure, the terminal can obtain the process information of the target execution device performing the target performance test. The target execution device can then call JMeter to perform the target performance test. After the test, the target execution device can send the test report to a designated location, such as the terminal, and display it on the terminal. If the message type is "cancel execution," the target execution device can terminate the currently processing JMeter process, register the task completion, and send an unlock message to the terminal, causing the terminal to release the target execution device. If the message type is a capture type, i.e., retrieving runtime snapshot files, the target execution device can retrieve the aforementioned javacore and heapdump files at a certain frequency. This frequency can be set when the test plan is added, for example, once per minute.

[0071] Through the above embodiments, the terminal can generate different types of messages based on the state of the target execution device and broadcast them to the target execution device, so that the target execution device can execute the corresponding process according to the messages received in real time, thereby improving the efficiency of performance testing.

[0072] In one embodiment, the method further includes: obtaining multiple historical test reports corresponding to the test script; the multiple historical test reports include multiple qualified operating status information obtained from tests at multiple historical time points; the multiple historical time points represent multiple time points within a test cycle corresponding to the test script; inputting the multiple historical time points and the qualified operating status information corresponding to each historical time point into the long short-term memory model to be trained, and having the long short-term memory model to be trained output the operating status prediction information of each historical time point corresponding to the test script based on the multiple historical time points and the multiple qualified operating status information corresponding to the multiple historical time points; adjusting the model parameters of the long short-term memory model to be trained according to the similarity between the operating status prediction information of each historical time point and the qualified operating status information of each time point, until the training conditions are met, and obtaining the target long short-term memory model.

[0073] In this embodiment, the terminal can pre-train a target LSTM (Long Short-Term Memory) model. One test script corresponding to one execution device can correspond to one target LSTM model; that is, each execution device can correspond to multiple target LSTM models for multiple test scripts. During training, the terminal can obtain multiple historical test reports corresponding to the test scripts. These historical test reports include multiple qualified operating status information obtained from tests at multiple historical time points. Qualified operating status information indicates that the operating status of the target execution device meets expectations. The multiple historical time points represent multiple time points within a test cycle corresponding to the test script, such as various time points from the start to the end of the test.

[0074] The terminal can acquire the Long Short-Term Memory (LSTM) model to be trained and input the multiple historical time points and their corresponding qualified operational state information into the LTM model. The LTM model then outputs operational state prediction information for each historical time point corresponding to the test script, based on the multiple historical time points and their corresponding qualified operational state information. The terminal can adjust the model parameters of the LTM model to be trained based on the similarity between the operational state prediction information output by the model for each historical time point and the corresponding qualified operational state information, until the training conditions are met, thus obtaining the target LTM model. The operational state information can include various types of operational states, which can be used as feature information for model prediction. For example, in one embodiment, multiple historical time points and the corresponding qualified operational status information for each historical time point are input into the Long Short-Term Memory (LSTM) model to be trained. This includes: for each historical test report, obtaining at least one of the following parameters corresponding to each historical time point: thread count, memory information, transmission control protocol (TCP) connection count, response time, number of business processes processed per unit time, number of business processing failures, and request latency, as the qualified operational status information for each historical time point; inputting the qualified operational status information for each historical time point into the LSM model to be trained, and having the LSM model extract the relationship between operational status features and time points based on each historical time point and the corresponding qualified operational status information, and outputting operational status prediction information for each historical time point corresponding to the test script based on the relationship. In this embodiment, each of the aforementioned historical test reports may include at least one of the following parameters corresponding to each historical time point: thread count, memory information, TCP connection count, response time, number of business processes processed per unit time, number of business processing failures, and request latency. The terminal can obtain at least one of the above operational status parameters as the qualified operational status information for each historical time point. Thus, the terminal can input the qualified operating status information of each of the above historical time points into the long short-term memory model to be trained, train the long short-term memory model to be trained, and obtain the target long short-term memory model.

[0075] Specifically, for transaction business systems, the operational characteristics will differ due to the different peripheral nodes of different transactions, such as the different communication methods used by different transactions. The terminal can accumulate a certain amount of test reports to ensure sufficient data and the accuracy of feature extraction. For example, the completion of a transaction requires the cooperation of multiple applications and multiple nodes. For a node within a transaction, its peripheral nodes include upstream nodes, downstream nodes, and interactions between nodes themselves, such as databases and message middleware. Depending on the differences in the transaction completion chain, the peripheral nodes will vary. A single business can correspond to a single test script. The terminal can obtain multiple historical test reports corresponding to a single business and extract features such as the number of wait threads, memory usage, TCP (Transmission Control Protocol) connections, response time, TPS (Transactions Per Second), number of failed transactions, and request latency from these reports. The relationship between these feature values ​​and time series is then input into the LSTM to be trained to extract the relationship between relevant features and time. Based on this relationship, the terminal can predict the performance of the execution device of a specified transaction node.

[0076] Taking transaction features as an example, the process of training the LSTM on the terminal includes: Step 1: Using data processing tools, obtain stress test data for different transactions, such as stress test time, number of threads, duration, connection duration, latency, and response time. Extract the above features for each transaction to construct a single data entry. For example, Transaction 1: (Withdrawal, 3, 600s, 0.01s, 0.01s, 0.02s) corresponds to (Transaction Name, Number of Threads, Duration, Connection Duration, Latency, Response Time) respectively. Step 2: Because transaction information is non-segmented data, which is not conducive to analysis and processing, it is converted into structured data. A data dictionary for transaction information is established to convert it into structured data. The specific details are shown in the table below:

[0077]

[0078] The terminal can convert the transaction data from step 1 into: Transaction 1: (1, 3, 600s, 0.01s, 0.01s, 0.02s). Step 3: The transaction information obtained from steps 1 and 2 constitutes a transaction data feature table, which is used to establish a multi-dimensional data axis. The dimensions are load testing time, number of threads, duration, connection duration, latency, and response time. A transaction feature distribution coordinate system is constructed using the data from each transaction in the table. The transaction data feature table is shown below:

[0079]

[0080] During the data acquisition process, the terminal can obtain historical transaction data, such as transaction name, number of threads, duration, connection duration, latency, and response time. This data reflects changes in various characteristics of the transactions, allowing for the construction of a historical transaction data table.

[0081]

[0082] The terminal can construct training data pairs (X_train, Y_train) by labeling historical transaction data with response time and other features arranged in ascending date order. A recurrent neural network (LSTM) model is then constructed. Unlike other traditional neural networks, it is not independent of multiple input data; after each computation, the result and the next input are passed together to the next computation unit. The hidden layer can be simply represented as g(x) = σ(W(x+a)+b). Therefore, it can "memorize" past data and make more accurate predictions about the future. By inputting historical transaction data, the LSTM model learns from the historical data to reduce the prediction error of response time. Taking the historical data table from step 1 as an example, the terminal can construct training data: using the withdrawal response time as the label Y, with the Y value sequence as: Y1, Y2, ... = [0.98, 0.975, ...]. The withdrawal transaction stress test time, number of threads, duration, connection duration, latency, and response time are used as features X in ascending date order. The value sequence of X is: X1, X2, ... = [(30, 200, 0.02, 0.01, 1, 2022-aa-bb), (30, 200, 0.01, 0.02, 1, 2022-aa-(bb+1)), ...].

[0083] Thus, the terminal can build an LSTM model and its learning process, such as Figure 5 As shown, Figure 5This is a flowchart illustrating the training steps in one embodiment. LSTM can be simply represented as g(x) = σ(Wx + b). After inputting (X, Y) data, the input layer of the neural network can be represented as a = σ(WX + b), and the hidden layer as g(x) = σ(W(X + a) + b), where σ represents the input and forget gate parameters of LSTM, combined into σ. Through backpropagation (BP), the parameters σ, W, and b undergo gradient descent in each learning round until convergence, at which point the model is built. For new data X to predict the result Y, inputting X yields g(X) = σ(WX + b), thus obtaining the predicted result Y = g(X), which represents the future trend characteristics of the response time, also known as the running state prediction information. The terminal can generate data that changes over time based on the running state prediction information obtained in the previous step, using a feature extractor to convert the new metadata into a feature matrix, and using a cosine similarity algorithm to calculate the distance between two pieces of metadata, normalizing it to a similarity between [0, 1]. If the similarity exceeds 90%, the node transaction is considered normal; otherwise, it is considered an abnormal transaction, and an alarm is sent for further processing. The formula is as follows:

[0084]

[0085] Where x is the feature matrix of the transaction, y is the newly defined feature matrix pushed by the configuration center, ||x|| represents the Euclidean norm of the feature matrix of previously occurring transactions, and ||y|| represents the Euclidean norm of the feature matrix of the currently ongoing transaction. i y represents each row vector in the old definition of the characteristic matrix. i This represents each row vector in the newly defined characteristic matrix.

[0086] Through the above embodiments, the terminal can extract features from multiple time points in the historical test report corresponding to the test script of a single service, train a target long short-term memory model, and then the terminal can predict the operating status of the target execution device based on the target long short-term memory model, thereby improving the efficiency of performance testing.

[0087] In one embodiment, comparing the current time point's running status information with the corresponding time point's running status prediction information includes: obtaining the similarity between the current time point's running status information and the corresponding time point's running status prediction information output by the target long short-term memory model; if the similarity corresponding to the current time point is detected to be less than a preset similarity threshold, the comparison result is determined to characterize the current time point's running status information as abnormal running status information.

[0088] In this embodiment, the terminal detects the operating status of the target execution device during the target performance test to determine whether the operating status of the target execution device is normal. The terminal can input the test script into the target long short-term memory model, and the target long short-term memory model outputs the operating status prediction information for each time point corresponding to the test script. The terminal can obtain the similarity between the operating status prediction information for each time point and the operating status information for the current time point, specifically, it can be cosine similarity. If the terminal detects that the similarity between the operating status information for the current time point and the corresponding time point is less than a preset similarity threshold, the terminal can determine that the operating status information for the current time point is abnormal operating status information. In addition, in some embodiments, the terminal can also determine that the comparison result represents the operating status information for the current time point as abnormal operating status information when it detects that the similarity of each time point within a preset time period is less than the preset similarity threshold. That is, the terminal can obtain the operating status information for multiple time points during the target performance test and compare it with the operating status prediction information for the corresponding time points respectively. When the similarity obtained by the comparison is less than the preset similarity threshold, it is determined that the target execution device has entered an abnormal state. Specifically, the aforementioned similarity can be cosine similarity. The terminal can determine whether the running status information is abnormal by detecting the cosine similarity between the running status information and the running status prediction information.

[0089] Through this embodiment, the terminal can detect whether there are any abnormal operating states during the target performance test of the target execution device based on the target long short-term memory model, thereby improving the efficiency of performance testing.

[0090] In one embodiment, acquiring and saving a runtime snapshot corresponding to the target execution device includes: sending a file capture message to the target execution device; the file capture message contains capture frequency and address information of a file transfer station, and the file capture message is used to instruct the target execution device to capture the corresponding heap dump file and thread snapshot file according to the capture frequency, and send the heap dump file and thread snapshot file to the file transfer station; wherein, the heap dump file includes a memory stack snapshot of the target execution device when executing the test script; the thread snapshot file includes the execution stack of each thread corresponding to the processor when the target execution device executes the test script; wherein, the file transfer station is used to save the heap dump file and thread snapshot file to a database.

[0091] In this embodiment, when the terminal detects abnormal operating status information of the target execution device, it collects relevant runtime snapshot files of the target execution device. When the terminal determines that runtime snapshot files need to be collected, it can send a file capture message to the target execution device. This file capture message can be generated based on the target execution device's device identifier, capture frequency, and the address information of the file transfer station. After receiving the file capture message, the target execution device, if it determines that the device identifier in the message is its own identifier, captures the corresponding heap dump file and thread snapshot file based on the capture frequency, and sends these files to the file transfer station according to the address information in the message. The heap dump file can be the aforementioned HeapDump file, including a memory stack snapshot of the target execution device when executing the test script; the thread snapshot file can be the aforementioned JavaCore file, including the execution stack of each thread corresponding to the processor when the target execution device executes the test script. After receiving the aforementioned runtime snapshot files, the file transfer station can save the heap dump file and thread snapshot file to the database.

[0092] Specifically, during target performance testing, the terminal can compare the target execution device's running status information with the predicted running status information based on the target's long short-term memory model. If a significant deviation exists, the terminal can initiate a file capture message through the task scheduling platform, requesting the target execution device to capture javacore and heapdump files via its task execution unit. The terminal will then contact the developers via SMS and email to ensure timely follow-up. The javacore and heapdump files can be sent to a file transfer platform, which stores the stress test report from the task execution unit and the files captured at a specified frequency when the javacore and heapdump file capture message is received. This prevents the loss of relevant files due to container restarts. These files originate from the task execution unit within the target execution device.

[0093] In this embodiment, when the target execution device malfunctions, the terminal can instruct the capture of the runtime snapshot file in the target execution device via a file capture message command. This allows relevant test developers to analyze and improve based on the runtime snapshot file, thereby improving the efficiency of performance testing.

[0094] In one embodiment, such as Figure 6 As shown, Figure 6This is a flowchart illustrating an anomaly detection method in performance testing in another embodiment. In this embodiment, the terminal may include a stress testing platform, a task scheduling platform, and a runtime status assessment platform. Each execution device in the business system may be configured with a task execution device. Each tester may be a separate individual tester. The terminal can provide a login page for testers on the stress testing platform, offering a channel for testers to initiate target performance tests. Testers can manage test cases on this platform, including routine functions such as adding, deleting, copying existing cases, adjusting test case parameters according to actual stress testing needs, and exporting existing case files. The platform also provides stress reports for each stress test for testers to download, helping them understand the results of each stress test. The platform displays all normally functioning machines to testers, who can select devices to perform stress tests as needed, and the task scheduling platform can also schedule the selected devices for stress testing.

[0095] Specifically, the stress testing platform includes four sections: Test Scripts, Test Tasks, Execution Machine, and Metrics Library. The Test Scripts section displays all scripts within a user's permissions. Testers can add test cases in the terminal. After logging into the stress testing platform, testers can add a test plan on the Test Plan page by entering the version, application name, and test plan name. After editing the details, the original JMX script is dragged in. The stress testing platform parses the original JMX and displays it on the front end. For example, after parsing the original JMX file, the stress testing platform obtains the corresponding basic stress testing parameters, such as the number of users in the thread group, the delay thread creation time, the stress test duration, the number of stress test executions, the path of the stress test request, the port, related components, etc. The terminal's processing of the original JMX completes two tasks: Previously, stress testers initiated stress tests in visual mode and could see the stress test progress during the process. However, stress tests executed on the execution machine are in non-visual mode and cannot be properly observed. By processing the JMX and adding corresponding components, the new system and the original JMeter provide consistent visualization services. By processing JMX data, the backend can obtain load testing data in real time for trend similarity assessment. This saves the test cases to the backend. Test cases can also be edited in the terminal. After logging into the load testing platform, testers can select a test plan, click "Details," and view the overall structure and configuration of each component. Testers can click on the component name to view its details, manually enter modified parameters, and click "Save" to overwrite the test case. The backend stores the parsed results in the database for later use. Testers can also delete test cases. After logging into the load testing platform, testers can select a test plan and click the "Delete" button to delete the test case. Due to access control, only the load testing platform administrator can modify or delete other people's test plans. Testers can initiate target performance tests through the terminal. After logging into the load testing platform, testers can select the "Execute" button next to the test plan to initiate the load test. The task scheduling platform then selects a machine to execute the load test. Testers can also terminate target performance tests. After logging into the stress testing platform, testers can decide to stop the stress test for various reasons by clicking the "Stop Execution" button on the right side of the test plan. The task scheduling platform in the terminal will then broadcast a stop command to the stress testing machine, ending the stress test. Testers can also browse historical reports in the terminal. They can retrieve a specified stress test report based on the time the stress test was initiated, and understand the historical stress test situation.Furthermore, the file capture frequency can be configured. When the terminal determines that there is a significant performance deviation during the node's operation through the task running status platform, it will send a message to the task scheduling center to capture the relevant javacore and heapdump files. Testers can configure this according to their own needs, with the default time being once per minute.

[0096] The aforementioned terminal can be a scheduler. The scheduler receives requests initiated by testers in their browsers. If the tester specifies a machine for load testing, the request is sent directly to that machine. If the tester does not specify a machine, the scheduler selects a machine for load testing based on the machine status of the cluster and writes the selected machine information to a database for later tracking. Furthermore, the scheduler can use a broadcast mechanism to send messages to all execution machines. Each execution machine determines whether it is its local machine based on the execution machine information in the message. Execution machines can be the target execution devices in the aforementioned business system. When an execution machine starts, it writes relevant running information to the database, which testers can view on the terminal's front-end page. When receiving commands from the scheduler, the execution machine determines whether the selected execution machine is its local machine. If it is, it updates the machine's status to "in use" and modifies the test plan, such as the JMX test script mentioned above. The execution machine can also add backend listeners and BeanShell scripts. After completion, the execution machine starts a new test plan. After the test is completed, the execution machine's status is updated to "idle," and the generated test files are sent to a specified location, such as a file transfer station, for testers to view on the front-end. The execution machine's status includes idle, in use, and faulty states. The backend listener can be an internal JMeter function, writing summary data from the test plan to InfluxDB (a time-series database). The data packet contains information such as the number of transactions, successful transactions, failed transactions, and response time. BeanShell is a lightweight scripting language written in Java; it allows the execution of Java code to perform logical calculations.

[0097] Through the above embodiments, the terminal, by training the target's Long Short-Term Memory (LSTM) model, can promptly detect anomalies in the test status at corresponding time points during the target execution device's testing process, and then capture the corresponding runtime snapshots in a timely manner, improving the efficiency of anomaly detection. Furthermore, it effectively lowers the barrier to performance testing, eliminating the need for testers to understand load testing information across multiple systems. It integrates commonly used performance testing information within a single system, providing a clear and intuitive display of the resource usage of the server under load, the number of performance tests initiated, and the success rate. This also frees up the machines of load testing personnel to a certain extent, ensuring that load tests can be initiated while other tasks can be completed, avoiding machine performance issues affecting work. Moreover, the aforementioned cloud containers are characterized by easy shrinking and expansion, making them better suited to the needs of performance testing compared to personal machines.

[0098] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0099] Based on the same inventive concept, this application also provides an anomaly detection device for implementing the anomaly detection method in the performance test described above. The solution provided by this device is similar to the implementation described in the above method. Therefore, the specific limitations in one or more embodiments of the anomaly detection device for performance testing provided below can be found in the limitations of the anomaly detection method for performance testing described above, and will not be repeated here.

[0100] In one embodiment, such as Figure 7 As shown, an anomaly detection device for performance testing is provided, comprising: a determination module 500, a transmission module 502, a detection module 504, and a data acquisition module 506, wherein:

[0101] The determination module 500 is used to receive test instructions for target performance testing and determine the target execution device from multiple execution devices contained in the business system.

[0102] The sending module 502 is used to send the corresponding test message to the target execution device. The test message carries the test identifier corresponding to the target performance test. The test message is used to instruct the target execution device to obtain the corresponding test script based on the test identifier and to execute the target performance test based on the test script.

[0103] The detection module 504 is used to acquire the current running status information of the target execution device during the target performance test, and compare the current running status information with the running status prediction information at the corresponding time point; the running status prediction information at the corresponding time point is obtained based on the target long short-term memory model and the model output when the test script is used as the model input; the target long short-term memory model is trained based on multiple historical test reports corresponding to the test script.

[0104] The acquisition module 506 is used to acquire and save the corresponding running snapshot of the target execution device if the comparison result indicates that the running status information at the current time point is abnormal running status information.

[0105] In one embodiment, the determination module 500 is specifically used to obtain the device status of each execution device in the business system; and to determine the execution device whose device status is non-faulty and idle as the target execution device.

[0106] In one embodiment, the sending module 502 is specifically used to obtain the device identifier corresponding to the target execution device, generate an execution type test message based on the device identifier and the test identifier corresponding to the target performance test, broadcast the execution type test message to each execution device, the execution type test message is used to instruct each execution device that receives the test message to compare whether the device identifier is consistent with its own identifier, if consistent, obtain the corresponding test script based on the test identifier, and execute the target performance test based on the test script.

[0107] In one embodiment, the apparatus further includes: a training module, configured to acquire multiple historical test reports corresponding to the test script; the multiple historical test reports include multiple qualified operating status information obtained from tests at multiple historical time points; the multiple historical time points represent multiple time points within a test cycle corresponding to the test script; input the multiple historical time points and the qualified operating status information corresponding to each historical time point into the long short-term memory model to be trained, and output the operating status prediction information of each historical time point corresponding to the test script based on the multiple historical time points and the multiple qualified operating status information corresponding to the multiple historical time points; adjust the model parameters of the long short-term memory model to be trained according to the similarity between the operating status prediction information of each historical time point and the qualified operating status information of each time point, until the training conditions are met, and obtain the target long short-term memory model.

[0108] In one embodiment, the training module is specifically used to obtain, for each historical test report, at least one of the following parameters corresponding to each historical time point: thread count, memory information, transmission control protocol connection count, response time, number of business processes per unit time, number of business processing failures, and request latency, as qualified operating status information for each historical time point; input the qualified operating status information corresponding to each historical time point into the Long Short-Term Memory (LSTM) model to be trained; the LSM model to be trained extracts the relationship between operating status features and time points based on each historical time point and the qualified operating status information corresponding to each historical time point, and outputs the predicted operating status information for each historical time point corresponding to the test script based on the relationship.

[0109] In one embodiment, the detection module 504 is specifically used to obtain the similarity between the current time point's running status information and the corresponding time point's running status prediction information output by the target long short-term memory model; if the similarity corresponding to the current time point is detected to be less than a preset similarity threshold, the comparison result is determined to characterize the current time point's running status information as abnormal running status information.

[0110] In one embodiment, the acquisition module 506 is specifically used to send a file capture message to the target execution device. The file capture message contains capture frequency and address information of the file transfer station. The file capture message is used to instruct the target execution device to capture the corresponding heap dump file and thread snapshot file according to the capture frequency, and send the heap dump file and thread snapshot file to the file transfer station. The heap dump file includes a memory stack snapshot of the target execution device when executing the test script. The thread snapshot file includes the execution stack of each thread corresponding to the processor when the target execution device executes the test script. The file transfer station is used to save the heap dump file and thread snapshot file to the database.

[0111] In one embodiment, the above apparatus further includes: a fault detection module, used to acquire heartbeat information of each target execution device and determine whether each target execution device is faulty based on the heartbeat information.

[0112] In one embodiment, the above apparatus further includes: a stop test module, configured to, if it is determined that the target execution device has malfunctioned, generate a corresponding test cancellation message based on the device identifier of the target service execution device and the test cancellation instruction; and send the test cancellation message to the target execution device, wherein the test cancellation message is used to instruct the target execution device to stop executing the target performance test if it is determined that the device identifier is consistent with its own identifier.

[0113] The modules in the anomaly detection device described above can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0114] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When executed by the processor, the computer program implements an anomaly detection method in performance testing. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device casing, or an external keyboard, touchpad, or mouse.

[0115] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0116] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the anomaly detection method in the performance test described above.

[0117] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the anomaly detection method in the performance test described above.

[0118] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the anomaly detection method in the performance test described above.

[0119] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0120] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0121] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0122] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An anomaly detection method in performance testing, characterized in that, The method includes: Receive test instructions for target performance testing, determine the target execution device from multiple execution devices included in the business system, wherein the target execution device is the execution device in the business system whose device status is non-faulty and idle; Send a corresponding test message to the target execution device. The test message carries a test identifier corresponding to the target performance test. The test message is used to instruct the target execution device to obtain the corresponding test script based on the test identifier and to execute the target performance test based on the test script. The system acquires the current running status information of the target execution device during the target performance test, and obtains the similarity between the current running status information and the running status prediction information of the corresponding time points output by the target long short-term memory model. If the similarity corresponding to the current time point is less than a preset similarity threshold, the running status information of the current time point is determined to be abnormal running status information. The running status prediction information of the corresponding time point is based on the target long short-term memory model and is obtained from the model output when the test script is used as the model input. The target long short-term memory model is trained based on multiple historical test reports corresponding to the test script. The multiple historical test reports include multiple qualified running status information obtained from multiple historical time points. The qualified running status information corresponding to each historical time point includes at least one of the following: number of threads, memory information, number of transmission control protocol connections, response time, number of business processes processed per unit time, number of business processing failures, and request consumption time. If the current running status information is abnormal, a file capture message is sent to the target execution device. The file capture message includes the capture frequency and the address information of the file transfer station. The file capture message instructs the target execution device to capture the corresponding heap dump file and thread snapshot file according to the capture frequency, and to send the heap dump file and the thread snapshot file to the file transfer station. The heap dump file includes a memory stack snapshot of the target execution device when executing the test script; the thread snapshot file includes the execution stack of each thread corresponding to the processor when the target execution device executes the test script. The file transfer station is used to save the heap dump file and the thread snapshot file to the database.

2. The method according to claim 1, characterized in that, Sending the corresponding test message to the target execution device includes: Obtain the device identifier corresponding to the target execution device, and generate a test message of the execution type based on the device identifier and the test identifier corresponding to the target performance test; The test message of the execution type is broadcast to each of the execution devices. The test message of the execution type is used to instruct each execution device that receives the test message to compare whether the device identifier is consistent with its own identifier. If they are consistent, the corresponding test script is obtained according to the test identifier, and the target performance test is executed based on the test script.

3. The method according to claim 1, characterized in that, The method further includes: Obtain multiple historical test reports corresponding to the test script; the multiple historical test reports include multiple qualified running status information obtained from tests at multiple historical time points; the multiple historical time points represent multiple time points within a test cycle corresponding to the test script. The multiple historical time points and the qualified operating status information corresponding to each historical time point are input into the long short-term memory model to be trained. The long short-term memory model to be trained outputs the operating status prediction information of each historical time point corresponding to the test script based on the multiple historical time points and the multiple qualified operating status information corresponding to the multiple historical time points. Based on the similarity between the predicted operational status information at each historical time point and the qualified operational status information at each time point, the model parameters of the long short-term memory model to be trained are adjusted until the training conditions are met, thus obtaining the target long short-term memory model.

4. The method according to claim 3, characterized in that, The step involves the training long short-term memory model outputting predicted runtime information for each historical time point corresponding to the test script, based on multiple historical time points and corresponding qualified runtime information. This includes: For each historical test report, the long short-term memory model to be trained extracts the relationship between the running status features and the time points based on each historical time point and the qualified running status information corresponding to each historical time point, and outputs the running status prediction information of each historical time point corresponding to the test script based on the relationship.

5. The method according to claim 1, characterized in that, The method further includes: Obtain the heartbeat information of each target execution device, and determine whether each target execution device is faulty based on the heartbeat information; After sending the corresponding test message to the target execution device, the method further includes: If it is determined that the target execution device has malfunctioned, a corresponding test cancellation message is generated based on the device identifier of the target execution device and the test cancellation instruction; The test cancellation message is sent to the target execution device, which instructs the target execution device to stop executing the target performance test if it determines that the device identifier matches its own identifier.

6. An anomaly detection device for performance testing, wherein the anomaly detection device for performance testing is used to implement the anomaly detection method for performance testing according to any one of claims 1-5, characterized in that, The device includes: The determination module is used to receive test instructions for target performance testing and determine the target execution device from multiple execution devices contained in the business system; A sending module is used to send a corresponding test message to the target execution device. The test message carries a test identifier corresponding to the target performance test. The test message is used to instruct the target execution device to obtain the corresponding test script based on the test identifier and to execute the target performance test based on the test script. The detection module is used to acquire the running status information of the target execution device at the current time point during the target performance test, and to acquire the similarity between the running status information at the current time point and the running status prediction information of the corresponding time points output by the target long short-term memory model; if the similarity corresponding to the current time point is less than a preset similarity threshold, the running status information at the current time point is determined to be abnormal running status information; the running status prediction information of the corresponding time point is obtained based on the target long short-term memory model and the model output when the test script is used as the model input; the target long short-term memory model is trained based on multiple historical test reports corresponding to the test script; The acquisition module is used to acquire and save the corresponding operation snapshot of the target execution device if the operation status information at the current time point is abnormal operation status information.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

Images