Security business-oriented pressure measurement data prefabrication and parameter generation method and device

Abstract

The invention relates to the technical field of security software pressure measurement, and discloses a security business-oriented pressure measurement data prefabrication and parameter generation method and device, equipment and a medium, and the method comprises the steps: constructing an interface-function number-data table three-layer mapping relation, obtaining the information of an interface to be subjected to pressure measurement according to a target pressure measurement scene, performing data prefabrication based on the three-layer mapping relation to obtain test data of a plurality of accounts; according to the account information, core authentication certificates of all the accounts are concurrently obtained through multiple threads, the account information is encrypted, and pressure measurement parameters of all the interfaces are generated through the account information and the core authentication certificates according to the target pressure measurement scene. By constructing a three-layer mapping relation, mapping and multi-task parallel execution of different peripheral systems on a core system data structure are achieved, it is ensured that million-level accounts are put into pressure measurement within the validity period of a core authentication certificate, the data preparation efficiency and the pressure measurement data validity of a security transaction system are improved, and the overhead of pressure sending resources is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of securities software stress testing, and particularly relates to a stress testing data preparation and parameter generation method and device for securities business. BACKGROUND

[0002] With the rapid development of Internet securities trading, securities business systems need to maintain millisecond-level order response capability under high concurrency and high availability stress. To verify the performance of the system in a real business scenario, the test team must perform full-link performance stress testing: not only close to real production scale business data is written, but also authentication parameters and encryption parameters that can be called by the stress testing script are generated in a short time. Only when the three elements of "complete data, correct parameters, and fast speed" are met, the stress testing result has engineering guidance value.

[0003] The commonly used data preparation method at present is to complete the preparation of business data by relying on manual Structured Query Language (SQL) data generation. Database administrators (DBA) write INSERT / DELETE statements one by one according to test cases, and execute them in batches in each business database. The corresponding interface parameters are usually generated by maintaining static Comma-Separated Values (CSV) files or hardcoding 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 stress testing, the stress testing script encrypts and authenticates the account information in real time, which occupies the stress testing resources and the system under test resources, resulting in the stress not being effectively applied to the system under test. The core authentication credentials expire and become invalid before the entire stress test is completed, resulting in test failure. The current data preparation and parameter generation process mostly requires manual intervention, and has the defects of long time consumption, low efficiency, high error rate, poor scalability, and poor resource utilization. SUMMARY

[0004] Therefore, the present application provides a stress testing data preparation and parameter generation method and device for securities business to solve the problems of long time consumption, low efficiency, high error rate, and poor scalability in the data preparation and parameter generation process.

[0005] In a first aspect, the present application provides a stress testing data preparation and parameter generation method for securities business, which comprises:

[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 stress testing scenario, and data preparation is performed based on the three-layer mapping relationship to obtain test data of a plurality of accounts;

[0007] According to the account information, core authentication credentials of each account are obtained by using multi-thread concurrent, the account information is encrypted, and the core authentication credentials and the account information are used to generate stress test parameters of each interface according to a target stress test scene.

[0008] The method for preparing stress test data and generating parameters for securities business provided by the application realizes the mapping of different systems of securities companies to the data structure of the core system, parallel encryption parameter generation and automatic distribution of core authentication credentials, ensures that million-level accounts generate parameters and are put into stress test within the validity period of the core authentication credentials, solves the problems of long time consumption, easy error and short-time validity of core authentication credentials of traditional manual scripts, significantly improves the data preparation efficiency and validity of million-level concurrent stress test of securities trading systems, and greatly reduces the cost of stress test resources in the form of generating parameter files before stress test.

[0009] In an optional embodiment, the three-layer mapping relationship of "interface-function number-data table" is constructed, including:

[0010] The interface uniform resource identifier is mapped to one or more function numbers by using the interface configuration file;

[0011] Each function number is mapped to a business data table and a corresponding structured query language execution order by using a function number configuration file;

[0012] A specific data manipulation language template is provided for each business data table by using a data table configuration file.

[0013] In an optional embodiment, the data preparation is performed based on the three-layer mapping relationship to obtain test data of multiple accounts, including:

[0014] According to the to-be-stressed interface information, batch structured query languages are queried and assembled by using the three-layer mapping relationship;

[0015] Execution data of each account is written according to the execution order of the structured query language to generate test data conforming to the target stress test scene.

[0016] The method for preparing stress test data and generating parameters for securities business provided by the application accurately associates interfaces, functions and data tables through configuration files, improves mapping flexibility and scalability, newly added interfaces can be reused by supplementing mapping, batch assembly and sequential execution of SQL can quickly generate multi-account test data, adapt to different stress test scenes, solve the problem of low efficiency of manual data generation, ensure the matching of data and business logic, provide reliable, compliant and effective basic data support for full-link stress test, and improve the preparation efficiency and quality of stress test.

[0017] In an optional embodiment, the method further includes:

[0018] With the database snapshot or transaction log function, after the stress test is completed, the test data is rolled back to the state before the data preparation.

[0019] The stress test data preparation and parameter generation method for securities business provided by the application provides one-key rollback capability with the help of the database snapshot or transaction log, can quickly restore the test environment to the state before the data preparation, ensures the reusability of the test environment, avoids the interference of the test data on the subsequent test, guarantees the purity and reusability of the environment, and does not need manual cleaning, greatly saves the labor and time cost.

[0020] In an optional implementation, the core authentication credentials of each account are obtained in a multi-threaded manner according to the account information, the account information is encrypted, and the stress test parameters of each interface are generated according to the target stress test scenario and the account information and the core authentication credentials, including:

[0021] The sensitive information of each account is encrypted and the core authentication credentials corresponding to each account are obtained and stored by starting the first multi-thread;

[0022] The account information and the corresponding core authentication credentials are added to the parameterized plaintext request template of each interface by starting the second multi-thread to obtain the plaintext request of each account;

[0023] The plaintext request of each account is encrypted to generate a ciphertext request;

[0024] A unique request identifier is generated for each ciphertext request, and a client authentication credential is generated according to the unique request identifier, the interface name and the ciphertext request, the unique request identifier and the client authentication credential constitute the message header information, and the ciphertext request and the message header information constitute the stress test parameters of the corresponding account.

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

[0026] It is judged whether the plaintext request of each account needs a counter authentication according to the parameterized plaintext request template of each interface, if the counter authentication is needed, the counter authentication credential is added to the plaintext request to obtain a complete plaintext request.

[0027] The stress test data preparation and parameter generation method for securities business provided by the application automatically calls the service injection dynamic identifier for the scene needing counter authentication, which not only guarantees the compliance of the request and makes the stress test parameters fit the real business logic, but also reduces the manual configuration errors through the templating and automatic process, improves the parameter generation efficiency, makes the plaintext request not only completely cover the business scene, but also adapt to the system security verification, provides more real and effective data support for the stress test, and helps to accurately verify the 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] In order to more clearly illustrate the technical solutions in the specific embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the specific embodiments or the prior art description. Obviously, the drawings described below are some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0038] Figure 1 is a flowchart of a securities business-oriented stress testing data preparation and parameter generation method according to an embodiment of the present application;

[0039] Figure 2 is a flowchart of another securities business-oriented stress testing data preparation and parameter generation method according to an embodiment of the present application;

[0040] Figure 3 is a flowchart of a data preparation process in a securities business-oriented stress testing data preparation and parameter generation method according to an embodiment of the present application;

[0041] Figure 4 is a flowchart of a parameter generation process in a securities business-oriented stress testing data preparation and parameter generation method according to an embodiment of the present application;

[0042] Figure 5 is a structural block diagram of a securities business-oriented stress testing data preparation and parameter generation device according to an embodiment of the present application;

[0043] Figure 6 is a hardware structure schematic diagram of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION

[0044] In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0045] The embodiments of the present application provide a securities business-oriented stress testing data preparation and parameter generation method, which prepares data by constructing a three-layer mapping relationship of "interface-function number-data table", and generates valid parameters by parallel encryption using core authentication credentials, so as to improve the data preparation efficiency in securities business stress testing, reduce the error rate, and improve the expansibility.

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

[0047] In this embodiment, a method for pre-preparing stress test data and generating parameters for securities business is provided, which can be used in the computer system described above, Figure 1 The flowchart of the method for pre-preparing stress test data and generating parameters for securities business according to the embodiment of the present application is shown in FIG. 1, which includes the following steps: Figure 1

[0048] In step S101, 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 stress test scenario, and the test data of multiple accounts is obtained by data pre-preparation based on the three-layer mapping relationship.

[0049] Specifically, the core transaction system of securities business provides services outside by function number, different function numbers correspond to different businesses, so by constructing a three-layer mapping system of "interface-function number-data table", an association model of interface request and underlying data is established. First, the interface list to be tested is determined according to the preset stress test scenario (such as concentrated transaction, financing and securities, etc.), and then the required data table and SQL template are automatically located based on the mapping relationship, and the test data is generated in batches. The automatic mapping from business interface to underlying data is realized, the problem of disconnection between data preparation and business scenario in traditional stress test is solved, and the matching degree of test data and actual business is improved.

[0050] In step S102, the core authentication credentials of each account are obtained by using multi-threading and concurrency according to the account information, the account information is encrypted, and the stress test parameters of each interface are generated according to the target stress test scenario by using the account information and the core authentication credentials.

[0051] Specifically, multi-threading technology is used to process authentication and encryption tasks in parallel. The system concurrently calls the authentication service to obtain a large number of Tickets within the effective time window of the core authentication credentials (Ticket), and synchronously encrypts the account information to generate cache data. According to the target stress test scenario, the target interface is determined, and the appropriate number of accounts is selected. According to the account information and the corresponding core authentication credentials, the stress test parameters conforming to the specifications of each interface are generated by using multi-threading and concurrency. Through the asynchronous parallel mechanism, the resource utilization rate is maximized, ensuring that the generation of millions of parameters is completed within the validity period of the Ticket, and solving the problem of long parameter generation time leading to invalidation of the credentials in traditional stress test.

[0052] ​Directly obtain each account information and corresponding core authentication credential from the cache, reduce the process of repeatedly generating account information and corresponding core authentication credential of different interfaces, save time and resources, and separate and execute the generation process of stress test parameters in parallel with the distribution process of stress test files, thereby accelerating the distribution speed.

[0053] The securities business-oriented stress test data preparation and parameter generation method provided in the embodiment realizes the mapping of the data structure of the core system by different systems of the securities company to the core system, parallel encryption parameter generation and automatic distribution of the core authentication credential, ensures that the million-level account generates parameters and is put into stress test within the validity period of the core authentication credential, solves the problems of long time consumption, easy error and short-time validity of the core authentication credential of the traditional manual script, and significantly improves the data preparation efficiency and stress test data effectiveness of the million-level concurrent stress test of the securities trading system.

[0054] In the embodiment, a securities business-oriented stress test data preparation and parameter generation method is provided, which can be used in the computer system described above, Figure 2 is a flowchart of the securities business-oriented stress test data preparation and parameter generation method according to the embodiment of the application, as shown in the figure, the flowchart comprises the following steps: Figure 2

[0055] In step S201, 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 stress test scene, and data preparation is performed based on the three-layer mapping relationship to obtain the test data of a plurality of accounts.

[0056] Specifically, the above step S201 comprises:

[0057] In step S2011, an interface uniform resource identifier is mapped to one or more function numbers by using an interface configuration file.

[0058] Specifically, a mapping level is constructed by using a three-level configuration file, an interface configuration file (uri.ini) is used to map an interface uniform resource identifier (Uniform Resource Identifier, URI) to one or more function numbers (funcid), for example: / trade / stock / buy→F410503, which is only an example and is not limited thereto.

[0059] In step S2012, each function number is mapped to a business data table and an execution order of a corresponding structured query language by using a function number configuration file.

[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 of the structured query language (sqlOrder), and the ORDER BY statement is used to sort the result set, with the records sorted in ascending order by default, with ASC indicating ascending order (default) and DESC indicating descending order. For example: F410503→[t_account, t_position, t_order], with the execution order being 1-SELECT, 2-DELETE, and 3-INSERT, which are merely examples and are not limited thereto.

[0061] In step S2013, the data table configuration file is used to provide specific data manipulation language templates for each business data table.

[0062] Specifically, the data table configuration file (tables.ini) is used to provide specific data manipulation language templates (such as INSERT / DELETE SQL templates) for each business data table. For example: t_account→INSERT INTO t_account VALUES(a, b, c), which are merely examples and are not limited thereto.

[0063] In step S2014, the three-layer mapping relationship is used to query and assemble batch structured query languages according to the to-be-stressed interface information.

[0064] Specifically, hot scenes such as “centralized transaction TOP16” and “financing and securities lending TOP7” are built in, and users are allowed to customize scenes and calculate account sampling ranges in real time to determine the to-be-stressed interface list to meet different stress testing goals. After reading the to-be-stressed interface list, the corresponding function number is searched in the interface configuration file, and then the function number configuration file and the data table configuration file are found in cascade. According to the pre-prepared scene (such as “100 active accounts”), the system performs parameterization processing on the SQL template: the scene parameters (such as account range and fund threshold) are replaced with placeholders in the SQL (for example: INSERT INTO t_account(acct_id, balance) VALUES('A001', 10000)); according to the scene size, multiple SQLs are generated (for example, 100 INSERT statements are generated for 100 accounts).

[0065] When a new interface or a new function number or a new data table is added, the new interface or the new function number or the new data table is added to the three-layer mapping relationship, and the three-layer mapping relationship is updated. For adding a new interface, only the mapping relationship needs to be modified in the interface configuration file, and the contents in the function number layer and the data table layer can be reused without rewriting the SQL logic, thereby reducing repeated development.

[0066] Step S2015, write the execution data of each account according to the execution order of the structured query language, and generate test data that meets the target stress testing scenario.

[0067] Specifically, the sqlOrder field in the function number configuration file defines the execution order (for example, write the account table first, and then write the transaction table), and in the data preparation process, the batch SQL is executed in series according to the execution order to ensure data integrity. The SQL execution order strictly matches the actual business process (for example, "open an account before trading"), avoiding "virtual transactions" (such as transaction table records but no corresponding account table) caused by incorrect data write order; using the foreign key, unique index and other mechanisms of the database, the data legality is automatically checked (such as triggering a unique index error when the account number is repeated), ensuring the consistency of test data and production environment data rules.

[0068] The securities business-oriented stress testing data preparation and parameter generation method provided in the embodiment precisely associates interfaces, functions and data tables through configuration files, improves mapping flexibility and scalability, and can quickly generate multi-account test data by supplementing mapping for new interfaces and reusing configuration, batch assembling and executing SQL in order, adapt to different stress testing scenarios, solve the problem of low efficiency of manual data generation, ensure data and business logic matching, provide reliable and compliant basic data support for full-link stress testing, and improve stress testing preparation efficiency and quality.

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

[0070] Using the database snapshot or transaction log function, the test data is rolled back to the state before data preparation after the stress testing is completed.

[0071] Specifically, the INSERT / DELETE statements are executed in batches according to the order defined in sqlOrder, and one-key rollback capability is provided with the help of database snapshots or transaction logs to ensure that the test environment can be reused, and one-key rollback is suitable for small changes and reverse execution of DELETE-INSERT operations. For large changes, the database can be directly backed up. For example, the execution order defined in sqlOrder is 1-SELECT, 2-DELETE, 3-INSERT, and during data preparation, 1-SELECT, 2-DELETE, 3-INSERT, and 1-SELECT are executed in sequence to ensure data integrity; during data rollback, 2-DELETE, 3-INSERT, and 1-SELECT are executed in sequence to restore the environment.

[0072] The security business-oriented stress test data pre-fabrication and parameter generation method provided by the embodiment can provide one-key rollback capability with the help of database snapshots or transaction logs, can quickly restore the test environment to the state before data pre-fabrication, ensure that the test environment can be reused, avoid test data residue interference on subsequent tests, guarantee the environment purity and reusability, and does not need manual cleaning, thereby greatly saving manpower and time cost.

[0073] In step S202, the core authentication credentials of each account are obtained by using multi-threading in parallel according to the account information, the account information is encrypted, and the stress test parameters of each interface are generated according to the target stress test scene by using the account information and the core authentication credentials.

[0074] Specifically, the above step S202 includes:

[0075] In step S2021, a first multi-threading is enabled, the sensitive information of each account is encrypted, and the core authentication credentials corresponding to each account are obtained and stored.

[0076] Specifically, the system initializes a multi-threading pool (for example, a default 64-thread configuration), and the first multi-threading pulls a list of accounts to be processed (including but not limited to account password, fund account, and other sensitive fields) from an account pre-fabrication library. By using multi-threading in parallel, the sensitive information of each account is encrypted according to a preset encryption algorithm (for example, SM4 algorithm) to convert into ciphertext that cannot be directly parsed. At the same time, an authentication service interface is called to obtain the core authentication credentials (for example, Ticket) for each account in real time, and the “encrypted sensitive information + core authentication credentials” are temporarily stored in the form of key-value pairs in the memory cache (local Map) to establish an association mapping between the account and the encrypted data and the authentication credentials, thereby ensuring that the subsequent process can be quickly called.

[0077] In step S2022, a second multi-threading is enabled, and each account information and the corresponding core authentication credentials are added to the parameterized plaintext request template of each interface to obtain the plaintext request of each account.

[0078] Specifically, the second multi-threading loads the parameterized plaintext request template (including but not limited to interface fixed fields and placeholders) of the corresponding interface according to the interface dimension (for example, transaction interface, query interface). The account information (including but not limited to encrypted sensitive information) and the core authentication credentials are read from the memory cache to replace the placeholders (for example, account ID placeholder and Ticket placeholder) in the template. If the interface requires dynamic business parameters (for example, transaction amount and commission time), the scene rules (for example, randomly generating a transaction amount interval) are filled to generate a complete plaintext request structure (in the format of HTTP protocol or business private protocol), and each plaintext request is associated with a unique account identifier and temporarily stored in a queue to be encrypted.

[0079] Step S2023, the plaintext request of each account is encrypted to generate a ciphertext request.

[0080] Specifically, for the plaintext request in the encryption queue, the plaintext content is encrypted and converted using a specified encryption algorithm (such as the SM4 algorithm) according to the system configured encryption strategy (such as full message encryption). If it is field-level encryption, the sensitive fields in the request (such as transaction password, fund value) are accurately identified and encrypted; if it is full message encryption, the entire request body is encrypted. After encryption, a Base64 encoded ciphertext request is generated, and the encryption algorithm identifier and encryption timestamp are recorded for server decryption verification to ensure the security of request transmission.

[0081] Step S2024, a unique request identifier is generated for each ciphertext request, and a client authentication credential is generated according to the unique request identifier, interface name, and ciphertext request. The unique request identifier and the client authentication credential constitute the message header information, and the ciphertext request and the message header information constitute the pressure test parameters of the corresponding account.

[0082] Specifically, a Universally Unique Identifier (UUID) can be used to generate a globally unique ID (such as 128-bit random characters) for each ciphertext request to mark the uniqueness of the request for link tracking and log association. Combined with the unique request identifier, interface name (such as / api / trade / ptjy / zccx), and hash value of the ciphertext request, a client authentication credential (such as a signature string) is generated through a hash message authentication code algorithm for server to check request integrity and prevent tampering. The "unique request identifier + client authentication credential + encryption algorithm identifier" is encapsulated as message header (header) information, and the message body (body) is filled with ciphertext request content. Finally, according to the interface protocol (such as HTTP / HTTPS) format, the complete pressure test parameters (such as {header:{reqId:"xxx",sign:"xxx"},body:"encrypted request body"}) are combined. The encryption process is a mature existing technology and will not be described here.

[0083] The pressure test parameters in this embodiment are the specific packet body messages and header information of the https protocol used in full link pressure testing. The messages and headers are sent in a parameterized form through the pressure test script. The user account information used in the message is associated with the account in the data preparation, and because of the timeliness of the authentication information, it must be regenerated and encrypted multiple times. The dynamic parameter generation of this patent emphasizes the dynamic generation of the packet body messages and header information used in the pressure test process. These parameters do not change after the pressure test starts.

[0084] In an optional embodiment, the account information and the corresponding core authentication credential are added to the parameterized plaintext request template of each interface in step S2022 to obtain the plaintext request of each account, including:

[0085] It is determined according to the parameterized plaintext request template of each interface whether the plaintext request of each account needs to be authenticated at the counter, and if so, the counter authentication credential is added to the plaintext request to obtain a complete plaintext request.

[0086] Specifically, the system pre-configures an identifier of “whether counter authentication is needed” in the interface parameterization template, for example, by selecting the content contained in the plaintext request through switchKey. When the specified field (for example, the transaction ticket field) of the counter authentication is not contained in the switchKey in the parameterized plaintext request template of a certain interface, the counter authentication is not needed, and the counter authentication credential does not need to be obtained. Otherwise, the counter authentication is needed. When the second multi-threaded process is processing the plaintext request, it is first determined whether the counter authentication is needed according to the switchKey. If not, the plaintext request is directly generated. If so, the authentication interface of the counter system is called, and the account basic information (for example, the customer ID and the fund account) is input to obtain the counter authentication credential (for example, the temporary authorization code generated by the counter). The counter authentication credential is inserted into the specified field (for example, JYPJ) of the plaintext request to complete the counter authentication process, ensure that the plaintext request meets the multi-level authentication requirements of the business system, and simulate the compliance calling logic of the real business.

[0087] The securities business-oriented pressure test data preparation and parameter generation method provided in this embodiment automatically calls the service injection dynamic identifier for the scene needing counter authentication, which not only ensures the compliance of the request and makes the pressure test parameters fit the real business logic, but also reduces the manual configuration errors through the template and automatic process, improves the parameter generation efficiency, makes the plaintext request not only completely cover the business scene, but also adapt to the system security check, provides more real and effective data support for the pressure test, and helps to accurately verify the system performance and compatibility.

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

[0089] In step S2025, the interface pressure test data is generated according to the pressure test parameters, and the interface pressure test data is stored in the pressure test file.

[0090] Specifically, the encrypted parameters are temporarily stored in the memory in the form of key-value pairs, which is to realize the quick access and temporary management of the parameters. The “key” corresponds to the unique identifier (account ID) of the parameter, and the “value” contains the complete pressure test parameters after encryption (for example, encrypted requests, message header information, etc.), which facilitates data management according to the interface dimension.

[0091] Write the pressure test file corresponding to the interface (for example, " / api / trade / ptjy / zccx.dat") in the preset format (such as field separator, line feed rule), for example, the preset format can be [unique identifier] [client certificate] [encrypted request], which is convenient for the pressure test node to parse. Before writing the file, first buffer through the memory queue to reduce disk input / output blocking and improve writing efficiency.

[0092] In step S2026, the compressed pressure test file is distributed to the pressure test node, and it is judged whether there is an unread interface. If there is, the step of generating pressure test parameters of each interface according to the target pressure test scene using each account information and core authentication certificate is returned until all interfaces are read.

[0093] Specifically, the creation or update state of the parameter storage file (for example, file writing completion signal) is captured in real time through a listening mechanism. When it is monitored that the parameter storage file of at least one interface is generated (for example, " / 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 monitored at the same time, multiple.dat files are compressed in parallel to reduce waiting time.

[0094] The pressure test file (.dat) is compressed in layers, and the pressure test node is allowed to download the compressed pressure test file in parallel through a distribution network, so as to reduce the bandwidth pressure of the central server and ensure that each node can quickly obtain the pressure test file of the corresponding interface.

[0095] While the current pressure test file is compressed and distributed, it is judged whether there is an unread interface. The interface state bit can be used to mark whether the interface is read. If there is an unread interface (for example, the third interface of the transaction scene is not processed), the step of "generating pressure test parameters" is returned, and the account, certificate and other data of the next interface are read again to ensure full interface coverage. The state bit of the read interface is recorded to avoid repeated data generation and ensure iteration efficiency (for example, after interruption, only the unread interface needs to be processed).

[0096] The pressure test data preparation and parameter generation method for securities business provided in the embodiment uses memory staging and interface aggregation to make parameter management clear and orderly, adapt to multiple interface pressure test scenes, drive packaging through file generation events, ensure timely availability of parameters, reduce redundant operations, automate distribution processes, improve pressure test node parameter deployment efficiency, avoid manual intervention errors, make pressure test parameter preparation and circulation more efficient and accurate, and help smooth execution of full-link pressure test.

[0097] In one specific embodiment, as Figure 3The following is a schematic 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 "2.1 million accounts in full volume" 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 including 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 parametric substitution on the SQL template: Replace the "?" placeholder in the SQL template with actual account data such as acct_id (such as A00001), available balance (such as 100000), etc.; Automatically generate dynamic parameters such as serial number (such as seq = 202507230001), operation time (such as trade_time = 2025-07-23 09:00:00), etc., to ensure that the data conforms to the business logic.

[0103] After generating the complete SQL, the system executes the SQL statements in batch according to the execution order defined in funcid.ini (for example, first execute the INSERT of the t_skasset table, and then execute the UPDATE of the associated table): INSERT statement: insert the initial capital, position, and other basic data for 2.1 million accounts; UPDATE statement: simulate the fund movement of the account (for example, deduct the transaction commission); SELECT statement: verify the data insertion result to ensure data integrity.

[0104] For example Figure 4 The flowchart of the parameter generation process is shown. According to the scene configuration, 2.1 million pre-stored accounts are selected as the stress testing data carrier, and the protocol specification, encryption algorithm (such as SM4), and other basic configurations of the corresponding interface are prepared to prepare for parameter generation.

[0105] The tester selects "test scene-two financing TOP7" in the system, which focuses on the high-frequency interface stress testing of financing and margin business. The system responds to the scene selection and filters 2.1 million pre-stored accounts that meet the characteristics of two financing business (such as accounts that open two financing permissions and have historical transaction records) from the account pool as the basic data carrier for parameter generation. At the same time, load the protocol specification, encryption algorithm (such as SM4), and parameterized plaintext request template of the two financing business-related interfaces to pave the way for the subsequent process.

[0106] The system starts the first multi-threading and carries out two core tasks in parallel: (1) Multi-threading based on Http request call, accessing mobile phone services, and concurrently applying for core authentication credentials Ticket for 2.1 million accounts. Using thread pool for efficient scheduling, Ticket acquisition for a large number of accounts is quickly completed within the effective duration of Ticket (assuming 30 minutes), simulating the high-frequency login and authentication scenarios of users in real business to inject legal identity labels for parameters. (2) Simultaneously, SM4 encryption is performed on sensitive information of the account (such as two financing credit limit, collateral market value, etc.). Multi-threading parallel processing converts plaintext sensitive data into ciphertext, reduces the risk of data leakage, and associates with the obtained Ticket to store in the form of key-value pairs in the memory (such as local cache or distributed cache), building "account-encrypted sensitive information-Ticket" associated data to support subsequent parameter assembly.

[0107] The "account-encryption sensitive information-ticket" association data is read from the memory, according to the parameterized plaintext request template selected according to the "test scene-two fusion TOP7", the business package body encryption process is started: (1) according to the interface dimension (such as two fusion transaction interface, guarantee query interface), the account information, ticket and other data are replaced in the template placeholder (such as {account_id}{ticket}), the plaintext request prototype is generated, which covers the transaction instruction, query condition and other fields. (2) Judge whether the plaintext request needs to be authenticated (such as two fusion contract signing confirmation interface), if authentication is needed, call the counter service to inject the counter authentication credentials (such as one-time authorization code) to improve the request legality. Then, the business package body encryption (such as using national encryption algorithm to re-encrypt) is performed on the complete plaintext request to generate a preliminary ciphertext request, which enhances the security of parameter transmission.

[0108] Start the second multi-thread, further process the preliminary ciphertext request: (1) generate a unique request identifier (such as UUID) for each ciphertext request, combine the interface name (such as "two fusion transaction interface") and the ciphertext content to generate a client authentication credential (such as generating a signature through the HMAC algorithm). The unique request identifier and the client authentication credential are encapsulated as message header information, combined with the ciphertext request body to form the basic structure of the complete compression test parameters. (2) According to the interface dimension, the assembled parameters are stored in the corresponding.dat file (such as "two fusion transaction order interface.dat"). The system listens to the.dat file generation event, and when it detects that the file is completely generated, it triggers the compression process to package the.dat file into a.zip file (such as "two fusion transaction interface.zip"), which optimizes the storage and transmission efficiency, and prepares for subsequent compression test node distribution.

[0109] Repeat the parameter generation process of the interface dimension until the.dat files of all interfaces (such as transaction, query, cancellation, etc.) covered by "test scene-two fusion TOP7" are generated and packaged. The packaged.zip file is distributed to the compression test node, and the compression test node calls the parameters in the file to simulate two fusion business high-frequency operations (such as batch ordering, real-time query of guarantee goods), verify the performance, stability and security of the system in the two fusion business scene, and realize the full-link connection from parameter generation to compression test execution.

[0110] Through multi-thread parallel processing, encryption layer processing, template dynamic adaptation and other links, the two fusion business real parameter generation and flow logic are accurately simulated to provide test data that conforms to the actual situation, is safe and compliant for compression test, and help to find potential performance bottlenecks and business risks of the system.

[0111] The compression test data preparation and parameter generation method for securities business provided by the embodiment of the application is compared with the traditional method, and each index is improved, as shown in Table 1.

[0112] Table 1

[0113]

[0114] In the embodiment, a device for securities business stress testing data preparation and parameter generation is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments, and will not be described again. 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, or a combination of software and hardware is also possible and contemplated.

[0115] The embodiment provides a device for securities business stress testing data preparation and parameter generation, as shown in the accompanying drawings, comprising: Figure 5

[0116] A data preparation module 501 is configured to construct a three-layer mapping relationship of "interface-function number-data table", obtain to-be-tested interface information according to a target stress testing scenario, and perform data preparation based on the three-layer mapping relationship to obtain test data of multiple accounts.

[0117] A parameter generation module 502 is configured to obtain core authentication credentials of each account by using multi-threaded concurrency according to account information, encrypt the account information, and generate stress testing parameters of each interface by using the account information and the core authentication credentials according to the target stress testing scenario.

[0118] In some optional embodiments, the data preparation module 501 comprises:

[0119] An interface mapping unit is configured to map an interface uniform resource identifier to one or more function numbers by using an interface configuration file.

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

[0121] A data table mapping unit is configured to provide a specific data manipulation language template for each business data table by using a data table configuration file.

[0122] A data query unit is configured to query and assemble batch structured query languages by using the three-layer mapping relationship according to the to-be-tested interface information.

[0123] A data writing unit is configured to write execution data of each account according to the execution order of the structured query language to generate test data that meets the target stress testing scenario.

[0124] In some optional embodiments, the parameter generation module 502 comprises:

[0125] ​The first multi-thread enabling unit is configured to enable the first multi-thread, encrypt sensitive information of each account, and store a core authentication credential corresponding to each account.

[0126] The second multi-thread enabling unit is configured to enable the second multi-thread, add each account information and the corresponding core authentication credential to a parameterized plaintext request template of each interface, and obtain a plaintext request of each account.

[0127] The encryption unit is configured to encrypt the plaintext request of each account to generate a ciphertext request.

[0128] The stress test parameter generation unit is configured to generate a unique request identifier for each ciphertext request, generate a client authentication credential according to the unique request identifier, the interface name and the ciphertext request, and generate a message header information composed of the unique request identifier and the client authentication credential, and generate a stress test parameter of the corresponding account composed of the ciphertext request and the message header information.

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

[0130] The stress test data storage unit is configured to generate interface stress test data according to the stress test parameter, and store the interface stress test data in a stress test file.

[0131] The stress test file distribution unit is configured to distribute the stress test file after compression to a stress test node, and determine whether there is an unread interface, if there is, return to the step of generating the stress test parameter of each interface according to the target stress test scenario using each account information and the core authentication credential, until all interfaces are read.

[0132] Further function descriptions of each module and unit are the same as those of the corresponding embodiments, and will not be repeated here.

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

[0134] The embodiment of the present application further provides a computer device with the stress test data pre-preparation and parameter generation device for securities business shown in the above Figure 5 .

[0135] Please refer to Figure 6 , Figure 6 is a structural schematic diagram of a computer device provided by an optional embodiment of the present application, as shown in Figure 6As shown, the computer device includes one or more processors 10, memory 20, and interfaces 30 for the various components to communicate with one another. The various components communicate through one or more buses, and can be mounted on a common motherboard or in other manners as appropriate. The processor 10 can execute instructions, for example, stored in the memory 20 to display graphical information for a GUI on an external input / output device, such as a display device coupled to the interface. In some optional implementations, multiple processors and / or multiple buses can be employed as appropriate, such as about the memory 20. Also, multiple computers can be connected, with each computer providing portions of the necessary operations (e.g., as a server array or a group of blade servers, or multiple processors). Figure 6 The processor 10 is taken as an example in the embodiments.

[0136] The processor 10 can be a central processing unit, a network processor, or a combination thereof. The processor 10 can further include a hardware chip. The hardware chip can be an application specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device can be a complex programmable logic device, a field programmable logic device, a general array logic, or any combination thereof.

[0137] The memory 20 stores instructions that are executable by the at least one processor 10, so as to enable the at least one processor 10 to perform the method shown in the above embodiments.

[0138] The memory 20 can include a program storage area and a data storage area. The program storage area can store an operating system, application programs required by at least one function, and the like. The data storage area can store data created according to the use of the computer device, and the like. In addition, the memory 20 can include a high-speed random access memory, and can further include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. In some optional implementations, the memory 20 can optionally include a memory that is remotely arranged with respect to the processor 10, and these remote memories can be connected to the computer device through a network. Examples of the network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0139] The memory 20 can include a volatile memory, such as a random access memory, and can also include a non-volatile memory, such as a flash memory, a hard disk, or a solid state disk. The memory 20 can further include a combination of the above-mentioned kinds of memories.

[0140] The computer device further includes a communication interface 30 for the computer device to communicate with other devices or communication networks.

[0141] The embodiments of the present application further provide a computer readable storage medium, and the method according to the embodiments of the present application can be implemented in hardware, firmware, or recorded in a storage medium, or be implemented as computer codes stored in a remote storage medium or a non-transitory machine readable storage medium and downloaded through a network and stored in a local storage medium, so that the method described herein can be processed by such software on a storage medium using a general purpose computer, a special purpose processor, or programmable or special hardware. The storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid state disk, etc. Further, the storage medium can also include a combination of the above-mentioned types of memories. It can be understood that the computer, the processor, the microprocessor controller, or the programmable hardware includes a storage component that can store or receive software or computer codes, when the software or computer codes are accessed and executed by the computer, the processor, or the hardware, the method shown in the above embodiments is implemented.

[0142] Although the embodiments of the present application are described in conjunction with the accompanying drawings, various modifications and changes can be made by those skilled in the art without departing from the spirit and scope of the present application, and such modifications and changes 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. 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. 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, Construct a three-tiered mapping relationship of "interface - function number - data table", including: Use the interface configuration file to map the interface's Uniform Resource Identifier to one or more function numbers; The function number configuration file maps each function number to a business data table and the corresponding execution order of the structured query language. Use data table configuration files to provide specific data manipulation language templates for each business data table.

3. The method according to claim 2, characterized in that, Data was prefabricated based on a three-layer mapping relationship to obtain test data from multiple accounts, including: Based on the interface information to be stress tested, a batch structured query language is queried and assembled using a three-layer mapping relationship. The execution data for each account is written according to the execution order of the structured query language to generate test data that conforms to the target load testing scenario.

4. 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.

5. 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.

6. The method according to claim 5, 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.

7. The method according to claim 5, 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.

8. 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 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.

9. 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 7.

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

Images