Automated testing platform based on financial risk system and its construction method

Abstract

The present invention discloses an automated testing platform based on a financial risk system and a construction method thereof, which relates to the technical field of financial risk management, and includes the following steps: writing a series of automated testing scripts covering core business logic, performance bottlenecks and security mechanisms for the financial risk management system; while executing the test scripts, monitoring the operating status of the system in real time, and obtaining various data indicators related to the transaction load. The present invention uses a machine learning model to intelligently predict transaction peaks, identify high concurrency risks in advance, and dynamically adjust the test strategy when the load surges. With the help of traffic mirroring technology, real transaction traffic is copied to the test environment in real time, and the data volume is dynamically adjusted to accurately simulate business pressure, helping the financial risk management system to promptly discover and solve performance bottlenecks, resource contention and other problems, improve the scalability and security of the system, and reduce economic losses and compliance risks caused by high concurrency.

Description

Technical Field

[0001] The present invention relates to the technical field of financial risk management, and in particular to an automated testing platform based on a financial risk system and a construction method thereof. Background Art

[0002] The establishment of an automated testing platform based on a financial risk system refers to the construction of an integrated testing environment specifically for the automated evaluation and verification of the functions, performance and security of financial risk management systems. The platform usually includes key modules such as test data generation and management, automated script execution, risk model verification, stress testing, regression testing, anomaly detection and result analysis. Its core goal is to quickly and accurately discover potential problems in the system in various scenarios such as market fluctuations, credit risks, and liquidity risks through automated means, improve testing efficiency, reduce human errors, and ensure the stability and compliance of the system in a complex financial environment. The platform can also combine machine learning and big data analysis technologies to continuously optimize testing strategies and dynamically adjust test coverage to adapt to changing financial regulatory requirements and market dynamics.

[0003] In the process of building an automated testing platform based on a financial risk system, automated script execution refers to the use of pre-written test scripts to automatically complete the testing process of various system functions, performance and security without human intervention. These scripts usually cover the core business logic of the financial risk management system, such as market risk calculation, credit risk assessment, liquidity stress testing, etc., and verify the accuracy, stability and responsiveness of the system by simulating real transaction scenarios, data input and operation processes. The execution of automated scripts can be triggered by test management tools or continuous integration / continuous deployment (CI / CD) pipelines to achieve efficient regression testing, stress testing and boundary condition testing, ensuring that new risks or errors are not introduced when the system is upgraded or the environment changes. In addition, automated script execution also supports parallel testing and batch running, which improves test coverage and efficiency, reduces the uncertainty caused by human intervention, and ensures the high reliability of financial systems in complex environments.

[0004] The prior art has the following deficiencies:

[0005] In the process of executing tests through automated scripts, existing technologies often have difficulty running scripts intelligently and efficiently in a high-concurrency environment, resulting in the inability to accurately simulate concurrent operations in real transactions. During the peak of high-concurrency transactions, the system has not been fully stress-tested in the production environment because the scripts fail to truly reflect the actual load. When actual high-concurrency transactions occur, the system may crash or even shut down due to thread contention, resource exhaustion (such as CPU, memory, database connection pool), etc., which directly affects transaction execution and customer trust, resulting in huge economic losses.

[0006] The above information disclosed in this Background section is only for enhancement of understanding of the background of the present disclosure and therefore it may contain information that does not constitute the prior art that is already known to one of ordinary skill in the art. Summary of the invention

[0007] The purpose of the present invention is to provide an automated testing platform based on a financial risk system and a construction method thereof, which uses a machine learning model to intelligently predict transaction peaks, identify high concurrency risks in advance, and dynamically adjust the test strategy when the load surges. With the help of traffic mirroring technology, real transaction traffic is copied to the test environment in real time, and the amount of data is dynamically adjusted to accurately simulate business pressure. This method helps the financial risk management system to promptly discover and solve problems such as performance bottlenecks and resource contention, improve the scalability and security of the system, and reduce economic losses and compliance risks caused by high concurrency, so as to solve the problems in the above-mentioned background technology.

[0008] In order to achieve the above object, the present invention provides the following technical solution: a method for building an automated testing platform based on a financial risk system, comprising the following steps:

[0009] Write a series of automated test scripts covering core business logic, performance bottlenecks and security mechanisms for the financial risk management system;

[0010] While executing the test script, monitor the system's operating status in real time and obtain various data indicators related to the transaction load;

[0011] Pre-process the transaction load data collected by monitoring to ensure the quality and consistency of input data;

[0012] After preprocessing, feature engineering is used to select features related to high-concurrency transaction scenarios from massive indicators. The selected features are used as feature vectors to represent the load level of the system in the current monitoring window. After feature engineering is completed, the feature vectors are input into the pre-trained machine learning model in real time for prediction, identifying high-concurrency risks and predicting the potential peak of transaction load.

[0013] According to the prediction results given by the machine learning model, the system state is dynamically divided into two stages: normal transaction stage and high concurrent transaction load stage;

[0014] Once it is detected that the system transaction situation has entered the high concurrent transaction load stage, the concurrent pressure is dynamically simulated through the production environment traffic mirror replication, and the amount of data copied to the test environment is dynamically adjusted according to the concurrency situation.

[0015] Preferably, various data indicators related to the transaction load are collected through point-of-care monitoring, log analysis or third-party monitoring tools.

[0016] Preferably, feature engineering is used to select features related to high-concurrency transaction scenarios from massive indicators, and the selected features are used as feature vectors. The specific process is as follows:

[0017] The total waiting time caused by lock contention when threads execute tasks and the frequency of conflicts among concurrent transactions are extracted from various data indicators related to transaction load. The extracted indicators are deeply analyzed within the monitoring window through feature engineering methods, and thread contention quantification values ​​and transaction conflict quantification values ​​are generated respectively. They are used as feature vectors to characterize the load level of the system within the current monitoring window, which are further used for the identification and prediction of high-concurrency transaction scenarios.

[0018] Preferably, within the monitoring window, the feature vector thread contention quantization value and the transaction conflict quantization value are input in real time into a pre-trained machine learning model to generate a transaction concurrency coefficient, and the concurrent transactions of the financial risk management system are predicted through the transaction concurrency coefficient to identify high concurrency risks and predict the potential peak of transaction load.

[0019] Preferably, within the monitoring window, the specific steps of generating the thread contention quantization value by in-depth analysis of the total amount of waiting time caused by lock contention when the extracted threads execute tasks by means of feature engineering are as follows:

[0020] In the current monitoring window, the impact weight of the system thread during the lock contention process is first calculated to comprehensively evaluate the impact of the system thread under the lock contention condition. The calculation logic of the thread lock waiting time weight is as follows: ,in: is the thread lock waiting time weight, Indicates i The lock waiting time of each thread represents the total blocking time of the thread when competing for resources. Indicates i The resource priority weight of a thread, ranging from between, Indicates i The number of times a thread successfully acquires a lock in the current monitoring window measures the success rate of threads in competing for resources. Indicates i The total task execution time of each thread reflects the task processing capability of the thread in the current monitoring window. The minimum value introduced to prevent the denominator from being zero, N The total number of active threads in the current monitoring window, reflecting the concurrent scale of the system;

[0021] After obtaining the thread lock waiting time weight, it is normalized to represent the overall load level of the system in the current monitoring window. The calculation logic of the thread contention quantization value is as follows: ,in: It is the thread contention quantification value, which is used to quantify the concurrency pressure level of the current system. is the Gamma function, which measures the complexity of system lock contention, where As a tuning parameter, it represents the nesting degree of resource locks and the complexity of concurrent processing. The maximum lock contention threshold of the system, used for standardization, represents the maximum thread contention level that the system can withstand under the current hardware and software configuration.

[0022] Preferably, within the monitoring window, the specific steps of performing an in-depth analysis of the frequency of concurrent transaction conflicts by means of feature engineering to generate a transaction conflict quantification value are as follows:

[0023] First, in the monitoring window, extract the relevant data of concurrent transactions in the system in real time, calculate the number of conflicts for each transaction, and generate a preliminary conflict frequency index based on the frequency of conflicts. Use the following formula to calculate the frequency of transaction conflicts: ,in, Indicates the transaction conflict frequency within the current monitoring window. Is the indicator function, when the transaction In Resources R If a conflict occurs, the value is 1, otherwise it is 0. is the number of active transactions in the monitoring window, Indicates u The index of a transaction, which is a single database operation or transaction being executed in the system. p Indicates the total number of active transactions in the current monitoring window;

[0024] After completing the calculation of the transaction conflict frequency, it is further mapped to the transaction conflict quantification value and calculated using the following formula. The specific calculation expression is: ,in, Indicates the transaction conflict quantification value, Every transaction The weighting factor of the conflict on the system load, It is the overall system load factor for the current monitoring window, used to adjust the impact of conflict frequency under high load conditions.

[0025] Preferably, the transaction concurrency prediction coefficient generated when predicting the transaction situation of the financial risk management system through the pre-trained machine learning model in the monitoring window is compared and analyzed with the pre-set transaction concurrency prediction coefficient reference threshold, and the state of the system is dynamically divided into two stages. The specific division steps are as follows:

[0026] If the transaction concurrency prediction coefficient is greater than the transaction concurrency prediction coefficient reference threshold, the state of the system is dynamically divided into a high concurrent transaction load stage;

[0027] If the transaction concurrency prediction coefficient is less than or equal to the transaction concurrency prediction coefficient reference threshold, the state of the system is dynamically divided into the normal transaction stage.

[0028] Preferably, the concurrency pressure is dynamically simulated through the production environment traffic mirror replication, and the amount of data copied to the test environment is dynamically adjusted according to the concurrency situation. The specific steps are as follows:

[0029] When the financial risk management system enters the high concurrent transaction load stage, it will first automatically trigger the traffic mirror replication operation in the production environment. After the traffic mirror replication is turned on, it will continuously monitor the concurrent transaction load in the test environment and dynamically simulate the concurrent pressure.

[0030] According to the real-time fluctuation of the transaction concurrency prediction coefficient, the traffic replication rate is adjusted. Through the dynamic feedback control mechanism, the deviation between the current transaction concurrency prediction coefficient and the reference threshold of the transaction concurrency prediction coefficient is detected, and the traffic increment or decrement is dynamically adjusted to ensure that the test environment is always in a high-efficiency concurrent pressure state. The expression for dynamic adjustment is: ,in, To adjust the flow rate increase or decrease in real time, Adjust the sensitivity coefficient for flow rate and determine the adjustment range. , is the current traffic level that has been copied to the test environment, is the transaction concurrency prediction coefficient predicted in real time by the machine learning model. A reference threshold for the transaction concurrency prediction coefficient;

[0031] While dynamically regulating the traffic, adaptive matching is performed according to the carrying capacity of the test environment to determine the transaction traffic that is ultimately copied to the test environment. The specific determination expression is: ,in, To finally copy the transaction flow to the test environment, is the load capacity adjustment coefficient, which is used for load balance adjustment and has a value range of , is the system load utilization of the current test environment, The maximum load bearing capacity of the test environment.

[0032] An automated testing platform based on financial risk systems, including an automated testing script writing module, a real-time transaction monitoring module, a data preprocessing module, a high-concurrency feature extraction and prediction module, a dynamic state division module, and a traffic mirroring and load control module;

[0033] Automated test script writing module, which writes a series of automated test scripts covering core business logic, performance bottlenecks and security mechanisms for the financial risk management system;

[0034] Real-time transaction monitoring module, which monitors the system's operating status in real time while executing the test script and obtains various data indicators related to the transaction load;

[0035] The data preprocessing module preprocesses the transaction load data collected by monitoring to ensure the quality and consistency of the input data;

[0036] The high-concurrency feature extraction and prediction module, after preprocessing, uses feature engineering to select features related to high-concurrency transaction scenarios from massive indicators, and uses the selected features as feature vectors to represent the system load level in the current monitoring window. After the feature engineering is completed, the feature vectors are input into the pre-trained machine learning model in real time for prediction, identifying high-concurrency risks and predicting the potential peak of transaction load;

[0037] The dynamic state division module dynamically divides the system state into two stages according to the prediction results given by the machine learning model: the normal transaction stage and the high concurrent transaction load stage;

[0038] The traffic mirroring and load regulation module, once it detects that the system transaction situation has entered the high concurrent transaction load stage, dynamically simulates the concurrent pressure through traffic mirroring replication in the production environment, and dynamically regulates the amount of data copied to the test environment according to the concurrent situation.

[0039] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0040] The present invention combines comprehensive automated test scripts with real-time transaction load monitoring, combined with data preprocessing and feature engineering to ensure the high quality and consistency of input data. Using pre-trained machine learning models, the system can intelligently predict transaction peaks and identify high concurrency risks in advance. When the transaction load surges, the system dynamically divides the state and adjusts the test strategy. With the help of traffic mirroring technology, real transaction traffic is copied to the test environment in real time without interrupting production business, and the data volume is dynamically adjusted according to the degree of concurrency to ensure that the test environment accurately simulates actual business pressure. Enable the financial risk management system to promptly discover and solve performance bottlenecks, resource contention, transaction conflicts and other problems, improve the system's scalability, security and transaction processing capabilities, while reducing potential economic losses and compliance risks caused by high concurrency. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0042] Figure 1 The present invention is a method flow chart of a method for building an automated testing platform based on a financial risk system.

[0043] Figure 2 It is a module schematic diagram of the automated testing platform based on the financial risk system of the present invention. DETAILED DESCRIPTION

[0044] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these example embodiments are provided so that the description of the present disclosure will be more comprehensive and complete, and the concept of the example embodiments will be fully conveyed to those skilled in the art.

[0045] The present invention provides Figure 1 The method for building an automated testing platform based on a financial risk system shown includes the following steps:

[0046] Write a series of automated test scripts covering core business logic, performance bottlenecks and security mechanisms for the financial risk management system;

[0047] These scripts need to be combined with the key functional modules of the system (such as market risk calculation, credit risk assessment, liquidity management, transaction matching, etc.), and classified and designed for different test types (functional testing, performance testing, abnormal testing, and security testing). The purpose is to verify the key functions of the system through standardized and repeatable test scripts, and provide a solid foundation for subsequent dynamic testing.

[0048] While executing the test script, monitor the system's operating status in real time and obtain various data indicators related to the transaction load;

[0049] For example, transaction requests per second (TPS), transaction response time, number of concurrent users, CPU and memory usage, number of database connections, etc. These data can be collected through point monitoring, log analysis, or third-party monitoring tools (such as Prometheus and Grafana). Provide real and continuously updated operation data for subsequent high-concurrency identification and intelligent prediction, and ensure that the test environment is as close to the actual production environment as possible.

[0050] 1. The process of collecting transaction load data through point monitoring;

[0051] Tracking monitoring is a proactive data collection method that usually manually or automatically embeds code-level monitoring points in key business processes of financial risk management systems (such as transaction requests, risk control calculations, payment processing, etc.). These tracking points can be inserted into the system's front-end (such as transaction page operations, button clicks, etc.) and back-end (such as database queries, service calls, API responses) processes through SDK, API or AOP (aspect-oriented programming) technology. During the transaction execution process, tracking points will automatically capture relevant data, such as the number of requests, processing delays, failure rates, user behaviors, etc., and upload them to the monitoring platform or database in real time for storage and analysis. The advantage of tracking point monitoring is that it is highly customizable and can accurately locate bottlenecks in the transaction process, but it requires more upfront development and maintenance investment.

[0052] 2. The process of collecting transaction load data through log analysis;

[0053] Log analysis is a passive collection method that relies on data sources such as application logs, system logs, and database logs that are automatically generated by the system during the transaction process. Usually, the system will record detailed log information when executing each transaction, including transaction time, user ID, request parameters, response time, error information, etc. Through centralized log management tools (such as ELK Stack—Elasticsearch, Logstash, Kibana), transaction logs distributed on various servers can be collected, stored, and analyzed in real time. The analysis tool will perform text parsing, regular matching, time series analysis, etc. on the logs to extract key indicators (such as transaction requests per second TPS, average response time, error rate, etc.). The advantage of log analysis is that it is non-invasive and can be expanded and adjusted at any time, but due to the huge amount of logs, storage and query optimization must be done to avoid excessive performance overhead.

[0054] 3. The process of third-party monitoring tools collecting transaction load data;

[0055] Third-party monitoring tools (such as Prometheus, Grafana, New Relic, Datadog, etc.) can provide real-time performance monitoring and data visualization, usually by deploying lightweight monitoring agents (agents) or server-side plug-ins in the system to automatically collect key performance indicators. These tools usually support multiple data collection methods, such as API pull, SNMP protocol, JMX interface, etc., and can monitor the server's CPU usage, memory usage, disk IO, number of database connections, network traffic, number of concurrent users, etc., and provide real-time alarms and data visualization. The real-time transaction load status is displayed through the dashboard, and threshold monitoring is set. If abnormal fluctuations are found (such as a surge in transactions, response time exceeding the standard, etc.), an alarm can be triggered immediately to notify relevant personnel. The advantage of third-party monitoring tools is that they are ready to use out of the box, provide highly visualized monitoring capabilities, and are easy to integrate with existing systems, but there may be certain costs and learning curves.

[0056] Pre-process the transaction load data collected by monitoring (denoising, standardization, missing value filling, normalization, etc.) to ensure the quality and consistency of input data;

[0057] Preprocess the transaction load data, including denoising, standardization, missing value filling, etc. For example, remove extreme noise points through sliding average, outlier detection and other methods, and standardize data of different orders of magnitude or distribution to a unified scale. Batch aggregation or segmentation can also be performed according to the monitoring window to better mine the time series characteristics of the data. The role is to ensure the quality and consistency of the input data, lay a solid foundation for subsequent feature screening and machine learning model prediction, and avoid bad data affecting the accuracy of the prediction results.

[0058] After preprocessing, feature engineering is used to select features related to high-concurrency transaction scenarios from massive indicators. The selected features are used as feature vectors to represent the load level of the system in the current monitoring window. After feature engineering is completed, the feature vectors are input into the pre-trained machine learning model in real time for prediction, identifying high-concurrency risks and predicting the potential peak of transaction load.

[0059] Feature engineering is used to select features related to high-concurrency transaction scenarios from massive indicators, and the selected features are used as feature vectors. The specific process is as follows:

[0060] The total waiting time caused by lock contention when threads execute tasks and the frequency of conflicts among concurrent transactions are extracted from various data indicators related to transaction load. The extracted indicators are deeply analyzed within the monitoring window through feature engineering methods, and thread contention quantification values ​​and transaction conflict quantification values ​​are generated respectively. They are used as feature vectors to characterize the load level of the system within the current monitoring window, which are further used for the identification and prediction of high-concurrency transaction scenarios.

[0061] The higher the total waiting time caused by lock contention when threads are executing tasks, the higher the risk of high-concurrency transactions that the financial risk management system is facing. The root cause of lock contention is that multiple threads access shared resources (such as databases, memory caches, transaction matching engines, etc.) at the same time. In a high-concurrency transaction environment, the surge in requests will lead to increased resource contention, which in turn causes threads to wait for lock release for a long time. As the waiting time increases, the throughput of the system gradually decreases and the response time increases, which may cause transaction backlogs, timeout failures, and even trigger cascading failures, affecting the stability and real-time performance of the overall financial business. In addition, a higher lock contention waiting time may also expose the system's potential bottlenecks in concurrency control, transaction isolation, resource scheduling, etc. If it is not optimized in time, it may cause the system to experience serious performance degradation during peak trading periods, thereby affecting user experience and business continuity. Therefore, continuous monitoring and optimization of lock contention is crucial to ensure the stability of the system in high-concurrency scenarios.

[0062] In the monitoring window, the specific steps of generating thread contention quantification values ​​by in-depth analysis of the total waiting time caused by lock contention when the extracted threads are executing tasks through feature engineering are as follows:

[0063] In the current monitoring window, the impact weight of the system thread during the lock contention process is first calculated to comprehensively evaluate the impact of the system thread under the lock contention condition. The calculation logic of the thread lock waiting time weight is as follows: ,in: is the thread lock waiting time weight, Indicates i The lock waiting time of each thread represents the total blocking time of the thread when competing for resources. Indicates i The resource priority weight of a thread, ranging from The larger the value, the higher the priority of the thread's demand for resources. For example, a high-priority transaction processing thread has a higher weight. Indicates i The number of times a thread successfully acquires a lock in the current monitoring window measures the success rate of threads in competing for resources. Indicates i The total task execution time of each thread reflects the task processing capability of the thread in the current monitoring window. The minimum value introduced to prevent the denominator from being zero, N The total number of active threads in the current monitoring window, reflecting the concurrent scale of the system;

[0064] This step combines the thread's lock waiting time, resource priority, number of successful contention, and task execution time to generate the impact of thread contention in a weighted manner. By introducing a logarithmic function, the interference of extreme task time on the overall weight is weakened, while the sensitivity to high-priority thread contention is enhanced. The purpose of this step is to accurately extract the key factors that affect the high concurrency of the system from the underlying thread running data, providing a basic basis for further generating thread contention quantification values.

[0065] After obtaining the thread lock waiting time weight, it is normalized to represent the overall load level of the system in the current monitoring window. The calculation logic of the thread contention quantization value is as follows: ,in: It is the thread contention quantification value, which is used to quantify the concurrency pressure of the current system. The higher the value, the greater the risk of high concurrent transactions faced by the system. is the Gamma function, which measures the complexity of system lock contention, where As a tuning parameter, it represents the nesting degree of resource locks and the complexity of concurrent processing. The maximum lock contention threshold of the system is used for standardization, indicating the maximum thread contention level that the system can withstand under the current hardware and software configuration;

[0066] The Gamma function is an important special function in mathematical analysis. It is an extension of the concept of factorial and is used to define and calculate factorials of non-integer orders. n , the relationship between the Gamma function and the factorial is , but it is defined in the right half plane of the complex domain, that is, for all complex numbers with real parts greater than zero z , the Gamma function is expressed by the following integral: , this definition ensures that the factorial can be effectively calculated even in non-integer cases, and is widely used in many mathematical and engineering fields, such as probability statistics, complex analysis, numerical calculation, etc. The Gamma function has a recursive property, that is, it satisfies This property makes it very useful in solving complex computational problems such as distribution functions, Beta distribution, and fluid dynamics. In addition, the Gamma function has an asymptotic expansion in terms of large number approximation and is closely related to related mathematical concepts such as Beta function and Poisson distribution.

[0067] By introducing The concurrent scale of the reaction system, combined with the Gamma function Zoom in on the factors that affect complex lock contention conditions and use a maximum lock contention threshold Normalization is performed to make the final result more meaningful. The purpose of this step is to transform complex thread contention characteristics into quantifiable results, help monitor the system load status in real time, and provide a reliable basis for predicting and responding to high concurrent transaction risks.

[0068] In the monitoring window, the thread contention quantization value generated by the feature engineering method is deeply analyzed for the total waiting time caused by lock contention when the extracted threads execute tasks. The larger the performance value, the higher the risk of high concurrent transactions in the financial risk management system. Conversely, the lower the risk of high concurrent transactions. The thread contention quantization value reflects the degree of competition for shared resources among multiple threads in the system in a concurrent environment. When the thread contention quantization value is high, it means that there are long lock waiting times, frequent resource contention, and potential performance bottlenecks in the system, which may lead to transaction delays, reduced throughput, and even transaction backlogs or failures. Therefore, a high thread contention quantization value is usually a direct signal of high concurrent transaction pressure. On the contrary, if the thread contention quantization value is low, it means that the system can efficiently handle the current transaction load, resource allocation is reasonable, and concurrency control is good, indicating that the system faces a low risk of high concurrent transactions under current conditions and stable performance.

[0069] A high frequency of conflicts in concurrent transactions usually indicates that the financial risk management system has a greater performance risk in high-concurrency trading scenarios. When multiple transactions modify the same resource (such as account balances, market data, or order records) at the same time, conflicts will occur if the system fails to effectively manage concurrent access. These conflicts not only cause transaction rollbacks and retries, but also increase latency and reduce transaction throughput, which in turn affects the system's response speed and processing capabilities. Frequent transaction conflicts mean that the system cannot efficiently handle concurrent requests under high concurrent transaction loads, which may cause deadlocks, resource contention and other problems, which in turn affects the stability and reliability of the system. In severe cases, it may cause transaction delays or failures, bringing great business risks to the financial risk management system. Therefore, the high frequency of transaction conflicts is an important early warning sign of high-concurrency trading risks.

[0070] In the monitoring window, the specific steps for generating transaction conflict quantification values ​​by in-depth analysis of the frequency of concurrent transaction conflicts through feature engineering are as follows:

[0071] First, in the monitoring window, extract relevant data about concurrent transactions in the system in real time, especially conflict records about database transactions. These records usually include information such as the start and end time of transaction execution, lock resources, conflict events (such as deadlock, resource competition, etc.), and transaction status. On this basis, calculate the number of conflicts for each transaction, and generate a preliminary conflict frequency index based on the frequency of conflicts. Specifically, the frequency of transaction conflicts can be calculated using the following formula: ,in, Indicates the transaction conflict frequency within the current monitoring window. Is the indicator function, when the transaction In Resources R If a conflict occurs, the value is 1, otherwise it is 0. is the number of active transactions in the monitoring window, Indicates u The index of a transaction, which is a single database operation or transaction being executed in the system. p Indicates the total number of active transactions in the current monitoring window, that is, p is the number of transactions being executed concurrently in the system;

[0072] This step can accurately reflect the concurrent pressure of the system by accurately recording and calculating the conflict events of each transaction. By calculating the frequency of transaction conflicts, the risk of excessive system load can be identified, thereby providing basic data for subsequent index generation.

[0073] After the transaction conflict frequency is calculated, it is further mapped to the transaction conflict quantification value. In order to more precisely characterize the system load level, the transaction conflict quantification value is not directly equal to the conflict frequency, but is combined with the weighted factor of the overall system load. Specifically, the following formula can be used for calculation. The specific calculation expression is: ,in, Indicates the transaction conflict quantification value, Every transaction The weighted coefficient of conflict on system load takes into account factors such as transaction type, intensity of lock contention, and time segment of transaction execution. No specific restrictions are made here. It is the overall system load factor (such as CPU utilization, memory usage, etc.) of the current monitoring window, which is used to adjust the impact of conflict frequency under high load conditions;

[0074] This step, through weighted adjustment and the introduction of load factors, makes the transaction conflict quantification value not only take into account the frequency of the conflict itself, but also reflect the dynamic changes of the system load, providing a more refined system load monitoring indicator. In this way, in high-concurrency transaction scenarios, the transaction conflict quantification value can more accurately reveal the bottleneck risk of the system, providing strong support for subsequent load tuning and resource allocation.

[0075] In the monitoring window, the transaction conflict quantification value generated by in-depth analysis of the frequency of concurrent transaction conflicts through feature engineering means has a larger performance value, indicating that the financial risk management system has a higher risk of high concurrent transactions. The transaction conflict quantification value reflects the frequency and intensity of conflicts when the system handles concurrent transactions in the monitoring window. When the transaction conflict quantification value is large, it means that there are more concurrent transaction conflicts in the system, which usually means that the system has weak processing capabilities under high concurrent loads, which may cause response delays, transaction failures, deadlocks and other problems, thereby increasing the risk of system crashes or unstable operations. On the contrary, when the transaction conflict quantification value is low, it means that there are fewer concurrent transaction conflicts, and the system can handle high concurrent loads more smoothly, indicating that the system has a lower risk when facing high concurrent transactions. Therefore, the transaction conflict quantification value is an important indicator for judging whether the system can operate stably in a high concurrent environment.

[0076] Within the monitoring window, the feature vector thread contention quantization value and transaction conflict quantization value are input in real time into the pre-trained machine learning model to generate a transaction concurrency coefficient. The transaction concurrency coefficient is used to predict the concurrent transactions of the financial risk management system, identify high concurrency risks, and predict the potential peak of transaction load.

[0077] In the concurrent transaction prediction of the financial risk management system, the so-called "pre-trained machine learning model" refers to the model training through historical transaction data and previously collected load indicators (such as thread contention quantification value, transaction conflict quantification value, etc.) before the system is officially put into operation, so as to obtain an algorithm that can intelligently predict the real-time transaction situation. This process usually involves a series of steps such as data preprocessing, feature engineering, model selection, training and verification. After training, the machine learning model can automatically identify the potential change pattern of transaction load, predict the occurrence of high-concurrency transactions in the future, and provide decision makers with efficient prediction results.

[0078] A pre-trained machine learning model is not just a static black box, but an intelligent system with dynamic learning and optimization capabilities. By using historical data sets (including system load, transaction requests, latency data, etc.), the model can gradually learn the key features of high-concurrency transactions at different training stages, thereby providing accurate load predictions for the real-time operation of the system. These models can be regression models (such as linear regression, support vector machine regression), classification models (such as decision trees, random forests), time series models (such as LSTM, ARIMA), etc. The specific choice depends on the characteristics of the task and the characteristics of the data. In the scenario of high-concurrency prediction of financial transactions, time series models and feature-based regression models are more common choices.

[0079] The quality of machine learning models is highly dependent on the quality of input data. Before training, it is first necessary to collect a large amount of historical transaction data, system resource data, and load indicators (such as thread contention quantification values, transaction conflict quantification values, CPU and memory utilization, etc.) from the financial risk management system. In order to ensure the high quality of data, data preprocessing is an indispensable step. Data preprocessing usually includes data cleaning (such as removing missing values, noise data, etc.), feature selection (such as selecting the most useful features for prediction), data normalization (ensuring the consistency of each feature dimension) and data partitioning (dividing the data into training set, validation set, and test set). For time series data, the data is usually processed for stationarity, such as difference and logarithmic transformation, in order to improve the accuracy of the prediction model.

[0080] In financial risk management systems, feature engineering is a key step that affects model performance. Thread contention quantification values ​​and transaction conflict quantification values ​​are common high-concurrency load features, but these are only part of the data. In order to further improve the predictive power of the model, it is often necessary to extract more fine-grained features, or even derive new features (such as latency, throughput change trends, load fluctuations, etc.) to enhance the model's sensitivity to high concurrency. For example, system resource consumption (such as CPU usage and memory usage) can be combined with transaction response time to generate a resource utilization index to help the model identify the impact of resource bottlenecks on transaction loads.

[0081] The purpose of feature selection is to select the most representative indicators, reduce data redundancy and the risk of overfitting of the model. Feature selection can be done through some methods, such as information gain-based selection method, L1 regularized regression, recursive feature elimination (RFE), etc. After selecting appropriate features, the training data can provide the model with a clear and concise perspective for training, thereby improving the accuracy and speed of prediction.

[0082] After feature engineering is completed, the next step is to select a suitable machine learning model. For transaction load prediction problems, commonly used models include linear regression, support vector machine, decision tree, random forest, neural network (such as LSTM, GRU), etc. Each model has different advantages and disadvantages, and the selection criteria usually depend on the characteristics of the data and the prediction target.

[0083] Linear regression: Applicable to situations where there is a linear relationship between input features and output targets. It is simple and easy to understand, but may not capture complex nonlinear relationships.

[0084] Support Vector Machine (SVM): It can perform classification and regression in high-dimensional space, has good processing capabilities for nonlinear relationships, and is suitable for learning complex data.

[0085] Decision trees and random forests: Making decisions through a tree structure can handle nonlinear features and provide better interpretability. Random forests can further improve the robustness and accuracy of the model by integrating multiple decision trees.

[0086] Long Short-Term Memory (LSTM): As an extension of the recurrent neural network (RNN), LSTM is particularly good at processing time series data and can effectively capture long-term dependencies in the data. It is particularly effective for transaction load data with time series characteristics.

[0087] During the training process, methods such as cross-validation and grid search are used to adjust the model's hyperparameters and optimize the model's prediction performance. In addition, loss functions (such as mean square error, cross entropy loss, etc.) are used during training to measure the model's prediction error, and the model weights are adjusted based on feedback. Through multiple rounds of iterative optimization, the model will continuously improve its prediction accuracy.

[0088] After the model training is completed, the validation set and test set need to be used to evaluate the model. Common evaluation indicators include accuracy, recall, F1 score, mean square error (MSE), etc. Through these evaluation indicators, the generalization ability of the model on unseen data can be judged to ensure that the model will not be overfitted or underfitted.

[0089] In particular, in high-concurrency prediction tasks, prediction accuracy and real-time performance are key indicators. The model needs to be able to accurately predict changes in transaction load and respond in a short time, so the model's real-time prediction capabilities also need to be verified.

[0090] After training is completed and passed the evaluation verification, the machine learning model will be deployed to the production environment and start processing the transaction load data in the system in real time. At this time, the model generates the transaction concurrency coefficient and predicts whether there is a high concurrency risk through the transaction load characteristics obtained in real time. As new data continues to flow in, the model can be updated in real time through incremental learning and online learning to ensure that the model always remains sensitive to the latest transaction trends.

[0091] Pre-trained machine learning models play a vital role in financial risk management systems. They build efficient prediction capabilities through historical data learning and feature engineering, and can intelligently identify potential risks of high concurrent transaction loads. In this way, the system can perceive fluctuations in concurrent pressure in advance and provide accurate guidance for decisions such as resource scheduling and traffic control. As the transaction load continues to change, the model can also dynamically adjust the prediction based on real-time data inflows to ensure that the financial system can operate efficiently and stably in the face of high concurrent transactions.

[0092] The machine learning model is not specifically limited here, and can achieve the quantization of thread contention values and transaction conflict quantification value Conduct comprehensive analysis to generate transaction concurrency prediction coefficients In order to realize the technical solution of the present invention, the present invention provides a specific implementation method; transaction concurrency prediction coefficient The generated expression is: , where , Quantized values ​​for thread contention and transaction conflict quantification value The preset scaling factor of , All are greater than 0. Preset proportional coefficient ( , ) refers to the weight parameters assigned to the thread contention quantization value and the transaction conflict quantization value in the process of calculating the transaction concurrency prediction coefficient. The role of these preset proportional coefficients is to determine the degree of influence of the two indicators on the final prediction results based on actual business needs and historical data experience. Specifically, the higher A value of 0 means that the thread contention quantization value takes a greater proportion in the concurrency prediction, and a higher This means that the transaction conflict quantification value contributes more to the prediction. The selection of preset proportional coefficients is usually based on the analysis of historical transaction data, combined with machine learning or statistical modeling methods to ensure that the prediction results can accurately reflect the system's concurrency risk status under different transaction load scenarios. The design of these preset proportional coefficients enables the prediction model to flexibly adapt to different sources of concurrency pressure and improve the accuracy and applicability of the prediction.

[0093] It can be seen from the transaction concurrency prediction coefficient that, within the monitoring window, the greater the performance value of the thread contention quantization value generated by in-depth analysis of the total waiting time caused by lock contention when the extracted threads execute tasks through feature engineering means, the greater the performance value of the transaction conflict quantization value generated by in-depth analysis of the frequency of concurrent transaction conflicts through feature engineering means, that is, the greater the performance value of the transaction concurrency prediction coefficient generated when predicting the transaction situation of the financial risk management system through a pre-trained machine learning model within the monitoring window, the higher the risk of high concurrent transactions in the financial risk management system, and vice versa.

[0094] According to the prediction results given by the machine learning model, the system state is dynamically divided into two stages: normal transaction stage and high concurrent transaction load stage;

[0095] The transaction concurrency prediction coefficient generated when the transaction situation of the financial risk management system is predicted by the pre-trained machine learning model in the monitoring window is compared and analyzed with the pre-set transaction concurrency prediction coefficient reference threshold, and the system state is dynamically divided into two stages. The specific division steps are as follows:

[0096] If the transaction concurrency prediction coefficient is greater than the transaction concurrency prediction coefficient reference threshold, the state of the system is dynamically divided into a high concurrent transaction load stage;

[0097] If the transaction concurrency prediction coefficient is less than or equal to the transaction concurrency prediction coefficient reference threshold, the state of the system is dynamically divided into the normal transaction stage.

[0098] Once it is detected that the system transaction situation has entered the high concurrent transaction load stage, the concurrent pressure is dynamically simulated through the production environment traffic mirror replication, and the amount of data copied to the test environment is dynamically adjusted according to the concurrency situation;

[0099] Through the production environment traffic mirror replication, dynamically simulate the concurrent pressure, and dynamically adjust the amount of data copied to the test environment according to the concurrency situation. The specific steps are as follows:

[0100] When the financial risk management system enters the high concurrent transaction load stage, it will first automatically trigger the traffic mirror replication operation in the production environment. After the traffic mirror replication is turned on, it will continuously monitor the concurrent transaction load in the test environment and dynamically simulate the concurrent pressure.

[0101] According to the real-time fluctuation of the transaction concurrency prediction coefficient, the traffic replication rate is adjusted. Through the dynamic feedback control mechanism, the deviation between the current transaction concurrency prediction coefficient and the reference threshold of the transaction concurrency prediction coefficient is detected, and the traffic increment or decrement is dynamically adjusted to ensure that the test environment is always in a high-efficiency concurrent pressure state. The expression for dynamic adjustment is: ,in, The flow rate increment or decrement adjusted in real time (positive value indicates increase, negative value indicates decrease). It is the flow rate adjustment sensitivity coefficient, which determines the adjustment range. Usually , is the current traffic level (transaction requests / second) that has been copied to the test environment. is the transaction concurrency prediction coefficient predicted in real time by the machine learning model. A reference threshold for the transaction concurrency prediction coefficient;

[0102] The purpose of this step is to achieve dynamic control and real-time adjustment of traffic, avoid sudden overload or underload of traffic, and ensure that the test environment always maintains a pressure level that matches the production environment. This strategy allows the test system to automatically adjust the traffic size according to the current system load, avoiding resource waste or test environment crash, and can simulate sudden transaction peaks in a timely manner.

[0103] While dynamically regulating the traffic, adaptive matching is performed according to the carrying capacity of the test environment to ensure that the test environment resources can effectively bear the load when the high concurrent transaction load continues to increase. In this step, by measuring the system load utilization, it is incorporated into the traffic regulation decision to prevent the distortion or collapse of the test environment due to overload, thereby determining the transaction traffic that is finally copied to the test environment. The specific expression is: ,in, To finally copy the transaction flow to the test environment, is the load capacity adjustment coefficient, which is used for load balance adjustment and has a value range of , is the system load utilization of the current test environment (CPU, memory, I / O, etc.), The maximum load bearing capacity of the test environment (usually set to 80% warning threshold);

[0104] The core goal of this step is to ensure that the carrying capacity of the test environment is balanced with the actual business load, so as to avoid exceeding the system carrying capacity when the traffic increases, resulting in test failure or distorted results. At the same time, by monitoring the utilization rate in real time, reasonable scheduling of resources is achieved to ensure the efficient operation and stability of the test environment in high-concurrency scenarios.

[0105] The purpose of this step is to use the production environment traffic mirroring technology to copy the real transaction traffic in the production environment to the test environment in real time when the system enters the high-concurrency transaction load stage, so as to accurately simulate the high-concurrency scenario without interrupting normal business. By dynamically adjusting the amount of data copied to the test environment, it is ensured that the test environment can accurately reproduce the load characteristics of the production environment and identify potential system bottlenecks, such as resource contention, transaction conflicts, response delays, etc. This process not only helps to verify the performance stability, fault recovery and scalability of the system under high-concurrency conditions, but also can intelligently adjust the test intensity based on the fluctuation of the real-time transaction concurrency coefficient to avoid overload or underload of the test environment, thereby providing a scientific basis for further optimization and capacity planning.

[0106] The present invention provides an automated testing platform based on a financial risk system and a construction method thereof, which can accurately and efficiently simulate high-concurrency transaction scenarios and ensure the stability and reliability of the financial system under extreme load conditions. Through comprehensive coverage of automated test scripts, real-time monitoring of transaction loads, combined with data preprocessing and feature engineering, the high quality and consistency of input data are guaranteed. With the help of a pre-trained machine learning model, the system can intelligently predict transaction peaks and identify high-concurrency risks in advance, so that when the transaction load surges, the system state can be dynamically divided and the test strategy can be adjusted. The beneficial effect of this solution is that, without interrupting production business, real transaction traffic can be copied to the test environment in real time through traffic mirroring technology, and the amount of data can be dynamically adjusted in combination with the degree of concurrency to ensure that the test environment accurately simulates the actual business pressure. Thereby, the financial risk management system can promptly discover and solve performance bottlenecks, resource contention, transaction conflicts and other problems, improve the scalability, security and transaction processing capabilities of the system, and reduce the potential economic losses and compliance risks caused by high concurrency.

[0107] The present invention provides Figure 2 The automated testing platform based on the financial risk system shown includes an automated testing script writing module, a real-time transaction monitoring module, a data preprocessing module, a high-concurrency feature extraction and prediction module, a dynamic state division module, and a traffic mirroring and load regulation module;

[0108] Automated test script writing module, which writes a series of automated test scripts covering core business logic, performance bottlenecks and security mechanisms for the financial risk management system;

[0109] Real-time transaction monitoring module, which monitors the system's operating status in real time while executing the test script and obtains various data indicators related to the transaction load;

[0110] The data preprocessing module preprocesses the transaction load data collected by monitoring to ensure the quality and consistency of the input data;

[0111] The high-concurrency feature extraction and prediction module, after preprocessing, uses feature engineering to select features related to high-concurrency transaction scenarios from massive indicators, and uses the selected features as feature vectors to represent the system load level in the current monitoring window. After the feature engineering is completed, the feature vectors are input into the pre-trained machine learning model in real time for prediction, identifying high-concurrency risks and predicting the potential peak of transaction load;

[0112] The dynamic state division module dynamically divides the system state into two stages according to the prediction results given by the machine learning model: the normal transaction stage and the high concurrent transaction load stage;

[0113] The traffic mirroring and load regulation module, once it detects that the system transaction situation has entered the high concurrent transaction load stage, will dynamically simulate the concurrent pressure through the production environment traffic mirror replication, and dynamically regulate the amount of data copied to the test environment according to the concurrent situation;

[0114] The method for building an automated testing platform based on a financial risk system provided in an embodiment of the present invention is implemented through the above-mentioned automated testing platform based on a financial risk system. The specific methods and processes of the automated testing platform based on a financial risk system are detailed in the embodiment of the method for building an automated testing platform based on a financial risk system, which will not be repeated here.

[0115] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters in the formula are set by technicians in this field according to actual conditions.

[0116] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0117] The above description is only by way of illustration of certain exemplary embodiments of the present invention. It is undoubted that those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the above drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

[0118] The above description is only by way of illustration of certain exemplary embodiments of the present invention. It is undoubted that those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the above drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. A method for building an automated testing platform based on a financial risk system, characterized in that: The following steps are involved: Write a series of automated test scripts covering core business logic, performance bottlenecks and security mechanisms for the financial risk management system; While executing the test script, monitor the system's operating status in real time and obtain various data indicators related to the transaction load; Pre-process the transaction load data collected by monitoring to ensure the quality and consistency of input data; After preprocessing, feature engineering is used to select features related to high-concurrency transaction scenarios from massive indicators. The selected features are used as feature vectors to represent the load level of the system in the current monitoring window. After feature engineering is completed, the feature vectors are input into the pre-trained machine learning model in real time for prediction, identifying high-concurrency risks and predicting the potential peak of transaction load. According to the prediction results given by the machine learning model, the system state is dynamically divided into two stages: normal transaction stage and high concurrent transaction load stage; Once it is detected that the system transaction situation has entered the high concurrent transaction load stage, the concurrent pressure is dynamically simulated through the production environment traffic mirror replication, and the amount of data copied to the test environment is dynamically adjusted according to the concurrency situation; Through the production environment traffic mirror replication, dynamically simulate the concurrent pressure, and dynamically adjust the amount of data copied to the test environment according to the concurrency situation. The specific steps are as follows: When the financial risk management system enters the high concurrent transaction load stage, it will first automatically trigger the traffic mirror replication operation in the production environment. After the traffic mirror replication is turned on, it will continuously monitor the concurrent transaction load in the test environment and dynamically simulate the concurrent pressure. According to the real-time fluctuation of the transaction concurrency prediction coefficient, the traffic replication rate is adjusted. Through the dynamic feedback control mechanism, the deviation between the current transaction concurrency prediction coefficient and the reference threshold of the transaction concurrency prediction coefficient is detected, and the traffic increment or decrement is dynamically adjusted to ensure that the test environment is always in a high-efficiency concurrent pressure state. The expression for dynamic adjustment is: ,in, To adjust the flow rate increase or decrease in real time, Adjust the sensitivity coefficient for flow rate and determine the adjustment range. , is the current traffic level that has been copied to the test environment, is the transaction concurrency prediction coefficient predicted in real time by the machine learning model. A reference threshold for the transaction concurrency prediction coefficient; While dynamically regulating the traffic, adaptive matching is performed according to the carrying capacity of the test environment to determine the transaction traffic that is ultimately copied to the test environment. The specific determination expression is: ,in, To finally copy the transaction flow to the test environment, is the load capacity adjustment coefficient, which is used for load balance adjustment and has a value range of , is the system load utilization of the current test environment, The maximum load bearing capacity of the test environment.

2. The method for building an automated testing platform based on a financial risk system according to claim 1, characterized in that: Collect various data indicators related to transaction load through point monitoring, log analysis or third-party monitoring tools.

3. The method for building an automated testing platform based on a financial risk system according to claim 1, characterized in that: Feature engineering is used to select features related to high-concurrency transaction scenarios from massive indicators, and the selected features are used as feature vectors. The specific process is as follows: The total waiting time caused by lock contention when threads execute tasks and the frequency of conflicts among concurrent transactions are extracted from various data indicators related to transaction load. The extracted indicators are deeply analyzed within the monitoring window through feature engineering methods, and thread contention quantification values ​​and transaction conflict quantification values ​​are generated respectively. They are used as feature vectors to characterize the load level of the system within the current monitoring window, which are further used for the identification and prediction of high-concurrency transaction scenarios.

4. The method for building an automated testing platform based on a financial risk system according to claim 3, characterized in that: Within the monitoring window, the feature vector thread contention quantization value and transaction conflict quantization value are input in real time into the pre-trained machine learning model to generate a transaction concurrency coefficient. The transaction concurrency coefficient is used to predict the concurrent transactions of the financial risk management system, identify high concurrency risks, and predict the potential peak of transaction load.

5. The method for building an automated testing platform based on a financial risk system according to claim 3, characterized in that: In the monitoring window, the specific steps of generating thread contention quantification values ​​by in-depth analysis of the total waiting time caused by lock contention when the extracted threads are executing tasks through feature engineering are as follows: In the current monitoring window, the impact weight of the system thread during the lock contention process is first calculated to comprehensively evaluate the impact of the system thread under the lock contention condition. The calculation logic of the thread lock waiting time weight is as follows: ,in: is the thread lock waiting time weight, Indicates i The lock waiting time of each thread represents the total blocking time of the thread when competing for resources. Indicates i The resource priority weight of a thread, ranging from between, Indicates i The number of times a thread successfully acquires a lock in the current monitoring window measures the success rate of threads in competing for resources. Indicates i The total task execution time of each thread reflects the task processing capability of the thread in the current monitoring window. The minimum value introduced to prevent the denominator from being zero, N The total number of active threads in the current monitoring window, reflecting the concurrent scale of the system; After obtaining the thread lock waiting time weight, it is normalized to represent the overall load level of the system in the current monitoring window. The calculation logic of the thread contention quantization value is as follows: ,in: It is the thread contention quantification value, which is used to quantify the concurrency pressure level of the current system. is the Gamma function, which measures the complexity of system lock contention, where As a tuning parameter, it represents the nesting degree of resource locks and the complexity of concurrent processing. The maximum lock contention threshold of the system, used for standardization, represents the maximum thread contention level that the system can withstand under the current hardware and software configuration.

6. The method for building an automated testing platform based on a financial risk system according to claim 3, characterized in that: In the monitoring window, the specific steps for generating transaction conflict quantification values ​​by in-depth analysis of the frequency of concurrent transaction conflicts through feature engineering are as follows: First, in the monitoring window, extract the relevant data of concurrent transactions in the system in real time, calculate the number of conflicts for each transaction, and generate a preliminary conflict frequency index based on the frequency of conflicts. Use the following formula to calculate the frequency of transaction conflicts: ,in, Indicates the transaction conflict frequency within the current monitoring window. Is the indicator function, when the transaction In Resources R If a conflict occurs, the value is 1, otherwise it is 0. is the number of active transactions in the monitoring window, Indicates u The index of a transaction, which is a single database operation or transaction being executed in the system. p Indicates the total number of active transactions in the current monitoring window; After completing the calculation of the transaction conflict frequency, it is further mapped to the transaction conflict quantification value and calculated using the following formula. The specific calculation expression is: ,in, Indicates the transaction conflict quantification value, Every transaction The weighting factor of the conflict on the system load, It is the overall system load factor for the current monitoring window, used to adjust the impact of conflict frequency under high load conditions.

7. The method for building an automated testing platform based on a financial risk system according to claim 4, characterized in that: The transaction concurrency prediction coefficient generated when the transaction situation of the financial risk management system is predicted by the pre-trained machine learning model in the monitoring window is compared and analyzed with the pre-set transaction concurrency prediction coefficient reference threshold, and the system state is dynamically divided into two stages. The specific division steps are as follows: If the transaction concurrency prediction coefficient is greater than the transaction concurrency prediction coefficient reference threshold, the state of the system is dynamically divided into a high concurrent transaction load stage; If the transaction concurrency prediction coefficient is less than or equal to the transaction concurrency prediction coefficient reference threshold, the state of the system is dynamically divided into the normal transaction stage.

8. An automated testing platform based on a financial risk system, used to implement the method for building an automated testing platform based on a financial risk system as described in any one of claims 1 to 7, characterized in that: It includes automated test script writing module, real-time transaction monitoring module, data preprocessing module, high-concurrency feature extraction and prediction module, dynamic state division module, and traffic mirroring and load regulation module; Automated test script writing module, which writes a series of automated test scripts covering core business logic, performance bottlenecks and security mechanisms for the financial risk management system; Real-time transaction monitoring module, which monitors the system's operating status in real time while executing the test script and obtains various data indicators related to the transaction load; The data preprocessing module preprocesses the transaction load data collected by monitoring to ensure the quality and consistency of the input data; The high-concurrency feature extraction and prediction module, after preprocessing, uses feature engineering to select features related to high-concurrency transaction scenarios from massive indicators, and uses the selected features as feature vectors to represent the system load level in the current monitoring window. After the feature engineering is completed, the feature vectors are input into the pre-trained machine learning model in real time for prediction, identifying high-concurrency risks and predicting the potential peak of transaction load; The dynamic state division module dynamically divides the system state into two stages according to the prediction results given by the machine learning model: the normal transaction stage and the high concurrent transaction load stage; The traffic mirroring and load regulation module, once it detects that the system transaction situation has entered the high concurrent transaction load stage, dynamically simulates the concurrent pressure through traffic mirroring replication in the production environment, and dynamically regulates the amount of data copied to the test environment according to the concurrent situation.

Images