Complex system-oriented full-link performance test system and method

Abstract

The invention relates to the technical field of data processing, in particular to a full-link performance test system and method for a complex system.The method comprises the steps that a scene modeling module obtains service scene parameters, analyzes an interface calling relation, a data transmission path and a conditional branch rule and generates a test link model comprising an interface sequence, data dependence and logic control; the pressure measurement execution module analyzes the model to generate a dynamic scheduling instruction and a multi-protocol pressure measurement script; the resource scheduling module analyzes the instruction, deploys distributed nodes and monitors loads; the data acquisition module acquires performance index data, extracts node identifiers and associates model service nodes; and the monitoring feedback module aggregates the data to identify performance bottleneck nodes, and maps the performance bottleneck nodes to a visual topological graph to generate a positioning report. According to the invention, through full-link modeling and a dynamic scheduling mechanism, the technical problem that a multi-interface series scene cannot be truly restored through existing single-interface voltage measurement is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and in particular to a full-link performance test system and method for complex systems. BACKGROUND

[0002] The existing software system performance test tool generally adopts the technical principle based on protocol simulation and thread pool scheduling, simulates user load by constructing independent request units and configuring the number of concurrent threads. The tool usually supports single-point stress testing capability of common protocols such as HTTP, JDBC, etc., allowing testers to design test scripts for specific interfaces or database operations, and record basic indicators such as response time and throughput.

[0003] The existing software system performance test tool is based on the design concept of discrete request response model, which disassembles the complex business system into independent interfaces for stress testing, ignoring the dynamic data dependency and state transmission requirements between interfaces in actual user operations. For example, in the e-commerce payment business scenario, the user needs to first execute the login interface to obtain an identity token, then use the token to trigger the product query interface to return the inventory ID, then call the shopping cart interface to generate an order based on the inventory ID, and finally complete the payment process through the order number. When the existing tool only performs static stress testing on the payment interface, the preset order data used cannot simulate the actual concurrent stress and data coupling relationship of the upstream order generation service, resulting in that the test results neither expose the data lock contention defects of the order service under high concurrency, nor reflect the cascading failure risk of the token invalidation mechanism on the entire payment link, ultimately making the test conclusion deviate from the real business bearing capacity. SUMMARY

[0004] In view of the deficiencies of the prior art, the present application provides a full-link performance test system and method for complex systems, which solves the technical problem that the existing test tool adopts a static single-interface stress testing mode, which cannot truly restore the multi-interface serial business scenario.

[0005] To solve the above technical problems, the specific content of the present application is as follows: In a first aspect, the present application provides a full-link performance test system for complex systems, comprising: A scene modeling module is configured to obtain user-configured business scenario parameters, parse the interface call relationship, data transmission path and conditional branch rules in the business scenario parameters, and generate a test link model including interface call sequence, data dependency relationship and logic control rules. A stress testing execution module is connected to the scene modeling module and configured to parse the interface call sequence and protocol type in the test link model to obtain a parsing result, generate a stress testing task based on the parsing result, and the stress testing task includes dynamic scheduling instructions and multi-protocol stress testing scripts. The resource scheduling module is connected with the pressure test execution module, is used for analyzing dynamic scheduling instructions in the pressure test task, generating a node resource allocation strategy, deploying distributed pressure test nodes according to the node resource allocation strategy, distributing the pressure test task to the deployed pressure test nodes for execution, and monitoring the node load state of the pressure test task execution. The data acquisition module is connected with the resource scheduling module, is used for acquiring performance index data returned by the target system in the pressure test task execution process, extracting node identifiers in the performance index data, the node identifiers including link response time, node resource occupancy and protocol interaction state, and associating the node identifiers to corresponding service nodes of the test link model. The monitoring feedback module is connected with the data acquisition module, combines the test link model with the received performance index data, aggregates to generate a link performance data set according to the node identifiers, identifies a performance bottleneck node in the test link model according to the link performance data set, maps the performance bottleneck node to a visual topology graph, and generates a visual report including a positioning mark.

[0006] Further, the scene modeling module of the full-link performance test system for a complex system includes: The graphical unit is used for providing a drag-and-drop interface node configuration interface and generating a test link model including interface parameters and logical branch conditions. The dependency binding unit is connected with the graphical unit, is used for receiving the test link model, extracting variables in the pre-sequencing interface response data in the model, and transmitting the variables to subsequent interface request parameters and updating the test link model. The semantic verification unit is connected with the dependency binding unit, is used for checking parameter integrity and calling sequence legality in the updated test link model.

[0007] Further, the pressure test execution module of the full-link performance test system for a complex system includes: The protocol adaptation unit is used for loading HTTP, gRPC and MQ protocol engines, and generating protocol configuration data according to the test link model. The script generation unit is connected with the protocol adaptation unit, is used for receiving the protocol configuration data and the test link model, and converting the protocol configuration data and the test link model into executable concurrent pressure test scripts.

[0008] Further, the resource scheduling module of the full-link performance test system for a complex system includes: an elastic scaling unit, which is used for dynamically increasing or releasing containerized pressure test nodes according to the concurrency change of the pressure test task, and generating an available node list. The load balancing unit is connected with the elastic scaling unit, is used for receiving the available node list and the pressure test script, and distributing the pressure test script to idle nodes in the list for execution.

[0009] Further, the complex system-oriented full-link performance test system of the present application, the data acquisition module comprises: a link tracking unit for recording path topology and node delay data of cross-service calls and generating a link tracking dataset; An index collection unit is connected to the link tracking unit and is configured to receive the link tracking dataset, aggregate the basic resource indicators and service operation indicators in the dataset according to the service link dimension.

[0010] Further, the complex system-oriented full-link performance test system of the present application, the monitoring feedback module comprises: a threshold detection unit configured to receive performance indicator data, compare the performance indicator data with historical performance baseline data, and mark abnormal indicators exceeding the threshold; A bottleneck positioning unit is connected to the threshold detection unit and is configured to receive abnormal indicators and a test link model, and associate the abnormal indicators with corresponding service nodes in the test link model.

[0011] Further, the complex system-oriented full-link performance test system of the present application, the monitoring feedback module further comprises: A report generation unit is connected to the bottleneck positioning unit and is configured to receive performance bottleneck nodes and a test link model, map the performance bottleneck nodes to corresponding positions in the test link model, and output link-level optimization suggestions.

[0012] Further, the complex system-oriented full-link performance test system of the present application, the report generation unit is specifically configured to: Generate a visual report including a response time heat map, a resource occupation trend chart, and a link topology anomaly mark based on the performance bottleneck nodes and the performance indicator data.

[0013] Further, the complex system-oriented full-link performance test system of the present application, the scenario modeling module further comprises: A version management unit is configured to save modification history records of the test link model and support historical version backtracking and difference comparison.

[0014] In a second aspect, the present application provides a complex system-oriented full-link performance test method applied to a complex system-oriented full-link performance test system, which comprises: Step 1: configured to obtain user-configured business scenario parameters, parse interface call relationships, data transmission paths, and conditional branch rules in the business scenario parameters, and generate a test link model including interface call sequences, data dependency relationships, and logic control rules; Step 2: connected to step 1, configured to parse interface call sequences and protocol types in the test link model to obtain a parsing result, generate a stress test task based on the parsing result, wherein the stress test task comprises dynamic scheduling instructions and multi-protocol stress test scripts; Step 3, connecting step 2, is used for analyzing the dynamic scheduling instruction in the pressure test task, generating a node resource allocation strategy, deploying the distributed pressure test node according to the node resource allocation strategy, distributing the pressure test task to the deployed pressure test node for execution, and monitoring the node load state of executing the pressure test task; Step 4, connecting step 3, is used for collecting performance index data returned by the target system during the execution of the pressure test task, extracting node identifiers in the performance index data, the node identifiers including link response time, node resource occupancy rate and protocol interaction state, and associating the node identifiers to corresponding service nodes of the test link model; Step 5, connecting step 4, combines the test link model with the received performance index data, aggregates to generate a link performance data set according to the node identifier, identifies the performance bottleneck node in the test link model according to the link performance data set, maps the performance bottleneck node to a visual topology graph, and generates a visual report including a positioning mark.

[0015] Advantages of the present application The present application realizes real restoration of business scenarios by constructing a full-link test model, and solves the problem that the existing single-point pressure test cannot expose multi-interface coupling defects. The scene modeling module generates a test link model including interface sequence, data dependency and control rules, and completely maps the business path; the pressure test execution module generates dynamic scheduling instructions and multi-protocol pressure test scripts based on the model analysis result, realizes the serial execution of interfaces in sequence, and the resource scheduling module dynamically deploys nodes according to the instructions, matches business concurrency fluctuations; the data acquisition module extracts link response time, resource occupancy rate and protocol state node identifier, and associates it to the model service node to capture the cascading failure risk; the monitoring feedback module aggregates to generate a link performance data set, locates the bottleneck node and maps it to a visual topology graph, and provides accurate diagnosis capability for multi-node collaborative defects. The scheme breaks through the limitation of the existing tool static single-interface pressure test, and completely restores the serial business scenario of mixed multi-protocol. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. Obviously, for those skilled in the art, other drawings can also be obtained without creative labor under the premise of the drawings.

[0017] Figure 1 The flowchart of the full-link performance test method for complex systems provided by the embodiments of the present application. DETAILED DESCRIPTION

[0018] In order to make the technical solutions of the present application clearer, the present application will be described below in detail with reference to the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of protection of the present application. The present application provided by each embodiment will be described in detail below with reference to the drawings. For the purpose of better understanding the present application, the present application will be described in further detail below.

[0019] In a first aspect, the present application provides a full-link performance test system for a complex system, comprising: A scenario modeling module is configured to obtain a service scenario parameter configured by a user, analyze an interface calling relationship, a data transmission path and a conditional branching rule in the service scenario parameter, and generate a test link model including an interface calling sequence, a data dependency relationship and a logical control rule. A pressure test execution module is connected to the scenario modeling module and configured to analyze the interface calling sequence and the protocol type in the test link model, obtain an analysis result, generate a pressure test task based on the analysis result, and configure the pressure test task with dynamic scheduling instructions and multi-protocol pressure test scripts. A resource scheduling module is connected to the pressure test execution module and configured to analyze the dynamic scheduling instructions in the pressure test task, generate a node resource allocation strategy, deploy distributed pressure test nodes according to the node resource allocation strategy, distribute the pressure test task to the deployed pressure test nodes for execution, and monitor the node load state of the pressure test task. A data collection module is connected to the resource scheduling module and configured to collect performance index data returned by a target system during execution of the pressure test task, extract node identifiers in the performance index data, associate the node identifiers to corresponding service nodes in the test link model, wherein the node identifiers include link response time, node resource occupancy rate and protocol interaction state. A monitoring feedback module is connected to the data collection module, aggregates link performance data sets according to the node identifiers based on the test link model and the received performance index data, identifies a performance bottleneck node in the test link model according to the link performance data sets, maps the performance bottleneck node to a visual topology graph, and generates a visual report including a positioning marker.

[0020] The scenario modeling module receives a service scenario parameter configured by a user, determines the execution sequence between service nodes by analyzing the interface calling relationship in the parameter, establishes the data dependency relationship between interfaces by analyzing the data transmission path, and extracts the conditional branching rule to define the logical control condition. After the analysis is completed, the module generates a structured test link model, which includes an interface calling sequence table, a data dependency mapping table and a logical control rule set, and provides complete path definition for subsequent pressure testing.

[0021] After the pressure test execution module loads the test link model, the interface call sequence in the model is parsed to determine the node execution priority, and each interface protocol type is matched with a corresponding protocol engine. Based on the parsing result, a pressure test task is generated: dynamic scheduling instructions are generated according to the call sequence to control the node trigger timing, and multi-protocol pressure test scripts are generated in combination with the protocol type, the scripts including an HTTP request template, a gRPC call method, and an MQ message body structure. The dynamic scheduling instructions and the multi-protocol pressure test scripts jointly constitute an executable pressure test task.

[0022] The resource scheduling module parses the dynamic scheduling instructions in the pressure test task, and generates a resource allocation strategy according to the concurrency strength and node distribution demand in the instructions. The strategy is used to deploy distributed pressure test nodes in the container cluster, and the number of nodes is dynamically adjusted to match the task demand. The pressure test task is distributed to the deployed nodes, and the CPU, memory, and network load states of the nodes are monitored in real time to achieve the expected resource utilization.

[0023] The data collection module collects the original performance indicator data returned by the target system during the execution of the pressure test task. Three types of node identifiers are extracted from the original data: link response time records service call delay, node resource occupancy rate statistics CPU and memory consumption, and protocol interaction state capture request success rate and error code. The extracted node identifiers are associated with the corresponding service nodes of the test link model to establish a mapping relationship between the performance data and the model nodes.

[0024] The monitoring feedback module combines the test link model and the performance indicator data to generate a link performance data set according to the node identifier: the indicator changes of the same node at different times are aggregated, and statistical values such as average response time and peak resource occupancy rate are calculated. Based on the data set, performance bottleneck nodes are identified, and service nodes with response delay exceeding a threshold or error rate anomaly are located. The bottleneck nodes are mapped to a visual topology graph to generate a positioning report including color markers for abnormal nodes and line width representing delay degree.

[0025] Specifically, the complex system-oriented full-link performance test system of the present application includes: A graphical unit for providing a drag-and-drop interface node configuration interface to generate a test link model including interface parameters and logical branch conditions; A dependency binding unit connected to the graphical unit for receiving the test link model, extracting variables in the pre-sequenced interface response data in the model, and passing the variables to subsequent interface request parameters and updating the test link model; A semantic verification unit connected to the dependency binding unit for checking the parameter integrity and call sequence legality in the updated test link model.

[0026] The graphical unit provides a drag-and-drop interface node configuration interface, and a user adds a service interface node and sets an interface parameter through the interface, configures a logical branch condition between nodes, and the graphical unit generates a test link model including the interface parameter and the branch condition according to the configuration. The dependent binding unit receives the test link model, parses a response data structure of a previous interface in the model, extracts a specified field as a variable, binds the variable to a request parameter position of a subsequent interface, and updates a parameter transmission relationship of the test link model. The semantic verification unit checks the integrity of the interface parameter in the updated model, and verifies whether the calling sequence meets a preset rule.

[0027] Specifically, the full-link performance test system for a complex system provided by the application comprises: The protocol adaptation unit is configured to load HTTP, gRPC and MQ protocol engines, and generate protocol configuration data according to the test link model; The script generation unit is connected to the protocol adaptation unit and is configured to receive the protocol configuration data and the test link model, and convert the protocol configuration data and the test link model into an executable concurrent stress test script.

[0028] The protocol adaptation unit loads the HTTP protocol engine to process a RESTful request, loads the gRPC protocol engine to process a remote procedure call, and loads the MQ protocol engine to process message queue communication. According to the protocol type identifier of each interface in the test link model, configuration data of the corresponding protocol is generated. The script generation unit receives the protocol configuration data and the test link model, converts the interface calling sequence into a script execution sequence, and generates a multithreaded concurrent stress test script in combination with the protocol configuration data.

[0029] Specifically, the full-link performance test system for a complex system provided by the application comprises: The load balancing unit is connected to the elastic scaling unit and is configured to receive the available node list and the stress test script, and distribute the stress test script to idle nodes in the list for execution.

[0030] The elastic scaling unit monitors the real-time concurrency of the stress test task, automatically creates a new containerized stress test node when the concurrency exceeds a preset threshold, and releases an idle node when the concurrency is below the threshold, thereby generating an available node list including node IP and resources. The load balancing unit receives the available node list and the stress test script, selects idle nodes according to the node load state, and distributes the stress test script to the selected nodes for execution.

[0031] Specifically, the full-link performance test system for a complex system provided by the application comprises: The link tracking unit is configured to record path topology and node delay data of cross-service calls, and generate a link tracking dataset. The index collection unit is connected with the link tracking unit and is configured to receive the link tracking dataset and aggregate the basic resource indexes and the service running indexes in the dataset according to the service link dimension.

[0032] The link tracking unit records the path topology of the cross-service call, collects the processing delay data of each service node, and generates a tracking dataset including the path structure and the delay value. The index collection unit receives the tracking dataset, aggregates the CPU usage rate, the memory occupancy rate and the network IO volume basic resource indexes according to the service link identification, and synchronously collects the interface throughput and the error rate service running indexes.

[0033] Specifically, the complex system-oriented full-link performance test system of the present application, the monitoring feedback module comprises: a threshold detection unit configured to receive performance index data, compare historical performance baseline data, and mark abnormal indexes exceeding the threshold; A bottleneck positioning unit is connected with the threshold detection unit and is configured to receive abnormal indexes and a test link model, and associate the abnormal indexes with corresponding service nodes in the test link model.

[0034] The threshold detection unit receives the performance index data, compares the normal fluctuation range of the corresponding indexes in the historical baseline library, and marks the abnormal indexes exceeding the upper limit or the lower limit. The bottleneck positioning unit receives the abnormal indexes and the test link model, associates the abnormal indexes with the service nodes, and determines the specific service nodes corresponding to the abnormal indexes.

[0035] Specifically, the complex system-oriented full-link performance test system of the present application, the monitoring feedback module further comprises: A report generation unit is connected with the bottleneck positioning unit and is configured to receive performance bottleneck nodes and a test link model, map the performance bottleneck nodes to corresponding positions in the test link model, and output link-level optimization suggestions.

[0036] The report generation unit receives the performance bottleneck nodes and the test link model, locates the physical positions of the bottleneck nodes in the model topology graph, and generates a text report including node optimization suggestions. The report generation unit calls a visualization engine, marks the bottleneck nodes as a red highlight state, and highlights in the link topology graph.

[0037] Specifically, the complex system-oriented full-link performance test system of the present application, the report generation unit is specifically configured to: Generate a visualization report including a response time heat map, a resource occupancy trend graph and a link topology abnormality mark based on the performance bottleneck nodes and the performance index data.

[0038] The report generation unit generates a response time heat map reflecting delay distribution in different time periods based on the performance bottleneck node list and the original performance index data, generates a resource occupation trend chart to show CPU memory change curves, and adds abnormal marker symbols to identify fault points in the link topology chart.

[0039] Specifically, the scene modeling module of the full-link performance test system for complex systems further includes: The version management unit is configured to save modification history records of the test link model and support historical version backtracking and difference comparison.

[0040] The version management unit stores the test link model that passes the semantic verification in the semantic verification unit as a version record according to a timestamp. The graphical unit calls the historical version record to compare the interface node differences and parameter changes between different versions.

[0041] In a second aspect, the application provides a full-link performance test method for complex systems, which is applied to the full-link performance test system for complex systems and includes the following steps: Step 1: configured to obtain user-configured business scenario parameters, parse the interface call relationship, data transmission path and conditional branch rules in the business scenario parameters, and generate a test link model including interface call order, data dependency relationship and logic control rules; Step 2: connected to step 1, configured to parse the interface call order and protocol type in the test link model to obtain a parsing result, generate a stress test task based on the parsing result, and the stress test task includes dynamic scheduling instructions and multi-protocol stress test scripts; Step 3: connected to step 2, configured to parse the dynamic scheduling instructions in the stress test task to generate a node resource allocation strategy, deploy distributed stress test nodes according to the node resource allocation strategy, distribute the stress test task to the deployed stress test nodes for execution, and monitor the node load state of the nodes executing the stress test task; Step 4: connected to step 3, configured to collect performance index data returned by the target system during the execution of the stress test task, extract node identifiers in the performance index data, the node identifiers including link response time, node resource occupation rate and protocol interaction state, and associate the node identifiers to corresponding service nodes of the test link model; Step 5: connected to step 4, configured to combine the test link model and the received performance index data, aggregate to generate a link performance data set according to the node identifiers, identify performance bottleneck nodes in the test link model according to the link performance data set, map the performance bottleneck nodes to a visual topology chart, and generate a visual report including positioning markers.

[0042] The application solves the technical problem that the existing static single-interface stress testing cannot truly restore the multi-interface serial business scenario, and realizes complete restoration of the business path through full-link modeling and a dynamic execution mechanism. A scene modeling module analyzes user-configured business scenario parameters, extracts interface call relationship to define service node execution order, analyzes data transmission paths to establish data dependencies between interfaces, identifies conditional branch rules to set logical control conditions, and generates a structured test link model. The model completely describes the node association relationship of the business path, replacing the single-interface static scripts of existing tools.

[0043] A stress testing execution module analyzes the interface call order in the test link model, generates dynamic scheduling instructions to control node trigger timing, and at the same time identifies protocol types to generate multi-protocol stress testing scripts, supporting mixed execution of HTTP requests, gRPC calls, and MQ messages. Dynamic scheduling instructions enable interfaces to be executed in serial according to business order, and multi-protocol scripts handle data interaction of different protocol interfaces to restore protocol switching in real scenarios.

[0044] A resource scheduling module generates node resource allocation strategies based on the concurrency requirements of dynamic scheduling instructions, and dynamically deploys stress testing nodes in a container cluster. The load state is monitored in real time when tasks are distributed to nodes, and the number of nodes is automatically scaled according to traffic fluctuations. Dynamic resource scheduling matches the concurrency changes of the business path, avoiding load imbalance caused by existing fixed nodes.

[0045] A data collection module collects original performance data of the target system during task execution, extracts node identifiers including link response time, resource occupancy, and protocol state, and associates the node identifiers with specific service nodes in the test link model to establish a mapping relationship between performance data and model nodes. This association mechanism captures the impact of upstream node performance on downstream nodes and exposes the cascading failure risks ignored by existing tools.

[0046] A monitoring feedback module aggregates link performance data sets according to node identifiers, calculates performance statistics of each node in the business path, and identifies bottleneck nodes with response delay exceeding the limit or error rate anomalies based on the data sets. The nodes are mapped to a visual topology graph of the test link model. The visual report marks the location and impact range of the bottleneck nodes, locates multi-interface coupling defects, and provides link-level diagnostic capabilities that existing tools cannot achieve.

[0047] By constructing a complete business path through a test link model, dynamically scheduling to enable interface serial execution, and data association to capture cascading effects, the system ultimately visualizes and locates multi-node collaborative bottlenecks, solving the problem of disconnection between single-point stress testing and real business scenarios.

[0048] The embodiment of the present application aims at the technical problem that the static single-interface stress testing mode adopted by the existing performance testing tool in the background art cannot truly restore the multi-interface serial service scenario. The complete service path restoration is achieved through the construction of a full-link test model and a dynamic execution mechanism. The background art takes an e-commerce payment scenario as an example. User operations involve multi-interface series, such as obtaining an identity token through a login interface, returning an inventory ID through a commodity query interface, generating an order through a shopping cart interface, and completing a transaction through a payment interface. The existing tool ignores the data dependency and state transmission between interfaces when testing independent interfaces, resulting in the inability to expose data lock contention defects under high concurrency of order services or the cascading failure risk caused by token invalidation. The present application solves this problem through the following embodiments, supporting the system and method defined in the claims.

[0049] In the implementation of the scenario modeling module, the user inputs the business scenario parameters through the drag-and-drop interface node configuration interface provided by the graphical unit, for example, in the e-commerce payment scenario, the node order of the login interface, the commodity query interface, the shopping cart interface, and the payment interface is configured; the module determines the node execution priority by analyzing the interface calling relationship in the parameters, identifies the data transmission path, such as the token variable in the response data of the previous login interface being transmitted to the request parameter of the subsequent commodity query interface, extracts the conditional branch rule, such as jumping to the error handling branch when the inventory is insufficient, and generates a test link model including the interface calling order table, the data dependency mapping table, and the logic control rule set; after receiving the model, the dependency binding unit extracts the variable in the previous interface response data and binds it to the subsequent interface parameter, and updates the model parameter transmission relationship; the semantic verification unit checks the parameter integrity and calling order legality of the updated model to ensure that the model maps the real business path; the version management unit saves the model modification history record to support backtracking and difference comparison. This implementation ensures that the test link model completely describes the node association of the business scenario, replacing the discrete request model of the existing tool.

[0050] In the implementation of the stress testing execution module, the protocol adaptation unit loads the HTTP protocol engine to process RESTful requests, the gRPC protocol engine to process remote calls, and the MQ protocol engine to process message queues, and generates protocol configuration data according to the test link model, such as configuring an HTTP request template for the login interface and an MQ message body structure for the payment interface in the e-commerce scenario; the script generation unit receives the protocol configuration data and the model, converts the interface calling order into an execution sequence, generates a multi-protocol stress testing script in combination with the protocol configuration, and generates dynamic scheduling instructions to control the node trigger timing based on the model analysis results, for example, the scheduling instructions ensure that the login interface is executed before the commodity query interface. This implementation realizes the serial execution of multi-protocol interfaces according to the business order, restores the protocol switching and data interaction of the real scenario.

[0051] In the implementation of the resource scheduling module, the elastic scaling unit parses the dynamic scheduling instruction of the stress testing task, generates a node resource allocation strategy according to the concurrency intensity in the instruction, dynamically increases or releases the containerized stress testing node according to the change of the concurrency amount, and generates an available node list; the load balancing unit receives the available node list and the stress testing script, selects an idle node to distribute the script according to the node load state, automatically expands the number of nodes during a high-concurrency period in an e-commerce scenario, monitors the CPU, memory and network load states of the node, and ensures that the resource utilization rate matches the business fluctuation. This implementation avoids the load imbalance caused by the existing fixed nodes through dynamic resource scheduling.

[0052] In the implementation of the data collection module, during the execution of the stress testing task, the link tracing unit records the path topology and node delay data of the cross-service call, and generates a link tracing dataset, such as capturing the complete path delay from the login interface to the payment interface in an e-commerce scenario; the index collection unit receives the dataset, aggregates basic resource indicators such as CPU usage and memory occupancy rate, and service running indicators such as protocol interaction state according to the business link dimension, extracts node identifiers including link response time, node resource occupancy rate and error code; the module associates the node identifiers to the corresponding service nodes of the test link model, establishes a mapping relationship between the performance data and the model nodes, and exposes the cascading impact risk of the performance of the upstream nodes on the downstream. This implementation captures the cascading failure mechanism ignored by existing tools.

[0053] In the implementation of the monitoring feedback module, the threshold detection unit receives the performance indicator data, compares the historical performance baseline data, and marks the abnormal indicators exceeding the threshold, such as the abnormal response time of the payment interface; the bottleneck positioning unit receives the abnormal indicators and the test link model, associates the abnormal indicators with the corresponding service nodes of the model, and identifies the performance bottleneck node; the report generation unit receives the bottleneck node and the model, maps the node to a visual topology graph, generates a visual report including a response time heat map, a resource occupancy trend graph and a link topology abnormality marker, and outputs a link-level optimization suggestion. The present application accurately locates the multi-node cooperative defects and provides link-level diagnosis capability. The present application restores the multi-interface series business scenario through full-link modeling, dynamic scheduling execution, data correlation collection and visual feedback, and solves the problem of disconnection between single-point stress testing and real business.

Claims

1. A complex system oriented full link performance test system, characterized in that, The method comprises the following steps: A scene modeling module is configured to obtain user-configured service scenario parameters, parse interface call relationships, data transmission paths, and conditional branching rules in the service scenario parameters, and generate a test link model comprising interface call sequences, data dependency relationships, and logic control rules; A stress testing execution module is connected to the scene modeling module and configured to parse interface call sequences and protocol types in the test link model, obtain a parsing result, generate a stress testing task based on the parsing result, and configure the stress testing task with dynamic scheduling instructions and multi-protocol stress testing scripts; A resource scheduling module is connected to the stress testing execution module and configured to parse the dynamic scheduling instructions in the stress testing task, generate a node resource allocation strategy, deploy distributed stress testing nodes according to the node resource allocation strategy, distribute the stress testing task to the deployed stress testing nodes for execution, and monitor the load states of the nodes executing the stress testing task; A data collection module is connected to the resource scheduling module and configured to collect performance indicator data returned by a target system during execution of the stress testing task, extract node identifiers from the performance indicator data, associate the node identifiers to corresponding service nodes in the test link model, wherein the node identifiers comprise link response times, node resource occupation rates, and protocol interaction states; A monitoring feedback module is connected to the data collection module and configured to combine the test link model and the received performance indicator data, aggregate link performance data sets according to the node identifiers, identify performance bottleneck nodes in the test link model based on the link performance data sets, map the performance bottleneck nodes to a visual topology graph, and generate a visual report comprising positioning markers.

2. The complex system oriented full link performance test system according to claim 1, wherein, The scene modeling module comprises: A graphical unit configured to provide a drag-and-drop interface node configuration interface and generate a test link model comprising interface parameters and logic branching conditions; A dependency binding unit connected to the graphical unit and configured to receive the test link model, extract variables from pre-sequenced interface response data in the model, pass the variables to subsequent interface request parameters, and update the test link model; A semantic verification unit connected to the dependency binding unit and configured to check the parameter integrity and call sequence legality of the updated test link model.

3. The complex system oriented full link performance test system according to claim 1, wherein, The stress testing execution module comprises: A protocol adaptation unit configured to load HTTP, gRPC, and MQ protocol engines and generate protocol configuration data based on the test link model; A script generation unit connected to the protocol adaptation unit and configured to receive the protocol configuration data and the test link model, and convert the protocol configuration data and the test link model into executable concurrent stress testing scripts.

4. The complex system oriented full link performance test system according to claim 1, wherein, The resource scheduling module comprises: An elastic scaling unit configured to dynamically increase or release containerized stress testing nodes according to the concurrency changes of the stress testing task, and generate a list of available nodes; 5. The complex system oriented full link performance test system according to claim 1, wherein, A load balancing unit connected to the elastic scaling unit and configured to receive the list of available nodes and the stress testing scripts, and distribute the stress testing scripts to idle nodes in the list for execution. The data collection module comprises: A link tracking unit configured to record path topologies and node delay data of cross-service calls, and generate a link tracking data set; An indicator aggregation unit connected to the link tracking unit and configured to receive the link tracking data set, and aggregate basic resource indicators and service running indicators in the data set according to business link dimensions. The method comprises the following steps:

6. The complex system oriented full link performance test system according to claim 1, wherein, The monitoring feedback module comprises a threshold detection unit configured to receive the performance index data, compare the historical performance baseline data, and mark abnormal indexes exceeding the threshold; a bottleneck positioning unit connected to the threshold detection unit and configured to receive the abnormal indexes and the test link model, and associate the abnormal indexes with corresponding service nodes in the test link model.

7. The complex system oriented full link performance test system according to claim 1, wherein, The monitoring feedback module further comprises: a report generation unit connected to the bottleneck positioning unit and configured to receive the performance bottleneck nodes and the test link model, map the performance bottleneck nodes to corresponding positions in the test link model, and output link-level optimization suggestions.

8. The complex system oriented full link performance test system according to claim 7, wherein, The report generation unit is specifically configured to: generate a visual report including a response time heat map, a resource occupation trend chart, and a link topology anomaly label based on the performance bottleneck nodes and the performance index data.

9. The complex system oriented full link performance test system according to claim 1, wherein, The scenario modeling module further comprises: a version management unit configured to save a modification history record of the test link model and support historical version backtracking and difference comparison.

10. A method for complex system oriented full link performance test, applied to the complex system oriented full link performance test system of any one of claims 1-9, characterized in that, The method comprises: Step 1: obtaining user-configured business scenario parameters, parsing interface call relationships, data transmission paths, and conditional branch rules in the business scenario parameters, and generating a test link model including interface call sequences, data dependency relationships, and logic control rules; Step 2: parsing the interface call sequences and protocol types in the test link model to obtain a parsing result, generating a stress testing task based on the parsing result, wherein the stress testing task comprises dynamic scheduling instructions and multi-protocol stress testing scripts; Step 3: parsing the dynamic scheduling instructions in the stress testing task to generate a node resource allocation strategy, deploying distributed stress testing nodes according to the node resource allocation strategy, distributing the stress testing task to the deployed stress testing nodes for execution, and monitoring node load states of the nodes executing the stress testing task; Step 4: during the execution of the stress testing task, collecting performance index data returned by the target system, extracting node identifiers in the performance index data, wherein the node identifiers comprise link response times, node resource occupation rates, and protocol interaction states, and associating the node identifiers with corresponding service nodes in the test link model; Step 5: combining the test link model and the received performance index data, generating a link performance data set according to the node identifiers, identifying performance bottleneck nodes in the test link model according to the link performance data set, mapping the performance bottleneck nodes to a visual topology map, and generating a visual report including positioning labels.

Images