System testing method, device and equipment

Abstract

The embodiment of the invention relates to the technical field of text processing, in particular to a system testing method, device and equipment. According to the embodiment of the invention, the method comprises the steps: capturing the transaction flow and response message of an old system in real time, obtaining the related configuration from the transaction information, screening out the proper transaction flow, executing the recording operation, and carrying out the partition storage according to the real-time transaction information; after a playback instruction is received, a corresponding message set is selected according to the playback instruction, the playback rate is adjusted, the corresponding message is played back to the new system, a response message generated by the new system is obtained, the response message is compared with an old system response message, and a test result of the new system is generated. Through the mode, the background pressure requirements of performance and chaos testing can be met by automatically adjusting the message playback rate, different business transaction functions can be verified by playing back different messages at the same time, and therefore testing of new system functions is completed.

Description

Technical Field

[0001] The embodiments of this specification relate to the technical field of text processing, and in particular, to a method, device, and equipment for system testing. Background Art

[0002] Currently, in the system construction of banks, transforming the original monolithic core system into a distributed architecture is a complex process. After developing the relevant functional modules, testing and verifying whether these functions meet the business objectives becomes a time-consuming and laborious process. First of all, each function needs to pass the business verification test, abbreviated as UAT test. Currently, this test process relies on a dedicated test team to write cases. During the process of writing cases, developers and business personnel are also required to participate in the writing of cases, and data generation is also needed. When encountering some complex business scenarios, data generation will bring a large amount of workload to the test. Secondly, some key transactions in the bank system have time-consuming rankings in UnionPay and NetsUnion. The less time-consuming, the higher the ranking. Therefore, these transactions also need to pass performance tests. This test also requires a team to execute. First, a test plan needs to be written, and then the pressure-generating script needs to be parameterized. When parameterizing, different transaction messages need to be referred to. Then, according to the real production transaction link, monitoring needs to be done in advance, and the relevant application deployment devices also need to be consistent with the production. Only when all these are ready can the stress test start. During the test process, if there are any non-conforming situations, the pressure-generating script needs to be continuously adjusted manually until both development and testing agree with the results of the stress test. Finally, chaos testing needs to be passed. Due to the complexity of the distributed architecture, there are more unpredictable problems in the actual operation process than in the monolithic application device. At this time, a professional team is required to conduct chaos testing. Similarly, relevant cases need to be written, and the expected goals of chaos testing are set according to the characteristics of different modules. If the expected goals are not met during the execution process, the pressure-generating script needs to be continuously adjusted.

[0003] Therefore, there is an urgent need for a system testing method to reduce the large amount of manpower and material resources consumed by UAT testers in writing cases, reduce the unreasonable parameter settings of performance tests, and simulate reasonable background pressure. Summary of the Invention

[0004] To solve the problems of inaccurate intent recognition and low multi-channel retrieval efficiency in the existing business Q&A system, the embodiments of this specification provide a method, device, and equipment for system testing. Through the recording and playback of messages, the messages sent by the gateway are recorded in real time according to traffic control; the recording and playback of real transaction traffic are realized automatically, and then the transaction traffic can be sent to the new distributed core through the bypass gateway. Finally, the correctness of the new system is verified by message comparison, so as to judge the performance of the new system and the rationality of chaos testing.

[0005] The specific technical solution of the embodiments of this specification is as follows:

[0006] On the one hand, the embodiments of this specification provide a method for system testing, including:

[0007] Real-time capture the transaction traffic received by the old system and its corresponding first response message, and annotate the real-time transaction information for the transaction traffic;

[0008] Obtain relevant configurations according to the real-time transaction information, and screen the transaction traffic for recording according to the configurations;

[0009] Partition and store the transaction messages generated by recording according to the annotation to generate message collections of different business types;

[0010] Select the corresponding message collection according to the playback instruction, and adjust the playback rate according to the playback instruction and playback it to the new system;

[0011] Compare the second response message generated by the new system with the first response message to generate the test result of the new system.

[0012] Further, partitioning and storing the transaction messages generated by recording according to the annotation further includes,

[0013] Obtain the daily cut time threshold according to the daily cut rule of the banking business trading day;

[0014] Obtain the timestamp of the transaction message according to the annotation of the real-time transaction information;

[0015] When it is detected that the timestamp crosses the daily cut time threshold, generate a new trading day storage partition;

[0016] Add the previous trading day identifier and the next trading day identifier to the transaction message, and map such cross-day transaction messages to the storage partitions of two adjacent trading days for storage at the same time;

[0017] When the recorded transaction messages include transaction messages continuously collected for multiple trading days, automatically generate storage partitions according to the daily cut time threshold to ensure that each storage partition contains the transaction messages in the transition period before and after the daily cut time of the trading day.

[0018] Further, selecting the corresponding message collection according to the playback instruction, and adjusting the playback rate according to the playback instruction and playback it to the new system further includes,

[0019] Generate the playback instruction according to the test requirements, test results of the new system and the real-time load status of the system resources;

[0020] Select a corresponding message collection according to the test requirements and the trading date and business type in the annotation of the real-time transaction information;

[0021] According to the real-time load status of the system resources, dynamically adjust the playback rate of the transaction messages in real time;

[0022] Play back the corresponding message collection to the new system according to the playback rate.

[0023] Further, generating the playback instruction according to the test requirements, test results and real-time load status of the system resources of the new system further includes,

[0024] The test results of the new system include the calculation rate of the new system, the message response time and the correct rate of the response messages;

[0025] Judge whether the test results meet the expectations according to the preset target calculation rate, target response time and correct rate threshold;

[0026] If the test results do not meet the expectations, adjust the playback rate in the playback instruction, and play back the corresponding message collection to the new system according to the adjusted playback rate.

[0027] Further, generating the playback instruction according to the test requirements, test results and real-time load status of the system resources of the new system further includes,

[0028] Generate the time density feature of the original transaction according to the time stamp of the transaction message, and adjust the playback rate of the transaction message according to the time density feature.

[0029] Further, comparing the second response message generated by the new system with the first response message further includes,

[0030] The old system is a monolithic core system, and the new system is a distributed system.

[0031] On the other hand, the embodiment of the present specification also provides a system test device, and the device includes:

[0032] A transaction traffic acquisition unit, configured to capture in real time the transaction traffic received by the old system and its corresponding first response message, and annotate the real-time transaction information for the transaction traffic;

[0033] A transaction traffic recording unit, configured to obtain relevant configurations according to the real-time transaction information, and screen and record the transaction traffic according to the configurations;

[0034] A transaction message storage unit, configured to store the recorded transaction messages in partitions according to the annotation, and generate message collections of different business types;

[0035] A transaction message playback unit, configured to select a corresponding message collection according to a playback instruction, and playback to a new system at a playback rate adjusted according to the playback instruction;

[0036] A test result generation unit, configured to compare a second response message generated by the new system with the first response message to generate a test result of the new system.

[0037] On the other hand, an embodiment of this specification further provides a computer device, including a memory, a processor, and a computer program stored on the memory. When the processor executes the computer program, the above method is implemented.

[0038] On the other hand, an embodiment of this specification further provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the above method is implemented.

[0039] Finally, an embodiment of this specification further provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the above method is implemented.

[0040] Using the embodiment of this specification, this solution captures the transaction traffic received by the old system in real time and the corresponding first response message generated thereby, annotates the transaction traffic according to the real-time transaction information, then obtains the relevant configuration of this transaction from the transaction information, filters out the transaction traffic according to the configuration, and performs a recording operation, thereby avoiding duplicate or failed transaction traffic in the recorded content; then stores the transaction messages generated by recording in partitions according to the real-time transaction information to generate message collections for different services, realizing that when playback is required, the corresponding transaction messages can be quickly and completely found. Therefore, when a playback instruction is received, the corresponding message collection can be selected according to the playback instruction, and the corresponding messages can be played back to the new system at a playback rate adjusted according to the playback instruction. Different rates can also be set during playback to meet the pressure requirements of performance testing; then the second response message generated by the new system is obtained, compared with the first response message, and a test result of the new system is generated. In this way, automatically adjusting the playback rate of the messages can meet the background pressure requirements of performance and chaos testing. At the same time, playing back different messages can verify different business transaction functions, and using message comparison can determine whether the execution results of the new and old systems are consistent, thereby verifying whether the functions of the new system are correct. This method verifies the performance of the new system through real production traffic, efficiently provides necessary and real test results for the new system to go online, reduces unreasonable parameter settings for performance testing, and simulates reasonable background pressure. Description of the Drawings

[0041] To more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the embodiments of this specification. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0042] Figure 1 The following shows a schematic diagram of the implementation system of a system testing method in an embodiment of this specification;

[0043] Figure 2 The following shows a schematic flowchart of the system testing method in an embodiment of this specification;

[0044] Figure 3 The following shows a schematic flowchart of partitioning and storing the recorded transaction messages according to the remarks in an embodiment of this specification;

[0045] Figure 4 The following shows a schematic flowchart of playback according to the playback instruction in an embodiment of this specification;

[0046] Figure 5 The following shows a schematic flowchart of generating a playback instruction in an embodiment of this specification;

[0047] Figure 6 The following shows a schematic diagram of the implementation system of the system testing method in an embodiment of this specification;

[0048] Figure 7 The following shows a specific structural schematic diagram of the system testing device in this embodiment;

[0049] Figure 8 The following shows a structural schematic diagram of a computer device in an embodiment of this specification.

[0050]

Explanation of the reference numerals in the drawings

[0051] 10, Service bus;

[0052] 101, Old system;

[0053] 102, New system;

[0054] 1021, Bypass gateway;

[0055] 103, Recording and playback module;

[0056] 104, Message comparison

[0057] 701, Transaction traffic acquisition unit;

[0058] 702, Transaction traffic recording unit;

[0059] 703. Transaction message storage unit;

[0060] 704. Transaction message playback unit;

[0061] 705. Test result generation unit;

[0062] 802. Computer device;

[0063] 804. Processing device;

[0064] 806. Storage resource;

[0065] 808. Drive system;

[0066] 810. Input / output module;

[0067] 812. Input device;

[0068] 814. Output device;

[0069] 816. Presentation device;

[0070] 818. Graphical user interface;

[0071] 820. Network interface;

[0072] 822. Communication link;

[0073] 824. Communication bus. Detailed implementation manners

[0074] Next, the technical solutions in the embodiments of this specification will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the embodiments of this specification.

[0075] It should be noted that in the description, claims and the above drawings of the embodiments of this specification, terms such as "first" and "second" are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the embodiments of this specification described here can be implemented in an order other than those illustrated or described here. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, device, product or equipment that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or equipment.

[0076] It should be noted that in the technical solutions of the embodiments of this specification, the acquisition, storage, use, processing, etc. of data all comply with the relevant regulations of national laws and regulations.

[0077] It should be noted that in the embodiments of this specification, some industry-existing solutions such as certain software, components, models, etc. may be mentioned. They should be regarded as exemplary, and their purpose is only to illustrate the feasibility in the implementation of the technical solutions of this application, but it does not mean that the applicant has already or necessarily used this solution.

[0078] As Figure 1 shown is a schematic diagram of an implementation system of a system testing method in the embodiments of this specification, including a service bus 10, an old system 101, a new system 102, and a recording and playback module 103. Optionally, the new system 102 is also provided with a bypass gateway 1021 for message screening. The service bus 10 can communicate with the old and new systems through a network, and the network can include a local area network (LAN for short), a wide area network (WAN for short), the Internet or a combination thereof, and is connected to a website, a user device (such as a computing device), and a backend system. Optionally, the service bus 10 can be a node of a cloud computing system, or each server can be a separate cloud computing system, including multiple computers interconnected by a network and working as a distributed processing system.

[0079] The service bus 10 sends transaction traffic to the legacy system 101. The legacy system 101 processes the transaction traffic and generates a first response message. The bypass gateway 1021 captures the transaction traffic during the process of the service bus 10 sending the transaction traffic and copies it to the recording and playback module 103 for message recording. The recording and playback module 103 stores the recorded transaction messages in partitions. When receiving relevant playback instructions, the corresponding messages are played back to the new system 102 through the bypass gateway 1021. The new system 102 generates a second response message according to the transaction messages, compares the second response message with the first response message, and generates the test result of the new system 102 to complete the test.

[0080] In addition, it should be noted that Figure 1 The application environment shown is only one provided by the embodiments of this specification. In actual applications, other application environments may also be included, which are not limited in this specification.

[0081] In view of the problems existing in the prior art, the embodiments of this specification provide a method for system testing. By recording transaction messages and playing them back according to requirements, some real transaction traffic processing scenarios are specifically simulated, thereby verifying whether the functions of the new system are correct. On the other hand, different business transaction functions can be verified by playing back different message collections, solving the problem of difficult system testing; during the process of message playback, by adjusting the rate at which the messages are played back to the new system, the backpressure requirements for performance testing and chaos testing are ensured. In the embodiments of this specification, Figure 2 The flow diagram of the method for system testing in the embodiments of this specification is shown. The process of system testing is described in this figure. The order of steps listed in the embodiments is only one way among the execution orders of numerous steps and does not represent the only execution order. When the actual system or device product is executed, it can be executed in the order of the method shown in the embodiments or the drawings or executed in parallel. Specifically, as Figure 2 shown, the method may include:

[0082] Step 201: Real-time capture the transaction traffic received by the legacy system and its corresponding first response message, and annotate the real-time transaction information of the transaction traffic;

[0083] Step 202: Obtain relevant configurations according to the real-time transaction information, and screen the transaction traffic for recording according to the configurations;

[0084] Step 203: Store the recorded transaction messages in partitions according to the annotation, and generate message collections of different business types;

[0085] Step 204: Select the corresponding message collection according to the playback instruction, and adjust the playback rate according to the playback instruction to play it back to the new system;

[0086] Step 205: Compare the second response message generated by the new system with the first response message to generate the test result of the new system.

[0087] Using the embodiments of this specification, this solution captures the transaction traffic received by the old system in real time and the corresponding first response message generated thereby, annotates the transaction traffic according to the real-time transaction information, then obtains the relevant configuration of this transaction from the transaction information, filters out the transaction traffic according to the configuration, and performs a recording operation, thereby avoiding duplicate or failed transaction traffic in the recorded content; then stores the transaction messages generated by the recording in partitions according to the real-time transaction information to generate message collections for different services, achieving that when playback is required, the corresponding transaction messages can be quickly and completely found. Therefore, when a playback instruction is received, the corresponding message collection can be selected according to the playback instruction, and the corresponding messages can be played back to the new system by adjusting the playback rate according to the playback instruction. Different rates can also be set during playback to meet the pressure requirements of performance testing; then obtain the second response message generated by the new system, compare it with the first response message, and generate the test result of the new system. In this way, automatically adjusting the playback rate of the messages can meet the background pressure requirements of performance and chaos testing. At the same time, playing back different messages can verify different business transaction functions, and using message comparison can determine whether the execution results of the new and old systems are consistent, thereby verifying whether the functions of the new system are correct. This method verifies the performance of the new system through real production traffic and efficiently provides necessary and real test results for the new system to go live.

[0088] In the existing migration test of the bank core system, the business verification test (UAT test) relies on manually writing test cases and constructing data, especially consuming a large amount of human resources in complex scenarios; the performance test requires manually parameterizing the stress script, and it is easy to cause the simulated traffic to deviate from real production due to too high or too low parameter concentration or dispersion; in the chaos test, the background traffic artificial modeling is inaccurate, affecting the credibility of the fault injection test. This application non-invasively records real production messages through a bypass gateway and automatically reuses them as test cases, eliminating the need for manual writing; by adjusting the playback rate, it precisely controls the traffic timing and pressure fluctuations, restoring both the real performance scenario and simulating abnormal pressure; adopting a parallel playback mechanism for the new and old systems, using the message comparison service to automatically verify the function consistency, and combining the log monitoring metrics to analyze the system behavior, realizing the full-process automation of function verification, performance testing, and chaos testing, and solving the efficiency bottleneck and simulation distortion problems caused by manual intervention.

[0089] According to an embodiment of this specification, in order to meet the requirement of using different message data for different transaction dates required by the bank core, such as Figure 3 shown, further including storing the transaction messages generated by the recording in partitions according to the annotation,

[0090] Step 301: Obtain the cut-off time threshold according to the cut-off rules of the banking business trading day;

[0091] Step 302: Obtain the timestamp of the transaction message according to the annotation of the real-time transaction information;

[0092] Step 303: When it is detected that the timestamp crosses the cut-off time threshold, generate a new trading day storage partition;

[0093] Step 304: Add the previous trading day identifier and the next trading day identifier to the transaction message, and map such cross-day transaction messages to the storage partitions of two adjacent trading days for storage at the same time;

[0094] Step 305: When the recorded transaction messages include transaction messages continuously collected on multiple trading days, automatically generate storage partitions according to the cut-off time threshold to ensure that each storage partition contains complete transaction messages in the transition period before and after the cut-off time of the trading day.

[0095] In the embodiments of this specification, the function of recording and playback needs to meet the requirement of using different message data for different trading dates required by the bank core. The function of starting and stopping recording regularly is used to implement the recording of multiple trading days. When playing back, the required files can also be randomly selected, and different files are distinguished by trading days. First, obtain the cut-off time threshold according to the cut-off rules of the banking business trading day. Exemplarily, in the message collection device deployed in some regional branches, the preset banking business cut-off time threshold is from 23:30 to 00:30 the next day (covering the end-of-day batch processing window of the head office clearing center). When the collection module detects that the current time enters 23:25, it automatically activates the cut-off preparation mode, pre-generates the storage partition identifier for the next day in the memory, and at the same time keeps the write channel of the current day partition open. Through the preset cut-off time and buffer overlap area design, when the recorded transaction messages include transaction messages continuously collected on multiple trading days, storage partitions are automatically generated according to the cut-off time threshold to ensure that each storage partition contains complete transaction messages in the transition period before and after the cut-off time of the trading day. It solves the problem of the attribution of cross-day transaction messages generated during the end-of-day batch processing of the financial system, aligns the recording time period with the banking business cut-off rules automatically, avoids the loss of end-of-day settlement messages caused by fixed-time truncation, and greatly improves the accuracy of the online verification of the distributed core system through this method.

[0096] According to an embodiment of this specification, in order to achieve automatic adjustment of the playback rate of the message, it can meet the background pressure requirements of performance and chaos testing, such as Figure 4 shown, select the corresponding message collection according to the playback instruction, and adjust the playback rate according to the playback instruction and play it back to the new system. Further include,

[0097] Step 401: Generate the playback instruction according to the test requirements, test results of the new system, and the real-time load status of system resources.

[0098] Step 402: Select the corresponding message collection according to the test requirements and the trading date and business type in the annotation of the real-time transaction information.

[0099] Step 403: Dynamically adjust the playback rate of the transaction message in real time according to the real-time load status of system resources.

[0100] Step 404: Play back the corresponding message collection to the new system according to the playback rate.

[0101] Specifically, in scenarios with performance requirements, generate a playback instruction according to the test requirements, test results of the new system, and the real-time load status of system resources. The playback instruction includes the target message and the target rate. Then, find the target message in the corresponding trading date partition and play it back at the target rate. At the same time, during the playback process, the playback rate of the transaction message can also be dynamically adjusted in real time according to the real-time load status of system resources. Calculate through the total number of messages played back and the required playback duration, and regularly compare the actual rate with the target rate. If the difference between the actual rate and the target rate is within a reasonable window, it will be automatically ignored. If the difference exceeds the set window, an alarm will be issued, and the playback service will automatically adjust the playback rate. It will be increased when the actual rate is small and decreased when the actual rate is large. Automatically adjusting the playback rate of messages can meet the background pressure requirements of performance and chaos testing.

[0102] Exemplarily, when simulating abnormal scenarios such as network latency and node failures, verify the disaster tolerance ability of the system by injecting controllable traffic disturbances (such as random packet loss and rate jitter); when performing playback during off-peak hours, automatically increase the rate to shorten the test cycle while ensuring that the resource occupancy rate does not exceed the safety threshold (such as 80%); during critical periods such as the clearing window and batch processing period of the bank's core system, actively reduce the playback rate to avoid interfering with real-time services; according to the real-time load status of the current system resources (CPU / memory / network bandwidth), intelligently match the message playback rate to prevent the production system from crashing due to instantaneous traffic overload; support extreme traffic pressurization (breaking through historical peaks) in stress test scenarios, while the precise playback scenario needs to strictly follow the original traffic pattern. Generate a playback instruction based on the specific performance requirements of these scenarios and the test results generated by each test of the new system. At the same time, adjust the injection rate in real time by monitoring the transaction response time of the production system in real time to form a closed-loop control.

[0103] According to another embodiment of this specification, in order to enable the new system to achieve the expected test results, it may be necessary to conduct multiple tests on the same set of messages by adjusting the playback rate, such as Figure 5 As shown, generating the playback instruction according to the test requirements, test results, and real-time load status of system resources of the new system further includes

[0104] Step 501: The test results of the new system include the calculation rate of the new system, the message response time, and the correct rate of the response messages.

[0105] Step 502: Determine whether the test results meet the expectations according to the preset target calculation rate, target response time, and correct rate threshold.

[0106] Step 503: If the test results do not meet the expectations, adjust the playback rate in the playback instruction, and replay the corresponding set of messages to the new system according to the adjusted playback rate.

[0107] Specifically, during the migration verification process of the bank core system, the real transaction flow in the production environment is recorded non-intrusively through a bypass gateway, and key business messages such as inter-bank transfers and batch payroll during high-concurrency periods such as quarter-end settlement and daily cutover are mainly collected. When performing tests, the system real-time monitors core indicators such as the calculation throughput, transaction response latency, and business correct rate of the new system. Among them, the calculation rate reflects the horizontal scalability of the distributed architecture, the response time detects lock competition and transaction conflict problems, and the correct rate verifies the accuracy of business logic by comparing fields such as interest amount and account status. When the system identifies that a certain type of transaction indicator fails to reach the preset threshold (such as the correct rate of batch payroll is lower than the preset requirement), the playback rate is dynamically adjusted. During the process of testing with real production traffic, precise sharding control is achieved through transaction feature recognition, and a mapping relationship between indicator overrun and speed regulation strategy is established, transforming the traditional parameter adjustment process relying on manual experience into a data-driven closed-loop optimization system, effectively solving the coordination problem between performance tuning and function verification in complex bank business scenarios.

[0108] According to another embodiment of this specification, in order to simulate a real transaction process, generating the playback instruction according to the test requirements, test results, and real-time load status of system resources of the new system further includes

[0109] Generating the time density feature of the original transaction according to the timestamp of the transaction message, and adjusting the playback rate of the transaction message according to the time density feature.

[0110] Specifically, by dynamically adjusting the rate, concurrency, and timing distribution of message injection to achieve rate control, queuing processing can be performed on high-concurrency historical transaction messages (such as during the peak clearing period), and they can be injected in batches according to the preset thread pool rules to avoid exhaustion of the database connection pool; it can also accurately reproduce the time density characteristics of the original transaction (such as the pulsed traffic at the opening at 9:30 am), rather than simply linearly replaying. During critical periods such as the clearing window and batch processing period of the bank's core system, the testing of the new system can be slowed down for playback to avoid interfering with real-time services.

[0111] According to an embodiment of the present specification, in order to compare the second response message generated by the new system with the first response message, it further includes

[0112] The old system is a monolithic core system, and the new system is a distributed system.

[0113] Specifically, the new system testing involved in this specification mainly replaces the original monolithic core system of the old system with a distributed system. After the relevant function modules are developed, it becomes a time-consuming and laborious process to test and verify whether this part of the function meets the business objectives. Due to the complexity of the distributed architecture, there are more unforeseen problems in the actual operation process than in the monolithic application device. Therefore, this specification verifies the new system through real production traffic, providing real and necessary verification results for the new system to go live.

[0114] In another embodiment of the present specification, such as Figure 6As shown in the figure, when using the device in the embodiments of this specification, the message playback can be manually controlled or automated through timing. When the message passes through the bypass gateway 1021, the bypass gateway 1021 will read the configuration of the application management service and can control the transaction traffic and the number of transactions. After the new and old systems are processed, the message comparison 104 compares their messages. If the comparison is consistent, it indicates that the function verification is okay. If the comparison is inconsistent, the problem will be recorded and then enter the defect and problem handling process. Or the recording and playback module 103 reads the configuration of the application management service and replays the messages to the bypass gateway 1021 at a certain rate. The gateway also reads the configuration of the application management service and sends some key transactions to the new system to implement the stress test verification for some transactions. The monitoring and analysis forms indicators of transaction volume, response time, and success rate by pulling the transaction logs of the new system in real time. The playback service will calculate the current playback rate regularly. If the pressure received by the new system is too small, the playback rate of the messages can be increased. When the playback volume of the messages exceeds the processing capacity of the gateway, the messages can queue up in the playback service. The recording and playback module of this specification pre-configures the recording and playback parameters on the application management service, receives the replicated traffic of the real production traffic, and then can record multiple different message collections and replay multiple different message collections. The switching between different files can be achieved through timing, and the whole process does not require manual operation. When playing back, the playback rate can be automatically adjusted according to the processing situation of the new system, specifically by comparing the actual rate and the target rate in real time. After the message playback is completed, the function of the business transaction is verified by comparing whether the message results of the new and old systems are consistent through the comparison service. If they are consistent, the verification passes. If they are inconsistent, the details of the detailed comparison will be recorded; the performance of the typical business transactions is judged by calculating the indicators in real time through the log monitoring system. If the response time, transaction volume per second, and success rate of the transaction all meet the technical requirements, the performance verification passes. If any one does not meet the requirements, further playback verification is required until the relevant performance indicators are met. This invention verifies the new system through the real production traffic and provides the necessary verification results for the new system to go online.

[0115] As an embodiment of this specification, reference can also be made to Figure 7 The figure shows the specific structural schematic diagram of the system test device of this embodiment.

[0116] The transaction traffic acquisition unit 701 is used to capture the transaction traffic received by the old system in real time and its corresponding first response message, and annotate the real-time transaction information of the transaction traffic.

[0117] The transaction traffic recording unit 702 is used to obtain relevant configurations according to the real-time transaction information, and screen and record the transaction traffic according to the configurations.

[0118] The transaction message storage unit 703 is configured to partition and store the transaction messages generated by recording according to the annotations, generating message collections of different business types;

[0119] The transaction message playback unit 704 is configured to select a corresponding message collection according to the playback instruction, and playback it to the new system at a playback rate adjusted according to the playback instruction;

[0120] The test result generation unit 705 is configured to compare the second response message generated by the new system with the first response message, generating a test result of the new system.

[0121] Since the principle of the above device for solving problems is similar to that of the above method, the implementation of the above system can refer to the implementation of the above method, and the repeated parts will not be described again.

[0122] As Figure 8 shown is the structural diagram of the computer device according to the embodiment of this specification. The computer device in the embodiment of this specification can run the method of the embodiment of this specification.

[0123] The computer device 802 may include one or more processing devices 804, such as one or more central processing units (CPUs), and each processing unit may implement one or more hardware threads. The computer device 802 may also include any storage resource 806 for storing any kind of information such as code, settings, data, etc. Non-limiting examples include, for instance, any type of RAM, any type of ROM, flash memory devices, hard disks, optical discs, etc. More generally, any storage resource can store information using any technology.

[0124] Furthermore, any storage resource can provide volatile or non-volatile retention of information.

[0125] Furthermore, any storage resource can represent a fixed or removable component of the computer device 802. In one case, when the processing device 804 executes the associated instructions stored in any storage resource or combination of storage resources, the computer device 802 can perform any operation of the associated instructions. The computer device 802 also includes one or more drive systems 808 for interacting with any storage resource, such as a hard disk drive system, an optical disc drive system, etc.

[0126] The computer device 802 may further include an input / output module 810 (I / O) for receiving various inputs (via the input device 812) and for providing various outputs (via the output device 814). A specific output mechanism may include a presentation device 816 and an associated graphical user interface 818 (GUI). In other embodiments, the input / output module 810 (I / O), the input device 812, and the output device 814 may not be included, and it may only be a computer device in the network. The computer device 802 may further include one or more network interfaces 820 for exchanging data with other devices via one or more communication links 822. One or more communication buses 824 couple the components described above together.

[0127] The communication link 822 may be implemented in any manner, for example, through a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. The communication link 822 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc. governed by any protocol or combination of protocols.

[0128] The embodiments of this specification also provide a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the above method is implemented.

[0129] The embodiments of this specification also provide a computer-readable instruction, and when the processor executes the instruction, the program therein causes the processor to execute the above method.

[0130] It should be understood that in various embodiments of the embodiments of this specification, the magnitudes of the sequence numbers of the above processes do not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of this specification.

[0131] It should also be understood that in the embodiments of this specification, the term "and / or" is only a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B may represent three cases: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in the embodiments of this specification generally represents an "or" relationship between the associated objects before and after.

[0132] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed in this specification can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of the examples have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this specification's embodiments.

[0133] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0134] In the several embodiments provided in this specification's embodiments, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Additionally, the displayed or discussed couplings or direct couplings or communication connections to each other can be indirect couplings or communication connections through some interfaces, devices, or units, or can also be in electrical, mechanical, or other forms of connection.

[0135] The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solutions in this specification's embodiments.

[0136] In addition, the functional units in each of the embodiments of this specification can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0137] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiments of this specification, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this specification. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs.

[0138] In the embodiments of this specification, specific embodiments are used to elaborate on the principles and implementation manners of the embodiments of this specification. The descriptions of the above embodiments are only used to help understand the methods and their core ideas of the embodiments of this specification; at the same time, for those of ordinary skill in the art, according to the ideas of the embodiments of this specification, there will be changes in the specific implementation manners and application scopes. In summary, the content of this specification should not be construed as a limitation to the embodiments of this specification.

Claims

1. A method for system testing, characterized in that, The method includes: Real-time capturing the transaction traffic received by the old system and its corresponding first response message, and annotating the real-time transaction information for the transaction traffic; Obtaining relevant configurations according to the real-time transaction information, and screening the transaction traffic for recording according to the configurations; Storing the recorded transaction messages in partitions according to the annotation to generate message collections of different business types; Selecting the corresponding message collection according to the playback instruction, and adjusting the playback rate according to the playback instruction and playing back to the new system; Comparing the second response message generated by the new system with the first response message to generate the test result of the new system.

2. The method for system testing according to claim 1, wherein Storing the recorded transaction messages in partitions according to the annotation further includes: Obtaining the daily cut time threshold according to the daily cut rule of the banking business trading day; Obtaining the timestamp of the transaction message according to the annotation of the real-time transaction information; When it is detected that the timestamp crosses the daily cut time threshold, generating a new trading day storage partition; Adding a pre-trading day identifier and a post-trading day identifier to the transaction message, and mapping such cross-day transaction messages to the storage partitions of two adjacent trading days for storage at the same time; When the recorded transaction messages include transaction messages continuously collected on multiple trading days, automatically generating storage partitions according to the daily cut time threshold to ensure that each storage partition contains the transaction messages in the complete transition period before and after the daily cut time of the trading day.

3. The method for system testing according to claim 2, wherein Selecting the corresponding message collection according to the playback instruction, and adjusting the playback rate according to the playback instruction and playing back to the new system further includes: Generating the playback instruction according to the test requirements of the new system, the test result, and the real-time load status of the system resources; Selecting the corresponding message collection according to the test requirements and the trading day and business type in the annotation of the real-time transaction information; Adjusting the playback rate of the transaction message in real time dynamically according to the real-time load status of the system resources; Playing back the corresponding message collection to the new system according to the playback rate.

4. The method for system testing according to claim 3, characterized in that, Generating the playback instruction according to the test requirements of the new system, the test result, and the real-time load status of the system resources further includes: The test result of the new system includes the calculation rate of the new system, the message response time, and the correct rate of the response message; Judging whether the test result meets the expectation according to the preset target calculation rate, target response time, and correct rate threshold; If the test result does not meet the expectation, adjusting the playback rate in the playback instruction, and playing back the corresponding message collection to the new system according to the adjusted playback rate.

5. The method for system testing according to claim 3, wherein Generating the playback instruction according to the test requirements of the new system, the test result, and the real-time load status of the system resources further includes: Generating the time density feature of the original transaction according to the timestamp of the transaction message, and adjusting the playback rate of the transaction message according to the time density feature.

6. The method for system testing according to claim 1, characterized in that Comparing the second response message generated by the new system with the first response message further includes: The old system is a monolithic core system, and the new system is a distributed system.

7. A system testing device, characterized in that, The device includes: A transaction flow acquisition unit, configured to capture in real time the transaction flow received by the old system and its corresponding first response message, and annotate the real-time transaction information of the transaction flow; A transaction flow recording unit, configured to obtain relevant configurations according to the real-time transaction information, and screen and record the transaction flow according to the configurations; A transaction message storage unit, configured to store the transaction messages generated by recording in partitions according to the annotation, and generate message collections of different business types; A transaction message playback unit, configured to select a corresponding message collection according to a playback instruction, and adjust the playback rate according to the playback instruction and playback it to the new system; A test result generation unit, configured to compare the second response message generated by the new system with the first response message, and generate a test result of the new system.

8. A computer device, comprising a memory, a processor, and a computer program stored on the memory, characterized in that, When the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and when the computer program is executed by the processor, the method according to any one of claims 1 to 6 is implemented.

10. A computer program product, characterized in that, The computer program product includes a computer program, and when the computer program is executed by the processor, the method according to any one of claims 1 to 6 is implemented.

Images