A testing method and system based on financial environment stability

Abstract

The present invention relates to the field of financial service technology, and in particular to a testing method and system based on the stability of a financial environment. The method comprises the following steps: real-time status monitoring of a financial transaction system to generate basic system status data; constructing a virtual test environment based on the basic system status data, and performing adaptive configuration of test scenarios to generate test environment parameter data; performing multi-dimensional stress test analysis on the test environment parameter data, and calculating system stability indicators to generate stability benchmark data; performing dynamic load gradient processing based on the stability benchmark data to obtain system pressure gradient data; performing risk level mapping on the system pressure gradient data to generate risk assessment mapping data. By constructing a virtual test environment and performing adaptive configuration, the present invention can simulate real transaction scenarios, improve the relevance and effectiveness of the test, and ensure the stable operation of the system under different stress conditions.

Description

Technical Field

[0001] The present invention relates to the technical field of financial services, and in particular to a testing method and system based on financial environment stability. Background Art

[0002] Financial environment stability refers to the ability of the financial system to maintain normal operation, resist risk shocks, and ensure that financial institutions and markets can trade and clear smoothly under the influence of various internal and external environmental factors. The stability of the financial environment involves multiple aspects, including the robustness of financial institutions, the liquidity of financial markets, the ability to prevent and control systemic risks, and the effectiveness of macroeconomic policies. The stability of the financial environment includes the robustness of the financial system, the liquidity of financial markets, the ability to prevent and control systemic risks, the reliability of financial infrastructure, and risk management and early warning mechanisms. Testing the stability of the financial environment is a key process to evaluate and ensure that the financial system can operate stably under different stress conditions. This test can help financial institutions, regulators and other market participants identify potential risks in advance and take measures to prevent the outbreak of systemic financial risks. The following is a detailed explanation of the financial environment stability test, covering the purpose of the test, key test indicators, common methods and specific test processes. However, traditional testing methods are difficult to fully cover multi-dimensional parameters such as the number of concurrent users, transaction frequency, and transaction complexity; they usually rely only on static stress test results and lack the ability to respond to real-time changes in the system; especially in large-scale trading scenarios, previous system tests have difficulty in quickly locating and identifying system bottlenecks. Summary of the invention

[0003] Based on this, it is necessary for the present invention to provide a testing method and system based on the stability of the financial environment to solve at least one of the above technical problems.

[0004] To achieve the above purpose, a testing method based on financial environment stability includes the following steps:

[0005] Step S1: Real-time status monitoring of the financial transaction system is performed to generate basic system status data; a virtual test environment is constructed based on the basic system status data, and test scenario adaptive configuration is performed to generate test environment parameter data;

[0006] Step S2: Perform multi-dimensional stress test analysis on the test environment parameter data, calculate the system stability index, and generate stability benchmark data; perform dynamic load gradient processing based on the stability benchmark data to obtain system pressure gradient data; perform risk level mapping on the system pressure gradient data to generate risk assessment mapping data;

[0007] Step S3: using the distributed monitoring system to collect abnormal behavior characteristics of the financial transaction system and generate abnormal behavior characteristic data; performing fault pattern recognition on the abnormal behavior characteristic data, establishing a fault warning threshold, and generating warning trigger condition data;

[0008] Step S4: Perform multi-dimensional performance analysis based on the system monitoring data acquired in real time to obtain performance indicator data, wherein the multi-dimensional performance includes multi-dimensional performance, resource utilization dimension, business processing dimension and reliability dimension; perform correlation analysis on the system pressure gradient data and the performance indicator data, identify bottlenecks, and generate performance bottleneck location data;

[0009] Step S5: Perform risk level assessment on the performance bottleneck location data through the early warning trigger condition data to obtain risk assessment data; construct a system recovery strategy based on the risk assessment data to generate fault recovery plan data; perform simulation verification on the fault recovery plan data, and generate a recovery strategy based on the simulation results to obtain recovery strategy data;

[0010] Step S6: Use the risk assessment mapping data and the recovery strategy data to perform stability assessment on the financial transaction system, thereby obtaining environmental stability assessment data.

[0011] The present invention also provides a testing system based on financial environment stability, which is used to execute the above-mentioned testing method based on financial environment stability. The testing system based on financial environment stability includes:

[0012] The environment construction module is used to monitor the real-time status of the financial transaction system and generate basic system status data; build a virtual test environment based on the basic system status data, perform adaptive configuration of the test scenario, and generate test environment parameter data;

[0013] The pressure assessment module is used to perform multi-dimensional pressure test analysis on the test environment parameter data, calculate the system stability index, and generate stability benchmark data; perform dynamic load gradient processing based on the stability benchmark data to obtain system pressure gradient data; perform risk level mapping on the system pressure gradient data to generate risk assessment mapping data;

[0014] The abnormal monitoring module is used to collect abnormal behavior characteristics of the financial transaction system using a distributed monitoring system and generate abnormal behavior characteristic data; perform fault pattern recognition on the abnormal behavior characteristic data, establish fault warning thresholds, and generate warning trigger condition data;

[0015] The performance diagnosis module is used to perform multi-dimensional performance analysis based on the real-time acquired system monitoring data to obtain performance indicator data, where the multi-dimensional performance includes multi-dimensional performance, resource utilization dimension, business processing dimension and reliability dimension; correlate the system pressure gradient data with the performance indicator data, identify bottlenecks, and generate performance bottleneck location data;

[0016] The recovery strategy module is used to evaluate the risk level of the performance bottleneck location data through the early warning trigger condition data to obtain risk assessment data; build a system recovery strategy based on the risk assessment data to generate fault recovery plan data; simulate and verify the fault recovery plan data, and generate a recovery strategy based on the simulation results to obtain recovery strategy data;

[0017] The stability assessment module is used to perform stability assessment on the financial transaction system using risk assessment mapping data and recovery strategy data, thereby obtaining environmental stability assessment data.

[0018] The present invention can quickly identify the operating status and potential problems of the system through real-time status monitoring, ensuring the high availability of the system; the generation of basic data of system status provides a reliable data basis for subsequent analysis, which helps decision makers make more scientific choices when optimizing system configuration; the constructed virtual test environment can simulate real transaction scenarios, provide a safe and reliable test platform for subsequent stress testing and performance evaluation, and reduce the risk of actual system operation; the adaptive configuration of the test scenario enables the environmental parameters to be dynamically adjusted according to the actual situation, improves the relevance and effectiveness of the test, and better reflects the performance of the system in real scenarios. Through multi-dimensional stress test analysis, the performance of the system under different stress conditions can be comprehensively evaluated, and the performance bottleneck of the system can be identified; the generated stability benchmark data provides an important reference for subsequent performance optimization, helping to identify the boundary between normal operation and abnormal state; dynamic load gradient processing can more accurately reflect the carrying capacity of the system, ensuring that the system can remain stable under high load; by mapping the risk level of pressure gradient data, potential high-risk areas can be discovered in time, providing data support for risk management and control. By collecting abnormal behavior characteristics, abnormal situations in system operation can be discovered in time, improving the sensitivity and response speed of the system; the identification of abnormal behavior can help system administrators locate the root cause of the problem more quickly and reduce the impact of failures on business. Establishing fault warning thresholds and trigger conditions can help to intervene in time before the problem escalates, reducing the risk of system crash or severe performance degradation. Multi-dimensional performance analysis provides a comprehensive understanding of system performance and identifies key factors that affect business processing efficiency; by combining pressure gradient data with performance indicators, the analysis method can accurately identify system bottlenecks and improve the pertinence of performance optimization; performance bottleneck location data can provide a clear direction for system improvement and optimization and enhance the overall efficiency of the system. The risk level assessment of performance bottlenecks provides data support for the subsequent recovery strategy formulation, making the recovery measures more scientific and effective; the recovery strategy built based on the assessment data ensures that problems can be responded to quickly and the time of business interruption can be reduced. Simulation testing of the recovery plan can discover deficiencies in the plan in advance, thereby reducing risks and resource waste in actual operations and improving the effectiveness of the recovery plan. By comprehensively analyzing risk assessment and recovery strategies, the stability of the system can be comprehensively evaluated to ensure that the system can operate stably under different circumstances; environmental stability assessment data provides key decision-making support for management, helping them consider potential risks when adjusting and optimizing the system. Regular stability assessment can improve system reliability, enhance business continuity, and ensure that high availability and consistency can always be provided in financial transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments thereof made with reference to the following drawings:

[0020] Figure 1 It is a schematic diagram of the steps of the testing method based on the stability of the financial environment of the present invention;

[0021] Figure 2 for Figure 1 Detailed step flow diagram of step S1;

[0022] Figure 3 for Figure 1 Detailed step flow chart of step S2 in FIG. DETAILED DESCRIPTION

[0023] The technical method of the present invention is described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by technicians in this field without creative work are within the scope of protection of the present invention.

[0024] In addition, the accompanying drawings are only schematic illustrations of the present invention and are not necessarily drawn to scale. The same reference numerals in the figures represent the same or similar parts, and their repeated description will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. The functional entities can be implemented in software form, or implemented in one or more hardware modules or integrated circuits, or implemented in different networks and / or processor methods and / or microcontroller methods.

[0025] It should be understood that, although the terms "first", "second", etc. may be used herein to describe various units, these units should not be limited by these terms. These terms are used only to distinguish one unit from another unit. For example, without departing from the scope of the exemplary embodiments, the first unit may be referred to as the second unit, and similarly the second unit may be referred to as the first unit. The term "and / or" used herein includes any and all combinations of one or more of the listed associated items.

[0026] To achieve this, please refer to Figures 1 to 3 The present invention provides a testing method based on financial environment stability, the method comprising the following steps:

[0027] Step S1: Real-time status monitoring of the financial transaction system is performed to generate basic system status data; a virtual test environment is constructed based on the basic system status data, and test scenario adaptive configuration is performed to generate test environment parameter data;

[0028] In a financial transaction system, an embodiment of the present invention installs a distributed monitoring agent to monitor the status of each module of the system in real time, collect system-level data including CPU usage, memory usage, disk I / O, network transmission rate, etc., obtain database status data such as the number of database connections, the number of active sessions, and SQL execution time, as well as middleware status data such as message queue depth and processing delay. Then, a virtual test environment is constructed based on these monitoring data. For example, hardware resources such as the number of CPU cores, memory capacity, and network bandwidth configured in the virtual environment are adjusted according to the status of the actual financial transaction system. In addition, the system will perform adaptive configuration according to the characteristics of the scenario, such as the number of concurrent users and transaction frequency in the transaction scenario, and finally generate test environment parameter data to ensure that the simulation environment truly reflects the status of the actual system.

[0029] Step S2: Perform multi-dimensional stress test analysis on the test environment parameter data, calculate the system stability index, and generate stability benchmark data; perform dynamic load gradient processing based on the stability benchmark data to obtain system pressure gradient data; perform risk level mapping on the system pressure gradient data to generate risk assessment mapping data;

[0030] According to the test environment parameter data generated in step S1, the stress test of the financial system in the embodiment of the present invention includes simulating thousands of concurrent transaction requests, gradually increasing the number of concurrent users and transaction complexity. In this process, multi-dimensional stress tests are performed on the system's transaction capabilities, database read and write capabilities, network bandwidth, etc. For example, start with 1,000 concurrent users and increase 1,000 users each time until the system crashes or the response time significantly exceeds the preset threshold. Based on these test results, the stability benchmark data of the system is generated to record the stability performance of the system under different loads. Subsequently, using these benchmark data, dynamic load gradient processing is performed to generate system pressure gradient data, and based on the risk level model, the gradient data is mapped to risk levels, and risk assessment mapping data is output.

[0031] Step S3: using the distributed monitoring system to collect abnormal behavior characteristics of the financial transaction system and generate abnormal behavior characteristic data; performing fault pattern recognition on the abnormal behavior characteristic data, establishing a fault warning threshold, and generating warning trigger condition data;

[0032] The embodiment of the present invention collects abnormal behavior data of the financial transaction system in real time through a distributed monitoring system, including abnormal phenomena such as memory leaks, abnormal CPU usage, and too many database connections. These abnormal data are preprocessed using time series analysis tools, such as detecting abnormal points on resource usage curves of different modules. Then, a machine learning-based fault pattern recognition model is used to identify common fault types of the system, such as database connection pool saturation, message queue accumulation, etc., and generate fault warning thresholds. These thresholds will serve as warning trigger conditions to ensure that the system issues a warning before the critical point of the fault so that recovery measures can be taken in time.

[0033] Step S4: Perform multi-dimensional performance analysis based on the system monitoring data acquired in real time to obtain performance indicator data, wherein the multi-dimensional performance includes multi-dimensional performance, resource utilization dimension, business processing dimension and reliability dimension; perform correlation analysis on the system pressure gradient data and the performance indicator data, identify bottlenecks, and generate performance bottleneck location data;

[0034] The embodiment of the present invention constructs a multi-dimensional performance analysis model based on the system monitoring data collected in real time, and performs performance analysis from the system layer, resource layer and business layer respectively. For example, at the resource layer, the focus is on analyzing dimensions such as CPU, memory, disk and network utilization; at the business layer, indicators such as transaction success rate, transaction response time, and clearing efficiency are analyzed. By correlating and analyzing these performance data with the system pressure gradient data generated in step S2, the system can identify performance bottlenecks under high load conditions, such as slow database query speed, insufficient network bandwidth, etc. Subsequently, the performance bottleneck point is located through link tracking technology to generate performance bottleneck location data.

[0035] Step S5: Perform risk level assessment on the performance bottleneck location data through the early warning trigger condition data to obtain risk assessment data; construct a system recovery strategy based on the risk assessment data to generate fault recovery plan data; perform simulation verification on the fault recovery plan data, and generate a recovery strategy based on the simulation results to obtain recovery strategy data;

[0036] The embodiment of the present invention evaluates the risk level of the current system based on the aforementioned performance bottleneck location data and the warning trigger condition data generated in step S3. For example, if it is monitored that the response time of a certain database instance continues to exceed the warning threshold, the system will automatically trigger the corresponding fault warning. Next, based on the risk assessment data, the system will refer to the historical fault recovery solution library to build a recovery strategy suitable for the current scenario. The recovery strategy may include measures such as resource expansion, load balancing, and service degradation. The generated fault recovery solution is simulated and tested, and the effectiveness of the solution is evaluated by testing parameters such as system recovery time, fault resolution rate, and resource consumption, and optimization is performed based on the test results to generate the final recovery strategy data.

[0037] Step S6: Use the risk assessment mapping data and the recovery strategy data to perform stability assessment on the financial transaction system, thereby obtaining environmental stability assessment data.

[0038] The embodiment of the present invention uses the risk assessment mapping data in step S2 and the recovery strategy data in step S5 to perform an overall stability assessment on the financial transaction system. In practical applications, the system will assess the stability of the financial transaction system based on the current load conditions and historical benchmark data, such as predicting the system risk level and potential failure points in the future. Through this real-time assessment, the system can discover and resolve potential performance bottlenecks or resource bottlenecks in advance, ensuring the long-term stability of the financial environment.

[0039] As an embodiment of the present invention, refer to Figure 2 As shown, Figure 1 Detailed step flow diagram of step S1 in the embodiment of the present invention, step S1 includes the following steps:

[0040] Step S11: Collect basic system operation parameters of the financial transaction system to generate basic performance data, where the basic system operation parameters include CPU usage, memory occupancy, disk IO, and network transmission rate;

[0041] In the financial transaction system, the embodiment of the present invention uses system performance monitoring tools such as Prometheus or Zabbix to collect the basic operating parameters of the system in real time. Specifically, by monitoring the CPU usage of the system, the CPU occupancy of the system at different transaction peaks is recorded; through the memory monitoring module, the dynamic changes of the memory usage are tracked to ensure stable memory usage; the disk I / O monitoring evaluates the disk performance of the system by tracking the disk read and write speed and waiting time; the network transmission rate measures the system network bandwidth usage and transmission efficiency by capturing network traffic data packets, and finally generates basic performance data containing these parameters as a basic reference for the system operation status.

[0042] Step S12: Obtain the number of database connections, the number of active sessions, the SQL execution time, and the lock waiting status of the financial transaction system, thereby generating database status data;

[0043] The embodiment of the present invention monitors the number of database connections and active sessions in the financial transaction system through database monitoring tools such as Oracle Enterprise Manager or MySQL Workbench. The collected SQL execution time data includes the execution time of each query, and the lock waiting situation is determined by analyzing the lock log and waiting queue of the database to determine whether there is a resource competition problem. Through these monitoring tools, the data is analyzed and processed, and the system generates database status data for further evaluating the operating efficiency and health of the database.

[0044] Step S13: monitor the message queue depth, message processing delay and message accumulation of the financial transaction system in real time, and generate middleware status data; monitor the key processes and thread status of the financial transaction system, and generate process status data;

[0045] The embodiment of the present invention uses a message queue monitoring tool such as Kafka Monitor or RabbitMQ ManagementPlugin to monitor the message queue depth in the financial transaction system in real time and track the message accumulation of the system in a high-concurrency transaction scenario. At the same time, the message processing delay data is collected to evaluate the delay time from the extraction of the message from the queue to the actual completion of the processing. The monitoring of key processes and thread states is carried out through process monitoring tools such as Grafana integrated with Prometheus to collect the CPU and memory usage of the process, as well as the concurrent status of the thread, to ensure the normal operation of the system core process under high load, and generate middleware status data and process status data.

[0046] Step S14: collecting the business operation status of the financial transaction system to obtain transaction performance data, clearing status data and risk control status data, wherein the risk control status data includes transaction processing time, transaction success rate and transaction concurrency, the clearing status data includes clearing processing efficiency, fund arrival time and reconciliation consistency, and the risk control status data includes risk control rule response time, risk control interception rate and risk control accuracy rate;

[0047] In the process of business operation of the financial transaction system, the embodiment of the present invention collects transaction performance data in real time through a business monitoring system, such as an ELK (Elasticsearch, Logstash, Kibana) stack based on log analysis. The transaction performance data includes the processing time, transaction success rate and transaction concurrency of each transaction. The clearing status data is obtained through the clearing system interface, including the clearing efficiency, fund arrival time and consistency data of the end-of-day reconciliation. The collection of risk control status data monitors the response time, interception rate and accuracy of the risk control rules through the risk control system interface, thereby comprehensively analyzing the business operation status of the financial transaction system and generating corresponding transaction, clearing and risk control status data.

[0048] Step S15: performing time serialization processing on basic performance data, database status data, middleware status data and process status data to generate system layer status sequence data;

[0049] The embodiment of the present invention uses a time series database such as InfluxDB to store and process the basic performance data, database status data, middleware status data and process status data collected from step S11 to step S13 in chronological order. Specifically, by time-stamping each monitoring indicator, the system status changes at each moment are recorded as time series data. For example, data such as CPU usage and memory occupancy are recorded at the second level, and the number of database connections and SQL execution time are collected at the minute level, and system-level status sequence data is generated through time serialization processing to facilitate subsequent trend analysis and status prediction.

[0050] Step S16: Perform business correlation analysis on the transaction performance data, liquidation status data, and risk control status data to generate business layer status correlation data;

[0051] The embodiment of the present invention uses correlation analysis tools such as Tableau or Power BI to perform correlation analysis on business layer data for the transaction performance data, liquidation status data, and risk control status data generated in step S14. For example, the system analyzes the correlation between transaction performance and liquidation efficiency, and evaluates the impact of transaction processing time on liquidation efficiency; at the same time, through correlation analysis of risk control status data, the relationship between risk control interception rate and transaction concurrency is determined, and business layer status correlation data is generated to help system operation and maintenance personnel identify business bottlenecks and potential risk factors.

[0052] Step S17: merging the system layer state sequence data and the business layer state association data into system state basic data;

[0053] The embodiment of the present invention merges the system layer state sequence data generated in step S15 with the business layer state association data generated in step S16. Through data fusion tools such as Apache NiFi, data from different sources are aligned in chronological order to ensure the synchronization of system layer data and business layer data. In actual operation, the system layer data and business layer data are first converted into a unified data format, and then unified system state basic data is generated through comparison and association analysis of time series data, providing a basis for the construction of subsequent test environment.

[0054] Step S18: construct a virtual test environment according to the basic system status data, and perform adaptive configuration of the test scenario to generate test environment parameter data.

[0055] According to the basic system status data generated in step S17, the embodiment of the present invention uses virtualization technology such as VMware or Docker to build a virtual test environment similar to a real financial transaction system. During the construction process, the system adaptively configures the hardware resources in the virtual environment, such as virtual CPU, memory, storage and network parameters, according to the transaction volume, concurrency, and clearing efficiency of the actual scenario. For example, if the basic system status data shows that high-concurrency transactions occur frequently, a disk with high network bandwidth and fast I / O will be configured in the virtual environment. Finally, test environment parameter data is generated to ensure that the virtual test scenario can truly reflect the operating status of the actual system.

[0056] The basic performance data of the present invention reflects the hardware resource consumption and overall health status of the system, and provides a basis for judging the system load and performance bottleneck. This step ensures dynamic monitoring of system resources, so as to timely discover abnormal or overload conditions, and facilitate rapid measures to prevent system performance degradation. Obtaining database status data can reflect the operating load, efficiency and potential bottlenecks of the database. By monitoring these key database performance indicators, system managers can understand the processing capacity of the database, avoid database performance degradation caused by excessive number of connections or lock waiting problems, and ensure the database response speed and stability during the transaction process. Real-time monitoring of message queue depth, message processing delay and accumulation, generating middleware status data, helps to identify the message processing efficiency in the transaction system. Especially in a high-concurrency transaction environment, the health of the message queue directly affects the response speed and reliability of the system. In addition, monitoring key processes and thread states to generate process status data can ensure the normal operation of the core functional modules of the system and avoid system failures or delays caused by key process or thread abnormalities. Collecting business operation status data, including transaction performance, clearing status and risk control status, can generate specific business performance data. These data not only reflect the operating efficiency of the trading system, but also help system managers grasp key business indicators such as transaction success rate, risk control response time, and clearing processing efficiency. By deeply understanding these data, the system can better optimize business processes, improve overall efficiency and accuracy, and play an important role in optimizing risk control and clearing links. The basic performance data, database status data, middleware status data, and process status data are processed in time series to generate system-level status sequence data. This time series can reflect the changing trend of the system status and help identify potential performance degradation or abnormal conditions, so that system administrators can predict the direction of system load by comparing historical data and take preventive measures in advance. Business correlation analysis is performed on transaction performance data, clearing status data, and risk control status data to generate business-level status correlation data. This step can identify the mutual influence between different business functions by correlating business-level data. For example, the impact of risk control rules on transaction processing, or the relationship between clearing efficiency and overall capital flow, helps optimize business logic and system processes, thereby improving overall operational efficiency. The system-level status sequence data and business-level status correlation data are merged into system-level status basic data. Through this data integration, the system can form a global understanding of the operating status, not only to see the situation at the system resource level, but also to understand the health of the business process. This provides an important data foundation for subsequent virtual testing and optimization, and helps to improve the pertinence and effectiveness of the test. Based on the actual operating status, the system conducts scenario simulation and stress testing to ensure that the test environment can accurately reflect the actual operation of the system, and adaptively configures according to different scenarios to improve the accuracy and comprehensiveness of the test.

[0057] Preferably, step S18 comprises the following steps:

[0058] Step S181: Perform hardware resource configuration based on the number of CPU cores, memory capacity, storage space, and network bandwidth according to the basic system status data, perform database instance configuration based on the connection pool size, cache size, and execution plan optimization parameter, and perform middleware parameter configuration based on the message queue size, thread pool parameters, and cache strategy, thereby obtaining environmental parameter configuration data;

[0059] According to the basic data of the system status, the embodiment of the present invention first uses an automated configuration tool such as Ansible or Terraform to configure the hardware resources of the virtual environment. Specifically, the system will dynamically allocate corresponding virtual machine resources according to the actual number of CPU cores, memory capacity, storage space and network bandwidth requirements. For example, when a higher concurrent transaction load is shown in the basic data of the system status, the system will configure more CPU cores and larger memory to process transaction requests. At the same time, based on the configuration requirements of the database instance, the connection pool size, cache size and execution plan optimization parameters of the database are adjusted to improve query efficiency. For the parameter configuration of the middleware, the system optimizes the middleware performance according to the size of the message queue, the concurrency parameters of the thread pool and the requirements of the cache strategy, and finally generates the environmental parameter configuration data.

[0060] Step S182: constructing a transaction scenario model based on the transaction performance data to generate transaction scenario data, wherein the transaction scenario data includes transaction type distribution, transaction frequency pattern, and transaction size distribution;

[0061] The embodiment of the present invention constructs a transaction scenario model by analyzing transaction performance data using simulation tools such as LoadRunner or JMeter. The model reflects the transaction type distribution, transaction frequency and transaction scale in the actual transaction scenario. For example, for the transaction scenario of retail banks, the system simulates different types of transactions based on historical data, such as fund transfers, bill payments and credit card repayments, and generates the distribution of transaction peak and trough periods through the transaction frequency model. At the same time, the transaction scale distribution is generated based on historical transaction volume statistics, such as the distribution range of single transaction amounts and the concentration of high-frequency transactions, and finally generates transaction scenario data for subsequent test scenarios.

[0062] Step S183: constructing a liquidation scenario model based on the liquidation status data to generate liquidation scenario data, wherein the liquidation scenario data includes liquidation batches, liquidation scales, and liquidation time windows;

[0063] The embodiment of the present invention uses a clearing simulation system to construct a clearing scenario model based on clearing status data. The system first simulates the batches and scale of daily or periodic clearing based on historical clearing data. For example, if a financial institution has multiple clearing batches every day, and the transaction volume and capital amount of each batch are different, the system will simulate these clearing batches and generate corresponding clearing scale data. The clearing time window is set according to the actual operation time. For example, the end-of-day clearing usually occurs at night, and the clearing time schedule is optimized through the model to ensure that the clearing scenario can truly reflect the clearing operation of the financial system and generate complete clearing scenario data.

[0064] Step S184: constructing a risk control scenario model according to the risk control status data to generate risk control scenario data, wherein the risk control scenario data includes a risk control rule set, a risk control threshold, and a risk control response strategy;

[0065] The embodiment of the present invention uses a rule engine tool such as Drools to build a risk control scenario model based on risk control status data. Specific operations include establishing a risk control rule set, such as configuring different risk identification rules for different transaction types; setting risk control thresholds, such as setting stricter risk control standards for large transfers or transactions in high-risk areas; and optimizing risk control response strategies by analyzing historical data to ensure that risk control rules can respond quickly under high-load environments. For example, for anti-fraud scenarios, the system will simulate abnormal high-frequency transactions in a short period of time to trigger the risk control response mechanism, thereby generating risk control scenario data.

[0066] Step S185: Optimize the scenario combination of the transaction scenario data, the clearing scenario data, and the risk control scenario data to generate comprehensive test scenario data;

[0067] In the construction of the comprehensive test scenario, the embodiment of the present invention first optimizes and combines the transaction scenario data, the clearing scenario data, and the risk control scenario data through a multi-scenario optimization tool such as Genetic Algorithm. By simulating the concurrent operations of different business scenarios, the system evaluates the mutual influence between transactions, clearing, and risk control. For example, during the peak period of clearing, the transaction frequency and the execution of risk control rules may put pressure on the overall performance of the system. The system optimizes the combination effect of each scenario by adjusting the batches of transactions and clearing and the execution frequency of risk control rules, and generates comprehensive test scenario data for further testing the performance of the system in a complex environment.

[0068] Step S186: adaptively adjusting load parameters of the comprehensive test scenario data based on the system status basic data to generate scenario load data;

[0069] The embodiment of the present invention adaptively adjusts the load parameters of the comprehensive test scenario data based on the basic system status data. Through load balancing tools such as HAProxy or Nginx, the system dynamically adjusts the load distribution in different scenarios according to real-time status data. For example, during peak trading periods, the system automatically increases virtual machine instances or expands network bandwidth according to transaction volume to adapt to load requirements. At the same time, through load stress testing tools such as Stress-ng, the load of clearing and risk control scenarios is evaluated, and the execution time of clearing batches and risk control rules is adjusted to ensure that the system remains stable under high load, and finally generate scenario load data.

[0070] Step S187: Integrate and match the environmental parameter configuration data with the scene load data to generate test environment parameter data.

[0071] When integrating environmental parameter configuration data and scenario load data, the embodiment of the present invention uses a system automation management platform such as Kubernetes to combine hardware resource configuration with business scenarios to ensure that the test environment can accurately simulate the operating state of the actual system. For example, the system dynamically allocates computing resources according to the environmental parameter configuration data, and matches the scenario load data with it to ensure that in each test scenario, resources such as CPU, memory, and network bandwidth are reasonably configured, and the load test pressure can be accurately applied to the system. Through this integration operation, the system ultimately generates complete test environment parameter data to ensure the authenticity and stability of the test scenario.

[0072] The present invention generates environment parameter configuration data by configuring hardware resources such as the number of CPU cores, memory capacity, storage space and network bandwidth, as well as optimizing database instances and middleware parameters (such as connection pool size, cache strategy, thread pool parameters, etc.). This step ensures that the test environment can accurately reflect the hardware and software resource usage of the production environment, making the test results more practical reference value. Through reasonable resource allocation, it is possible to avoid resource waste or insufficiency and improve the stability and efficiency of the system in actual scenarios. According to the transaction performance data, a transaction scenario model is constructed to generate transaction scenario data (including transaction type distribution, transaction frequency pattern and transaction scale distribution), which can accurately simulate transaction activities in the financial system. This helps to test the performance of the system under different transaction loads and identify potential performance bottlenecks, such as response speed and system stability in high-frequency or large-scale transactions. By simulating real transaction patterns, the reliability of the system can be better evaluated. According to the clearing status data, a clearing scenario model is constructed to generate clearing scenario data, including clearing batches, scales and time windows. Clearing is an important part of the financial transaction system. By simulating the actual clearing scenario, the system processing efficiency and consistency during the clearing process can be evaluated. At the same time, this step can help discover the system's pressure-bearing capacity at the peak of clearing, thereby optimizing the clearing process and improving the overall operational capacity of the system. Based on the risk control status data, a risk control scenario model is constructed to generate risk control scenario data (such as risk control rule sets, risk control thresholds, and risk control response strategies), which can conduct in-depth testing of the system's risk control capabilities. This step can help the system identify the rationality and effectiveness of risk control rules by simulating different risk control strategies and rule responses, prevent misinterception or omission of risk events, and thus ensure the accuracy and response speed of the system in risk management. By optimizing the scenario combination of transaction, clearing, and risk control scenario data to generate comprehensive test scenario data, it is helpful to simultaneously evaluate the performance of the system in the transaction, clearing, and risk control processes in a unified test environment. This step can maximize the simulation of multi-dimensional scenario interactions in the actual production environment by optimizing different scenario combinations, ensuring that the system can run smoothly in complex business scenarios. This plays a key role in the all-round testing and optimization of the overall performance of the system. Based on the basic system status data, the load parameters of the comprehensive test scenario data are adaptively adjusted to generate scenario load data. This step ensures that the test can be performed under different load conditions by dynamically adjusting the load parameters, helping to discover the system's performance under extreme load conditions and identifying performance bottlenecks or resource shortages. Adaptive adjustment can make the test results more practical and instructive, thereby improving the robustness of the system under high load. Integrate and match the environmental parameter configuration data with the scenario load data to generate the test environment parameter data. This step ensures that the configuration of the test environment matches the load model, making the test closer to the actual operating environment.At the same time, through the integration and matching of parameters, we can better simulate the resource consumption in the production environment and ensure the reliability and accuracy of the test results. Ultimately, it helps to optimize the system configuration and make the system more stable and efficient in actual operation.

[0073] As an embodiment of the present invention, refer to Figure 3 As shown, Figure 1 Detailed step flow diagram of step S2 in the embodiment of the present invention, step S2 includes the following steps:

[0074] Step S21: Performing a gradient incremental test on the transaction parameters in the test environment parameter data to generate transaction stress test data, wherein the transaction parameters include the number of concurrent users, transaction frequency, and transaction complexity;

[0075] When performing a gradient incremental test on the transaction parameters in the test environment parameter data, the embodiment of the present invention uses a stress testing tool such as JMeter or LoadRunner. The system first gradually increases the number of concurrent users, setting it to gradually increase from the initial 100 users to 5,000 users, and monitors the response time and transaction processing capabilities of the system under different concurrency conditions. At the same time, the system simulates the transaction frequency, gradually increasing from 10 transactions per second to 100 transactions per second, and analyzes the performance of the system under high-frequency transactions. The transaction complexity is tested by adjusting the transaction type, such as simple fund transfers and complex cross-border transactions, recording the time delay and success rate of the system in processing complex transactions, and finally generating transaction stress test data.

[0076] Step S22: Perform large-value transaction and batch transaction stress tests according to the test environment parameter data to generate transaction capacity data including the upper limit of a single transaction amount, batch transaction concurrency, and cross-system transaction processing capability;

[0077] According to the test environment parameter data, the system of the embodiment of the present invention performs stress testing on large transactions and batch transactions. First, by simulating large transactions, the upper limit of a single transaction amount is gradually increased, for example, from 10,000 yuan to 1 million yuan, and the response time and transaction success rate of the system in processing large transactions are recorded. Secondly, for the stress test of batch transactions, the system simulates multiple concurrent batch transaction scenarios, and simultaneously initiates 100 batches of transaction requests through tools such as Gatling, and records the upper limit of the concurrency of batch transactions. At the same time, the system simulates cross-system transactions and analyzes its processing capabilities. For example, when the system conducts high-frequency cross-system transactions with a third-party payment platform, its response speed and accuracy are tested, thereby generating transaction capacity data.

[0078] Step S23: performing correlation analysis on the transaction stress test data and the transaction capacity data to generate transaction stress bearing capacity data;

[0079] When correlating transaction stress test data with transaction capacity data, the system of the embodiment of the present invention uses data analysis tools such as Elastic Stack to perform correlation analysis on the two. Specifically, the system will analyze whether the increase in the number of concurrent users significantly affects the transaction capacity, for example, whether the transaction response time of the system is significantly prolonged or the error rate increases when the number of concurrent users exceeds 2,000. Through this correlation analysis, the system can determine the impact of different transaction parameters on the system's carrying capacity, and finally generate transaction pressure bearing capacity data to judge the system's pressure bearing performance in real transaction scenarios.

[0080] Step S24: performing a system capacity stress test according to the test environment parameter data to generate system capacity limit data, wherein the system capacity stress test includes a database stress test and a system storage capacity test;

[0081] In the system capacity stress test of the embodiment of the present invention, the system will perform special tests on the database and system storage capacity according to the test environment parameter data. The database stress test simulates high-concurrency database read and write operations through tools such as SysBench, gradually increases the processing volume of database transactions, until the system response is significantly delayed or an error occurs, and records the upper limit of the maximum transaction volume processed by the database. The storage capacity test simulates a large amount of data writing and reading operations through tools such as IOmeter, gradually increases the amount of data to the upper limit of the system storage, and monitors the performance of the system when the storage capacity is close to saturation, and generates system capacity limit data as the system's limit performance indicator.

[0082] Step S25: Performing a network stress test based on network bandwidth pressure and network connection number limit according to the test environment parameter data to generate network carrying capacity data;

[0083] In the network stress test of the embodiment of the present invention, the system performs a limit test on the network bandwidth and the number of connections based on the test environment parameter data. Use tools such as iPerf to simulate high-traffic network transmission, gradually increase the network bandwidth utilization rate, for example, from 100Mbps to 1Gbps, and record the response speed and delay of the system under high bandwidth conditions. For the network connection number test, the system simulates a large number of users' connection requests, gradually increases the number of users connected at the same time, for example, from 1,000 connections to 50,000, analyzes the system's processing power and stability when the number of connections reaches the limit, and finally generates network carrying capacity data.

[0084] Step S26: Calculate the system stability index based on the system capacity limit data, the transaction pressure bearing capacity data, and the network carrying capacity data, and compare and analyze with the pre-acquired historical benchmark to obtain stability benchmark data;

[0085] In the calculation of the system stability index in the embodiment of the present invention, the system first comprehensively analyzes the system capacity limit data, the transaction pressure bearing capacity data, and the network carrying capacity data. Using an algorithm model such as a linear regression or a random forest model, the system compares and analyzes these data with the pre-acquired historical stability benchmark data. For example, when the current test results show that the system's transaction pressure bearing capacity is lower than the historical benchmark, the system will evaluate its potential risks and generate an alarm. Through this analysis, the system obtains the system stability benchmark data under the current test environment to evaluate the overall stability of the system.

[0086] Step S27: Perform dynamic load gradient processing according to the stability benchmark data to generate system pressure gradient data; perform risk level mapping on the system pressure gradient data to generate risk assessment mapping data.

[0087] In an embodiment of the present invention, the system will perform dynamic gradient processing on the load based on the stability benchmark data. Through automated load management tools such as Kubernetes HPA (Horizontal Pod Autoscaler), the system will adjust the load distribution based on real-time stability data. For example, when the system pressure exceeds a certain threshold, the system will automatically increase computing resources or reduce concurrent transaction loads to generate system pressure gradient data. Subsequently, the system maps these pressure gradient data to a risk level model, for example, by setting thresholds for different risk levels to determine the risk level of the current system, and ultimately generates risk assessment mapping data for further risk management and response strategy formulation.

[0088] The present invention enables the test to run under increasing loads, thereby identifying the performance of the system under different transaction conditions. Through meticulous transaction parameter adjustment, the carrying capacity of the system can be clarified, providing data support for subsequent performance optimization. This test ensures the processing capacity of the system when facing large and high-concurrency transactions, and can identify bottlenecks and problems that may occur in actual transaction scenarios. The evaluation of transaction capacity is the key to ensuring that the system can handle the expected transaction volume and reduce the risks in actual operations. By cross-validating the relationship between different data sets, it is helpful to deeply understand the performance of the system under pressure. For example, the response time and processing efficiency of the system under high-concurrency transaction conditions can be evaluated. Such analysis can provide an important basis for the design and architecture of the system to ensure that business needs can be met. System capacity stress testing is performed according to the test environment parameter data to generate system capacity limit data. This includes database stress testing and system storage capacity testing, which can evaluate the operation of the system under extreme conditions. This step can discover potential storage shortages or slow database response problems in advance, providing an important reference for subsequent capacity planning and expansion. Ensuring the reliability of the system under high network load can identify network bottlenecks and their impact on transaction processing; it provides a quantitative standard for system performance, which helps to evaluate the stability and reliability of the system under different load conditions. By comparing with historical data, we can better understand the improvement effect and possible problems of the system. Dynamic load gradient processing not only helps to identify the risk level of the system under different loads, but also provides a basis for dynamically adjusting the system load. Through risk mapping, the system can take corresponding preventive measures for different stress conditions, thereby reducing potential risks and ensuring the security of transactions and the stability of the system.

[0089] Preferably, step S27 includes the following steps:

[0090] Step S271: Perform multi-dimensional data stratification processing on the stability benchmark data to generate stratified benchmark data including a transaction layer pressure benchmark, a system layer pressure benchmark, and a network layer pressure benchmark;

[0091] In the embodiment of the present invention, the system first performs multi-dimensional data stratification processing on the stability benchmark data, and uses data stratification algorithms such as decision trees or hierarchical clustering to classify data at different levels of the system. At the transaction layer, the system generates transaction layer pressure benchmark data based on factors such as the number of concurrent users, transaction frequency, and transaction type; at the system layer, the system generates system layer pressure benchmark data based on system performance parameters such as CPU occupancy, memory utilization, and disk IO; at the network layer, the network layer pressure benchmark data is generated based on network bandwidth utilization, network latency, and number of connections. Through this hierarchical processing, the system can identify the pressure performance of each level, thereby laying the foundation for subsequent load calculations.

[0092] Step S272: constructing a dynamic load calculation model based on the hierarchical benchmark data, and performing load parameter standardization processing to generate load standardization data;

[0093] When constructing a dynamic load calculation model based on hierarchical benchmark data, the embodiment of the present invention uses a mathematical model such as a multivariate linear regression model, combined with benchmark data of the transaction layer, system layer, and network layer, to construct a load calculation model. Next, the system standardizes the load parameters, and uses normalization or Z-score methods to convert the load parameters of each layer into dimensionless data, so that data at different levels have a unified dimension for subsequent model calculation and analysis. Finally, load standardized data is generated to ensure parameter consistency and comparability during the load calculation process.

[0094] Step S273: performing gradient feature extraction based on machine learning on the load normalization data to generate load feature vector data;

[0095] Based on the load normalization data, the embodiment of the present invention applies a gradient feature extraction algorithm based on machine learning, such as principal component analysis (PCA) or convolutional neural network (CNN), to extract features from the normalized load data. The specific operation includes analyzing the correlation between various load parameters, extracting the gradient features that are most sensitive to the system load, such as a sudden increase in CPU utilization, extreme use of network bandwidth, etc., and then generating load feature vector data. This data contains the features that have the most significant impact on the load, and can provide accurate information for subsequent load gradient classification.

[0096] Step S274: establishing a multi-level load gradient model according to the load characteristic vector data, and generating load gradient classification data including light load level, medium load level, heavy load level and overload level;

[0097] According to the load feature vector data, the system of the embodiment of the present invention constructs a multi-level load gradient model. The load feature vector data is classified using the K-means clustering algorithm or the fuzzy C-means algorithm to generate load gradient classification data including light load, medium load, heavy load and overload levels. The light load level may represent that the system is in an idle or light load state, the medium load level reflects the load state during normal operation, the heavy load level indicates that the system load is close to the upper limit, and the overload level indicates that the system is under extreme pressure and may be about to have a performance bottleneck or failure. Through these classifications, the system can monitor and predict the load status more accurately.

[0098] Step S275: dynamically calculating the threshold value of the load gradient classification data, adaptively optimizing the threshold value according to the preset historical stress measurement data, and generating gradient threshold data;

[0099] When performing dynamic threshold calculations on load gradient classification data, the embodiment of the present invention will combine historical stress test data and use an adaptive threshold optimization algorithm, such as a genetic algorithm or Bayesian optimization, to adjust the thresholds for each load level. For example, based on the system performance in different stress test scenarios in the past, the thresholds between medium load and heavy load are dynamically adjusted to ensure that the threshold settings are more in line with the actual load conditions. Finally, gradient threshold data is generated, which not only reflects the current operating status of the system, but also has the ability to adaptively adjust to cope with future dynamic changes in the system.

[0100] Step S276: Based on the gradient threshold data, the current load state of the system is evaluated in real time, and load prediction analysis is performed to generate system pressure gradient data;

[0101] In the embodiment of the present invention, the system evaluates the current load status in real time based on the gradient threshold data. The system monitors various parameters of the transaction layer, system layer and network layer in real time, and combines the gradient threshold data, uses a sliding window algorithm or a recursive neural network (RNN) model to perform load forecasting analysis, and predicts the load change trend of the system in the future time period, especially the system pressure change during peak trading hours. Through these analyses, the system can warn of possible pressure peaks in advance, thereby generating system pressure gradient data to support the self-regulation of the system under high load.

[0102] Step S277: Perform risk level mapping on the system pressure gradient data to generate risk assessment mapping data.

[0103] The system of the embodiment of the present invention performs risk level mapping on the generated pressure gradient data, and applies a risk assessment model such as a model based on fuzzy logic or a decision tree to correspond different pressure gradients to different risk levels, for example, a light load state corresponds to a low risk, a medium load state corresponds to a medium risk, and an overload state corresponds to a high risk. Finally, the system generates risk assessment mapping data based on the mapping results, and provides corresponding early warning prompts and processing suggestions to help operation and maintenance personnel take timely measures to reduce the risk of failure of the system under high pressure.

[0104] The present invention divides complex benchmark data into different levels of standards, so that the analysis of each layer is more accurate, which is convenient for targeted optimization and monitoring. The construction of hierarchical benchmark data provides a clear reference framework for subsequent analysis and decision-making, ensuring that the pressure conditions at all levels are effectively monitored. Through standardization, the differences between different data sources can be eliminated, making the analysis model more comparable and consistent, and ensuring the accuracy and reliability of load calculation. The use of machine learning algorithms to extract feature vectors can more deeply explore the potential patterns and relationships in the data, improving the intelligence of the load model. The generation of load feature vectors can provide data support for dynamic load adjustment and optimization of resource allocation, and enhance the adaptive ability of the system. The process of establishing a multi-level load gradient model helps to achieve refined management and monitoring by dividing the load into multiple levels. The load gradient classification data at different levels provides clear standards for real-time load evaluation, enabling the system to take corresponding response measures for different load conditions, thereby improving the flexibility and stability of the system. It ensures that load management is more accurate, and the setting of dynamic thresholds can be adjusted according to actual operating conditions, so as to more effectively cope with sudden load changes. Through adaptive optimization, the system can adjust its load tolerance in real time and improve the resilience of the system. Real-time assessment and load forecast analysis enable the system to quickly identify the current operating status and predict potential load problems in advance. This process can provide timely warnings for the system, helping the operation and maintenance team to take necessary measures to reduce the risk of system collapse and ensure the continuity and reliability of financial transactions. Risk level mapping of system pressure gradient data is performed to generate risk assessment mapping data. Through risk assessment mapping of pressure gradient data, the system's load conditions can be converted into intuitive risk levels, which helps the operation and maintenance team to quickly understand the system's security status and respond. This mapping data can help formulate corresponding emergency plans to ensure that resources can be adjusted or other remedial measures can be taken in a timely manner when the system pressure is too high.

[0105] Preferably, step S277 includes the following steps:

[0106] Step S2771: Establish a multi-dimensional risk assessment indicator system based on the system pressure gradient data to generate risk indicator data, where the risk indicators include system performance risk, business processing risk, data consistency risk, and network transmission risk;

[0107] In the embodiment of the present invention, the system first establishes a multi-dimensional risk assessment index system based on the system pressure gradient data, and uses the analytic hierarchy process (AHP) or weighted scoring method to take system performance, business processing, data consistency and network transmission as the main dimensions. System performance risk is determined by analyzing key indicators such as CPU usage, memory occupancy, disk IO and system response time; business processing risk is evaluated based on parameters such as transaction processing success rate, transaction delay and concurrency; data consistency risk is determined based on data such as reconciliation consistency and fund arrival time during the clearing process; network transmission risk is evaluated through network bandwidth utilization, network delay and packet loss rate. The risk indicators of each dimension are combined according to different weights to generate risk indicator data, which is used to comprehensively reflect the operating risk status of the system.

[0108] Step S2772: classify the risk indicator data into risk levels according to the preset risk indicator threshold value to obtain risk level classification data;

[0109] In the embodiment of the present invention, the system then classifies the generated risk indicator data into risk levels according to the preset risk indicator threshold. Using logistic regression or fuzzy logic methods, risk indicators of different dimensions are divided into different risk levels, such as low risk, medium risk and high risk. System performance risk may be judged as medium risk when the CPU usage rate exceeds 70%, and high risk when it exceeds 90%; business processing risk will also trigger a high risk warning when the transaction delay exceeds the preset threshold. Through these classifications, the system generates risk level classification data, so that different risk scenarios can be assigned to appropriate risk levels according to their respective indicators.

[0110] Step S2773: constructing an early warning rule model including early warning triggering conditions, early warning level determination, and early warning message push strategy based on the risk level classification data;

[0111] In the embodiment of the present invention, based on the risk level classification data, the system constructs an early warning rule model, which includes early warning triggering conditions, early warning level determination and early warning message push strategy. The triggering conditions may include triggering an early warning when the CPU usage rate exceeds 90% or the network delay exceeds the specified time; the early warning level determination is determined according to the risk level classification data, low risk triggers a low-level early warning, medium risk triggers an intermediate early warning, and high risk triggers an emergency early warning. The early warning message push strategy is based on the level and scenario of the risk. For example, a low-level early warning can be notified by email, and an emergency early warning can be sent to relevant operation and maintenance personnel via instant messaging. This model ensures that the early warning can be triggered and the relevant personnel can be notified at the right time through strictly defined conditions and strategies.

[0112] Step S2774: verify the reliability of the early warning rule model, and optimize and adjust the rules based on the verification results to generate early warning strategy data;

[0113] After the warning rule model is constructed, the embodiment of the present invention will conduct reliability verification, use historical data for backtesting verification, or test with data generated by simulation stress testing. The system will analyze the accuracy and timeliness of the warning trigger and whether the judgment of the warning level is in line with the actual situation. According to the verification results, the system optimizes and adjusts the warning rules by using machine learning models such as random forests or gradient boosting decision trees (GBDT). For example, if the warning level judgment of a certain type of risk is too frequent and the false alarm rate is high, the system will appropriately adjust the trigger threshold or condition of the warning, and finally generate optimized warning strategy data to make the warning model more accurate and reliable.

[0114] Step S2775: Map and associate the risk level classification data with the early warning strategy data to build a risk response mechanism, thereby obtaining risk assessment mapping data.

[0115] The embodiment of the present invention maps and associates the risk level classification data with the optimized early warning strategy data to build a complete risk response mechanism. In this process, the system matches the early warning strategy corresponding to each risk level to determine the best response measures under different risk scenarios. For example, for high-risk level scenarios, the system not only sends emergency warnings, but also triggers automated emergency response processes, such as automatic resource expansion or transaction flow limiting measures. Through this mapping association, the system ultimately generates risk assessment mapping data, providing a comprehensive risk prevention and control and response mechanism for the financial transaction system.

[0116] The beneficial effect of the process of establishing a multi-dimensional risk assessment indicator system in the present invention is that by classifying risks of different dimensions, the potential risk factors of the system can be more comprehensively identified and evaluated. Multi-dimensional risk assessment indicators can provide a richer information basis for subsequent risk analysis and decision-making, and improve the system's sensitivity and responsiveness to various risks. Through the classification process, the system can identify indicators of different risk levels in real time and quickly determine the current risk status. The division of risk levels helps the operation and maintenance team to quickly obtain key information and take appropriate response measures in emergency situations, thereby improving the efficiency and effectiveness of risk management. The construction of the model makes risk management more systematic and standardized. By setting clear warning trigger conditions and message push strategies, relevant personnel can be notified in time when the risk level reaches a certain threshold, ensuring rapid response and reducing the impact of potential risks on the business. The reliability verification and optimization process can ensure the effectiveness and adaptability of the warning rule model. Through continuous testing and adjustment, it can better adapt to the changing business environment and risk factors, and improve the accuracy and reliability of the early warning system. Through mapping associations, it can be ensured that corresponding response measures can be implemented at different risk levels to form a complete risk management closed loop. This risk response mechanism can help organizations take quick action to prevent risk events from occurring and reduce disruptions and losses to business operations.

[0117] Preferably, step S3 comprises the following steps:

[0118] Step S31: Collect abnormal behavior data of the financial transaction system through a distributed monitoring system, thereby obtaining original abnormal data including system layer abnormal data, application layer abnormal data and network layer abnormal data;

[0119] The embodiment of the present invention uses a distributed monitoring system to monitor all levels of the financial transaction system in real time, and the collected raw abnormal data includes various abnormal behaviors at the system layer, application layer, and network layer. For example, system layer abnormal data includes resource abnormalities such as CPU overload and memory leak; application layer abnormal data includes application crashes, request timeouts, and other problems; network layer abnormal data includes packet loss, excessive latency, and other phenomena. The distributed monitoring system aggregates these raw abnormal data and integrates them into raw abnormal data sets based on data sources at different levels for subsequent processing and analysis.

[0120] Step S32: performing data cleaning and time series alignment on the original abnormal data to generate standardized abnormal data; extracting features based on performance abnormalities, resource abnormalities, and business abnormalities on the standardized abnormal data to obtain abnormal behavior feature data;

[0121] The original abnormal data collected by the embodiment of the present invention often contains noise and redundant data, so the system first cleans the data, removes irrelevant or duplicate data, and processes missing values. After that, the system uses a time series alignment algorithm to align abnormal data from different sources under a unified timeline to generate standardized abnormal data. Next, the system extracts features from the standardized abnormal data based on dimensions such as performance anomalies, resource anomalies, and business anomalies. The extracted features may include CPU overload time, memory usage peak, transaction request failure rate, etc., and finally generates abnormal behavior feature data to provide a basis for subsequent fault mode identification.

[0122] Step S33: constructing a fault mode classification model for distinguishing system fault types, service fault types, and network fault types according to the abnormal mode sequence data, and using the fault mode classification model to identify the fault type to obtain fault classification data;

[0123] The embodiment of the present invention constructs a fault mode classification model by analyzing abnormal behavior feature data. The model can distinguish different types of system failures, business failures, and network failures. For example, system failures may be related to hardware resources or operating systems, business failures are associated with abnormalities in business logic processing, and network failures may be related to network connectivity or bandwidth limitations. By training a classification model based on data from abnormal pattern sequences, the system can identify specific types of failures and output fault classification data. For example, when the system detects that a CPU overload and a database connection timeout occur at the same time, the model can determine that it is a system-level failure; and when the transaction success rate drops sharply and the network packet loss rate increases, it may be identified as a network failure.

[0124] Step S34: training an intelligent early warning model based on pre-acquired historical fault data to generate early warning model parameter data; performing dynamic probability evaluation on the fault classification data to generate fault probability data;

[0125] The embodiment of the present invention uses historical fault data to train the intelligent early warning model, and generates parameter data of the early warning model, such as the model weight, threshold setting, etc., through supervised learning or reinforcement learning methods. The system will perform dynamic probability evaluation based on the fault classification data, evaluate the possibility of different fault types, and generate fault probability data. Fault probability evaluation usually uses algorithms such as Bayesian probability or Markov chain, taking into account the frequency of historical faults, the current state of the system, and the time correlation of faults. For example, when the system detects that multiple business anomalies occur simultaneously with system-level anomalies, the system may calculate a higher probability of business failure.

[0126] Step S35: performing multi-level warning threshold calculation according to the warning model parameter data and the fault probability data, thereby obtaining threshold classification data;

[0127] In the embodiment of the present invention, the system performs multi-level warning threshold calculations for various types of faults based on the warning model parameter data and the fault probability data. Using an algorithm based on dynamic threshold adjustment, the system can set different threshold levels based on current fault data and historical data. For example, a system-level fault may be set to a low-level warning when the CPU usage exceeds 80%, and a high-level warning when it exceeds 95%. A network fault may trigger an intermediate warning when the packet loss rate exceeds 2%. Ultimately, the results of these calculations generate threshold classification data, which is used to distinguish different levels of fault risks.

[0128] Step S36: construct an early warning rule model based on the threshold classification data to generate early warning trigger condition data, wherein the early warning rule model includes early warning condition definition, early warning level determination and early warning trigger mechanism.

[0129] The embodiment of the present invention constructs an early warning rule model based on the generated threshold classification data, defines the conditions for triggering early warnings, the criteria for determining the early warning level, and the triggering mechanism for early warnings. For example, the early warning condition can be defined as being triggered when the CPU usage rate at the system level exceeds 90% and the network delay exceeds 100ms; the early warning level is determined to be divided into low-level, medium-level, and high-level early warnings according to the severity and impact range of the fault; the early warning trigger mechanism controls the way the early warning is sent, such as low-level early warnings are notified via email, and medium-level and high-level early warnings are sent to relevant personnel via instant messages. The early warning trigger condition data finally generated ensures that the system can respond to fault risks in real time and promptly notify relevant personnel to take countermeasures.

[0130] The present invention collects abnormal behavior data of financial transaction systems through a distributed monitoring system, and can fully obtain the original abnormal information of the system layer, application layer and network layer. This multi-dimensional data collection not only provides a more complete perspective, but also helps to identify the root cause of potential problems, improves the accuracy and timeliness of fault detection, and thus enhances the stability and security of the system and reduces the risks caused by abnormal behavior. Cleaning and time series alignment of the original abnormal data helps to eliminate noise and inconsistent data, making the analysis more reliable. By extracting features based on performance, resources and business anomalies, the data can be converted into a more interpretable feature set. This standardized processing reduces the complexity of subsequent analysis and improves the ability to detect abnormal behavior, thereby reducing the possibility of false positives and false negatives, and helps to locate problems more quickly. By constructing a fault mode classification model that distinguishes system faults, business faults and network faults, automated fault diagnosis can be achieved. Using this model to identify fault types, the source of the fault can be quickly and accurately located, reducing the time required for manual intervention and judgment. This automated fault classification not only improves the response speed, but also optimizes the allocation of resources to ensure that key problems can be solved in a timely manner. Training an intelligent early warning model and performing dynamic probability evaluation helps to accurately identify and predict potential fault risks based on historical data. The generated failure probability data can help the team develop more effective emergency response strategies, take preventive measures in advance, and reduce the possibility of failures. This predictive capability improves the robustness of the overall system and can proactively intervene before failures occur, thereby reducing losses. Multi-level warning threshold calculation provides the system with clear fault trigger conditions. By setting thresholds at different levels, the system can issue warnings when problems first appear, allowing the team to take action before the problem escalates. This early warning mechanism significantly improves the flexibility and timeliness of emergency response, thereby reducing potential risks and losses. The constructed early warning rule model ensures that early warnings can be automatically triggered when abnormal situations occur. This mechanism includes the definition of warning conditions, level determination, and triggering mechanism, allowing the system to respond quickly when faced with emergencies. Through this systematic early warning mechanism, the security and reliability of financial trading systems have been significantly improved, reducing reliance on manual monitoring and the possibility of human error.

[0131] Preferably, step S4 comprises the following steps:

[0132] Step S41: construct a multi-dimensional performance evaluation model including system performance dimension, resource utilization dimension, business processing dimension and reliability dimension according to the system monitoring data acquired in real time, and obtain performance indicator data;

[0133] The embodiment of the present invention constructs a multi-dimensional performance evaluation model through real-time collected monitoring data. The model includes four dimensions: system performance dimension (such as response time, throughput, etc.), resource utilization dimension (such as CPU, memory, disk IO, etc. usage), business processing dimension (such as transaction success rate, request processing time, etc.) and reliability dimension (such as failure rate, recovery time, etc.). After the system integrates the data of each dimension, it uses data normalization and weighting algorithm to generate performance indicator data. For example, in the scenario of high concurrent transactions, the response time in the system performance dimension may increase significantly, and the CPU and memory usage of the resource utilization dimension will also increase. The system summarizes these data in real time and generates overall performance evaluation data.

[0134] Step S42: extracting a pressure characteristic vector from the system pressure gradient data to generate pressure characteristic data; performing multi-dimensional feature decomposition on the performance index data to obtain performance characteristic data;

[0135] In the embodiment of the present invention, the system first extracts key pressure feature vectors from the system pressure gradient data, such as the rate of change of the pressure gradient, the response curve of the system under different load conditions, etc., to generate pressure feature data. At the same time, the system performs multi-dimensional feature decomposition on the generated performance indicator data. The decomposed performance feature data may include specific performance performance under different dimensions, such as service response delay and throughput reduction when the CPU usage rate exceeds 80%. Through feature decomposition, the system can more accurately describe the characteristic behavior under each performance dimension, which is convenient for subsequent performance analysis.

[0136] Step S43: performing performance characteristic data recognition based on a machine learning algorithm on the pressure characteristic data and the performance characteristic data to generate performance abnormality characteristic data;

[0137] The embodiment of the present invention utilizes machine learning algorithms, such as support vector machines (SVM) or random forests, etc. The system identifies and classifies the extracted pressure characteristic data and performance characteristic data, and screens out abnormal performance characteristic data. For example, when the system shows abnormal response time and throughput decline trends under certain specific pressure conditions, the system can identify such abnormal performance and mark it as performance abnormality characteristic data. By learning from historical data, the machine learning model can improve its sensitivity to abnormal situations, thereby accurately detecting potential performance problems.

[0138] Step S44: performing root cause analysis on the performance abnormality feature data, and locating the performance bottleneck point using link tracking technology to generate preliminary bottleneck location data;

[0139] In the embodiment of the present invention, the system will perform root cause analysis on the identified performance anomaly feature data, and analyze the source of the anomaly by combining historical data with the current system environment. In order to accurately locate the performance bottleneck, the system will use link tracking technology, such as distributed link tracking tools (such as Zipkin or Jaeger), to analyze the path where the anomaly occurs, track the delays of each link from user requests to database access, and thus generate preliminary bottleneck location data. For example, when the system response time is found to be abnormal, link tracking can be used to find that the bottleneck may occur in the long lock waiting time of the database query or the exhaustion of the thread pool at the application layer.

[0140] Step S45: Analyze the propagation path and impact range of the performance bottleneck among various system components based on the preliminary bottleneck location data to generate performance impact assessment data;

[0141] After determining the initial bottleneck location, the system of the embodiment of the present invention further analyzes the propagation path and impact range of the bottleneck in different system components. For example, if database query is a bottleneck, the system will analyze whether this bottleneck will cause resource exhaustion of other components, such as application servers or load balancers, thereby expanding the impact range of the failure. Through simulation or speculation based on historical data, the system generates performance impact assessment data, clarifies the direct and indirect impact range of the bottleneck, and helps system administrators evaluate the impact of the bottleneck on the performance of the entire system.

[0142] Step S46: Formulate a performance optimization strategy based on system configuration optimization, resource expansion suggestions, and code optimization direction for the preliminary bottleneck location data according to the performance impact assessment data, thereby obtaining performance bottleneck location data.

[0143] In an embodiment of the present invention, the system formulates corresponding performance optimization strategies based on the performance impact assessment data. For example, if the bottleneck is due to a performance problem of a database query, the system may suggest optimizing the database query statement or increasing the cache size of the database. In addition, if the system resources are insufficient, the system may suggest expanding the resources, such as increasing the number of CPU cores or memory capacity. At the same time, for performance bottlenecks at the code level, the system may suggest optimizing the execution logic of the code or improving concurrent processing capabilities. Ultimately, the system generates performance bottleneck location data and provides clear optimization suggestions to system administrators to help improve the overall performance of the system.

[0144] The present invention can comprehensively evaluate the overall health status of the system by constructing a performance evaluation model including multiple dimensions such as system performance, resource utilization, business processing and reliability. The generation of performance indicator data enables managers to monitor the multi-dimensional performance of the system in real time, so as to timely discover potential problems and make decisions. This all-round monitoring and evaluation ensures the stability of the system under high load and improves the responsiveness to business needs. Extracting pressure feature vectors from system pressure gradient data helps to quantify the performance of the system under different loads. The generated pressure feature data combined with the multi-dimensional feature decomposition of performance indicator data provides a deeper understanding of performance. This analysis can reveal the changes in system performance under specific loads, help identify potential weaknesses in performance, and thus lay the foundation for subsequent optimization. Using machine learning algorithms to identify pressure feature data and performance feature data can automatically detect and identify performance abnormality features. Through this intelligent analysis, the accuracy and efficiency of abnormality detection can be greatly improved, reducing the need for manual intervention. This method not only accelerates the process of problem discovery, but also improves the resilience of the system and ensures the continuity of key businesses. Root cause analysis of performance abnormality feature data and locating performance bottlenecks using link tracking technology can achieve in-depth mining of problems. By accurately identifying performance bottlenecks, the team can take targeted measures to solve the problem, avoiding business interruptions or performance degradation caused by failure to identify bottlenecks in time. This process improves the efficiency and accuracy of troubleshooting, making system maintenance more scientific and effective. By analyzing the propagation path and impact range of the preliminary bottleneck location data between various system components, we can gain a deep understanding of the system impact of the bottleneck and how it propagates. This performance impact assessment data provides an important basis for formulating optimization strategies, making the optimization plan more targeted and effective. This analysis helps managers identify key points in the system and ensure that resources are concentrated where they really need to be optimized, thereby optimizing overall system performance. The optimization strategies formulated based on the performance impact assessment data, including system configuration optimization, resource expansion recommendations, and code optimization directions, provide clear action guidance for system performance improvement. This systematic optimization approach can not only effectively solve the identified performance bottlenecks, but also lay the foundation for future performance improvements. By implementing these strategies, the system's response speed, processing power, and reliability can be significantly improved to better meet changing business needs.

[0145] Preferably, step S5 comprises the following steps:

[0146] Step S51: construct a multi-dimensional risk assessment model based on the warning trigger condition data, extract risk features from the performance bottleneck location data, and generate risk feature data, wherein the risk features include performance degradation risk features, system crash risk features, data consistency risk features, and business interruption risk features;

[0147] The embodiment of the present invention constructs a multi-dimensional risk assessment model based on the early warning trigger condition data, and combines the performance bottleneck location data to analyze and extract features of risks in different dimensions of the system. For example, the performance degradation risk feature may come from the gradual increase in system response time, the system crash risk feature may come from the situation where the CPU or memory usage is close to 100%, the data consistency risk feature comes from the database lock waiting time being too long or the data writing delay, and the business interruption risk feature comes from a significant decrease in the transaction success rate. By extracting these risk features, the system generates risk feature data to help with subsequent risk processing.

[0148] Step S52: performing risk propagation path analysis on the risk characteristic data, thereby obtaining risk propagation path data;

[0149] The embodiment of the present invention analyzes the extracted risk feature data, focusing on the risk propagation path. By tracing the impact propagation path of performance bottlenecks in different system components, for example, from database query delays to thread pool resource exhaustion at the application layer, and then to increased request response time at the user end, the system can clearly describe the risk propagation method and generate risk propagation path data. This helps system administrators quickly identify the source of the problem and the potential scope of risk spread.

[0150] Step S53: Probabilistically evaluate the risk propagation path data, establish a risk probability matrix, and generate risk probability distribution data;

[0151] The embodiment of the present invention evaluates the probability of risk occurrence of different nodes based on the risk propagation path data and generates a risk probability matrix. This matrix calculates the risk probability distribution of each node through a comprehensive analysis of historical data and the current system status. For example, in a high concurrency situation, the probability of extending the database lock waiting time is high, which will further increase the risk of transaction failure. Finally, the system generates risk probability distribution data to clarify the possibility of each risk point and its impact.

[0152] Step S54: performing multi-level risk classification according to the risk probability distribution data to generate risk assessment data;

[0153] In the embodiment of the present invention, the system divides the risk levels of different risk points according to the risk probability distribution data, using a multi-level approach, such as low, medium, high, and severe. The system determines the level of each risk point by comparing historical benchmark data and the real-time status of the current system. For example, if the probability of collapse of a risk point is high and may affect the entire system, it is classified as high risk, and risk assessment data is generated to help prioritize high-risk risks.

[0154] Step S55: performing a policy matching analysis on the risk assessment data according to a preset system recovery policy library to generate policy matching data, wherein the system recovery policy library includes a resource expansion policy, a load balancing policy, a service degradation policy, and a fault isolation policy;

[0155] The embodiment of the present invention matches the risk assessment data with the preset system recovery policy library. The policy library includes resource expansion policies (such as increasing CPU and memory resources), load balancing policies (such as dynamically allocating task loads), service degradation policies (such as reducing the execution frequency of non-critical tasks), and fault isolation policies (such as isolating faulty services). The system finds a response strategy suitable for the current risk situation through policy matching analysis, generates policy matching data, and ensures that subsequent recovery plans can effectively respond to different risk scenarios.

[0156] Step S56: construct a multi-dimensional recovery plan based on the policy matching data, and generate fault recovery plan data including an immediate recovery plan, a gradual recovery plan, an emergency recovery plan, and a disaster recovery switching plan;

[0157] In the embodiment of the present invention, based on the policy matching data, the system constructs a multi-dimensional fault recovery plan. These plans are divided into immediate recovery plans (such as immediate reallocation of resources), gradual recovery plans (such as gradually increasing the carrying capacity of the system), emergency recovery plans (such as temporarily shutting down some non-critical functions to ensure the operation of core services), and disaster recovery switching plans (such as starting the backup system when a serious fault occurs in the main system) according to the needs of different scenarios. The system generates fault recovery plan data based on actual conditions to provide guidance for subsequent execution.

[0158] Step S57: Perform scenario simulation test on the fault recovery solution data, and perform effectiveness evaluation based on solution success rate, recovery time and resource consumption to generate simulation result data;

[0159] The embodiment of the present invention performs scenario simulation testing on the generated fault recovery solution, and tests the performance of the solution under different conditions by simulating actual fault scenarios. The focus of the simulation test includes the success rate of the recovery solution (i.e., the effectiveness of the solution), the recovery time (i.e., the execution efficiency of the solution), and the resource consumption (i.e., the system resources consumed during the recovery process). Through statistical analysis of the test results, the system generates simulation result data to verify the effectiveness of each recovery solution.

[0160] Step S58: Generate a recovery strategy based on the simulation result data, thereby obtaining recovery strategy data.

[0161] The embodiment of the present invention further optimizes and adjusts the fault recovery strategy based on the simulation result data. For example, if a solution takes too long to recover or consumes too many resources in a simulation test, the system will re-optimize the strategy based on the test data to ensure that the system can be restored in a more efficient way in actual applications. Finally, the system generates recovery strategy data to ensure that the system can be restored quickly and effectively in real fault scenarios.

[0162] The present invention can systematically identify and quantify various potential risks by constructing a multi-dimensional risk assessment model and extracting risk features from performance bottleneck location data. These risk features (such as performance degradation, system crash, data consistency, and business interruption risk) provide in-depth insights into the health status of the system, enabling managers to identify problems earlier, optimize system design, reduce the possibility of failures, and improve the overall stability of the system. Risk propagation path analysis of risk feature data helps to understand the transmission mechanism and impact range of risks between system components. This analysis can reveal potential system weaknesses and help managers take forward-looking risk control measures. By clarifying the risk propagation path, organizations can better formulate preventive measures to reduce the impact of risks on the overall performance of the system. By performing probability assessment on risk propagation path data and establishing a risk probability matrix, the possibility of different risk events can be quantified. This risk probability distribution data enables managers to make more scientific decisions based on data, give priority to high-probability risk events, thereby effectively reducing the risk of business interruption and system crash, and improving the continuity and reliability of the overall business. Multi-level risk level division based on risk probability distribution data can systematically prioritize different risks. This risk assessment data enables the team to focus resources and attention on the most important risks, thereby optimizing the effectiveness of risk management, ensuring that key risks are handled in a timely manner, and reducing the negative impact on the business. The risk assessment data is matched with the preset system recovery strategy library to determine the most appropriate response measures for different types of risks. This strategy matching process improves the efficiency of system recovery, makes the recovery plan more flexible and targeted, and helps to respond quickly when risks occur and reduce potential losses. The multi-dimensional recovery plan built based on the strategy matching data provides a variety of recovery options, including instant recovery, progressive recovery, emergency recovery, and disaster recovery switching plans. This diverse recovery plan ensures that the system can be restored quickly and effectively in different situations, improves the flexibility and resilience of the business, and ensures the availability of key services. Scenario simulation testing of fault recovery plan data and evaluation of its effectiveness can identify potential problems and deficiencies before actual implementation. This effectiveness evaluation ensures the rationality of the selected recovery plan in terms of resource consumption, recovery time, and success rate, provides data support for subsequent recovery plan optimization, and thus improves the feasibility and reliability of the recovery strategy. The recovery strategy data generated based on the simulation result data can achieve continuous optimization and adjustment of the plan. This data-based dynamic strategy generation process ensures that the recovery strategy adapts to actual business needs and environmental changes, improves the system's overall risk resistance and recovery capabilities, and enhances the company's ability to respond to emergencies.

[0163] Therefore, the embodiments should be regarded as illustrative and non-restrictive from all points, and the scope of the present invention is limited by the appended claims rather than the above description, and it is therefore intended that all changes falling within the meaning and range of equivalent elements of the application documents are included in the present invention.

[0164] The above description is only a specific embodiment of the present invention, so that those skilled in the art can understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but should conform to the widest scope consistent with the principles and novel features invented herein.

Claims

1. A testing method based on financial environment stability, characterized in that: The following steps are involved: Step S1: Perform real-time status monitoring on the financial transaction system and generate basic system status data; Build a virtual test environment based on the basic data of the system status, perform adaptive configuration of the test scenario, and generate test environment parameter data; Step S2: Perform multi-dimensional stress test analysis on the test environment parameter data, calculate the system stability index, and generate stability benchmark data; Perform dynamic load gradient processing based on stability benchmark data to obtain system pressure gradient data; perform risk level mapping on the system pressure gradient data to generate risk assessment mapping data; Step S3: using the distributed monitoring system to collect abnormal behavior characteristics of the financial transaction system and generate abnormal behavior characteristic data; performing fault pattern recognition on the abnormal behavior characteristic data, establishing a fault warning threshold, and generating warning trigger condition data; Step S4: Perform multi-dimensional performance analysis based on the system monitoring data acquired in real time to obtain performance indicator data, wherein the multi-dimensional performance includes multi-dimensional performance, resource utilization dimension, business processing dimension and reliability dimension; The system pressure gradient data and the performance index data are correlated and analyzed, and bottlenecks are identified to generate performance bottleneck location data. Step S4 is specifically as follows: Step S41: construct a multi-dimensional performance evaluation model including system performance dimension, resource utilization dimension, business processing dimension and reliability dimension according to the system monitoring data acquired in real time, and obtain performance indicator data; Step S42: extracting a pressure characteristic vector from the system pressure gradient data to generate pressure characteristic data; Perform multi-dimensional feature decomposition on the performance indicator data to obtain performance feature data; Step S43: performing performance characteristic data recognition based on a machine learning algorithm on the pressure characteristic data and the performance characteristic data to generate performance abnormality characteristic data; Step S44: performing root cause analysis on the performance abnormality feature data, and locating the performance bottleneck point using link tracking technology to generate preliminary bottleneck location data; Step S45: Analyze the propagation path and impact range of the performance bottleneck among various system components based on the preliminary bottleneck location data to generate performance impact assessment data; Step S46: formulating a performance optimization strategy based on system configuration optimization, resource expansion suggestions, and code optimization direction for the preliminary bottleneck location data according to the performance impact assessment data, thereby obtaining performance bottleneck location data; Step S5: Perform risk level assessment on the performance bottleneck location data using the early warning trigger condition data to obtain risk assessment data; Build system recovery strategies based on risk assessment data and generate fault recovery plan data; Perform simulation verification on the fault recovery plan data, and generate a recovery strategy based on the simulation results, thereby obtaining recovery strategy data; Step S6: Use the risk assessment mapping data and the recovery strategy data to perform stability assessment on the financial transaction system, thereby obtaining environmental stability assessment data.

2. The testing method based on financial environment stability according to claim 1 is characterized in that: Step S1 includes the following steps: Step S11: Collect basic system operation parameters of the financial transaction system to generate basic performance data, where the basic system operation parameters include CPU usage, memory occupancy, disk IO, and network transmission rate; Step S12: Obtain the number of database connections, the number of active sessions, the SQL execution time, and the lock waiting status of the financial transaction system, thereby generating database status data; Step S13: monitor the message queue depth, message processing delay and message accumulation of the financial transaction system in real time, and generate middleware status data; monitor the key processes and thread status of the financial transaction system, and generate process status data; Step S14: collecting the business operation status of the financial transaction system to obtain transaction performance data, clearing status data and risk control status data, wherein the risk control status data includes transaction processing time, transaction success rate and transaction concurrency, the clearing status data includes clearing processing efficiency, fund arrival time and reconciliation consistency, and the risk control status data includes risk control rule response time, risk control interception rate and risk control accuracy rate; Step S15: performing time serialization processing on basic performance data, database status data, middleware status data and process status data to generate system layer status sequence data; Step S16: Perform business correlation analysis on the transaction performance data, liquidation status data, and risk control status data to generate business layer status correlation data; Step S17: merging the system layer state sequence data and the business layer state association data into system state basic data; Step S18: construct a virtual test environment according to the basic system status data, and perform adaptive configuration of the test scenario to generate test environment parameter data.

3. The testing method based on financial environment stability according to claim 2, characterized in that: Step S18 includes the following steps: Step S181: Perform hardware resource configuration based on the number of CPU cores, memory capacity, storage space, and network bandwidth according to the basic system status data, perform database instance configuration based on the connection pool size, cache size, and execution plan optimization parameter, and perform middleware parameter configuration based on the message queue size, thread pool parameters, and cache strategy, thereby obtaining environmental parameter configuration data; Step S182: constructing a transaction scenario model based on the transaction performance data to generate transaction scenario data, wherein the transaction scenario data includes transaction type distribution, transaction frequency pattern, and transaction size distribution; Step S183: constructing a liquidation scenario model based on the liquidation status data to generate liquidation scenario data, wherein the liquidation scenario data includes liquidation batches, liquidation scales, and liquidation time windows; Step S184: constructing a risk control scenario model according to the risk control status data to generate risk control scenario data, wherein the risk control scenario data includes a risk control rule set, a risk control threshold, and a risk control response strategy; Step S185: Optimize the scenario combination of the transaction scenario data, the clearing scenario data, and the risk control scenario data to generate comprehensive test scenario data; Step S186: adaptively adjusting load parameters of the comprehensive test scenario data based on the system status basic data to generate scenario load data; Step S187: Integrate and match the environmental parameter configuration data with the scene load data to generate test environment parameter data.

4. The testing method based on financial environment stability according to claim 3 is characterized in that: Step S2 includes the following steps: Step S21: Performing a gradient incremental test on the transaction parameters in the test environment parameter data to generate transaction stress test data, wherein the transaction parameters include the number of concurrent users, transaction frequency, and transaction complexity; Step S22: Perform large-value transaction and batch transaction stress tests according to the test environment parameter data to generate transaction capacity data including the upper limit of a single transaction amount, batch transaction concurrency, and cross-system transaction processing capability; Step S23: performing correlation analysis on the transaction stress test data and the transaction capacity data to generate transaction stress bearing capacity data; Step S24: performing a system capacity stress test according to the test environment parameter data to generate system capacity limit data, wherein the system capacity stress test includes a database stress test and a system storage capacity test; Step S25: Performing a network stress test based on network bandwidth pressure and network connection number limit according to the test environment parameter data to generate network carrying capacity data; Step S26: Calculate the system stability index based on the system capacity limit data, the transaction pressure bearing capacity data, and the network carrying capacity data, and compare and analyze with the pre-acquired historical benchmark to obtain stability benchmark data; Step S27: Perform dynamic load gradient processing according to the stability benchmark data to generate system pressure gradient data; perform risk level mapping on the system pressure gradient data to generate risk assessment mapping data.

5. The testing method based on financial environment stability according to claim 4 is characterized in that: Step S27 includes the following steps: Step S271: Perform multi-dimensional data stratification processing on the stability benchmark data to generate stratified benchmark data including a transaction layer pressure benchmark, a system layer pressure benchmark, and a network layer pressure benchmark; Step S272: constructing a dynamic load calculation model based on the hierarchical benchmark data, and performing load parameter standardization processing to generate load standardization data; Step S273: performing gradient feature extraction based on machine learning on the load normalization data to generate load feature vector data; Step S274: establishing a multi-level load gradient model according to the load characteristic vector data, and generating load gradient classification data including light load level, medium load level, heavy load level and overload level; Step S275: dynamically calculating the threshold value of the load gradient classification data, adaptively optimizing the threshold value according to the preset historical stress measurement data, and generating gradient threshold data; Step S276: Based on the gradient threshold data, the current load state of the system is evaluated in real time, and load prediction analysis is performed to generate system pressure gradient data; Step S277: Perform risk level mapping on the system pressure gradient data to generate risk assessment mapping data.

6. The testing method based on financial environment stability according to claim 5, characterized in that: Step S277 includes the following steps: Step S2771: Establish a multi-dimensional risk assessment indicator system based on the system pressure gradient data to generate risk indicator data, where the risk indicators include system performance risk, business processing risk, data consistency risk, and network transmission risk; Step S2772: classify the risk indicator data into risk levels according to the preset risk indicator threshold value to obtain risk level classification data; Step S2773: constructing an early warning rule model including early warning triggering conditions, early warning level determination, and early warning message push strategy based on the risk level classification data; Step S2774: verify the reliability of the early warning rule model, and optimize and adjust the rules based on the verification results to generate early warning strategy data; Step S2775: Map and associate the risk level classification data with the early warning strategy data to build a risk response mechanism, thereby obtaining risk assessment mapping data.

7. The testing method based on financial environment stability according to claim 6, characterized in that: Step S3 includes the following steps: Step S31: Collect abnormal behavior data of the financial transaction system through a distributed monitoring system, thereby obtaining original abnormal data including system layer abnormal data, application layer abnormal data and network layer abnormal data; Step S32: performing data cleaning and time series alignment on the original abnormal data to generate standardized abnormal data; extracting features based on performance abnormalities, resource abnormalities, and business abnormalities on the standardized abnormal data to obtain abnormal behavior feature data; Step S33: constructing a fault mode classification model for distinguishing system fault types, service fault types, and network fault types according to the abnormal mode sequence data, and using the fault mode classification model to identify the fault type to obtain fault classification data; Step S34: training an intelligent early warning model based on pre-acquired historical fault data to generate early warning model parameter data; performing dynamic probability evaluation on the fault classification data to generate fault probability data; Step S35: Calculate multi-level warning thresholds according to the warning model parameter data and the failure probability data, thereby obtaining threshold classification data; Step S36: construct an early warning rule model based on the threshold classification data to generate early warning trigger condition data, wherein the early warning rule model includes early warning condition definition, early warning level determination and early warning trigger mechanism.

8. The testing method based on financial environment stability according to claim 1, characterized in that: Step S5 includes the following steps: Step S51: construct a multi-dimensional risk assessment model based on the warning trigger condition data, extract risk features from the performance bottleneck location data, and generate risk feature data, wherein the risk features include performance degradation risk features, system crash risk features, data consistency risk features, and business interruption risk features; Step S52: performing risk propagation path analysis on the risk characteristic data, thereby obtaining risk propagation path data; Step S53: Probabilistically evaluate the risk propagation path data, establish a risk probability matrix, and generate risk probability distribution data; Step S54: performing multi-level risk classification according to the risk probability distribution data to generate risk assessment data; Step S55: performing a policy matching analysis on the risk assessment data according to a preset system recovery policy library to generate policy matching data, wherein the system recovery policy library includes a resource expansion policy, a load balancing policy, a service degradation policy, and a fault isolation policy; Step S56: construct a multi-dimensional recovery plan based on the policy matching data, and generate fault recovery plan data including an immediate recovery plan, a gradual recovery plan, an emergency recovery plan, and a disaster recovery switching plan; Step S57: Perform scenario simulation test on the fault recovery solution data, and perform effectiveness evaluation based on solution success rate, recovery time and resource consumption to generate simulation result data; Step S58: Generate a recovery strategy based on the simulation result data, thereby obtaining recovery strategy data.

9. A testing system based on financial environment stability, characterized in that: Used to execute the testing method based on financial environment stability as claimed in claim 1, the testing system based on financial environment stability comprises: The environment construction module is used to monitor the real-time status of the financial transaction system and generate basic system status data; build a virtual test environment based on the basic system status data, perform adaptive configuration of the test scenario, and generate test environment parameter data; The pressure assessment module is used to perform multi-dimensional pressure test analysis on the test environment parameter data, calculate the system stability index, and generate stability benchmark data; perform dynamic load gradient processing based on the stability benchmark data to obtain system pressure gradient data; perform risk level mapping on the system pressure gradient data to generate risk assessment mapping data; The abnormal monitoring module is used to collect abnormal behavior characteristics of the financial transaction system using a distributed monitoring system and generate abnormal behavior characteristic data; perform fault pattern recognition on the abnormal behavior characteristic data, establish fault warning thresholds, and generate warning trigger condition data; The performance diagnosis module is used to perform multi-dimensional performance analysis based on the real-time acquired system monitoring data to obtain performance indicator data, where the multi-dimensional performance includes multi-dimensional performance, resource utilization dimension, business processing dimension and reliability dimension; correlate the system pressure gradient data with the performance indicator data, identify bottlenecks, and generate performance bottleneck location data; The recovery strategy module is used to evaluate the risk level of the performance bottleneck location data through the early warning trigger condition data to obtain risk assessment data; build a system recovery strategy based on the risk assessment data to generate fault recovery plan data; simulate and verify the fault recovery plan data, and generate a recovery strategy based on the simulation results to obtain recovery strategy data; The stability assessment module is used to perform stability assessment on the financial transaction system using risk assessment mapping data and recovery strategy data, thereby obtaining environmental stability assessment data.

Images