An offline data-driven login stress test account construction and stress test method

Abstract

The application provides an offline data-driven login stress test account construction and stress test method in the technical field of software testing, comprising the following steps: first, importing a business table and checking integrity, then performing consistent dynamic desensitization on sensitive fields to ensure format compliance; subsequently, extracting account behavior characteristics and calculating weight coefficients, classifying portraits and proportionally sampling to generate stress test data sets; finally, importing a stress test tool, configuring differentiated strategies according to portrait labels to perform login interface stress test and collect performance indicators, and destroying sandbox data after completion; data security, business association authenticity and stress test effectiveness are considered throughout the process. The application has the advantages of greatly improving the security of stress test data, account simulation degree, traffic model authenticity, self-controllability and efficiency of the preparation process, data quality guarantee level, and completeness of data destruction after stress test.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to an offline data-driven method for constructing and testing login stress testing accounts. Background Technology

[0002] In the operation and maintenance of bidding information systems, during critical business periods such as bid opening and centralized bid evaluation, a massive number of suppliers log in with high concurrency in a short period of time, and the system performance bottleneck is concentrated on the login interface. In order to verify the system's peak load capacity, the industry generally needs to build supplier test accounts in batches and conduct special stress tests on the login link accordingly.

[0003] Currently, there are two main technical approaches to creating load testing accounts: First, the production database-based approach. This approach grants access to the production database, allowing online reading of raw supplier information, extraction of account-related fields, and subsequent processing to generate test accounts. Second, the external interface-based approach. This approach connects to upstream business system interfaces, calls third-party data sources to obtain basic supplier information, and then assembles and generates test data according to the target system's account rules.

[0004] The existing solutions described above have the following technical defects: 1. High data security risks. The production database solution requires granting database access to load testing personnel, which makes it extremely easy for data to be accidentally deleted or corrupted due to operational errors. This also expands the exposure of sensitive data, posing a risk of leakage. Even with data masking, conventional masking methods (such as random replacement and masking) often disrupt foreign key relationships between tables and the consistency of business logic, causing the masked data to be unable to support multi-table join queries, resulting in the loss of availability of load testing data.

[0005] Second, there is a strong external dependency and the process is uncontrollable. The interface solution requires coordination with multiple systems to complete protocol adaptation, field mapping and joint debugging. The process is cumbersome and time-consuming, and it is severely dependent on the availability of upstream systems. Once the interface changes or the service goes down, the preparation for stress testing will be interrupted.

[0006] Third, the accounts generated by the existing solution have low fidelity and distorted traffic models. The accounts generated are inconsistent with real supplier logic in terms of organizational structure, permission configuration, and field format, and the login request messages deviate from actual business scenarios. More importantly, the generated accounts are all homogeneous, lacking the ability to simulate the differences in login behavior among suppliers with varying activity levels in a real environment (such as high-frequency bidders, low-frequency inactive users, and newly registered users). This results in a significant deviation between the business distribution of the load testing traffic model and actual production, limiting the reference value of the test results.

[0007] Fourth, the preparation cycle is long, the cost is high, and the quality assurance is lacking. The existing solution lacks a standardized offline data reuse mechanism, and the data source needs to be re-coordinated for each load test, resulting in a large amount of repetitive work. At the same time, the pre-testing process lacks verification of data integrity and foreign key consistency. Problems such as broken foreign keys and missing fields often only emerge during the load test execution stage, leading to rework and further increasing testing costs and time investment.

[0008] 5. Incomplete data destruction poses a risk of residual data. After load testing, existing solutions typically only perform logical deletion or file deletion operations without physically overwriting the storage media. Sensitive data can be recovered using data recovery tools, posing a secondary risk of data leakage.

[0009] Therefore, how to provide an offline data-driven method for constructing and testing login stress test accounts, thereby improving the security of stress test data, the fidelity of account simulation and the authenticity of traffic models, the autonomy and controllability and efficiency of the preparation process, the level of data quality assurance, and the thoroughness of data destruction after stress testing, has become an urgent technical problem to be solved. Summary of the Invention

[0010] The technical problem to be solved by this invention is to provide an offline data-driven login stress testing account construction and stress testing method, which improves the security of stress testing data, the fidelity of account simulation and the authenticity of traffic models, the autonomy and controllability and efficiency of the preparation process, the level of data quality assurance, and the thoroughness of data destruction after stress testing.

[0011] This invention provides an offline data-driven login stress testing account construction and stress testing method, including the following steps: Step S1: Import the multiple business data tables exported offline into the local sandbox environment and perform data integrity verification on the multiple business data tables; Step S2: Perform dynamic data desensitization processing on the sensitive fields in each of the business data tables after verification to ensure the authenticity of the association relationship, and generate a desensitized data table. The dynamic data desensitization processing ensures that the related fields of the same business entity in different business data tables are consistent after desensitization, and the format of the desensitized fields conforms to the verification rules of the login interface of the target system. Step S3: Based on the de-identified data table, extract the multi-dimensional behavioral features of each account, calculate the behavioral weight coefficient of each account based on the multi-dimensional behavioral features, and classify and label the accounts based on the behavioral weight coefficient and assign image labels. Sample from each image category according to a preset ratio to generate a load test account dataset with image labels. Step S4: Import the load test account dataset into the load test tool, configure differentiated load test execution strategies according to the profile tags of various types of accounts, perform load tests on the login interface of the target system, and collect performance indicator data; Step S5: After the stress test is completed, perform data destruction processing on the storage medium in the local sandbox environment.

[0012] Furthermore, in step S1, the multiple business data tables exported offline are data tables exported offline from the local business system, without accessing the online production database or calling third-party business interfaces throughout the process.

[0013] Furthermore, in step S1, the data integrity verification includes: File fingerprint verification: Calculate the MD5 checksum of each of the imported business data tables and compare it with the MD5 checksum generated in advance when the business data table is exported. If the two are inconsistent, terminate the process and output an abnormal alarm. Foreign key association integrity check: Identify the primary key fields and foreign key fields of each business data table, and calculate the cross-table record matching rate through association query. If the matching rate of any association is lower than the preset threshold, the process is terminated and the number of missing rows, the table names involved, and the list of missing primary key values ​​are output. Field-level metadata compliance verification: Traverse each field of each business data table, verify the compliance of field type, length, precision and non-null constraints according to the preset metadata rule base, establish dictionary mapping for enumeration type fields with business meaning, verify whether the actual field value falls within the predefined legal enumeration value range, and if non-compliant fields are found, generate field anomaly reports and mark the corresponding records; Business logic deep validation: Based on preset cross-field association rules, contextual logic validation is performed on the data in the business data table. The business logic deep validation includes at least the following: (1) Time axis logic verification: verify whether the timestamps of each state change corresponding to the same entity in the business data table conform to the preset business time sequence. (2) Verify the activity of the associated data. Verify whether the status field of the main table record associated with the foreign key in the business data table is valid. If the associated main table record has been marked as logically deleted or has expired, the foreign key association is determined to be invalid. Tiered data cleaning and repair mechanism: Based on the verification results of the foreign key association integrity check, the field-level metadata compliance check, and the business logic deep verification, records are processed in a tiered manner according to preset anomaly level classification rules: (a) For records that are judged to be fatal anomalies, remove them from the load testing account candidate set and generate a cleaning log containing the record primary key and the reason for the anomaly; (b) For records that are determined to be repairable anomalies, field value correction or foreign key remapping is automatically performed according to the preset data repair strategy library. The data repair strategy library includes mean filling strategy based on inter-table relationships, default value mapping strategy based on business dictionary and correction strategy based on timestamp sequence prediction. (c) For the repaired record, perform incremental verification again. Only after the verification is passed can the record be included in the subsequent desensitization process.

[0014] Furthermore, in step S1, the business data table includes at least a supplier registry, a qualification information table, a permission allocation table, an account information table, a basic information table, a role configuration table, and a unit basic information table.

[0015] Furthermore, in step S2, the dynamic data anonymization process for preserving the association relationship specifically includes: Establish a global desensitization mapping dictionary, traverse the sensitive fields in each of the aforementioned business data tables, and generate a unique desensitization value for the original value of each of the aforementioned sensitive fields; For related fields that are primary keys or foreign keys, a consistent hashing algorithm is used for de-identification, so that the results of de-identification of the same original ID are consistent in different business data tables. For fields with format constraints, a format-preserving encryption algorithm is used for desensitization to ensure that the length and character set of the desensitized field remain consistent with those before desensitization.

[0016] Furthermore, step S2 also includes: Verify the irreversibility of the de-identified data table, the consistency between the results of multi-table join queries and those before de-identification, and that the format compliance rate of fields with format constraints meets the preset standard.

[0017] Furthermore, in step S3, the multidimensional behavioral features include the frequency of historical bidding records, the most recent login time, the registration duration, the qualification level, the number of historical successful bids, the industry category, the number of units associated with the account, the entropy value of the login behavior sequence in the past N natural days, and the business collaboration relationship strength index between the account and other supplier accounts. The most recent login time is calculated using a time decay function based on a half-life parameter to determine the decay factor, and the decay function dynamically adjusts its decay rate according to the business period. The behavior weighting coefficient is dynamically calculated through the following steps: Step A: Divide accounts into four lifecycle stages based on their registration duration: initial stage, growth stage, stable stage, and decline stage; Step B: Based on the business scenario type of the current load testing task, match the corresponding initial weight allocation scheme from the preset weight strategy library; Step C: Based on the account's current lifecycle stage, the initial weight allocation scheme is modified in stages to generate a stage weight vector; Step D: After normalizing the feature values ​​of each dimension, perform a weighted sum with the stage weight vector to obtain the behavior weight coefficient; The generation of the profile tags adopts a fuzzy classification strategy, introducing a confidence interval based on the behavior weight coefficient: When the behavior weight coefficient falls into the core confidence interval of a certain category, a unique profile label is directly assigned. When the behavior weight coefficient falls into the overlapping range of the category boundary, a multi-label candidate set is generated for the account, and the membership score of each label is recorded for elastic strategy matching when configuring subsequent stress testing strategies. The profile tags include at least four categories: high-frequency active suppliers, medium-frequency ordinary suppliers, low-frequency zombie suppliers, and newly registered suppliers, and the division boundaries of the weight thresholds for each category are dynamically adjusted according to the business scenario.

[0018] Furthermore, in step S3, the preset ratio is: 10% for high-frequency active suppliers, 50% for medium-frequency ordinary suppliers, 30% for low-frequency zombie suppliers, and 10% for newly registered suppliers.

[0019] Furthermore, in step S4, the load testing execution strategy includes: High-frequency active accounts use a request interval of 1-3 seconds, and their concurrent thread count is higher than that of medium-frequency ordinary accounts; Medium-frequency ordinary accounts use a request interval of 5-10 seconds, and their concurrent thread count is between that of high-frequency active accounts and low-frequency zombie accounts. Low-frequency zombie accounts use a request interval of 30-60 seconds, and their concurrent thread count is lower than that of medium-frequency ordinary accounts. Newly registered accounts use a complete first-time login process that includes verification code checking and initial password modification.

[0020] Furthermore, in step S5, the data destruction process includes: Logical deletion steps: Delete the de-identified data tables, load testing scripts, and result report files in the local sandbox environment; Physical overwrite steps: Perform multiple overwrite operations on the storage medium storing pressure test related data. The multiple overwrite operations include writing all 0 data in the first round, writing all 1 data in the second round, and writing random 0 / 1 data in the third round. Cache cleanup steps: Clear relevant data from system memory cache, page file, and temporary directory.

[0021] The advantages of this invention are: 1. A completely offline isolated closed-loop technical system was constructed, fundamentally eliminating the risks of production database permission exposure and external interface dependencies. Simultaneously, a high-fidelity de-identification algorithm combining consistent hashing and format-preserving encryption was employed to fully preserve cross-table relationships and field format compliance while ensuring data irreversibility, thus effectively guaranteeing data security and availability. Building upon this, a multi-level deep verification mechanism (covering file fingerprints, foreign key integrity, metadata, and business logic) combined with a tiered automatic repair strategy eliminates quality issues such as broken foreign keys and logical conflicts before load testing, significantly improving data quality assurance levels. Furthermore, multi-dimensional behavioral characteristics, lifecycle stage segmentation, dynamic weight calculation, and fuzzy classification strategies are used to generate refined account profiles. For example, different request intervals and concurrent thread counts are configured for different profile categories, making the load testing traffic model highly consistent with the mixed access distribution of different active suppliers in real business scenarios, which greatly improves the account simulation and traffic authenticity. The entire preparation process relies entirely on the offline data standardization pipeline in the local sandbox environment, without the need to coordinate multi-system joint debugging, which not only achieves autonomous control and efficient reuse of the process, but also greatly shortens the preparation cycle. After the load test is completed, a three-level deep destruction operation is performed in sequence: logical deletion, multiple rounds of physical overwriting (all 0, all 1 and random data), and cache cleanup, to ensure that the data in the storage medium cannot be restored by any recovery tool, and finally form a complete security closed loop from secure data import, high-quality fidelity processing, high-simulation load test execution to complete destruction.

[0022] 2. By isolating offline import with a local sandbox environment and combining dynamic data masking to ensure the fidelity of relationships, a high degree of consistency in security and availability of load testing data is achieved. All business data tables are exported offline from the local business system, without accessing the online production database or calling any third-party business interfaces. Load testing personnel operate only in an independent sandbox environment, completely eliminating the risk of accidental operation in the production environment. Simultaneously, a global data masking mapping dictionary and a consistent hashing algorithm are used to mask primary and foreign key relationship fields, ensuring consistent relationships across tables for the same entity after masking. Format constraint fields are encrypted using a format-preserving algorithm, ensuring that the masked data satisfies login interface verification rules while maintaining consistency between multi-table join query results and the original data. This preserves the complete business logic relationships while ensuring data irreversibility, giving the load testing data high availability value.

[0023] 3. Achieving a fully autonomous closed-loop process for load testing account preparation and execution significantly improves test organization efficiency. The entire method relies solely on offline exported business data tables, requiring no interface integration with any external business systems, and eliminating the need for cross-system protocol adaptation, field mapping, or joint debugging tests. All operations are completed independently within a local sandbox environment. This frees load testing preparation from the availability of upstream systems, interface changes, or network fluctuations. The testing team can fully control the progress, significantly shortening the preparation cycle, avoiding the uncertainties caused by cross-departmental coordination, and achieving a standardized and repeatable offline data reuse mechanism.

[0024] 4. Based on multi-dimensional behavioral features and dynamic profiling technology, a highly realistic differentiated load testing traffic model was constructed. Multi-dimensional features such as historical bidding frequency, login behavior sequence entropy, and business collaboration strength were extracted from anonymized data. Lifecycle stages were divided based on account registration duration, and behavioral weight coefficients were dynamically calculated. A fuzzy classification strategy was used to generate profile tags such as high-frequency active, medium-frequency ordinary, low-frequency inactive, and newly registered accounts, and the classification thresholds were flexibly adjusted according to business scenarios. On this basis, a load testing account dataset was formed by sampling at a preset ratio close to real-world distribution. Differentiated request intervals, concurrent thread counts, and login processes were configured for each profile, ensuring that the load testing traffic accurately simulates the concurrent behavior distribution of different activity groups in a real production environment, guaranteeing that the test results have high business reference value.

[0025] 5. A systematic pre-testing data quality verification and tiered repair mechanism ensures the integrity and consistency of load testing data, effectively mitigating data anomalies during the load testing execution phase. During the import stage, the system performs file fingerprint verification, foreign key integrity checks, field-level metadata compliance checks, and in-depth cross-field business logic verification (such as timeline sequence and related data liveness). Issues are tiered according to their anomaly severity: fatal anomaly records are automatically removed and cleaned logs are generated; repairable anomalies are automatically filled with the mean, mapped to default values, or corrected with timestamps based on a strategy library, and only proceed to subsequent stages after passing incremental verification. This pre-testing assurance system ensures that the data entering the anonymization and load testing phase has complete foreign key relationships, compliant field formats, and correct business logic, preventing load testing failures and rework due to broken foreign keys or missing fields from the outset. It also supports standardized reuse of the same offline dataset, significantly reducing repetitive labor costs.

[0026] 6. Construct a multi-layered, irreversible data destruction process to ensure that sensitive data is completely free of any residual risk after load testing. After load testing, first, logical deletion is performed to clear the anonymized data tables, load testing scripts, and result report files from the local sandbox environment; then, a physical overwrite operation is performed, overwriting the storage media multiple times (all 0s, all 1s, random 0 / 1s) to ensure that the original data cannot be recovered by any data recovery tools; finally, related data in the system memory cache, page file, and temporary directory is cleared. This triple destruction mechanism ensures that no recoverable data traces remain in the local environment, completely eliminating the possibility of secondary access to test data at the physical level, and meeting the data compliance requirements of high-security systems. Attached Figure Description

[0027] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0028] Figure 1 This is a flowchart of an offline data-driven login stress testing account construction and stress testing method according to the present invention. Detailed Implementation

[0029] The overall approach of the technical solution in this application is as follows: Multiple data tables exported offline from the business system are imported into a local sandbox environment. A multi-layered verification and hierarchical automatic repair mechanism, encompassing file fingerprinting, foreign key integrity, metadata compliance, and business logic depth, is executed beforehand to ensure that the data entering subsequent stages has complete foreign key relationships, compliant field formats, and correct business logic. Then, a high-fidelity de-identification algorithm combining consistent hashing and format-preserving encryption is used to fully preserve cross-table relationships and field format compliance while ensuring data irreversibility, thus balancing data security and availability. Subsequently, based on the de-identified data… Based on extracted multi-dimensional behavioral features, combined with account lifecycle stage segmentation, dynamic weight calculation, and fuzzy classification strategies, refined account profiles are generated (such as high-frequency active, medium-frequency ordinary, low-frequency inactive, and newly registered categories). A load testing account dataset is then formed by sampling according to a preset proportion closely resembling real-world distribution. Different request intervals and concurrent thread counts are configured for different profile categories, ensuring the load testing traffic model closely matches the mixed access distribution of different activity providers in real-world business scenarios. After the load test, a three-level deep destruction operation is performed sequentially: logical deletion, multiple rounds of physical overwriting, and cache cleanup, ensuring no residual risk of sensitive data. The entire process relies entirely on an offline data standardization pipeline in a local sandbox environment, without accessing online production databases or calling external interfaces. This achieves both autonomous control and efficient reuse of the process, forming a complete security closed loop from secure data import, high-quality fidelity processing, high-fidelity load testing execution to complete destruction.

[0030] Please refer to Figure 1As shown, a preferred embodiment of the present invention, a method for constructing and stress testing login stress testing accounts based on offline data, includes the following steps: Step S1: Import the multiple business data tables exported offline into the local sandbox environment and perform data integrity verification on the multiple business data tables; Step S2: Perform dynamic data desensitization processing on the sensitive fields in each of the business data tables after verification to ensure the authenticity of the association relationship, and generate a desensitized data table. The dynamic data desensitization processing ensures that the related fields of the same business entity in different business data tables are consistent after desensitization, and the format of the desensitized fields conforms to the verification rules of the login interface of the target system. Step S3: Based on the de-identified data table, extract the multi-dimensional behavioral features of each account, calculate the behavioral weight coefficient of each account based on the multi-dimensional behavioral features, and classify and label the accounts based on the behavioral weight coefficient and assign image labels. Sample from each image category according to a preset ratio to generate a load test account dataset with image labels. Step S4: Import the load test account dataset into a load testing tool (such as JMeter), configure differentiated load test execution strategies according to the profile tags of various types of accounts, perform load tests on the login interface of the target system, and collect performance indicator data; During the load test, performance metrics such as response time, success rate, throughput, and error rate of the login interface are collected in real time, as well as resource metrics such as CPU, memory, and database connection count of the server, forming a complete load data analysis report.

[0031] During load testing, the response status of the target system is monitored in real time. When the error rate of the login interface exceeds a preset alarm threshold or the average response time exceeds a preset timeout threshold, an adaptive traffic adjustment mechanism is triggered. This mechanism gradually reduces the number of concurrent threads for high-frequency active accounts and medium-frequency ordinary accounts until the system stabilizes and then gradually returns to the original concurrency level. Simultaneously, the trigger time, adjustment range, and recovery process of the adaptive traffic adjustment mechanism are recorded as part of the performance metric data for subsequent stress analysis to assess the system's bottleneck threshold and resilience. Furthermore, during load testing, the account usage status in the load testing account dataset is marked to prevent the same account from being repeatedly invoked in concurrent requests, which could lead to status conflicts.

[0032] Step S5: After the stress test is completed, perform data destruction processing on the storage medium in the local sandbox environment.

[0033] In step S1, the multiple business data tables exported offline are data tables exported offline from the local business system, without accessing the online production database or calling third-party business interfaces.

[0034] In step S1, the data integrity verification includes: File fingerprint verification: Calculate the MD5 checksum of each of the imported business data tables and compare it with the MD5 checksum generated in advance when the business data table is exported. If the two are inconsistent, terminate the process and output an abnormal alarm. Foreign key association integrity check: Identify the primary key fields and foreign key fields of each business data table, and calculate the cross-table record matching rate through association query. If the matching rate of any association is lower than the preset threshold (such as 90%), the process is terminated and the number of missing rows, the table names involved, and the list of missing primary key values ​​are output. Field-level metadata compliance verification: Traverse each field of each business data table, verify the compliance of field type, length, precision and non-null constraints according to the preset metadata rule base, establish dictionary mapping for enumeration type fields with business meaning, verify whether the actual field value falls within the predefined legal enumeration value range, and if non-compliant fields are found, generate field anomaly reports and mark the corresponding records; Business logic deep validation: Based on preset cross-field association rules, contextual logic validation is performed on the data in the business data table. The business logic deep validation includes at least the following: (1) Time axis logic verification: verify whether the timestamps of each state change corresponding to the same entity in the business data table conform to the preset business time sequence. (2) Verify the activity of the associated data. Verify whether the status field of the main table record associated with the foreign key in the business data table is valid. If the associated main table record has been marked as logically deleted or has expired, the foreign key association is determined to be invalid. Tiered data cleaning and repair mechanism: Based on the verification results of the foreign key association integrity check, the field-level metadata compliance check, and the business logic deep verification, records are processed in a tiered manner according to preset anomaly level classification rules: (a) For records that are judged to be fatal anomalies, remove them from the load testing account candidate set and generate a cleaning log containing the record primary key and the reason for the anomaly; (b) For records that are determined to be repairable anomalies, field value correction or foreign key remapping is automatically performed according to the preset data repair strategy library. The data repair strategy library includes mean filling strategy based on inter-table relationships, default value mapping strategy based on business dictionary and correction strategy based on timestamp sequence prediction. (c) For the repaired record, perform incremental verification again. Only after the verification is passed can the record be included in the subsequent desensitization process.

[0035] In a preferred embodiment, the local sandbox environment is a physically or virtually isolated computing environment independent of the business production environment. Its network communication interface is disconnected during the stress test preparation phase, and the stress test communication port with the target system is only opened as needed during the stress test execution phase. The offline export operation of the business data tables is performed by the data administrator of the business system under authorized audit. During the export process, the file hash value and export timestamp of each data table are recorded synchronously, and the file hash value and export timestamp are packaged together and transmitted to the local sandbox environment as the basis for subsequent file fingerprint verification. Through the above-mentioned offline export and sandbox isolation mechanism, it is ensured that the original business data does not pass through any public network transmission link during the entire stress test preparation cycle, nor is it stored on any intermediate storage node other than the sandbox storage medium, thereby physically eliminating the risk of data leakage during transmission and temporary storage.

[0036] In step S1, the business data table includes at least a supplier registry, a qualification information table, a permission allocation table, an account information table, a basic information table, a role configuration table, and a unit basic information table.

[0037] In step S2, the dynamic data anonymization process for ensuring the authenticity of the association relationship specifically includes: Establish a global desensitization mapping dictionary, traverse the sensitive fields in each of the aforementioned business data tables, and generate a unique desensitization value for the original value of each of the aforementioned sensitive fields; For related fields that serve as primary keys or foreign keys, a consistent hashing algorithm is used for data masking, ensuring that the same original ID remains consistent across different business data tables after masking. For example, if the supplier ID "ABC00123" in the supplier registry is masked as "DES_8a7f2b", then all foreign key fields referencing this supplier ID in the qualification information table, permission allocation table, etc., will also be uniformly masked as "DES_8a7f2b", thus ensuring that cross-table relationships are not disrupted.

[0038] For fields with format constraints, a Format-Preserving Encryption (FPE) algorithm is used for de-identification to ensure that the length and character set of the de-identified field remain consistent with those before de-identification. For example, if the original account number is a 10-digit number, it will remain a 10-digit number after de-identification; if the original permission code is a combination of letters and numbers with a fixed length, the same format constraints will be maintained after de-identification.

[0039] During the de-identification process, a cross-table de-identification mapping dictionary is established to ensure that the primary key and foreign key fields of the same business entity remain completely consistent after de-identification in different tables, ensuring that the multi-table relationships are not damaged. At the same time, format constraint validation is performed on the account field and permission encoding field to ensure that the account length, character set, and permission encoding rules after de-identification comply with the regular expression validation rules of the login interface, avoiding the interception of load test requests due to abnormal formats.

[0040] In a preferred embodiment, when a sensitive field simultaneously meets the requirements of being a primary key / foreign key related field and having format constraints, a consistent hashing algorithm is preferentially used for desensitization, and the output result is checked for format compliance after desensitization. If the check fails, a secondary format adaptation conversion is performed based on the output result of the consistent hashing algorithm. The secondary format adaptation conversion includes character set mapping, length truncation or padding operations, and a bidirectional mapping relationship between the original desensitized value and the converted value is maintained during the conversion process to ensure cross-table consistency and field-level format compliance. In addition, the global desensitization mapping dictionary is stored in an encrypted manner, indexed by the desensitization task identifier, and is destroyed along with the sandbox data after the load testing process is completed, ensuring that the desensitization mapping relationship is not stored externally, further eliminating the risk of data recovery.

[0041] Step S2 further includes: Verify the irreversibility of the de-identified data table (cannot be reversed), the consistency between the results of multi-table join queries and those before de-identification (association fidelity), and that the format compliance rate of fields with format constraints meets the preset standard.

[0042] In step S3, the multidimensional behavioral features include the frequency of historical bidding records, the most recent login time, the registration duration, the qualification level, the number of historical successful bids, the industry category, the number of units associated with the account, the entropy value of the login behavior sequence in the past N natural days, and the business collaboration relationship strength index between the account and other supplier accounts. The most recent login time is calculated using a time decay function based on a half-life parameter to determine the decay factor, and the decay function dynamically adjusts its decay rate according to the business period. The behavior weighting coefficient is dynamically calculated through the following steps: Step A: Divide accounts into four lifecycle stages based on their registration duration: initial stage, growth stage, stable stage, and decline stage; Step B: Based on the business scenario type of the current load testing task, match the corresponding initial weight allocation scheme from the preset weight strategy library; Step C: Based on the account's current lifecycle stage, the initial weight allocation scheme is modified in stages to generate a stage weight vector; Step D: After normalizing the feature values ​​of each dimension, perform a weighted sum with the stage weight vector to obtain the behavior weight coefficient; Before calculating the behavioral weight coefficients, the behavioral feature values ​​of each dimension need to be normalized. Specifically, for numerical features such as the frequency of historical bidding records, the number of historical successful bids, and the number of units associated with the account, linear normalization is performed using the min-max scaling method, mapping them to the [0,1] interval; for categorical features such as qualification level and industry category, one-hot encoding or target encoding is used to convert them into numerical features before normalization; for the login behavior sequence entropy value, the sliding window method is used to calculate the login behavior information entropy of each account in the past N natural days to measure the regularity and randomness of its login time. The higher the entropy value, the more unpredictable the login behavior is, and the higher the risk weight of abnormal activity; for the business collaboration relationship strength index, a weighted co-occurrence network is constructed based on the number of times the account and other supplier accounts participate in bidding together, and the node degree centrality index is used to measure its collaboration strength. During the normalization process, the value range of each feature is dynamically truncated according to the quantiles of the actual distribution in the desensitized data table to eliminate the interference of extreme outliers on the weight calculation results.

[0043] The generation of the profile tags adopts a fuzzy classification strategy, introducing a confidence interval based on the behavior weight coefficient: When the behavior weight coefficient falls into the core confidence interval of a certain category, a unique profile label is directly assigned. When the behavior weight coefficient falls into the overlapping range of the category boundary, a multi-label candidate set is generated for the account, and the membership score of each label is recorded for elastic strategy matching when configuring subsequent stress testing strategies. The profile tags include at least four categories: high-frequency active suppliers (accounts in the top 10% of the score, simulating core suppliers who frequently participate in bidding and log in), medium-frequency ordinary suppliers (accounts in the 10%-60% range of the score, simulating suppliers with normal activity), low-frequency zombie suppliers (accounts in the bottom 30% of the score, simulating suppliers who rarely log in and are inactive for a long time), and newly registered suppliers (accounts registered for less than 7 days, simulating new suppliers logging into the system for the first time). The division boundaries of the weight thresholds for each category are dynamically adjusted according to the business scenario.

[0044] When performing the preset proportion sampling, a stratified random sampling strategy is adopted. This involves secondary stratification within each profile category based on secondary dimensions such as account registration duration or industry affiliation. This ensures that the distribution ratio of the sampled load testing account dataset across each secondary dimension is essentially consistent with the original distribution in the anonymized data table. For accounts assigned multi-label candidate sets within overlapping category boundaries, if such accounts are selected in the sampling, they are randomly assigned to the corresponding single profile category based on their membership score during the actual load testing strategy allocation. This ensures the reasonableness of boundary samples while maintaining the distinguishability between categories and the natural transition of load testing traffic distribution.

[0045] In step S3, the preset ratio is: 10% for high-frequency active suppliers, 50% for medium-frequency ordinary suppliers, 30% for low-frequency zombie suppliers, and 10% for newly registered suppliers.

[0046] In step S4, the load testing execution strategy includes: High-frequency active accounts use a request interval of 1-3 seconds, and their concurrent thread count is higher than that of medium-frequency ordinary accounts; this simulates the peak scenario of suppliers logging in 1 hour before the bid opening, in order to test the system's maximum capacity. For regular accounts with medium frequency, the request interval is 5-10 seconds, and the number of concurrent threads is between that of high-frequency active accounts and low-frequency inactive accounts; this simulates daily login scenarios and is used to test the stability of the system. Low-frequency zombie accounts use a request interval of 30-60 seconds, and their concurrent thread count is lower than that of medium-frequency ordinary accounts; this simulates occasional login scenarios to test the system's response performance under low load. Newly registered accounts use a complete first-time login process that includes verification code checking and initial password modification; the entire process of a new user's first login is simulated to test the performance of the entire login process.

[0047] In step S5, the data destruction process includes: Logical deletion steps: Delete the de-identified data tables, load testing scripts, and result report files in the local sandbox environment; Physical overwrite steps: Perform multiple overwrite operations on the storage medium storing pressure test related data. The multiple overwrite operations include writing all 0 data in the first round, writing all 1 data in the second round, and writing random 0 / 1 data in the third round. Cache cleanup steps: Clear relevant data from system memory cache, page file, and temporary directory.

[0048] After the logical deletion, physical overwrite, and cache cleanup steps are completed, a data destruction audit report is automatically generated. This report includes a destruction task identifier, destruction start and completion times, a list of destroyed data tables, the number of physical overwrite rounds and verification results, a cache cleanup path list, and an operation log of the destruction operation. The audit report is output in encrypted form to an external audit storage medium to meet the compliance audit requirements of high-security systems. Simultaneously, after performing the physical overwrite operation, a random sampling method is used to verify the overwrite of specified sectors in the storage medium, ensuring that the overwritten data pattern is consistent with expectations. Destruction is considered complete only after verification passes; otherwise, the physical overwrite is re-executed until verification passes.

[0049] Taking a large-scale login load test of a provincial bidding information system as an example, the system has approximately 120,000 registered suppliers. The load test team first exported seven business data tables offline from the business system management backend: supplier registry, qualification information table, permission allocation table, account information table, basic information table, role configuration table, and unit basic information table, with a total exported data volume of approximately 8GB. After importing the above data tables into the local sandbox environment, file fingerprint verification, foreign key association integrity check, field-level metadata compliance verification, and deep business logic verification were performed in sequence. The verification revealed that approximately 0.3% of the records had missing foreign keys or timeline logic anomalies. Among them, approximately 0.1% of the fatal anomaly records were automatically removed, and approximately 0.2% of the repairable anomaly records were repaired through mean filling and timestamp correction strategies. After repair, incremental verification was performed, and finally, approximately 118,000 valid records were included in the de-identification process.

[0050] Subsequently, a consistent hashing algorithm was used to anonymize primary and foreign key fields such as supplier ID, and a format-preserving encryption algorithm was used to anonymize account fields and permission code fields. After anonymization, the data was verified, and the cross-table join query results were completely consistent with those before anonymization, with a format compliance rate of 99.97%. Based on the anonymized data, nine behavioral features were extracted, including historical bidding frequency, login behavior sequence entropy value, and business collaboration relationship strength. Combined with the registration duration, the lifecycle stages were divided. After dynamic weight calculation and fuzzy classification, approximately 12,000 high-frequency active suppliers, approximately 59,000 medium-frequency ordinary suppliers, approximately 35,000 low-frequency zombie suppliers, and approximately 12,000 newly registered suppliers were generated.

[0051] After stratified sampling at proportions of 10%, 50%, 30%, and 10%, a dataset of 10,000 test accounts was generated and imported into the JMeter load testing tool. High-frequency active accounts were configured with an average request interval of 2 seconds and 200 concurrent threads; medium-frequency ordinary accounts were configured with an average request interval of 8 seconds and 80 concurrent threads; low-frequency inactive accounts were configured with an average request interval of 45 seconds and 20 concurrent threads; and newly registered accounts were configured with a complete login process including CAPTCHA simulation and password modification, and 30 concurrent threads. A mixed-scenario load test was executed for 30 minutes, collecting real-time data on login interface response time, success rate, and server resource metrics. After the load test, logical deletion, three rounds of physical overwriting, and cache cleanup were performed sequentially, generating a data destruction audit report. The entire process took approximately 4 hours (including approximately 2 hours for data preparation and verification, approximately 30 minutes for load test execution, and approximately 1.5 hours for data destruction). Compared to the traditional solution's average preparation cycle of 2-3 days, this represents a significant efficiency improvement, and the entire process did not access the online production database, ensuring data security and compliance.

[0052] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. An offline data-driven method for constructing and stress testing login accounts, characterized in that, Includes the following steps: Step S1: Import the multiple business data tables exported offline into the local sandbox environment and perform data integrity verification on the multiple business data tables; Step S2: Perform dynamic data desensitization processing on the sensitive fields in each of the business data tables after verification to ensure the authenticity of the association relationship, and generate a desensitized data table. The dynamic data desensitization processing ensures that the related fields of the same business entity in different business data tables are consistent after desensitization, and the format of the desensitized fields conforms to the verification rules of the login interface of the target system. Step S3: Based on the de-identified data table, extract the multi-dimensional behavioral features of each account, calculate the behavioral weight coefficient of each account based on the multi-dimensional behavioral features, and classify and label the accounts based on the behavioral weight coefficient and assign image labels. Sample from each image category according to a preset ratio to generate a load test account dataset with image labels. Step S4: Import the load test account dataset into the load test tool, configure differentiated load test execution strategies according to the profile tags of various types of accounts, perform load tests on the login interface of the target system, and collect performance indicator data; Step S5: After the stress test is completed, perform data destruction processing on the storage medium in the local sandbox environment.

2. The offline data-driven login stress testing account construction and stress testing method as described in claim 1, characterized in that, In step S1, the multiple business data tables exported offline are data tables exported offline from the local business system, without accessing the online production database or calling third-party business interfaces.

3. The offline data-driven login stress testing account construction and stress testing method as described in claim 1, characterized in that, In step S1, the data integrity verification includes: File fingerprint verification: Calculate the MD5 checksum of each of the imported business data tables and compare it with the MD5 checksum generated in advance when the business data table is exported. If the two are inconsistent, terminate the process and output an abnormal alarm. Foreign key association integrity check: Identify the primary key fields and foreign key fields of each business data table, and calculate the cross-table record matching rate through association query. If the matching rate of any association is lower than the preset threshold, the process is terminated and the number of missing rows, the table names involved, and the list of missing primary key values ​​are output. Field-level metadata compliance verification: Traverse each field of each business data table, verify the compliance of field type, length, precision and non-null constraints according to the preset metadata rule base, establish dictionary mapping for enumeration type fields with business meaning, verify whether the actual field value falls within the predefined legal enumeration value range, and if non-compliant fields are found, generate field anomaly reports and mark the corresponding records; Business logic deep validation: Based on preset cross-field association rules, contextual logic validation is performed on the data in the business data table. The business logic deep validation includes at least the following: (1) Time axis logic verification: verify whether the timestamps of each state change corresponding to the same entity in the business data table conform to the preset business time sequence. (2) Verify the activity of the associated data. Verify whether the status field of the main table record associated with the foreign key in the business data table is valid. If the associated main table record has been marked as logically deleted or has expired, the foreign key association is determined to be invalid. Tiered data cleaning and repair mechanism: Based on the verification results of the foreign key association integrity check, the field-level metadata compliance check, and the business logic deep verification, records are processed in a tiered manner according to preset anomaly level classification rules: (a) For records that are judged to be fatal anomalies, remove them from the load testing account candidate set and generate a cleaning log containing the record primary key and the reason for the anomaly; (b) For records that are determined to be repairable anomalies, field value correction or foreign key remapping is automatically performed according to the preset data repair strategy library. The data repair strategy library includes mean filling strategy based on inter-table relationships, default value mapping strategy based on business dictionary and correction strategy based on timestamp sequence prediction. (c) For the repaired record, perform incremental verification again. Only after the verification is passed can the record be included in the subsequent desensitization process.

4. The offline data-driven login stress testing account construction and stress testing method as described in claim 1, characterized in that, In step S1, the business data table includes at least a supplier registry, a qualification information table, a permission allocation table, an account information table, a basic information table, a role configuration table, and a unit basic information table.

5. The offline data-driven login stress testing account construction and stress testing method as described in claim 1, characterized in that, In step S2, the dynamic data anonymization process for ensuring the authenticity of the association relationship specifically includes: Establish a global desensitization mapping dictionary, traverse the sensitive fields in each of the aforementioned business data tables, and generate a unique desensitization value for the original value of each of the aforementioned sensitive fields; For related fields that are primary keys or foreign keys, a consistent hashing algorithm is used for de-identification, so that the results of de-identification of the same original ID are consistent in different business data tables. For fields with format constraints, a format-preserving encryption algorithm is used for desensitization to ensure that the length and character set of the desensitized field remain consistent with those before desensitization.

6. The offline data-driven login stress testing account construction and stress testing method as described in claim 5, characterized in that, Step S2 further includes: Verify the irreversibility of the de-identified data table, the consistency between the results of multi-table join queries and those before de-identification, and that the format compliance rate of fields with format constraints meets the preset standard.

7. The offline data-driven login stress testing account construction and stress testing method as described in claim 1, characterized in that, In step S3, the multidimensional behavioral features include the frequency of historical bidding records, the most recent login time, the registration duration, the qualification level, the number of historical successful bids, the industry category, the number of units associated with the account, the entropy value of the login behavior sequence in the past N natural days, and the business collaboration relationship strength index between the account and other supplier accounts. The most recent login time is calculated using a time decay function based on a half-life parameter to determine the decay factor, and the decay function dynamically adjusts its decay rate according to the business period. The behavior weighting coefficient is dynamically calculated through the following steps: Step A: Divide accounts into four lifecycle stages based on their registration duration: initial stage, growth stage, stable stage, and decline stage; Step B: Based on the business scenario type of the current load testing task, match the corresponding initial weight allocation scheme from the preset weight strategy library; Step C: Based on the account's current lifecycle stage, the initial weight allocation scheme is modified in stages to generate a stage weight vector; Step D: After normalizing the feature values ​​of each dimension, perform a weighted sum with the stage weight vector to obtain the behavior weight coefficient; The generation of the profile tags adopts a fuzzy classification strategy, introducing a confidence interval based on the behavior weight coefficient: When the behavior weight coefficient falls into the core confidence interval of a certain category, a unique profile label is directly assigned. When the behavior weight coefficient falls into the overlapping range of the category boundary, a multi-label candidate set is generated for the account, and the membership score of each label is recorded for elastic strategy matching when configuring subsequent stress testing strategies. The profile tags include at least four categories: high-frequency active suppliers, medium-frequency ordinary suppliers, low-frequency zombie suppliers, and newly registered suppliers, and the division boundaries of the weight thresholds for each category are dynamically adjusted according to the business scenario.

8. The offline data-driven login stress testing account construction and stress testing method as described in claim 1, characterized in that, In step S3, the preset ratio is: 10% for high-frequency active suppliers, 50% for medium-frequency ordinary suppliers, 30% for low-frequency zombie suppliers, and 10% for newly registered suppliers.

9. The offline data-driven login stress testing account construction and stress testing method as described in claim 1, characterized in that, In step S4, the load testing execution strategy includes: High-frequency active accounts use a request interval of 1-3 seconds, and their concurrent thread count is higher than that of medium-frequency ordinary accounts; Medium-frequency ordinary accounts use a request interval of 5-10 seconds, and their concurrent thread count is between that of high-frequency active accounts and low-frequency zombie accounts. Low-frequency zombie accounts use a request interval of 30-60 seconds, and their concurrent thread count is lower than that of medium-frequency ordinary accounts. Newly registered accounts use a complete first-time login process that includes verification code checking and initial password modification.

10. The offline data-driven login stress testing account construction and stress testing method as described in claim 1, characterized in that, In step S5, the data destruction process includes: Logical deletion steps: Delete the de-identified data tables, load testing scripts, and result report files in the local sandbox environment; Physical overwrite steps: Perform multiple overwrite operations on the storage medium storing pressure test related data. The multiple overwrite operations include writing all 0 data in the first round, writing all 1 data in the second round, and writing random 0 / 1 data in the third round. Cache cleanup steps: Clear relevant data from system memory cache, page file, and temporary directory.

Images