Test method and device for securities industry transaction system

Abstract

The invention discloses a testing method and device for a securities industry transaction system in the technical field of financial software testing. Interface full coverage, comparison capability enhancement and transaction full-link closed loop are achieved through full simulation, full-link log backtracking and data comparison testing. Comprising the steps of obtaining and analyzing a request message and a response log of a production interface layer, identifying a transaction interface dependency relationship and performing static binding, constructing serial and parallel playback scenes, dynamically replacing response content, judging a message processing state in real time, performing linkage playback on an offer behavior log, and comparing response differences of a baseline environment and an upgrade environment. And comparing the data difference between the test environment and the production environment table. According to the method and the system, a test mode with more simulation, higher interface coverage rate and more complete link coverage can be obtained when a security transaction system test is carried out, faults introduced by version upgrading can be more effectively found, and high requirements of the security industry on a core service system are met.

Description

Technical Field

[0001] This invention belongs to the field of financial software testing technology, and in particular relates to a testing method and apparatus for a securities trading system. Background Art

[0002] Currently known log replay technology uses production messages to construct test case scenarios that mimic actual production business scenarios. It supports multiple test scenario construction methods and saves the test scenarios to disk files. During replay, the request messages in the test scenario files are simultaneously sent to both the baseline and upgraded versions of the system under test. By comparing the differences in the responses to the same request from the baseline and upgraded versions, it can be confirmed whether the version upgrade has affected existing functionality. This provides test engineers with an efficient and automated regression testing method for securities trading systems, enabling them to discover faults introduced by version upgrades.

[0003] With the deepening of market reforms and the continuous advancement of the securities industry, the industry is setting sail towards specialization and differentiation. The trading systems that support the core business of the securities industry are experiencing increasingly diverse business types, more complex business logic, and more frequent system changes and upgrades. Effectively mitigating the systemic risks brought about by rapid business development has become an inevitable challenge for all securities firms. Existing log replay technology can perform automated and efficient regression testing on trading systems, reducing the impact of system changes and upgrades on existing businesses. However, with deeper practical experience and root cause analysis of production environment failures, the impact of existing technologies on issues such as inability to achieve full interface coverage, limited comparison elements, and incomplete transaction loops is becoming increasingly prominent. The breadth and depth of interface coverage in regression testing are gradually failing to meet the securities industry's requirement for zero-failure core business systems.

[0004] Existing technologies suffer from deficiencies such as incomplete interface coverage, limited comparison elements, and unclosed transaction links, failing to meet the securities industry's high requirements for zero-failure core business systems. Summary of the Invention

[0005] The technical problem to be solved by this invention is to address the issues of incomplete interface coverage, limited comparison elements, and unclosed transaction links in existing technologies.

[0006] This invention provides a testing method and apparatus for a securities trading system. Through full simulation and full-link playback testing, it achieves full interface coverage, enhanced comparison capabilities, and a closed-loop transaction process, thereby meeting the securities industry's high requirements for zero-failure core business systems.

[0007] To solve the above-mentioned technical problems, the present invention is implemented using the following technical solution.

[0008] This invention provides a testing method for a securities trading system, comprising:

[0009] Acquire and parse the production interface layer request messages and response logs of the securities industry trading system for a complete trading day. Save the key fields parsed from the response fields of the production interface layer request messages and response logs to the field query service. Store the production interface layer request messages in the playback message library. Acquire and parse the order placement behavior on the order placement machine and store it in the order placement behavior log playback service. Acquire the key table data of the securities industry trading system after the market closes and store it in the comparison database.

[0010] Identify and record the dependent transaction interfaces in the securities industry trading system. Parse the request fields of the dependent transaction interfaces from the request messages of the production interface layer. Use the key fields in the request fields to uniquely find the request messages of other interfaces that the dependent transaction interfaces depend on in the field query service. Statically bind the unique playback serial number corresponding to the request message to the request message of the dependent transaction interfaces.

[0011] Based on the obtained and parsed production interface layer request messages, response logs, order behavior logs, production post-market key table data, and the dependency relationships of the transaction-type interfaces, a serial replay scenario is constructed for interfaces with strong data correlation in the securities industry trading system, and a parallel replay scenario is constructed for customer-related interfaces in the securities industry trading system according to the customer dimension, to fully simulate the actual trading process in the securities industry.

[0012] The response content received from the statically bound request message is parsed to obtain the key response fields. The parsed key response fields are then saved to the program memory of the playback scene. When the playback scene plays back the request message associated with the key response fields, the key fields in the request message are checked and dynamically replaced according to the saved key response fields. After the replacement is completed, the request message is played back.

[0013] In real time, it is determined whether the processing status of each transaction request message parsed from the production interface layer request message has reached the final state. If the final state is reached, the next request message is pushed back. If the final state is not reached, the processing status of the current request message is determined periodically until the final state is reached, and then the next request message is pushed back.

[0014] The key fields of the parsed order behavior logs are associated with the request / response fields of the request messages in the replay message library to generate associated fields. The order machine is configured in the log replay test environment and connected to the simulated exchange program. Using the generated associated fields, the order machine in the log replay test environment is controlled to perform linked replay according to the order and content of the order behavior logs through the fully simulated exchange program.

[0015] Send the same transaction request message to both the baseline environment and the upgrade environment simultaneously. Record and parse the response fields returned by the baseline environment and the upgrade environment. Compare the response fields returned by the baseline environment and the response fields returned by the upgrade environment line by line to obtain the difference comparison results.

[0016] The entire replay process creates a replay task that matches the actual securities industry trading scenario and links it with the replay of order behavior logs. During the replay process, key data tables for the test environment are recorded and created. The differences between the key table data in the test environment and the key table data in the production after-hours market are compared based on the differences. The test scope is then improved and the test strategy is optimized based on the differences.

[0017] The testing methods for the aforementioned securities trading system also include centrally storing interface layer request messages and response logs in a certain physical area.

[0018] Based on the aforementioned testing method for securities trading systems, the key fields parsed from the response fields of the response log include function number, message sequence number, customer number, fund account, and order number.

[0019] Based on the aforementioned testing method for securities trading systems, the order placement behavior logs on the order placement machine are parsed according to business type, market category, and log type.

[0020] Based on the aforementioned testing method for securities trading systems, the dependent trading interfaces include order cancellation interface, modification interface, query interface by order number, and query interface by order number.

[0021] Based on the aforementioned testing method for the securities trading system, the request field of the cancellation interface is parsed from the request message of the production interface layer. The order number, customer number, and fund account in the request field are used to uniquely find the request message of the order placement interface that the cancellation interface depends on in the field query service. The unique replay serial number corresponding to the request message is statically bound to the request message of the cancellation interface.

[0022] Based on the aforementioned testing method for securities trading systems, the differences in the comparison results are highlighted, and defects are recorded through difference analysis.

[0023] Based on the aforementioned testing method for securities trading systems, it also supports real-time reconfirmation of the discrepancies.

[0024] Based on the aforementioned testing method for securities trading systems, the final state of each transaction request message includes:

[0025] Request successful: The request message was successfully received and processed by the system, and the expected response message was returned. The status code or flag in the response message indicates that the request has been successfully completed.

[0026] Request failed: The request message failed to be processed for some reason, and the system returned a clear error response, which indicates that the request has been processed and the reason for failure has been determined.

[0027] Timeout handling: The request message did not receive a system response within the preset timeout mechanism.

[0028] The present invention also provides a testing device for a securities trading system, comprising:

[0029] The log cleaning module is used to acquire and parse the production interface layer request messages and response logs of the securities industry trading system for a complete trading day. It saves the key fields parsed from the response fields of the production interface layer request messages and response logs to the field query service, and stores the production interface layer request messages to the replay message library. It also acquires, parses, and stores the order placement behavior on the order placement machine to the order placement behavior log replay service; and acquires the key table data of the securities industry trading system after the market closes and stores it to the comparison database.

[0030] The static binding module is used to identify and record the dependent transaction interfaces in the securities industry trading system. It parses the request fields of the dependent transaction interfaces from the request messages of the production interface layer, uses the key fields in the request fields to uniquely find the request messages of other interfaces that the dependent transaction interfaces depend on in the field query service, and statically binds the unique playback serial number corresponding to the request message to the request message of the dependent transaction interfaces.

[0031] The scenario construction module is used to construct serial replay scenarios for interfaces with strong data correlation in the securities industry trading system based on the obtained and parsed production interface layer request messages, response logs, order behavior logs, production post-market key table data, and the dependency relationships of the transaction-type interfaces. It also constructs parallel replay scenarios for customer-related interfaces in the securities industry trading system according to the customer dimension, and performs full simulation of the actual trading process in the securities industry.

[0032] The dynamic replacement module is used to parse the response content received from the statically bound request message to obtain the key response fields, and save the parsed key response fields to the program memory of the playback scene. When the playback scene plays back the request message associated with the key response fields, it checks the key fields in the request message and performs dynamic replacement according to the saved key response fields. After the replacement is completed, the request message is played back.

[0033] The timing control module is used to determine in real time whether the processing status of each transaction request message parsed from the production interface layer request message has reached the final state. If the final state is reached, the next request message is pushed back. If the final state is not reached, the processing status of the current request message is determined periodically until the final state is reached, and then the next request message is pushed back.

[0034] The order log module is used to associate key fields of the parsed order behavior logs with request / response fields of request messages in the replay message library to generate associated fields. In the log replay test environment, the order machine is configured and connected to the simulated exchange program. Using the generated associated fields, the order machine in the log replay test environment is controlled to perform linked replay according to the order behavior logs in the order and content through the fully simulated exchange program.

[0035] The response comparison module is used to send the same transaction request message to both the baseline environment and the upgrade environment at the same time, record and parse the response fields returned by the baseline environment and the response fields returned by the upgrade environment, and compare the response fields returned by the baseline environment and the response fields returned by the upgrade environment line by line to obtain the difference comparison results.

[0036] The table data comparison module is used to create a replay task that conforms to the actual securities industry trading scenario through the entire replay process, and is linked with the replay of the order behavior log. During the replay process, it records and creates key data tables in the test environment, compares the key table data in the test environment with the differences between the key table data in the production post-market, and improves the test scope and optimizes the test strategy based on the differences.

[0037] Compared with the prior art, the beneficial effects achieved by the present invention are as follows:

[0038] This invention achieves full-chain log backtracking and data comparison of a fully simulated securities industry trading system. Based on production messages, order behavior logs, and post-market table data, it ensures data authenticity and integrity, achieving full simulation characteristics. The test environment is strictly built according to the production environment, highlighting the full-chain features. Through static binding, dynamic replacement, scenario construction, timing control, and order linkage, it accurately simulates production transactions, achieving full interface coverage and full simulation, improving test accuracy, and effectively identifying version upgrade faults. Simultaneously, it compares differences between interface response fields and table data, expanding the scope of comparison testing and providing test engineers with a more comprehensive and highly realistic testing method. It solves the shortcomings of existing technologies, such as incomplete interface coverage, limited comparison elements, and incomplete transaction chain closure, providing a more efficient and reliable solution for testing securities industry trading systems. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the module flow of a testing device for a securities trading system provided in an embodiment of the present invention. Detailed Implementation

[0040] Example 1

[0041] This embodiment describes a testing method for a securities trading system, including the following steps:

[0042] 1) Log cleaning:

[0043] By using the log system or interface of the securities industry trading system, the production interface layer request messages and response logs of the complete trading day of the securities industry trading system are obtained and parsed, and centrally stored on a dedicated server for easy unified management and access in the future.

[0044] Write a parsing program to parse the production interface layer request messages, extract key fields such as function number, message sequence number, customer number, fund account, and entrustment number from the messages, and store the parsed production interface layer request messages in the replay message library. The replay message library is a database or file system specifically used to store request messages for subsequent replay testing.

[0045] Use parsing tools or programs to parse the response logs and extract the response fields corresponding to the production interface layer request messages, including status codes and return information.

[0046] The parsed key fields are saved to the field query service, which is a database or caching system that provides fast query functionality. Through the field query service, specific request messages and response logs can be quickly located in subsequent replay tests.

[0047] Obtain the order placement behavior logs from the production order placement machine, and parse and process them according to the format and content of the order placement behavior logs, based on dimensions such as business type, market category, and log type.

[0048] Extract the order placement information associated with the production interface layer request message, including order placement time, order content, transaction time, transaction type, stock code, transaction quantity, and transaction price. Parse and process the information according to business type, market category, log type, and other dimensions.

[0049] The parsed and processed order placement behavior logs are stored in the order placement behavior log replay service. The order placement behavior replay service can simulate actual order placement behavior according to the order and content of the logs for replay testing.

[0050] Key table data obtained from the securities industry trading system after the production session is stored in a comparison database. The comparison database is used for subsequent comparison testing. By comparing the differences between the table data in the test environment and the production environment, potential problems can be discovered.

[0051] 2) Static binding:

[0052] In securities trading systems, there are certain dependencies between trading interfaces. This is mainly reflected in the fact that the execution of certain subsequent operations depends on the results or information generated by previous operations.

[0053] First, the business logic and interface documentation of the securities trading system are analyzed to identify and record dependent trading interfaces within the system, including order cancellation, order modification, and query interfaces. The request fields of these dependent trading interfaces are parsed from the production interface layer request messages. Key fields from these request fields are used to uniquely locate the request messages of other interfaces that the dependent trading interfaces depend on in a field query service. Finally, a unique replay serial number corresponding to each request message is statically bound to the request message of the dependent trading interface.

[0054] The following are the static binding steps for the order cancellation interface:

[0055] Parse the request field of the cancellation interface from the production interface layer request message in step 1), use the entrustment number, customer number, and fund account in the request field to uniquely find the request message of the order placement interface that the cancellation interface depends on in the field query service, and statically bind the unique playback serial number corresponding to the request message of the cancellation interface to the request message of the cancellation interface.

[0056] Static binding allows for the simulation of real-world business scenarios and dependencies, making replay tests more closely resemble actual transactions. This helps improve the accuracy and reliability of testing, and assists testers in identifying and resolving potential problems and faults.

[0057] 3) Scene construction:

[0058] Based on the production interface layer request messages, response logs, order behavior logs, production post-order key table data that have been obtained and parsed in step 1) and the transaction interface dependencies known in step 2);

[0059] Constructing a serial playback scenario for interfaces with strong data correlation in securities trading systems:

[0060] Based on the dependencies of transaction-related interfaces, determine the chain of interfaces that need to be executed sequentially, including order placement interface, order cancellation interface, query interface, etc., which constitute a sequential interface chain. The order cancellation interface depends on the order number generated by the order placement interface.

[0061] Following the order in the interface chain, replay the request message of each interface in turn to ensure that the request message of each interface uses the result or data generated by the previous interface as input.

[0062] For each interface request message, verify whether its response is correct and compare it with the response log in the production environment;

[0063] At the same time, by combining the order placement behavior log, we can ensure that the order placement behavior during the playback process is consistent with the actual production environment.

[0064] Parallel playback scenarios are constructed for customer-related interfaces in securities trading systems, categorized by customer dimension:

[0065] The interfaces are grouped based on key fields such as customer number or fund account to ensure that all interfaces in the same group belong to the same customer.

[0066] For each client group, its internal interface request messages are replayed in parallel. Since these interfaces have no dependencies on each other, they can be executed simultaneously, improving replay efficiency.

[0067] During parallel replay, it is verified that the consistency of each client's transaction operations is maintained. That is, it is ensured that the client's transaction behavior in the replay environment is the same as that in the production environment.

[0068] By combining serial and parallel replay scenarios, a replay test environment that fully simulates the actual trading process in the securities industry was constructed. This environment can simulate not only multiple trading operations by a single client, but also the interactions and mutual influences between multiple clients. Furthermore, by incorporating key post-market data from production, results can be compared after the replay test to ensure the accuracy and reliability of the results.

[0069] 4) Dynamic replacement:

[0070] For request messages that have been statically bound, when a response message is received, use a parsing tool or program to parse the response message and extract key fields, including status code, return information, order number, and fund changes.

[0071] The parsed key fields of the response are saved into the program memory of the playback scene by storing the data in variables or data structures in memory.

[0072] When saving, ensure that there is a clear association between the key fields of the response and their corresponding request message or statically bound serial number, so as to facilitate subsequent search and replacement operations;

[0073] When the playback scene is played back to the request message associated with the key fields of the response, the key fields in the request message are examined. The key fields are certain parameters or identifiers in the request message used to identify and associate different transaction operations or requests.

[0074] Based on the previously saved relationships between key fields in the response and key fields in the request message, a dynamic replacement operation is performed. The replaced content includes order number, transaction amount, timestamp, etc. This replacement ensures that the request message in the replay test is consistent with the response content in the actual production environment.

[0075] After completing the dynamic replacement of key fields, the modified request message is sent to the playback test environment for playback.

[0076] Dynamic replacement can simulate scenarios that more closely resemble actual trading conditions, improving the accuracy and reliability of replay testing.

[0077] 5) Timing control:

[0078] After obtaining the request messages from the production interface layer, the header information, request body content, and additional information of each transaction request message are extracted and parsed.

[0079] In parsing transaction request messages, we focus on the fields in the request message that indicate the processing status, including the status code and the processing result identifier. Based on the business logic and interface specifications of the securities industry trading system, we extract the fields that indicate the processing status and determine whether their values ​​indicate that each transaction request has reached the final state.

[0080] The final state of each transaction request message includes:

[0081] Request successful: The request message was successfully received and processed by the system, and the expected response message was returned. The status code or flag in the response message indicates that the request has been successfully completed.

[0082] Request failed: The request message failed to be processed for some reason, and the system returned a clear error response, which indicates that the request has been processed and the reason for failure has been determined.

[0083] Timeout handling: The request message did not receive a system response within the preset timeout mechanism.

[0084] If the processing status of the current request message has not yet reached the final state, the processing status of the current request message is checked periodically until the final state is reached, and then the next request message is sent back.

[0085] If the current request message reaches the final state, the next request message will be sent back.

[0086] By controlling the timing, it is possible to determine in real time whether the processing status of each transaction request message parsed from the production interface layer request message has reached the final state, and to replay the next request message after reaching the final state, thereby ensuring the accuracy and efficiency of replay testing.

[0087] 6) Quotation Log:

[0088] Key fields, including transaction time, transaction type, stock code, transaction quantity, and transaction price, are extracted from the order behavior log. By comparing field names, data formats, and logical relationships, the key fields of the parsed order behavior log are associated with the fields of request and response messages in the playback message library.

[0089] In the log replay test environment, a trading machine is configured to simulate the trading behavior in actual transactions. The trading machine sends transaction request messages according to preset rules and strategies.

[0090] When the order book machine sends a transaction request message, the simulated exchange program processes it according to preset rules and logic and returns a corresponding response message. The response content of the corresponding response message is captured for verification and analysis.

[0091] During the replay, the behavior of the order book machine is verified in real time to be consistent with the order book behavior log by comparing the content of the request and response and checking the transaction status, as well as to whether the response of the simulated exchange program meets expectations.

[0092] By using the order logs, the generated associated fields can be used to control the order machine to perform linked playback in the log playback test environment according to the order and content of the order behavior logs, thereby more accurately simulating the actual transaction scenario and verifying the system's performance and stability.

[0093] 7) Response comparison

[0094] Based on testing needs, generate transaction request messages covering the main functions and business scenarios of the system;

[0095] Using testing tools or automated scripts, send the same transaction-type request messages to both the baseline and upgrade environments simultaneously, ensuring that the request messages sent to the baseline and upgrade environments are exactly the same, including the message header, message body, and any accompanying parameters.

[0096] Receive response messages from the baseline environment and the upgrade environment respectively, and save them to the corresponding logs or databases;

[0097] Based on the format and structure of the response message, the response fields returned by the baseline environment and the upgrade environment are parsed, including key information such as status code, transaction result, and execution time;

[0098] Using comparison tools or scripts, the response fields returned by the baseline environment are compared line by line with the response fields returned by the upgrade environment. The differences in the comparison results are highlighted, and the defects are recorded through difference analysis.

[0099] The differences are reconfirmed in real time;

[0100] Based on the comparison results, assess the impact of these differences on business logic, system performance, or user experience.

[0101] The comparison results and analysis were compiled into a test report, including a list of differences, an impact assessment, and possible improvement suggestions.

[0102] By comparing responses, identical transaction request messages can be effectively sent to both the baseline and upgrade environments, and the response fields of the two environments can be compared to identify potential problems and differences, providing strong testing support for software upgrades or changes.

[0103] 8) Comparison of table data

[0104] During the replay process, key data in the test environment is captured and recorded, including transaction orders, transaction records, account fund changes, etc. Based on the captured key data, corresponding data tables are created to store and manage this data. The data tables should be able to clearly reflect the transaction status and data changes in the test environment.

[0105] The key tables generated after the trading day are produced from the production environment. The data in the key tables generated after the trading day represent the results and status of actual transactions.

[0106] Compare the key table data in the test environment with the key table data in the production environment to identify differences between the two, including data inconsistencies, missing data, or errors.

[0107] Based on the results of the difference analysis, refine the testing scope to ensure coverage of all scenarios and situations where problems may occur;

[0108] Adjust the parameters of the replay task and optimize the data comparison algorithm based on the test results and feedback to improve test efficiency and accuracy.

[0109] By comparing table data, replay tasks that conform to actual securities industry trading scenarios can be created and linked with the replay of order behavior logs. By recording and analyzing the data differences between the test environment and the production environment, the test scope can be continuously improved and the test strategy optimized, thereby improving the quality and effectiveness of the test.

[0110] Example 2

[0111] Based on the same inventive concept as Embodiment 1, this embodiment introduces a testing device for a securities trading system, such as... Figure 1 The following are included:

[0112] The log cleaning module is used to acquire and parse the production interface layer request messages and response logs of the securities industry trading system for a complete trading day. It saves the key fields parsed from the response fields of the production interface layer request messages and response logs to the field query service, and stores the production interface layer request messages to the replay message library. It also acquires, parses, and stores the order placement behavior on the order placement machine to the order placement behavior log replay service; and acquires the key table data of the securities industry trading system after the market closes and stores it to the comparison database.

[0113] The static binding module is used to identify and record the dependent transaction interfaces in the securities industry trading system. It parses the request fields of the dependent transaction interfaces from the request messages of the production interface layer, uses the key fields in the request fields to uniquely find the request messages of other interfaces that the dependent transaction interfaces depend on in the field query service, and statically binds the unique playback serial number corresponding to the request message to the request message of the dependent transaction interfaces.

[0114] The scenario construction module is used to construct serial replay scenarios for interfaces with strong data correlation in the securities industry trading system based on the obtained and parsed production interface layer request messages, response logs, order behavior logs, production post-market key table data, and the dependency relationships of the transaction-type interfaces. It also constructs parallel replay scenarios for customer-related interfaces in the securities industry trading system according to the customer dimension, and performs full simulation of the actual trading process in the securities industry.

[0115] The dynamic replacement module is used to parse the response content received from the statically bound request message to obtain the key response fields, and save the parsed key response fields to the program memory of the playback scene. When the playback scene plays back the request message associated with the key response fields, it checks the key fields in the request message and performs dynamic replacement according to the saved key response fields. After the replacement is completed, the request message is played back.

[0116] The timing control module is used to determine in real time whether the processing status of each transaction request message parsed from the production interface layer request message has reached the final state. If the final state is reached, the next request message is pushed back. If the final state is not reached, the processing status of the current request message is determined periodically until the final state is reached, and then the next request message is pushed back.

[0117] The order log module is used to associate key fields of the parsed order behavior logs with request / response fields of request messages in the replay message library to generate associated fields. In the log replay test environment, the order machine is configured and connected to the simulated exchange program. Using the generated associated fields, the order machine in the log replay test environment is controlled to perform linked replay according to the order behavior logs in the order and content through the fully simulated exchange program.

[0118] The response comparison module is used to send the same transaction request message to both the baseline environment and the upgrade environment at the same time, record and parse the response fields returned by the baseline environment and the response fields returned by the upgrade environment, and compare the response fields returned by the baseline environment and the response fields returned by the upgrade environment line by line to obtain the difference comparison results.

[0119] The table data comparison module is used to create a replay task that conforms to the actual securities industry trading scenario through the entire replay process, and is linked with the replay of the order behavior log. During the replay process, it records and creates key data tables in the test environment, compares the key table data in the test environment with the differences between the key table data in the production post-market, and improves the test scope and optimizes the test strategy based on the differences.

[0120] The specific functions of each module described above are explained in the relevant content of the method in Embodiment 1, and will not be repeated here.

[0121] In summary, this invention achieves full-chain log backtracking and data comparison of a fully simulated securities industry trading system. Based on production messages, order behavior logs, and post-market table data, it ensures data authenticity and integrity, achieving full simulation characteristics. The test environment is strictly built according to the production environment, highlighting the full-chain features. Through static binding, dynamic replacement, scenario construction, timing control, and order linkage, it accurately simulates production transactions, achieving full interface coverage and full simulation, improving test accuracy, and effectively identifying version upgrade faults. Simultaneously, by comparing differences between interface response fields and table data, the scope of comparison testing is expanded, providing test engineers with a more comprehensive and highly realistic testing method. This invention overcomes the shortcomings of existing technologies, such as incomplete interface coverage, limited comparison elements, and incomplete transaction chain closure, providing a more efficient and reliable solution for testing securities industry trading systems.

[0122] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

Claims

1. A testing method for a securities trading system, characterized in that, include: Acquire and parse the production interface layer request messages and response logs of the securities industry trading system for a complete trading day, save the key fields parsed from the response fields of the production interface layer request messages and response logs to the field query service, and store the production interface layer request messages to the replay message library; The system retrieves and analyzes order placement behavior from the order placement machine and stores it in the order placement behavior log playback service; it also retrieves key post-market data from the securities industry trading system and stores it in the comparison database. Identify and record the dependent transaction interfaces in the securities industry trading system. Parse the request fields of the dependent transaction interfaces from the request messages of the production interface layer. Use the key fields in the request fields to uniquely find the request messages of other interfaces that the dependent transaction interfaces depend on in the field query service. Statically bind the unique playback serial number corresponding to the request message to the request message of the dependent transaction interfaces. Based on the obtained and parsed production interface layer request messages, response logs, order behavior logs, production post-market key table data, and the dependency relationships of the transaction-type interfaces, a serial replay scenario is constructed for interfaces with strong data correlation in the securities industry trading system, and a parallel replay scenario is constructed for customer-related interfaces in the securities industry trading system according to the customer dimension, to fully simulate the actual trading process in the securities industry. The response content received from the statically bound request message is parsed to obtain the key response fields. The parsed key response fields are then saved to the program memory of the playback scene. When the playback scene plays back the request message associated with the key response fields, the key fields in the request message are checked and dynamically replaced according to the saved key response fields. After the replacement is completed, the request message is played back. In real time, it is determined whether the processing status of each transaction request message parsed from the production interface layer request message has reached the final state. If the final state is reached, the next request message is pushed back. If the final state is not reached, the processing status of the current request message is determined periodically until the final state is reached, and then the next request message is pushed back. The key fields of the parsed order behavior logs are associated with the request / response fields of the request messages in the replay message library to generate associated fields. The order machine is configured in the log replay test environment and connected to the simulated exchange program. Using the generated associated fields, the order machine in the log replay test environment is controlled to perform linked replay according to the order and content of the order behavior logs through the fully simulated exchange program. Send the same transaction request message to both the baseline environment and the upgrade environment simultaneously. Record and parse the response fields returned by the baseline environment and the upgrade environment. Compare the response fields returned by the baseline environment and the response fields returned by the upgrade environment line by line to obtain the difference comparison results. The entire replay process creates a replay task that matches the actual securities industry trading scenario and links it with the replay of order behavior logs. During the replay process, key data tables for the test environment are recorded and created. The differences between the key table data in the test environment and the key table data in the production after-hours market are compared based on the differences. The test scope is then improved and the test strategy is optimized based on the differences.

2. The testing method for a securities trading system according to claim 1, characterized in that, It also includes storing interface layer request messages and response logs centrally in a certain physical area.

3. The testing method for a securities trading system according to claim 1, characterized in that, The key fields parsed from the response fields of the response log include function number, message sequence number, customer number, fund account, and entrustment number.

4. The testing method for a securities trading system according to claim 1, characterized in that, The order processing logs on the order processing machine are parsed according to business type, market category, and log type.

5. The testing method for a securities trading system according to claim 1, characterized in that, The dependent transaction interfaces include the order cancellation interface, the modification interface, the query interface by order number, and the query interface by order number.

6. The testing method for a securities trading system according to claim 5, characterized in that, Parse the request field of the cancellation interface from the request message of the production interface layer, use the entrustment number, customer number, and fund account in the request field to uniquely find the request message of the order placement interface that the cancellation interface depends on in the field query service, and statically bind the unique playback serial number corresponding to the request message of the cancellation interface to the request message of the cancellation interface.

7. The testing method for a securities trading system according to claim 1, characterized in that, The differences in the comparison results are highlighted, and the defects are recorded through difference analysis.

8. The testing method for a securities trading system according to claim 7, characterized in that, It also supports real-time reconfirmation of the differences.

9. The testing method for a securities trading system according to claim 1, characterized in that, The final state of each transaction request message includes: Request successful: The request message was successfully received and processed by the system, and the expected response message was returned. The status code or flag in the response message indicates that the request has been successfully completed. Request failed: The request message failed to be processed for some reason, and the system returned a clear error response, which indicates that the request has been processed and the reason for failure has been determined. Timeout handling: The request message did not receive a system response within the preset timeout mechanism.

10. A testing device for a securities trading system, characterized in that, include: The log cleaning module is used to obtain and parse the production interface layer request messages and response logs of the securities industry trading system for a complete trading day. It saves the key fields parsed from the response fields of the production interface layer request messages and response logs to the field query service, and stores the production interface layer request messages to the replay message library. The system retrieves and analyzes order placement behavior from the order placement machine and stores it in the order placement behavior log playback service; it also retrieves key post-market data from the securities industry trading system and stores it in the comparison database. The static binding module is used to identify and record the dependent transaction interfaces in the securities industry trading system. It parses the request fields of the dependent transaction interfaces from the request messages of the production interface layer, uses the key fields in the request fields to uniquely find the request messages of other interfaces that the dependent transaction interfaces depend on in the field query service, and statically binds the unique playback serial number corresponding to the request message to the request message of the dependent transaction interfaces. The scenario construction module is used to construct serial replay scenarios for interfaces with strong data correlation in the securities industry trading system based on the obtained and parsed production interface layer request messages, response logs, order behavior logs, production post-market key table data, and the dependency relationships of the transaction-type interfaces. It also constructs parallel replay scenarios for customer-related interfaces in the securities industry trading system according to the customer dimension, and performs full simulation of the actual trading process in the securities industry. The dynamic replacement module is used to parse the response content received from the statically bound request message to obtain the key response fields, and save the parsed key response fields to the program memory of the playback scene. When the playback scene plays back the request message associated with the key response fields, it checks the key fields in the request message and performs dynamic replacement according to the saved key response fields. After the replacement is completed, the request message is played back. The timing control module is used to determine in real time whether the processing status of each transaction request message parsed from the production interface layer request message has reached the final state. If the final state is reached, the next request message is pushed back. If the final state is not reached, the processing status of the current request message is determined periodically until the final state is reached, and then the next request message is pushed back. The order log module is used to associate key fields of the parsed order behavior logs with request / response fields of request messages in the replay message library to generate associated fields. In the log replay test environment, the order machine is configured and connected to the simulated exchange program. Using the generated associated fields, the order machine in the log replay test environment is controlled to perform linked replay according to the order behavior logs in the order and content through the fully simulated exchange program. The response comparison module is used to send the same transaction request message to both the baseline environment and the upgrade environment at the same time, record and parse the response fields returned by the baseline environment and the response fields returned by the upgrade environment, and compare the response fields returned by the baseline environment and the response fields returned by the upgrade environment line by line to obtain the difference comparison results. The table data comparison module is used to create a replay task that conforms to the actual securities industry trading scenario through the entire replay process, and is linked with the replay of the order behavior log. During the replay process, it records and creates key data tables in the test environment, compares the key table data in the test environment with the differences between the key table data in the production post-market, and improves the test scope and optimizes the test strategy based on the differences.

Images