Bank-enterprise direct connection scene restoration test method

Abstract

The invention provides a bank-enterprise direct connection scene restoration test method, and relates to the technical field of software testing, and the method comprises the steps: carrying out the comparison verification of a message through a simulator based on an interaction message and a test case, and the simulator comprises an ERP simulator and a bank simulator; the comparison verification is specifically as follows: the ERP simulator sends the ERP request message to a tested program, receives a tested generation request message generated by the tested program, and calls a verifier to compare the tested generation request message with a pre-stored forwarding request message; the bank simulator returns a bank response message to the tested program, receives a tested generated feedback message generated by the tested program, and calls the verifier to compare the tested generated feedback message with a pre-stored final feedback message; and marking whether the test case is passed or not according to a message comparison result, and generating a test report.

Description

Technical Field

[0001] This application belongs to the technical field of software testing, and particularly relates to a method for restoring and testing the direct connection scenario between enterprises and banks. Background Art

[0002] With the in-depth digital transformation of enterprises, as a core link in enterprise fund management, the reliability and accuracy of the interfaces of direct connection between enterprises and banks directly affect the efficiency of enterprise financial operations. The technology of direct connection between enterprises and banks directly connects the ERP system with the bank system to realize the automated processing of services such as account query and payment settlement. However, with the diversification of business scenarios (such as cross-border transactions and support for multiple account types), the testing of the direct connection interfaces between enterprises and banks faces severe challenges.

[0003] Traditional testing needs to rely on the testing environment provided by the bank, but there are differences between this environment and the real production environment (such as data format and response logic), resulting in the test results being unable to truly reflect the performance of the interfaces in the production environment. In addition, the bank testing environment is easily affected by factors such as policies and system upgrades, and it is difficult to obtain stably.

[0004] Existing testing mostly uses stub programs to simulate bank behaviors, but it can only implement simple request-response logic and cannot reproduce the complex interactions in the real production environment (such as multiple message exchanges and dynamic signature verification), resulting in incomplete test coverage and difficult exposure of defects. Test cases rely on manual operations (such as message generation and result comparison), with a large amount of repetitive work, and manual judgment is prone to introducing errors. Especially in frequently iterated scenarios, the cost of repeated testing is high. For services involving multiple interactions (such as querying the transaction status after payment), the existing technology is difficult to automate the processing of dependency relationships and requires manual intervention to adjust the test order, resulting in a long and error-prone process.

[0005] The above defects often cause problems (such as incorrect message formats and missing logical branches) due to insufficient testing after the direct connection interfaces between enterprises and banks are launched, seriously affecting the enterprise's fund security and operation efficiency. Summary of the Invention

[0006] This application provides a method for restoring and testing the direct connection scenario between enterprises and banks to solve one of the above technical problems.

[0007] The technical solution adopted by this application is as follows:

[0008] An embodiment of this application provides a method for restoring and testing the direct connection scenario between enterprises and banks, which is characterized by including:

[0009] Based on the interaction messages and test cases, the messages are compared and verified through a simulator, and the simulator includes an ERP simulator and a bank simulator;

[0010] The comparison and verification specifically includes: the ERP simulator sends the ERP request message to the program under test, receives the generated request message under test generated by the program under test, and calls the validator to compare the generated request message under test with the pre-stored forwarding request message;

[0011] The bank simulator returns the bank response message to the program under test, receives the generated feedback message under test generated by the program under test, and calls the validator to compare the generated feedback message under test with the pre-stored final feedback message;

[0012] Mark the test case as passed or failed according to the message comparison result, and generate a test report.

[0013] According to an embodiment of the present application, the desensitization processing of the interaction message includes:

[0014] Remove the enterprise account information, user identity identifier and transaction sensitive fields from the message;

[0015] Retain the message structure, business logic fields and check codes.

[0016] According to an embodiment of the present application, the initialization of the simulator is implemented in a singleton mode, specifically including:

[0017] Generate a unique simulator instance according to the bank code number;

[0018] Bind a fixed network port and multiplex thread resources;

[0019] Support high-concurrency test scenarios through asynchronous processing.

[0020] According to an embodiment of the present application, the implementation of the validator includes:

[0021] The base class validator is used to verify the message header, timestamp format, and continuity of the transaction serial number;

[0022] The subclass validator is customized according to the bank type or transaction scenario, including signature verification, amount precision matching, and response code mapping rule check.

[0023] According to an embodiment of the present application, the subclass validator is implemented through dynamic loading, specifically:

[0024] Configure the validator class name in the test case, separating multiple class names;

[0025] When the tool runs, reflect and instantiate the validator, and execute the verification in order.

[0026] According to an embodiment of the present application, the processing of multiple interaction scenarios includes:

[0027] Execute the test cases in sequence according to the dependency relationship of the previous test case numbers;

[0028] The bank simulator returns responses in the order of the preset message, and marks failure if the number of requests or the order does not match.

[0029] According to an embodiment of the present application, the test report generation includes:

[0030] Recording the verification differences in the stage of the generated request message under test and the stage of the generated feedback message under test;

[0031] Associating the failed test cases with the corresponding validator logs to locate the defect types as message format errors, field value mismatches, or missing logical branches.

[0032] According to an embodiment of the present application, it further includes the test case maintenance steps:

[0033] When adding a new scenario, expanding the message library and verification rules based on the production system logs;

[0034] When optimizing the validator, reusing the base class logic through inheritance or composition to reduce code redundancy.

[0035] A computer-readable storage medium, on which a program is stored, and when the program is executed by a processor, the steps in the method for restoring the test scenario of direct connection between enterprises and banks are implemented.

[0036] An electronic device includes a memory, a processor, and a program stored on the memory and executable on the processor. When the processor executes the program, the steps in the method for restoring the test scenario of direct connection between enterprises and banks are implemented.

[0037] Due to the adoption of the above technical solution, the beneficial effects obtained by the present application are:

[0038] Through the ERP simulator and the bank simulator, the present application directly uses the real interaction messages (after desensitization) collected from the production environment to ensure that the test scenario is highly consistent with the production environment, and solves the problem of simulation distortion caused by the traditional method relying on the bank test environment. After the ERP simulator sends a request message, the validator automatically compares the request message (message No. 2') generated by the program under test with the pre-stored real forwarded message (message No. 2) to ensure the correctness of the interface logic. After the bank simulator returns a response message, the validator compares the feedback message (message No. 4') of the program under test with the pre-stored final feedback message (message No. 4) again, comprehensively covering the full-link verification. Automatic execution: The generation, execution, and result determination of test cases are fully automated, significantly reducing manual intervention and increasing the test efficiency by more than 80%.

[0039] This application initializes the simulator through the singleton pattern and binds a fixed port, supporting high-concurrency testing; based on the dependency relationship of the precondition use cases, it dynamically adjusts the execution order to ensure the coherence and accuracy of multiple interaction scenarios (such as payment-query). The test report details the differences such as message format errors, inconsistent field values, or missing logical branches, and associates with the validator logs to help the development team quickly locate the root cause of the problem and shorten the repair cycle.

[0040] This application supports dynamic loading of validators (such as the base class validating common fields and the subclass customizing bank-specific rules), reusing logic through inheritance or composition to reduce code redundancy; when adding new scenarios, it expands the message library and validation rules based on production logs to flexibly adapt to the business iteration requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The drawings described herein are used to provide a further understanding of the present application and form a part of the present application. The illustrative embodiments and descriptions thereof of the present application are used to explain the present application and do not constitute an improper limitation of the present application. In the drawings:

[0042] Figure 1 It is a schematic flow chart of a method for restoring the direct connection scenario between banks and enterprises provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0043] In order to more clearly illustrate the overall concept of the present application, the following will be described in detail by way of examples in conjunction with the drawings of the specification.

[0044] In the following description, many specific details are set forth in order to fully understand the present application. However, the present application may be implemented in other ways different from those described herein. Therefore, the protection scope of the present application is not limited by the specific embodiments disclosed below. It should be noted that, without conflict, the embodiments of the present application and the features in each embodiment may be combined with each other.

[0045] In the present application, unless otherwise clearly defined and limited, the first feature being "on" or "under" the second feature may be that the first and second features are in direct contact, or the first and second features are in indirect contact through an intermediate medium. In the description of this specification, the description with reference to terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0046] Embodiment 1

[0047] As shown Figure 1 in the figure, a method for restoring and testing a direct connection scenario between a bank and an enterprise includes:

[0048] Based on the interactive message and test cases, the simulator is used to compare and verify the message. The simulator includes an ERP simulator and a bank simulator.

[0049] Specifically, the composition of the simulator

[0050] ERP simulator: Used to simulate the behavior of real ERP software, send ERP request messages to the program under test, and receive the feedback messages generated by the program under test.

[0051] Bank simulator: Used to simulate the behavior of the bank side, return the preset bank response message to the program under test, and receive the feedback from the program under test.

[0052] Message comparison and verification process

[0053] ERP simulator sends a request: The ERP simulator sends an ERP request message to the program under test according to the test case, and then receives the generated request message under test generated by the program under test.

[0054] First comparison and verification: Call the verifier to compare the generated request message under test with the pre-stored forwarded request message (i.e., the real message extracted from the production environment) to verify the accuracy of the program under test in processing the ERP request.

[0055] Bank simulator response: The bank simulator returns the corresponding bank response message to the program under test according to the test case, and receives the generated feedback message under test generated by the program under test.

[0056] Second comparison and verification: Call the verifier again to compare the generated feedback message under test with the pre-stored final feedback message (also real data from the production environment) to check whether the program under test processes the bank response accurately.

[0057] Result marking and report generation

[0058] According to the results of the two message comparisons, mark the test case as "passed" or "failed". If the message comparison fails at any stage, the entire test case is considered failed. In addition, a detailed test report will be generated, recording the verification difference points, and associating the failed cases with the corresponding verifier logs to accurately locate the defect types (such as message format errors, field value inconsistencies, or missing logic branches, etc.).

[0059] Desensitization processing: When using real transaction data, sensitive information (such as enterprise account information, user identity identifiers, and transaction sensitive fields) will be removed, and only the necessary structural and business logic fields will be retained.

[0060] Simulator Initialization: Implemented using the singleton pattern, a unique simulator instance is generated through line numbering, binding a fixed network port and reusing thread resources to support high-concurrency test scenarios.

[0061] Dynamic Loading of Validators: Allows different validators to be dynamically loaded through a configuration file to meet the requirements of different bank types or transaction scenarios.

[0062] For example, assume that the payment interface between an enterprise's ERP system and a certain bank is being tested. To ensure that this interface can correctly process payment requests and receive bank feedback in actual applications, a test case needs to be designed to verify this process.

[0063] Test Preparation

[0064] Collect Real Transaction Messages: Collect the request message (Message 1) sent by the ERP software to the bank from the production environment, the response message (Message 3) returned by the bank after receiving the request, and the result feedback message (Message 4) finally received by the ERP software.

[0065] Design Test Cases: Based on the collected real messages, design corresponding test cases and desensitize sensitive data.

[0066] Test Execution

[0067] ERP Simulator Sends Request:

[0068] The ERP simulator sends Message 1 (ERP request message) to the program under test (i.e., the bank-enterprise docking interface) according to the test case.

[0069] First Comparison and Verification:

[0070] After receiving Message 1, the program under test generates Message 2' (forwarded request message).

[0071] The validator compares Message 2' with the pre-stored Message 2 (the real message forwarded by the bank from the production environment).

[0072] If the comparison fails, the test is marked as failed; if successful, proceed to the next step.

[0073] Bank Simulator Response:

[0074] After receiving Message 2', the bank simulator finds Message 3 (the real message of the bank's feedback processing result) extracted from the production system according to the currently executed message and returns this response to the program under test.

[0075] Second Comparison and Verification:

[0076] After the program under test receives the response from the bank simulator, it generates Message No. 4 (the real message for feedback on the processing result to the ERP software).

[0077] The validator compares Message No. 4 with the pre - stored Message No. 4 (the real message for feedback on the processing result from the ERP software in the production environment).

[0078] If the comparison fails, the test is marked as failed; if it succeeds, the test is marked as passed.

[0079] Result Recording and Report Generation

[0080] Test Report: Record the verification difference points in all stages. For any failed comparison, associate the corresponding validator log to locate the defect type (such as message format error, field value mismatch, or missing logic branch, etc.).

[0081] Automation Extension: Support the processing of multiple interaction scenarios, such as executing test cases in sequence according to the dependency relationship of the previous test case numbers, and the bank simulator returning responses in the order of the pre - set messages, so as to ensure the test accuracy in complex scenarios.

[0082] Summary

[0083] Through the above steps, we can use the ERP simulator and the bank simulator, combined with real interaction messages and carefully designed test cases, to achieve the accuracy and reliability testing of the interface logic. This method not only improves the test efficiency but also effectively reduces manual intervention and ensures the quality of the direct bank - enterprise connection interface.

[0084] Furthermore, on the existing basis, the ERP simulator and the bank simulator can automatically adjust their response behaviors according to different test scenarios. For example, dynamically generate response messages according to the request content sent by the program under test, rather than being limited to the pre - stored message templates, to more realistically simulate complex or abnormal situations. Implement a data synchronization mechanism with the production environment so that the ERP simulator and the bank simulator can obtain the latest transaction data as a basis to ensure that the test environment is as close as possible to the actual operating environment and improve the authenticity and effectiveness of the test. Introduce machine learning algorithms so that the simulator can learn from each test process and optimize its behavior model. For example, identify common error patterns and improve the simulator's behavior for these patterns, thereby enhancing the accuracy and efficiency of subsequent tests.

[0085] In addition to basic message comparison, more in-depth message parsing tools can be developed to analyze the internal structure of messages, the logical relationships between fields, and their trends of change. This helps to discover hidden problems, such as potential security vulnerabilities or business logic defects. Not limited to one-to-one message comparison, multi-dimensional comparative analysis across time points and versions can also be added. For example, compare the performance differences of the same type of transaction in different time periods, or how the old and new system versions handle the same transaction request differently.

[0086] Automatically construct new test scenarios based on historical test data and user feedback, reducing the workload of manually designing test cases. At the same time, it supports one-key scenario switching to quickly locate the problem. It allows dynamic adjustment of test scenarios according to the results of real-time monitoring during test execution. For example, when a performance bottleneck is detected in a certain link, the parameter settings in the current scenario can be modified immediately to observe the system's reaction.

[0087] The comparison and verification are specifically as follows: The ERP simulator sends the ERP request message to the program under test, receives the generated request message of the program under test, and calls the verifier to compare the generated request message of the program under test with the pre-stored forwarded request message; The bank simulator returns the bank response message to the program under test, receives the generated feedback message of the program under test, and calls the verifier to compare the generated feedback message of the program under test with the pre-stored final feedback message.

[0088] Specifically, the message comparison and verification process

[0089] The ERP simulator sends a request message:

[0090] The ERP simulator first sends an ERP request message to the program under test (i.e., the interface program for the enterprise to connect with the bank) according to the settings in the test case. This request message is obtained after desensitizing the real business data collected from the actual production system.

[0091] Receive the request message generated by the program under test:

[0092] After receiving the request message sent by the ERP simulator, the program under test will process the request according to its internal logic and generate a new request message (referred to as the "generated request message of the program under test"). This step reflects how the program under test responds to requests from the ERP system.

[0093] Call the verifier for the first comparison:

[0094] The validator compares the request message generated by the program under test (the request message generated by the program under test) with the pre-stored forwarding request message (i.e., the real forwarding request message corresponding to the current test case extracted from the production environment). In this way, it is verified whether the program under test correctly processes the ERP request and generates the correct forwarding request.

[0095] If the comparison results are consistent, this part of the test is considered passed; if not, the difference points are recorded and marked as failed.

[0096] The bank simulator returns a response message:

[0097] Next, according to the requirements of the test case, the bank simulator returns a simulated bank response message to the program under test. This response message is also adjusted based on the real bank feedback message.

[0098] Receive the feedback message generated by the program under test:

[0099] After receiving the response message returned by the bank simulator, the program under test will also process this response according to its internal logic and generate a feedback message (referred to as the "feedback message generated by the program under test"), which will be sent back to the ERP system or displayed to the user.

[0100] Call the validator for a second comparison:

[0101] Similarly, the validator compares the feedback message generated by the program under test (the feedback message generated by the program under test) with the pre-stored final feedback message (i.e., the real feedback message corresponding to the current test case extracted from the production environment) to check whether the program under test accurately processes the bank's response and generates the correct feedback information.

[0102] According to the comparison results, if they are consistent, the entire test case is regarded as passed; otherwise, the inconsistencies are recorded and marked as failed.

[0103] Based on the results of the above two comparisons, it can be determined whether the test case is successful. If there are inconsistencies in any stage, the entire test case will fail, and these difference points will be detailedly recorded in the test report.

[0104] The test report not only contains the detailed results of each comparison but also associates the failed cases with the corresponding validator logs to accurately locate the problem, such as whether the failure is caused by incorrect message format, inconsistent field values, or missing logical branches, etc.

[0105] For example, assume that an enterprise is testing the payment interface between its ERP system and a certain bank. To ensure that the interface can correctly process payment requests and receive feedback from the bank, a specific test case needs to be designed for verification.

[0106] Test Preparation

[0107] Collect real transaction messages: Obtain the following messages from the production environment:

[0108] Message No. 1: A real request message generated by a specific business initiated by the ERP software.

[0109] Message No. 2: A real request message that the program under test (the bank-enterprise interface program) forwards to the bank after receiving Message No. 1.

[0110] Message No. 3: A real response message returned by the bank after processing the request.

[0111] Message No. 4: A real feedback message generated by the program under test based on Message No. 3 and fed back to the ERP software.

[0112] Desensitization processing: Remove the enterprise account information, user identity identifiers, and transaction-sensitive fields involved in the above messages, and retain the necessary structural and business logic fields.

[0113] Test Execution Steps

[0114] Step 1: The ERP simulator sends an ERP request message

[0115] The ERP simulator sends Message No. 1 (the real request message after desensitization processing) to the program under test.

[0116] Step 2: Receive the request message generated by the program under test

[0117] After receiving Message No. 1, the program under test processes it according to its internal logic and generates a new request message (referred to as Message No. 2'), which is the request that the program under test is about to forward to the bank.

[0118] Step 3: Call the validator to compare the request message generated by the program under test with the pre-stored forwarding request message

[0119] The validator compares Message No. 2' with the pre-stored Message No. 2 (i.e., the real forwarding request message extracted from the production environment).

[0120] If Message No. 2' is consistent with Message No. 2, it indicates that the program under test has correctly processed the ERP request; if not, record the difference points and mark it as failed.

[0121] Step 4: The bank simulator returns a bank response message

[0122] After the bank simulator receives the message No. 2’, according to the requirements of the test case, it returns the preset message No. 3 (a real response message with appropriate adjustments) to the program under test.

[0123] Step 5: Receive the feedback message generated by the program under test

[0124] After the program under test receives the message No. 3, it processes again according to its internal logic and generates a new feedback message (referred to as message No. 4’), which is the result that the program under test is prepared to feedback to the ERP software.

[0125] Step 6: Call the validator to compare the feedback message generated by the program under test with the pre-stored final feedback message

[0126] The validator compares message No. 4’ with the pre-stored message No. 4 (i.e., the real feedback message extracted from the production environment).

[0127] If message No. 4’ is consistent with message No. 4, it means that the program under test has correctly processed the bank's response; if not, the difference points are recorded and marked as failed.

[0128] Result analysis and report generation

[0129] Based on the results of the above two comparisons, it can be determined whether the test case is successful. If the message comparison fails at any stage, the entire test case is regarded as failed.

[0130] The test report will detail the verification difference points at each stage and associate the failed test cases with the corresponding validator logs to help accurately locate the defect types (such as message format errors, field value mismatches, or missing logical branches, etc.).

[0131] In this way, without an actual bank test environment, enterprises can use the ERP simulator and bank simulator to comprehensively and effectively verify the bank-enterprise interface, ensuring the accuracy and reliability of the interface in actual applications.

[0132] Furthermore, in addition to the basic field value comparison, more dimensions of comparison criteria can be introduced, such as timestamps, digital signatures, check codes, etc. This helps to more comprehensively check the consistency and integrity of the message. When detecting message inconsistencies, instead of simply marking as failed, an automated tool can be developed to analyze the specific reasons for the differences, such as missing fields, data type mismatches, or format errors, etc., and provide improvement suggestions. Allow users to customize verification rules according to specific business requirements, so that the system can not only execute the preset verification logic but also flexibly handle different test scenarios and requirements.

[0133] The ERP simulator and the bank simulator can dynamically adjust the content of the messages they output according to the real-time received data, rather than being limited to static pre-stored message templates. This can better simulate complex or changing actual transaction environments. Enhance the functions of the simulator so that it can simulate responses in various abnormal situations, such as timeouts, network interruptions, server errors, etc., to ensure that the program under test can also handle correctly in the face of abnormal operations. Optimize multiple interaction scenarios, such as automatically adjusting the test order by intelligently identifying the pre-dependency relationships, reducing manual intervention, and improving test efficiency.

[0134] Collect and analyze the results of previous tests, identify common problem patterns, and help improve the test strategy and product quality. Develop a dedicated interface for visually displaying test results, including but not limited to forms such as charts and tree diagrams, to facilitate quickly understanding complex comparison results and locating problems.

[0135] Mark the test case as passed or failed according to the message comparison result and generate a test report.

[0136] Specifically, the processing of the message comparison result

[0137] Message comparison:

[0138] During the test, the ERP simulator and the bank simulator respectively send request messages and receive the feedback messages generated by the program under test.

[0139] The validator will compare these feedback messages (i.e., the request messages and feedback messages generated by the program under test) with the pre-stored standard messages (forwarded request messages and final feedback messages).

[0140] Result determination:

[0141] If all comparisons are consistent (i.e., the messages generated by the program under test are exactly the same as the pre-stored standard messages), then the test case is considered "passed".

[0142] If there are differences in the message comparison at any stage, the test case will be marked as "failed".

[0143] Generation of the test report

[0144] Record the differences:

[0145] For each failed test case, the test tool will record in detail all detected differences. This includes but is not limited to specific problems such as message format errors, field value inconsistencies, or missing logical branches.

[0146] Associate the failed cases with the validator logs:

[0147] For subsequent analysis, the test report will also associate the failed test cases with their corresponding validator logs. This helps to accurately locate the defect types and the reasons for their occurrence.

[0148] Generate a detailed test report:

[0149] After the test is completed, the system will automatically generate a comprehensive test report. This report not only includes the results (passed / failed) of each test case, but also lists the specific differences of all failed test cases and the corresponding validator log information.

[0150] The report can serve as an important basis for improving the program under test, helping the development team quickly locate and fix problems.

[0151] Automated maintenance and update:

[0152] In addition, as new business scenarios are added or existing scenarios change, the test case library also needs to be continuously updated. When adding new scenarios, the test content can be enriched by expanding the message library and verification rules based on production system logs; at the same time, when optimizing the validator, the base class logic should be reused as much as possible through inheritance or composition to reduce code redundancy.

[0153] For example, assume that you are testing the transfer interface between an enterprise's ERP system and a certain bank. It is necessary to ensure that when the ERP system initiates a transfer request, the bank-enterprise docking program can correctly process the request and return the correct response to the ERP system.

[0154] Test steps and result processing

[0155] Step 1: Send an ERP request message

[0156] The ERP simulator sends an ERP request message (e.g., a transfer request) to the program under test (i.e., the bank-enterprise docking program). This message is a desensitized version of the real data collected from the production environment.

[0157] Step 2: Receive and verify the forwarded request message

[0158] After receiving the ERP request, the program under test generates a forwarded request message (message No. 2') and sends it to the bank.

[0159] The validator compares message No. 2' with the pre-stored forwarded request message (message No. 2). If they are the same, proceed to the next step; if not, record the differences and mark this test case as "failed".

[0160] Step 3: The bank simulator returns a response message

[0161] After the bank simulator receives Message No. 2’, it returns a simulated bank response message (Message No. 3) to the program under test according to the requirements of the test case.

[0162] Step 4: Receive and verify the final feedback message

[0163] After the program under test receives the bank response message, it generates a final feedback message (Message No. 4’) and feeds it back to the ERP system.

[0164] The validator compares Message No. 4’ with the pre - stored final feedback message (Message No. 4). If the two are consistent, the entire test case is regarded as “passed”; if not, the points of difference are recorded and the test case is marked as “failed”.

[0165] Generate a test report

[0166] Assume that during the above process, all message comparisons are consistent. Then the test report will be as follows:

[0167] Example of test report

[0168] Test case number: TC001

[0169] Test scenario description: The ERP system initiates a transfer request, the bank - enterprise interface program processes the request and interacts with the bank, and finally returns the result to the ERP system.

[0170] Test result: Passed

[0171] Detailed comparison result:

[0172] ERP request message vs forwarded request message: The comparison result is consistent.

[0173] Bank response message vs final feedback message: The comparison result is consistent.

[0174] Abnormal situation record: No abnormal situation record.

[0175] Associated log: The validator log shows that all comparisons are successful, and no problems such as inconsistent field values or missing logical branches are found.

[0176] Remark: All messages have been desensitized according to the preset rules to ensure the security of sensitive information.

[0177] Based on the results of this test, it can be confirmed that the current version of the bank - enterprise interface program functions normally in processing transfer requests and does not require further modification.

[0178] If there is an inconsistent situation

[0179] Assume that in the second step, there are differences between the Message No. 2' and Message No. 2, for example, a certain key field value does not match. The test report will record as follows:

[0180] Test case number: TC001

[0181] Test scenario description: The ERP system initiates a transfer request, the bank-enterprise interface program processes the request and interacts with the bank, and finally returns the result to the ERP system.

[0182] Test result: Failed

[0183] Detailed comparison result: ERP request message vs Forward request message: The comparison result is inconsistent. The specific difference lies in that the value of the amount field does not match (the expected value is 1000.00, and the actual value is 999.99).

[0184] Bank response message vs Final feedback message: Since the previous step failed, this step was not executed.

[0185] Abnormal situation record: The value of the amount field does not match, which may be caused by numerical precision problems or business logic errors.

[0186] Related log: The validator log points out the specific location and reason for the mismatch of the amount field value.

[0187] Remark: It is necessary to further check the code related to handling amounts in the program under test to ensure that it meets the business requirements.

[0188] Furthermore, introduce a more detailed result classification mechanism, not just simple "Pass" or "Fail", but also categories such as "Warning", "Partially Passed", etc. For example, differences in some non-key fields can be marked as "Warning", while only when the key business logic is affected is it marked as "Fail". Allow users to set different error tolerances or verification criteria according to specific needs. For example, a deviation of ±0.01 is allowed in the amount field, while exact matching is required in the date field. When detecting message inconsistencies, the system can not only mark failures but also provide automated improvement suggestions. For example, for specific types of errors (such as format errors, data type mismatches), recommended correction solutions are given.

[0189] In addition to the basic pass / fail markers, detailed log information can be added to the report, including the specific steps of each verification, the name of the validator used, and its execution order, etc., to facilitate subsequent problem troubleshooting. Use forms such as charts and tree diagrams to visually display the test results. Especially for complex multiple-interaction scenarios, the verification situation and results of each step can be clearly shown through a flow chart. Store the results of previous tests and support the comparison and analysis function to help identify common problem patterns or performance bottleneck points, providing a basis for optimizing the test strategy. When a test case is marked as failed, notifications can be automatically generated and sent to relevant personnel, including detailed error information and suggested repair measures, to promote quick response and problem solving. Add multi-dimensional summary analysis to the final test report, such as counting pass rates, failure rates, etc. according to dimensions such as bank type, transaction scenario, time period, etc., to help understand the overall test effect and trend. Provide flexible report template options, allowing users to customize the content and format of the report according to their needs to meet the requirements of different departments or roles.

[0190] According to an embodiment of the present application, the desensitization processing of the interaction message includes:

[0191] Remove the enterprise account information, user identity identifier, and transaction sensitive fields in the message;

[0192] Retain the message structure, business logic fields, and check codes.

[0193] Specifically, remove sensitive information

[0194] Enterprise account information: In a real transaction message, it contains detailed bank account information of an enterprise, such as account number, name of the bank where the account is opened, etc. These information are directly related to the enterprise's capital security and must be removed or replaced with fictional data in the test environment to prevent leakage.

[0195] User identity identifier: This refers to the information that can uniquely identify a certain user, such as ID number, username, password, etc. During the test process, these personal identity identifiers also need to be deleted or replaced with false data to ensure that personal information will not be exposed due to testing.

[0196] Transaction sensitive fields: They involve specific transaction details, such as transaction amount, transaction timestamp, payment method, etc. In some cases, they may also be regarded as sensitive information. Especially when these information may indirectly point to a specific enterprise or individual, appropriate shielding or disguising processing is also required.

[0197] Retain necessary elements

[0198] Message Structure: Even after data masking, the basic framework and format of the message remain unchanged. This means that the structural features such as the positions of various fields and the hierarchical relationships in the message are retained, thus ensuring that the messages in the test environment have the same architectural basis as those in the production environment.

[0199] Business Logic Fields: To ensure the effectiveness and accuracy of testing, those keyword fields carrying the core business logic are still retained in the message. For example, the code indicating the transaction type, the marker reflecting the status of the business process, etc. These are all necessary information for verifying whether the system functions properly.

[0200] The checksum is a mechanism used to ensure data integrity and correctness. Even after the masking operation, the original checksum rules still apply, and the new masked message should also be able to pass the corresponding checks to ensure its legality and consistency.

[0201] According to an embodiment of the present application, the initialization of the simulator is implemented in the singleton pattern, specifically including:

[0202] Generate a unique simulator instance according to the bank code;

[0203] Bind to a fixed network port and reuse thread resources;

[0204] Support high-concurrency test scenarios through asynchronous processing.

[0205] Specifically, the singleton pattern initialization

[0206] The singleton pattern is a design pattern that ensures that a class has only one instance and provides a global access point to access this instance. In the scenario restoration test of bank-corporate direct connection, using the singleton pattern to initialize the simulator can effectively manage resources and improve performance.

[0207] Generate a unique simulator instance according to the bank code:

[0208] The bank code refers to a specific identifier of a bank, and each bank has its unique code.

[0209] During the initialization process, the system will create a unique simulator instance based on the incoming bank code. This means that even if multiple test cases are running simultaneously, the simulator for the same bank will only be initialized once, thus saving resources.

[0210] Bind to a fixed network port and reuse thread resources:

[0211] The simulator needs to communicate with the program under test through the network, so it needs to be bound to a fixed network port. This not only ensures the stability and reliability of communication but also makes the switching between different test cases smoother.

[0212] Reusing thread resources means that the simulator can process the next request immediately after finishing one request, without having to create a new thread every time. This greatly improves the system's response speed and efficiency, especially important in high-concurrency test scenarios.

[0213] Support high-concurrency test scenarios through asynchronous processing:

[0214] Asynchronous processing allows the simulator to continue executing other tasks while waiting for an operation to complete, rather than blocking and waiting. For example, during the process of waiting for the response from the bank simulator, the ERP simulator can continue to send other requests, thus avoiding unnecessary waiting time.

[0215] This approach is particularly suitable for handling complex multiple-interaction scenarios or multi-user concurrent operation situations. Through asynchronous processing, the simulator can manage a large number of concurrent requests more efficiently, ensuring a smooth and efficient test process.

[0216] Suppose in a test environment, it is necessary to test the interfaces of multiple banks, and each bank has different business logic and data format requirements. In this case:

[0217] When testing the interface of Industrial and Commercial Bank of China, the system generates a unique ERP simulator instance and bank simulator instance according to the bank code of Industrial and Commercial Bank of China.

[0218] These simulator instances will be bound to pre-set network ports and utilize the existing thread pool resources to process requests and responses from the ERP system and the bank system.

[0219] If multiple test cases are running simultaneously, these simulators can concurrently process multiple requests through the asynchronous mechanism, ensuring that the entire test process will not be stalled due to waiting for the response of a certain request.

[0220] According to an embodiment of the present application, the implementation of the validator includes:

[0221] Base class validator, used to verify the message header, timestamp format, and continuity of the transaction serial number;

[0222] Subclass validator, customized according to the bank type or transaction scenario, including signature verification, amount precision matching, and response code mapping rule check.

[0223] Specifically, the base class validator is the basis of all validators, providing general verification logic applicable to all types of message verifications. Its main responsibilities include but are not limited to the following aspects:

[0224] Message header verification: The message header usually contains basic information of the message, such as version number, message type, etc. The base validator checks whether these basic information meet the expected standards to ensure the correct message structure.

[0225] Timestamp format verification: The timestamp records the specific time point when the message is generated, which is crucial for transaction processing. The base validator needs to ensure that the timestamp format is correct and within a reasonable range (e.g., no future timestamps).

[0226] Continuity of transaction serial numbers: Transaction serial numbers are used to identify each transaction, ensuring that each transaction has a unique identifier and these identifiers increase sequentially. The base validator checks whether these serial numbers are continuous to prevent skipping or duplication.

[0227] The subclass validator is an extension based on the base validator, providing more detailed validation logic for specific bank types or transaction scenarios. Each subclass validator can customize different validation rules according to specific requirements, mainly including but not limited to the following:

[0228] Signature verification: In some cases, the message needs to be ensured of its authenticity and integrity through digital signatures. The subclass validator can implement the signature verification process to ensure that the received message has not been tampered with.

[0229] Amount precision matching: For transactions involving amounts, the subclass validator needs to pay special attention to the precision of the amount field. For example, in some scenarios, the amount may be required to be accurate to two decimal places, while in other scenarios, higher precision may be required. The subclass validator can adjust the validation rules according to specific business requirements.

[0230] Response code mapping rule check: The response codes returned by the bank system have specific meanings indicating the status of the transaction (success, failure, or others). The subclass validator needs to check whether the response codes meet the expectations according to the predefined mapping rules and be able to identify uncommon response codes and their meanings.

[0231] Dynamic loading and execution

[0232] In addition, the document also mentions that the subclass validator can be implemented through dynamic loading. This means configuring the required validator class names in the test cases and instantiating the corresponding validator objects through the reflection mechanism when the tool runs. This approach allows for flexible selection and combination of different validators to adapt to various complex test scenarios.

[0233] Suppose we are testing a fund transfer interface that needs to interface with multiple banks. We can design a subclass validator for each bank:

[0234] Industrial and Commercial Bank Validator: In addition to basic message header, timestamp, and serial number verification, it is also necessary to verify specific signature algorithms and whether the amount is accurate to two decimal places.

[0235] Agricultural Bank Validator: Similarly, basic verification is performed, but the mapping rules for response codes may be different and need to be adjusted according to the specific specifications of the Agricultural Bank.

[0236] According to an embodiment of the present application, the subclass validator is implemented through dynamic loading, specifically:

[0237] Configure the validator class name in the test case, separating multiple class names;

[0238] When the tool runs, reflectively instantiate the validator and perform verification in order.

[0239] Specifically, dynamic loading means that during the program's runtime, different validator classes are dynamically loaded and used as needed, rather than determining all verification logics at compile time. This approach provides great flexibility, enabling the system to select appropriate validators according to specific test requirements.

[0240] Implementation steps

[0241] Configure the validator class name in the test case:

[0242] First, define the validator class names to be used in the test case. This is usually a list of strings, where each string represents a specific validator class name.

[0243] If a test case requires multiple validators for different aspects of checks (such as signature verification, amount precision matching, etc.), these class names can be concatenated using a specific delimiter (such as the English half-width vertical bar symbol "|"). For example:

[0244] "com.example.SignatureValidator|com.example.AmountPrecisionValidator"

[0245] Reflectively instantiate the validator when the tool runs:

[0246] When the tool actually runs, use Java's reflection mechanism to dynamically create corresponding validator objects according to the configured class names.

[0247] Reflection is a powerful feature that allows programs to obtain class information and call its constructor or method at runtime. Specifically, after reading the above configuration string, the tool will parse the names of each validator class, load these classes through the reflection API (such as Class.forName()), and then use their constructors to generate instances.

[0248] Perform the checks in order:

[0249] Once all necessary validator instances have been created, the tool calls the validate method on each of them in the order they appear in the configuration string.

[0250] Each validator is responsible for performing a specific type of check (e.g., the base class validator is responsible for basic message headers, timestamp format, etc., while the subclass validator is responsible for specific requirements such as signature verification and amount accuracy). This ensures that each step of the verification can be performed in a predetermined logical order, thereby fully covering all possible problem points.

[0251] Assume there is a transfer interface test case, which requires the following verifications to be performed on the request and response messages:

[0252] Signature Verification

[0253] Timestamp format check

[0254] Amount accuracy matching

[0255] The validator for this test case can be configured as follows:

[0256] "com.example.TimeStampValidator|com.example.SignatureValidator|com.example.AmountPrecisionValidator"

[0257] When the tool runs, it:

[0258] Parse the above string and identify three validator class names.

[0259] Use the reflection mechanism to load these three classes in turn and create their instances.

[0260] Call the validation method of each validator in the specified order:

[0261] First call the verification method of TimeStampVal idator to check the timestamp format.

[0262] Then call the verification method of SignatureValidator to check whether the signature is correct.

[0263] Finally, call the verification method of AmountPrecisionValidator to check whether the amount precision meets the expectation.

[0264] According to an embodiment of the present application, the processing of multiple interaction scenarios includes:

[0265] Execute the use cases in the order of the dependency relationship of the precondition use case numbers;

[0266] The bank simulator returns responses in the order of the preset messages. If the number of requests or the order does not match, it is marked as failed.

[0267] Specifically, the concept of multiple interaction scenarios

[0268] In the test of the bank-enterprise direct connection interface, some business logics may involve interactions in multiple steps. For example, a transfer operation may first require initiating a transfer request, then performing identity verification, and finally confirming the transfer result. There may be dependency relationships between these steps, and each step needs to communicate with the bank system. Therefore, in order to accurately simulate such a complex scenario, it is necessary to ensure that each step is executed in the correct order and the response of each step also meets the expectation.

[0269] Specific processing method

[0270] Execute the use cases in the order of the dependency relationship of the precondition use case numbers:

[0271] The precondition use case number refers to that a certain test case depends on the result of another test case to be correctly executed. For example, when performing a payment transaction, it may be necessary to first complete the account balance query (precondition use case) and then perform the actual payment operation.

[0272] When designing test cases, a unique number is assigned to each use case, and it is specified whether the use case depends on other use cases. If there is a dependency relationship, it is necessary to check whether the precondition use case has been successfully executed before the test execution.

[0273] The test tool will automatically adjust the execution order according to these dependency relationships to ensure that all preconditions are met before executing the current use case. For example, assume that use case TC002 depends on TC001, then the test tool will first execute TC001 and only execute TC002 after it is successfully completed.

[0274] The bank simulator returns responses in the order of the preset messages:

[0275] The bank simulator is used to simulate the response behavior of the bank system. In multiple interaction scenarios, the bank simulator needs to return corresponding responses according to the preset message order.

[0276] For example, in a payment process, the bank simulator first receives a transfer request and then needs to return a series of response messages in a predefined order, such as "Request received successfully", "Authentication passed", "Transfer successful", etc.

[0277] The content and order of each response message are determined in advance to ensure that the real bank system response can be accurately simulated.

[0278] Mark as failed if the number of requests or the order does not match:

[0279] If the number of requests sent by the program under test to the bank simulator or the order does not match the expectation, the test is regarded as failed. For example, if the program under test should send an authentication request first and then a transfer request, but directly sends a transfer request in actual operation, this situation will be detected and marked as failed.

[0280] Similarly, if the number of responses returned by the bank simulator or the order does not meet the expectation, it will also cause the test to fail. For example, if the bank simulator should return "Request received successfully" and "Authentication passed" in sequence, but actually returns "Authentication passed" and "Request received successfully", the test will be marked as failed.

[0281] Actual application example

[0282] Suppose there is a transfer test scenario with two interactions:

[0283] First step: Query account balance

[0284] The program under test sends a balance query request to the ERP simulator.

[0285] The ERP simulator forwards the request to the bank simulator.

[0286] The bank simulator returns the account balance information as a response.

[0287] Second step: Transfer request

[0288] Based on the balance information obtained in the previous step, the program under test decides whether to make a transfer and sends a transfer request to the ERP simulator.

[0289] The ERP simulator forwards the request to the bank simulator.

[0290] The bank simulator returns the following responses in sequence:

[0291] "Request received successfully"

[0292] "Authentication passed"

[0293] "Transfer successful"

[0294] In this process:

[0295] Pre-use case dependency: The transfer request (step 2) depends on the account balance query (step 1). Therefore, the test tool will ensure that the account balance query is successful before executing the transfer request.

[0296] Sequential execution: The bank simulator must return responses in a strict predetermined order. If any step's response order is wrong or a step's response is missing, the test will be marked as failed.

[0297] Request count and order check: If the program under test sends a transfer request without completing the account balance query, or sends the requests in the wrong order, the test will also be marked as failed.

[0298] According to one embodiment of the present application, the test report generation includes:

[0299] Record the verification differences between the test request message generation stage and the test feedback message generation stage;

[0300] Correlate the failed use cases with the corresponding validator logs and locate the defect type, which is incorrect message format, inconsistent field values, or missing logical branches.

[0301] Specifically, the key elements of test report generation

[0302] Record verification differences:

[0303] During the test, the ERP simulator and the bank simulator respectively send requests and receive feedback messages generated by the program under test.

[0304] For each phase (i.e., request message phase and feedback message phase), if the validator detects any inconsistencies, it needs to record these differences in detail. The specific steps are as follows:

[0305] Request message stage: After the ERP simulator sends the request message, the program under test generates a forwarding request message (message No. 2'). The verifier compares message No. 2' with the pre-stored forwarding request message (message No. 2). If there is a difference, the specific difference content is recorded (for example, the value of a certain field is different).

[0306] Feedback message stage: When the bank simulator returns the response message, the program under test generates a final feedback message (message No. 4'). Similarly, the verifier will compare message No. 4' with the pre-stored final feedback message (message No. 4) and record any differences found.

[0307] Correlate the failed cases with the validator logs:

[0308] When a test case fails, not only should its result be recorded, but it also needs to be associated with the corresponding validator log. This can more precisely locate the cause of the problem. The specific implementation methods are as follows:

[0309] Failed test case marking: For test cases that fail to pass the verification, the system will mark them as "failed" in the test report.

[0310] Validator log association: For each failed test case, the system will automatically associate the relevant validator log. The validator log usually contains detailed information about the verification process, such as which fields were compared and what the comparison results were, etc.

[0311] Defect type location: Based on the validator log, further analyze and determine the specific type of the defect. Common defect types include:

[0312] Message format error: For example, some required fields are missing or the data format does not meet the expectation (such as incorrect date format).

[0313] Field value mismatch: It means that the values of the corresponding fields in two messages are inconsistent (such as different numerical values in the amount field).

[0314] Missing logical branch: It indicates that the program under test does not execute according to the expected path when processing some business logics (such as a conditional judgment that should be executed is not executed).

[0315] Practical application example

[0316] Suppose we are testing a fund transfer interface. The following is a specific example to illustrate the above process:

[0317] Example background

[0318] Test case number: TC001

[0319] Test scenario description: The ERP system initiates a fund transfer request, the bank-enterprise interface program processes the request and interacts with the bank, and finally returns the result to the ERP system.

[0320] Test report content

[0321] Record of differences in the request message stage:

[0322] The validator compares the request message (Message 1) sent by the ERP simulator with the forwarded request message (Message 2') generated by the program under test.

[0323] Difference: The value of the amount field does not match. The expected value is 1000.00, and the actual value is 999.99.

[0324] Record of differences in the feedback message stage:

[0325] The validator compares the response message returned by the bank simulator (Message No. 3) with the final feedback message generated by the program under test (Message No. 4').

[0326] Differences: None, all fields match.

[0327] Associate failed test cases with validator logs:

[0328] Failed test case: TC001

[0329] Validator log: Records the specific location and reason for the mismatch of the amount field value.

[0330] Defect type location: Field value mismatch.

[0331] Test report summary:

[0332] Test result: Fail

[0333] Detailed comparison result:

[0334] Request message stage: Mismatch of the amount field value (expected value is 1000.00, actual value is 999.99)

[0335] Feedback message stage: No differences

[0336] Abnormal situation record: Mismatch of the amount field value

[0337] Associated log: Provides detailed validator logs to help the development team quickly locate problems.

[0338] In this way, the generated test report can not only clearly show the results of each test case, but also, according to an embodiment of the present application, further includes test case maintenance steps:

[0339] When adding a new scenario, expand the message library and validation rules based on the production system logs;

[0340] When optimizing the validator, reuse the base class logic through inheritance or composition to reduce code redundancy.

[0341] Specifically, expand the message library and validation rules based on the production system logs

[0342] Collect and analyze production system logs:

[0343] When a new test scenario needs to be added, first collect relevant log data from the actually running production system. These logs record the data formats, numerical values, and business logics during the interaction between the enterprise application and the bank.

[0344] Desensitization processing: Before using these real transaction data, it must be desensitized to remove any sensitive information (such as enterprise account information, user identity identifiers, and transaction sensitive fields) to ensure privacy security.

[0345] Expand the message library: Update and expand the existing message library based on the collected log data. This means adding new message templates to the existing message library for use in test case design for new scenarios.

[0346] Formulate or adjust verification rules: For newly added business scenarios, formulate corresponding verification rules to ensure that newly introduced messages can be correctly parsed and verified. For example, define which fields are required and which field values need to meet specific format requirements, etc.

[0347] Optimize the strategy of the validator

[0348] Reuse the base class logic through inheritance or composition to reduce code redundancy

[0349] Inheritance mechanism: Utilize the inheritance feature in object-oriented programming to build a new validator starting from an existing base class validator. The base class validator usually contains some common verification logics, such as message header checks, timestamp format verification, etc. The subclass validator can inherit these basic functions and add special verification logics for specific bank types or transaction scenarios on this basis.

[0350] Composition mechanism: Another method is to adopt the composition method, that is, combine multiple small functional modules to form a new validator. This method allows developers to flexibly add new functions without modifying the original code. For example, a small module specifically responsible for signature verification can be created and then combined with other modules to form a complete validator.

[0351] Reduce code redundancy: Whether through inheritance or composition, the goal is to avoid repeating the same code logic. Doing so can not only improve development efficiency but also reduce maintenance costs because once an error is found in a common part, fixing it in one place will affect all places that depend on this part.

[0352] Practical application examples

[0353] Suppose it is necessary to add a test scenario for the transfer interface for a newly cooperated bank:

[0354] Collect and analyze logs: Obtain all relevant logs of transfer operations involving this bank from the production environment to understand its specific message format and business process.

[0355] Expanded message library: Add the message templates extracted from the above logs to the existing message library and make necessary adjustments according to the actual situation.

[0356] Formulate verification rules: Define specific verification rules for this bank transfer interface, including but not limited to amount precision, response code mapping, etc.

[0357] Optimize the validator: If the existing base validator already contains most of the required basic verification logic (such as message header check), a new validator can be created by inheriting this base class and adding functions specific to this bank, such as signature verification, on this basis. Or, if some verification logic can be shared among different banks, these logics can be encapsulated into independent small modules and then integrated into the new validator in a combined manner.

[0358] A computer-readable storage medium with a program stored thereon, and when the program is executed by a processor, it implements the steps in the method for restoring the direct bank-enterprise connection scenario test.

[0359] An electronic device, including a memory, a processor, and a program stored on the memory and executable on the processor, and when the processor executes the program, it implements the steps in the method for restoring the direct bank-enterprise connection scenario test.

[0360] What is not described in this application can be implemented by adopting or referring to existing technologies.

[0361] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments.

[0362] The above are only the embodiments of this application and are not used to limit this application. For those skilled in the art, various changes and modifications can be made to this application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this application shall be included within the scope of the claims of this application.

Claims

1. A method for restoring and testing the direct connection scenario between banks and enterprises, characterized in that, Including: Based on the interaction message and test case, the message is compared and verified by a simulator, and the simulator includes an ERP simulator and a bank simulator; The comparison and verification specifically is: The ERP simulator sends the ERP request message to the program under test, receives the generated request message under test generated by the program under test, and calls the validator to compare the generated request message under test with the pre-stored forwarding request message; The bank simulator returns the bank response message to the program under test, receives the generated feedback message under test generated by the program under test, and calls the validator to compare the generated feedback message under test with the pre-stored final feedback message; Mark the test case as passed or failed according to the message comparison result, and generate a test report.

2. The method according to claim 1, wherein The desensitization processing of the interaction message includes: Removing the enterprise account information, user identity identifier and transaction sensitive fields in the message; Retaining the message structure, business logic fields and check codes.

3. The method according to claim 1, wherein The initialization of the simulator is implemented in a singleton pattern, specifically including: Generating a unique simulator instance according to the bank code number; Binding a fixed network port and reusing thread resources; Supporting high-concurrency test scenarios through asynchronous processing.

4. The method according to claim 1, wherein The implementation of the validator includes: A base class validator for verifying the message header, timestamp format, and continuity of the transaction serial number; A subclass validator for customization according to the bank type or transaction scenario, including signature verification, amount precision matching, and response code mapping rule check.

5. The method according to claim 4, wherein The subclass validator is implemented through dynamic loading, specifically: Configuring the validator class name in the test case and separating multiple class names; Reflectively instantiating the validator when the tool runs and performing verification in sequence.

6. The method according to claim 1, wherein The processing of multiple interaction scenarios includes: Executing the use cases in sequence according to the dependency relationship of the precondition use case numbers; The bank simulator returns responses in the order of the preset messages. If the number of requests or the order does not match, it is marked as failed.

7. The method according to claim 1, characterized in that The generation of the test report includes: Recording the verification difference points in the generated request message stage under test and the generated feedback message stage under test; Associating the failed use cases with the corresponding validator logs to locate the defect types as message format errors, field value mismatches, or missing logical branches.

8. The method according to claim 1, wherein It also includes the test case maintenance steps: When adding a new scenario, expanding the message library and verification rules based on the production system logs; When optimizing the validator, reusing the base class logic through inheritance or composition to reduce code redundancy.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by a processor, it implements the steps in the bank-enterprise direct connection scenario restoration test method described in any one of claims 1-8.

10. An electronic device, comprising a memory, a processor, and a program stored on the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the bank-enterprise direct connection scenario restoration test method described in any one of claims 1-8.

Images