Software performance test system, method and equipment under high-concurrency scene

Abstract

The invention discloses a software performance test system, method and device in a high-concurrency scene, and relates to the field of software testing, the system comprises a scene intelligent construction module used for generating a concurrency scene through a behavior tree modeling and time sequence prediction algorithm according to service demand parameters and historical traffic data; the distributed test environment scheduling module is used for constructing a distributed test environment by adopting a container arrangement technology; the virtual user load generation module is used for simulating concurrent user requests by adopting a coroutine pool technology; the real-time performance data acquisition module is used for acquiring multi-source performance data of the tested software in real time; the intelligent performance analysis module is used for calculating a core performance index according to the multi-source performance data and carrying out anomaly detection and trend prediction; and the performance bottleneck positioning module is used for mining a dependency relationship among the core performance indexes and generating a bottleneck positioning report and an optimization suggestion document. According to the method, the accuracy, the efficiency and the stability of software performance testing in a high-concurrency scene are improved.

Description

Technical Field

[0001] This application relates to the field of software testing, and in particular to a software performance testing system, method and device for high concurrency scenarios. Background Technology

[0002] With the rapid iteration of internet technology, software performance in high-concurrency scenarios has become a core indicator determining user experience and business continuity. Current mainstream performance testing systems generate standardized virtual user flows through a pre-set test case library, use a centralized scheduling engine to control test node execution, and utilize a time-series database to store performance metrics. Specifically, during the test preparation phase, testers manually write JMeter or LoadRunner scripts containing fixed access paths and define the number of concurrent virtual users using Extensible Markup Language (XML) configuration files. During test execution, all test nodes periodically report basic metrics such as CPU utilization and memory usage to the central controller, which determines system stability based on a threshold trigger mechanism. After the test, an Elasticsearch cluster is used to perform offline analysis of terabytes of log data, generating a test report containing aggregated metrics such as average response time and error rate.

[0003] However, the aforementioned performance testing system has the following technical problems: First, the script's fixed mechanism makes it impossible to simulate the randomness of real user behavior, such as the diversity of product browsing paths in e-commerce scenarios and the transaction timing dependence in financial scenarios. It is impossible to reproduce random access patterns, timing dependencies, and sudden traffic surges under high concurrency, resulting in significant deviations between test results and actual operating conditions.

[0004] Secondly, static resource allocation strategies are prone to node overload when facing sudden traffic surges. For example, during flash sales, some test nodes may experience service interruptions due to request backlogs, while other nodes remain idle. It is difficult to dynamically adjust the load capacity according to business pressure, resulting in the dual problems of resource waste or insufficient load.

[0005] Third, the data acquisition and transmission adopts a push-mode architecture. When the number of virtual users exceeds 100,000, the message queue of the central controller is prone to blockage, resulting in the loss of monitoring data, which leads to real-time monitoring interruption and difficulty in tracing the source of anomalies.

[0006] Fourth, anomaly localization relies on manually correlating multiple dimensions of indicators. For example, it requires simultaneously analyzing the causal relationship between database connection pool exhaustion and Java Virtual Machine (JVM) garbage collection pauses, resulting in low diagnostic efficiency and difficulty in quickly locating the root cause. Summary of the Invention

[0007] The purpose of this application is to provide a software performance testing system, method, and device for high-concurrency scenarios, which can improve the accuracy, efficiency, and stability of software performance testing in high-concurrency scenarios.

[0008] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a software performance testing system for high-concurrency scenarios, including: The scene intelligence construction module is used to generate concurrent scenes based on business requirement parameters and historical traffic data through behavior tree modeling and time series prediction algorithms, and save them as scene files; The distributed test environment scheduling module is used to construct a distributed test environment for the software under test using container orchestration technology based on the scenario file. The virtual user load generation module is used to simulate concurrent user requests based on the scenario file and the distributed test environment using coroutine pool technology. The real-time performance data acquisition module is used to collect multi-source performance data of the software under test in real time during the process of simulating concurrent user requests. The intelligent performance analysis module is used to calculate core performance indicators based on the multi-source performance data, and to use machine learning algorithms to perform anomaly detection and trend prediction on the core performance indicators, so as to obtain anomaly detection results and trend prediction results. The performance bottleneck localization module is used to discover the dependencies between core performance indicators and generate a bottleneck localization report and optimization suggestion document based on the dependencies between core performance indicators and the anomaly detection results.

[0009] Secondly, this application provides a software performance testing method for high-concurrency scenarios, including: Based on business requirements parameters and historical traffic data, concurrent scenarios are generated through behavior tree modeling and time series prediction algorithms, and saved as scenario files; Based on the scenario file, a distributed test environment for the software under test is constructed using container orchestration technology; Based on the scenario file and the distributed test environment, coroutine pool technology is used to simulate concurrent user requests; During the simulation of concurrent user requests, multi-source performance data of the software under test are collected in real time. The core performance indicators are calculated based on the multi-source performance data, and machine learning algorithms are used to detect anomalies and predict trends in the core performance indicators to obtain anomaly detection results and trend prediction results. Discover the dependencies between core performance indicators, and generate a bottleneck location report and optimization suggestion document based on the dependencies between core performance indicators and the anomaly detection results.

[0010] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described software performance testing method under high concurrency scenarios.

[0011] According to the specific embodiments provided in this application, this application has the following technical effects: By using behavior tree modeling and time-series prediction algorithms, combined with business requirement parameters and historical traffic data, concurrent scenarios are generated, ensuring that the scenarios closely match actual application scenarios. This solves the problem of deviation between traditional fixed scripts and actual scenarios, improving the efficiency and accuracy of scenario construction. A distributed testing environment is built using container orchestration technology, which can quickly and elastically expand resources to adapt to high-concurrency testing needs of different scales, reducing environment deployment complexity and resource consumption, and improving the utilization rate of the testing environment. Concurrent user requests are simulated based on coroutine pool technology. Compared with traditional thread pools, it can support higher concurrency and lower resource consumption, realistically reproducing user access pressure under high-concurrency scenarios, ensuring the authenticity and stability of test pressure. Accurate anomaly detection and trend prediction of core performance indicators are achieved through machine learning algorithms, providing early warning of performance risks; at the same time, the dependencies between indicators are mined to accurately locate performance bottlenecks under high-concurrency scenarios, and optimization suggestion documents are generated, providing clear guidance for software performance optimization, significantly improving testing efficiency and optimization targeting, and ensuring the stable operation of software under high-concurrency scenarios. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of the functional modules of a software performance testing system in a high-concurrency scenario, provided as an embodiment of this application.

[0014] Figure 2 This is a schematic diagram of the scene intelligent construction module in one embodiment of this application.

[0015] Figure 3 This is a schematic diagram of the distributed test environment scheduling module in one embodiment of this application.

[0016] Figure 4 This is a schematic diagram of a virtual user load generation module in one embodiment of this application.

[0017] Figure 5 This is a schematic diagram of a real-time performance data acquisition module in one embodiment of this application.

[0018] Figure 6 This is a schematic diagram of the intelligent performance analysis module in one embodiment of this application.

[0019] Figure 7 This is a schematic diagram of a performance bottleneck location module in one embodiment of this application.

[0020] Figure 8 This application provides a flowchart of a software performance testing method in a high-concurrency scenario, based on one embodiment. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] In one exemplary embodiment, a software performance testing system for high-concurrency scenarios is provided. This system is deployed within a computer device and executed by the computer device's processor. Figure 1 As shown, the software performance testing system under high concurrency scenarios includes: a scenario intelligent construction module 101, a distributed test environment scheduling module 102, a virtual user load generation module 103, a real-time performance data acquisition module 104, an intelligent performance analysis module 105, a performance bottleneck location module 106, and a system operation and maintenance management module 107.

[0024] The scenario intelligence construction module 101 is used to generate concurrent scenarios based on business requirement parameters and historical traffic data through behavior tree modeling and time series prediction algorithms, and save them as scenario files. Specifically, the scenario intelligence construction module 101 transforms abstract business requirements into executable, high-fidelity concurrent test scenarios.

[0025] In a specific application example, such as Figure 2 As shown, the scene intelligent construction module 101 includes: a requirement parsing unit 201, a behavior modeling unit 202, a time sequence generation unit 203, and a scene verification unit 204.

[0026] The requirement parsing unit 201 receives business requirement parameters input by the user and extracts core test metrics using natural language processing algorithms. These business requirement parameters include business type, peak concurrency, request ratio, and data model. The requirement parsing unit 201 further constructs a dataset containing these business parameters; it supports three input methods: JSON, YAML, and visual forms, and automatically verifies the completeness and logical consistency of the parameters.

[0027] The behavior modeling unit 202 is used to construct a multi-level behavior tree model based on core test metrics. The root node of the multi-level behavior tree model is the business scenario type (e.g., flash sale scenario, payment scenario), the first-level child nodes are user roles (e.g., regular users, VIP users), the second-level child nodes are core operations (e.g., browsing products, placing orders, payment), and the leaf nodes are atomic behaviors (e.g., clicking a button, entering text). The probability distribution of different behaviors is achieved through request ratios, and custom behavior dependencies are supported (e.g., requiring login before placing an order).

[0028] The timing generation unit 203 generates request timing sequences based on historical traffic data using a Markov chain prediction model and simulates sudden traffic surges using a Poisson process to calculate the dynamic number of concurrent users. The request timing sequences include the dependency call relationships between various interfaces. The formula used is... Calculate the number of dynamically concurrent users. Among them, For dynamic concurrent users, Peak transaction volume The request frequency for each user, The average user thinking time is the interval between the completion of one operation and the start of the next.

[0029] The scenario verification unit 204 is used to generate concurrent scenarios based on the multi-level behavior tree model, the request timing sequence, and the dynamic concurrent user count, and to simulate the concurrent scenarios using a Monte Carlo simulation algorithm. Based on the simulation results, it determines whether the concurrent scenarios meet the preset accuracy requirements. If the preset accuracy requirements are not met, the multi-level behavior tree model and the request timing sequence are adjusted until the preset accuracy requirements are met, and then the concurrent scenarios are saved as scenario files.

[0030] Specifically, test elements such as multi-level behavior tree models, request timing sequences, and dynamic concurrent user counts are integrated and arranged to construct a complete and realistic high-concurrency test environment, thus obtaining the concurrent scenario. Scenario verification unit 204 uses a Monte Carlo simulation algorithm to pre-run the generated scenario, verifying the rationality of the scenario logic and the effectiveness of concurrency pressure. By comparing the deviation between the simulation results and the required indicators, it automatically adjusts the behavior weights and timing parameters until the preset accuracy requirements are met. Scenario verification unit 204 supports scenario template saving and reuse functions, and constructs a scenario template library according to business type.

[0031] The simulation results include runtime performance data such as system throughput, average response time, maximum response time, error rate, and resource utilization. Requirement metrics data: jointly developed by the business and technical teams.

[0032] The behavior weight adjustment strategy includes: (1) Increasing weight scenario: When the error rate of a certain type of user behavior simulation results is higher than the demand index, or its response time is too long and affects the overall throughput, the weight of the behavior needs to be increased to simulate more such behavior pressure and locate the performance bottleneck. (2) Decreasing weight scenario: If the simulation result of a certain behavior is much better than the demand index and has little impact on the overall performance, its weight can be reduced and resources can be focused on other weak links. (3) Weight adjustment step size: Dynamically set according to the degree of deviation. Generally, when the deviation is 10%~30%, the step size is set to 5%; when the deviation is >30%, the step size is set to 10% to avoid the adjustment range being too large and causing simulation distortion. (4) Timing parameter adjustment strategy: Shorten the timing interval: If the overall throughput of the system does not reach the demand index and the resource utilization rate is idle, the timing interval of user behavior triggering can be shortened to simulate a more compact operation rhythm. Extend the timing interval: When the system response time is too long or the error rate soars and the resource utilization rate is close to saturation, the timing interval is extended to alleviate the system pressure. Timing adjustment step size: Set according to the response time deviation. If the response time exceeds the requirement by less than 50%, the step size is set to 0.1 seconds; if it exceeds 50%, the step size is set to 0.2 seconds to ensure stable system pressure adjustment.

[0033] The distributed test environment scheduling module 102 is used to construct a distributed test environment for the software under test using container orchestration technology based on the scenario file. Specifically, the distributed test environment scheduling module 102 uses container orchestration technology to achieve elastic scaling and load balancing of test nodes, thereby constructing an elastic and scalable distributed test environment.

[0034] In a specific application example, such as Figure 3 As shown, the distributed test environment scheduling module 102 includes: a resource pool management unit 301, a container orchestration unit 302, an environment configuration unit 303, and a status monitoring unit 304.

[0035] The resource pool management unit 301 is used to determine the required resources based on the scenario file.

[0036] Specifically, the resource pool management unit 301 maintains a hybrid resource pool of physical machines and cloud servers, records node configuration information and real-time resource utilization, and adopts a hierarchical resource scheduling strategy, prioritizing the allocation of nodes with high idle rates. When resources are insufficient, it automatically triggers cloud server expansion. The node configuration information includes the number of CPU cores, memory capacity, network bandwidth, and storage type.

[0037] The container orchestration unit 302 is used to create corresponding container instances based on the required resources and deploy test nodes and the software under test.

[0038] Specifically, the container orchestration unit 302 implements containerized deployment of test nodes based on Kubernetes, supporting both Docker and Containerd container runtimes; it automatically calculates the required number of container instances based on the concurrency of the scenario, and implements the creation, updating and destruction of containers through the Deployment controller; it uses StatefulSet to ensure the deployment stability of stateful services (such as databases and caches), and manages container configuration and sensitive information through ConfigMap and Secret.

[0039] The environment configuration unit 303 is used to load the corresponding middleware configuration and application server configuration according to the scenario file to initialize the distributed test environment.

[0040] Specifically, the environment configuration unit 303 provides one-click environment deployment and version management functions, supports configuration mapping for test, pre-production, and production environments, has built-in configuration templates for mainstream middleware and application servers, supports custom configuration parameter overriding, and implements environment snapshot functionality, allowing for quick rollback to a specified configuration state. The middleware includes MySQL, Redis, Kafka, and Elasticsearch, while the application servers include Tomcat, Nginx, and Spring Boot.

[0041] The status monitoring unit 304 is used to detect the running status of the container instance in real time, and to perform container migration or restart when the running status of the container instance is abnormal.

[0042] Specifically, the status monitoring unit 304 collects the running status of container instances in real time and uses a health check mechanism to monitor service availability. The health check mechanism includes liveness probes and readiness probes. When node resource utilization exceeds the threshold or service is abnormal, container migration or restart is automatically triggered to ensure the stability of the test environment. The running status of container instances includes CPU utilization, memory usage, network I / O, disk I / O, etc.

[0043] The virtual user load generation module 103 is used to simulate concurrent user requests based on the scenario file and the distributed test environment using coroutine pool technology. Specifically, the virtual user load generation module 103 simulates large-scale concurrent user requests through coroutine pool technology, supporting both protocol-level and interface-level load injection.

[0044] In a specific application example, such as Figure 4As shown, the virtual user load generation module 103 includes: a script parsing unit 401, a coroutine management unit 402, a protocol adaptation unit 403, and a traffic control unit 404.

[0045] The script parsing unit 401 is used to parse the scene file and import test data.

[0046] Specifically, the script parsing unit 401 extracts virtual user behavior sequences and request parameters; it supports parameterized data configuration, importing test data via CSV, Excel, and database to achieve dynamic replacement of request parameters; it supports script breakpoint debugging, visually displaying the execution results of each step of the behavior. The process of importing test data is as follows: through log analysis, user behavior data is extracted from the historical operation logs of the real business system. After cleaning and filtering, a test dataset suitable for high-concurrency scenarios is constructed. The test dataset includes request parameters from actual user operations, directly mapped to the specific operation steps in the virtual user behavior sequence.

[0047] The coroutine management unit 402 is used to initialize the coroutine pool for virtual user simulation.

[0048] Specifically, the coroutine management unit 402 uses the Go language coroutine mechanism to implement lightweight virtual user simulation, which can support higher concurrency compared to the traditional thread model; it constructs a coroutine pool management model, pre-creates a fixed number of coroutines to reduce dynamic creation overhead, and achieves uniform distribution of requests through the coroutine scheduler; it supports virtual user group management, allocates different coroutine pools according to roles, and realizes differentiated load injection.

[0049] Protocol adaptation unit 403 is used to load protocol plugins corresponding to concurrent scenarios.

[0050] Specifically, the protocol adaptation unit 403 has built-in adaptation plugins for mainstream protocols such as HTTP / HTTPS, TCP / UDP, WebSocket, and gRPC, and supports performance testing of RESTful API, SOAP interface, and Dubbo service; it provides custom protocol extension interfaces and allows the development of new protocol adaptation plugins through the SDK; it implements request message construction and response parsing functions, and supports multiple data formats such as JSON, XML, and Protobuf.

[0051] The flow control unit 404 is used to inject load into the distributed test environment according to a preset load mode based on the test data, the coroutine pool and the protocol plugin, and adjust the load intensity in real time to simulate concurrent user requests.

[0052] Specifically, the traffic control unit 404 supports three load modes: tiered, pulsed, and constant-pressure. It achieves precise traffic control through the token bucket algorithm; it automatically distributes load pressure according to the number of nodes in the distributed test environment; it uses a consistent hashing algorithm to ensure the uniformity of request distribution; it monitors the load injection status in real time; and it automatically reduces the load intensity when the request failure rate exceeds the threshold to prevent the test environment from crashing.

[0053] The real-time performance data acquisition module 104 is used to collect multi-source performance data of the software under test in real time during the simulation of concurrent user requests. Specifically, the real-time performance data acquisition module 104 integrates edge computing and stream processing technologies to achieve low-latency acquisition and preprocessing of multi-source performance indicators.

[0054] In a specific application example, such as Figure 5 As shown, the real-time performance data acquisition module 104 includes: an acquisition agent unit 501, a data preprocessing unit 502, a transmission forwarding unit 503, and a storage management unit 504.

[0055] The data acquisition agent unit 501 is used to collect test metrics of the test nodes and the software under test in real time during the process of simulating concurrent user requests.

[0056] Specifically, the data acquisition agent unit 501 deploys a lightweight data acquisition agent on the test node and the software under test, supporting both active pull and passive push data acquisition modes. The test node is the carrier used to execute software performance testing tasks.

[0057] The test metrics include system-level metrics, application-level metrics, and middleware metrics. System-level metrics include: CPU utilization, memory usage, input / output operations per second (IOPS), network throughput, and the number of Transmission Control Protocol (TCP) connections. Application-level metrics include: response time, request success rate, error code distribution, and API call frequency; response time includes average response time, 95% response time, and 99% response time. Middleware metrics include: database query latency, cache hit rate, message queue backlog, and service registry health status.

[0058] The data preprocessing unit 502 is used to perform data cleaning on the test indicators at the acquisition end using edge computing methods, and to calculate the performance fluctuation coefficient to obtain multi-source performance data. The multi-source performance data includes the data-cleaned performance indicators and the performance fluctuation coefficient.

[0059] Specifically, the data preprocessing unit 502 uses edge computing technology to perform data cleaning and aggregation at the acquisition end, removing outliers and duplicate data; it downsamples the time-series data and uses a sliding window algorithm to calculate minute-level and hourly aggregated indicators. The aggregated indicators include the average, maximum, minimum, and standard deviation. These are calculated using formulas. Calculate the performance fluctuation coefficient to quantify the stability of the indicator. Among these, For performance fluctuation coefficient, The standard deviation of the time series data of the indicator. This represents the average value of the time-series data for the indicator. The smaller the value, the more stable the performance indicator.

[0060] The transmission forwarding unit 503 is used to send the multi-source performance data to different topics of Kafka according to the indicator type, and to encrypt and transmit the multi-source performance data to the storage system.

[0061] Specifically, the transmission and forwarding unit 503 uses Kafka as a message middleware to achieve high-throughput data transmission, divides different topics according to indicator types, and supports data partitioning and storage; it implements a data transmission reliability guarantee mechanism, adopts a message confirmation mechanism and retry strategy to ensure that data is not lost; and it supports encrypted transmission function, protecting data transmission security through SSL / TLS protocol.

[0062] Storage management unit 504 is used to manage the storage system using a hybrid storage architecture.

[0063] Specifically, performance metrics data are stored in time-series databases (InfluxDB, Prometheus), test metadata is stored in relational databases (MySQL, PostgreSQL), and raw log data is stored in a distributed file system (Hadoop Distributed File System, HDFS), enabling data lifecycle management, automatic data archiving according to test tasks, and support for custom data retention duration.

[0064] The intelligent performance analysis module 105 is used to calculate core performance indicators based on the multi-source performance data, and to use machine learning algorithms to perform anomaly detection and trend prediction on the core performance indicators, thereby obtaining anomaly detection results and trend prediction results.

[0065] In a specific application example, such as Figure 6 As shown, the intelligent performance analysis module 105 includes: a feature extraction unit 601, an index calculation unit 602, an anomaly detection unit 603, and a trend prediction unit 604.

[0066] The feature extraction unit 601 is used to extract features from the multi-source performance data to obtain performance data features.

[0067] Specifically, the feature extraction unit 601 further employs principal component analysis to reduce feature dimensionality, retaining key features to improve subsequent analysis efficiency. Performance data features include statistical features, time-series features, and correlation features. Statistical features include mean, variance, and quantiles. Time-series features include trend, periodicity, and stationarity. Correlation features are the correlation coefficients between indicators. Trend in time-series features can be determined by fitting the time series data using the least squares method and calculating the slope of the fitted line. Periodicity is determined using Fourier transform or spectral analysis to identify frequencies of concentrated energy in the data. Stationarity is determined using the Augmented Dickey-Fuller Test (ADF); rejecting the null hypothesis indicates stationarity. The correlation coefficients between indicators in the correlation features can be calculated using the Pearson correlation coefficient.

[0068] The indicator calculation unit 602 is used to calculate core performance indicators based on the performance data characteristics.

[0069] Specifically, the indicator calculation unit 602 supports custom indicator calculation rules and allows configuration of indicator formulas through SQL or scripting languages; it enables real-time calculation and updating of indicators, and the calculation results are synchronized to the visualization display module.

[0070] Key performance metrics include concurrent users, throughput (TPS / QPS), response time, error rate, and resource utilization.

[0071] The calculation method for concurrent users is as follows: User behavior is simulated using performance testing tools, with requests being sent to the software under test simultaneously. The number of active virtual users counted by the tool is the concurrent user count. Alternatively, log analysis can be used to count the number of unique user identifiers received by the software under test per unit time. The number of concurrent users directly affects throughput, response time, and resource utilization. When the number of concurrent users increases, if the processing capacity of the software under test is insufficient, it will lead to longer response times, increased resource utilization, and may also cause request queuing, reduced throughput, or even errors. System-level metrics such as CPU and memory usage will increase with the number of concurrent users; application-level metrics such as thread pool utilization and database connection count are also closely related to the number of concurrent users; the connection count and request queue length of middleware such as web servers are also affected.

[0072] Throughput includes Transactions Per Second (TPS) and Queries Per Second (QPS). TPS refers to a series of operations that complete a specific business function, such as user login and order placement. TPS = Total Transactions / Test Time. QPS is commonly used to measure database or API query performance; QPS = Total Queries / Test Time. Throughput is constrained by network bandwidth and disk I / O speed at the system layer. Insufficient bandwidth or slow disk read / write speeds limit data transmission and processing speed, reducing throughput. Application layer code execution efficiency and algorithm complexity affect the processing speed of transactions or queries, thus impacting throughput. The processing capacity of middleware, such as Tomcat's thread processing capacity, also directly determines the number of requests that can be handled. Response time is inversely proportional to throughput; the longer the response time, the fewer transactions or queries are processed per unit of time, resulting in lower throughput. An increased error rate may be due to system overload causing some requests to fail to process normally, thus affecting throughput.

[0073] Response time is calculated as the time interval from when the client initiates a request to when it receives a response from the server. Performance testing tools can directly record the response time for each request and calculate statistical data such as average, maximum, and minimum values. Response time is closely related to the number of concurrent users, throughput, and resource utilization. An increase in the number of concurrent users will strain system resources, leading to a longer response time; a decrease in throughput may be due to an increase in response time, indicating a decrease in the efficiency of the software under test in processing requests; excessively high utilization of system-level resources such as CPU, memory, and disk I / O can affect the execution speed of the application and prolong response time; complex application-level code logic and slow database queries can also increase response time; improper middleware configuration, such as an inappropriate thread pool size setting, can cause requests to queue and wait, lengthening the response time.

[0074] The error rate is calculated as follows: Error Rate = (Number of erroneous requests / Total number of requests) × 100%. Erroneous requests include unexpected status codes returned by the server (such as 500, 404), request timeouts, and business logic errors. The error rate is a crucial indicator of system stability and reliability. Insufficient system-level resources (such as memory overflow or 100% CPU usage) can trigger numerous errors. Vulnerabilities in application-level code and database connection anomalies can lead to failed business requests, increasing the error rate. Middleware misconfiguration or performance bottlenecks can also generate errors. An increased error rate reduces throughput because erroneous requests need to be reprocessed or discarded, affecting the system's ability to effectively handle requests. Furthermore, erroneous requests may consume system resources, further impacting response time and resource utilization.

[0075] Resource utilization includes CPU utilization, memory utilization, disk I / O utilization, and network utilization. CPU utilization = (CPU busy time / total time) × 100%, which can be obtained through operating system commands (such as top, taskmanager). Memory utilization = (used memory / total memory) × 100%. Disk I / O utilization is the proportion of disk busy time to total time or the amount of data read / written by the disk per unit time. Network utilization = (actual network traffic / network bandwidth) × 100%. Resource utilization is a key indicator for measuring system performance bottlenecks. Excessive utilization of resources such as CPU and memory can lead to decreased system processing power, longer response times, reduced throughput, and may also cause errors. For example, high CPU utilization may cause application threads to block, increasing response time; insufficient memory may lead to frequent garbage collection, affecting application performance, and even causing memory overflow errors. The complexity of application-layer business logic and the frequency of database operations affect system resource consumption; the configuration and performance of middleware also affect resource utilization efficiency. Proper middleware configuration can optimize resource utilization and improve overall system performance.

[0076] The anomaly detection unit 603 is used to perform anomaly detection on the core performance indicators using a dual detection mechanism based on rules and machine learning. When an anomaly is detected, the anomaly period and related indicators are marked to obtain the anomaly detection result.

[0077] Specifically, the anomaly detection unit 603 integrates rule-based and machine learning-based dual detection mechanisms. The rule base includes static thresholds (such as CPU utilization > 80%), dynamic thresholds (adaptive thresholds calculated based on historical data), and composite rules (such as increased response time and increased error rate). It uses the isolated forest algorithm to detect unknown anomalies and trains the model with historical anomaly data to improve detection accuracy. When an anomaly is detected, it automatically marks the anomaly period and related indicators.

[0078] When using the Isolation Forest algorithm, the input consists of massive amounts of time-series data generated during software performance testing in high-concurrency scenarios, including real-time monitoring data of metrics such as response time, throughput, and resource utilization. The output consists of sample data identified as anomalous and their corresponding anomalous scores; a higher score indicates a greater likelihood that the sample is anomalous. In practice, the Isolation Forest algorithm recursively divides the dataset into subsets by randomly selecting an attribute and a split value for that attribute, constructing multiple isolation trees. During this partitioning process, normal data points are typically isolated deeper within the trees, while anomalous data points, due to their significant differences from the majority of data, are quickly isolated at shallower levels. Finally, by calculating the average path length of each data point across the multiple isolation trees and combining this with the tree height, an anomalous score is derived, which is used to determine whether the data is anomalous.

[0079] The trend prediction unit 604 is used to predict the trend of indicator changes in the future period based on historical performance data and current load pressure using a performance trend prediction model, obtain the trend prediction result, and issue a performance warning when the indicator change trend exceeds the warning threshold; the performance trend prediction model is constructed based on a long short-term memory network.

[0080] Specifically, the trend prediction unit 604 constructs a performance trend prediction model based on a long short-term memory network. It takes historical performance data and current load pressure as input and predicts the trend of indicator changes over a period of time. It supports the visualization of prediction results, presenting the predicted value and confidence interval of the indicator through a line chart. When the predicted value exceeds the warning threshold, it triggers a performance warning in advance.

[0081] The performance bottleneck localization module 106 is used to mine the dependencies between core performance indicators, and generate a bottleneck localization report and optimization suggestion document based on the dependencies between core performance indicators and the anomaly detection results. Specifically, the performance bottleneck localization module 106 establishes indicator dependencies through association rule mining, generates a bottleneck localization report, and provides optimization suggestions.

[0082] In a specific application example, such as Figure 7 As shown, the performance bottleneck location module 106 includes: a bottleneck association unit 701, a root cause analysis unit 702, an impact assessment unit 703, and an optimization suggestion unit 704.

[0083] The bottleneck association unit 701 is used to analyze the dependencies between core performance indicators using association rule mining algorithms (such as the Apriori algorithm) and construct an indicator association graph. For example, when it is found that "increased database query latency" and "soaring CPU utilization" frequently occur simultaneously, a strong association relationship between the two is established; it supports manual adjustment of association weights and incorporates expert experience to optimize association results.

[0084] The root cause analysis unit 702 is used to locate the root cause of the bottleneck and determine the core bottleneck point by employing a causal inference algorithm based on the indicator correlation map and the anomaly detection results. Specifically, starting from the abnormal indicators, it traces the changes of upstream related indicators, eliminates indirect influencing factors, and determines the core bottleneck point.

[0085] The root cause analysis unit 702 supports automatic bottleneck classification, including resource bottlenecks, code bottlenecks, and architectural bottlenecks. Resource bottlenecks include CPU, memory, disk, and network; code bottlenecks include slow queries, memory leaks, and thread blocking; and architectural bottlenecks include poor interface design and inappropriate caching strategies.

[0086] The impact assessment unit 703 is used to quantify the degree of impact of the core bottleneck on the performance of the software under test, and generate a bottleneck location report based on the core bottleneck and the degree of impact.

[0087] Specifically, using the formula Quantify the impact of core bottlenecks on the performance of the software under test. Among them, The overall impact of the bottleneck is represented by a value between 0 and 1, with the value closer to 1 indicating a greater impact. The weights are the combined weights of resource bottlenecks, code bottlenecks, architectural bottlenecks, and response time. ; As a weight for resource utilization rate, As a weight for code complexity, Weights for architectural defects For response time weighting, ; As for the current resource utilization rate, For normal resource utilization, To achieve saturated resource utilization, This is a metric for the current code complexity. This is a normal code complexity metric. For the maximum acceptable code complexity, The number of defects in the current architecture. This represents the number of defects in a normal architecture. This represents the maximum number of architectural defects the system can tolerate. This is the current response time. This is the normal response time.

[0088] The optimization suggestion unit 704 is used to match optimization suggestions from a pre-built knowledge base based on the type of core bottleneck and the degree of impact of the core bottleneck on the performance of the software under test, and generate an optimization suggestion document.

[0089] Specifically, the optimization suggestion unit 704 matches optimization suggestions from the knowledge base based on bottleneck type and impact assessment results. It supports suggestion priority ranking, scores suggestions based on implementation cost and optimization effect, and provides a performance comparison function before and after optimization to verify the optimization effect. The knowledge base covers resource expansion solutions, code optimization techniques, architecture adjustment strategies, configuration parameter optimization, and other content.

[0090] The system operation and management module 107 is used for user permission control, test task scheduling and system status monitoring to ensure the standardized execution of the test process.

[0091] In a specific application example, the system operation and maintenance management module 107 includes a user permission unit, a task scheduling unit, a log management unit, and a system configuration unit.

[0092] The user permission unit employs a role-based access control (RBAC) model for permission management, supporting three roles: administrator, test engineer, and viewer. It manages user accounts (creation, modification, deletion, and disabling) and password security policies (complexity requirements, periodic changes). Administrators have full system access, test engineers can create and execute test tasks, and viewers can only view test results.

[0093] The task scheduling unit supports manual triggering and scheduled scheduling of test tasks. Scheduled scheduling allows setting the execution cycle by minute, hour, day, week, and month. It enables task dependency configuration and supports both serial and parallel execution modes. It provides task queue management functions, displaying the status of tasks that are pending, in execution, completed, or failed, and supports task pause, termination, and retry.

[0094] The log management unit collects operational logs from various modules of the system, including operation logs (user login, task creation, configuration modification), business logs (scenario generation, load injection, data collection), and error logs (exception stack traces, error causes). It supports log retrieval by module, level, and time range, and enables log export and backup functions. It uses log analysis algorithms to identify system operational anomalies and provide early warnings of potential problems.

[0095] The system configuration unit provides global system configuration functions, including collection frequency, storage policy, early warning threshold, email notification configuration, etc.; it supports version management and rollback of configuration parameters and records the configuration modification history; it realizes system health status monitoring, displays the usage of resources such as CPU, memory, disk, and network, and sends alarm notifications when resource utilization exceeds the threshold.

[0096] Based on the same inventive concept, this application also provides a method for implementing the system described above. The solution provided by this method is similar to the solution described in the system above; therefore, specific limitations in one or more method embodiments provided below can be found in the system limitations described above, and will not be repeated here.

[0097] The software performance testing method for high-concurrency scenarios provided in this application can be implemented independently by a server or a terminal. For example... Figure 8 As shown, the software performance testing method under high concurrency scenarios includes the following steps 801 to 807.

[0098] Step 801: Based on business requirement parameters and historical traffic data, generate concurrent scenarios using behavior tree modeling and time series prediction algorithms, and save them as scenario files.

[0099] Specifically, the parsing unit receives user-inputted business requirement parameters, extracts and validates core test metrics. The behavior modeling unit 202 constructs a multi-level behavior tree model, configuring behavior weights and dependencies. The time-series generation unit 203 combines historical traffic data with a Markov chain prediction model to generate request time-series sequences and calculates the dynamic number of concurrent users. The scenario verification unit 204 uses Monte Carlo simulation to verify the scenario's rationality, automatically adjusting parameters until the requirements are met, and finally saves the scenario configuration, generating an executable scenario file.

[0100] Step 802: Based on the scenario file, construct a distributed test environment for the software under test using container orchestration technology.

[0101] Specifically, the scenario file is received by the distributed test environment scheduling module 102. The required resources are evaluated by the resource pool management unit 301. Container instances are created by the container orchestration unit 302 based on the resource evaluation results, and test nodes and the software under test are deployed. The corresponding middleware configuration and application server configuration are loaded by the environment configuration unit 303 to complete environment initialization. Environment monitoring is started by the status monitoring unit 304 to confirm that all nodes and services are running normally.

[0102] Step 803: Based on the scenario file and the distributed test environment, use coroutine pool technology to simulate concurrent user requests.

[0103] Specifically, the script parsing unit 401 parses the scenario file and processes virtual user behaviors and parameters. The coroutine management unit 402 initializes the coroutine pool. The protocol adaptation unit 403 loads the corresponding protocol plugin. The traffic control unit 404 injects load according to a preset load mode and adjusts the load intensity in real time.

[0104] Step 804: During the simulation of concurrent user requests, collect multi-source performance data of the software under test in real time.

[0105] Specifically, a data acquisition agent is deployed through the data acquisition agent unit 501 to collect metrics from the system layer, application layer, and middleware layer. The data is cleaned and aggregated through the data preprocessing unit 502. Finally, the data is stored in the corresponding database through the transmission and forwarding unit 503.

[0106] Step 805: Calculate core performance indicators based on the multi-source performance data, and use machine learning algorithms to perform anomaly detection and trend prediction on the core performance indicators to obtain anomaly detection results and trend prediction results.

[0107] Specifically, the feature extraction unit 601 extracts performance data features. The indicator calculation unit 602 calculates core performance indicators. The anomaly detection unit 603 uses rule-based and machine learning algorithms to detect anomalies and mark abnormal periods. The trend prediction unit 604 constructs a performance trend prediction model to predict the changing trends of performance indicators, trigger performance alerts, generate real-time performance analysis reports, and synchronize them to the visualization platform for display.

[0108] Step 806: Discover the dependencies between core performance indicators, and generate a bottleneck location report and optimization suggestion document based on the dependencies between core performance indicators and the anomaly detection results.

[0109] Specifically, the bottleneck association unit 701 constructs an indicator association graph to uncover the dependencies between indicators. The root cause analysis unit 702 traces the root causes of anomalies and classifies and identifies bottleneck types. The impact assessment unit 703 calculates the bottleneck impact degree to quantify the impact of the bottleneck on the software under test. The optimization suggestion unit 704 matches the knowledge base to generate priority-ranked optimization suggestions and outputs a bottleneck location report and optimization suggestion document.

[0110] Step 807: Test summary and environment cleanup.

[0111] Specifically, the system operation and management module 107 summarizes the test results and generates a complete performance test report, including scenario configuration, environment information, performance indicators, anomaly analysis, bottleneck location, and optimization suggestions. Users view the test report to confirm whether the test results meet the requirements. The distributed test environment scheduling module 102 destroys container instances to release test resources. The log management unit archives test logs and data, completing the test process.

[0112] This application also provides an application scenario in which the software performance testing system for high concurrency scenarios described above is applied. Specifically: The software performance testing system for high concurrency scenarios provided in this embodiment can be applied to the testing of e-commerce software, and its testing process includes the following steps (1) to (6).

[0113] (1) Scenario construction and verification.

[0114] (11) Users input their needs for the flash sale scenario through a visual form. The requirement analysis unit 201 extracts the core test indicators: 100,000 concurrent users, 10:3:1 request ratio, burst traffic characteristics, response time <500ms, and success rate >99.9%.

[0115] (12) Behavior modeling unit 202 constructs behavior tree: the root node is "flash sale scenario", the first-level child node is "ordinary user", the second-level child nodes include "product browsing", "order placement" and "payment", and the leaf nodes are specific atomic behaviors; configure "product browsing" weight 10, "order placement" weight 3, "payment" weight 1, and set "order placement" to depend on "product browsing" and "payment" to depend on "order placement".

[0116] (13) The timing generation unit 203 imports the historical traffic data of the flash sale activities in the past 3 months, generates the request timing through the Markov chain, and uses the Poisson process to simulate the burst traffic of 5 seconds, according to the formula Calculate the number of dynamically concurrent users, where, =100,000 =0.5 times / second =2 seconds, calculated as follows ≈83,000, adjust parameters to 100,000.

[0117] (14) The scenario verification unit 204 Monte Carlo simulation pre-run found that the response time exceeded the standard under sudden traffic. The weight of "product browsing" was automatically adjusted to 8, cache query behavior was added, and the scenario template was saved after re-simulation to meet the requirements.

[0118] (2) Deployment of the test environment.

[0119] (21) The distributed test environment scheduling module 102 receives the scenario file, and the resource pool management unit 301 evaluates that 50 test nodes are needed.

[0120] (22) Container orchestration unit 302 creates 50 load generation containers, 1 control container and 3 data acquisition containers using Kubernetes; it deploys Redis and MySQL test environments using StatefulSet and configures Nginx load balancing strategies using ConfigMap.

[0121] (23) Environment configuration unit 303 loads the middleware configuration corresponding to the flash sale scenario: Redis sets the product inventory cache expiration time, MySQL configures master-slave replication, and RabbitMQ sets the order message queue.

[0122] (24) The status monitoring unit 304 detected abnormal CPU utilization on two nodes, automatically restarted the container, and confirmed that all node services were normal.

[0123] (3) Load injection and data acquisition.

[0124] (31) The virtual user load generation module 103 parses the scene file, and the script parsing unit 401 imports parameterized data such as product ID and user account.

[0125] (32) The coroutine management unit 402 initializes 50 coroutine pools, each with 2,000 coroutines, for a total of 100,000 coroutines simulating virtual users.

[0126] (33) Protocol adaptation unit 403 loads the HTTP protocol plugin and constructs product browsing, order placement and payment messages.

[0127] (34) The flow control unit 404 adopts a pulse load mode, which increases the concurrency to 100,000 in a stepwise manner for the first 5 seconds, and then maintains constant pressure; the flow is controlled by the token bucket algorithm, and the load is evenly distributed among 50 nodes.

[0128] (35) The data collection agent unit 501 is deployed on each service node and test node of the software under test. The data collection indicators are: system layer (CPU, memory, network throughput), application layer (response time, success rate, error code), middleware layer (Redis hit rate, MySQL query latency, RabbitMQ backlog).

[0129] (36) Data preprocessing unit 502 cleans the data, removes outliers caused by network jitter, calculates the average response time using a 1-minute sliding window, and uses the formula... Calculate the response time fluctuation coefficient.

[0130] (37) The transmission and forwarding unit 503 sends the data to different Kafka Topics according to the index type and transmits it to the storage system in encrypted form.

[0131] (4) Performance analysis and anomaly detection.

[0132] (41) Intelligent performance analysis module 105 extracts features: mean response time 420ms, standard deviation 80ms, 95th percentile 510ms, and mean CPU utilization 75%.

[0133] (42) Real-time calculation of indicator calculation unit 602: QPS 80,000 / second, order response time 480ms, payment success rate 99.8%, Redis hit rate 92%.

[0134] (43) Anomaly detection unit 603 triggers dynamic threshold alarm: payment success rate is lower than 99.9%, and the abnormal period is marked as the 10th to 15th minute.

[0135] (44) Trend prediction unit 604LSTM model prediction: If it continues to run for 1 hour, the payment success rate will drop to 99.5%, triggering an early warning.

[0136] (5) Bottleneck identification and optimization suggestions.

[0137] (51) Bottleneck association unit 701 mining association rules: “Payment success rate decline” is strongly associated with “RabbitMQ backlog increase” and “MySQL query delay increase”.

[0138] (52) Root cause analysis unit 702 traced back: The increased backlog of RabbitMQ caused delays in order status updates, and slow MySQL queries (the SQL query for payment orders was not indexed) exacerbated the delays, which was determined to be a dual bottleneck of middleware and code.

[0139] (53) Impact assessment unit 703 calculates the degree of impact: =0.4, =0.6, =85%, =60%, =100%, =550ms, =450ms, then ≈0.48, with a moderate impact.

[0140] (54) Optimize the 704 matching scheme of the recommended unit: 1. Add consumer instances to RabbitMQ; 2. Add SQL index for payment order query in MySQL; 3. Add Redis order status cache; Sort by optimization effect and generate a recommendation report.

[0141] (6) Test summary and environmental cleanup.

[0142] (61) The system generates a test report, including: scenario configuration, environment information, performance indicators, anomaly analysis, bottleneck location results and optimization suggestions.

[0143] (62) The user confirms the test results and believes that optimization is needed before retesting.

[0144] (63) Distributed test environment scheduling module 102 destroys 50 test node containers and releases cloud server resources.

[0145] (64) The log management unit archives test logs and performance data and retains them for 3 months.

[0146] This application accurately reproduces user behavior patterns and traffic characteristics under high concurrency by combining behavior tree modeling and time-series prediction algorithms with dynamic concurrent user count calculation, solving the problem of discrepancies between traditional fixed scripts and actual scenarios. It employs container orchestration and elastic scaling technology to achieve dynamic allocation and reclamation of test nodes, automatically adjusting resource scale according to load pressure to avoid the dual dilemma of resource waste and insufficient load. It integrates edge computing and stream processing technologies to complete data preprocessing at the acquisition end, ensuring low-latency processing of massive amounts of data through a high-throughput transmission mechanism, providing support for real-time monitoring and anomaly detection. Based on association rule mining and causal inference algorithms, it establishes dependencies between indicators, achieving automated location and classification of bottleneck root causes. Combined with quantitative impact assessment, it significantly reduces the cost of manual analysis.

[0147] In one exemplary 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 steps in the above-described method embodiments.

[0148] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0149] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0150] 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, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0151] Those skilled in the art will understand that all or part of the processes in 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. When executed, the computer program can include the processes of the embodiments described above. 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).

[0152] 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, etc., and are not limited to these.

[0153] 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.

[0154] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A software performance testing system for high-concurrency scenarios, characterized in that, The system includes: The scene intelligence construction module is used to generate concurrent scenes based on business requirement parameters and historical traffic data through behavior tree modeling and time series prediction algorithms, and save them as scene files; The distributed test environment scheduling module is used to construct a distributed test environment for the software under test using container orchestration technology based on the scenario file. The virtual user load generation module is used to simulate concurrent user requests based on the scenario file and the distributed test environment using coroutine pool technology. The real-time performance data acquisition module is used to collect multi-source performance data of the software under test in real time during the process of simulating concurrent user requests. The intelligent performance analysis module is used to calculate core performance indicators based on the multi-source performance data, and to use machine learning algorithms to perform anomaly detection and trend prediction on the core performance indicators, so as to obtain anomaly detection results and trend prediction results. The performance bottleneck localization module is used to discover the dependencies between core performance indicators and generate a bottleneck localization report and optimization suggestion document based on the dependencies between core performance indicators and the anomaly detection results.

2. The software performance testing system for high-concurrency scenarios according to claim 1, characterized in that, The scene intelligent construction module includes: The requirement parsing unit is used to receive business requirement parameters input by the user and extract core test indicators using natural language processing algorithms. The behavior modeling unit is used to build a multi-level behavior tree model based on core test metrics. The time series generation unit is used to generate request time series based on historical traffic data using a Markov chain prediction model, and to simulate sudden traffic surges using a Poisson process to calculate the dynamic number of concurrent users. The scenario verification unit is used to generate concurrent scenarios based on the multi-level behavior tree model, the request timing sequence, and the dynamic number of concurrent users, and to simulate the concurrent scenarios using a Monte Carlo simulation algorithm. Based on the simulation results, it determines whether the concurrent scenarios meet the preset accuracy requirements. If the preset accuracy requirements are not met, the multi-level behavior tree model and the request timing sequence are adjusted until the preset accuracy requirements are met, and then the concurrent scenarios are saved as scenario files.

3. The software performance testing system for high-concurrency scenarios according to claim 1, characterized in that, The distributed test environment scheduling module includes: The resource pool management unit is used to determine the required resources based on the scenario file. The container orchestration unit is used to create corresponding container instances based on the required resources and deploy test nodes and the software under test. The environment configuration unit is used to load the corresponding middleware configuration and application server configuration according to the scenario file to initialize the distributed test environment; The status monitoring unit is used to detect the running status of the container instance in real time, and to perform container migration or restart when the running status of the container instance is abnormal.

4. The software performance testing system for high-concurrency scenarios according to claim 1, characterized in that, The virtual user load generation module includes: The script parsing unit is used to parse the scene file and import test data; The coroutine management unit is used to initialize the coroutine pool for virtual user simulation. The protocol adaptation unit is used to load protocol plugins corresponding to concurrent scenarios. The traffic control unit is used to inject load into the distributed test environment according to a preset load mode based on the test data, the coroutine pool, and the protocol plugin, and adjust the load intensity in real time to simulate concurrent user requests.

5. The software performance testing system for high-concurrency scenarios according to claim 1, characterized in that, The real-time performance data acquisition module includes: The data acquisition agent unit is used to collect test metrics of test nodes and the software under test in real time during the process of simulating concurrent user requests. The data preprocessing unit is used to perform data cleaning on the test indicators at the acquisition end using edge computing methods, and to calculate the performance fluctuation coefficient to obtain multi-source performance data; the multi-source performance data includes the data-cleaned performance indicators and the performance fluctuation coefficient.

6. The software performance testing system for high-concurrency scenarios according to claim 5, characterized in that, The real-time performance data acquisition module also includes: The transmission and forwarding unit is used to send the multi-source performance data to different Topic storages of Kafka according to the indicator type, and to encrypt and transmit the multi-source performance data to the storage system. A storage management unit for managing the storage system using a hybrid storage architecture.

7. The software performance testing system for high-concurrency scenarios according to claim 1, characterized in that, The intelligent performance analysis module includes: A feature extraction unit is used to extract features from the multi-source performance data to obtain performance data features; The indicator calculation unit is used to calculate core performance indicators based on the performance data characteristics. An anomaly detection unit is used to perform anomaly detection on the core performance indicators using a dual detection mechanism based on rules and machine learning. When an anomaly is detected, the anomaly period and related indicators are marked to obtain the anomaly detection result. The trend prediction unit is used to predict the trend of indicator changes in the future period based on historical performance data and current load pressure using a performance trend prediction model, obtain the trend prediction result, and issue a performance warning when the indicator change trend exceeds the warning threshold; the performance trend prediction model is constructed based on a long short-term memory network.

8. The software performance testing system for high-concurrency scenarios according to claim 1, characterized in that, The performance bottleneck localization module includes: The bottleneck association unit is used to analyze the dependencies between core performance indicators using association rule mining algorithms and to construct an indicator association graph. The root cause analysis unit is used to locate the root cause of the bottleneck and determine the core bottleneck point based on the index correlation map and the anomaly detection results using a causal inference algorithm. The impact assessment unit is used to quantify the degree of impact of the core bottleneck on the performance of the software under test, and generate a bottleneck location report based on the core bottleneck and the degree of impact. The optimization suggestion unit is used to match optimization suggestions from a pre-built knowledge base based on the type of core bottleneck and the degree of impact of the core bottleneck on the performance of the software under test, and generate an optimization suggestion document.

9. A software performance testing method under high concurrency scenarios, characterized in that, The method is applied to the software performance testing system under high concurrency scenarios as described in any one of claims 1-8, and the method includes: Based on business requirements parameters and historical traffic data, concurrent scenarios are generated through behavior tree modeling and time series prediction algorithms, and saved as scenario files; Based on the scenario file, a distributed test environment for the software under test is constructed using container orchestration technology; Based on the scenario file and the distributed test environment, coroutine pool technology is used to simulate concurrent user requests; During the simulation of concurrent user requests, multi-source performance data of the software under test are collected in real time. The core performance indicators are calculated based on the multi-source performance data, and machine learning algorithms are used to detect anomalies and predict trends in the core performance indicators to obtain anomaly detection results and trend prediction results. Discover the dependencies between core performance indicators, and generate a bottleneck location report and optimization suggestion document based on the dependencies between core performance indicators and the anomaly detection results.

10. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the software performance testing method for high-concurrency scenarios as described in claim 9.

Images