Banking system test data coverage processing method and device and electronic equipment

Abstract

The application discloses a bank business system test data coverage processing method and device and electronic equipment, and relates to the field of financial science and technology automation testing. The method comprises the following steps: acquiring production data and test data from a production data source and a test data source of a bank business system respectively, and performing feature extraction on the production data and the test data respectively to obtain a production feature vector and a test feature vector; determining a test weight of the test data based on a business logic importance weight, a risk exposure weight and a cost efficiency weight; and determining a coverage relationship of the test data to the production data based on the test weight of the test data, the test feature vector and the production feature vector. The above technical solution improves the efficiency and accuracy of determining the test data coverage relationship.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to the field of automated testing in financial technology, specifically to a method, apparatus, and electronic device for processing test data coverage of a banking business system. Background Technology

[0002] Testing of banking systems typically relies on manually constructed test cases and simulated datasets. However, such test data often fails to fully cover the complex and ever-changing transaction scenarios in real production environments, leading to potential risks (such as high-risk transaction vulnerabilities and abnormal behavior of specific user groups) being overlooked during the testing phase, which affects the stability and security of the system after it goes live.

[0003] The data in banking systems has the following characteristics: First, the production data is massive, covering a vast amount of customer transactions, accounts, and interaction records, typically reaching TB or even PB levels. Second, the data structure is complex, with high-dimensional data models and strong interrelationships across multiple tables and systems, including various types of fields such as numerical, categorical, identifier, time-series, and text fields. Third, it is highly sensitive to customer data, directly linked to personal privacy and financial assets, and subject to strict regulation by financial industry data security standards, necessitating extremely high requirements for data security and privacy protection. Therefore, determining the comprehensiveness of the coverage of production data by test data in banking systems has become a critical issue that urgently needs to be addressed within the industry. Summary of the Invention

[0004] This application provides a method, apparatus, and electronic device for processing test data coverage in a banking business system, in order to improve the efficiency and accuracy of determining test data coverage relationships.

[0005] In a first aspect, embodiments of this application provide a method for overlaying test data in a banking business system, including:

[0006] Production data and test data are obtained from the production data source and test data source of the banking business system, respectively, and feature extraction is performed on the production data and test data to obtain production feature vectors and test feature vectors.

[0007] The test weights of the test data are determined based on the importance weight of business logic, the risk exposure weight, and the cost efficiency weight.

[0008] Based on the test weights of the test data, the test feature vectors, and the production feature vectors, the coverage relationship between the test data and the production data is determined.

[0009] Secondly, embodiments of this application also provide a banking business system test data coverage processing apparatus, including:

[0010] The data feature extraction module is used to obtain production data and test data from the production data source and test data source of the banking business system, respectively, and to extract features from the production data and test data to obtain production feature vectors and test feature vectors.

[0011] The test weighting module is used to determine the test weights of test data based on the importance weight of business logic, the risk exposure weight, and the cost efficiency weight.

[0012] The coverage relationship determination module is used to determine the coverage relationship between the test data and the production data based on the test weights of the test data, the test feature vectors, and the production feature vectors.

[0013] Thirdly, embodiments of this application also provide an electronic device, which includes:

[0014] One or more processors;

[0015] Storage device for storing one or more programs;

[0016] When one or more programs are executed by one or more processors, the one or more processors implement any of the banking business system test data coverage processing methods provided in the embodiments of this application.

[0017] Fourthly, embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements any of the banking business system test data coverage processing methods provided in embodiments of this application.

[0018] The technical solution of this application extracts production data and test data from the banking business system, and obtains corresponding production feature vectors and test feature vectors through feature extraction. It then determines the business logic importance weight, risk exposure weight, and cost efficiency weight of the test data, and merges them to form a comprehensive test weight. Addressing the difficulty of achieving refined resource allocation using traditional fixed weights or simple business weighting methods, this solution proposes a three-layer weight architecture, which is resolved by quantifying the "risk value density" and "coverage cost coefficient" of feature combinations. Based on the comprehensive test weight, test feature vector, and production feature vector, the coverage relationship between test data and production data is determined. Subsequently, the test data can be dynamically optimized based on this coverage relationship, providing a quantitative basis for testing the banking business system and thus improving system stability. Attached Figure Description

[0019] Figure 1 This is a flowchart of a test data coverage processing method for a banking business system according to Embodiment 1 of this application;

[0020] Figure 2This is a flowchart of another method for processing test data coverage in a banking business system according to Embodiment 2 of this application;

[0021] Figure 3 This is a flowchart of another method for processing test data coverage in a banking business system according to Embodiment 3 of this application;

[0022] Figure 4 This is a schematic diagram of the structure of a test data overlay processing device for a banking business system according to Embodiment 4 of this application;

[0023] Figure 5 This is a schematic diagram of the structure of an electronic device that implements the banking business system test data overlay processing method according to the embodiments of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first" and "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] Example 1

[0027] Figure 1 This is a flowchart of a method for processing test data coverage of a banking business system according to Embodiment 1 of this application. This embodiment is applicable to situations where test data of a banking business system is dynamically adjusted. It can be executed by a banking business system test data coverage processing device, which can be implemented in hardware and / or software and can be configured in a blockchain node. Figure 1 As shown, the method includes:

[0028] S101. Obtain production data and test data from the production data source and test data source of the banking business system respectively, and extract features from the production data and test data respectively to obtain production feature vector and test feature vector.

[0029] S102. Determine the test weights for test data based on the importance weight of business logic, the risk exposure weight, and the cost efficiency weight.

[0030] S103. Based on the test weights of the test data, the test feature vectors, and the production feature vectors, determine the coverage relationship between the test data and the production data.

[0031] Production data sources may include core transaction systems, credit systems, and customer relationship management systems, while test data sources may include test management systems, historical test execution records, and simulation environment data. Metadata such as business dictionary tables, transaction code tables, and product catalogs must be included to aid in feature construction and data understanding. Data acquisition must adhere to strict standards: production data is extracted through an internal secure data exchange platform or dedicated pipelines, with access permissions based on role control and following the "least privilege" principle; all operations are logged. Test data is extracted from historical test records or simulation environments, ensuring compliance with data minimization requirements; metadata directly references existing files in the business systems. Data transmission uses transport layer security protocols for encryption, and the transmission of sensitive or linkable information without encryption is prohibited.

[0032] Production data and test data share the same feature set, meaning they use the same feature dimensions. These can include at least one of the following features: transaction type code, transaction amount range, timestamp, channel identifier, product code, anonymized customer category, transaction type, transaction amount, time distribution, or operation frequency. Note that a single piece of production data may contain only some feature dimensions, and a single piece of test data may also contain only some feature dimensions; the feature dimensions in production data are called production feature dimensions, and the feature dimensions in test data are called test feature dimensions.

[0033] When optimizing test data, it is necessary to focus on key feature dimensions such as transaction type coding, transaction amount range, timestamp, channel identifier, and anonymized customer category. Simultaneously, sensitive information (such as names, ID card numbers, complete bank card numbers, and other personal identification information) in production and test data should be anonymized to ensure that the anonymized data retains the statistical features and relationships required for business analysis. Specific anonymization methods are as follows: 1) Dynamic data anonymization: Sensitive fields are processed in real-time during data extraction. For example, bank card numbers retain the identification code and the last four digits and are masked; ID card numbers retain the birth date range and the last four digits or are replaced with compliant fake data; names are replaced with randomly generated values ​​or generic pseudonyms; and contact information is replaced with fake format data. 2) Static data anonymization: Intermediate datasets are irreversibly processed before storage, using techniques such as pseudonymization, generalization, and replacement. 3) Synthetic data production: Simulation datasets are generated based on the production data distribution, and privacy leakage risks are eliminated through statistical modeling. Both production and test data must be labeled with their source (e.g., anonymized production samples, historical test data, synthetic data) and anonymization type. To enhance data security, production and test data are stored in a dedicated storage area within the bank's security domain, and environmental isolation is implemented: the production data sample processing environment is physically / logically isolated from the actual production environment, and the evaluation computing environment is separated from the development and testing environments; static data is protected using strong encryption algorithms. The information collected in this application is authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0034] In the feature extraction stage, different types of data are processed specifically to meet computational needs. For timestamps, binning is used to divide continuous timestamps into discrete time periods, and normalization is performed to obtain time distribution features. For numerical data such as transaction amounts, normalization or standardization is required during vectorization to eliminate scale differences. Normalization is used to map numerical fields to the [0,1] interval. The normalization formula is as follows:

[0035] Xnorm=(X-min(X)) / (max(X)-min(X))

[0036] Where X represents the original data, min(X) and max(X) are the minimum and maximum values ​​of the field, respectively; Xnorm is the normalization result. Standardization is used to transform a numerical field into a distribution with a mean of 0 and a standard deviation of 1. The standardization formula is as follows:

[0037] Xstd=(X-μ) / σ

[0038] Where μ is the mean and σ is the standard deviation. After processing, the numerical data can be directly used as part of a vector for calculation.

[0039] For category data such as transaction type and customer category tags, one-hot encoding can be used to convert each category into an independent binary bit (0 or 1). For example, if "transaction type" includes three types: transfer, deposit, and withdrawal, the one-hot encoding is represented as: transfer: [1,0,0], deposit: [0,1,0], withdrawal: [0,0,1]. Identifier data such as channel identifiers and product codes cannot be directly used in calculations, but can be converted into numerical vectors through hash encoding or unique identifier mapping. For example, a hash operation is performed on identifier data such as channel identifiers and product codes to produce a fixed-length hash value; the hash value is converted into a numerical type and normalized to finally form a feature vector representation. Through the above feature extraction, while meeting privacy protection requirements, the generated feature vector and test feature vector have computability with a definite coverage relationship.

[0040] Furthermore, the business logic importance weight, risk exposure weight, and cost efficiency weight of the test data are determined separately, and these three are then combined (e.g., summed) to obtain a comprehensive test weight. The business logic importance weight reflects the business value represented by the test data; for example, private banking customer data or large-value transaction settlement data, due to their significant impact on banking operations, will be assigned a higher weight. The risk exposure weight characterizes the risk level involved in the test data, including two scenarios: first, high-risk businesses (such as fast payment data with extremely high daily transaction volume); and second, historical data that has caused problems in the production environment (such as some zero-customer data generated due to special reasons), which requires additional weighting. The cost efficiency weight measures the cost of preparing the test data; a higher weight indicates a lower data preparation cost. By comprehensively evaluating business value, risk coverage, and data cost, the extracted test data can prioritize coverage of high-risk, high-business-value scenarios at a lower cost. In practice, test data with higher weights not only have an advantage in feature similarity comparisons but also achieve more effective test coverage at a lower cost.

[0041] After determining the comprehensive test weights, they need to be combined with the test feature vectors of the test data. For example, multiplying the test weights by the test feature vectors yields a corrected test feature vector; this corrected vector is then compared with the production feature vectors, and the coverage relationship between the test data and the production data is determined based on the comparison results. The core contradiction in bank testing lies in the conflict between the need for comprehensive coverage of massive high-dimensional production data and the high costs of data extraction and de-identification, as well as test execution resources. Fixed weights or simple business weighting methods in related technologies cannot achieve refined resource allocation. This application's embodiment uses a three-layer weight architecture to quantify the "risk value density" and "coverage cost coefficient" of feature combinations. Subsequently, test data can be dynamically optimized based on the coverage relationship, providing a quantitative basis for banking business system testing, thereby improving the stability of banking business systems.

[0042] The technical solution of this embodiment extracts production data and test data from the banking business system, and obtains corresponding production feature vectors and test feature vectors through feature extraction. It then determines the business logic importance weight, risk exposure weight, and cost efficiency weight of the test data, and merges them to form a comprehensive test weight. Addressing the difficulty of achieving refined resource allocation using traditional fixed weights or simple business weighting methods, this solution proposes a three-layer weight architecture, which is solved by quantifying the "risk value density" and "coverage cost coefficient" of feature combinations. Based on the comprehensive test weight, test feature vector, and production feature vector, the coverage relationship between test data and production data is determined. Subsequently, the test data can be dynamically optimized based on the coverage relationship, providing a quantitative basis for testing the banking business system and thus improving system stability.

[0043] Example 2

[0044] Figure 2 This is a flowchart of another method for processing test data coverage in a banking business system according to Embodiment 2 of this application. The technical solution of this embodiment further refines the dynamic weights of the test data based on the above technical solution. See also... Figure 2 The method for handling test data coverage in a banking business system, as shown, includes:

[0045] S201. Obtain production data and test data from the production data source and test data source of the banking business system respectively, and extract features from the production data and test data respectively to obtain production feature vector and test feature vector.

[0046] S202. Based on each test feature dimension in the test data and the pre-sorting of the importance of each key feature dimension, determine the business logic importance weight of the test data.

[0047] S203. Determine the risk exposure weight of the test data based on the transaction type and historical issue information to which the test data belongs;

[0048] S204. Determine the cost-efficiency weight of the test data based on at least one of the following: the type of de-identification of the test data, the extraction complexity, or the storage overhead.

[0049] S205. Determine the test weight of the test data based on the business logic importance weight, risk exposure weight, and cost efficiency weight of the test data;

[0050] S206. Based on the test weights of the test data, the test feature vectors, and the production feature vectors, determine the coverage relationship between the test data and the production data.

[0051] The process involves pre-acquiring key feature dimensions tagged from various feature dimensions in production and test data, ranking these dimensions by importance, and determining the value weight of each key feature dimension in the business by comparing their relative importance (e.g., cross-border transfers are more important than large transactions, large transactions are more important than private banking clients). This ensures the weight distribution reflects the varying impacts of different features on business value in real-world scenarios. For any given test data point, the key feature dimensions it contains are acquired, and the pre-determined weights corresponding to these key feature dimensions are summed to obtain the business logic importance weight of that test data.

[0052] The system can match the transaction type of the test data with preset transaction type association information to determine the risk level corresponding to that transaction type (e.g., quick payment protocol data is set to high risk level 3 due to large transaction volume, and the combination of cross-border transfer and large transaction is also set to high risk level 3); and retrieve the impact level of historical issues from the historical issue database based on the transaction type (e.g., when this type of transaction had fewer issues historically, it was set to medium risk level 2). The system calculates the median value by weighting and summing the transaction type risk level and the historical issue impact level using preset coefficients (e.g., 0.6 and 0.4); this median value is then combined with a preset index coefficient (e.g., k = 0.5) to calculate the risk exposure weight using an index formula (e.g., if the median value is 2.2, when k = 0.5, the risk exposure weight is approximately 3.0).

[0053] Cost efficiency weights are determined by three cost factors: the type of data anonymization, extraction complexity, and storage overhead. Lower data preparation costs result in higher cost efficiency weights. Specifically, the type of data anonymization directly impacts data availability costs. Anonymization costs for synthetic data are lower than for dynamic data, thus synthetic data production has higher anonymization costs. If the test data is already anonymized (e.g., private bank customer information), the anonymization cost is low, resulting in a higher weight. Regarding extraction complexity, the more systems or data sources the test data needs to be associated with, the higher the extraction cost. For example, if the test data needs to be associated with cross-border transfer system logs, the extraction complexity is "medium," and the cost is moderate. If extraction is required across multiple heterogeneous systems, the complexity is "high," and the cost efficiency weight decreases. Regarding storage overhead, the smaller the data storage requirement for a single test record (e.g., only containing core fields such as transaction time and amount), the lower the storage cost and the higher the weight. If storing complete logs or large attachments is required, the storage overhead is "high," and the weight decreases. By using pre-defined scoring rules (e.g., low anonymization cost scores 3 points, medium cost 2 points, high cost 1 point; low extraction complexity scores 3 points, medium cost 2 points, high cost 1 point; low storage overhead scores 3 points, medium cost 2 points, high cost 1 point), the three scores are weighted and summed, and finally normalized to obtain the cost efficiency weight. By quantifying the costs of anonymization type, extraction complexity, and storage overhead, accurate calculation of the cost efficiency weight is achieved, providing a cost-oriented optimization basis for test resource allocation. By quantifying the importance of key feature dimensions, the impact of transaction type risks and historical issues, and anonymization type costs, the importance of business logic, risk exposure, and cost efficiency weights are determined respectively, ensuring that weight allocation aligns with actual business value, dynamically and accurately assesses risks, and optimizes test resource allocation.

[0054] In one optional implementation, determining the business logic importance weight of the test data based on each test feature dimension in the test data and the pre-ranking of the importance of each key feature dimension includes: constructing a judgment matrix based on the pre-ranking of the importance of each key feature dimension; solving the eigenvalues ​​of the judgment matrix using the analytic hierarchy process to obtain the initial weights of the key feature dimensions; normalizing the initial weights of the key feature dimensions to obtain the final weights of the key feature dimensions; and determining the business logic importance weight of the test data based on each test feature dimension in the test data and the final weights of the key feature dimensions.

[0055] For example, key feature dimensions marked from various feature dimensions included in production data and test data are pre-acquired, and their importance is ranked. Based on this ranking, a judgment matrix is ​​constructed by comparing the relative importance of each feature pairwise. Taking the key feature dimensions as follows—cross-border transfers, large transactions, private banking clients, and channel identifiers—with their importance ranking decreasing in that order, the judgment matrix is ​​as follows:

[0056] Key feature dimensions Cross-border transfer Large transactions Private banking clients Channel identification Cross-border transfer 1 3 5 7 Large transactions 1 / 3 1 3 5 Private banking clients 1 / 5 1 / 3 1 3 Channel identification 1 / 7 1 / 5 1 / 3 1

[0057] The eigenvalues ​​of the judgment matrix are solved using the analytic hierarchy process (AHP) to obtain the initial weights of each key feature dimension. These initial weights are then normalized to obtain the final weights. Using the table above as an example, the final weights for cross-border transfers, large transactions, private banking clients, and channel identifiers are 0.5, 0.3, 0.15, and 0.05, respectively. For any given test data, the key feature dimensions included in the test data are obtained, and the final weights of the corresponding key feature dimensions are summed to obtain the business logic importance weight of the test data. If a test data point involves cross-border transfers, large transactions, and private banking clients, but not channel identifiers, its business logic importance weight is 0.5 + 0.3 + 0.15 = 0.95.

[0058] By constructing a judgment matrix by comparing the relative importance of different key feature dimensions, qualitative judgments are transformed into quantitative values, effectively reducing subjective bias. By solving the eigenvalues ​​of the judgment matrix and normalizing them, the final weights of each key feature dimension are obtained, ensuring that the weight distribution strictly conforms to the differences in the impact of features on business value in actual business scenarios. For any test data, its importance in business logic can be quantified simply by accumulating the weights corresponding to the key feature dimensions it contains.

[0059] In one optional implementation, determining the risk exposure weight of the test data based on the transaction type to which the test data belongs and historical issue information includes: obtaining the transaction volume level corresponding to the transaction type to which the test data belongs; obtaining the frequency of historically triggered issues from a historical issue database based on the transaction type; determining the risk factor of the test data based on the transaction type, the transaction volume level, and the issue frequency; and determining the risk exposure weight of the test data based on the risk factor and a preset risk coefficient.

[0060] For any given test data, its transaction type is matched with a preset transaction type-transaction volume level association to determine the corresponding transaction volume level. Then, based on the transaction type and transaction volume level, the transaction risk level (TrxRiskLevel) is determined. Simultaneously, according to the transaction type of the test data, the frequency of problems caused by this transaction type in historical transactions is obtained from the historical problem database to determine the historical problem risk level (ProductBugLevel). The transaction risk level and the historical problem risk level are then weighted using preset coefficients (e.g., 0.6, 0.4) to calculate the risk factor (Risk), using the following formula:

[0061] Risk=0.6×TrxRiskLevel+0.4×ProductBugLevel

[0062] Among them, TrxRiskLevel reflects the risk level of the transaction itself (e.g., data from quick payment protocols is set to high-risk level 3 due to its large daily transaction volume; cross-border transfers combined with large transactions are also set to high-risk level 3), and ProductBugLevel reflects the impact level of historical issues (e.g., historically, this type of transaction issue has had low frequency, so it is set to medium-risk level 2). The risk factors are combined with preset index coefficients (e.g., k = 0.5) to calculate the risk exposure weight using a formula:

[0063] Wrisk = e k×Risk

[0064] Here, Wrisk represents the risk exposure weight. For example, if the risk factor of a certain test data is 2.2, then when k = 0.5, its risk exposure weight is 3.0. By quantifying the risk level of trading characteristics and the impact of historical issues, the risk exposure weight is dynamically calculated, avoiding the uncertainty of subjective assignment and improving the accuracy of risk assessment.

[0065] In addition, dynamic feedback and iterative optimization can be implemented for the weights of test data. During test execution, the actual coverage of each feature combination is recorded in real time through a real-time monitor; when the coverage of a high-risk feature combination reaches a preset threshold, its risk exposure weight is automatically reduced, and resources are released to other uncovered combinations; the cost of data preparation is reassessed periodically (such as when a new system goes live and the data source changes); and the prediction accuracy is enhanced by learning the correlation between risk events and uncovered features through closed-loop learning.

[0066] The technical solution in this embodiment determines the importance of business logic, risk exposure, and cost efficiency weights by quantifying the importance of key feature dimensions, the impact of transaction type risks and historical issues, and cost factors such as anonymization types. This ensures that the weight allocation is consistent with the actual business value, dynamically and accurately assesses risks, and optimizes the allocation of test resources.

[0067] Example 3

[0068] Figure 3 This is a flowchart of another method for processing test data coverage in a banking business system according to Embodiment 3 of this application. The technical solution of this embodiment is further refined based on the above technical solution. See also Figure 3 The method for handling test data coverage in a banking business system, as shown, includes:

[0069] S301. Obtain production data and test data from the production data source and test data source of the banking business system respectively, and extract features from the production data and test data respectively to obtain production feature vector and test feature vector.

[0070] S302. Determine the test weights for test data based on the importance weight of business logic, the risk exposure weight, and the cost efficiency weight.

[0071] S303. Based on the test weights of the test data, the test feature vectors, and the production feature vectors, determine the coverage relationship between the test data and the production data;

[0072] S304. Based on the coverage relationship between the test data and the production data, determine the areas with insufficient coverage; the areas with insufficient coverage are used to characterize the fact that the test data failed to effectively cover the transaction patterns or feature dimension combinations in the production data;

[0073] S305. Determine the service security level corresponding to the insufficient coverage area;

[0074] S306. Based on the aforementioned business security level, supplement the insufficient coverage area with test data.

[0075] For each test data point, its test weight is multiplied by the corresponding test feature vector to obtain a corrected test feature vector. The feature matching degree between the corrected test feature vector and the production feature vector of the production data is calculated. A matching degree threshold (e.g., 0.8) is preset. If the feature matching degree reaches or exceeds the preset matching degree threshold, the test data is marked as covering the corresponding production data; otherwise, it is marked as not covering. By traversing all combinations of test data and production data, marking records of covering relationships are generated, and the proportion of covered records to the total number of records is counted to determine the covering relationship between the test data and the production data.

[0076] Based on the coverage relationship between test data and production data, areas with insufficient coverage are identified. These areas characterize the failure of test data to effectively cover transaction patterns or feature dimension combinations in the production data. By obtaining test feature vectors with feature matching degrees below a threshold and extracting the corresponding transaction patterns and feature dimension combinations from the test data, specific areas with insufficient test data coverage (such as high-risk transaction types, transaction patterns of specific user groups, or transaction patterns within specific time periods) are identified. Based on the coverage and similarity matrix, optimization suggestions can be provided to the testing team to help adjust and expand the test dataset.

[0077] Determine the business security level corresponding to the under-covered areas. The business security level can include both data sensitivity and business frequency, and can be classified as non-sensitive low-frequency business or sensitive high-frequency business. Non-sensitive low-frequency business or sensitive high-frequency business must simultaneously meet the following conditions: the partition data does not contain direct identifiers (ID card, account number), and the business frequency is lower than the risk control threshold (e.g., less common transaction types with fewer than 100 transactions per month). Samples can be copied from the anonymized test dataset in the same partition.

[0078] Determine the business security level corresponding to the insufficiently covered areas. This level is determined based on data sensitivity and business frequency, and can include non-sensitive low-frequency businesses and sensitive high-frequency businesses. Non-sensitive low-frequency businesses' partitioned data do not contain direct identifiers (such as ID cards or account numbers), and the business frequency is lower than the risk control threshold (e.g., less frequent transactions less than 100 per month). The conditions for sensitive high-frequency businesses can be defined according to actual business scenarios, such as critical business scenarios involving payment clearing, regulatory reporting, etc., which require high-frequency transaction recording. These scenarios typically contain sensitive data and the transaction frequency is higher than the risk control threshold. For insufficiently covered areas and non-sensitive low-frequency businesses, samples can be copied from the de-identified test dataset in the same partition to supplement the test data. By quantifying the feature matching degree between the test data and production data and setting thresholds, the coverage relationship is accurately marked, thereby locating the production data areas not effectively covered by the test data. Combining the business security level classification of insufficiently covered areas, a supplementary strategy is clarified to improve the comprehensiveness and relevance of the test dataset, ensuring effective coverage and security verification of key business scenarios.

[0079] In one optional implementation, determining the coverage relationship between the test data and the production data based on the test weights, the test feature vectors, and the production feature vectors of the test data includes: for the i-th test data and the j-th production data, multiplying the test weight of the i-th test data by the test feature vector of the i-th test data to obtain the i-th corrected test feature vector; calculating the cosine similarity between the i-th corrected test feature vector and the production feature vector of the j-th production data; and generating a cosine similarity matrix; wherein, in the cosine similarity matrix, the i-th row... The element in the j-th column is the cosine similarity between the i-th modified test feature vector and the j-th production feature vector of the production data. Each element in the cosine similarity matrix is ​​traversed, and the element is compared with a preset similarity threshold. A coverage relation matrix is ​​generated based on the comparison results. If the element in the i-th row and j-th column of the cosine similarity matrix is ​​equal to or greater than the preset similarity threshold, then the element in the i-th row and j-th column of the coverage relation matrix is ​​assigned a first value; otherwise, it is assigned a second value. The number of elements in the coverage relation matrix with the first value is counted to obtain the coverage rate of the test data over the production data.

[0080] For example, the test feature vectors corresponding to the test data are organized into a test data matrix by rows (or columns), where each row represents a test data point and each column corresponds to a feature dimension; and the production feature vectors corresponding to the production data are organized into a production data matrix by rows (or columns), where each row represents a data point and each column corresponds to a feature dimension. For the i-th test data point and the j-th production data point, the test weight of the i-th test data point is multiplied by the test feature vector of the i-th test data point to obtain the i-th corrected test feature vector; the cosine similarity between the i-th corrected test feature vector and the production feature vector of the j-th production data point is calculated. By calculating the cosine similarity between each pair of test data and production data, an n×m similarity matrix is ​​obtained, where n is the number of rows in the test data point, n is the number of rows in the production data point, and S ij The value represents the similarity between the i-th test data and the j-th production data, where i and j are natural numbers.

[0081] A pre-set similarity threshold (e.g., 0.8) is used. If the cosine similarity between the test data and the production data is greater than or equal to the similarity threshold, the test data "covers" the production data; otherwise, it is not covered. Each element in the similarity matrix is ​​iterated over, and if the element value is greater than or equal to the similarity threshold, the element at the corresponding position in the coverage matrix is ​​assigned the first value (e.g., 1); otherwise, the element at the corresponding position is assigned the second value (e.g., 0). The number of elements with the first value in the coverage matrix is ​​counted, and divided by the total number of elements in the coverage matrix to obtain the coverage rate of the test data over the production data. A structured test data matrix and a production data matrix are constructed. The test weights of the test data are multiplied by the corresponding test feature vectors to obtain the corrected test feature vectors. The cosine similarity between the corrected test feature vectors and the production feature vectors is calculated to quantify the feature matching degree, and a similarity threshold is set to generate the coverage matrix. The proportion of the number of elements with the first value in the coverage matrix is ​​counted to obtain the coverage rate. This process effectively improves the accuracy and reliability of coverage rate calculation.

[0082] For each test data point, its test weight is multiplied by the corresponding test feature vector to obtain a corrected test feature vector. The cosine similarity between this corrected vector and the production feature vector of each production data point is calculated to quantify the degree of feature matching. A uniform similarity threshold (e.g., 0.8) is set; if the similarity is ≥ the threshold, it is marked as covered (corresponding position is recorded as 1); otherwise, it is not covered (recorded as 0), generating a coverage relationship matrix. Finally, the proportion of 1s in the coverage relationship matrix to the total number of elements is counted to obtain the coverage rate. These steps effectively improve the accuracy and reliability of coverage rate calculation.

[0083] To adapt to different testing needs, the similarity threshold can be dynamically adjusted. If the current coverage is low, the similarity threshold can be lowered to allow more test data to be considered to cover production data. Conversely, if higher coverage is required, the similarity threshold can be increased to strictly filter coverage relationships.

[0084] In one optional implementation, supplementing the insufficiently covered area with test data according to the business security level includes: if the business security level is a sensitive high-frequency business, then filtering raw production data including the corresponding feature dimension from the production data source according to the test feature dimension corresponding to the insufficiently covered area; de-identifying the actual account identifier in the raw production data through a de-identification engine; and replacing the account identifier in the de-identified production data with a virtual account identifier pre-allocated in the test environment to obtain supplementary test data.

[0085] For high-frequency businesses with insufficient coverage and high sensitivity, the feature dimension combinations (such as transaction type, user group characteristics, etc.) corresponding to the insufficient coverage areas are obtained. Through the query interface or database query statement of the production data source, the original production data containing the corresponding attributes is filtered according to the feature dimension combinations. A de-identification engine is used to de-identify the filtered original data. For example, sensitive information (such as name, ID number, complete bank card number, etc.) in the actual production data is irreversibly de-identified using rules or algorithms (such as hashing, encryption, replacement), ensuring that sensitive information cannot be restored. After de-identification, a mapping relationship is established between the de-identified account identifier and the pre-assigned virtual account identifier, and the account field in the original data is replaced with the virtual identifier, generating supplementary test data that meets the requirements of the test environment. By accurately locating insufficient coverage areas, classifying and de-identifying production data according to business security levels, and generating supplementary test data with virtual account identifiers, the comprehensiveness and relevance of the test dataset are improved while ensuring data security, ensuring effective verification of key business scenarios.

[0086] The technical solution in this embodiment quantifies the feature matching degree between test data and production data and sets a threshold to accurately locate production data areas not covered by test data. Combined with business security level classification processing, it filters, de-identifies, and replaces account identifiers to generate supplementary test data for sensitive and high-frequency businesses from production data sources. While ensuring data security, it improves the comprehensiveness and relevance of the test dataset, ensuring effective coverage and verification of key business scenarios.

[0087] Example 4

[0088] Figure 4This is a schematic diagram of a test data overlay processing device for a banking business system according to Embodiment 4 of this application. This embodiment is applicable to situations where test data for a banking business system is dynamically adjusted. The test data overlay processing device can be implemented in hardware and / or software, and can be configured in a blockchain node. (Reference) Figure 4 The specific structure of the test data coverage processing device 400 of the banking business system is as follows:

[0089] The data feature extraction module 410 is used to obtain production data and test data from the production data source and test data source of the banking business system respectively, and to extract features from the production data and test data respectively to obtain production feature vector and test feature vector.

[0090] The test weight module 420 is used to determine the test weight of test data based on the importance weight of business logic, the risk exposure weight, and the cost efficiency weight.

[0091] The coverage relationship determination module 430 is used to determine the coverage relationship between the test data and the production data based on the test weight of the test data, the test feature vector, and the production feature vector.

[0092] In one alternative implementation, the test weighting module 420 includes:

[0093] The business weight unit is used to determine the business logic importance weight of the test data based on each test feature dimension in the test data and the pre-sorting of the importance of each key feature dimension.

[0094] The risk weighting unit is used to determine the risk exposure weight of the test data based on the transaction type and historical issue information to which the test data belongs;

[0095] The cost weighting unit is used to determine the cost efficiency weight of the test data based on at least one of the following: the anonymization type of the test data, the extraction complexity, or the storage overhead.

[0096] The test weighting unit is used to determine the test weight of the test data based on the business logic importance weight, risk exposure weight, and cost efficiency weight of the test data.

[0097] In one optional implementation, the business weighting unit is specifically used for:

[0098] A judgment matrix is ​​constructed based on the pre-sorting of the importance of each key feature dimension.

[0099] The eigenvalues ​​of the judgment matrix are solved using the analytic hierarchy process (AHP) to obtain the initial weights of the key feature dimensions.

[0100] The initial weights of the key feature dimensions are normalized to obtain the final weights of the key feature dimensions.

[0101] The business logic importance weight of the test data is determined based on each test feature dimension in the test data and the final weight of the key feature dimension.

[0102] In one optional implementation, the risk weighting unit is specifically used for:

[0103] Based on the transaction type of the test data, obtain the transaction volume level corresponding to that transaction type;

[0104] Based on the transaction type, retrieve the frequency of historically triggered issues from the historical issue database;

[0105] The risk factors of the test data are determined based on the transaction type, the transaction volume level, and the frequency of the problem.

[0106] The risk exposure weight of the test data is determined based on the risk factors and preset risk coefficients.

[0107] In one optional implementation, the coverage relationship determination module 430 is specifically used for:

[0108] For the i-th test data and the j-th production data, the test weight of the i-th test data is multiplied by the test feature vector of the i-th test data to obtain the i-th corrected test feature vector;

[0109] Calculate the cosine similarity between the i-th corrected test feature vector and the j-th production feature vector;

[0110] Produce a cosine similarity matrix; wherein the element in the i-th row and j-th column of the cosine similarity matrix is ​​the cosine similarity between the i-th corrected test feature vector and the production feature vector of the j-th production data;

[0111] Iterate through each element in the cosine similarity matrix, compare the element with the preset similarity threshold, and generate a coverage relation matrix based on the comparison results. If the element in the i-th row and j-th column of the cosine similarity matrix is ​​equal to or greater than the preset similarity threshold, then the element in the i-th row and j-th column of the coverage relation matrix is ​​set to the first value; otherwise, it is set to the second value.

[0112] The coverage ratio of the test data to the production data is obtained by counting the number of elements in the coverage matrix that have the first value.

[0113] In one optional embodiment, the device 400 further includes a test data supplementation module, the test data supplementation module comprising:

[0114] The insufficient coverage unit is used to determine the insufficient coverage area based on the coverage relationship between the test data and the production data; the insufficient coverage area is used to characterize the failure of the test data to effectively cover the transaction patterns or feature dimension combinations in the production data;

[0115] The business security level unit is used to determine the business security level corresponding to the insufficient coverage area;

[0116] The test data supplementation unit is used to supplement test data for the insufficiently covered areas according to the business security level.

[0117] In one optional implementation, the test data supplementation unit is specifically used for:

[0118] If the security level of the business is a sensitive high-frequency business, then based on the test feature dimension corresponding to the insufficient coverage area, the original production data including the corresponding feature dimension is filtered from the production data source.

[0119] The actual account identifiers in the original production data are de-identified using a de-identification engine;

[0120] Replace the account identifiers in the anonymized production data with virtual account identifiers pre-assigned in the test environment to obtain supplementary test data.

[0121] The banking business system test data coverage processing device provided in this application embodiment can execute the banking business system test data coverage processing method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the banking business system test data coverage processing method.

[0122] According to embodiments of the present invention, the present invention also provides an electronic device, a readable storage medium, and a computer program product. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements any of the bank business system test data overlay processing methods provided in any embodiment of the present invention.

[0123] Example 5

[0124] Figure 5This is a schematic diagram of the structure of an electronic device 510 implementing the banking system test data coverage processing method of this application embodiment. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0125] like Figure 5 As shown, the electronic device 510 includes at least one processor 511 and a memory, such as a read-only memory (ROM) 512 or a random access memory (RAM) 513, communicatively connected to the at least one processor 511. The memory stores computer programs executable by the at least one processor. The processor 511 can perform various appropriate actions and processes based on the computer program stored in the ROM 512 or loaded from storage unit 518 into the RAM 513. The RAM 513 can also store various programs and data required for the operation of the electronic device 510. The processor 511, ROM 512, and RAM 513 are interconnected via a bus 514. An input / output (I / O) interface 515 is also connected to the bus 514.

[0126] Multiple components in electronic device 510 are connected to I / O interface 515, including: input unit 516, such as keyboard, mouse, etc.; output unit 517, such as various types of displays, speakers, etc.; storage unit 518, such as disk, optical disk, etc.; and communication unit 519, such as network card, modem, wireless transceiver, etc. Communication unit 519 allows electronic device 510 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0127] Processor 511 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 511 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 511 performs the various methods and processes described above, such as the test data coverage processing method for a banking system.

[0128] In some embodiments, the banking system test data coverage processing method can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 518. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 510 via ROM 512 and / or communication unit 519. When the computer program is loaded into RAM 513 and executed by processor 511, one or more steps of the banking system test data coverage processing method described above can be performed. Alternatively, in other embodiments, processor 511 can be configured as the banking system test data coverage processing method by any other suitable means (e.g., by means of firmware).

[0129] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0130] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0131] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0132] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0133] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0134] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0135] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0136] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for processing test data coverage in a banking business system, characterized in that, include: Production data and test data are obtained from the production data source and test data source of the banking business system, respectively, and feature extraction is performed on the production data and test data to obtain production feature vectors and test feature vectors. The test weights of the test data are determined based on the importance weight of business logic, the risk exposure weight, and the cost efficiency weight. Based on the test weights of the test data, the test feature vectors, and the production feature vectors, the coverage relationship between the test data and the production data is determined.

2. The method according to claim 1, characterized in that, The determination of test weights for test data based on business logic importance weights, risk exposure weights, and cost efficiency weights includes: Based on each test feature dimension in the test data, and the prior ranking of the importance of each key feature dimension, the business logic importance weight of the test data is determined. Based on the transaction type and historical issue information of the test data, determine the risk exposure weight of the test data; The cost-efficiency weight of the test data is determined based on at least one of the following: the type of anonymization of the test data, the extraction complexity, or the storage overhead. The test weights of the test data are determined based on the business logic importance weight, risk exposure weight, and cost efficiency weight of the test data.

3. The method according to claim 2, characterized in that, The step of determining the business logic importance weight of the test data based on each test feature dimension in the test data and the pre-sorting of the importance of each key feature dimension includes: A judgment matrix is ​​constructed based on the pre-sorting of the importance of each key feature dimension. The eigenvalues ​​of the judgment matrix are solved using the analytic hierarchy process (AHP) to obtain the initial weights of the key feature dimensions. The initial weights of the key feature dimensions are normalized to obtain the final weights of the key feature dimensions. The business logic importance weight of the test data is determined based on each test feature dimension in the test data and the final weight of the key feature dimension.

4. The method according to claim 2, characterized in that, The step of determining the risk exposure weight of the test data based on the transaction type and historical issue information of the test data includes: Based on the transaction type of the test data, obtain the transaction volume level corresponding to that transaction type; Based on the transaction type, retrieve the frequency of historically triggered issues from the historical issue database; The risk factors of the test data are determined based on the transaction type, the transaction volume level, and the frequency of the problem. The risk exposure weight of the test data is determined based on the risk factors and preset risk coefficients.

5. The method according to claim 1, characterized in that, The determination of the coverage relationship between the test data and the production data based on the test weights, the test feature vectors, and the production feature vectors includes: For the i-th test data and the j-th production data, the test weight of the i-th test data is multiplied by the test feature vector of the i-th test data to obtain the i-th corrected test feature vector; Calculate the cosine similarity between the i-th corrected test feature vector and the j-th production feature vector; Produce a cosine similarity matrix; wherein the element in the i-th row and j-th column of the cosine similarity matrix is ​​the cosine similarity between the i-th corrected test feature vector and the production feature vector of the j-th production data; Iterate through each element in the cosine similarity matrix, compare the element with the preset similarity threshold, and generate a coverage relation matrix based on the comparison results. If the element in the i-th row and j-th column of the cosine similarity matrix is ​​equal to or greater than the preset similarity threshold, then the element in the i-th row and j-th column of the coverage relation matrix is ​​set to the first value; otherwise, it is set to the second value. The coverage ratio of the test data to the production data is obtained by counting the number of elements in the coverage matrix that have the first value.

6. The method according to claim 1 or 5, characterized in that, Also includes: Based on the coverage relationship between the test data and the production data, areas with insufficient coverage are identified; these areas with insufficient coverage are used to characterize the failure of the test data to effectively cover the transaction patterns or feature dimension combinations in the production data. Determine the business security level corresponding to the insufficient coverage area; Based on the stated business security level, supplement test data for the areas with insufficient coverage.

7. The method according to claim 6, characterized in that, The step of supplementing test data for the under-covered areas according to the business security level includes: If the security level of the business is a sensitive high-frequency business, then based on the test feature dimension corresponding to the insufficient coverage area, the original production data including the corresponding feature dimension is filtered from the production data source. The actual account identifiers in the original production data are de-identified using a de-identification engine; Replace the account identifiers in the anonymized production data with virtual account identifiers pre-assigned in the test environment to obtain supplementary test data.

8. A device for processing test data coverage in a banking business system, characterized in that, include: The data feature extraction module is used to obtain production data and test data from the production data source and test data source of the banking business system, respectively, and to extract features from the production data and test data to obtain production feature vectors and test feature vectors. The test weighting module is used to determine the test weights of test data based on the importance weight of business logic, the risk exposure weight, and the cost efficiency weight. The coverage relationship determination module is used to determine the coverage relationship between the test data and the production data based on the test weights of the test data, the test feature vectors, and the production feature vectors.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the banking business system test data coverage processing method as described in any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the banking business system test data coverage processing method according to any one of claims 1-7.

Images