Baffle testing method and apparatus

Abstract

This invention discloses a baffle testing method and apparatus, relating to the field of testing technology and also applicable to the financial field. The method includes: receiving first request messages sent by at least one system under test, wherein each first request message includes transaction identification code information; obtaining transaction information of the current transaction corresponding to each first request message based on the transaction identification code information; determining the target system type corresponding to each first request message based on the transaction information; adjusting the first request message according to the target system type to obtain a second request message corresponding to the first request message; and generating a target response message for each first request message based on the second request message corresponding to the first request message. This invention can support concurrent requests from multiple test environments, making full use of system resources.

Description

Technical Field

[0001] This invention relates to the field of testing technology, and can also be used in the financial field, particularly to a baffle testing method and apparatus. Background Technology

[0002] In the face of the increasing reliance on and complexity of external systems in the software development industry, especially in the banking sector's testing field, building efficient and flexible testing environments has become crucial for improving development efficiency and ensuring system quality. Against this backdrop, squeegee services, as an effective means of simulating interactions with external systems, are becoming increasingly important. However, the limitations of traditional squeegee tools, such as static responses, high barriers to entry, and potential security risks, urgently necessitate a new type of squeegee tool.

[0003] This section is intended to provide background or context for the embodiments of the invention set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section. Summary of the Invention

[0004] This invention provides a baffle testing method to support concurrent requests from multiple test environments and fully utilize system resources. The method includes:

[0005] Receive at least one first request message sent by a system under test, wherein each first request message includes transaction identification code information;

[0006] Based on the transaction identification code information of each first request message, obtain the transaction information of the current transaction corresponding to the first request message from the architecture management system;

[0007] Based on the transaction information corresponding to each first request message, determine the target system type corresponding to the first request message;

[0008] Based on the target system type corresponding to each first request message, the first request message is adjusted to obtain the second request message corresponding to the first request message;

[0009] Based on the second request message corresponding to each first request message, a target response message for the first request message is generated, and the target response message for the first request message is sent to the system under test corresponding to the first request message.

[0010] In some embodiments, adjusting the first request message according to the target system type corresponding to each first request message to obtain a second request message corresponding to the first request message includes:

[0011] The at least one first request message is grouped according to the target system type corresponding to each first request message;

[0012] Based on the grouping results, a destination identifier is added to each of the first request messages to obtain the second request message corresponding to the first request message.

[0013] In some embodiments, generating a target response message for each first request message based on a second request message corresponding to that first request message includes:

[0014] For each of the first request messages

[0015] Extract key information from the second request message;

[0016] The key information is matched with the baffle rules of the second request message corresponding to the first request message to obtain the matching result;

[0017] The target response message for the first request message is generated based on the matching result.

[0018] In some embodiments, generating the target response message of the first request message based on the matching result includes:

[0019] If the matching result is a successful match, then at least two response results are determined based on the first request message;

[0020] Construct test data that conforms to at least two of the aforementioned response results;

[0021] At least two target response messages are generated based on the test data, wherein the response result includes at least one of the following: success, failure, or partial success.

[0022] In some embodiments, generating the target response message of the first request message based on the matching result includes:

[0023] If the matching result is unsuccessful, then obtain the historical transaction record information;

[0024] The first request message is compared with the historical request messages in the historical transaction record information to determine their similarity.

[0025] The historical request message with the highest similarity to the first request message is selected as the reference request message, and the historical response message corresponding to the reference request message is selected as the target response message of the first request message.

[0026] In some embodiments, generating a target response message for each first request message based on a second request message corresponding to each first request message, and sending the target response message to the system under test corresponding to the first request message, includes:

[0027] For each first request message,

[0028] Based on the second request message corresponding to the first request message, generate the target response message of the first request message;

[0029] Based on the transaction scenario, the response configuration items of the target response message of the first request message are dynamically adjusted to obtain the adjusted target response message of the first request message.

[0030] The adjusted target response message is sent to the system under test corresponding to the first request message.

[0031] In some embodiments, the method further includes:

[0032] Intercept the first request message sent by the system under test;

[0033] Determine whether each of the first request messages conforms to the preset detection rules;

[0034] If the first request message meets the preset detection rules, then the first request message is accepted.

[0035] In some embodiments, the method further includes:

[0036] If the first request message does not meet the preset detection rules, the first request message will be sent to the original application system corresponding to the first request message.

[0037] The original application system that receives the first request message sends a target response message in response to the first request message.

[0038] The target response message is sent to the system under test corresponding to the first request message.

[0039] This invention also provides a baffle testing device to support concurrent requests from multiple testing environments, thus fully utilizing system resources. The device includes:

[0040] The relay module is used to receive a first request message sent by at least one system under test, wherein each first request message includes transaction identification code information;

[0041] The acquisition module is used to acquire the transaction information of the current transaction corresponding to each first request message from the architecture management system based on the transaction identification code information of each first request message;

[0042] The determining module is used to determine the target system type corresponding to each first request message based on the transaction information corresponding to each first request message;

[0043] The adjustment module is used to adjust the first request message according to the target system type corresponding to each first request message to obtain the second request message corresponding to the first request message;

[0044] The data processing module is used to generate a target response message for each first request message based on the second request message corresponding to each first request message, and send the target response message of the first request message to the system under test corresponding to the first request message.

[0045] In some embodiments, the adjustment module includes:

[0046] A grouping module is used to group the at least one first request message according to the target system type corresponding to each first request message;

[0047] An adding module is used to add a destination identifier to each of the first request messages based on the grouping results, so as to obtain the second request message corresponding to the first request message.

[0048] In some embodiments, for each of the first request messages, the data processing module includes:

[0049] The extraction module is used to extract key information from the second request message;

[0050] The matching module is used to match the key information with the baffle rules of the second request message corresponding to the first request message to obtain the matching result;

[0051] The generation module is used to generate the target response message of the first request message based on the matching result.

[0052] In some embodiments, the generation module includes:

[0053] A determination submodule is configured to determine at least two response results based on the first request message when the matching result is a successful match.

[0054] A construction module is used to construct test data that conforms to the at least two response results;

[0055] A generation submodule is used to generate at least two target response messages based on the test data, wherein the response result includes at least one of the following: success, failure, and partial success.

[0056] In some embodiments, the generation module further includes:

[0057] The acquisition module is used to acquire historical transaction record information when the matching result is unsuccessful.

[0058] The evaluation module is used to evaluate the similarity between the first request message and the historical request messages in the historical transaction record information;

[0059] The selection module is used to select the historical request message with the highest similarity to the first request message as the reference request message, and to use the historical response message corresponding to the reference request message as the target response message of the first request message.

[0060] In some embodiments, for each first request message, the data processing module includes:

[0061] The dynamic adjustment module is used to dynamically adjust the response configuration items of the target response message of the first request message based on the transaction scenario, so as to obtain the adjusted target response message of the first request message.

[0062] The sending module is used to send the adjusted target response message to the system under test corresponding to the first request message.

[0063] In some embodiments, the relay module includes:

[0064] The interception module is used to intercept the first request message sent by the system under test;

[0065] The judgment module is used to determine whether each of the first request messages conforms to the preset detection rules;

[0066] The receiving module is used to receive the first request message when the first request message meets the preset detection rules.

[0067] In some embodiments, the relay module further includes:

[0068] The sending submodule is used to send the first request message to the original application system corresponding to the first request message when the first request message does not meet the preset detection rules;

[0069] The receiving module is further configured to receive the target response message fed back by the original application system corresponding to the first request message in response to the first request message;

[0070] The sending submodule is further configured to send the target response message to the system under test corresponding to the first request message.

[0071] Thirdly, embodiments of the present invention also provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described baffle testing method.

[0072] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described baffle testing method.

[0073] Fifthly, embodiments of the present invention also provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the above-described baffle testing method.

[0074] The stencil testing method and apparatus provided in this invention can simultaneously receive first request messages sent by one or more different systems under test. This invention determines the target system type corresponding to each first request message through the transaction identification code information in each first request message, thereby adjusting the first request message to obtain its corresponding second request message. Furthermore, the second request message can be used to distinguish the target system corresponding to each of the multiple first request messages, ultimately obtaining the target response message corresponding to each first request message based on the target system. The stencil testing method provided by this invention supports concurrent requests from multiple test environments, fully utilizes system resources, enables cross-team and cross-platform stencil sharing, reduces the workload of developers, minimizes human resource waste, and improves testing efficiency. Simultaneously, the stencil testing method provided by this invention requires no coding background, has a low barrier to entry, and the stencil is deployed non-intrusively, making deployment simple; changes to the configuration will not affect the running system under test. Attached Figure Description

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

[0076] Figure 1 A flowchart of a baffle testing process provided in an embodiment of the present invention;

[0077] Figure 2 A flowchart of a baffle testing method provided in an embodiment of the present invention;

[0078] Figure 3 A baffle testing device provided in an embodiment of the present invention;

[0079] Figure 4 This invention provides yet another baffle testing device.

[0080] Figure 5 A structural block diagram of a data processing module provided in an embodiment of this disclosure;

[0081] Figure 6 A flowchart of a baffle test is provided for this invention;

[0082] Figure 7 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0083] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0084] The information collected in the technical solution of this application is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with relevant laws, regulations and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation portals are provided for users to choose to authorize or refuse.

[0085] The acquisition, transmission, storage, use, and processing of data in this application all comply with the relevant provisions of laws and regulations.

[0086] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0087] In existing technologies, tools such as WireMock, Postman, Fiddler, and SoapUI are commonly used to perform block testing by defining a mock service, creating a mock interface, defining response rules, and starting the mock service. However, these tools have the following drawbacks:

[0088] (1) It has a high barrier to entry, requires coding skills, and has a certain learning cost.

[0089] (2) It is not custom-developed for bank application systems and has poor support for internal bank systems.

[0090] (3) The logic response is fixed and cannot accurately respond to the test requirements of multiple logic branches.

[0091] To address the aforementioned problems in existing technologies, in a first aspect, this invention provides a baffle testing method. This baffle testing method not only reduces the complexity and time cost of test preparation but also improves test coverage and response speed, achieving a high degree of simulation of external system interactions. The core advantage of the baffle testing method provided by this invention lies in its ability to flexibly adjust logic according to different test scenarios, thereby improving testing efficiency and accuracy, effectively simulating complex and ever-changing business environments, and providing strong support for software quality assurance.

[0092] First, the business process of the baffle testing method involved in this invention is introduced.

[0093] Figure 1 This is a flowchart illustrating a baffle testing process provided in an embodiment of the present invention. Figure 1 As shown, the business process includes the following steps:

[0094] Step YS1, Requirements Analysis.

[0095] First, it's necessary to confirm the test environment for the beacon test, which determines which specific systems the beacon needs to be deployed to. Then, it's necessary to obtain the transaction code definition document; understanding the request message logic based on this document is crucial for setting matching rules effectively. Next, it's essential to analyze the transaction call relationships to understand which transaction requests are being made upstream and downstream. Finally, the beacon response rules must be analyzed to meet the testing requirements.

[0096] Step YS2: Configure baffle parameters.

[0097] Transaction codes are typically unique identifiers for business operations, and are particularly important in financial transaction systems. For comprehensive test coverage, it's necessary to collect all relevant transaction codes and their corresponding functional descriptions. This step can be accomplished by reading system documentation or extracting information directly from system interface logs. After collection, these transaction codes are compiled into a list, and the expected inputs, outputs, and possible exceptions for each transaction code are defined, providing a foundation for subsequent test design. The physical system to which the system under test belongs is added, the transaction codes to be tested are added, transaction keyword information for the baffle service items is set, and transaction code response rules are designed.

[0098] Step YS3: Configure the baffle application.

[0099] The baffle application is launched on the server of the system under test. The present invention adopts a non-intrusive design for testing the system under test. Because it is a non-intrusive design, there is no need to modify the code of the system under test or restart the system under test.

[0100] Step YS4: Adjust the baffle.

[0101] By actually calling the function, we can verify whether the baffle's response to different transaction codes meets expectations.

[0102] Step YS5: Determine if the baffle adjustment was successful.

[0103] If the baffle adjustment fails, proceed to step YS1 or step YS2. If the baffle adjustment succeeds, proceed to step YS6 and put it into use.

[0104] If any anomalies are detected, adjust the configuration or rules quickly based on the log feedback until verification is successful and the baffle is officially enabled.

[0105] Based on the above-described baffle testing process, the baffle testing method of the present invention will be described below through specific embodiments.

[0106] Figure 2 This is a flowchart illustrating a baffle testing method provided in an embodiment of the present invention. Figure 2 As shown, the method includes the following steps:

[0107] S1. Receive at least one first request message sent by the system under test, wherein each first request message includes transaction identification code information.

[0108] In this context, the system under test (SUBST) refers to the server that the baffle needs to test. A single SUBST can send only one first request message, while multiple SUBSTs correspond to multiple first request messages. Of course, a single SUBST can also send multiple different first request messages to test various functions of that SUBST; this invention does not impose any limitations on this. When multiple first request messages are received, this baffle testing method can support concurrent requests from multiple test environments, making full use of system resources.

[0109] Specifically, the baffle includes at least one relay module deployed on the system under test (DUT) to receive the first request message sent by the DUT. The relay module needs to be deployed on each DUT, adhering to the principle of non-intrusion, meaning it can monitor the behavior of the DUT and capture data without affecting its normal operation. This feature avoids the risk of modifying application code for testing purposes, maintains the original state and functional integrity of the software, and reduces the possibility of introducing new errors.

[0110] This invention eliminates the need to modify the code under test, significantly simplifying the testing process. Development teams no longer need to adjust production code to meet testing requirements, reducing test preparation time and collaboration costs between development and testing, making testing activities more flexible and autonomous. Furthermore, the relay module does not require a restart of the service under test after startup, which is crucial for continuously operating production environments. Hot deployment capabilities ensure service continuity and stability, preventing service interruptions due to test intervention, aligning with modern enterprises' pursuit of high availability.

[0111] Furthermore, this module consumes limited server resources after startup, ensuring that testing activities do not become a burden on server performance. This is especially crucial in resource-constrained environments, particularly when testing needs to be conducted in a production-like environment; minimizing the impact of testing on system resources is essential for maintaining system stability.

[0112] Each first request message corresponds to one transaction, and each transaction has a unique transaction identifier used to identify it. When any transaction is initiated, the first request message corresponding to that transaction includes this specific transaction identifier. This transaction identifier can be a simple identifier or other identifier; this invention does not impose any restrictions on this.

[0113] S2. Based on the transaction identification code information of each first request message, obtain the transaction information of the current transaction corresponding to the first request message from the architecture management system.

[0114] Specifically, the architecture management system stores detailed transaction information for each transaction involved in the system under test. This transaction information includes, but is not limited to, the transaction identifier corresponding to the transaction, the requester and responder information, and other additional details of the transaction content.

[0115] Upon receiving multiple first request messages, the key transaction identification code information is first extracted from each first request message. Subsequently, the identification code in this transaction identification code information can be used as a query parameter to send a request to the architecture management system to obtain specific ownership information and additional details of the transaction corresponding to the first request message.

[0116] S3. Based on the transaction information corresponding to each first request message, determine the target system type corresponding to the first request message.

[0117] Specifically, the target system corresponding to the first request message refers to the target system to which the transaction corresponding to the first request message will be routed. This target system is capable of generating a corresponding response message based on the first request message, and the response messages generated by different target systems based on the first request message are not exactly the same.

[0118] The target system types include internal business systems and external business systems. Internal business systems refer to systems within the bank, including clearing systems and risk control systems. External business systems refer to systems from external partners, including systems from the People's Bank of China's credit reporting service and insurance company platforms.

[0119] S4. Adjust the first request message according to the target system type corresponding to each first request message to obtain the second request message corresponding to the first request message.

[0120] Specifically, the second request message has a one-to-one correspondence with the first request message, and the target system type to which each transaction corresponding to the first request message will be routed can be determined based on the second request message generated after adjusting the first request message.

[0121] S5. Based on the second request message corresponding to each first request message, generate the target response message of the first request message, and send the target response message of the first request message to the system under test corresponding to the first request message.

[0122] Specifically, based on the second request message generated after adjusting the first request message, the target system type corresponding to the first request message can be determined. Thus, the baffle can obtain the target response message of the first request message from the target system type corresponding to the first request message, and send the target response message to the system under test corresponding to the first request message, thus completing the entire baffle testing process.

[0123] In the testing environment, to comply with regulations against using real customer data, the stencil testing method provided by this invention simulates external responses such as those from the People's Bank of China's credit reporting system, thereby supporting complete transaction process testing without exposing sensitive information. For example, in a credit card account opening scenario, the applicant's credit history needs to be checked first. The credit card system then generates a first request message with a unique transaction code, which contains the applicant's basic information. After processing as described above, this first request message is forwarded to the People's Bank of China's credit reporting system and the bank's internal risk control system. During the testing phase, stencil technology is used to simulate the response behavior of these two systems, thus completing the entire pre-card opening qualification review process. This approach not only ensures that operations comply with regulatory requirements but also improves development efficiency and quality control.

[0124] The stencil testing method provided by this invention can simultaneously receive first request messages sent by one or more different systems under test. This invention determines the target system type corresponding to each first request message through the transaction identification code information in each first request message, thereby adjusting the first request message to obtain its corresponding second request message. Furthermore, it can distinguish the target system corresponding to each of the multiple first request messages based on the second request message, and finally obtain the target response message corresponding to each first request message based on the target system. This stencil testing method provides support concurrent requests from multiple test environments, fully utilizes system resources, enables cross-team and cross-platform stencil sharing, reduces the workload of developers, minimizes human resource waste, and improves testing efficiency. Simultaneously, the stencil testing method provided by this invention requires no coding background, has a low barrier to entry, and the relay module deployed in the system under test is non-intrusive, simple to deploy, and configuration changes will not affect the running system under test.

[0125] In some embodiments, step S4, adjusting the first request message according to the target system type corresponding to each first request message to obtain a second request message corresponding to the first request message, specifically includes the following steps:

[0126] S41. Group the at least one first request message according to the target system type corresponding to each first request message.

[0127] S42. Based on the grouping result, add a destination identifier to each first request message to obtain the second request message corresponding to the first request message.

[0128] The destination identifier can identify the target system to which the transaction corresponding to the first request message will be routed. Optionally, the destination identifier can be the specific name of the target system to which the transaction corresponding to the first request message will be routed. This invention can preliminarily group first request messages sent by at least one system under test based on the target system name corresponding to the first request message. First request messages corresponding to the same target system name are grouped together, and the rules for generating target response messages within the same group are the same.

[0129] Optionally, the present invention can also pre-group different systems under test logically according to their physical system names. This automated grouping method, relying on the data interface between the system under test and other platforms, can directly import the physical system names of external systems, thereby completely freeing test and development personnel from manual data entry, greatly reducing their burden, and allowing them to focus more on core test design and development tasks.

[0130] Optionally, the destination identifier can also be the response message logic of the target system to which the transaction corresponding to the first request message will be routed. The present invention can also preliminarily group first request messages sent by at least one system under test according to the logic of the target system corresponding to the first request message in generating response messages. First request messages corresponding to the same target system in generating response messages are grouped together, and the rules for generating target response messages within the same group are the same.

[0131] Each group contains various external / internal systems related to the system under test. This mapping ensures a high degree of matching between the test environment and real business scenarios. In this way, the test plan can more accurately simulate the interactions between different systems, improving the accuracy and coverage of the tests and helping to identify and resolve potential integration problems in advance.

[0132] In this configuration mode, the relationship between the system under test and its corresponding transaction code blocking rules is more intuitive. Blocking rules refer to the processing logic set for specific transaction codes during testing, such as simulating responses and intercepting requests, to simulate various situations in actual operation. Because the systems under test are clearly grouped, the classification and management of these rules become more orderly, easier to identify and adjust, effectively preventing rule confusion and improving maintenance efficiency.

[0133] This invention pre-groups first request messages sent by at least one system under test according to the target system type corresponding to each first request message. This distinguishes the response message generation rules of the target system corresponding to each first request message in multiple first request messages, thereby ultimately obtaining the target response message corresponding to each first request message based on the target system. The stencil testing method provided by this invention supports concurrent requests from multiple test environments, fully utilizes system resources, enables cross-team and cross-platform stencil sharing, reduces the workload of developers, minimizes waste of human resources, and improves testing efficiency.

[0134] In some embodiments, step S5, generating a target response message for each first request message based on the second request message corresponding to each first request message, specifically includes performing the following steps for each first request message:

[0135] S51. Extract key information from the second request message.

[0136] S52. Match the key information with the baffle rules of the second request message corresponding to the first request message to obtain the matching result.

[0137] S53. Generate the target response message of the first request message based on the matching result.

[0138] Specifically, when the baffle receives a second request message, it first parses it to extract key information. Optionally, this key information can be keywords or key logic from the first request message. Optionally, this key information is used as the basis for querying the hash table. A hash table (also known as a hash table) is used to store the tag information in the baffle rules. The hash table determines its storage location by calculating the hash value of the keyword, which makes the lookup time complexity close to O(1), that is, almost unaffected by the size of the data. Each tag or keyword is mapped to a unique index in the hash table, and the corresponding value can be all the baffle rules related to that tag or pointers to those rules. Subsequently, the system begins to traverse the hash table, comparing the list of keywords in each second request message with the tag information stored in the hash table. This process may involve multi-level matching, such as first matching the HTTP method, then the URL path, and finally specific fields in the request header or request body. Each step of matching is to narrow down the range of potential baffle rules until a completely matching rule is found, generating the target response message for the first request message.

[0139] Furthermore, regular expressions are a powerful and flexible text matching tool. This invention can use regular expressions to check whether specific fields in a second request message meet preset format or content rules (smudge rules). For example, to verify whether the order number in a transaction request is a 16-character alphanumeric combination, this step uses regular expressions to verify whether the values ​​of specific fields in the test transaction request message meet the expected conditions. Then, according to the user-preset response configuration rules, the corresponding response message information is generated.

[0140] In some embodiments, the baffle testing method includes not only steps S1 to S5 as described above, but also, before step S5, encapsulating the second request message according to a standard format. Here, the standard format refers to the format corresponding to the parsing rule. Thus, multiple second request messages are encapsulated using the same rule, allowing the same parsing rule to be used when parsing the second request messages, thereby improving the efficiency of parsing the second request messages.

[0141] In some embodiments, step S53, generating the target response message of the first request message based on the matching result, includes the following steps:

[0142] S531. If the matching result is a successful match, then at least two response results are determined based on the first request message.

[0143] S532. Construct test data that conforms to the at least two response results.

[0144] S533. Generate at least two target response messages based on the test data, wherein the response result includes at least one of the following: success, failure, and partial success.

[0145] Specifically, if the matching result is successful, it indicates that the barrier pre-stores target response messages with multiple response results corresponding to the first request message. The barrier testing method provided in this disclosure configures multiple possible response results for the transaction code corresponding to the same first request message, such as success, failure, partial success, etc., covering more comprehensive test cases according to different scenario requirements. For example, in the scenario of applying for a car installment loan with a credit card, querying the installment approval result is a complex task. During testing, it is necessary to simulate different financial institutions and counter roles, and construct diverse judgment conditions to generate corresponding test data. These judgment conditions include, but are not limited to: age requirements, identity verification, residential stability, income level and occupation, credit history, down payment ability, provision of guarantees or collateral, and marital status. The system's response will vary depending on the different combinations of these factors. For example, if the applicant's age, credit history, or down payment ability does not meet the standards, it may directly lead to the loan application being rejected; while for other conditions, the system may only issue a low-risk warning rather than immediately rejecting the application. This invention utilizes intelligent barrier services to greatly simplify this process. The smart swatch can quickly generate test data that meets various preset conditions, and then generate corresponding target response messages based on the test data, effectively reducing the workload of testers. This approach not only improves testing efficiency but also ensures more comprehensive coverage of all potential situations, helping development teams more accurately evaluate the performance of new features under different user contexts, ultimately leading to a significant improvement in product quality. Furthermore, with the help of smart swatch technology, teams can complete more test case analyses in a shorter time, accelerating product iteration to better meet market demands.

[0146] In some embodiments, step S53, generating the target response message of the first request message based on the matching result, includes the following steps:

[0147] S534. If the matching result is unsuccessful, then obtain historical transaction record information.

[0148] S535. Perform a similarity assessment between the first request message and the historical request messages in the historical transaction record information.

[0149] S536. Select the historical request message with the highest similarity to the first request message as the reference request message, and use the historical response message corresponding to the reference request message as the target response message of the first request message.

[0150] Specifically, if the matching result is unsuccessful, it means that there is no pre-set response message corresponding to the first request message on the baffle. For first request messages that cannot match the baffle rules, the present invention adopts an intelligent response strategy, namely, enabling intelligent baffle logic. This process involves a deep understanding and flexible processing capability of the first request message. When the baffle recognizes that a first request message does not conform to the established baffle rules, it will not simply refuse service or return an error message, but will switch to a more complex processing mechanism.

[0151] Specifically, the intelligent baffle automatically connects to a message monitoring platform, which collects and stores transaction information from all relevant servers. This transaction information covers several key fields, such as transaction identifier, physical system name, request message, response message, request time, and specific server information. By comprehensively recording this data, the transaction platform can not only ensure the transparency and traceability of each transaction but also provide strong support for subsequent data analysis and troubleshooting. Through advanced algorithms and data analysis, the intelligent baffle searches for existing real response messages in this historical data that are closest to or related to the current first request message. The intelligent baffle service searches the transaction monitoring platform, queries the transaction records with successful responses within the most recent preset time period (e.g., within the last 24 hours) based on the transaction identifier, extracts the request messages, evaluates the similarity between the request parameters of each historical request message and the current first request message, and finally selects the record with the closest parameters. Once selected, the intelligent baffle service directly feeds back the response message corresponding to this record as a reference answer or simulated reply to the system under test. This approach aims to simulate feedback that most closely resembles real-world scenarios, ensuring a reasonable and consistent response even in the face of unexpected requests, thereby maintaining stable system operation and a consistent user experience.

[0152] The advantage of this strategy lies in its ability to effectively manage unexpected traffic, preventing system disruptions due to abnormal requests, and providing dynamic adaptability, making the system more robust and flexible in the face of complex and ever-changing network environments. By reusing successful historical interaction examples, intelligent baffle logic reduces the need for manual intervention and improves the level of automation, making it an indispensable part of modern high-performance systems, especially in applications requiring high availability and fault tolerance.

[0153] The baffle testing method provided by this invention can generate a target response message regardless of whether the first request message matches the response rules in the message platform. This is to ensure that the baffle system can provide a basic feedback mechanism no matter how the test scenario changes. The design of the response configuration items is highly flexible, and can include static, fixed message information, or be designed as a dynamic, parameterized structure to adapt to complex and ever-changing test requirements.

[0154] In some embodiments, step S5 involves generating a target response message for each first request message based on the second request message corresponding to that first request message, and sending the target response message to the system under test corresponding to that first request message. This includes performing the following steps for each first request message:

[0155] S54. Generate the target response message of the first request message based on the second request message corresponding to the first request message.

[0156] S55. Based on the transaction scenario, dynamically adjust the response configuration items of the target response message of the first request message to obtain the adjusted target response message of the first request message.

[0157] S56. The adjusted target response message is sent to the system under test corresponding to the first request message.

[0158] Specifically, the transaction scenario includes the time, location, and characteristics of the transaction content. The baffle testing method provided by this invention can also dynamically adjust the generated target response message based on the transaction scenario.

[0159] This invention, in addition to directly replacing parameters, involves complex data processing logic, such as date format conversion, currency unit conversion, and data encryption / decryption. These data conversion rules are pre-defined according to business needs and automatically applied during response construction, meeting the requirements of actual business scenarios. For example, in cross-border banking transactions, the baffle system needs to dynamically adjust the date and currency display formats based on language preferences or regional settings in the request. Furthermore, it can also adjust dynamic variables in the target response message in real time based on upstream and downstream information. For example, it can dynamically adjust variable information such as serial number and timestamp in the target response message based on upstream and downstream information.

[0160] The baffle testing method provided by this invention uses dynamic response messages, which makes the testing environment more closely resemble the complexity of the production environment, effectively improving the test coverage and the realism of the test results. It can simulate various edge cases and abnormal processes.

[0161] For scenarios with clearly defined testing objectives and no need for dynamic changes, static response messages ensure the consistency and predictability of test results for each test. This consistency is fundamental to verifying system stability and reliability, helps in quickly locating problems, reduces uncertainty in test results caused by response changes, and thus improves overall testing efficiency. Compared to dynamic responses, using static messages reduces the demand for computing resources during testing. Since there is no need for real-time calculations or database queries, this is particularly important in large-scale automated testing or continuous integration / continuous deployment (CI / CD) processes, effectively reducing server load and saving computing resources. This type of configuration simplifies the testing process; once the beacon system recognizes specific test request keywords, it can directly extract the corresponding message from the pre-set library and send it to the system under test. Test engineers only need to predefine the expected response template, and the system can automatically respond to the template when specific trigger conditions are detected, greatly simplifying test preparation and accelerating the testing cycle.

[0162] In some embodiments, the baffle testing method includes not only steps S1 to S5, but also the following steps before performing step S1:

[0163] S00: Intercept the first request message sent by the system under test.

[0164] S01. Determine whether each of the first request messages conforms to the preset detection rules.

[0165] If the first request message meets the preset detection rules, then step S1 is executed to receive the first request message.

[0166] In some embodiments, if the first request message does not conform to the preset detection rules, the following steps are performed:

[0167] S02. Send the first request message to the original application system corresponding to the first request message.

[0168] S03. Receive the target response message from the original application system corresponding to the first request message.

[0169] S04. Send the target response message to the system under test corresponding to the first request message.

[0170] The detection rule can be a specific transaction code, IP address, or port number, used to determine whether the first request message sent by the system under test can simulate the corresponding target response message through the barrier.

[0171] Specifically, the shielding system includes a relay module deployed on the server of the system under test. First, this relay module intercepts the first request message sent by the system under test. Then, it checks all first request messages of transaction requests sent by the system under test according to detection rules (transaction code, IP address, and port number). If a match is found, the shield performs further data processing on the first request message. If no match is found, a pass-through shielding technique is used to directly obtain the corresponding target response message from the application system corresponding to the first request message. This pass-through shielding technique, also known as pass-through service or bypass mode, plays a crucial role in software testing, especially in integration and system testing phases. The core of this technique is that it allows transaction requests in the test environment to bypass the conventional processing flow and directly penetrate (or bypass) the intermediate test or monitoring shield to reach the target external application server. This ensures that test data or simulated transactions can access the actual business processing logic, thereby obtaining response messages that most closely resemble real-world scenarios.

[0172] The slat testing method provided by this invention utilizes a slat service with a highly organized and intelligent design to achieve precise processing and response generation of test requests, greatly improving the practicality and efficiency of testing. The core mechanism of this service lies in its refined layering and classification strategy, as well as its dynamic response capability. Based on keyword information, the first request message is initially classified according to the target system type, ensuring that the test environment can simulate the interaction of multiple independent systems. On this basis, field data is further used to determine whether it conforms to slat rules, further subdividing the first request message into different business logic branches. This two-layer classification method not only organizes test resources in an orderly manner but also ensures a high degree of relevance to the test scenarios. This process involves intelligent parsing of key fields in the first request message, thereby achieving accurate matching of test requirements. Subsequently, based on the matched business logic branch, the corresponding response configuration item is selected, and the target response message is dynamically generated. Compared with existing testing solutions, this slat response service, through the above mechanism, can provide more appropriate simulations in a wider range of business scenarios and logical complexities. It can not only handle standardized test requirements but also effectively cope with special or edge cases, ensuring the comprehensiveness and depth of test coverage. Most importantly, the service can flexibly respond to ever-changing testing needs. Especially in environments with rapid development iterations and ever-changing business logic, it can quickly adapt to new testing scenarios by dynamically adjusting response configuration items without frequently modifying the underlying code or testing framework, significantly reducing maintenance costs and test preparation time.

[0173] Based on the same invention, in a second aspect, the present invention also provides a baffle testing device, as described in the following embodiments. Since the principle by which this device solves the problem is similar to the baffle testing method provided in the first aspect, the implementation of this device can refer to the implementation of the baffle testing method described above, and repeated details will not be elaborated further.

[0174] Figure 3 A baffle testing device 300 is provided as an embodiment of the present invention. For example... Figure 3 As shown, the baffle testing device 300 includes a relay module 301, a data filtering module 302, and a data processing module 303.

[0175] The relay module 301 is used to receive a first request message sent by at least one system under test, wherein each first request message includes transaction identification code information.

[0176] Specifically, relay module 301 needs to be deployed on each server under test. It adheres to the principle of non-intrusion, meaning it can monitor system behavior and capture data without affecting the normal operation of the system under test. This feature avoids the risk of modifying application code for testing purposes, maintains the original state and functional integrity of the software, and reduces the possibility of introducing new errors.

[0177] The fact that no changes are needed to the code under test greatly simplifies the testing process. Development teams no longer need to adjust production code specifically to meet testing requirements, reducing test preparation time and collaboration costs between development and testing, making testing activities more flexible and autonomous.

[0178] The relay module 301 does not require a restart of the service under test after startup, which is crucial for continuously operating production environments. Hot deployment capability ensures service continuity and stability, avoiding service interruptions caused by test intervention, meeting the high availability requirements of modern enterprises.

[0179] After the relay module 301 starts, it consumes limited server resources, ensuring that testing activities do not become a burden on server performance. This is especially critical in resource-constrained environments, particularly when testing needs to be conducted in a production-like environment; minimizing the impact of testing on system resources is essential for maintaining system stability.

[0180] The data filtering module 302 is used to group the received first request message to obtain a second request message corresponding to the first request message.

[0181] Specifically, the data filtering module 302 logically groups different systems under test, with each group containing various related external systems. This mapping relationship ensures a high degree of matching between the test environment and real business scenarios. In this way, the test plan can more accurately simulate the interaction between different external systems, improving the accuracy and coverage of the test and helping to identify and resolve potential integration problems in advance.

[0182] In this configuration mode, the relationship between the system under test and its corresponding transaction code blocking rules is more intuitive. Blocking rules refer to the processing logic set for specific transaction codes during testing, such as simulating responses and intercepting requests, to simulate various situations in actual operation. Because the system is clearly grouped, the classification and management of these rules become more orderly, easier to identify and adjust, effectively preventing rule confusion and improving maintenance efficiency.

[0183] The data processing module 303 is used to generate a target response message for each first request message based on the second request message corresponding to each first request message, and send the target response message of the first request message to the system under test corresponding to the first request message.

[0184] Figure 4 Another baffle testing device 300 is provided as an embodiment of the present invention. For example... Figure 4 As shown, the baffle testing device 300 includes a relay module 301, a data filtering module 302, and a data processing module 303. The data filtering module 302 includes an acquisition module 312, a determination module 322, and an adjustment module 332.

[0185] The acquisition module 312 is used to acquire the transaction information of the current transaction corresponding to each first request message from the architecture management system based on the transaction identification code information of each first request message. The determination module 322 is used to determine the target system type corresponding to each first request message based on the transaction information corresponding to each first request message. The adjustment module 332 is used to adjust the first request message according to the target system type corresponding to each first request message to obtain the second request message corresponding to the first request message.

[0186] The baffle testing device provided by this invention deploys a relay module 301 on one or more systems under test (SUTs) to simultaneously receive first request messages sent by one or more different SUTs. A determination module 322 determines the target system type corresponding to each first request message based on the transaction identification code information in that first request message. This allows an adjustment module 332 to adjust the first request message to obtain its corresponding second request message. Furthermore, a data processing module 303 can distinguish the target system corresponding to each of the multiple first request messages based on the second request message, ultimately obtaining the target response message corresponding to each first request message based on the target system. This baffle testing device provides support concurrent requests from multiple test environments, fully utilizes system resources, enables cross-team and cross-platform baffle sharing, reduces the workload of developers, minimizes human resource waste, and improves testing efficiency.

[0187] In some embodiments, the adjustment module 332 includes a grouping module 132 and an adding module 232. The grouping module 132 is used to group the at least one first request message according to the target system type corresponding to each first request message. The adding module 232 is used to add a destination identifier to each first request message according to the grouping result, to obtain a second request message corresponding to that first request message.

[0188] In the baffle testing device provided by this invention, the grouping module 132 initially groups the first request messages sent by at least one system under test according to the target system type corresponding to each first request message. This distinguishes the response message generation rules of the target system corresponding to each first request message in multiple first request messages, thereby ultimately obtaining the target response message corresponding to each first request message based on the target system. The baffle testing device provided by this invention can support concurrent requests from multiple test environments, fully utilize system resources, realize cross-team and cross-platform baffle sharing, reduce the workload of developers, reduce human resource waste, and improve testing efficiency.

[0189] Figure 5 This is a structural block diagram of a data processing module 303 provided in an embodiment of the present disclosure.

[0190] like Figure 5 As shown, in some embodiments, the data processing module 303 includes an extraction module 313, a matching module 323, and a generation module 333. The extraction module 313 is used to extract key information from the second request message. The matching module 323 is used to match the key information with the stencil rules of the second request message corresponding to the first request message to obtain a matching result. The generation module 333 is used to generate a target response message for the first request message based on the matching result.

[0191] In some embodiments, the generation module 333 includes a determining submodule 10, a constructing submodule 20, and a generating submodule 30. The determining submodule 10 is used to determine at least two response results based on the first request message if the matching result is a successful match. The constructing submodule 20 is used to construct test data that conforms to the at least two response results. The generating submodule 30 is used to generate at least two target response messages based on the test data, wherein the response result includes at least one of the following: success, failure, and partial success.

[0192] The baffle testing device provided in this embodiment has a construction module 20 that constructs test data that conforms to at least two response results for the transaction code corresponding to the same first request message, so that the generation submodule 30 can generate multiple possible response results, such as success, failure, partial success, etc., and can cover more comprehensive test cases according to different scenario requirements.

[0193] In some embodiments, the generation module 333 further includes an acquisition module 40, an evaluation module 50, and a selection module 60. The acquisition module 40 is used to acquire historical transaction record information when the matching result is unsuccessful. The evaluation module 50 is used to perform a similarity assessment between the first request message and historical request messages in the historical transaction record information. The selection module 60 is used to select the historical request message with the highest similarity to the first request message as a reference request message, and to use the historical response message corresponding to the reference request message as the target response message for the first request message.

[0194] The baffle testing device provided by this invention can generate a target response message regardless of whether the first request message can match the response rules in the message platform. This is to ensure that the baffle system can provide a basic feedback mechanism no matter how the test scenario changes.

[0195] In some embodiments, the data processing module 303 further includes a dynamic adjustment module 343 and a sending module 353. The dynamic adjustment module 343 is used to dynamically adjust the response configuration items of the target response message of the first request message based on the transaction scenario, to obtain the adjusted target response message of the first request message. The sending module 353 is used to send the adjusted target response message to the system under test corresponding to the first request message.

[0196] The baffle testing device provided by this invention has extremely high design flexibility in response to configuration items. It can include static and fixed message information, or be designed as a dynamic and parameterized structure to adapt to complex and ever-changing testing requirements.

[0197] In some embodiments, the relay module 301 includes an interception module 351, a judgment module 321, and a receiving module 331. The interception module 351 intercepts first request messages sent by the system under test. The judgment module 321 determines whether each first request message conforms to a preset detection rule. The receiving module 331 receives the first request message if it conforms to the preset detection rule.

[0198] In some embodiments, the relay module 301 further includes a sending submodule 341, which is configured to send the first request message to the original application system corresponding to the first request message if the first request message does not conform to a preset detection rule. The receiving module 331 is further configured to receive the target response message fed back by the original application system corresponding to the first request message in response to the first request message. The sending submodule 341 is further configured to send the target response message to the system under test corresponding to the first request message.

[0199] The baffle testing device provided by this invention uses a relay module 301 to intercept the first request message sent by the system under test. Then, it detects all first request messages of transaction requests sent by the system under test according to detection rules (transaction code, IP address, and port number). If a match is found, the baffle performs further data processing on the first request message. If no match is found, a baffle-penetration technique is used to directly obtain the corresponding target response message from the application system corresponding to the first request message. The core of this baffle-penetration technique is that it allows transaction requests in the test environment to bypass the conventional processing flow and directly penetrate (or bypass) the intermediate test or monitoring baffle to reach the target external application server. This ensures that the test data or simulated transactions can access the actual business processing logic, thereby obtaining response messages that most closely resemble real-world scenarios.

[0200] Figure 6 The present invention provides a flowchart of a baffle test, which is applied to any of the baffle test devices 300 described above.

[0201] like Figure 6 As shown, the baffle test method specifically includes the following steps:

[0202] Relay module 301 executes step 1: intercept and analyze the request message, and determine whether the request message matches the detection rule.

[0203] If the request message does not match the detection rules, the relay module executes step 6: to make the request message pass through the barrier and directly obtain the response message corresponding to the request message from the original application system corresponding to the request message.

[0204] If the request message matches the detection rule, the data filtering module 302 executes step 2: encapsulates the request message into a standard format and sends the encapsulated request message to the data processing module 303.

[0205] The data processing module 303 executes step 3: receiving and parsing the request message, and performing baffle rule matching based on the parsed request message until a completely matching rule is found.

[0206] Furthermore, if a match is successful, the data processing module 303 executes step 4: generating a corresponding response message according to the user-preset response configuration rules. If a match fails, the data processing module 303 executes step 5: enabling the smart baffle logic to find the closest successful response message.

[0207] Finally, the data processing module 303 executes step 7: the response message generated by the speech shield test device is sent to the corresponding system under test.

[0208] It should be noted that, Figure 6 The corresponding flowchart is intended to illustrate the overall process of the baffle test provided in this disclosure. The specific details of each step can be found in any of the embodiments described above, and will not be repeated here.

[0209] It should also be noted that the baffle testing method provided in this embodiment of the invention can be used in the financial field, or in any technical field other than the financial field. This embodiment of the invention does not limit the application field of the virtual reality-based bank training system and its training method.

[0210] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the above-described baffle testing methods.

[0211] Figure 7 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention, such as... Figure 7 As shown, the electronic device includes: a processor 501, a memory 502, and a bus 503.

[0212] The processor 501 and the memory 502 communicate with each other via the bus 503.

[0213] The processor 501 is used to call program instructions in the memory 502 to execute the baffle testing method provided in the above-described method embodiments.

[0214] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described baffle testing method.

[0215] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described baffle testing method.

[0216] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0217] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0218] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0219] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0220] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A baffle testing method, characterized in that, The method includes: Receive at least one first request message sent by a system under test, wherein each first request message includes transaction identification code information; Based on the transaction identification code information of each first request message, obtain the transaction information of the current transaction corresponding to the first request message from the architecture management system; Based on the transaction information corresponding to each first request message, determine the target system type corresponding to the first request message; Based on the target system type corresponding to each first request message, the first request message is adjusted to obtain the second request message corresponding to the first request message; Based on the second request message corresponding to each first request message, a target response message for the first request message is generated, and the target response message for the first request message is sent to the system under test corresponding to the first request message.

2. The method according to claim 1, characterized in that, The step of adjusting the first request message according to the target system type corresponding to each first request message to obtain the second request message corresponding to the first request message includes: The at least one first request message is grouped according to the target system type corresponding to each first request message; Based on the grouping results, a destination identifier is added to each of the first request messages to obtain the second request message corresponding to the first request message.

3. The method according to claim 1, characterized in that, The step of generating a target response message for each first request message based on the second request message corresponding to that first request message includes: For each of the first request messages Extract key information from the second request message; The key information is matched with the baffle rules of the second request message corresponding to the first request message to obtain the matching result; The target response message for the first request message is generated based on the matching result.

4. The method according to claim 3, characterized in that, The step of generating the target response message for the first request message based on the matching result includes: If the matching result is a successful match, then at least two response results are determined based on the first request message; Construct test data that conforms to at least two of the aforementioned response results; At least two target response messages are generated based on the test data, wherein the response result includes at least one of the following: success, failure, or partial success.

5. The method according to claim 3, characterized in that, The step of generating the target response message for the first request message based on the matching result includes: If the matching result is unsuccessful, then obtain the historical transaction record information; The first request message is compared with the historical request messages in the historical transaction record information to determine their similarity. The historical request message with the highest similarity to the first request message is selected as the reference request message, and the historical response message corresponding to the reference request message is selected as the target response message of the first request message.

6. The method according to claim 1, characterized in that, The step of generating a target response message for each first request message based on a second request message corresponding to that first request message, and sending the target response message to the system under test corresponding to the first request message, includes: For each first request message, Based on the second request message corresponding to the first request message, generate the target response message of the first request message; Based on the transaction scenario, the response configuration items of the target response message of the first request message are dynamically adjusted to obtain the adjusted target response message of the first request message. The adjusted target response message is sent to the system under test corresponding to the first request message.

7. The method according to claim 1, characterized in that, The method further includes: Intercept the first request message sent by the system under test; Determine whether each of the first request messages conforms to the preset detection rules; If the first request message meets the preset detection rules, then the first request message is accepted.

8. The method according to claim 7, characterized in that, The method further includes: If the first request message does not meet the preset detection rules, the first request message will be sent to the original application system corresponding to the first request message. The original application system that receives the first request message sends a target response message in response to the first request message. The target response message is sent to the system under test corresponding to the first request message.

9. A baffle testing device, characterized in that, The device includes: The relay module is used to receive a first request message sent by at least one system under test, wherein each first request message includes transaction identification code information; The acquisition module is used to acquire the transaction information of the current transaction corresponding to each first request message from the architecture management system based on the transaction identification code information of each first request message; The determining module is used to determine the target system type corresponding to each first request message based on the transaction information corresponding to each first request message; The adjustment module is used to adjust the first request message according to the target system type corresponding to each first request message to obtain the second request message corresponding to the first request message; The data processing module is used to generate a target response message for each first request message based on the second request message corresponding to each first request message, and send the target response message of the first request message to the system under test corresponding to the first request message.

10. The apparatus according to claim 9, characterized in that, The adjustment module includes: A grouping module is used to group the at least one first request message according to the target system type corresponding to each first request message; An adding module is used to add a destination identifier to each of the first request messages based on the grouping results, so as to obtain the second request message corresponding to the first request message.

11. The apparatus according to claim 9, characterized in that, For each of the first request messages, the data processing module includes: The extraction module is used to extract key information from the second request message; The matching module is used to match the key information with the baffle rules of the second request message corresponding to the first request message to obtain the matching result; The generation module is used to generate the target response message of the first request message based on the matching result.

12. The apparatus according to claim 11, characterized in that, The generation module includes: A determination submodule is configured to determine at least two response results based on the first request message when the matching result is a successful match. A construction module is used to construct test data that conforms to the at least two response results; A generation submodule is used to generate at least two target response messages based on the test data, wherein the response result includes at least one of the following: success, failure, or partial success.

13. The apparatus according to claim 11, characterized in that, The generation module further includes: The acquisition module is used to acquire historical transaction record information when the matching result is unsuccessful. The evaluation module is used to evaluate the similarity between the first request message and the historical request messages in the historical transaction record information; The selection module is used to select the historical request message with the highest similarity to the first request message as the reference request message, and to use the historical response message corresponding to the reference request message as the target response message of the first request message.

14. The apparatus according to claim 9, characterized in that, For each first request message, the data processing module includes: The dynamic adjustment module is used to dynamically adjust the response configuration items of the target response message of the first request message based on the transaction scenario, so as to obtain the adjusted target response message of the first request message. The sending module is used to send the adjusted target response message to the system under test corresponding to the first request message.

15. The apparatus according to claim 9, characterized in that, The relay module includes: The interception module is used to intercept the first request message sent by the system under test; The judgment module is used to determine whether each of the first request messages conforms to the preset detection rules; The receiving module is used to receive the first request message when the first request message meets the preset detection rules.

16. The apparatus according to claim 15, characterized in that, The relay module also includes: The sending submodule is used to send the first request message to the original application system corresponding to the first request message when the first request message does not meet the preset detection rules; The receiving module is further configured to receive the target response message fed back by the original application system corresponding to the first request message in response to the first request message; The sending submodule is further configured to send the target response message to the system under test corresponding to the first request message.

17. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 8.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

19. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

Images