A method and apparatus for pre-compiling stress test data and generating parameters for securities business.

Abstract

This invention relates to the field of stress testing technology for securities software, and discloses a method, apparatus, equipment, and medium for pre-preparing stress test data and generating parameters for securities business. The method includes: constructing a three-layer mapping relationship of "interface-function number-data table"; obtaining the interface information to be stress tested according to the target stress test scenario; pre-preparing data based on the three-layer mapping relationship to obtain test data for multiple accounts; obtaining the core authentication credentials of each account concurrently using multi-threading based on the account information; encrypting the account information; and generating stress test parameters for each interface according to the target stress test scenario using the account information and core authentication credentials. By constructing a three-layer mapping relationship, the mapping of different peripheral systems to the core system data structure is realized, and multiple tasks are executed in parallel, ensuring that millions of accounts are put into stress testing within the validity period of the core authentication credentials, improving the data preparation efficiency and the validity of stress test data in the securities trading system, and reducing the overhead of stress testing resources.

Description

Technical Field

[0001] This invention relates to the field of stress testing technology for securities software, and specifically to a method and apparatus for pre-compiling stress test data and generating parameters for securities business. Background Technology

[0002] With the rapid development of internet securities trading, securities business systems need to maintain millisecond-level order response capabilities under high concurrency and high availability pressure. To verify the system's performance in real business scenarios, the testing team must perform end-to-end performance stress testing: writing business data close to the scale of real production, and generating authentication and encryption parameters that can be called by the stress testing script within a short period of time. Only when the three elements of "data integrity, parameter correctness, and speed are met simultaneously" can the stress test results have engineering guidance value.

[0003] Currently, the commonly used data pre-compilation method relies on manual creation of data using Structured Query Language (SQL) to complete the pre-compilation of business data. Database administrators (DBAs) write INSERT / DELETE statements one by one according to test cases, and execute them in batches in various business databases. The corresponding interface parameters are usually generated by maintaining static comma-separated values ​​(CSV) files or hard-coding variables in scripts. Testers first export a small number of sample accounts from the database, and then manually organize the CSV using Excel or a text editor. During load testing, the load testing script encrypts and authenticates the information of each account in real time, consuming resources from both the load generator and the system under test, resulting in the load not being effectively applied to the system under test. Due to the excessive time consumption, the core authentication credentials expire before the load is fully applied, causing the test to fail. The current data pre-compilation and parameter generation process mostly requires manual intervention, which has drawbacks such as long processing time, low efficiency, high error rate, poor scalability, and poor resource utilization. Summary of the Invention

[0004] In view of this, the present invention provides a method and apparatus for pre-preparing stress test data and generating parameters for securities business, so as to solve the problems of long time consumption, low efficiency, high error rate and poor scalability in the data pre-preparation and parameter generation process.

[0005] In a first aspect, the present invention provides a method for pre-compiling stress test data and generating parameters for securities business, the method comprising:

[0006] A three-layer mapping relationship of "interface-function number-data table" is constructed. The interface information to be tested is obtained according to the target load testing scenario. Data is pre-made based on the three-layer mapping relationship to obtain test data for multiple accounts.

[0007] Based on the account information, the core authentication credentials of each account are obtained concurrently using multi-threading. The account information is then encrypted, and load testing parameters for each interface are generated based on the target load testing scenario using the account information and the core authentication credentials.

[0008] The present invention provides a method for pre-preparing stress test data and generating parameters for securities business. By constructing a three-layer mapping relationship of "interface-function number-data table", it realizes the mapping of data structure of different peripheral systems of securities firms to the core system. The core authentication certificate generates encrypted parameters in parallel and automatically distributes them, ensuring that parameters are generated and put into stress test for millions of accounts within the validity period of the core authentication certificate. This solves the problems of long time consumption, error-proneness and short validity of core authentication certificates in traditional manual scripts. It significantly improves the data preparation efficiency and the validity of stress test data for millions of concurrent stress tests of securities trading systems. Moreover, the method of generating parameter files before stress test greatly reduces the overhead of stress test resources.

[0009] In one optional implementation, a three-tiered mapping relationship of "interface-function number-data table" is constructed, including:

[0010] Use the interface configuration file to map the interface's Uniform Resource Identifier to one or more function numbers;

[0011] The function number configuration file maps each function number to a business data table and the corresponding execution order of the structured query language.

[0012] Use data table configuration files to provide specific data manipulation language templates for each business data table.

[0013] In one optional implementation, data is prefabricated based on a three-layer mapping relationship to obtain test data for multiple accounts, including:

[0014] Based on the interface information to be stress tested, a batch structured query language is queried and assembled using a three-layer mapping relationship.

[0015] The execution data for each account is written according to the execution order of the structured query language, generating test data that matches the target load testing scenario.

[0016] The present invention provides a method for pre-compiling and generating load testing data for securities business. By accurately associating interfaces, functions and data tables through configuration files, it improves the flexibility and scalability of mapping. New interfaces can be added by simply supplementing the mapping and reusing the configuration. Batch assembly and sequential execution of SQL can quickly generate test data for multiple accounts, adapt to different load testing scenarios, solve the problem of inefficiency in manual data generation, ensure data and business logic matching, provide reliable, compliant and effective basic data support for end-to-end load testing, and improve the efficiency and quality of load testing preparation.

[0017] In one alternative implementation, the method further includes:

[0018] By using database snapshots or transaction logs, the test data can be rolled back to its pre-prepared state after the load test is completed.

[0019] The stress test data pre-production and parameter generation method for securities business provided by this invention provides one-click rollback capability by using database snapshots or transaction logs. It can quickly restore the test environment to the state before data pre-production, ensuring that the test environment can be reused, avoiding test data residue from interfering with subsequent tests, ensuring the purity and reusability of the environment, and eliminating the need for manual cleaning, thus greatly saving manpower and time costs.

[0020] In one optional implementation, core authentication credentials for each account are obtained concurrently using multi-threading based on account information. The account information is then encrypted, and load testing parameters for each interface are generated based on the target load testing scenario using the account information and core authentication credentials. This includes:

[0021] The first multi-threading is enabled to encrypt sensitive information of each account and to obtain and store the core authentication credentials corresponding to each account.

[0022] Enable the second multi-threading to add the account information and corresponding core authentication credentials to the parameterized plaintext request template of each interface to obtain the plaintext request of each account.

[0023] Encrypt plaintext requests from each account to generate ciphertext requests;

[0024] A unique request identifier is generated for each encrypted request, and client authentication credentials are generated based on the unique request identifier, interface name, and encrypted request. The unique request identifier and client authentication credentials form the message header information, and the encrypted request and message header information form the load testing parameters for the corresponding account.

[0025] In one optional implementation, the account information and corresponding core authentication credentials are added to the parameterized plaintext request template of each interface to obtain the plaintext request for each account, including:

[0026] Based on the parameterized plaintext request template of each interface, determine whether the plaintext request of each account requires counter authentication. If counter authentication is required, add the counter authentication credentials to the plaintext request to obtain the complete plaintext request.

[0027] The present invention provides a method for pre-compiling stress test data and generating parameters for securities business. For scenarios requiring counter authentication, it automatically calls services to inject dynamic identifiers, ensuring request compliance and making stress test parameters closely match real business logic. Furthermore, through templated and automated processes, it reduces manual configuration errors and improves parameter generation efficiency. This ensures that plaintext requests fully cover business scenarios and are compatible with system security checks, providing more realistic and effective data support for stress testing and facilitating accurate verification of system performance and compatibility.

[0028] In an optional implementation, the method further includes:

[0029] Generate interface stress test data based on the stress test parameters, and save the interface stress test data into a stress test file;

[0030] After compressing the load test files, distribute them to the load test nodes. At the same time, check if there are any unread interfaces. If so, return to the steps of generating load test parameters for each interface based on the target load test scenario using each account information and core authentication credentials, until all interfaces have been read.

[0031] The present invention provides a method for pre-compiling stress test data and generating parameters for securities business. By generating and storing stress test data according to interfaces, it achieves precise data and interface adaptation, improves the targeting of stress tests, compresses and distributes files to reduce transmission volume, accelerates data distribution, and continuously judges the interface reading status to ensure full interface coverage and avoid omissions. From data generation to distribution, it forms a closed loop, efficiently supporting the stress test process. It not only improves the efficiency of stress test preparation, but also enhances the effectiveness of stress test results in verifying system performance through precise adaptation and full coverage.

[0032] Secondly, this invention provides a stress test data pre-production and parameter generation device for securities business, the device comprising:

[0033] The data pre-processing module is used to construct a three-layer mapping relationship of "interface-function number-data table". It obtains the interface information to be tested according to the target load testing scenario, and performs data pre-processing based on the three-layer mapping relationship to obtain test data for multiple accounts.

[0034] The parameter generation module is used to obtain the core authentication credentials of each account concurrently using multi-threading based on the account information, encrypt the account information, and generate the load testing parameters of each interface based on the target load testing scenario using the account information and core authentication credentials.

[0035] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in the first aspect or any corresponding embodiment thereof.

[0036] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to perform the method described in the first aspect or any corresponding embodiment thereof. Attached Figure Description

[0037] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0038] Figure 1 This is a flowchart illustrating a method for pre-compiling stress test data and generating parameters for securities business according to an embodiment of the present invention.

[0039] Figure 2 This is a flowchart illustrating another method for pre-compiling stress test data and generating parameters for securities business according to an embodiment of the present invention.

[0040] Figure 3 This is a flowchart illustrating the data pre-production process in the stress test data pre-production and parameter generation method for securities business according to an embodiment of the present invention.

[0041] Figure 4 This is a flowchart illustrating the parameter generation process in the stress test data pre-production and parameter generation method for securities business according to an embodiment of the present invention.

[0042] Figure 5 This is a structural block diagram of a stress test data pre-production and parameter generation device for securities business according to an embodiment of the present invention.

[0043] Figure 6 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0045] This invention provides a method for pre-compiling stress test data and generating parameters for securities business. By constructing a three-layer mapping relationship of "interface-function number-data table" to pre-compile data, and using core authentication credentials to generate valid parameters in parallel encryption, the method aims to improve the efficiency of data preparation, reduce the error rate, and improve scalability in securities business stress testing.

[0046] According to an embodiment of the present invention, a method for pre-compiling stress test data and generating parameters for securities business is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0047] This embodiment provides a data pre-production and parameter generation method for securities business, which can be used in the aforementioned computer system. Figure 1 This is a flowchart of a stress test data pre-production and parameter generation method for securities business according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps:

[0048] Step S101: Construct a three-layer mapping relationship of "interface-function number-data table", obtain the interface information to be tested according to the target load testing scenario, and pre-compile data based on the three-layer mapping relationship to obtain test data for multiple accounts.

[0049] Specifically, the core trading systems of the securities business all provide services externally using function numbers. Different function numbers correspond to different businesses. Therefore, a three-layer mapping system of "interface-function number-data table" is constructed to establish a relationship model between interface requests and underlying data. First, the list of interfaces to be tested is determined based on the preset load testing scenarios (such as centralized trading, margin trading, etc.). Then, based on the mapping relationship, the required data tables and SQL templates are automatically located, and test data is generated in batches. This achieves automated mapping from business interfaces to underlying data, solves the problem of data preparation being disconnected from business scenarios in traditional load testing, and improves the matching degree between test data and actual business.

[0050] Step S102: Based on the account information, use multi-threaded concurrent acquisition of the core authentication credentials of each account, encrypt the account information, and generate the load testing parameters of each interface based on the target load testing scenario using the account information and core authentication credentials.

[0051] Specifically, multi-threading technology is used to process authentication and encryption tasks in parallel. Within the validity window of the core authentication credential (Ticket), the system concurrently calls the authentication service through a thread pool to obtain a large number of Tickets, and simultaneously encrypts the account information to generate cached data. The target interface is determined based on the target load testing scenario, and an appropriate number of accounts are selected. Through multi-threading, load testing parameters conforming to the specifications of each interface are generated concurrently based on the account information and corresponding core authentication credentials. An asynchronous parallel mechanism maximizes resource utilization, ensuring that millions of parameters are generated within the Ticket's validity period, thus solving the problem of excessively long parameter generation time leading to credential expiration in traditional load testing.

[0052] Retrieving account information and corresponding core authentication credentials directly from the cache reduces the process of repeatedly generating account information and corresponding core authentication credentials for different interfaces, saving time and resources. The generation process of load test parameters and the distribution process of load test files are executed separately and in parallel, accelerating the distribution speed.

[0053] The method for pre-compiling and generating stress test data for securities business provided in this embodiment realizes the mapping of data structures of different peripheral systems of securities firms to the core system by constructing a three-layer mapping relationship of "interface-function number-data table". The parallel encryption and automatic distribution of core authentication credentials ensures that parameters are generated and put into stress test for millions of accounts within the validity period of the core authentication credentials. This solves the problems of long time consumption, error-proneness and short validity of core authentication credentials in traditional manual scripts. It significantly improves the data preparation efficiency and the validity of stress test data for millions of concurrent stress tests of securities trading systems. Moreover, the method of generating parameter files before stress test greatly reduces the overhead of stress test resources.

[0054] This embodiment provides a method for pre-compiling stress test data and generating parameters for securities business, which can be used in the aforementioned computer system. Figure 2 This is a flowchart of a stress test data pre-production and parameter generation method for securities business according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps:

[0055] Step S201: Construct a three-layer mapping relationship of "interface-function number-data table", obtain the interface information to be tested according to the target load testing scenario, and pre-compile data based on the three-layer mapping relationship to obtain test data for multiple accounts.

[0056] Specifically, step S201 includes:

[0057] Step S2011: Use the interface configuration file to map the interface Uniform Resource Identifier to one or more function numbers.

[0058] Specifically, a mapping hierarchy is constructed using a three-level configuration file. The interface configuration file (uri.ini) is used to map the interface Uniform Resource Identifier (URI) to one or more function numbers (funcid), for example: / trade / stock / buy→F410503. This is just an example, but not a limitation.

[0059] Step S2012: Use the function number configuration file to map each function number to the business data table and the corresponding execution order of the structured query language.

[0060] Specifically, the function number configuration file (funcid.ini) further maps each function number to the business data table it involves and the corresponding execution order (sqlOrder) of the Structured Query Language. The ORDER BY statement is used to sort the result set, and by default, records are sorted in ascending order. ASC indicates ascending order (default), and DESC indicates descending order. For example: F410503→[t_account,t_position,t_order], the execution order is 1-SELECT, 2-DELETE, 3-INSERT. This is just an example, but it is not a limitation.

[0061] Step S2013: Use the data table configuration file to provide specific data manipulation language templates for each business data table.

[0062] Specifically, the data table configuration file (tables.ini) provides a specific data manipulation language template (such as INSERT / DELETE SQL template) for each business data table. For example: t_account → INSERT INTO t_accountVALUES(a,b,c), this is just an example, but not a limitation.

[0063] Step S2014: Based on the interface information to be stress tested, use the three-layer mapping relationship to query and assemble a batch structured query language.

[0064] Specifically, the system includes built-in hot topics such as "Top 16 Centralized Trading Strategies" and "Top 7 Margin Trading Strategies," while also allowing users to customize scenarios and calculate the account sampling range in real time to determine the list of interfaces to be stress-tested to meet different stress-testing objectives. After reading the list of interfaces to be stress-tested, the system first retrieves the corresponding function number in the interface configuration file, and then cascades the lookup of the function number configuration file and the data table configuration file. Based on the pre-built scenario (such as "100 active accounts"), the system parameterizes the SQL template: replacing placeholders in the SQL with scenario parameters (such as account range and fund threshold) (e.g., INSERT INTO t_account(acct_id,balance)VALUES('A001',10000)); and generating multiple SQL statements based on the scenario scale (e.g., generating 100 INSERT statements for 100 accounts).

[0065] When a new interface, function number, or data table is added, it is added to the three-tier mapping relationship, and the mapping relationship is updated. Adding a new interface only requires modifying the interface configuration file to add the mapping relationship, allowing reuse of content from the function number layer and data table layer without rewriting SQL logic, thus reducing redundant development.

[0066] Step S2015: Write the execution data of each account according to the execution order of the structured query language to generate test data that conforms to the target load testing scenario.

[0067] Specifically, the `sqlOrder` field in the function configuration file defines the execution order (e.g., writing to the account table first, then the transaction table). During data pre-processing, batch SQL statements are executed sequentially according to this order to ensure data integrity. The SQL execution order strictly matches the actual business process (e.g., "accounts must be opened before trading") to avoid "virtual transactions" caused by incorrect data writing order (e.g., records in the transaction table but no corresponding account in the account table). Foreign keys and unique indexes in the database are used to automatically verify data validity (e.g., triggering a unique index error when accounts are duplicated), ensuring consistency between test data and production environment data rules.

[0068] The method for pre-compiling and generating load testing data for securities business provided in this embodiment improves the flexibility and scalability of mapping by accurately associating interfaces, functions and data tables through configuration files. New interfaces can be reused by simply supplementing the mapping. Batch assembly and sequential execution of SQL can quickly generate test data for multiple accounts, adapt to different load testing scenarios, solve the problem of inefficiency in manual data generation, ensure data and business logic matching, provide reliable and compliant basic data support for end-to-end load testing, and improve the efficiency and quality of load testing preparation.

[0069] In one alternative implementation, the method further includes:

[0070] By using database snapshots or transaction logs, the test data can be rolled back to its pre-prepared state after the load test is completed.

[0071] Specifically, INSERT / DELETE statements are executed in batches according to the order defined in SQLOrder, and one-click rollback capability is provided with the help of database snapshots or transaction logs to ensure the reusability of the test environment. One-click rollback is suitable for minor changes, where DELETE-INSERT operations are executed in reverse order. For major changes, the database can be backed up directly. For example, if the execution order defined in SQLOrder is 1-SELECT, 2-DELETE, 3-INSERT, during data preparation, the execution order is 1-SELECT, 2-DELETE, 3-INSERT, 1-SELECT to ensure data integrity; during data rollback, the environment is restored in the order of 2-DELETE, 3-INSERT, 1-SELECT.

[0072] The stress test data pre-production and parameter generation method for securities business provided in this embodiment provides one-click rollback capability with the help of database snapshots or transaction logs. It can quickly restore the test environment to the state before data pre-production, ensuring that the test environment can be reused, avoiding test data residue from interfering with subsequent tests, ensuring the purity and reusability of the environment, and eliminating the need for manual cleaning, thus greatly saving manpower and time costs.

[0073] Step S202: Based on the account information, use multi-threaded concurrent acquisition of the core authentication credentials of each account, encrypt the account information, and generate the load testing parameters of each interface based on the target load testing scenario using the account information and core authentication credentials.

[0074] Specifically, step S202 includes:

[0075] Step S2021: Activate the first multi-threading to encrypt the sensitive information of each account and obtain and store the core authentication credentials corresponding to each account.

[0076] Specifically, the system initializes a multi-threaded pool (e.g., a default configuration of 64 threads). The first thread retrieves a list of accounts to be processed (including but not limited to sensitive fields such as account passwords and fund accounts) from a pre-built account database. Through parallel execution by multiple threads, the sensitive information of each account is encrypted using a preset encryption algorithm (e.g., SM4 algorithm), transforming it into ciphertext that cannot be directly parsed. Simultaneously, the system calls the authentication service interface to obtain core authentication credentials (e.g., Tickets) for each account in real time. The encrypted sensitive information + core authentication credentials are then temporarily stored in a memory cache (local Map) as key-value pairs, establishing a mapping between accounts, encrypted data, and authentication credentials to ensure rapid access to subsequent processes.

[0077] Step S2022: Enable the second multi-threading, add the account information and corresponding core authentication credentials to the parameterized plaintext request template of each interface, and obtain the plaintext request of each account.

[0078] Specifically, the second multi-threaded process loads parameterized plaintext request templates (including but not limited to fixed fields and placeholders) for the corresponding interfaces (e.g., transaction interfaces, query interfaces). It reads account information (including but not limited to encrypted sensitive information) and core authentication credentials from the memory cache, replacing placeholders in the template (e.g., account ID placeholders, Ticket placeholders). If the interface requires dynamic business parameters (e.g., transaction amount, order time), it fills in the parameters according to scenario rules (e.g., randomly generating a transaction amount range) to generate a complete plaintext request structure (conforming to the HTTP protocol or a business-specific protocol format). Each plaintext request is associated with a unique account identifier and temporarily stored in a queue awaiting encryption.

[0079] Step S2023: Encrypt the plaintext requests of each account to generate ciphertext requests.

[0080] Specifically, for plaintext requests in the encryption queue, the plaintext content is encrypted using a specified encryption algorithm (e.g., SM4) according to the system-configured encryption strategy (e.g., full-message encryption). If field-level encryption is used, sensitive fields in the request (e.g., transaction passwords, fund values) are precisely identified and encrypted; if full-message encryption is used, the entire request body is encrypted. After encryption, a Base64-encoded ciphertext request is generated, along with the encryption algorithm identifier and encryption timestamp, for server-side decryption verification, ensuring the security of request transmission.

[0081] Step S2024: Generate a unique request identifier for each encrypted request, and generate client authentication credentials based on the unique request identifier, interface name, and encrypted request. The unique request identifier and client authentication credentials form the message header information, and the encrypted request and message header information form the load testing parameters for the corresponding account.

[0082] Specifically, a Universally Unique Identifier (UUID) can be used to generate a globally unique ID (e.g., a 128-bit random character) for each encrypted request, marking the uniqueness of the request for use in tracing and log correlation. Combining the unique request identifier, the interface name (e.g., / api / trade / ptjy / zccx), and the hash value of the encrypted request, a client authentication credential (e.g., a signature string) is generated using a hash message authentication code algorithm. This credential is used by the server to verify request integrity and prevent tampering. The "unique request identifier + client authentication credential + encryption algorithm identifier" is encapsulated into a header, and the body is filled with the encrypted request content. Finally, according to the interface protocol (e.g., HTTP / HTTPS), the complete load testing parameters are combined into a single parameter (e.g., {header:{reqId:"xxx",sign:"xxx"},body:"encrypted request body"}). The encryption process is a mature existing technology and will not be elaborated here.

[0083] In this embodiment, the load testing parameters are the specific packet body and header information of the HTTPS protocol used during end-to-end load testing. These packets and headers are sent in a parameterized form via the load testing script. The user account information used in these packets is associated with the account in the pre-built data and, due to the time-sensitive nature of authentication information, must be regenerated and encrypted multiple times. The dynamic parameter generation in this patent emphasizes the dynamic generation of the packet body and header information used during load testing; these parameters do not change after the load test begins.

[0084] In an optional implementation, step S2022 involves adding each account's information and corresponding core authentication credentials to the parameterized plaintext request template of each interface to obtain the plaintext request for each account, including:

[0085] Based on the parameterized plaintext request template of each interface, determine whether the plaintext request of each account requires counter authentication. If counter authentication is required, add the counter authentication credentials to the plaintext request to obtain the complete plaintext request.

[0086] Specifically, the system pre-configures a "counter authentication required" flag in the interface parameterized template. For example, the switchKey selects the content to be included in the plaintext request. If the switchKey in the parameterized plaintext request template of a certain interface does not contain the specified field for counter authentication (such as a transaction receipt field), then counter authentication is not required, and there is no need to obtain a counter authentication certificate; otherwise, counter authentication is required. When the second multi-threaded process handles the plaintext request, it first determines whether counter authentication is required based on the switchKey. If not, it directly generates the plaintext request; if so, it calls the counter system's authentication interface, passing in basic account information (such as customer ID and fund account number), and obtains the counter authentication certificate (such as a temporary authorization code generated by the counter). This counter authentication certificate is then inserted into the specified field of the plaintext request (such as JYPJ), completing the counter authentication process and ensuring that the plaintext request complies with the multi-level authentication requirements of the business system, simulating the compliant call logic of real business.

[0087] The method for pre-compiling and generating load testing data for securities business provided in this embodiment automatically calls services to inject dynamic identifiers for scenarios requiring counter authentication. This ensures request compliance and makes load testing parameters closely match real business logic. Furthermore, through templated and automated processes, it reduces manual configuration errors and improves parameter generation efficiency. This ensures that plaintext requests fully cover business scenarios and are compatible with system security checks, providing more realistic and effective data support for load testing and helping to accurately verify system performance and compatibility.

[0088] In some optional implementations, the method further includes:

[0089] Step S2025: Generate interface stress test data based on the stress test parameters, and save the interface stress test data into a stress test file.

[0090] Specifically, encrypted parameters are temporarily stored in memory in key-value pairs to enable fast access and temporary management of parameters. The "key" corresponds to the unique identifier of the parameter (account ID), and the "value" contains the complete encrypted load testing parameters (such as encrypted requests, message header information, etc.), which facilitates data management by interface dimension.

[0091] Write the load test file (e.g., " / api / trade / ptjy / zccx.dat") corresponding to the interface according to a preset format (such as field separators and line break rules). For example, the preset format can be [unique identifier][client credential][encrypted request], which facilitates parsing by the load test nodes. Before writing the file, it is buffered through a memory queue to reduce disk I / O blocking and improve writing efficiency.

[0092] Step S2026: After compressing the load test file, distribute it to the load test nodes. At the same time, determine whether there are any unread interfaces. If so, return to the step of generating load test parameters for each interface based on the target load test scenario using each account information and core authentication credentials, until all interfaces have been read.

[0093] Specifically, the creation or update status of parameter storage files is captured in real time through a listening mechanism (e.g., file write completion signal). When the generation of parameter storage files for at least one interface is detected (e.g., " / api / trade / ptjy / zccx.dat" is created), the system immediately triggers the packaging process: for a single file generation event, the corresponding .dat file is directly compressed into a .zip package; if multiple interface files are generated simultaneously, multiple .dat files are compressed in parallel to reduce waiting time.

[0094] Layered compression is performed on the load test file (.dat), and the compressed load test file is downloaded in parallel by load test nodes through the distribution network, which reduces the bandwidth pressure on the central server and ensures that each node can quickly obtain the load test file for the corresponding interface.

[0095] While the current load test files are being compressed and distributed, it's crucial to determine if there are any unread interfaces. This can be done by marking the interface status bits to indicate whether an interface has been read. If any interfaces remain unread (e.g., the third interface in a transaction scenario is unprocessed), the process returns to the "Generate Load Test Parameters" step to reread the account, voucher, and other data for the next interface, ensuring full interface coverage. The status bits of read interfaces are recorded to avoid duplicate data generation and ensure iteration efficiency (e.g., if the process resumes after an interruption, only unread interfaces need to be processed).

[0096] The method for pre-compiling and generating load testing data for securities business provided in this embodiment utilizes memory storage and interface aggregation to make parameter management clear and orderly, adapt to multi-interface load testing scenarios, and ensure timely availability of parameters through event-driven file generation. It reduces redundant operations, automates the distribution process, improves the efficiency of load testing node parameter deployment, avoids human intervention errors, and makes load testing parameter preparation and transfer more efficient and accurate, thus facilitating the smooth execution of end-to-end load testing.

[0097] In one specific embodiment, such as Figure 3The figure shows a schematic flow diagram of the data prefabrication process. Taking the centralized trading TOP16 scenario as an example, testers select "Test Scenario - Trading TOP16" (simulating the high-frequency interface stress test scenario of the securities centralized trading business) through the system interface, and check "All 2.1 million accounts" as the stress test data coverage. After the system identifies the scenario, it automatically associates the list of interfaces to be stress tested for this scenario (such as 16 core interfaces like entrustment trading, order cancellation, query, etc.).

[0098] Retrieve the configuration file level by level according to "interface layer → function number layer → data surface layer":

[0099] Interface layer: Traverse the 16 interfaces of the "Trading TOP16" scenario (such as the entrustment trading interface / trade / order), and query the corresponding function number for each interface in the uri.ini file (such as the entrustment trading interface mapping funcid = 410503).

[0100] Function number layer: According to funcid = 410503, query the data table associated with this function number and the SQL execution order in the funcid.ini file (such as associating with the t_skasset table, and the execution order is select → delete → insert).

[0101] Data surface layer: According to the t_skasset table name, query the corresponding SQL template in the tables.ini file (such as INSERT INTO run.dbo.stkissue(serverid,market,stkcode,stkname,linkstk,issuetype,issuedate,fixprice,buyunit,minqty,maxqty,stkfullname)VALUES(1,'0','151990','19 Dahua 01',”,'1',20200101,100.000,10,10,10000,”)).

[0102] According to the prefabricated account range (2.1 million accounts), perform parameter substitution on the SQL template: Replace the "?" placeholder in the SQL template with actual account data such as acct_id (such as A00001) and available balance (such as 100000); Automatically generate dynamic parameters such as serial number (such as seq = 202507230001) and operation time (such as trade_time = 2025-07-23 09:00:00) to ensure that the data conforms to the business logic.

[0103] After generating the complete SQL, the system executes the SQL statements in batches according to the execution order defined in funcid.ini (e.g., first executing INSERT on the t_skasset table, then executing UPDATE on the related tables): INSERT statement: inserts basic data such as initial funds and holdings for 2.1 million accounts; UPDATE statement: simulates changes in account funds (e.g., deducting transaction commissions); SELECT statement: verifies the data insertion results to ensure data integrity.

[0104] For example Figure 4 The diagram shows the parameter generation process. Based on the scenario configuration, 2.1 million pre-stored accounts are selected as the load test data carrier. At the same time, the basic configurations such as the corresponding interface protocol specifications and encryption algorithms (e.g., SM4) are prepared to prepare for parameter generation.

[0105] Testers selected "Test Scenario - Margin Trading TOP7" in the system, a scenario focusing on stress testing of high-frequency interfaces in margin trading. The system responded to the scenario selection by selecting 2.1 million pre-stored accounts from the account pool that meet the characteristics of margin trading (such as accounts with margin trading permissions and historical transaction records) as the basic data carrier for parameter generation. Simultaneously, it loaded the protocol specifications, encryption algorithms (such as SM4), and parameterized plaintext request templates for the relevant margin trading interfaces, paving the way for subsequent processes.

[0106] The system initiates its first multi-threaded operation, performing two core tasks in parallel: (i) Multi-threaded calls via HTTP requests access mobile services to concurrently apply for core authentication credentials (Tickets) for 2.1 million accounts. Utilizing efficient thread pool scheduling, Ticket acquisition for a large number of accounts is rapidly completed within the valid Ticket duration (assuming 30 minutes), simulating high-frequency user login and authentication scenarios in real-world business, injecting legitimate identity identifiers into the parameters. (ii) SM4 encryption is simultaneously applied to sensitive account information (such as margin trading credit limits and collateral market value). Multi-threaded parallel processing transforms plaintext sensitive data into ciphertext, reducing the risk of data leakage. Simultaneously, this ciphertext is associated with the acquired Tickets and stored in memory (such as local or distributed cache) as key-value pairs, constructing a "Account-Encrypted Sensitive Information-Ticket" association to support subsequent parameter assembly.

[0107] Read the associated data "Account-Encrypted Sensitive Information-Ticket" from memory. Based on the parameterized plaintext request template selected in "Test Scenario-Margin Trading TOP7", initiate the business packet encryption process: (I) By interface dimension (such as margin trading interface, collateral query interface), replace the placeholders in the template (such as {account_id}{ticket}) with data such as account information and ticket to generate a prototype plaintext request that fits the margin trading business logic, covering fields such as transaction instructions and query conditions. (II) Determine whether the plaintext request requires counter authentication (such as margin trading contract signing confirmation interface). If authentication is required, call the counter service to inject counter authentication credentials (such as one-time authorization code) to improve the legality of the request. Afterwards, perform business packet encryption on the complete plaintext request (such as using national cryptographic algorithms for further encryption) to generate a preliminary ciphertext request and enhance the security of parameter transmission.

[0108] A second multi-threaded process is initiated to further process the initial encrypted requests: (i) A unique request identifier (e.g., UUID) is generated for each encrypted request. Combined with the interface name (e.g., "Margin Trading Interface") and the encrypted content, a client authentication credential is generated (e.g., a signature generated using the HMAC algorithm). The unique request identifier and client authentication credential are encapsulated into a message header and combined with the encrypted request body to form the basic structure of complete load testing parameters. (ii) The assembled parameters are stored in the corresponding .dat file (e.g., "Margin Trading Order Placement Interface.dat") according to the interface dimension. The system listens for .dat file generation events. When the complete generation of the file is detected, a compression process is triggered to package the .dat file into a .zip file (e.g., "Margin Trading Interface.zip"). Compression optimizes storage and transmission efficiency, preparing for distribution to subsequent load testing nodes.

[0109] The parameter generation process at the interface level is repeated until the .dat files for all interfaces (such as trading, querying, and order cancellation) covered in the "Test Scenario - Top 7 Margin Trading" are generated and packaged. The packaged .zip file is then distributed to the load testing nodes. The load testing nodes call the parameters in the file to simulate high-frequency operations of margin trading (such as batch order placement and real-time querying of collateral), verifying the system's performance, stability, and security in margin trading scenarios, and achieving end-to-end connectivity from parameter generation to load testing execution.

[0110] Through multi-threaded parallel processing, encrypted layered processing, and dynamic template adaptation, the system accurately simulates the real parameter generation and flow logic of margin trading and securities lending businesses, providing realistic, safe, and compliant test data for stress testing, and helping to discover potential performance bottlenecks and business risks in the system.

[0111] Compared with traditional methods, the stress test data pre-production and parameter generation method for securities business provided in this embodiment of the invention has improved in all indicators, as detailed in Table 1.

[0112] Table 1

[0113]

[0114] This embodiment also provides a stress test data pre-production and parameter generation device for securities business. This device is used to implement the above embodiments and preferred embodiments, and will not be repeated for details already described. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0115] This embodiment provides a device for pre-compiling stress test data and generating parameters for securities business, such as... Figure 5 As shown, it includes:

[0116] The data pre-processing module 501 is used to construct a three-layer mapping relationship of "interface-function number-data table". It obtains the interface information to be tested according to the target load testing scenario, and performs data pre-processing based on the three-layer mapping relationship to obtain test data for multiple accounts.

[0117] The parameter generation module 502 is used to obtain the core authentication credentials of each account concurrently using multi-threading based on the account information, encrypt the account information, and generate the load test parameters of each interface based on the target load test scenario using the account information and core authentication credentials.

[0118] In some alternative implementations, the data prefabrication module 501 includes:

[0119] The interface mapping unit is used to map the interface Uniform Resource Identifier to one or more function numbers using the interface configuration file.

[0120] The function number mapping unit is used to map each function number to a business data table and the corresponding execution order of the structured query language using the function number configuration file.

[0121] The data table mapping unit is used to provide specific data manipulation language templates for each business data table using data table configuration files.

[0122] The data query unit is used to query and assemble batch structured query language based on the interface information to be stress tested using a three-layer mapping relationship.

[0123] The data writing unit is used to write the execution data of each account according to the execution order of the structured query language, and generate test data that conforms to the target load testing scenario.

[0124] In some alternative implementations, the parameter generation module 502 includes:

[0125] The first multi-threaded activation unit is used to enable the first multi-threaded operation, encrypt sensitive information of each account, and obtain and store the core authentication credentials corresponding to each account.

[0126] The second multi-threading activation unit is used to enable the second multi-threading, adding each account's information and corresponding core authentication credentials to the parameterized plaintext request template of each interface to obtain the plaintext request for each account.

[0127] The encryption unit is used to encrypt plaintext requests from each account and generate ciphertext requests.

[0128] The load testing parameter generation unit is used to generate a unique request identifier for each encrypted request, and generate client authentication credentials based on the unique request identifier, interface name, and encrypted request. The unique request identifier and client authentication credentials form the message header information, and the encrypted request and message header information form the load testing parameters for the corresponding account.

[0129] In some optional implementations, the parameter generation module 502 further includes:

[0130] The load test data storage unit is used to generate interface load test data based on the load test parameters and store the interface load test data into a load test file.

[0131] The load test file distribution unit is used to compress the load test file and distribute it to the load test nodes. At the same time, it determines whether there are any unread interfaces. If there are, it returns the steps of generating load test parameters for each interface based on the target load test scenario using each account information and core authentication credentials, until all interfaces have been read.

[0132] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0133] In this embodiment, the stress test data pre-production and parameter generation device for securities business is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0134] This invention also provides a computer device having the above-described features. Figure 5 The device shown is for pre-compiling stress test data and generating parameters for securities business.

[0135] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 6As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 6 Take a processor 10 as an example.

[0136] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0137] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0138] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0139] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0140] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0141] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0142] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for pre-compiling stress test data and generating parameters for securities business, characterized in that, The method includes: A three-layer mapping relationship of "interface-function number-data table" is constructed. Based on the target load testing scenario, the interface information to be tested is obtained, and data is pre-built based on the three-layer mapping relationship to obtain test data for multiple accounts. This includes: mapping the interface's Uniform Resource Identifier (URI) to one or more function numbers using the interface configuration file; mapping each function number to a business data table and the corresponding execution order of the Structured Query Language (SCL) using the function number configuration file; providing specific data manipulation language templates for each business data table using the data table configuration file; querying and assembling batch SCLs based on the interface information to be tested using the three-layer mapping relationship; and writing the execution data of each account according to the execution order of the SCLs to generate test data that conforms to the target load testing scenario. Based on the account information, the core authentication credentials of each account are obtained concurrently using multi-threading. The account information is then encrypted, and load testing parameters for each interface are generated based on the target load testing scenario using the account information and the core authentication credentials.

2. The method according to claim 1, characterized in that, The method further includes: By using database snapshots or transaction logs, the test data can be rolled back to its pre-prepared state after the load test is completed.

3. The method according to claim 1, characterized in that, Based on the account information, core authentication credentials for each account are obtained concurrently using multi-threading. The account information is then encrypted. Based on the target load testing scenario, load testing parameters for each interface are generated using the account information and core authentication credentials, including: The first multi-threading is enabled to encrypt sensitive information of each account and to obtain and store the core authentication credentials corresponding to each account. Enable the second multi-threading to add the account information and corresponding core authentication credentials to the parameterized plaintext request template of each interface to obtain the plaintext request of each account. Encrypt plaintext requests from each account to generate ciphertext requests; A unique request identifier is generated for each encrypted request, and client authentication credentials are generated based on the unique request identifier, interface name, and encrypted request. The unique request identifier and client authentication credentials form the message header information, and the encrypted request and the message header information form the load testing parameters for the corresponding account.

4. The method according to claim 3, characterized in that, Add the account information and corresponding core authentication credentials to the parameterized plaintext request template of each interface to obtain the plaintext request for each account, including: Based on the parameterized plaintext request template of each interface, determine whether the plaintext request of each account requires counter authentication. If counter authentication is required, add the counter authentication credentials to the plaintext request to obtain the complete plaintext request.

5. The method according to claim 3, characterized in that, The method further includes: The interface stress test data is generated based on the stress test parameters, and the interface stress test data is stored in the stress test file; The load test file is compressed and distributed to the load test nodes. At the same time, it is determined whether there are any unread interfaces. If there are, the process returns to the step of generating load test parameters for each interface based on the target load test scenario using each account information and core authentication credentials, until all interfaces have been read.

6. A device for pre-compiling stress test data and generating parameters for securities business, characterized in that, The device includes: The data pre-processing module is used to construct a three-layer mapping relationship of "interface-function number-data table". It obtains the interface information to be tested according to the target load testing scenario, and performs data pre-processing based on the three-layer mapping relationship to obtain test data for multiple accounts. The parameter generation module is used to obtain the core authentication credentials of each account using multi-threaded concurrency based on the account information, encrypt the account information, and generate the load testing parameters of each interface based on the target load testing scenario using the account information and core authentication credentials. The data pre-production module includes: The interface mapping unit is used to map the interface Uniform Resource Identifier to one or more function numbers using the interface configuration file. The function number mapping unit is used to map each function number to a business data table and the corresponding execution order of the structured query language using the function number configuration file; The data table mapping unit is used to provide specific data manipulation language templates for each business data table using the data table configuration file. The data query unit is used to query and assemble batch structured query language based on the interface information to be stress tested using a three-layer mapping relationship; The data writing unit is used to write the execution data of each account according to the execution order of the structured query language, and generate test data that conforms to the target load testing scenario.

7. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the method of any one of claims 1 to 5.

Images