Dynamic performance test method and system based on business portrait and intelligent analysis

Abstract

The invention provides a dynamic performance test method and system based on business portraits and intelligent analysis, and belongs to the field of business system application in the building industry. According to the technical scheme, a service portrait is constructed based on multi-source data of a service system; forming a business-performance heterogeneous dynamic graph based on the business portrait; deducing a propagation path of the risk along the dependency relationship; acquiring a test result according to the performance risk score and the propagation path; and recharging a test result to the business portrait and the business-performance heterogeneous dynamic graph for calibration and updating. The method has the beneficial effects that a service portrait is constructed through service event standardization and process mining, a service-performance heterogeneous dynamic graph is established, risk prediction and propagation path inference are intelligently realized based on the graph, a risk-driven dynamic pressure measurement scene and adaptive load distribution are generated, online safety control and result recharge closed-loop calibration are matched, and the service performance is improved. And interpretable, reproducible and continuous optimization of the performance test consistent with real business semantics and dependency structures is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of business system application in the construction industry, and particularly relates to a dynamic performance test method and system based on business portrait and intelligent analysis. BACKGROUND

[0002] With the evolution of the construction industry business platformization, service and cloud native, the system scale expands and the business load shows obvious time period and peak characteristics. Performance guarantee gradually shifts from offline stress testing to observability and continuous performance engineering that integrates logs, link tracking and resource monitoring. Although the existing technology can carry out monitoring and stress testing, it is generally driven by interface list or fixed script, lacks business event standardization and process mining support, and is difficult to automatically identify high-frequency business links and key interfaces, resulting in insufficient scene representation and disconnection with real-time period load. At the same time, the topology is mostly static or offline maintained, which is difficult to adapt to deployment changes and dependency drift, and the cross-layer bottleneck positioning persistence is poor. Abnormal identification focuses on single-index alarm, ignores dependency propagation mechanism, and is difficult to generate targeted directional pressure and combined risk scenarios. The execution stage also lacks auditable security constraints and closed-loop calibration, making it difficult to achieve explainable, reproducible and continuously optimized dynamic performance test results. SUMMARY

[0003] The purpose of the present application is to provide a dynamic performance test method and system based on business portrait and intelligent analysis, which constructs business portrait through business event standardization and process mining, establishes a business-performance heterogeneous dynamic graph that can be dynamically updated with business and system events, and realizes risk prediction and propagation path inference based on graph intelligence, and then generates risk-driven dynamic stress testing scenarios and adaptive load allocation, cooperates with online security control and result back-feeding closed-loop calibration, and realizes explainable, reproducible and continuously optimized dynamic performance test based on business portrait and intelligent analysis.

[0004] The present application is realized by the following measures: The application discloses a dynamic performance test method based on business portrait and intelligent analysis, and has the characteristics that the method comprises the following steps: S1, based on multi-source data of a business system, a business portrait containing a high-frequency business link set and a key interface candidate set is constructed through business event standardization and process mining; S2, based on the business portrait, business entities and system components are mapped into heterogeneous nodes and multi-type edges are established to form a business-performance heterogeneous dynamic graph which is updated through event triggering with the change of business and system states; S3, a graph intelligent analysis model is applied on the business-performance heterogeneous dynamic graph to calculate performance risk scores of nodes and links in a future prediction window and deduce a propagation path of the risk along a dependency relationship; S4, a dynamic performance test plan for high-risk links and key nodes is generated according to the performance risk scores and the propagation path, and test loads are adaptively allocated and executed based on risk weights and business time period characteristics to obtain test results; and S5, the test results are fed back to the business portrait and the business-performance heterogeneous dynamic graph, and the graph intelligent analysis model and the features of the business-performance heterogeneous dynamic graph are calibrated and updated according to the test results.

[0005] The application also has the following specific features: Based on multi-source data of a business system, a business portrait containing a high-frequency business link set and a key interface candidate set is constructed through business event standardization and process mining, which comprises the following steps: business event logs, link tracking data and resource monitoring data are acquired from the business system; The business event logs are standardized, log entries are mapped into standardized event records with a unified field structure according to a preset business event ontology, and the records are data-cleaned; The cleaned standardized event records are time-sequenced to form business activity sequences according to project identifiers and role identifiers as grouping bases; Process mining technology is applied to the business activity sequences, direct following relationships between events are analyzed, event sequences with a frequency higher than a set threshold are extracted as high-frequency business links, and transfer probabilities and time consumption characteristics of the high-frequency business links are counted to form a high-frequency business link set; Based on the high-frequency business link set, call frequency data, business criticality weights and historical fault records, a key interface candidate set and a key service candidate set are determined through a filtering logic of multi-dimensional evaluation indexes; Finally, the high-frequency business link set, the key interface and service candidate sets, role-link relationships and time period load distribution are integrated to construct the business portrait.

[0006] The process of mapping business entities and system components to heterogeneous nodes and establishing multiple types of edges based on the business profile includes: defining and instantiating multiple types of heterogeneous nodes representing business activities, service interfaces, data entities and infrastructure resources based on the high-frequency business link set, key interface candidate set and key service candidate set in the business profile. Based on the dependency and flow relationships parsed from link tracing data, business logs and deployment configurations, multiple types of directed edges, including at least business transfer edges, call dependency edges, data dependency edges and deployment mapping edges, are established between the heterogeneous nodes. The business transfer edge connects business nodes based on the sequence of steps in the high-frequency business link; the call dependency edge connects service nodes based on the inter-service call relationship; the data dependency edge connects service nodes and data nodes based on the service's access relationship to data; and the deployment mapping edge connects service nodes and resource nodes based on the deployment bearing relationship, thus constructing a graph skeleton that reflects the system structure and business flow.

[0007] The process of forming a business-performance heterogeneous dynamic graph that is updated via events triggered by changes in business and system status includes: designing and implementing a hybrid update mechanism that integrates fixed-period and event-triggered updates for the graph skeleton; The fixed-period update is as follows: aggregate multi-source monitoring data according to a preset time window, calculate the performance status feature values ​​of each node and edge, and update the corresponding elements of the graph as attribute vectors; The event-triggered update is as follows: real-time monitoring of business and system metrics, and when an event that meets predefined conditions is detected, a targeted adjustment to the graph structure or edge weights is immediately triggered. The event includes at least sudden changes in business load, changes in deployment configuration, changes in business link structure, or changes in service dependencies. Through the hybrid update mechanism, the topology and feature attributes of the graph can dynamically evolve with the real operating environment, forming the business-performance heterogeneous dynamic graph.

[0008] Applying a graph intelligent analysis model to the business-performance heterogeneous dynamic graph to calculate the performance risk score of nodes and links within a future prediction window includes: based on the historical feature sequence of nodes and the topological relationship of edges in the business-performance heterogeneous dynamic graph, using a pre-trained graph intelligent analysis model to perform joint spatiotemporal feature learning, and predicting the probability of each node experiencing performance anomalies within a future time window. By combining the impact weights that reflect the importance of node services, the probability of performance anomalies is converted into a performance risk score for the node; for a link, based on the real-time status of its contained node sequence and edges, the overall performance risk score of the link is calculated by aggregating the performance risk scores of each node on the link and the performance indicators of the edges.

[0009] The process of inferring the propagation path of risk along dependencies includes: starting from the initial high-risk node identified by the performance risk score, and based on the dependencies of various edges in the business-performance heterogeneous dynamic graph and the preset propagation coefficients, simulating or analyzing the diffusion process of risk in the graph network through graph algorithms. Identify nodes that play a key role in the transfer or amplification of risk during its spread as key propagation nodes; Based on the connectivity of the graph, the path from the initial high-risk node to each critical propagation node is searched and evaluated. The propagation intensity of each path is calculated based on the risk value of the node and the edge propagation coefficient. The critical path sequence of risk propagation is output based on the propagation intensity.

[0010] The process of generating a dynamic performance test plan for high-risk links and key nodes based on the performance risk score and propagation path includes: selecting high-risk business links to be tested based on the link performance risk score ranking results and preset high-risk thresholds, and converting them into a stress test master scenario that can simulate user operation sequences; The propagation path is analyzed, and key service, data, and resource nodes other than the starting point are extracted. For each type of key node, a targeted pressure sub-scenario is designed to simulate its specific pressure. The dependency structure of the business-performance heterogeneous dynamic graph is analyzed, and node groups with shared key dependencies and risk scores of medium or higher are identified. For each group, a multi-point combined risk scenario for concurrent execution is constructed. The main load testing scenario, the targeted pressure application sub-scenario, and the combined risk scenario are integrated and arranged to generate a structured test plan. The plan defines a unique identifier for each scenario, the specific target it targets, and the initial number of concurrent users, request rate, and benchmark test duration parameters determined based on historical load and risk scores in the business profile.

[0011] The process of adaptively allocating and executing test loads based on risk weights and business time period characteristics to obtain test results includes: calculating the load allocation weights for each scenario based on the performance risk score of the target for each test scenario, the historical load coefficient in the business profile corresponding to the execution time of the scenario, and the topological centrality of the target in the business-performance heterogeneous dynamic graph through weighted fusion, and allocating the total global test load to the specific number of concurrent users, request rate, and test phase duration for each scenario based on the weights. During the test execution according to the allocated parameters, the system performance indicators are monitored in real time and compared with the predicted risk threshold. When the real-time confidence of the system performance deterioration trend exceeds the preset safety threshold, the load adjustment operation is dynamically triggered. The test is continuously executed until the plan is completed or safely terminated, and the performance indicator data, abnormal events and resource bottleneck information of the whole process are collected to form a structured test result containing load parameters, performance timing and abnormal records.

[0012] The step of feeding the test results back into the business profile and the business-performance heterogeneous dynamic graph, and calibrating and updating the features of the graph intelligent analysis model and the business-performance heterogeneous dynamic graph based on the test results includes: The structured test results are analyzed to extract the measured load, performance indicators and anomaly information. Based on the corresponding scenarios and objectives, the load distribution characteristics in the business profile and the node and edge feature sequences in the business-performance heterogeneous dynamic graph are updated. Based on the test results, the consistency between the performance risks previously predicted by the graph intelligent analysis model and the actual test results is evaluated, and the relevant parameters of the model and the feature weights of the corresponding nodes and edges in the graph are calibrated and adjusted according to the evaluation results. When the accumulated updated data meets the conditions or a change in the business model is detected, the retraining of the graph intelligent analysis model and the maintenance of the graph structure are triggered to form a closed-loop iteration.

[0013] A system employing the aforementioned dynamic performance testing method based on business profiling and intelligent analysis is characterized by comprising:

[0014] The module comprises the following components: a business profile construction module and a heterogeneous dynamic graph module. The business profile is constructed based on multi-source data from the business system, through business event standardization and process mining. The heterogeneous dynamic graph module maps business entities and system components to heterogeneous nodes and establishes multiple edge types, forming a business-performance heterogeneous dynamic graph that is updated event-triggered as business and system states change. The risk prediction and inference module applies a graph intelligence analysis model to the business-performance heterogeneous dynamic graph, calculating the performance risk scores of nodes and links within a future prediction window and inferring the propagation path of risks along dependencies. The dynamic load testing execution module generates dynamic performance test plans for high-risk links and key nodes based on the performance risk scores and propagation paths. It adaptively allocates and executes test loads based on risk weights and business time period characteristics to obtain test results. The feedback calibration and update module feeds the test results back to the business profile and the business-performance heterogeneous dynamic graph, and calibrates and updates the features of the graph intelligence analysis model and the business-performance heterogeneous dynamic graph based on the test results.

[0015] The beneficial effects of this invention are as follows: by standardizing business events and mining processes to construct business profiles, a dynamic business-performance heterogeneous graph that can be dynamically updated with business and system events is established. Based on graph intelligence, risk prediction and propagation path inference are realized, thereby generating risk-driven dynamic stress testing scenarios and adaptive load allocation. Combined with online security control and result feedback closed-loop calibration, the performance test is consistent with the semantics and dependency structure of real business, making it interpretable, reproducible and continuously optimized. Attached Figure Description

[0016] Figure 1 This is an overall flowchart of an embodiment of the present invention.

[0017] Figure 2 A schematic diagram illustrating the rule expression of an embodiment of the present invention.

[0018] Figure 3 A schematic diagram illustrating the rule expression of an embodiment of the present invention.

[0019] Figure 4 A schematic diagram illustrating the rule expression of an embodiment of the present invention.

[0020] Figure 5 A schematic diagram illustrating the rule expression of an embodiment of the present invention.

[0021] Figure 6 A schematic diagram illustrating the rule expression of an embodiment of the present invention.

[0022] Figure 7 A schematic diagram illustrating the rule expression of an embodiment of the present invention. Detailed Implementation

[0023] To clearly illustrate the technical features of this solution, the following detailed implementation method will be used to explain the solution.

[0024] Example 1, see Figure 1 A dynamic performance testing method based on business profiling and intelligent analysis is characterized by the following steps: S1. Based on multi-source data of the business system, a business profile containing a set of high-frequency business links and a candidate set of key interfaces is constructed through business event standardization and process mining, including: obtaining business event logs, link tracing data and resource monitoring data from the business system; Business event logs are standardized by mapping log entries to standardized event records with a unified field structure based on a predefined business event ontology, and then cleaning the records. The cleaned standardized event records are then sorted by time based on project and role identifiers to form business activity sequences. Process mining techniques are applied to these business activity sequences to analyze direct follow-up relationships between events, extracting event sequences with occurrence frequencies exceeding a set threshold as high-frequency business links, and statistically analyzing their transition probabilities and time consumption characteristics to form a high-frequency business link set. Based on the high-frequency business link set, call frequency data, business criticality weights, and historical fault records, a selection logic integrating multi-dimensional evaluation indicators is used to determine candidate sets of key interfaces and key services. Finally, the high-frequency business link set, key interface and service candidate sets, role-link relationships, and time-period load distribution are integrated to construct a business profile.

[0025] Step S1 specifically includes: This method targets the "multi-role, multi-stage, and multi-system linkage" characteristics of business systems in the construction industry (such as project management, progress measurement, material warehousing, quality acceptance, change orders, payment approval, and completion archiving). First, it obtains multi-source data from the business systems, which includes at least: business event logs, link tracing data, and resource monitoring data.

[0026] Specifically, business event logs are used to depict user-side business actions and changes in business status; tracing data is used to depict the call chain of business requests between services and interfaces; and resource monitoring data is used to depict the resource consumption status of the system during the execution of business requests, including CPU, memory, I / O, and network. By using these three types of data in combination, the shortcomings of relying solely on a single business log ("seeing only the business, not the system") or relying solely on resource monitoring ("seeing only the metrics, not the business semantics") can be avoided. This provides a unified and alignable data foundation for the subsequent step S2, which maps business entities and system components to heterogeneous nodes and establishes multiple types of edges.

[0027] Specifically, it includes: I. Business Event Standardization and Data Cleaning (Solving the technical problems of "incomparable heterogeneous logs and misaligned links") Because business systems in the construction industry typically have multiple entry points (Web / mobile / third-party interfaces), are developed by multiple teams, and are integrated with multiple systems, log field naming, event granularity, and coding standards are often inconsistent. This results in the same business action being presented in different formats in different systems, further causing statistical distortion of "direct follow-up relationships" in subsequent process mining, or preventing reliable association between business nodes and service nodes in subsequent graph construction. To address this, this embodiment introduces a "preset business event ontology" and uses this ontology as a standardized mapping rule: the original log entries are parsed into standardized event records with a unified field structure, and data cleaning is performed.

[0028] Specifically, the business event ontology should include at least five parts: "event type set, event field constraints, role type set, project object type set, and state transition set," used to constrain standardized event records to include key fields such as project identifier and role identifier. Standardized event records should at least include: event type, project identifier, role identifier, timestamp, business object identifier (e.g., contract / document / component / acceptance form), result code, and link association identifier (used for alignment with link tracing data). Data cleaning should at least include: deduplication (removing duplicate records with the same link association identifier and a time interval less than a threshold), missing field completion (completing missing fields or marking them as unavailable according to the event type template), and anomaly filtering (removing or isolating obviously erroneous timestamps, illegal project identifiers, and out-of-bounds result codes). The purpose of the aforementioned standardization and cleaning is twofold: firstly, to reduce the structural differences in logs from different sources, making the statistics based on "direct follow relationships" in process mining more stable; secondly, to provide a consistent primary key alignment basis for the establishment of edges such as "business transfer edges" and "call dependency edges" in subsequent S2, thereby improving the reliability of the "business semantics-system topology" mapping in the technology chain.

[0029] II. Business Activity Sequence Construction and Process Mining to Extract High-Frequency Business Links (Solving the technical problems of "scenario selection relying on experience and insufficient coverage") After completing the standardized event recording, this embodiment uses project identifiers and role identifiers as grouping criteria, and sorts the cleaned standardized event records by timestamp to form a business activity sequence. The reason for this is that business behaviors in the construction industry have significant "project context" and "role permission boundaries." Mixing events from different projects and roles within the same time period can obscure the true link structure, leading to biases in high-frequency link extraction. Grouping events by (project identifier, role identifier) ​​yields a sequence input that more closely reflects the actual business process, making high-frequency links more representative of real usage paths, thereby improving the realism and relevance of subsequent dynamic performance test scenario generation (step S4).

[0030] In the process mining stage, this embodiment analyzes the direct-follows relationship between events to extract event sequences with an occurrence frequency exceeding a set threshold as high-frequency service links, and statistically analyzes their transition probability and time consumption characteristics. The occurrence frequency of high-frequency links can be measured using the following support form:

[0031] in, For the first The frequency of occurrence (support) of each candidate event sequence; For the first The number of times an event sequence is matched in all business activity sequences; This is the sum of the number of matches for all candidate sequences.

[0032] To characterize the flow patterns of key steps within the link, this embodiment further statistically analyzes the direct follow-up transition probability of adjacent events in the link:

[0033] in, Event type Follow the event type directly The transition probability; To observe "in the entire sequence of business activities" The number of times directly followed; Event type This refers to the total number of times a precursor event occurs.

[0034] The beneficial effect of the above process of mining and statistics is not in the superficial result of "obtaining a set of links", but in that: by combining the support threshold and the transition probability, it is possible to eliminate occasional paths and noisy operations, and retain the backbone links with stable business semantics. Meanwhile, the time consumption characteristics and transfer patterns of the link can serve as the basis for script organization in the "main stress test scenario" in S4, and can provide statistical support for the initialization of business transfer edge weights in S2, thereby forming a verifiable data path from S1 to S2 and S4. Compared to the traditional approach of relying on human experience to orchestrate stress testing scenarios, this embodiment can continuously produce reusable and comparable sets of links in construction industry systems with frequent business changes and significant differences in role operations, thereby improving both "scenario coverage" and "scenario authenticity" at the same time.

[0035] III. Selection of Key Interface Candidate Set and Key Service Candidate Set (Solving the technical problem of "not being able to find the real bottleneck entry point and wasting testing resources") After obtaining the set of high-frequency business links, this embodiment further integrates call frequency data, business criticality weights, and historical fault records to determine the candidate set of key interfaces and the candidate set of key services. The purpose of this step is that high-frequency links can only represent "the paths users frequently take," but system performance risks are often concentrated in a few key interfaces / services (such as approval submission, attachment upload, report export, batch import, metering calculation, etc.). Selecting scenarios solely based on link frequency may result in insufficient pressure on key weak points.

[0036] Therefore, this embodiment constructs a screening logic that integrates multi-dimensional evaluation indicators, sorts candidate interfaces / services according to their comprehensive scores, and selects the group with the highest scores as the key candidate set. An exemplary comprehensive score can take the following form:

[0037] in, For the first A comprehensive score for each interface (or service); The weighting coefficient for the call frequency metric; Weighting coefficients for key business indicators; The weighting coefficients for historical failure indicators; For the first Normalized call frequency of each interface (or service); For the first The business criticality weight of each interface (or service) (e.g., giving higher weight to approval / metering / settlement interfaces); For the first Historical fault intensity metrics for each interface (or service) (e.g., normalized results of SLA defaults, abnormal alarms, or critical failures).

[0038] This filtering logic is not merely used to generate a candidate list, but rather to establish a traceable connection between the "main business link" and the "high-risk system entry point," thereby enabling the heterogeneous dynamic graph of S2 to have a higher quality set of system nodes during the initialization phase and reducing the introduction of low-value nodes in the graph. At the same time, it provides clear targets for the generation of "targeted pressure sub-scenarios" in S4, allowing stress testing resources to be concentrated on the entry points most likely to cause performance degradation. Especially in the construction industry scenario, peak periods such as end-of-month measurement, payment approval, and completion archiving often lead to queuing and resource contention for a few key interfaces. This filtering mechanism can prioritize such interfaces based on historical failures and criticality weights, making dynamic stress testing closer to the actual risk distribution, rather than applying pressure evenly and causing "bottleneck dilution."

[0039] IV. Business Profile Summary and Output and Support for Subsequent Steps Ultimately, this embodiment integrates the high-frequency service link set, key interface and service candidate set, role-link relationship, and time-period load distribution into a service profile. The role-link relationship describes the contribution of different roles to different links, supporting S4 in generating test scenarios that more closely resemble actual permissions and operation modes based on role combinations. The time-period load distribution describes the load variation patterns of the service at different times, allowing S4 to perform realistic time-period weighted load allocation when generating test plans, thereby improving the risk approximation capability of dynamic performance testing during peak hours. More importantly, the business profile, as a unified output object, provides a "seed set" of nodes and edges and initial statistics for the subsequent construction of the business-performance heterogeneous dynamic graph in S2, and provides semantic anchors for the structured input of the S3 graph intelligent analysis model, thereby forming a self-consistent data flow closed loop in the method chain.

[0040] S2. Based on business profiles, map business entities and system components to heterogeneous nodes and establish multiple types of edges, including: based on the high-frequency business link set, key interface candidate set and key service candidate set in the business profile, define and instantiate multiple types of heterogeneous nodes representing business activities, service interfaces, data entities and infrastructure resources. Based on the dependency and flow relationships parsed from link tracing data, business logs and deployment configurations, multiple types of directed edges are established between heterogeneous nodes, including at least business transfer edges, call dependency edges, data dependency edges and deployment mapping edges; The business transfer edge connects business nodes based on the sequence of steps in the high-frequency business link; the call dependency edge connects service nodes based on the inter-service call relationship; the data dependency edge connects service nodes and data nodes based on the service's access relationship to data; and the deployment mapping edge connects service nodes and resource nodes based on the deployment bearing relationship, thus constructing a graph skeleton that reflects the system structure and business flow.

[0041] The formation of a business-performance heterogeneous dynamic graph that is updated dynamically based on changes in business and system status includes: designing and implementing a hybrid update mechanism that integrates fixed-period and event-triggered updates for the graph skeleton; fixed-period updates involve aggregating multi-source monitoring data according to a preset time window, calculating the performance status feature values ​​of each node and edge, and updating the corresponding elements of the graph as attribute vectors; event-triggered updates involve real-time monitoring of business and system metrics, and when an event that meets predefined conditions is detected, targeted adjustments to the graph structure or edge weights are immediately triggered. Events include at least sudden changes in business load, deployment configuration changes, changes in business link structure, or changes in service dependencies; through the hybrid update mechanism, the topology and feature attributes of the graph can dynamically evolve with the real operating environment, forming a business-performance heterogeneous dynamic graph.

[0042] Step S2 specifically includes: Step S2 takes the business profile constructed in step S1 as the core input and utilizes the set of high-frequency business links (their occurrence frequency) obtained from the business profile. Directly following the transition probability (obtained from step S1) and a candidate set of key interfaces / key services (based on their comprehensive scores) (Obtained from step S1), under the premise of ensuring that the business semantics are interpretable, "business activities - system components - data entities - infrastructure resources" are uniformly organized into a business-performance heterogeneous dynamic graph.

[0043] This design aims to solve two common problems in existing technologies: First, the disconnect between business and system metrics makes it impossible to correlate performance anomalies with specific business links. Second, system topology and dependencies drift with version iterations, deployment scaling, and changes in business peaks, causing static call graphs or static load testing objects to quickly become invalid. To address this, this embodiment uses a "graph skeleton construction + hybrid update mechanism" to enable the topology and performance attributes to evolve dynamically with the operating environment.

[0044] I. Definition and Instantiation of Heterogeneous Nodes (Solving the technical problems of "unbounded expansion of node sets and lack of semantic anchors") First, based on the high-frequency business link set and candidate set in the business profile, multiple types of heterogeneous nodes are defined and instantiated. Specifically, this includes: 1) Business activity nodes: The event type recorded in the standardized event record in step S1 is used as the business node identifier, and only the event type that appears in the high-frequency business link set is instantiated to avoid introducing a large number of sporadic events into the graph, which would lead to unbounded expansion of nodes. 2) Service interface nodes and service nodes: Instantiate interface / service nodes using the key interface candidate set and key service candidate set as "seed sets", and supplement their upstream and downstream dependent nodes with the call chain information in the link tracing data, thereby forming a system node set that can cover the critical path but has a controllable scale. 3) Data entity nodes: Extract data entities (tables, collections, object buckets, etc.) based on business logs and database access audits (e.g., SQL templates, table access records) and instantiate them as data nodes; 4) Resource Nodes: Based on the instance-host mapping relationship resolved from the deployment configuration, resource nodes (such as container instances, virtual machines, node hosts, storage volumes, etc.) are instantiated, and service instance nodes with service instance granularity are adopted in the deployment mapping to correspond one-to-one with the deployment bearing relationship.

[0045] The node instantiation strategy of "using business profiles as seeds" mentioned above is used not only for graph construction, but more importantly, to introduce clear "business semantic anchors" in the initial stage of the graph: high-frequency links and key candidate sets come from the statistics and screening of real business behaviors in step S1, making the node set of the graph interpretable and targeted, avoiding the noise interference and increased computational cost brought about by the traditional "full collection - full graph construction", thereby providing a higher signal-to-noise ratio structural input for subsequent graph intelligent analysis.

[0046] To ensure that key interfaces / services have quantifiable initial importance in the graph, this embodiment utilizes the comprehensive score obtained in step S1. Constructing the initial importance coefficients (Priorities used for node attribute initialization or subsequent edge weight adjustment):

[0047] in, For the first The initial importance coefficient of each key interface (or key service) node; The first one obtained in step S1 A comprehensive score for each interface (or service); This represents the maximum value of the overall score in the candidate set.

[0048] II. Establishment of multiple types of directed edges and construction of graph skeleton (solving the technical problem that "building only a call graph cannot carry business semantics") Based on the dependency and flow relationships parsed from link tracing data, business logs, and deployment configurations, multiple types of directed edges are established between heterogeneous nodes, including at least business transfer edges, call dependency edges, data dependency edges, and deployment mapping edges, thereby constructing a graph skeleton that reflects the system structure and business flow.

[0049] 1) Service Transfer Edge: For each high-frequency service link obtained in step S1, connect adjacent service activity nodes within the link in the order of the steps to form a directed edge, and transfer the occurrence frequency obtained in step S1 to the corresponding edge. Directly following the transition probability As a statistical prior for this side, it is used to characterize "the stability and directionality of this business flow in the real environment".

[0050] For example, the business transfer edge weight can be set as follows:

[0051] in, For business nodes Pointing to business node Business transfer edge weights; For the first step that includes the adjacent step The frequency of occurrence of each high-frequency service link (obtained from step S1); Event type Follow the event type directly The transition probability (obtained from step S1); For event type Business nodes; For event type The business nodes.

[0052] 2) Call dependency edges: Based on the tracing data, the call relationship between services is parsed, and call dependency edges are established between service nodes to express the structural constraints of microservice links and interface call chains; 3) Data dependency edge: Based on the service's access relationship to data entities, a data dependency edge is established between the service node and the data node to express the cross-layer propagation path of "business performance anomalies may be triggered by data layer bottlenecks"; 4) Deployment mapping edge: Connect service instances and resource nodes according to the deployment bearing relationship, which is used to express the fact that "the same service performs differently under different resource bearing conditions".

[0053] By combining the above-mentioned multiple types of edges, the graph skeleton constructed in this embodiment can simultaneously express the cross-domain structure of "business flow (business transfer edge) - system call (call dependency edge) - data access (data dependency edge) - resource carrying (deployment mapping edge)".

[0054] III. A hybrid update mechanism that integrates fixed-period and event-triggered updates (solving the technical problems of "static topology expiration and performance feature lag"). After the graph skeleton is established, this embodiment designs and implements a hybrid update mechanism that integrates fixed period and event triggering, so that the topology and feature attributes of the graph can dynamically evolve with the real operating environment.

[0055] 1) Fixed-period update: Aggregate multi-source monitoring data according to a preset time window, calculate the performance status feature values ​​of each node and edge, and update the corresponding elements of the graph as attribute vectors. To ensure that subsequent intelligent graph analysis can be used directly, the performance attribute vector of a node / edge within window t can be represented as:

[0056] in, For graph elements The performance attribute vector within the time window t; For elements In the window Internal delay characteristics (e.g., P95 delay); For elements In the window Error rate within; For elements In the window The throughput characteristic value within; For elements In the window Resource pressure characteristic values ​​within; A node or edge in the graph; Index for time windows.

[0057] The error rate can be calculated by summing the number of errors within the window to the total number of errors:

[0058] in, For elements In the window Error rate within; For elements In the window The number of error events within; For elements In the window Total number of events within.

[0059] The purpose of fixed-period updates is to project multi-source indicators into learnable attribute vectors, making the graph not only "structured" but also "stateful," thereby avoiding subsequent analysis that is based solely on topology and ignores performance evolution.

[0060] 2) Event-Triggered Updates: Real-time monitoring of business and system metrics. When an event meeting predefined conditions is detected, targeted adjustments to the graph structure or edge weights are immediately triggered. Events include at least sudden changes in business load, deployment configuration changes, changes in business link structure, or changes in service dependencies. For example, sudden changes in business load can be monitored through the load change rate. Determine if an update has been triggered:

[0061] in, For time window Relative to window The rate of change in business load; For window Internal business load count (e.g., request count or pageviews); For window Internal business load count; To prevent smoothing constants with denominators of zero.

[0062] when When the preset threshold gamma_t_threshold is exceeded, the attribute refresh frequency of the business activity node corresponding to the high-frequency business link and its downstream call dependency edge can be increased, or the edge weight can be re-evaluated. In engineering implementation, this "threshold determination - action trigger" can be configured as an executable rule entry, see [link / reference]. Figure 2 For example, the following JSON rule fragment can be embedded in this stage for direct execution by the rule engine; Deployment configuration change events can trigger incremental maintenance of newly added service instance nodes and deployment mapping edges; see [link / reference] Figure 3 To enhance the verifiability of implementation, the following executable rule fragment can be embedded in the corresponding link of this sentence, so that the system can automatically complete "node / edge incremental update" and "resource node mapping correction" after receiving the deployment configuration change event; Service dependency change events can trigger the addition, deletion, and weight reassessment of the call dependency edge set; the change type `change_type` is limited to either `add` or `remove`, representing the addition and removal of dependencies respectively; see also Figure 4 The following JSON rule fragment is embedded in the corresponding stage, enabling the system to perform structural maintenance on newly added / invalidated dependencies and synchronously trigger the weight reassessment of affected edges, thereby preventing the static call graph from becoming invalid during iteration; The unexpected effect of this event triggering mechanism in this invention is that it binds "topology maintenance" with "business / system state mutations," enabling timely correction of the graph structure and key edge weights at critical moments such as release, scaling up / down, and business peaks. This avoids structural lag caused by fixed-period updates, thereby reducing the sources of error in subsequent risk prediction and propagation inference. At the same time, the aforementioned rule entries solidify the triggering conditions, input fields, and action sequences in a configurable and auditable manner, making "when to update, where to update, and what action to update" reproducible, further enhancing the engineering credibility of the method of this invention.

[0063] In summary, this embodiment achieves the dynamic evolution of a business-performance heterogeneous dynamic graph through heterogeneous node instantiation using business profiles as seeds, construction of multi-type directed edges, and a hybrid update mechanism. This graph inherits from step S1. The statistical measures characterize the "real business behavior" and introduce periodic aggregation and event triggering to reflect the "real system state" in a timely manner. Thus, in terms of invention concept, business semantics, system dependencies and performance status are unified into the same graph structure, providing a structured, updatable and interpretable basic data object for intelligent analysis and dynamic testing in subsequent steps.

[0064] S3. Applying a graph intelligence analysis model to the business-performance heterogeneous dynamic graph to calculate the performance risk score of nodes and links in the future prediction window includes: based on the historical feature sequence of nodes and the topological relationship of edges in the business-performance heterogeneous dynamic graph, using a pre-trained graph intelligence analysis model to perform joint spatiotemporal feature learning, and predicting the probability of each node experiencing performance anomalies in the future time window. By combining the impact weights that reflect the importance of node services, the probability of performance anomalies is converted into a performance risk score for the node. For a link, based on the real-time status of its contained node sequence and edges, the overall performance risk score of the link is calculated by aggregating the performance risk scores of each node on the link and the performance indicators of the edges.

[0065] The method infers the propagation path of risk along dependencies, including: starting from the initial high-risk node identified by the performance risk score, simulating or analyzing the risk diffusion process in the graph network using graph algorithms based on the dependencies of various edges in the business-performance heterogeneous dynamic graph and the preset propagation coefficients; identifying nodes that play a key transit or amplification role in the risk diffusion process as key propagation nodes; searching and evaluating paths from the initial high-risk node to each key propagation node based on the graph connectivity; calculating the propagation intensity of each path based on the node risk value and edge propagation coefficient; and outputting the key path sequence of risk propagation based on the propagation intensity.

[0066] Step S3 specifically includes: The design of step S3 is based on the fact that performance risks in business systems in the construction industry often do not suddenly occur on a single interface, but rather exhibit an evolutionary pattern of "phased load concentration - dependency link amplification - cross-layer propagation". For example, peak business periods such as month-end metering, report exporting, and centralized submission of approval workflows will first put pressure on the data layer and resource layer, and then affect service nodes along the call dependency edges, ultimately resulting in an increase in the overall latency of the business chain. If only traditional threshold alarms or static load testing of single interfaces are used, it is not only difficult to make a forward-looking judgment before the risk is formed, but it is also easy to overlook the systemic problem of "medium-risk nodes superimposed leading to an increase in the overall risk of the chain".

[0067] Therefore, in this embodiment, a graph intelligence analysis model is introduced on the heterogeneous dynamic graph in step S2 to perform joint spatiotemporal feature learning. Risk prediction is constrained by "topological dependence + temporal evolution". Furthermore, the critical path is output through propagation inference, so that the risk results are interpretable and operable for stress test orchestration.

[0068] I. Graph Intelligent Analysis Model Input Organization and Future Anomaly Probability Prediction (Solving the problem of "only looking at indicators without considering dependencies, and false positives and false negatives") First, using the service-performance heterogeneous dynamic graph formed in step S2, the performance attribute vectors of the graph elements within a continuous time window are... The organization is input as a historical feature sequence.

[0069] because Delay features have been uniformly included in step S2. Error rate Swallowing characteristics resource pressure Therefore, this input can simultaneously express both the "current performance status" and the "evolutionary trend"; Meanwhile, the graph topology is given by the multi-type directed edges constructed in step S2, where the business transfer edge weights are... It provides statistical priors for business flow direction and provides cross-layer dependency structures for call dependency edges, data dependency edges, and deployment mapping edges.

[0070] In this embodiment, the pre-trained graph intelligence analysis model takes the historical state sequence of nodes and the graph structure at time t as input, and outputs the probability that a node will experience performance anomalies within a future prediction window, which is formally represented as:

[0071] in, For nodes Future prediction window (relative time) Forward The predicted probability of a performance anomaly occurring within a window; For pre-trained graph intelligence analysis models; For nodes At any moment Previous historical feature sequence input (by (assembled according to time) For a moment The graph topology representation (consisting of the multi-type directed edges from step S2, including business transfer edge weights) wait); For node identifiers in the graph; Index for the current time window; The prediction step size (look-ahead length of the prediction window).

[0072] The purpose of the above modeling method is: When a node's current metrics have not yet exceeded the threshold, but its upstream resource nodes or data nodes have shown a continuous deterioration trend in the topology, Dependency relationships can be used to detect early signs that "risk will spread along the edge," thus providing earlier warnings of probability before the risk manifests. This approach, compared to the traditional method of judging based on a single indicator threshold, can explainably reduce "lagging alarms" and "false alarms without business semantics".

[0073] II. Construction of Node Risk Score: Integration of Anomaly Probability and Business Importance (Solving the problem that "ranking by probability alone does not reflect business impact") Secondly, in order to ensure that the risk results reflect both the possibility of technical anomalies and the degree of business impact, this embodiment integrates the node anomaly probability with the node business importance weight to obtain the node performance risk score. The business importance weight is selected by the comprehensive score of the candidate set in step S2. Importance coefficients obtained by normalization (or map it to node-level weights) This ensures that the risk ranking is semantically aligned with the candidate set of key interfaces / key services selected in step S1. The node risk score is calculated as follows:

[0074] in, For nodes At any moment Performance risk score; For nodes The business importance weight (which can be determined by step S2) The mapping reflects the business criticality and the impact of historical failures. For nodes The probability of anomalies within the future prediction window; For node identification; Index for time windows; To predict the step size.

[0075] The beneficial effect of this structure is that, in the construction industry scenario, even if certain interfaces / services (such as approval submission, measurement calculation, and archive export) have similar probabilities of anomaly, their business impact can differ significantly. If only based on... Sorting may misclassify low-impact business nodes as priority targets; integration After that, risk score This allows for a more reasonable alignment of analysis results with the "business profile-driven" goal, enabling the dynamic load testing plan generated in subsequent steps (S4) to prioritize coverage of truly critical links and nodes, thereby improving the efficiency of test resource utilization and reducing ineffective stress.

[0076] III. Aggregation of Overall Risk Scores for the Link (Solving the problem of "difficulty in identifying link failures due to the superposition of risks from scattered nodes") Furthermore, for each link in the high-frequency service link set (derived from the process mining results of step S1), this embodiment performs aggregated calculations on the link risk based on the real-time status of the node sequence and edges contained in the link. The overall link risk score considers not only node risk. Furthermore, it considers the error rate or anomaly indicators of internal dependent edges (especially call dependent edges / data dependent edges) within the current window to identify situations where "all nodes are of medium risk, but edge state deterioration leads to overall high risk of the link." Link risk can be represented as:

[0077] in, For the first Each business link at any time Overall performance risk score; This represents the fusion coefficient for the node risk aggregation item; The fusion coefficient for the edge state aggregation term; For link The number of nodes; For the first in the link Each node at time... The node risk score; For the first in the link Edge at time The error rate (defined in step S2) Consistent, edges are also used as graph elements ); For link node indexing; For link edge indexing; For link identification; Index for time windows.

[0078] The purpose of the aforementioned link aggregation is to provide a directly sortable list of link risk quantities for the subsequent step S4 to select the "main load testing scenario". Compared to traditional methods that only use interface P95 or single-service CPU as the basis for stress testing, this link risk is closer to "end-to-end risk that users can perceive," and can avoid the blind spot of "local indicators being normal but the entire link being unavailable" in complex dependency scenarios.

[0079] IV. Risk Diffusion Simulation and Key Propagation Node Identification (Solving the problems of "only being able to issue alarms but not provide explanations, and high location costs") After obtaining the risk scores of nodes and links, this embodiment starts with the initial high-risk nodes identified by their performance risk scores. Based on the dependencies of various edges in the dynamic graph and preset propagation coefficients, it simulates or analyzes the risk diffusion process in the graph network. Considering that different edge types in the graph have different risk propagation intensities, this embodiment assigns a propagation coefficient to each directed edge. This is used to quantify the "effective coupling strength" of risk propagation along the edge. For business transfer edges, the business transfer edge weights obtained in step S2 can be used directly. Normalization is performed to obtain the propagation coefficient:

[0080] in, For the node Pointing to node The edge propagation coefficient; The weights of the business transfer edges defined in step S2; For the set of business transfer edges; For nodes The business transfer outwards from the adjacent node index; As the starting node; This is the endpoint node.

[0081] Based on this, the propagation impact intensity of a node within the current window (i.e., the convergence of risks from upstream) can be calculated to identify "critical transit or amplification nodes":

[0082] in, For nodes At any moment The intensity of the spread and impact; A set of directed edges in a dynamic graph (which may include call dependency edges, data dependency edges, deployment mapping edges, and business transfer edges); upstream node At any moment The node risk score, The edge propagation coefficient; For upstream nodes; For downstream nodes; Index for time windows.

[0083] when When a node is significantly larger than the others in the node set, it indicates that the node plays a strong role in risk aggregation or amplification during the risk diffusion process, and can therefore be identified as a key propagation node. The beneficial effect of this process is that risk assessment is no longer limited to "a certain node is high-risk", but can form a quantitative explanation of "why the risk affects which modules" in the graph structure, providing a set of target nodes that can be evidenced for subsequent stress measurement and directional pressure application sub-scenario (step S4).

[0084] Furthermore, to output the critical path sequence of risk propagation, this embodiment searches for candidate paths from the initial high-risk node to each critical propagation node based on graph connectivity, and calculates the propagation strength of each path. The path propagation strength takes into account both the "risk level of nodes along the path" and the "coupling strength along the propagation path," and can be expressed as:

[0085] in, For path The propagation intensity at time t; A directed path (consisting of several edges) from an initial high-risk node to a target critical propagation node. Composed in order); This represents the propagation coefficient along the path; The number of nodes (or length metric) contained in the path; For nodes on the path At any moment The node risk score; Index for path nodes; Index for time windows.

[0086] according to The candidate paths are sorted, and the paths with the highest propagation intensity are selected as the critical path sequence for risk propagation. This output has a direct use in this invention: in step S4, the critical propagation paths can be used to determine the target set (service nodes, data nodes, resource nodes) of the "targeted pressure application sub-scenario" and to construct combined risk scenarios (a group of nodes sharing critical dependencies), thereby transforming the intelligent analysis results of S3 into an executable basis for dynamic performance test orchestration. Compared with simply outputting an alarm list, the critical path sequence provides an "operable interpretation chain," which can significantly reduce the cost of manual investigation and scenario construction, making dynamic stress testing more targeted and repeatable.

[0087] In summary, this embodiment outputs node risk scores by performing spatiotemporal joint learning on a heterogeneous dynamic graph of business and performance. Link risk score The key propagation path sequence enables a closed-loop process from structured input driven by "business profiles" to "explainable risk prediction and propagation inference," providing test orchestration basis and calibration objects for subsequent steps S4 and S5, ensuring that the method chain is logically autonomous and can be implemented in engineering.

[0088] S4. Based on the performance risk score and propagation path, generate dynamic performance test plans for high-risk links and key nodes, including: according to the link performance risk score ranking results and the preset high-risk threshold, select the high-risk business links to be tested, and transform them into a stress test main scenario that can simulate user operation sequences. Analyze the propagation path, extract key service, data, and resource nodes in the path excluding the starting point, and design targeted pressure sub-scenarios to simulate specific pressures for each type of key node; analyze the dependency structure of the business-performance heterogeneous dynamic graph, identify node groups with shared key dependencies and risk scores of medium to high, and construct multi-point combined risk scenarios for concurrent execution for each group; The main load testing scenario, targeted pressure application sub-scenario, and combined risk scenario are integrated and arranged to generate a structured test plan. The plan defines a unique identifier for each scenario, the specific target it targets, and the initial number of concurrent users, request rate, and benchmark test duration parameters determined based on historical load and risk scores in the business profile.

[0089] The test load is adaptively allocated and executed based on risk weights and business time period characteristics to obtain test results including: the performance risk score of the target for each test scenario, the historical load coefficient in the business profile corresponding to the execution time of the scenario, and the topological centrality of the target in the business-performance heterogeneous dynamic graph. The load allocation weight of each scenario is calculated by weighted fusion, and the total global test load is allocated to the specific number of concurrent users, request rate and test phase duration of each scenario based on the weight. During the test execution according to the allocated parameters, the system performance indicators are monitored in real time and compared with the predicted risk threshold. When the real-time confidence of the system performance deterioration trend exceeds the preset safety threshold, the load adjustment operation is dynamically triggered. The test is continuously executed until the plan is completed or safely terminated, and the performance indicator data, abnormal events and resource bottleneck information of the whole process are collected to form a structured test result containing load parameters, performance timing and abnormal records.

[0090] Step S4 specifically includes: The inventive concept of step S4 is to transform the "explainable risk" output in step S3 into an executable dynamic performance test action to solve problems in traditional performance testing such as "scenario selection relying on human experience, load configuration being out of touch with actual business, dispersed test resources making it difficult to approach bottlenecks, and lack of security constraints in the test process easily disrupting production". Especially in the construction industry's business systems, business loads exhibit distinct time-of-day and phase-of-day characteristics (e.g., month-end metering, centralized approvals, report export, completion archiving, etc.), and business links and service-data-resource dependencies are coupled across layers. Using only fixed scripts and fixed concurrency configurations often fails to reproduce the real conditions of "link risk superposition" and "propagation risk amplification." This embodiment employs a layered scenario system of "main stress testing scenario + targeted stress application sub-scenario + combined risk scenario," and introduces an adaptive load allocation mechanism that integrates three factors: risk weight, time-of-day load coefficient, and topological centrality. This allows the test plan to dynamically adjust with changes in risk and, within a limited test budget, more closely approximates the actual bottleneck locations and triggering conditions.

[0091] I. Screening of High-Risk Business Links and Construction of Main Load Testing Scenarios First, based on the overall link risk score obtained in step S3 The business links are sorted and compared with a preset high-risk threshold to select high-risk business links to be tested.

[0092] The purpose of this filter is: As an aggregate of end-to-end link risks, it can comprehensively reflect the superposition effect of node risks and edge state degradation in the link, thereby avoiding scenario bias caused by relying solely on single interface indicators.

[0093] To clarify the screening criteria, this embodiment can define the high-risk link set as follows:

[0094] in, For a moment The set of high-risk business links obtained through screening; The first one calculated in step S3 The link at time Overall performance risk score: To preset a high-risk threshold; For link identification; Index for time windows.

[0095] The above process of "threshold filtering - output set - mapping to main load testing scenario" can be configured as executable rule entries; See Figure 5 To ensure that the rule output matches the text symbols, the rule output key uses mathcal_H_t to correspond to... And use pressure_test_primary_scenario to correspond to the "main load test scenario", for example, embed the following JSON rule fragment in this stage and execute it directly by the rule engine; Then, the collection Each high-risk business link within the system is transformed into a load testing master scenario that simulates a user operation sequence. Specifically, based on the association mapping relationship between the standardized event records in step S1 and the interfaces / service nodes in step S2, the business activity nodes within the link are mapped to corresponding interface calls or page operation sequences. Simultaneously, the direct follow-up transfer statistics obtained from step S1 can be referenced to set the branch probability and operation order in the script, thereby enabling the master scenario to statistically reproduce the real business flow structure. This process gives the load testing master scenario "business semantic interpretability" and establishes a traceable relationship between subsequent test results and business impact.

[0096] II. Propagation Path Analysis and Construction of Targeted Pressure Sub-Scenarios Secondly, analyze the risk propagation critical path sequence output in step S3 (based on propagation intensity). (Sorted), extract the key nodes in the path excluding the starting point. Key nodes include at least service nodes, data nodes, and resource nodes. For different types of key nodes, this embodiment constructs targeted pressure sub-scenarios to simulate their specific pressure patterns: 1. For service nodes: Generate high-concurrency or high-frequency requests to simulate thread pool contention, connection pool exhaustion, or service computing pressure; 2. For data nodes: generate pressure such as high-frequency queries, batch writes, and hot data access to simulate slow queries, lock waits, and cache breakdown; 3. For resource nodes: generate pressure such as I / O intensive operations, network bandwidth consumption, or large object read / write operations to simulate storage throughput bottlenecks and network congestion.

[0097] The purpose of this targeted pressure is that the propagation path provides an explanatory chain of "where the risk may amplify," while targeted pressure transforms the explanatory chain into an executable verification action, enabling the test to not only verify "whether the link is abnormal," but also "whether the abnormality is caused by the critical dependency indicated by the propagation path," thereby reducing the manual cost of subsequent investigation and scenario construction, and improving the usability of the test conclusions.

[0098] III. Construction of Combined Risk Scenarios Furthermore, this embodiment analyzes the dependency structure of the heterogeneous dynamic graph of business and performance, identifies node groups with shared critical dependencies and risk scores exceeding a preset medium-risk threshold, and constructs multi-point combined risk scenarios for concurrent execution for each group. The reason for this is that shared dependencies (such as shared database instances, shared object storage, shared message queues, or shared gateway rate limiting policies) often fail to reach a critical state under single-point stress, while multiple medium-risk nodes concurrently accessing the same dependency are more likely to trigger queue accumulation, connection exhaustion, and cascading latency. Combined risk scenarios can more realistically approximate the triggering conditions of systemic bottlenecks, compensating for the insufficient coverage of the "coupling effect" when only single-link or single-node stress testing is performed.

[0099] IV. Structured Test Plan Generation After constructing the three types of scenarios, this embodiment integrates and orchestrates the main load testing scenario, targeted pressure application sub-scenarios, and combined risk scenarios to generate a structured test plan. The structured test plan defines for each scenario: a unique identifier, target object (a set of links or nodes), execution time period, initial concurrent user count, request rate, and benchmark test duration. The determination of initial parameters references two types of information: firstly, the time-period load distribution in the business profile of step S1 (used to determine the business scale and time-period differences); and secondly, the risk score in step S3 (used to increase the testing intensity of high-risk objects). The formation of the structured test plan makes the subsequent testing process repeatable, comparable, and traceable, and provides the necessary "scenario-target-parameter-result" mapping foundation for the backfeedback calibration in step S5.

[0100] V. Load Distribution Weight Calculation and Global Load Splitting Subsequently, this embodiment calculates the load allocation weight for each test scenario based on three factors: the target risk of the scenario, the load coefficient corresponding to the execution period of the scenario, and the topological centrality of the target in the business-performance heterogeneous dynamic graph.

[0101] Risk quantity is used to reflect "risk objects that should be verified first"; time period load coefficient is used to reflect "real business load background"; topology centrality is used to reflect "criticality in the dependent network", thereby avoiding local optima caused by configuring only according to risk quantity.

[0102] Load distribution weights can be expressed as:

[0103] in, For the first Load allocation weights for each test scenario; Risk fusion coefficient; The load fusion coefficient for the time period; The topological centrality fusion coefficient; The risk level for the scenario target can be taken as the corresponding value when the scenario target is a link. When the scene target is a node, the corresponding value can be retrieved. Alternatively, it can be obtained by aggregating multiple nodes / edges according to scenario rules; The load factor is determined by the time-period load distribution in the service profile of step S1; The topological centrality index of the scene target in the service-performance heterogeneous dynamic graph in step S2; For scene indexing.

[0104] Based on the above weights, the total global test load can be distributed across various scenarios using a normalized split:

[0105] in, To assign to scene Test load limit; This represents the total global test load. This represents the total number of test scenarios; For the scene Load assignment weights; For the first Weights are assigned to the load of each scenario. For scene indexing.

[0106] To avoid situations where "extremely small quotas lead to unmeasurability" or "extremely large quotas lead to uncontrollability" after load splitting, this embodiment introduces a quota constraint threshold for the test load quota of each scenario in the splitting stage: the minimum quota threshold is denoted as... The maximum quota threshold is denoted as and the quota set for all scenarios. Perform pruning and renormalization to ensure that the global total is still satisfied after pruning. The process remains unchanged; in engineering implementation, this "quota range determination-pruning-re-normalization" process can be configured as an executable rule entry. For example, the following JSON rule fragment can be embedded in this stage. (See [link]). Figure 6 ; Wherein, Lambda_min is used for the corresponding Lambda_max is used for the corresponding Lambda_q_set is used for the corresponding Lambda_Sigma is used for the corresponding .

[0107] The evidentiary effect of this load distribution mechanism lies in the fact that when the target object has a high load background at a certain time ( (High) and located in a topologically critical position ( High) and exhibiting a high level of risk ( When it is high, its Significantly increased, thus achieving higher This makes it more likely to approach real bottlenecks with a limited testing budget; conversely, objects with low centrality or low load periods will not be over-configured, reducing waste of testing resources and improving overall testing efficiency.

[0108] VI. Online security control and generation of structured test results During the test performed according to the assigned parameters, this embodiment monitors the system performance indicators in real time. The performance indicators can directly reuse the performance attribute vector of the graph elements in step S2. Delay features in Error rate resource pressure And compare it with the preset risk threshold; When the real-time confidence level of the detected system performance degradation trend exceeds the preset safety threshold, load adjustment operations are dynamically triggered, including reducing concurrency, reducing request rate, extending the low-intensity steady-state phase or shortening the high-intensity phase, in order to verify the risk while avoiding irreversible disturbances to the system.

[0109] To ensure that this online security control has clear criteria and reproducible triggering conditions, this embodiment closes the threshold sign as follows: the error rate security threshold is denoted as... The delay safety threshold is denoted as The resource pressure safety threshold is denoted as The real-time confidence level security threshold is denoted as The load reduction factor when safety control is triggered is denoted as... Used to set the test load quota for the current scenario. Execution ratio adjustment.

[0110] In engineering implementation, the above process of "index determination - confidence threshold - load reduction / stage adjustment - safety abort flag" can be configured as executable rule entries. For example, the following JSON rule fragment can be embedded in this stage for direct execution by the online control module. See [link to relevant documentation]. Figure 7 : Among them, epsilon_safe is used for the corresponding d_safe is used for the corresponding rho_safe is used for corresponding zeta_safe is used for the corresponding beta_drop is used for the corresponding .

[0111] The test continues until the plan is completed or safely terminated, and collects performance metrics, abnormal events, and resource bottleneck information throughout the process to form structured test results. The structured test results include at least: scenario identifier, target object, execution period, load parameters (number of concurrent users / request rate / stage duration), performance time series data, anomaly records, and bottleneck type labeling (service / data / resource).

[0112] In summary, this embodiment achieves an operable mapping from risk quantification and propagation interpretation in step S3 to dynamic performance test plan generation and execution verification in step S4: high-risk links drive the main stress test scenario, propagation critical paths drive targeted stress application sub-scenarios, shared dependencies and medium-risk node groups drive combined risk scenarios, and load adaptive allocation is completed through risk-time-topology three-factor weighting, combined with online security control to ensure the test process is controllable. The resulting structured test results are traceable and can be directly used for subsequent backfeed calibration and closed-loop update in step S5.

[0113] S5. Feed the test results back into the business profile and the business-performance heterogeneous dynamic graph, and calibrate and update the features of the graph intelligence analysis model and the business-performance heterogeneous dynamic graph based on the test results, including: Analyze the structured test results, extract the measured load, performance indicators and anomaly information, and update the load distribution characteristics in the business profile and the node and edge feature sequences in the business-performance heterogeneous dynamic graph according to their corresponding scenarios and objectives. Based on the test results, the consistency between the performance risks previously predicted by the graph intelligent analysis model and the actual test results was evaluated, and the relevant parameters of the model and the feature weights of the corresponding nodes and edges in the graph were calibrated and adjusted according to the evaluation results. When the accumulated updated data meets the conditions or a change in the business model is detected, the retraining of the graph intelligent analysis model and the maintenance of the graph structure are triggered to form a closed-loop iteration.

[0114] Step S5 specifically includes: Step S5 is used to achieve a closed-loop self-updating of "test-profile-graph-model". Its core lies in using the structured test results from step S4 as observational evidence obtained under controllable load disturbances to update the business profile from step S1 and the business-performance heterogeneous dynamic graph from step S2. Furthermore, the test evidence is used to perform consistency evaluation and calibration updates on the graph intelligent analysis model from step S3, thereby solving two common problems in existing technologies: Firstly, performance test results are often statically archived in the form of reports, making it difficult to distill them into reusable profile features and map features, resulting in subsequent tests still relying mainly on experience-based configurations. Secondly, risk prediction models are prone to systematic deviations after system version iterations, changes in dependencies, or changes in business time patterns. However, they lack a quantifiable "prediction-actual test comparison" mechanism to trigger calibration and retraining, ultimately resulting in unstable risk ranking, biased scenario selection, and distorted test load allocation.

[0115] This invention establishes a traceable quantitative closed loop through step S5, enabling the feature sequence of the dynamic map in subsequent step S2 and the risk prediction in step S3 to continuously align with the evolution of the real operating environment, and in turn improves the effectiveness of the dynamic test plan in step S4.

[0116] I. Structured Test Result Analysis and Feedback Update (Focusing on Business Profiles and Graph Feature Sequences) First, the structured test results are analyzed to extract the measured load, performance indicators and anomaly information. Based on the corresponding scenario identifiers and target objects (links / nodes / edges), the load distribution features in the business profile and the node and edge feature sequences in the business-performance heterogeneous dynamic graph are updated respectively.

[0117] The specific process is as follows: 1) Scene alignment and load normalization: For each test scene Read its load limit The execution period is determined and aligned with the load distribution of the same time period in the business profile of step S1 to obtain the "load percentage of that time period under test evidence," which serves as the basis for updating the load distribution characteristics. To avoid drastic fluctuations in the profile due to a single test, this embodiment adopts a fusion update method, which updates the original load coefficients... The updated load coefficient is obtained by weighting and combining the load coefficient with the test load percentage. :

[0118] in, For the reflow of the updated scene Load factor for the corresponding time period; The fusion coefficient; For the scenarios already present in the business profile of step S1 Load factor for the corresponding time period; Assign step S4 to the scene Test load limit; This refers to the total global test load in step S4. For scene indexing.

[0119] The purpose of the above update is to ensure that the business profile not only reflects the distribution of natural online traffic, but also incorporates boundary samples from high-risk periods obtained from risk-driven load testing, thereby enabling subsequent steps in S4 to... When performing adaptive load distribution, it can more closely approximate the actual peak business conditions and risk triggering conditions.

[0120] 2) Target mapping and graph feature sequence refeeding: For each scene The target object is mapped to the graph element in step S2 based on its corresponding graph element identifier (node ​​or edge). The performance time series collected during the test were aggregated into a test observation vector. This is to complete or update the historical feature sequence of map elements.

[0121] To ensure consistency with step S2 In this embodiment, the test observation vectors are organized according to the same field structure:

[0122] in, For graph elements In the time window The performance attribute vector is obtained from test observations; To test the observation delay characteristic value; To test the observation error rate; To test and observe throughput characteristics; To test and observe the characteristic values ​​of resource pressure; Identifiers for map elements; Index for time windows.

[0123] To avoid distortion of the spectral feature sequence due to noise differences between test observations and online observations, this embodiment uses online feature vectors... With test observation vector The fusion process is performed to obtain the updated map feature vector. :

[0124] in, To refill the updated map elements In the time window Internal performance attribute vector; The fusion coefficient; The original performance attribute vector obtained from step S2, which is updated at a fixed period / event. To test the observed performance attribute vector; Identifiers for map elements; Index for time windows.

[0125] The beneficial effects of this refeeding are as follows: the test data is generated driven by the risk scores and propagation paths in step S3, focusing on high-risk links, key dependent nodes, and areas with shared dependencies. After refeeding, the feature sequences in these areas of the graph are denser and more identifiable, which can reduce the dependence of subsequent risk prediction on rare real fault samples, thereby improving the risk boundary identification capability and iteration efficiency.

[0126] (II) Prediction-Measurement Consistency Assessment and Model / Feature Weight Calibration (for Risk Bias Convergence) Secondly, the consistency between the performance risks previously predicted by the graph intelligent analysis model and the actual test results is evaluated based on the test results, and the model parameters and graph feature weights are calibrated and updated accordingly. This step replaces subjective judgment with quantifiable bias, giving the calibration an evidentiary basis.

[0127] 1) Node-level deviation calculation: For the nodes covered by the test Read the anomaly probability of the future prediction window given in step S3. And construct outlier observations within the same prediction window from the structured test results. Calculate the deviation between the predicted and measured values:

[0128] in, For nodes At any moment The deviation between prediction and actual measurement; The nodes predicted in step S3 The probability of an anomaly occurring within the future prediction window; The nodes obtained from the structured test results Anomaly observations within the future forecast window; For node identification; Index for time windows; To predict the step size.

[0129] 2) Element-level deviation summarization and calibration intensity determination: The nodal deviations are summed across the spectral element dimensions to obtain the average deviation of each element. The calibration intensity coefficients are obtained by normalizing them in the set of elements. :

[0130] in, For graph elements The calibration intensity coefficient; For graph elements The average deviation within the test coverage window (by elements) Related (Statistical results) The maximum value of the average deviation among the set of elements participating in the calibration; Used as an identifier for map elements.

[0131] Then As a calibration factor for the feature weights of the graph, elements with larger prediction biases receive more attention in subsequent inference and training. For example, this can be applied to the re-fed feature vectors. Perform weight calibration to obtain the calibrated feature vector. :

[0132] in, The calibrated spectral element feature vectors; For calibrating the intensity coefficient; The feature vector of the map elements after reinjection and fusion; Identifiers for map elements; Index for time windows.

[0133] The purpose of the aforementioned calibration mechanism is to address situations where deployment changes, resource bottleneck migrations, or changes in data hotspots cause persistently large prediction deviations for certain elements. This will improve the feature of the element, making it more significant in subsequent model updates, thereby driving the model parameters to converge in the direction of reducing bias; compared to relying solely on fixed-period retraining, it can align the new distribution faster and reduce the systematic drift of risk prediction, thereby improving the stability of step S4 in generating test plans and allocating loads based on risk scores.

[0134] III. Retraining Triggering and Graph Structure Maintenance (Closed-Loop Iteration Formation) Furthermore, when the accumulated updated data meets the conditions or a change in business model is detected, retraining of the graph intelligent analysis model and maintenance of the graph structure are triggered to form a closed-loop iteration. To provide quantifiable triggering criteria, this embodiment is based on the set of nodes covered in this batch of tests. Construct a global consistency index And compare it with a threshold to determine whether to trigger retraining:

[0135] in, This serves as a global consistency metric for the test batch. This refers to the set of nodes covered in this batch of tests. Size of the set; For nodes The average deviation within the test coverage window (by...) (Statistical results) Used as a node identifier.

[0136] when If the value remains consistently above the preset threshold, or if a large number of new services / interfaces / resource nodes appear, dependencies change significantly, or the value is determined by... When the updated load distribution shows a structural shift, the following actions are triggered: Model retraining: The newly added structured test samples are merged with online samples to form a training batch, and the graph intelligent analysis model is updated. The relevant parameters make the output More consistent with actual observations; Graph structure maintenance: Based on the deployment configuration and link tracing analysis results, the graph topology is maintained, including the incremental addition of new nodes and edges, the deletion of failed dependent edges, and the continuous repair of node / edge feature sequences, to ensure that the dynamic graph topology and feature attributes in step S2 continuously reflect the real operating environment.

[0137] Through the above closed-loop iteration, step S5 will convert the structured test evidence from step S4 into a continuous source for updating the business profile load distribution and dynamic graph feature sequence, and transform the prediction-test deviation into a calibration signal and retraining trigger basis for the model and feature weights.

[0138] Finally, the updated business profile, the dynamic graph of heterogeneous business-performance, and the calibrated intelligent analysis model of the graph are stored and called as the input basis for the next round of steps S2 to S4, thereby completing the closed-loop iteration of dynamic performance testing and ensuring the integrity and sustainable evolution capability of the method system of this invention.

[0139] Example 2: A system employing a dynamic performance testing method based on business profiling and intelligent analysis, characterized in that it includes:

[0140] The module comprises the following components: Business Profile Construction Module: Based on multi-source data from the business system, it constructs a business profile containing a set of high-frequency business links and a candidate set of key interfaces through business event standardization and process mining; Heterogeneous Dynamic Graph Module: Based on the business profile, it maps business entities and system components to heterogeneous nodes and establishes multiple types of edges, forming a business-performance heterogeneous dynamic graph that is updated by event triggers as business and system states change; Risk Prediction and Inference Module: It applies a graph intelligence analysis model to the business-performance heterogeneous dynamic graph to calculate the performance risk scores of nodes and links within the future prediction window and infers the propagation path of risks along dependencies; Dynamic Load Testing Execution Module: Based on the performance risk scores and propagation paths, it generates dynamic performance test plans for high-risk links and key nodes, and adaptively allocates and executes test loads based on risk weights and business time period characteristics to obtain test results; Feedback Calibration and Update Module: It feeds the test results back to the business profile and the business-performance heterogeneous dynamic graph, and calibrates and updates the features of the graph intelligence analysis model and the business-performance heterogeneous dynamic graph based on the test results.

[0141] The technical features of this invention not described can be implemented by or using existing technology, and will not be repeated here. Of course, the above description is not a limitation of this invention, and this invention is not limited to the examples above. Any changes, modifications, additions or substitutions made by those skilled in the art within the scope of this invention should also be within the protection scope of this invention.

Claims

1. A dynamic performance testing method based on business profiling and intelligent analysis, characterized in that, Includes the following steps: S1. Based on multi-source data from the business system, a business profile is constructed by standardizing business events and mining processes, including a set of high-frequency business links and a candidate set of key interfaces. S2. Based on the business profile, business entities and system components are mapped to heterogeneous nodes and multiple types of edges are established to form a business-performance heterogeneous dynamic graph that is updated by event triggering as business and system states change. S3. A graph intelligence analysis model is applied to the business-performance heterogeneous dynamic graph to calculate the performance risk scores of nodes and links within the future prediction window, and to infer the propagation path of risk along dependencies. S4. Based on the performance risk score and propagation path, generate a dynamic performance test plan for high-risk links and key nodes, and adaptively allocate test load and execute it based on risk weight and business time period characteristics to obtain test results. S5. Feed the test results back into the business profile and the business-performance heterogeneous dynamic graph, and calibrate and update the features of the graph intelligent analysis model and the business-performance heterogeneous dynamic graph based on the test results.

2. The dynamic performance testing method based on business profiling and intelligent analysis according to claim 1, characterized in that, Based on multi-source data from business systems, and through business event standardization and process mining, a business profile is constructed that includes a set of high-frequency business links and a candidate set of key interfaces. This includes obtaining business event logs, link tracing data, and resource monitoring data from business systems. The business event logs are standardized by mapping log entries to standardized event records with a unified field structure based on a preset business event ontology, and the records are cleaned. Based on project and role identifiers, the cleaned standardized event records are sorted by time to form a sequence of business activities; The process mining technique is applied to the business activity sequence. By analyzing the direct follow-up relationship between events, event sequences with an occurrence frequency exceeding a set threshold are extracted as high-frequency business links, and their transfer probability and time consumption characteristics are statistically analyzed to form a set of high-frequency business links. Based on the high-frequency business link set, call frequency data, business criticality weight, and historical fault records, the candidate set of key interfaces and the candidate set of key services are determined by integrating the screening logic of multi-dimensional evaluation indicators. Finally, the high-frequency business link set, key interface and service candidate set, role-link relationship and time period load distribution are integrated to form the business profile.

3. The dynamic performance testing method based on business profiling and intelligent analysis according to claim 2, characterized in that, The process of mapping business entities and system components to heterogeneous nodes and establishing multiple types of edges based on the business profile includes: defining and instantiating multiple types of heterogeneous nodes representing business activities, service interfaces, data entities and infrastructure resources based on the high-frequency business link set, key interface candidate set and key service candidate set in the business profile. Based on the dependency and flow relationships parsed from link tracing data, business logs and deployment configurations, multiple types of directed edges, including at least business transfer edges, call dependency edges, data dependency edges and deployment mapping edges, are established between the heterogeneous nodes. The business transfer edge connects business nodes based on the sequence of steps in the high-frequency business link; the call dependency edge connects service nodes based on the inter-service call relationship; the data dependency edge connects service nodes and data nodes based on the service's access relationship to data; and the deployment mapping edge connects service nodes and resource nodes based on the deployment bearing relationship, thus constructing a graph skeleton that reflects the system structure and business flow.

4. The dynamic performance testing method based on business profiling and intelligent analysis according to claim 3, characterized in that, The formation of the service-performance heterogeneous dynamic graph that is updated via event triggering as business and system states change includes: A hybrid update mechanism that integrates fixed-period and event-triggered updates is designed and implemented for the graph skeleton. The fixed-period update is as follows: aggregate multi-source monitoring data according to a preset time window, calculate the performance status feature values ​​of each node and edge, and update the corresponding elements of the graph as attribute vectors; The event-triggered update is as follows: real-time monitoring of business and system metrics, and when an event that meets predefined conditions is detected, a targeted adjustment to the graph structure or edge weights is immediately triggered. The event includes at least sudden changes in business load, changes in deployment configuration, changes in business link structure, or changes in service dependencies. Through the hybrid update mechanism, the topology and feature attributes of the graph can dynamically evolve with the real operating environment, forming the business-performance heterogeneous dynamic graph.

5. The dynamic performance testing method based on business profiling and intelligent analysis according to claim 4, characterized in that, Applying a graph intelligent analysis model to the business-performance heterogeneous dynamic graph to calculate the performance risk score of nodes and links within a future prediction window includes: based on the historical feature sequence of nodes and the topological relationship of edges in the business-performance heterogeneous dynamic graph, using a pre-trained graph intelligent analysis model to perform joint spatiotemporal feature learning, and predicting the probability of each node experiencing performance anomalies within a future time window. By combining the impact weights that reflect the importance of node services, the probability of performance anomalies is converted into a performance risk score for the node. For a link, based on the real-time status of its node sequence and edges, the overall performance risk score of the link is calculated by aggregating the performance risk scores of each node and the performance indicators of the edges.

6. The dynamic performance testing method based on business profiling and intelligent analysis according to claim 5, characterized in that, The method of inferring the propagation path of risk along dependencies includes: starting from the initial high-risk node identified by the performance risk score, and based on the dependencies of various edges in the business-performance heterogeneous dynamic graph and the preset propagation coefficients, simulating or analyzing the diffusion process of risk in the graph network through graph algorithms. Identify nodes that play a key role in the transfer or amplification of risk during its spread as key propagation nodes; Based on the connectivity of the graph, the path from the initial high-risk node to each critical propagation node is searched and evaluated. The propagation intensity of each path is calculated based on the risk value of the node and the edge propagation coefficient. The critical path sequence of risk propagation is output based on the propagation intensity.

7. The dynamic performance testing method based on business profiling and intelligent analysis according to claim 6, characterized in that, The process of generating a dynamic performance test plan for high-risk links and key nodes based on the performance risk score and propagation path includes: selecting high-risk business links to be tested based on the link performance risk score ranking results and preset high-risk thresholds, and converting them into a stress test master scenario that can simulate user operation sequences; The propagation path is analyzed, and key service, data, and resource nodes other than the starting point are extracted. For each type of key node, a targeted pressure sub-scenario is designed to simulate its specific pressure. The dependency structure of the business-performance heterogeneous dynamic graph is analyzed, and node groups with shared key dependencies and risk scores of medium or higher are identified. For each group, a multi-point combined risk scenario for concurrent execution is constructed. The main load testing scenario, the targeted pressure application sub-scenario, and the combined risk scenario are integrated and arranged to generate a structured test plan. The plan defines a unique identifier for each scenario, the specific target it targets, and the initial number of concurrent users, request rate, and benchmark test duration parameters determined based on historical load and risk scores in the business profile.

8. The dynamic performance testing method based on business profiling and intelligent analysis according to claim 7, characterized in that, The process of adaptively allocating and executing test loads based on risk weights and business time period characteristics to obtain test results includes: calculating the load allocation weights for each scenario based on the performance risk score of the target for each test scenario, the historical load coefficient in the business profile corresponding to the execution time of the scenario, and the topological centrality of the target in the business-performance heterogeneous dynamic graph through weighted fusion, and allocating the total global test load to the specific number of concurrent users, request rate, and test phase duration for each scenario based on the weights. During the test execution according to the allocated parameters, the system performance indicators are monitored in real time and compared with the predicted risk threshold. When the real-time confidence of the system performance deterioration trend exceeds the preset safety threshold, the load adjustment operation is dynamically triggered. The test is continuously executed until the plan is completed or safely terminated, and the performance indicator data, abnormal events and resource bottleneck information of the whole process are collected to form a structured test result containing load parameters, performance timing and abnormal records.

9. The dynamic performance testing method based on business profiling and intelligent analysis according to claim 8, characterized in that, The step of feeding the test results back into the business profile and the business-performance heterogeneous dynamic graph, and calibrating and updating the features of the graph intelligent analysis model and the business-performance heterogeneous dynamic graph based on the test results includes: The structured test results are analyzed to extract the measured load, performance indicators and anomaly information. Based on the corresponding scenarios and objectives, the load distribution characteristics in the business profile and the node and edge feature sequences in the business-performance heterogeneous dynamic graph are updated. Based on the test results, the consistency between the performance risks previously predicted by the graph intelligent analysis model and the actual test results is evaluated, and the relevant parameters of the model and the feature weights of the corresponding nodes and edges in the graph are calibrated and adjusted according to the evaluation results. When the accumulated updated data meets the conditions or a change in the business model is detected, the retraining of the graph intelligent analysis model and the maintenance of the graph structure are triggered to form a closed-loop iteration.

10. A system employing the dynamic performance testing method based on business profiling and intelligent analysis as described in any one of claims 1-9, characterized in that, include: Business profile building module: Based on multi-source data from business systems, it constructs a business profile that includes a set of high-frequency business links and a candidate set of key interfaces through business event standardization and process mining; Heterogeneous Dynamic Graph Module: Based on the business profile, business entities and system components are mapped as heterogeneous nodes and multiple types of edges are established to form a business-performance heterogeneous dynamic graph that is updated by event triggers as the business and system states change; Risk Prediction and Inference Module: Applying a graph intelligence analysis model to the business-performance heterogeneous dynamic graph, calculating the performance risk scores of nodes and links within the future prediction window, and inferring the propagation path of risk along dependencies; Dynamic load testing execution module: Based on the performance risk score and propagation path, it generates dynamic performance test plans for high-risk links and key nodes, and adaptively allocates test load and executes them based on risk weight and business time period characteristics to obtain test results; Feedback calibration update module: Feeds back the test results to the business profile and the business-performance heterogeneous dynamic graph, and calibrates and updates the features of the graph intelligent analysis model and the business-performance heterogeneous dynamic graph based on the test results.

Images