Method, device, equipment and product for constructing pressure measurement scene based on artificial intelligence

Abstract

The invention discloses a method, device, equipment and product for constructing a pressure measurement scene based on artificial intelligence, and the method comprises the steps: predicting the reference pressure measurement flow of a target interface through a flow prediction model based on a target pressure measurement constraint; based on the system design architecture information and / or the interface upstream and downstream dependency information, constructing a calling relation topological graph taking the target interface as a starting point; inputting the calling relation topological graph, the reference pressure measurement flow, the historical flow data of each node and the historical calling frequency data of each edge into a trained graph neural network model; and generating a linkage pressure measurement flow model of the target interface and upstream and downstream interfaces of the target interface based on the reference pressure measurement flow, the weight of each node in the calling relation topological graph output by the graph neural network model and the key calling path. According to the embodiment of the invention, the pressure measurement scene which truly reflects the service calling link can be automatically constructed, and the linkage pressure measurement model which accords with the actual service flow distribution is generated.

Description

Technical Field

[0001] This application relates to the field of software testing technology, particularly the intersection of stress testing and artificial intelligence, and especially to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for constructing stress testing scenarios based on artificial intelligence. Background Technology

[0002] Internet applications, exemplified by online recruitment platforms, commonly employ complex microservice architectures. These platforms handle core functionalities such as resume search, job recommendations, online application submissions, and instant messaging, involving hundreds of microservice interfaces. These interfaces are deeply interdependent; for example, a simple resume search request might sequentially or in parallel call multiple downstream interfaces, including user authentication, enterprise information verification, the Elasticsearch search cluster, and intelligent recommendation services, forming a complete call chain.

[0003] Load testing on such complex systems is crucial for ensuring system stability during peak recruitment periods. However, traditional load testing methods have the following shortcomings when dealing with microservice architectures: testers often only perform isolated load testing on single core interfaces such as resume search, or simply mix traffic from several interfaces according to experience. This approach ignores the complete call chain triggered by user operations in real business scenarios, resulting in a discrepancy between the load testing scenario and the actual business flow. The direct consequence is the inability to discover chained performance bottlenecks caused by service dependencies. For example, a previously unnoticed underlying service might unexpectedly become a bottleneck during load testing because it is called by multiple upstream interfaces; or the load testing traffic might fail to reproduce the real call topology, leading to overly optimistic performance assessments of complex transaction interfaces such as resume submission. Such distorted test results cannot accurately predict the system's performance under real high-concurrency scenarios, creating potential risks to platform stability. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method, apparatus, electronic device, computer-readable storage medium, and computer program product for constructing stress testing scenarios based on artificial intelligence, to solve at least one of the above-mentioned technical problems.

[0005] In a first aspect, embodiments of this application provide a method for constructing a stress testing scenario based on artificial intelligence, including: Obtain the target load testing constraints, system design architecture information, and / or upstream and downstream dependency information of the target interface; Based on the target load test constraints, the baseline load test traffic of the target interface is predicted using a trained traffic prediction model; Based on system design architecture information and / or upstream and downstream interface dependency information, a call relationship topology graph is constructed with the target interface as the starting point; wherein, the call relationship topology graph includes the target interface and its upstream and downstream interfaces, the nodes in the call relationship topology graph represent interfaces, and the edges represent call relationships; The call relationship topology graph, benchmark load test traffic, historical traffic data of each node, and historical call frequency data of each edge are input into the trained graph neural network model. The graph neural network model is used to analyze and infer the key call paths and traffic hotspot distribution in the call relationship topology graph, and adjust the weight of each node in the call relationship topology graph according to the key call paths and traffic hotspot distribution. Based on the baseline load test traffic, the weights of each node in the call relationship topology graph, and the key call paths, a linked load test traffic model is generated for the target interface and its upstream and downstream interfaces. The linked load test traffic model is configured with an execution strategy that uses the baseline load test traffic as the starting traffic and distributes the pressure to the upstream and downstream interfaces in the call relationship topology graph in a proportional and sequential manner. The linked load test traffic model is used to perform load testing on the target interface and its upstream and downstream interfaces.

[0006] Secondly, embodiments of this application provide an apparatus for constructing stress testing scenarios based on artificial intelligence, comprising: The acquisition unit is used to acquire the target stress test constraints, system design architecture information and / or interface upstream and downstream dependency information of the target interface; The traffic prediction unit is used to predict the baseline load test traffic of the target interface based on the target load test constraints and through a trained traffic prediction model. The topology graph construction unit is used to construct a call relationship topology graph starting from the target interface based on system design architecture information and / or interface upstream and downstream dependency information; wherein, the call relationship topology graph includes the target interface and its upstream and downstream interfaces, the nodes in the call relationship topology graph represent interfaces, and the edges represent call relationships; The input unit is used to input the call relationship topology graph, the baseline load test traffic, the historical traffic data of each node, and the historical call frequency data of each edge into the trained graph neural network model. The graph neural network model is used to analyze and infer the key call paths and traffic hotspot distribution in the call relationship topology graph, and adjust the weight of each node in the call relationship topology graph according to the key call paths and traffic hotspot distribution. The generation unit is used to generate a linked load testing traffic model for the target interface and its upstream and downstream interfaces based on the baseline load testing traffic, the weights of each node in the call relationship topology graph, and the key call paths. The linked load testing traffic model is configured with an execution strategy that uses the baseline load testing traffic as the starting traffic and distributes the pressure to the upstream and downstream interfaces in the call relationship topology graph in a proportional and sequential manner. The linked load testing traffic model is used to perform load testing on the target interface and its upstream and downstream interfaces.

[0007] Thirdly, embodiments of this application provide an electronic device, which includes a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the steps of the method for constructing a stress testing scenario based on artificial intelligence as described above.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the steps of the method for constructing a stress testing scenario based on artificial intelligence as described above.

[0009] Fifthly, embodiments of this application provide a computer program product, which includes computer program instructions. When the computer program instructions are executed by a processor, they implement the steps of the method for constructing a stress testing scenario based on artificial intelligence as described above.

[0010] The method, apparatus, electronic device, computer-readable storage medium, and computer program product for constructing load testing scenarios based on artificial intelligence, as provided in the embodiments of this application, can, on the one hand, accurately predict the baseline load testing traffic when the target interface meets the target load testing constraints through a traffic prediction model, and automatically and accurately identify key call paths and traffic hotspots through deep analysis of the system call topology using a graph neural network (GNN), thereby generating a linked load testing traffic model that is highly consistent with the real business logic. This fundamentally solves the problem of scenario distortion caused by traditional single-point load testing or fixed-ratio mixed traffic, enabling load testing to realistically simulate the chain pressure caused by user operations in the microservice link. On the other hand, since the load testing traffic is distributed throughout the entire link according to the real call relationship and weight ratio, it can effectively expose systemic performance bottlenecks and chain failure risks caused by inter-service dependencies and resource competition that are difficult to discover in isolated interface load testing, providing an accurate basis for comprehensive system performance optimization. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings of the embodiments of this application will be briefly described below.

[0012] Figure 1 This is a flowchart illustrating a method for constructing a stress testing scenario based on artificial intelligence, as provided in an embodiment of this application.

[0013] Figure 2 This is a schematic flowchart of step S105 in the AI-based stress testing method provided in the embodiments of this application.

[0014] Figure 3 This is another flowchart illustrating the AI-based stress testing method provided in this application embodiment.

[0015] Figure 4 This is a schematic flowchart of step S106 in the AI-based stress testing method provided in the embodiments of this application.

[0016] Figure 5 This is another schematic diagram of S106 in the AI-based stress testing method provided in the embodiments of this application.

[0017] Figure 6 This is another flowchart illustrating an artificial intelligence-based stress testing method provided in an embodiment of this application.

[0018] Figure 7 This is another flowchart illustrating an artificial intelligence-based stress testing method provided in an embodiment of this application.

[0019] Figure 8 This is a schematic diagram of step S703 in the AI-based stress testing method provided in the embodiments of this application.

[0020] Figure 9 This is another schematic diagram of S703 in the AI-based stress testing method provided in the embodiments of this application.

[0021] Figure 10 This is a structural block diagram of an apparatus for constructing a stress testing scenario based on artificial intelligence, provided in an embodiment of this application.

[0022] Figure 11 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0023] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0024] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0025] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0026] Various modifications and variations can be made to this application without departing from its spirit or scope, which will be apparent to those skilled in the art. Therefore, this application is intended to cover modifications and variations falling within the scope of the corresponding claims (the claimed technical solutions) and their equivalents. It should be noted that the implementation methods provided in the embodiments of this application can be combined with each other without contradiction.

[0027] Before describing the technical solutions provided in the embodiments of this application, in order to facilitate understanding of the embodiments of this application, this application first specifically explains the problems existing in the related technologies: Internet applications, exemplified by online recruitment platforms, commonly employ complex microservice architectures. These platforms handle core functionalities such as resume search, job recommendations, online application submissions, and instant messaging, involving hundreds of microservice interfaces. These interfaces are deeply interdependent; for example, a simple resume search request might sequentially or in parallel call multiple downstream interfaces, including user authentication, enterprise information verification, the Elasticsearch search cluster, and intelligent recommendation services, forming a complete call chain.

[0028] Load testing on such complex systems is crucial for ensuring system stability during peak recruitment periods. However, traditional load testing methods have the following shortcomings when dealing with microservice architectures: testers often only perform isolated load testing on single core interfaces such as resume search, or simply mix traffic from several interfaces according to experience. This approach ignores the complete call chain triggered by user operations in real business scenarios, resulting in a discrepancy between the load testing scenario and the actual business flow. The direct consequence is the inability to discover chained performance bottlenecks caused by service dependencies. For example, a previously unnoticed underlying service might unexpectedly become a bottleneck during load testing because it is called by multiple upstream interfaces; or the load testing traffic might fail to reproduce the real call topology, leading to overly optimistic performance assessments of complex transaction interfaces such as resume submission. Such distorted test results cannot accurately predict the system's performance under real high-concurrency scenarios, creating potential risks to platform stability.

[0029] To address at least one of the aforementioned problems, embodiments of this application provide a method, apparatus, electronic device, computer-readable storage medium, and computer program product for constructing load testing scenarios based on artificial intelligence. Through a traffic prediction model, the baseline load testing traffic when the target interface meets the target load testing constraints can be accurately predicted. By performing deep analysis of the system call topology using a graph neural network (GNN), key call paths and traffic hotspots can be automatically and accurately identified, thereby generating a linked load testing traffic model highly consistent with real business logic. This solves the problem of scenario distortion caused by traditional single-point load testing or fixed-ratio mixed traffic, enabling load testing to realistically simulate the chain reaction pressure caused by user operations in the microservice chain.

[0030] The method for constructing load testing scenarios based on artificial intelligence, as provided in the embodiments of this application, will be introduced first below.

[0031] Figure 1 This is a flowchart illustrating a method for constructing a load testing scenario based on artificial intelligence, as provided in an embodiment of this application. Figure 1 As shown, the method for constructing a stress testing scenario based on artificial intelligence provided in this application embodiment may include the following steps S101 to S105.

[0032] S101: Obtain the target load testing constraints, system design architecture information, and / or upstream and downstream dependency information of the target interface.

[0033] The target interface can be any interface. For example, the target interface can be an interface involved in the event planning information or an interface that meets the preset load test trigger conditions. For example, during the "Golden March and Silver April" spring recruitment event, which runs from March 1st to April 30th, the expected traffic to the target interface (such as the resume search interface and the job list query interface) will increase by 300%.

[0034] For example, the preset load test triggering conditions include, but are not limited to, at least one of the following: interface traffic change data is greater than or equal to a preset traffic threshold, interface performance alarm data appears, or version information changes. The interface traffic change data may include, in the production environment (i.e., online), the change in the frequency of interface access within a preset time period, and the access frequency includes, but is not limited to, queries per second (QPS) and / or transactions per second (TPS). The size of the preset traffic threshold can be flexibly adjusted according to actual conditions, and this application does not limit it.

[0035] For example, monitoring reveals that interface A's daily QPS is stable at 1000, but during a pre-event promotion, its QPS surges to 1800 within two hours, representing a change of 800 QPS over two hours. This change in QPS is greater than or equal to a preset traffic threshold. This dynamic change triggers a load testing decision analysis for interface A, making interface A the target interface.

[0036] Interface performance alarm data refers to alarm information generated by monitoring the performance and stability indicators of an interface based on preset thresholds. Interface performance and stability indicators include, but are not limited to, response time (such as the average time it takes for an interface to process requests), error rate (such as the proportion of servers that return 5xx error codes), and system resources (such as the CPU utilization, memory utilization, and disk I / O of the server where the interface is located).

[0037] For example, if the average response time of interface A increases from 50ms to 500ms and the error rate exceeds 5%, a performance alarm will be generated for interface A. The occurrence of this performance alarm will trigger a load testing decision analysis for interface A, which will then become the target interface.

[0038] Version information can be the version information of an interface or the system in which the interface resides. When the version information changes, it can trigger load testing decision analysis for the interfaces involved in the version information, which can be the target interfaces.

[0039] The target load testing constraints define the goals and limitations for the target interface load testing, such as target throughput (queries per second (QPS) and / or transactions per second (TPS), response time limit, error rate threshold, system resource utilization limit (e.g., CPU < 80%), and load testing type (extreme load testing, stability load testing). System design architecture information describes the service deployment structure, number of instances, middleware configuration, etc. Upstream and downstream dependency information for the interface can be obtained through a distributed tracing system (such as SkyWalking, Zipkin), describing the call relationships between interfaces.

[0040] S102: Based on the target stress test constraints, the baseline stress test traffic of the target interface is predicted using a trained traffic prediction model.

[0041] In S102, the performance requirements in the target stress test constraints are analyzed by the traffic prediction model. Combined with the historical traffic data and / or test traffic data of the target interface, the baseline stress test traffic to be applied to the target interface is predicted, that is, the initial stress test traffic applied to the target interface.

[0042] S103: Based on system design architecture information and / or upstream and downstream dependency information of interfaces, construct a call relationship topology graph starting from the target interface; wherein, the call relationship topology graph includes the target interface and its upstream and downstream interfaces, the nodes in the call relationship topology graph represent interfaces, and the edges represent call relationships.

[0043] In traditional load testing, testers often only stress a single interface or simply mix traffic from a few interfaces in a fixed ratio. However, in real system architectures, a user action triggers a series of interface calls, forming a call chain with a specific structure and dependencies. If the load test traffic cannot reproduce this structure, it may lead to localized overload. For example, a neglected underlying interface might unexpectedly become a bottleneck during load testing because it is called by multiple upstream interfaces, something that would not be detected in single-interface load testing. And / or, it may lead to misjudgments, such as assuming the order placement interface performs well when in reality the load test traffic is not calling its downstream interfaces like real users, resulting in overly optimistic test results. And / or, it may lead to wasted load testing resources, such as testing the wrong path and failing to discover truly high-risk links.

[0044] In view of this, this application distributes load testing traffic according to the actual call relationships of the system architecture when allocating load testing traffic, thereby discovering real and systemic performance bottlenecks in the entire business chain. In S103, a call relationship topology graph starting from the target interface can be constructed based on system design architecture information and / or upstream and downstream dependency information of interfaces. In this graph, nodes represent interfaces, and edges represent call relationships. For example, taking the resume search interface as the target interface, the call relationship topology graph could include: resume search interface → enterprise information interface → user authentication interface; resume search interface → recommendation algorithm interface; resume search interface → application status notification interface, etc.

[0045] S104: Input the call relationship topology graph, benchmark load test traffic, historical traffic data of each node, and historical call frequency data of each edge into the trained graph neural network model; wherein, the graph neural network model is used to analyze and infer the key call paths and traffic hotspot distribution in the call relationship topology graph, and adjust the weight of each node in the call relationship topology graph according to the key call paths and traffic hotspot distribution.

[0046] Historical traffic data for each node refers to the historical traffic data for each interface, such as the QPS, response time, and error rate of each interface over the past 30 days. Historical call frequency data for each side refers to the historical call frequency data between interfaces, such as 80 calls to enterprise information queries per 100 resume searches.

[0047] Graph Neural Networks (GNNs) are deep learning models used to process graph-structured data. Their core idea is that in a graph, each node (such as an interface) can receive and aggregate information from its neighbors through the edges connected to it (interface calls). In S104, the call relationship topology graph, baseline load test traffic, historical traffic data for each node, and historical call frequency data for each edge can be input into the trained GNN model. The GNN model can be used to analyze and infer the key call paths and traffic hotspot distribution in the call relationship topology graph, and adjust the weight of each node in the call relationship topology graph based on these key call paths and traffic hotspot distributions.

[0048] Graph neural network models can analyze the call relationship topology to identify critical call paths and traffic hotspot distribution. For example, a critical call path might be: the resume search interface triggered by the resume search operation → enterprise information interface → user authentication interface. This path is crucial for business logic but has a relatively long latency. Traffic hotspot distribution: While the job details interface itself is not a bottleneck, it simultaneously calls the enterprise credit interface and the salary analysis interface, resulting in high inbound edge load on the enterprise credit interface.

[0049] Each node (interface) in the call relationship topology can be assigned an initial weight, which can be determined based on historical call frequency data. For example, taking the resume search interface as an example, out of every 100 resume search requests, 80 will call the enterprise information interface, 60 will call the recommendation algorithm interface, 30 will call the user authentication interface, and 10 will asynchronously trigger the behavior analysis interface. Therefore, the initial weights of the enterprise information interface, recommendation algorithm interface, user authentication interface, and behavior analysis interface would be 80%, 60%, 30%, and 10%, respectively.

[0050] Based on critical call paths and traffic hotspot distribution, graph neural network models can adjust the weight of each node (interface) in the call relationship topology graph, which affects the final distribution ratio of load testing traffic. For example, the weight of interfaces on critical call paths can be increased. For instance, if the resume search interface → enterprise information interface → user authentication interface is identified as a critical call path, the graph neural network model can increase the weight of interfaces on this path by 5-10%. After adjustment, for example, the weight of the enterprise information interface can be increased from 80% to 85%. For traffic hotspot interfaces discovered by the graph neural network model, the proportion can be adjusted appropriately. For example, if an interface is already a performance bottleneck, its weight can be appropriately reduced. Conversely, if an interface has stable performance and sufficient capacity, its weight can be appropriately increased. For example, if the recommendation algorithm interface is a hotspot but performs well, its weight can be adjusted from 60% to 65%.

[0051] S105: Based on the baseline load test traffic, the weights of each node in the call relationship topology diagram, and the key call paths, generate a linkage load test traffic model for the target interface and its upstream and downstream interfaces; wherein, the linkage load test traffic model is set with an execution strategy that uses the baseline load test traffic as the starting traffic and distributes the pressure to the upstream and downstream interfaces in the call relationship topology diagram in proportion and order, and the linkage load test traffic model is used to perform load testing on the target interface and its upstream and downstream interfaces.

[0052] Based on the weight of each node in the call relationship topology graph output by the graph neural network model, stress test traffic can be distributed to the target interface and its upstream and downstream interfaces.

[0053] The weights output by the graph neural network model represent the proportion of stress each interface should bear during load testing, i.e., the distribution ratio of load testing traffic. By calculating the product of the baseline load testing traffic and the weights of each interface, the load testing traffic that should be distributed to each interface can be obtained. For example, taking the resume search interface as the target interface, assuming the baseline load testing traffic is 10,000 QPS, the load testing traffic that should be distributed to the enterprise information interface is 10,000 QPS × 0.85 = 8,500 QPS, the load testing traffic that should be distributed to the recommendation algorithm interface is 10,000 QPS × 0.57 = 5,700 QPS, the load testing traffic that should be distributed to the user authentication interface is 10,000 QPS × 0.30 = 3,000 QPS, and the load testing traffic that should be distributed to the behavior analysis interface is 10,000 QPS × 0.08 = 800 QPS.

[0054] Based on the critical call paths determined by the graph neural network model, the order of load testing for each interface can be determined. For example, interfaces on the critical call path are tested first. When load testing resources are sufficient, interfaces on non-critical call paths can be tested in parallel with those on the critical call path, thereby improving load testing efficiency.

[0055] Based on this, a linked load testing traffic model can be constructed. The linked load testing traffic model can include an execution strategy that uses the baseline load testing traffic as the starting traffic and distributes the pressure to upstream and downstream interfaces in proportion and order in the call relationship topology graph.

[0056] The method for constructing load testing scenarios based on artificial intelligence provided in the embodiments of this application, on the one hand, can accurately predict the baseline load testing traffic when the target interface meets the target load testing constraints through a traffic prediction model. Through deep analysis of the system call topology using a graph neural network (GNN), it can automatically and accurately identify key call paths and traffic hotspots, thereby generating a linked load testing traffic model highly consistent with real business logic. This fundamentally solves the problem of scenario distortion caused by traditional single-point load testing or fixed-ratio mixed traffic, enabling load testing to realistically simulate the cascading pressure caused by user operations in the microservice chain. On the other hand, since the load testing traffic is distributed throughout the entire chain according to the actual call relationships and weight ratios, it can effectively expose systemic performance bottlenecks and chain failure risks caused by inter-service dependencies and resource competition that are difficult to detect in isolated interface load testing, providing an accurate basis for comprehensive system performance optimization.

[0057] According to some embodiments of this application, optionally, differentiated traffic prediction strategies are adopted for different online states of interfaces to improve the accuracy of baseline load test traffic prediction. Specifically, the traffic prediction model may include a first traffic prediction model and a second traffic prediction model. The first traffic prediction model can be used to predict the baseline load test traffic of online interfaces, and the second traffic prediction model can be used to predict the baseline load test traffic of offline interfaces. For example, the first traffic prediction model can be a prediction model based on time series analysis, such as a Long Short-Term Memory (LSTM) network model. The second traffic prediction model can be a regression model, such as an XGBoost model or a random forest model.

[0058] S102: Based on the target stress test constraints, predict the baseline stress test traffic of the target interface through the traffic prediction model, which may include the following steps one and two.

[0059] Step 1: For the target interface that has been launched, based on the target load test constraints and combined with the online historical data of the target interface, predict the baseline load test traffic of the target interface through the first traffic prediction model.

[0060] If the target interface is an online interface, detailed operational data of the target interface over a historical period can be obtained, including traffic and performance data. For example, for a resume search interface, its QPS change curve over the past 30 days, CPU utilization, memory usage, response time, and error rate at corresponding moments can be collected. Based on this historical data, and combined with the target load testing constraints, such as an interface response time not exceeding 200 milliseconds and CPU utilization not exceeding 80%, the first traffic prediction model is used to analyze and predict the baseline load testing traffic that meets the target interface's load testing constraints. For example, the prediction result is that the baseline load testing traffic of the target interface when meeting the target load testing constraints is 8500 QPS.

[0061] Step 2: For target interfaces that are not yet online, based on target load testing constraints and combined with offline test data and system design data of the target interface, predict the baseline load testing traffic of the target interface through the second traffic prediction model.

[0062] If the target interface is an offline interface, you can obtain the offline test data collected during stress testing in the test environment, as well as the system design data that the target interface depends on. For example, for a newly developed intelligent resume matching interface, you can collect its offline test data, such as the maximum processing capacity of a single instance being 600 TPS. Simultaneously, you can combine this with system design data, such as the planned number of instances to be deployed, database configuration, caching strategies, etc., and refer to the target stress test constraints. If the system remains stable during the stress test and resource utilization is within a safe threshold, the second traffic prediction model can perform comprehensive calculations to predict the baseline stress test traffic of the target interface when the target stress test constraints are met. For example, the prediction result might be that the baseline stress test traffic of the target interface when the target stress test constraints are met is 4500 TPS.

[0063] Figure 2 This is a schematic flowchart of step S105 in the AI-based stress testing method provided in this application embodiment. Figure 2 As shown, according to some embodiments of this application, optionally, S105: Based on the baseline load test traffic, the weight of each node in the call relationship topology diagram and the key call path, generate a linkage load test traffic model of the target interface and its upstream and downstream interfaces, which may include the following steps S201 and S202.

[0064] S201: Based on the baseline load test traffic, the weight of each node in the call relationship topology diagram, and the key call paths, generate the first linkage load test traffic model with the online environment traffic value as the baseline.

[0065] In S201, based on the node weights and key call path information output by the graph neural network model, and combined with the baseline load test traffic of the target interface, a first linked load test traffic model can be constructed with the online environment traffic value as the benchmark. For details, please refer to the introduction on constructing the linked load test traffic model above, which will not be repeated here.

[0066] S202: When the online environment and the offline testing environment are inconsistent, perform cross-environment traffic migration on the first linkage stress test traffic model to generate a second linkage stress test traffic model suitable for the offline testing environment.

[0067] In practical applications, the hardware configuration, deployment architecture, and data scale of the offline testing environment may differ from those of the online environment (i.e., the production environment). Directly using a first-stage load testing traffic model based on the online environment may distort the test results. For example, if the server configuration in the offline testing environment is only one-quarter of that in the online environment, applying the same pressure directly may prematurely trigger performance bottlenecks, making it difficult to accurately reflect the performance of the online environment.

[0068] In view of this, in S202, when there are hardware or deployment differences between the online environment and the offline testing environment, cross-environment traffic migration can be performed to convert the first linkage stress test traffic model into a second linkage stress test traffic model suitable for the offline testing environment.

[0069] The first linked load testing traffic model can be used to perform load testing on the target interface and its upstream and downstream interfaces when the online and offline testing environments are consistent. The second linked load testing traffic model can be used to perform load testing on the target interface and its upstream and downstream interfaces when the online and offline testing environments are inconsistent.

[0070] In this way, by migrating traffic across environments, the performance of the online environment can be accurately simulated in a resource-limited test environment, improving the credibility and reference value of the stress test results and providing a reliable basis for system performance evaluation and optimization.

[0071] In some specific embodiments, optionally, S202: performing cross-environment traffic migration on the first linked load test traffic model to generate a second linked load test traffic model suitable for the offline test environment may include the following steps three to six.

[0072] Step 3: Obtain environmental difference data between the online environment and the offline testing environment. Environmental difference data includes at least one of the following: differences in machine specifications, differences in deployment architecture, and differences in the amount of dependency data.

[0073] In step three, environmental difference data between the online and offline testing environments can be obtained. This environmental difference data can include at least one of the following: machine specifications, deployment architecture, and the amount of dependent data. For example, machine specifications differences can include CPU core ratio, memory capacity ratio, and network bandwidth ratio; deployment architecture differences can include instance number ratio and cluster configuration differences; and dependent data volume differences can include database table data volume ratio and cached data volume ratio.

[0074] Step 4: Combine the environmental difference data with the online baseline traffic value for a single interface in the first linkage stress test traffic model to construct an environmental difference feature vector.

[0075] In step four, a quantified environmental difference feature vector can be constructed for each interface in the first linked load testing traffic model. The specific construction process is as follows: For the target interface, extract its online baseline traffic value Q_online allocated in the first linked load testing traffic model, and then combine it with the environmental difference parameters obtained in step three. For example, for the resume search interface, if its online baseline traffic value is 2000 QPS, the constructed feature vector is: [CPU ratio = 0.25, memory ratio = 0.25, instance ratio = 0.2, data volume ratio = 0.1, online baseline QPS = 2000].

[0076] The environment difference feature vector organically combines environment difference parameters with the baseline traffic value of the interface in the online environment. It not only considers the differences in environmental hardware, but also combines specific business traffic characteristics, enabling the traffic migration model to learn the performance mapping relationship of different interfaces under different environmental configurations.

[0077] Step 5: Input the environmental difference feature vector into the trained traffic migration model, and the traffic migration model outputs the equivalent benchmark stress test traffic of the interface in the offline test environment.

[0078] In step five, the constructed environmental difference feature vector is input into the pre-trained traffic migration model. The traffic migration model can be trained based on historical stress test data and can learn the non-linear mapping relationship from environmental differences + online target traffic to offline equivalent traffic.

[0079] In some embodiments, the traffic migration model can be a regression model, such as XGBoost or a deep neural network model. In other embodiments, the traffic migration model can be a generative adversarial network (GAN) model that learns the performance mapping relationship between two environments. The generator learns how to map online traffic to reasonable offline equivalent traffic under given environmental differences; the discriminator then determines whether the (environmental differences, traffic values) pair is real historical data.

[0080] The traffic migration model can output the equivalent baseline load test traffic for an interface in an offline testing environment. For example, for a resume search interface, the traffic migration model can output an equivalent offline QPS of 320, which means that using 320 QPS in the offline testing environment can produce system performance similar to 2000 QPS online.

[0081] Step 6: Traverse and transform all traffic values ​​in the first linked load test traffic model to form a linked load test traffic model suitable for the offline testing environment.

[0082] In step six, the transformation operations of steps four and five are repeated for all interface nodes in the first linked load testing traffic model. For example, the environmental difference feature vector construction and traffic migration calculation for each interface can be processed sequentially according to the node order of the call relationship topology graph. During the transformation process, the original call relationships and weight ratios are maintained so that the transformed linked load testing traffic model still accurately reflects the business logic. Finally, the equivalent traffic values ​​after the transformation of all interfaces are used to reconstruct the complete linked load testing traffic model.

[0083] Figure 3 This is another flowchart illustrating the AI-based load testing method provided in an embodiment of this application. Figure 3 As shown, according to some embodiments of this application, optionally, the method for constructing a stress testing scenario based on artificial intelligence may further include the following steps: S106: Based on the trained load testing parameter prediction model, load testing request data and load testing response data are constructed for the target interface and its upstream and downstream interfaces in the call relationship topology graph.

[0084] In systems such as recruitment platforms, preparing a large amount of test data that conforms to business logic is a heavy and error-prone task. For example, preparing request data for a resume submission interface requires not only valid user IDs and job IDs, but also ensuring that the user meets the application criteria for the job. If the business logic dependencies between data are not handled properly, the request may be directly rejected by the server, making it impossible to effectively stress test the core business logic.

[0085] In view of this, the embodiments of this application construct load test request data and load test response data for the target interface and its upstream and downstream interfaces in the call relationship topology graph through a load test parameter prediction model, thereby reducing the workload of manually preparing test data and improving load test efficiency.

[0086] For example, the load testing parameter prediction model can be a deep learning model based on the Transformer architecture. This model can learn the language patterns of API request and response data, understanding the semantic relationships and business rules between fields.

[0087] The load testing request data can be the specific request content sent when simulating a user calling an interface. For example, for a resume search interface, the load testing request data can include HTTP request messages with different search keywords (such as Java engineer, city A) and filtering conditions (such as education requirement: bachelor's degree, work experience: 3-5 years).

[0088] Load testing response data can be used to simulate the return results of downstream dependent interfaces during end-to-end load testing or when certain dependent interfaces need to be isolated for testing. For example, when testing a job list query interface, the response data can be simulated to return enterprise rating data from its downstream enterprise reputation service interface. By generating load testing response data for each interface, even if a downstream interface is unavailable or lacks realistic test data, the interface currently being tested can still receive an expected and reasonable response, thus ensuring the complete execution of the test process.

[0089] In this way, by using the load testing parameter prediction model, test data covering a variety of business scenarios can be automatically generated, reducing the workload of manually preparing test data and helping to improve the coverage of test cases.

[0090] Figure 4 This is a schematic flowchart of step S106 in the AI-based stress testing method provided in this application embodiment. Figure 4 As shown, according to some embodiments of this application, optionally, S106: constructing stress test request data may include the following steps S401 to S403.

[0091] S401: Obtain historical request data and upstream and downstream dependency information of the interfaces in the call relationship topology diagram.

[0092] Historical request data can include the actual request messages and their structure generated when the interface was previously called, collected from online logs or test records, such as the request URL, header, and body (e.g., JSON formatted field names and field value examples). Upstream and downstream dependency information describes other interfaces or data sources that the interface needs to call or query during business processing.

[0093] S402: Input historical request data and upstream and downstream dependency information of interfaces into the load testing parameter prediction model.

[0094] S403: The load testing parameter prediction model infers the business logic constraints between fields in historical request data based on the field structure, data type, and business logic relationships between fields, and combines the upstream and downstream dependency information of the interface to generate a set of load testing request data that conforms to the business logic of each interface in the call relationship topology diagram. The set of load testing request data includes compliant data used to simulate normal business processes, as well as boundary condition data and abnormal logic data used to test the fault tolerance capability of the system.

[0095] In S403, the load testing parameter prediction model first performs deep semantic learning on historical request data to understand its inherent patterns. This includes identifying the data type (e.g., integer, string), value format (e.g., date format, phone number format), and common value ranges for each field. It can also analyze hidden business logic constraints between fields. For example, it learns that when the positionType (job type) in the request parameter is internship, the workExperience (work experience requirement) field is usually unlimited or has a lower limit; or it identifies that salaryUpper (maximum salary) must be greater than salaryLower (minimum salary).

[0096] Then, the load testing parameter prediction model combines upstream and downstream dependency information of the interface to ensure the business rationality of the generated data. For example, when generating data for the interview invitation interface, the model can ensure that the generated resumeId (resume ID) and jobId (job ID) are logically related, that is, the resume was indeed submitted for the job.

[0097] Based on the above learning, the load testing parameter prediction model can generate multiple types of data in batches, such as compliant data, boundary condition data, and abnormal logic data. Compliant data can be data that simulates normal user behavior and fully conforms to business rules. For example, generating a correctly formatted resume search request with valid parameters: { "keyword": "backend development", "city": "a city", "workYears": "3"}. Boundary condition data and abnormal logic data can be used to probe system fault tolerance. For example, boundary condition data can include generating boundary values ​​such as 0 (minimum value) and 50 (potentially outside the normal range) for the work experience field. Abnormal logic data can include generating contradictory data such as salaryUpper being less than salaryLower, or generating a user ID that does not exist in the database and has a malformed format.

[0098] In this way, through the automated learning and generation of the load testing parameter prediction model, a considerable amount of load testing request data covering various test scenarios such as normal, boundary, and abnormal can be prepared in a short period of time. This helps to conduct more comprehensive load testing on various interfaces, while reducing the omissions that may be introduced by manually constructing data.

[0099] Figure 5 This is another schematic diagram of S106 in the AI-based stress testing method provided in the embodiments of this application. For example... Figure 5 As shown, according to some embodiments of this application, optionally, S106: constructing stress test response data may include the following steps S501 to S503.

[0100] S501: Obtain historical response data, historical request data, and upstream and downstream dependency information of interfaces in the call relationship topology diagram.

[0101] Historical response data can include the actual response content returned by the interface after processing various requests, collected from online logs or test records, such as HTTP status codes, response headers, and response bodies (e.g., JSON-formatted success / error data structures). Historical request data can include the actual request messages and their structures generated when the interface was previously called, collected from online logs or test records, such as the request URL, header, and body (e.g., JSON-formatted field names and field value examples). The interface's upstream and downstream dependency information describes other interfaces or data sources that the interface needs to call or query during business processing.

[0102] S502: Input historical response data, historical request data, and upstream and downstream dependency information of interfaces into the load testing parameter prediction model.

[0103] S503: The load testing parameter prediction model analyzes the dynamic mapping relationship between historical request data, upstream and downstream dependency information of the interface, and historical response data to generate an expected response template corresponding to the load testing request data and the simulated downstream service status. The expected response template contains the standard structure and content of the load testing response data that the interface should return when it receives the load testing request data and provides simulated feedback from the downstream dependent service.

[0104] In S503, the load testing parameter prediction model learns the mapping logic by analyzing numerous historical request and response pairs and combining them with the dependency context of the interface. The model can identify what kind of response different types of request parameters will trigger. For example, it learns that when the keyword in a "resume search" request is empty, the system typically returns an error response indicating "keyword cannot be empty"; while when search results are found, it returns a success response containing an array of resumes.

[0105] Secondly, the load testing parameter prediction model can analyze how the status of downstream services affects the final response. For example, it can learn that when the resume search interface calls the downstream enterprise information service and times out or fails, the final response is likely to be an error code and a message, rather than simply returning an empty list.

[0106] Then, based on the learned patterns, the load testing parameter prediction model can generate a structured expected response template. The expected response template not only defines the basic structure of the response (such as JSON fields), but also includes dynamic content generation rules based on different conditions.

[0107] For example, the expected response template generated for creating an interview invitation API might include the following: When all downstream dependencies (such as "Resume Status Service" and "Job Validity Service") pass the check, the response template indicates that { "code": 200, "message": "Invitation sent successfully", "interviewId": "Automatically generated ID"} should be returned; When the simulated downstream "Resume Status Service" returns "The resume has been marked as unsuitable", the response template indicates that it should return { "code": 400, "message": "This resume is currently uninvitable"}.

[0108] Dynamic parts of the expected response template (such as interviewId) can be linked to data generation rules to ensure their uniqueness and correct format.

[0109] In this way, by generating expected response templates, a standardized response basis is provided for simulating various normal and abnormal business scenarios during load testing. This helps to ensure that the load testing process can still proceed smoothly when some downstream services are unavailable or specific test scenarios are required, and to verify the validity of the return results of the interface under load testing, thereby improving the flexibility and depth of load testing.

[0110] Traditional load testing primarily focuses on a system's performance under normal high load. However, in complex distributed systems, the real risks often stem from various unforeseen anomalies, such as the failure of a single service instance, network latency, or database connection timeouts. These failures can trigger a "snowball effect" through service dependency chains, causing local problems to spread into global service unavailability. Conventional load testing methods struggle to proactively and systematically simulate such failure scenarios and assess their impact.

[0111] In view of this, in some embodiments, this application integrates proactive fault injection capabilities into the stress testing process, and achieves a comprehensive test of the system's fault tolerance and self-healing capabilities through systematic fault scenario definition, automated fault injection execution, and intelligent fault impact analysis. This will be described in detail below.

[0112] Figure 6 This is another schematic flowchart illustrating the AI-based load testing method provided in this application. Figure 6 As shown, according to some embodiments of this application, optionally, the AI-based stress testing method may further include the following steps S601 to S603.

[0113] S601: For the business processes involved in the target interface and its upstream and downstream interfaces, define systemic failure scenarios based on fault tree analysis and generate corresponding multi-dimensional fault injection schemes.

[0114] Fault Tree Analysis (FTA) is a system reliability analysis method that uses logical reasoning to analyze all possible causes of undesirable events (top events) in a system from top to bottom. In S601, for the business processes involved in the target interface and its upstream and downstream interfaces, based on fault tree analysis, various underlying failure modes that may lead to business process failure can be systematically identified and transformed into specific, executable fault injection schemes.

[0115] S602: During the stress test, a multi-dimensional fault injection scheme is automatically executed to inject faults into relevant nodes in the call relationship topology graph.

[0116] In S602, according to a pre-generated fault injection scheme, faults can be automatically applied to the instances or infrastructure components corresponding to the target interface at preset time points during load testing through the integrated chaos engineering control plane. For example, when the resume submission interface process reaches the 5th minute of load testing, a network delay of 2000 milliseconds can be automatically injected into 50% of the instances of the payment interface for 2 minutes; or when the load testing reaches the 10th minute, an instance of the enterprise information query interface can be randomly terminated.

[0117] S603: Monitor and analyze the operating status of the system under test after fault injection, trace the propagation path of the fault within the system under test, and evaluate the self-healing capability of the system under test.

[0118] In S603, by monitoring data in real time, we can observe changes in the performance indicators of the system under stress after fault injection, such as an increase in error rate and abnormal resource usage. We can also track how these anomalies propagate along the interface call chain and record the time required for the system under stress to recover from the fault to a stable state, thereby evaluating its self-healing capability.

[0119] In this way, by combining proactive fault detection with performance stress testing, it is possible to discover vulnerable links and potential single points of failure in the system under stress testing earlier, and accurately identify abnormal faults such as single service instance downtime, network latency, and database connection timeout.

[0120] According to some embodiments of this application, optionally, S601: For the business processes involved in the target interface and its upstream and downstream interfaces, a systemic fault scenario is defined based on fault tree analysis, and a corresponding multi-dimensional fault injection scheme is generated, which may include the following steps seven to nine.

[0121] Step 7: Construct a fault tree with the failure of the core function of the business process as the top event.

[0122] A core functional failure in a business process refers to the inability to achieve the ultimate business goal that the process aims to accomplish. For example, in a resume submission interface business process, the core function is for job seekers to successfully submit their resumes to the target position. Therefore, a core functional failure in this process manifests as a resume submission failure. In fault tree analysis, this core functional failure event can be used as the starting point of the analysis, i.e., the top event.

[0123] Step 8: Decompose the top event layer by layer into a set of basic events based on direct failures of infrastructure, application services, or dependent components.

[0124] Basic events are the lowest-level initial events in the fault tree that cannot be further decomposed. They represent directly observable or directly injected failures in infrastructure (such as networks and servers), interfaces (such as a microservice interface instance), or dependent components (such as databases and caches).

[0125] In step eight, the top event is decomposed layer by layer down through logic gates (such as AND gates and OR gates) until all basic events that may have caused the top event are found.

[0126] Taking the aforementioned resume submission failure as an example, its breakdown process can be as follows: Resume submission failure may be caused by a timeout in the submission request processing or a failure in the execution of the submission transaction (OR gate). A timeout in the submission request processing may be caused by a slow response from the gateway interface or a timeout in the resume submission interface itself (OR gate). A timeout in the resume submission interface itself may be caused by the exhaustion of the database connection pool that the interface depends on or a timeout in calling the downstream job inventory verification interface (OR gate).

[0127] Finally, a set of basic events that can be directly injected with faults is decomposed, such as: injecting a 3000ms network delay into the job inventory verification interface (simulating a network failure), killing an instance of a resume submission interface (simulating an interface failure), and simulating a full database connection pool (simulating a dependent component failure).

[0128] Step 9: Map the basic event set to chaos engineering fault actions to generate a multi-dimensional fault injection scheme; wherein, the fault actions include injecting network latency, simulating service unavailability, and triggering data anomalies, at least one of them.

[0129] In step nine, the basic events obtained in step eight are transformed into chaos engineering fault actions recognizable by the chaos engineering platform, and their execution order, timing, and scope are arranged to form a complete multi-dimensional fault injection scheme. The fault actions include injecting network latency, simulating interface unavailability, and triggering data anomalies, at least one of these. For example, in some examples, the multi-dimensional fault injection scheme could inject a 1500ms network latency into all instances of the job inventory verification interface at the 3rd minute after the load test begins, lasting for 3 minutes. Another example is that the multi-dimensional fault injection scheme could randomly kill a Pod instance of a user session interface at the 8th minute after the load test begins.

[0130] Thus, through fault tree analysis, fault injection is no longer a random, isolated test, but a systematic and theoretically supported comprehensive risk verification based on system architecture and business logic, which helps to cover more potential fault modes.

[0131] According to some embodiments of this application, optionally, S603: monitoring and analyzing the operating status of the system under test after fault injection, tracing the propagation path of the fault in the system under test, and evaluating the self-healing capability of the system under test may include steps ten to twelve.

[0132] Step 10: Based on the call relationship topology and real-time monitoring data, construct a cascading fault propagation graph that shows the fault spreading upstream and downstream from the injection point along the service call chain.

[0133] In step ten, using the existing call relationship topology as the base map and combining it with real-time collected monitoring data, such as error rates and sudden increases in response time between interfaces, a cascading fault propagation graph is constructed, showing how the fault spreads upstream and downstream along the interface call chain from the injection point. For example, when a high-latency fault is injected into the enterprise information query interface, the monitoring system observes that the job details page interface calling it begins to experience thread blocking, which in turn causes the requests from the job details page interface to the user authentication interface to time out, ultimately affecting the homepage recommendation interface from obtaining the necessary enterprise information. This chain reaction is marked and visualized on the topology in real time, forming a cascading fault propagation graph.

[0134] Step 11: Based on the cascading fault propagation map, identify single-point bottlenecks and vulnerable links in the system.

[0135] In step eleven, by analyzing the cascading fault propagation map, it is possible to clearly identify which interfaces or links are most likely to become bottlenecks or cause the impact to expand under fault conditions. For example, the map shows that although the user authentication interface itself is not the source of the fault, it is frequently called by multiple upstream interfaces and lacks an effective circuit breaker mechanism, causing a downstream latency fault to be rapidly amplified. This indicates that the link containing this interface is a vulnerable link.

[0136] Step 12: Record the time taken from fault injection to the system performance indicators returning to normal range, as the basis for calculating the mean fault recovery time.

[0137] In step 12, the time taken from the issuance of the fault injection command to the restoration and stabilization of the system's core performance indicators within the preset normal threshold through means such as alarms, circuit breakers, degradation, capacity expansion, or manual intervention is recorded. This duration is the observed value of the Mean Time To Repair (MTTR) for this fault. MTTR data from multiple experiments can serve as a key indicator for measuring the system's self-healing capability and operational efficiency.

[0138] In this way, by constructing a fault propagation map and quantifying recovery time, systemic risks can be visually displayed, and clear directions for improvement can be provided for subsequent targeted reinforcement of system architecture and optimization of fault tolerance strategies.

[0139] According to some embodiments of this application, optionally, S603: monitoring and analyzing the operating status of the system under test after fault injection, tracing the propagation path of the fault in the system under test, and evaluating the self-healing capability of the system under test may also include steps thirteen and fourteen.

[0140] Step 13: Verify whether the preset fault tolerance mechanism of the system under stress test is triggered as expected. The fault tolerance mechanism includes at least one of the following: service circuit breaking, automatic degradation, traffic scheduling, and overload protection.

[0141] In step thirteen, real-time monitoring data and log records can be analyzed to verify the actual triggering and execution effects of various preset fault tolerance mechanisms under fault scenarios. These fault tolerance mechanisms may include at least one of the following: service circuit breaking, automatic degradation, traffic scheduling, and overload protection.

[0142] Taking service circuit breaking as an example, when it is detected that the error rate of a downstream interface (such as an enterprise information query interface) increases or the response times out due to fault injection, the circuit breaker status of its upstream caller (such as a job details page interface) is checked. It is verified whether the circuit breaker opens correctly after the number of consecutive failures reaches the threshold, thereby stopping requests to the faulty downstream interface, and whether the preset degraded response is returned as configured.

[0143] Step Fourteen: Output a verification report and optimization suggestions for the effective status of the fault tolerance mechanism.

[0144] In step fourteen, a structured verification report can be automatically generated based on the verification results of step thirteen. The verification report may include the following: a comparison of the expected triggering conditions and actual triggering conditions of each fault tolerance mechanism, an evaluation of the actual effect after the mechanism is triggered (such as whether the fault is effectively isolated or whether the avalanche effect is avoided), and identified problems, such as: unreasonable circuit breaker threshold settings leading to premature or untimely circuit breaking; missing degradation strategies or poor user experience after degradation; and imperfect traffic scheduling strategies leading to an expanded scope of fault impact.

[0145] Based on these issues, corresponding optimization suggestions can be generated. For example, it is suggested to increase the circuit breaker failure count threshold of the job inventory verification interface from 5 times to 10 times to avoid accidental circuit breaking during peak traffic periods; or it is suggested to add a degradation strategy to the online communication interface when there is a backlog of messages, automatically switching to offline message mode when the backlog exceeds 1000 messages.

[0146] In this way, by systematically verifying the fault tolerance mechanism and outputting specific improvement suggestions, developers can accurately adjust and optimize the system configuration, so that various fault tolerance measures can play a full role in real failure scenarios.

[0147] Figure 7 This is another schematic flowchart illustrating the AI-based load testing method provided in this application. Figure 7 As shown, according to some embodiments of this application, optionally, the AI-based stress testing method may further include the following steps S701 to S703.

[0148] S701: During the stress test, real-time performance feedback data of the system under stress is collected; the performance feedback data includes at least one of throughput, error rate, response time and system resource utilization.

[0149] Throughput can include queries per second (QPS) and / or transactions per second (TPS) of the interface. System resource utilization can include at least one of CPU utilization, memory utilization, disk I / O throughput, network bandwidth utilization, and database connection pool utilization.

[0150] S702: Based on performance feedback data, construct a state vector that represents the real-time state of the system under stress.

[0151] In S702, the collected multi-dimensional performance data (such as current TPS, error rate, average response time, CPU utilization, etc.) are normalized and feature-combined to form a numerical, multi-dimensional state vector.

[0152] For example, the state vector can be represented as [TPS_normalized, ErrorRate_normalized, AvgResponseTime_normalized, CPU_Utilization_normalized, ...].

[0153] S703: Input the state vector into the trained reinforcement learning model, and the reinforcement learning model outputs the adjustment decision of the parameters of the linkage load test traffic model. The parameters include at least one of the following: number of concurrent users, request injection rate, and load test duration.

[0154] In S703, the state vector is input into the trained reinforcement learning model. The core objective of the reinforcement learning model is to learn a policy that, based on the current system state, selects the load testing parameter adjustment action that maximizes the long-term cumulative reward; that is, the adjustment decision for the parameters of the linked load testing traffic model. Examples include adjustment decisions for the number of concurrent users, request injection rate, and / or load testing duration in the linked load testing traffic model.

[0155] Thus, by introducing a reinforcement learning model for dynamic parameter tuning, the stress testing process can automatically adapt to the real-time state changes of the system, explore the system performance boundaries in a more efficient way, and at the same time help control test risks and avoid system overload caused by improper parameter settings.

[0156] According to some embodiments of this application, optionally, the reinforcement learning model is a model trained based on the proximal policy optimization algorithm (PPO).

[0157] Figure 8 This is a schematic flowchart of step S703 in the AI-based stress testing method provided in this application embodiment. Figure 8 As shown, according to some embodiments of this application, optionally, S703: inputting the state vector into the trained reinforcement learning model, and having the reinforcement learning model output an adjustment decision on the parameters of the linkage pressure test flow model, may include the following steps S801 and S802.

[0158] S801: The policy network that inputs the state vector into the reinforcement learning model.

[0159] Proximal Policy Optimization (PPO) is a policy gradient algorithm that stabilizes the training process by constraining the step size of policy updates. Its core idea is to avoid excessive differences between the new and old policies during policy optimization, thereby ensuring the reliability of the learning process. The policy network is the core component of the PPO algorithm; it is a neural network that maps the input state vector to a probability distribution of a series of actions. In S801, the state vector can be input into the policy network of the reinforcement learning model.

[0160] S802: The policy network performs calculations and inferences, and outputs parameter adjustment actions.

[0161] After receiving the state vector, the policy network performs internal calculations and ultimately outputs specific parameter adjustment actions. These actions include at least one of the following: adjusting the number of concurrent users, adjusting the request injection rate, or adjusting the stress test duration. For example, Action A: Increase the number of concurrent users by 50; Action B: Reduce the request injection rate by 10%; Action C: Keep all current parameters unchanged.

[0162] Thus, reinforcement learning models based on the PPO algorithm can directly output decision actions, achieving end-to-end parameter adjustment. Their training stability helps to obtain reliable tuning strategies in complex stress testing environments.

[0163] According to some embodiments of this application, the reinforcement learning model may optionally be a model trained based on the Deep Q-Network algorithm (DQN).

[0164] Figure 9 This is another schematic diagram of step S703 in the AI-based stress testing method provided in the embodiments of this application. For example... Figure 9 As shown, according to some embodiments of this application, optionally, the state vector is input to the trained reinforcement learning model, and the reinforcement learning model outputs the adjustment decision on the parameters of the linkage pressure test flow model, which may include the following steps S901 to S903.

[0165] S901: Input the state vector into the value evaluation network of the reinforcement learning model.

[0166] The Deep Q-Network algorithm is a value function approximation method that uses a neural network (i.e., a Q-network) to approximate the long-term expected reward (Q-value) obtained after performing each possible action in a given state, and makes a decision by selecting the action with the highest Q-value. The value evaluation network (i.e., the Q-network) is the core of the DQN algorithm. In the S901, the state vector can be input into the value evaluation network of the reinforcement learning model.

[0167] S902: The long-term expected reward value of each candidate adjustment action in a set of candidate adjustment actions for the parameters of the linked stress test flow model is calculated by the value assessment network.

[0168] After receiving the state vector, the value evaluation network calculates a Q-value for each pre-defined candidate adjustment action. For example, for state vector S, the value evaluation network can simultaneously calculate: Q(S, Action A: Concurrency + 50) = +5.2; Q(S, Action B: Request Rate - 20%) = -1.5; Q(S, Action C: Duration + 5min) = +3.0.

[0169] The Q value represents the expected long-term cumulative reward that can be obtained by performing the action in the current state S and then following the optimal strategy.

[0170] S903: Select the candidate adjustment action with the highest long-term expected reward value from the candidate adjustment actions and use it as the adjustment decision.

[0171] Compare the Q-values ​​of all candidate actions and select the action with the highest Q-value as the final adjustment decision. Continuing with the previous example, since action A has the highest Q-value (+5.2), the adjustment of "increasing the number of concurrent users by 50" will be executed.

[0172] Thus, models based on the DQN algorithm make decisions by evaluating the long-term value of all possible actions. This approach can often select the optimal action more accurately in the discrete action space, which helps the stress testing process to more intelligently approach the true performance limit of the system.

[0173] Based on the same technical concept as the method for constructing stress testing scenarios based on artificial intelligence provided in the above-described method embodiments, this application also provides an apparatus for constructing stress testing scenarios based on artificial intelligence.

[0174] Figure 10 This is a structural block diagram of an apparatus for constructing load testing scenarios based on artificial intelligence, provided in an embodiment of this application. For example... Figure 10 As shown in the embodiments of this application, the apparatus 100 for constructing stress testing scenarios based on artificial intelligence may include the following units: Acquisition unit 1001 is used to acquire target stress testing constraints, system design architecture information and / or interface upstream and downstream dependency information of the target interface; The traffic prediction unit 1002 is used to predict the baseline load test traffic of the target interface based on the target load test constraints and through a trained traffic prediction model. The topology graph construction unit 1003 is used to construct a call relationship topology graph starting from the target interface based on system design architecture information and / or interface upstream and downstream dependency information; wherein, the call relationship topology graph includes the target interface and its upstream and downstream interfaces, the nodes in the call relationship topology graph represent interfaces, and the edges represent call relationships; Input unit 1004 is used to input the call relationship topology graph, the baseline stress test traffic, the historical traffic data of each node, and the historical call frequency data of each edge into the trained graph neural network model; wherein, the graph neural network model is used to analyze and infer the key call paths and traffic hotspot distribution in the call relationship topology graph, and adjust the weight of each node in the call relationship topology graph according to the key call paths and traffic hotspot distribution; The generation unit 1005 is used to generate a linkage stress test traffic model for the target interface and its upstream and downstream interfaces based on the baseline stress test traffic, the weight of each node in the call relationship topology graph, and the key call path. The linkage stress test traffic model is set with an execution strategy that uses the baseline stress test traffic as the starting traffic and distributes the pressure to the upstream and downstream interfaces in the call relationship topology graph in a proportional and sequential manner. The linkage stress test traffic model is used to perform stress tests on the target interface and its upstream and downstream interfaces.

[0175] The apparatus for constructing load testing scenarios based on artificial intelligence provided in the embodiments of this application, on the one hand, can accurately predict the baseline load testing traffic when the target interface meets the target load testing constraints through a traffic prediction model, and automatically and accurately identify key call paths and traffic hotspots through deep analysis of the system call topology using a graph neural network (GNN), thereby generating a linked load testing traffic model that is highly consistent with the real business logic. This fundamentally solves the problem of scenario distortion caused by traditional single-point load testing or fixed-ratio mixed traffic, enabling load testing to realistically simulate the chain pressure caused by user operations in the microservice link. On the other hand, since the load testing traffic is distributed throughout the entire link according to the real call relationship and weight ratio, it can effectively expose systemic performance bottlenecks and chain failure risks caused by inter-service dependencies and resource competition that are difficult to find in isolated interface load testing, providing an accurate basis for comprehensive system performance optimization.

[0176] In some embodiments, the traffic prediction model may optionally include a first traffic prediction model and a second traffic prediction model. Specifically, the traffic prediction unit 1002 can be used to predict the baseline load test traffic of an already online target interface using the first traffic prediction model, based on the target load test objective and combined with the target interface's online historical data; and to predict the baseline load test traffic of an un-launched target interface using the second traffic prediction model, based on the target load test constraints and combined with the target interface's offline test data and system design data.

[0177] In some embodiments, optionally, the generation unit 1005 can be specifically used to generate a first linked load test traffic model based on the online environment traffic value, according to the baseline load test traffic, the weight of each node in the call relationship topology graph, and the key call path; when the online environment and the offline test environment are inconsistent, the first linked load test traffic model is migrated across environments to generate a second linked load test traffic model suitable for the offline test environment; wherein, the first linked load test traffic model is used to perform load testing on the target interface and its upstream and downstream interfaces when the online environment and the offline test environment are consistent; the second linked load test traffic model is used to perform load testing on the target interface and its upstream and downstream interfaces when the online environment and the offline test environment are inconsistent.

[0178] In some embodiments, optionally, the generation unit 1005 can be used to acquire environmental difference data between the online environment and the offline testing environment. The environmental difference data includes at least one of machine specification differences, deployment architecture differences, and differences in the amount of dependent data. The environmental difference data is combined with the online baseline traffic value for a single interface in the first linked stress test traffic model to construct an environmental difference feature vector. The environmental difference feature vector is input into the trained traffic migration model, and the traffic migration model outputs the equivalent baseline stress test traffic of the interface in the offline testing environment. All traffic values ​​in the first linked stress test traffic model are traversed and transformed to form a second linked stress test traffic model suitable for the offline testing environment.

[0179] In some embodiments, optionally, the apparatus 100 for constructing load testing scenarios based on artificial intelligence provided in this application may further include a load testing parameter construction unit, used to construct load testing request data and load testing response data for the target interface and its upstream and downstream interfaces in the call relationship topology graph based on a trained load testing parameter prediction model.

[0180] In some embodiments, optionally, the load testing parameter construction unit can be used to obtain historical request data and upstream and downstream dependency information of interfaces in the call relationship topology diagram; input the historical request data and upstream and downstream dependency information of interfaces into the load testing parameter prediction model; the load testing parameter prediction model infers based on the field structure, data type, and business logic constraint relationship between fields in the historical request data, and in combination with the upstream and downstream dependency information of interfaces, to generate a set of load testing request data that conforms to the business logic of each interface in the call relationship topology diagram; wherein, the set of load testing request data includes compliant data for simulating normal business processes, and boundary condition data and abnormal logic data for testing the fault tolerance capability of the system.

[0181] In some embodiments, optionally, the load testing parameter construction unit can be used to obtain historical response data, historical request data, and upstream and downstream dependency information of interfaces in the call relationship topology diagram; input the historical response data, historical request data, and upstream and downstream dependency information of interfaces into the load testing parameter prediction model; analyze the dynamic mapping relationship between historical request data, upstream and downstream dependency information of interfaces, and historical response data by the load testing parameter prediction model, and generate an expected response template corresponding to the load testing request data and the simulated downstream service status; wherein, the expected response template contains the standard structure and content of the load testing response data that the interface should return when receiving the load testing request data and given the simulated feedback of the downstream dependent service.

[0182] In some embodiments, optionally, the apparatus 100 for constructing load testing scenarios based on artificial intelligence provided in this application may further include a fault injection unit, used to define systemic fault scenarios based on fault tree analysis for the business processes involved in the target interface and its upstream and downstream interfaces, and generate corresponding multi-dimensional fault injection schemes; during the load testing process, automatically execute the multi-dimensional fault injection schemes to inject faults into relevant nodes in the call relationship topology graph; monitor and analyze the operating status of the stressed system after fault injection, track the propagation path of the fault in the stressed system, and evaluate the self-healing capability of the stressed system.

[0183] In some embodiments, the fault injection unit may be specifically used to construct a fault tree with the failure of the core function of the business process as the top event; decompose the top event layer by layer into a basic event set based on direct failures of infrastructure, application services or dependent components; map the basic event set to chaos engineering fault actions to generate a multi-dimensional fault injection scheme; wherein the fault actions include injecting network latency, simulating service unavailability, and triggering data anomalies.

[0184] In some embodiments, the fault injection unit may be specifically used to construct a cascading fault propagation graph based on the call relationship topology and real-time monitoring data, in which the fault spreads upstream and downstream along the service call chain from the injection point; based on the cascading fault propagation graph, identify single-point bottlenecks and vulnerable links in the system; and record the time taken from fault injection to the recovery of system performance indicators to the normal range, as a basis for calculating the average fault recovery time.

[0185] In some embodiments, the fault injection unit may optionally be used to verify whether the fault tolerance mechanism preset by the stressed system is triggered as expected. The fault tolerance mechanism includes at least one of service circuit breaking, automatic degradation, traffic scheduling, and overload protection; and output a verification report and optimization suggestions for the effective status of the fault tolerance mechanism.

[0186] In some embodiments, optionally, the apparatus 100 for constructing a load testing scenario based on artificial intelligence provided in this application embodiment may further include a load testing parameter adjustment unit, used to collect performance feedback data of the system under load in real time during the load testing process; the performance feedback data includes at least one of throughput, error rate, response time and system resource utilization; based on the performance feedback data, a state vector representing the real-time state of the system under load is constructed; the state vector is input to a trained reinforcement learning model, and the reinforcement learning model outputs an adjustment decision on the parameters of the linked load testing traffic model, the parameters including at least one of concurrent users, request injection rate and load testing duration.

[0187] In some embodiments, the reinforcement learning model may optionally be a model trained based on a proximal policy optimization algorithm. Specifically, the load testing parameter adjustment unit can be used to input the state vector into the policy network of the reinforcement learning model; the policy network performs calculations and inferences, and outputs parameter adjustment actions; wherein the parameter adjustment actions include at least one of adjusting the number of concurrent users, adjusting the request injection rate, and adjusting the load testing duration.

[0188] In some embodiments, the reinforcement learning model may optionally be a model trained based on a deep Q-network algorithm. Specifically, the load testing parameter adjustment unit can be used to input the state vector into the value evaluation network of the reinforcement learning model; the value evaluation network calculates the long-term expected reward value of each candidate adjustment action in a set of candidate adjustment actions for the parameters of the linked load testing traffic model; and selects the candidate adjustment action with the highest long-term expected reward value from the candidate adjustment actions as the adjustment decision.

[0189] The apparatus for constructing load testing scenarios based on artificial intelligence provided in this application has the same or corresponding technical features as the method for constructing load testing scenarios based on artificial intelligence in the above-described method embodiments, and both can achieve the same technical effect. For the sake of brevity, further details are omitted here.

[0190] Based on the method for constructing stress testing scenarios using artificial intelligence provided in the above-described embodiments, this application also provides an electronic device.

[0191] The electronic device in this application embodiment may be a user terminal device, a server, other computing devices, or a cloud server. Figure 11 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. The electronic device may include a processor 1101 and a memory 1102 storing computer program instructions. When the processor 1101 executes the computer program instructions, it implements the process or function of any of the methods described above.

[0192] Specifically, processor 1101 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Memory 1102 may include a mass storage device for data or instructions. For example, memory 1102 may be at least one of the following: a hard disk drive (HDD), read-only memory (ROM), random access memory (RAM), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, universal serial bus (USB) drive, or other physical / tangible memory storage device. Alternatively, memory 1102 may include removable or non-removable (or fixed) media. Furthermore, memory 1102 may be internal or external to the integrated gateway disaster recovery device. Memory 1102 may be non-volatile solid-state memory. In other words, typically memory 1102 includes a tangible (non-transitory) computer-readable storage medium (such as a memory device) encoded with computer-executable instructions, and when the software is executed (e.g., by one or more processors), it can perform the operations described in the methods of the embodiments of this application. The processor 1101 implements the process or function of any of the methods described in the above embodiments by reading and executing computer program instructions stored in the memory 1102.

[0193] In one example Figure 11 The illustrated electronic device may also include a communication interface 1103 and a bus 1110. The processor 1101, memory 1102, and communication interface 1103 are connected via bus 1110 and communicate with each other. Communication interface 1103 is primarily used to enable communication between modules, devices, units, and / or equipment in the embodiments of this application. Bus 1110 includes hardware, software, or both, and can couple components of the online data traffic billing device together. For example, the bus may include at least one of the following: Accelerated Graphics Port (AGP) or other graphics bus, Enhanced Industry Standard Architecture (EISA) bus, Front Side Bus (FSB), HyperTransport (HT) Interconnect, Industry Standard Architecture (ISA) bus, Infinite Bandwidth Interconnect, Low Pin Count (LPC) bus, memory bus, Microchannel Architecture (MCA) bus, Peripheral Component Interconnect (PCI) bus, PCI-Express (PCI-X) bus, Serial Advanced Technology Attachment (SATA) bus, Video Electronics Standards Association Local (VLB) bus, or other suitable buses. Bus 1110 may include one or more buses. Although specific buses are described or illustrated in the embodiments of this application, any suitable bus or interconnection method may be considered in the embodiments of this application.

[0194] In conjunction with the methods in the above embodiments, this application also provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the process or function of any of the methods in the above embodiments.

[0195] In addition, this application also provides a computer program product that stores computer program instructions, which, when executed by a processor, implement the process or function of any of the methods described above.

[0196] The flowcharts and / or block diagrams of methods, apparatuses, systems, and computer program products according to embodiments of this application have been exemplarily described above, and related aspects have been described. It should be understood that each block or combination thereof in the flowcharts and / or block diagrams may be implemented by computer program instructions, by dedicated hardware performing a specified function or action, or by a combination of dedicated hardware and computer instructions. For example, these computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to form a machine that enables the implementation of the function / action specified in each block or combination thereof in the flowcharts and / or block diagrams, executable via such processor. Such a processor may be a general-purpose processor, a dedicated processor, a special-purpose application processor, or a field-programmable logic circuit.

[0197] The functional blocks shown in the structural block diagrams of this application can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc.; when implemented in software, they are programs or code segments used to perform the required tasks. Programs or code segments can be stored in memory or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. Code segments can be downloaded via computer networks such as the Internet or intranets.

[0198] It should be noted that this application is not limited to the specific configurations and processes described above or shown in the figures. The above descriptions are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the described systems, devices, modules, or units can be referred to the corresponding processes in the method embodiments, and need not be repeated here. It should be understood that the scope of protection of this application is not limited thereto. Any person skilled in the art can conceive of various equivalent modifications or substitutions within the scope of the technology disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application.

Claims

1. A method for constructing load testing scenarios based on artificial intelligence, characterized in that, include: Obtain the target load testing constraints, system design architecture information, and / or upstream and downstream dependency information of the target interface; Based on the target load test constraints, the baseline load test traffic of the target interface is predicted using a trained traffic prediction model; Based on system design architecture information and / or upstream and downstream interface dependency information, a call relationship topology graph is constructed with the target interface as the starting point; wherein, the call relationship topology graph includes the target interface and its upstream and downstream interfaces, the nodes in the call relationship topology graph represent interfaces, and the edges represent call relationships; The call relationship topology graph, benchmark load test traffic, historical traffic data of each node, and historical call frequency data of each edge are input into the trained graph neural network model. The graph neural network model is used to analyze and infer the key call paths and traffic hotspot distribution in the call relationship topology graph, and adjust the weight of each node in the call relationship topology graph according to the key call paths and traffic hotspot distribution. Based on the baseline load test traffic, the weights of each node in the call relationship topology graph, and the key call paths, a linked load test traffic model is generated for the target interface and its upstream and downstream interfaces. The linked load test traffic model is configured with an execution strategy that uses the baseline load test traffic as the starting traffic and distributes the pressure to the upstream and downstream interfaces in the call relationship topology graph in a proportional and sequential manner. The linked load test traffic model is used to perform load testing on the target interface and its upstream and downstream interfaces.

2. The method according to claim 1, characterized in that, The traffic prediction model includes a first traffic prediction model and a second traffic prediction model; Based on the target load test objective, and using a trained traffic prediction model to predict the baseline load test traffic of the target interface, including: For a target interface that has been launched, based on the target load test target and combined with the online historical data of the target interface, the baseline load test traffic of the target interface is predicted by the first traffic prediction model. For target interfaces that are not yet online, based on the target stress test constraints and combined with the offline test data and system design data of the target interface, the baseline stress test traffic of the target interface is predicted by the second traffic prediction model.

3. The method according to claim 1, characterized in that, Based on the baseline load test traffic, the weights of each node in the call relationship topology diagram, and key call paths, a coordinated load test traffic model for the target interface and its upstream and downstream interfaces is generated, including: Based on the baseline load test traffic, the weights of each node in the call relationship topology diagram, and the key call paths, a first linkage load test traffic model is generated with the online environment traffic value as the baseline. In cases where the online environment differs from the offline testing environment, the first linked stress test traffic model is migrated across environments to generate a second linked stress test traffic model suitable for the offline testing environment. The first linked load testing traffic model is used to perform load testing on the target interface and its upstream and downstream interfaces when the online environment and the offline testing environment are consistent; the second linked load testing traffic model is used to perform load testing on the target interface and its upstream and downstream interfaces when the online environment and the offline testing environment are inconsistent.

4. The method according to claim 3, characterized in that, Perform cross-environment traffic migration on the first linked load testing traffic model to generate a second linked load testing traffic model suitable for the offline testing environment, including: Acquire environmental difference data between the online environment and the offline testing environment. The environmental difference data includes at least one of the following: differences in machine specifications, differences in deployment architecture, and differences in the amount of dependency data. The environmental difference data is combined with the online baseline traffic value for a single interface in the first linkage stress test traffic model to construct an environmental difference feature vector; The environmental difference feature vector is input into the trained traffic migration model, and the traffic migration model outputs the equivalent benchmark stress test traffic of the interface in the offline test environment. Iterate through and transform all traffic values ​​in the first linked load test traffic model to form a second linked load test traffic model suitable for offline testing environments.

5. The method according to claim 1, characterized in that, The method further includes: Based on the trained load testing parameter prediction model, load testing request data and load testing response data are constructed for the target interface and its upstream and downstream interfaces in the call relationship topology graph.

6. The method according to claim 5, characterized in that, The data for constructing the load testing request includes: Obtain historical request data and upstream and downstream dependency information of the interfaces in the call relationship topology diagram; Input historical request data and upstream and downstream dependency information of interfaces into the stress test parameter prediction model; The load testing parameter prediction model infers from the field structure, data type, and business logic constraints between fields in the historical request data, and combines the upstream and downstream dependency information of the interface to generate a set of load testing request data that conforms to the business logic of each interface in the call relationship topology diagram; wherein, the set of load testing request data includes compliant data for simulating normal business processes, and boundary condition data and abnormal logic data for testing the fault tolerance capability of the system.

7. The method according to claim 5, characterized in that, The constructed stress test response data includes: Obtain historical response data, historical request data, and upstream and downstream dependency information of the interfaces in the call relationship topology graph; The historical response data, historical request data, and upstream and downstream dependency information of the interface are input into the stress test parameter prediction model; The load testing parameter prediction model analyzes the dynamic mapping relationship between the historical request data, the upstream and downstream dependency information of the interface, and the historical response data to generate an expected response template corresponding to the load testing request data and the simulated downstream service status. The expected response template contains the standard structure and content of the load testing response data that the interface should return when it receives the load testing request data and provides simulated feedback from the downstream dependent service.

8. The method according to claim 1, characterized in that, The method further includes: For the business processes involved in the target interface and its upstream and downstream interfaces, systemic failure scenarios are defined based on fault tree analysis, and corresponding multi-dimensional fault injection schemes are generated. During the stress test, the multi-dimensional fault injection scheme is automatically executed to inject faults into the relevant nodes in the call relationship topology graph; Monitor and analyze the operating status of the system under stress test after fault injection, trace the propagation path of the fault within the system under stress test, and evaluate the self-healing capability of the system under stress test.

9. The method according to claim 8, characterized in that, For the business processes involved in the target interface and its upstream and downstream interfaces, systemic failure scenarios are defined based on fault tree analysis, and corresponding multi-dimensional fault injection schemes are generated, including: A fault tree is constructed using the failure of the core function of the business process as the top event; The top event is decomposed layer by layer into a set of basic events based on direct failures of infrastructure, application services, or dependent components; The basic event set is mapped to chaotic engineering fault actions to generate the multidimensional fault injection scheme; wherein, the fault actions include injecting network latency, simulating service unavailability, and triggering data anomalies at least one of them.

10. The method according to claim 8, characterized in that, Monitor and analyze the operational status of the system under test after fault injection, trace the propagation path of the fault within the system under test, and evaluate the self-healing capability of the system under test, including: Based on the aforementioned call relationship topology and real-time monitoring data, a cascading fault propagation graph is constructed, which shows the fault spreading upstream and downstream along the service call chain from the injection point. Based on the cascading fault propagation map, single-point bottlenecks and vulnerable links in the system are identified; Record the time taken from fault injection to the system performance indicators returning to normal range, as the basis for calculating the mean fault recovery time.

11. The method according to claim 10, characterized in that, Monitoring and analyzing the operational status of the system under stress test after fault injection, tracing the propagation path of the fault within the system under stress test, and evaluating the self-healing capability of the system under stress test also includes: Verify whether the preset fault tolerance mechanism of the stress test system is triggered as expected. The fault tolerance mechanism includes at least one of service circuit breaking, automatic degradation, traffic scheduling, and overload protection. Output a verification report and optimization suggestions regarding the effectiveness of the fault tolerance mechanism.

12. The method according to claim 1, characterized in that, The method further includes: During the stress test, performance feedback data of the system under stress is collected in real time; the performance feedback data includes at least one of throughput, error rate, response time and system resource utilization. Based on performance feedback data, a state vector representing the real-time state of the system under stress is constructed. The state vector is input into the trained reinforcement learning model, and the reinforcement learning model outputs an adjustment decision on the parameters of the linked load test traffic model. The parameters include at least one of the following: number of concurrent users, request injection rate, and load test duration.

13. The method according to claim 12, characterized in that, The reinforcement learning model is a model trained based on the proximal policy optimization algorithm; The state vector is input into the trained reinforcement learning model, and the reinforcement learning model outputs adjustment decisions for the parameters of the linked load testing flow model, including: The state vector is input into the policy network of the reinforcement learning model; The policy network performs calculations and inferences, and outputs parameter adjustment actions; The parameter adjustment actions include at least one of adjusting the number of concurrent users, adjusting the request injection rate, and adjusting the stress test duration.

14. The method according to claim 12, characterized in that, The reinforcement learning model is a model trained based on the deep Q-network algorithm; The state vector is input into the trained reinforcement learning model, and the reinforcement learning model outputs adjustment decisions for the parameters of the linked load testing flow model, including: The state vector is input into the value evaluation network of the reinforcement learning model; The value assessment network calculates the long-term expected reward value for each candidate adjustment action in a set of candidate adjustment actions for the parameters of the linkage stress test flow model. The candidate adjustment action with the highest long-term expected reward value is selected from the candidate adjustment actions and used as the adjustment decision.

15. A device for constructing stress testing scenarios based on artificial intelligence, characterized in that, include: The acquisition unit is used to acquire the target stress test constraints, system design architecture information and / or interface upstream and downstream dependency information of the target interface; The traffic prediction unit is used to predict the baseline load test traffic of the target interface based on the target load test constraints and through a trained traffic prediction model. The topology graph construction unit is used to construct a call relationship topology graph starting from the target interface based on system design architecture information and / or interface upstream and downstream dependency information; wherein, the call relationship topology graph includes the target interface and its upstream and downstream interfaces, the nodes in the call relationship topology graph represent interfaces, and the edges represent call relationships; The input unit is used to input the call relationship topology graph, the baseline load test traffic, the historical traffic data of each node, and the historical call frequency data of each edge into the trained graph neural network model. The graph neural network model is used to analyze and infer the key call paths and traffic hotspot distribution in the call relationship topology graph, and adjust the weight of each node in the call relationship topology graph according to the key call paths and traffic hotspot distribution. The generation unit is used to generate a linked load testing traffic model for the target interface and its upstream and downstream interfaces based on the baseline load testing traffic, the weights of each node in the call relationship topology graph, and the key call paths. The linked load testing traffic model is configured with an execution strategy that uses the baseline load testing traffic as the starting traffic and distributes the pressure to the upstream and downstream interfaces in the call relationship topology graph in a proportional and sequential manner. The linked load testing traffic model is used to perform load testing on the target interface and its upstream and downstream interfaces.

16. An electronic device, characterized in that, The electronic device includes a processor and a memory storing computer program instructions; when the electronic device executes the computer program instructions, it implements the method as described in any one of claims 1-14.

17. A computer program product, characterized in that, It includes computer program instructions that, when executed by a processor, implement the method as described in any one of claims 1-14.

Images