Business interaction docking test method, device, equipment, storage medium and product

Abstract

The application discloses a business interaction docking test method and device, equipment, a storage medium and a product, and relates to the technical field of financial technology. The method comprises the following steps: acquiring business scene data of an external financial subsidiary company which is interactively docked with a financial system; generating a current system running configuration of the external financial subsidiary company according to the business scene data; generating a test case to be executed for the external financial subsidiary company according to the business scene data and the system running configuration; and executing the test case according to a preset batch running process. According to the application, a suitable test scheme can be automatically generated according to the differentiated business characteristics of different financial subsidiary companies, and the test case can be executed, so that the repeated manual input is reduced, the automation level and the accuracy of the docking test are improved, and finally, the systematic and intelligent management of the business interaction docking process of the financial subsidiary company is realized.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular to a business interaction and connection testing method, apparatus, equipment, storage medium, and product. Background Technology

[0002] In the current financial industry's wealth management business, banks' sales agents and various wealth management subsidiaries primarily exchange documents based on a unified exchange platform's business data exchange protocol. Although the business rules are generally consistent, slight differences exist in the implementation methods of different wealth management subsidiaries in certain business scenarios. Therefore, one-on-one business integration testing is still required before interaction in the formal production environment. The existing integration process typically begins with a meeting between the two parties to confirm specific business interaction scenarios and compile the results into an Excel or Word document. Subsequently, testers manually design test cases based on the scenario documents and manually prepare various test wealth management products and customer data. During test execution, transactions need to be triggered daily, and the system's batch settlement process needs to be started. The execution status of the daily test cases needs to be manually checked until all scenarios are covered, and finally, a test summary report is generated. The entire process is highly dependent on manual operation and offline document circulation.

[0003] However, the aforementioned existing technologies have obvious drawbacks: On the one hand, the communication and testing conclusions of business scenarios during business integration are stored in document form. As the business develops, various problems arise, such as data not being easy to keep fresh, data reliability declining, and numerous, messy, and difficult-to-find documents. It is impossible to conduct effective and systematic analysis of all integrated financial products by flipping through documents, and the cost of document analysis is extremely high. On the other hand, each business integration test requires preparing test data, executing batch processes, and checking the test data execution results. Since the tests are generally similar but still have some differences, the testing process involves a large amount of repetitive manual input of the same type, resulting in high labor costs. Summary of the Invention

[0004] The main purpose of this application is to provide a business interaction and docking testing method, device, equipment, storage medium and product, which aims to realize the systematic and intelligent management of the business interaction and docking process of wealth management subsidiaries, reduce repetitive manual input, and improve the automation level and accuracy of docking testing.

[0005] To achieve the above objectives, this application proposes a business interaction and integration testing method, the method comprising: Obtain business scenario data from external wealth management subsidiaries that interact with the wealth management system; Based on the business scenario data, the current system operation configuration of the external wealth management subsidiary is generated; Based on the business scenario data and system operation configuration, generate test cases to be executed for the external wealth management subsidiary; The test case is executed according to the preset batch processing flow.

[0006] In one embodiment, obtaining business scenario data from external wealth management subsidiaries with which the wealth management system interacts includes: Based on the preset standard business scenario docking documents, business docking communication data is entered according to the preset tree-structured hierarchical storage model to obtain the business scenario data of the external wealth management subsidiary that interacts with the wealth management system and to persist the data. The tree-structured hierarchical storage model is organized according to the hierarchy of business category, business scenario, specific transaction type and difference tag. The difference tag is used to identify the differentiated characteristics of the external wealth management subsidiary relative to the standard business scenario.

[0007] In one embodiment, generating the current system operation configuration of the external wealth management subsidiary based on the business scenario data includes: Based on the business scenario data, identify the scope of business scenarios that the external wealth management subsidiary needs to connect with and the difference tags of the business scenarios; Based on the identified scope of business scenarios that the external wealth management subsidiary needs to connect with and the differences in business scenarios, the basic configuration of the test environment and the test data configuration of the external wealth management subsidiary are generated.

[0008] In one embodiment, generating test cases to be executed for the external wealth management subsidiary based on the business scenario data and system operation configuration includes: Based on the basic configuration of the test environment and the test data configuration, as well as the business scenario data, test cases to be executed are generated for the external wealth management subsidiary according to the preset standard working case template.

[0009] In one embodiment, generating test cases to be executed for the external wealth management subsidiary based on the business scenario data and system operation configuration further includes: During the test case generation process, differentiated test cases are generated based on the difference tags of the business scenarios associated with the test cases.

[0010] In one embodiment, the differentiated case generation includes: The differential determination determines whether test cases need to be generated, and / or, what test cases to generate.

[0011] In one embodiment, the method further includes: After the batch run is completed, a data inspection process is automatically triggered to review the execution results of the test cases. During the review process, based on the difference tags associated with the test cases, the corresponding inspection logic is selected for inspection to determine whether each test case passes or fails.

[0012] In one embodiment, the method further includes: Based on the execution conclusions of the test cases for each business scenario being connected, a summary report of the connection test for the external wealth management subsidiary is generated and the test summary report is persistently stored.

[0013] In one embodiment, the method further includes: The stored business scenario data is linked and bound to the test summary report in the system to support joint retrieval and historical backtracking by the financial subsidiary name, business scenario type, product type and / or time version.

[0014] Furthermore, to achieve the above objectives, this application also proposes a business interaction and docking testing device, the device comprising: The acquisition module is used to acquire business scenario data from external wealth management subsidiaries that interact with the wealth management system. The configuration module is used to generate the current system operation configuration of the external wealth management subsidiary based on the business scenario data. The test case generation module is used to generate test cases to be executed for the external wealth management subsidiary based on the business scenario data and system operation configuration. The execution module is used to execute the test cases according to the preset batch processing flow.

[0015] In addition, to achieve the above objectives, this application also proposes a business interaction and docking test device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the business interaction and docking test method described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the business interaction docking test method described above.

[0017] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the business interaction docking test method described above.

[0018] The one or more technical solutions proposed in this application have at least the following technical effects: acquiring business scenario data of external wealth management subsidiaries with which the wealth management system interacts; generating the current system operation configuration of the external wealth management subsidiary based on the business scenario data; generating test cases to be executed for the external wealth management subsidiary based on the business scenario data and system operation configuration; and executing the test cases according to a preset batch processing flow. This application's solution can automatically generate suitable test plans and execute test cases based on the differentiated business characteristics of different wealth management subsidiaries, thereby reducing repetitive manual input, improving the automation level and accuracy of the interface testing, and ultimately achieving systematic and intelligent management of the business interaction and interface process of wealth management subsidiaries. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating the first embodiment of the business interaction and docking testing method of this application; Figure 2 A schematic diagram of the data structure of the tree-structured hierarchical storage model provided in the embodiments of this application; Figure 3 This is a schematic diagram illustrating the test case content provided in the embodiments of this application; Figure 4 This is a schematic diagram of the overall system architecture of the business interaction and docking testing method provided in the embodiments of the present invention; Figure 5 This is a schematic diagram of the module structure of the business interaction and docking test device according to an embodiment of this application; Figure 6 This is a schematic diagram of the hardware operating environment involved in the business interaction and docking test method in the embodiments of this application.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] The main solution of this application embodiment is as follows: Business scenario data of external wealth management subsidiaries with which the wealth management system interacts and connects is obtained; based on the business scenario data, the current system operation configuration of the external wealth management subsidiary is generated; based on the business scenario data and system operation configuration, test cases to be executed are generated for the external wealth management subsidiary; and the test cases are executed according to a preset batch processing flow. This application solution can automatically generate suitable test plans and execute test cases based on the differentiated business characteristics of different wealth management subsidiaries, thereby reducing repetitive manual input, improving the automation level and accuracy of the connection test, and ultimately achieving systematic and intelligent management of the business interaction and connection process of wealth management subsidiaries.

[0026] This application embodiment takes into account the obvious defects of the prior art: On the one hand, the communication conclusions and test conclusions of business scenarios during the business integration process are stored in the form of documents. As the business develops, various problems will arise, such as data not being easy to keep fresh, data reliability decreasing, documents being numerous, messy, and difficult to view. It is impossible to conduct effective and systematic analysis of all the financial management sub-sub ...

[0027] This application provides a solution that enables the persistent and standardized storage and management of business interaction scenarios and test results between bank sales agents and different wealth management subsidiaries, supporting efficient retrieval and backtracking. Simultaneously, it can automatically generate suitable test plans, execute test cases, and conduct reviews based on the differentiated business characteristics of different wealth management subsidiaries, thereby reducing repetitive manual input, improving the automation level and accuracy of the integration test, and ultimately achieving systematic and intelligent management of the business interaction integration process of wealth management subsidiaries.

[0028] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device, business interaction testing device, or system capable of performing the above functions. The following description uses a business interaction testing system as an example to illustrate this embodiment and the subsequent embodiments.

[0029] Based on this, the embodiments of this application provide a business interaction and integration testing method, referring to... Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the business interaction and docking testing method of this application.

[0030] In this embodiment, the business interaction and integration testing method includes steps S10 to S40. The following provides a detailed explanation of each step.

[0031] like Figure 1 As shown, the first embodiment of this application proposes a business interaction and integration testing method, the method comprising: Step S10: Obtain business scenario data of external wealth management subsidiaries with which the wealth management system interacts; Specifically, when the bank's wealth management sales agency system (SA) interacts with the external wealth management subsidiary (TA), it first needs to obtain the business scenario data of the external wealth management subsidiary.

[0032] The business scenario data refers to the collection of various business types and their specific rules involved in the business interaction between the bank's sales agency and the wealth management subsidiary, including but not limited to: supported wealth management product types (such as cash management products, periodic open-ended products, closed-end products, etc.), specific transaction types supported under each product type (such as subscription, redemption, order cancellation, etc.), the permitted scope of customer information changes, and interaction rules for account and fund transactions. This data reflects the differentiated characteristics of the wealth management subsidiary compared to standard business rules and serves as the data foundation for subsequent automated integration testing.

[0033] In practice, the acquisition of business scenario data includes, but is not limited to: data being filled out by technical personnel of the wealth management subsidiary based on a pre-set standard business scenario template and then imported into the system; or data being entered into the system by technical personnel of the sales agency according to unified specifications after the business scenario is confirmed through a meeting between the sales agency and the wealth management subsidiary. After the business scenario data is acquired, it needs to be persistently stored in the system for subsequent steps and historical data review.

[0034] Step S20: Generate the current system operation configuration of the external wealth management subsidiary based on the business scenario data; Then, based on the business scenario data, the current system operation configuration of the external wealth management subsidiary is generated.

[0035] Specifically, after obtaining business scenario data from external wealth management subsidiaries, the system needs to automatically generate system operation configurations for those subsidiaries based on the data.

[0036] The system operation configuration refers to the basic technical configuration required for the bank's sales terminal system to conduct normal business interactions with the wealth management subsidiary, including two main categories: system environment configuration and test data configuration.

[0037] The system environment configuration includes, but is not limited to: communication parameter configuration (such as network address, port number, connection timeout, etc.), file transfer path configuration (such as the receiving and sending directories of the wealth management agreement file), and interface address configuration (such as the Uniform Resource Locator for each business interface). Test data configuration refers to the various basic data required for integration testing, including test product data (such as the code, name, term, yield, and other attribute information of different types of wealth management products) and test customer data (such as simulated wealth management customer identity information, account information, etc.).

[0038] When generating configurations, the system automatically determines which configuration items need to be enabled and which do not, based on the scope of business scenarios the wealth management subsidiary is involved in, as recorded in the business scenario data. For example, if the business scenario data records that the wealth management subsidiary does not offer fixed-term investment products, the system automatically skips the preparation of test data related to fixed-term investment products, thereby avoiding the generation of invalid data and saving system resources.

[0039] Step S30: Based on the business scenario data and system operation configuration, generate test cases to be executed for the external wealth management subsidiary; Specifically, after completing the runtime configuration, the system needs to automatically generate test cases to be executed for the wealth management subsidiary based on the business scenario data obtained above and the generated system runtime configuration.

[0040] The test cases refer to test cases designed to verify whether the interaction between the sales agent and the wealth management subsidiary can proceed normally in various business scenarios. Each test case includes: test objective (to verify what type of transaction), test input data (various parameters required to initiate a transaction), expected results (conditions that the status and data of each system should meet after the transaction is executed), and other information.

[0041] The generation of test cases follows a preset standard workday case template, which defines the various transaction types and their execution order that need to be covered on each financial business workday. During generation, the system checks the associated business scenario data for each case node in the standard template, and determines whether the case needs to be generated and what type should be generated based on the difference tags.

[0042] For example, for a case of subscription to a periodically open product, the system will check the value of the difference label "Regularly Open Product - Whether Connected" in the business scenario data: if the value is "Yes", then the subscription case of the regularly open product of the wealth management subsidiary will be generated; if the value is "No", then the generation of the case will be skipped.

[0043] Step S40: Execute the test case according to the preset batch running process.

[0044] Specifically, after the test cases are generated, the system automatically executes each test case according to the working day rhythm of the wealth management business and the preset batch processing flow.

[0045] The batch processing flow is the daily business process of the wealth management system, which includes multiple nodes such as data import, settlement processing, and end-of-day processing. The system automatically triggers the execution of each batch processing node based on the time when the wealth management subsidiary provides the data file and the expected time when the file is exported to the wealth management subsidiary. After each node is completed, its execution status (success, failure, or timeout) is checked.

[0046] During the batch processing, the system automatically initiates the transaction instructions corresponding to each test case generated in the above steps, simulating real business interaction scenarios. For example, at the transaction initiation time, the system automatically generates a subscription request for a fixed-term product, sends it to the wealth management subsidiary, and checks whether the processing results of the transaction in both systems are consistent during the batch processing and settlement phase.

[0047] Through the above steps, the entire process of business interaction and integration between the bank's sales agency and external wealth management subsidiaries—from business scenario acquisition, system configuration generation, test case generation to test case execution—is fully automated. This eliminates the need for manual intervention in repetitive tasks such as scenario documentation, configuration checks, test case design, and execution triggering, significantly improving the efficiency of integration testing and reducing labor costs and error risks. Furthermore, because the entire process is driven by systematic business scenario data, consistency and repeatability of each integration test are guaranteed.

[0048] This embodiment, through the above-described solution, specifically acquires business scenario data of external wealth management subsidiaries with which the wealth management system interacts; generates the current system operation configuration of the external wealth management subsidiary based on the business scenario data; generates test cases to be executed for the external wealth management subsidiary based on the business scenario data and system operation configuration; and executes the test cases according to a preset batch processing flow. This solution can automatically generate suitable test plans and execute test cases based on the differentiated business characteristics of different wealth management subsidiaries, thereby reducing repetitive manual input, improving the automation level and accuracy of the integration test, and ultimately achieving systematic and intelligent management of the business interaction and integration process of wealth management subsidiaries.

[0049] Based on the first embodiment described above, a second embodiment of this application is proposed. In this embodiment, step S10, obtaining business scenario data of the external wealth management subsidiary that is interactively connected to the wealth management system, is further refined.

[0050] As one implementation method, step S10 involves obtaining business scenario data from external wealth management subsidiaries with which the wealth management system interacts, specifically including: Based on the preset standard business scenario docking documents, business docking communication data is entered according to the preset tree-structured hierarchical storage model to obtain the business scenario data of the external wealth management subsidiary that interacts with the wealth management system and to persist the data. The tree-structured hierarchical storage model is organized according to the hierarchy of business category, business scenario, specific transaction type and difference tag. The difference tag is used to identify the differentiated characteristics of the external wealth management subsidiary relative to the standard business scenario.

[0051] Specifically, in order to input business scenario data from different wealth management subsidiaries into the system in a unified and standardized manner, this application designs a tree-structured hierarchical storage model.

[0052] The tree-structured hierarchical storage model is a data organization method that draws inspiration from mind mapping. It decomposes complex business scenarios step by step from macro to micro levels to form a tree structure.

[0053] The hierarchical structure of the model, from top to bottom, is as follows: The first level is the "Business Category," representing the top-level classification of wealth management business. For example, it can be divided into major business segments such as "Product Management Business," "Transaction Business," and "Client Management Business." The second level is the "Business Scenario," representing the specific business scenario under a particular business category. For example, "Transaction Business" could include "Subscription Transaction Scenario," "Redemption Transaction Scenario," and "Order Cancellation Transaction Scenario." The third level is the "Specific Transaction Type," representing the specific transaction product or operation type within a particular business scenario. For example, "Subscription Transaction Scenario" can be further divided into specific types such as "Cash Product Subscription," "Fixed-Term Product Subscription," and "Closed-End Product Subscription." The fourth level is the "Differentiation Label," indicating the potentially differentiated characteristics of this specific transaction type across different wealth management subsidiaries.

[0054] The difference tag is the core data structure for achieving differentiated processing in this application. It is a key-value pair identifier used to record the differences in the implementation of specific business scenario nodes across different wealth management subsidiaries. The key of the difference tag represents the difference dimension, and the value of the difference tag represents the specific value under that dimension. Through the difference tag, the system can accurately describe the differences between each wealth management subsidiary and the standard model at each business node, providing data support for subsequent differentiated configuration, differentiated case generation, and differentiated review.

[0055] like Figure 2 As shown, Figure 2This is a schematic diagram of the data structure of the tree-structured hierarchical storage model provided in this application embodiment. This application designs a tree-structured storage mode based on mind maps to input data for various business scenarios of the sales agent (SA) and financial advisor (TA) ends, and supports exporting system business scenarios as Word documents for financial advisors to fill out and then importing into the system for persistent storage.

[0056] In this embodiment, the specific process for data entry based on the preset standard business scenario interface document is as follows: First, the system automatically generates a standardized business scenario entry document (e.g., a Word document) based on the hierarchical structure of the tree-like hierarchical storage model. This document enumerates all standard business scenarios according to the hierarchy of business category, business scenario, and specific transaction type, and reserves differentiation label options (such as checkboxes, drop-down menus, or fill-in boxes) for each scenario, allowing external wealth management subsidiaries to select or fill in the information according to their own business needs.

[0057] Secondly, after receiving the standardized document, the technical staff of the external wealth management subsidiary fill in the corresponding difference label values ​​at each business scenario node according to the company's actual business rules, and complete the document filling.

[0058] Finally, the sales-side technical staff imported the completed documents from the wealth management subsidiary into the system. Upon receiving the documents, the system automatically parsed the content and entered the business scenario data and difference tags at each level into the database according to the hierarchical tree storage model. At the same time, it recorded the version information of this entry (including the entry time, operator, version number, etc.), thus achieving persistent storage of business scenario data.

[0059] Through the above steps, this embodiment achieves standardized, structured entry and persistent storage of business scenario data for wealth management subsidiaries. Because the data is organized according to a unified tree model, the business scenario records of all wealth management subsidiaries maintain a consistent style and clear structure, avoiding the problems of inconsistent styles and disorganized storage associated with traditional document storage. Simultaneously, since the data is stored in a structured format in the database, the system can support rapid retrieval, comparison, and historical backtracking based on multiple dimensions such as wealth management subsidiary name, business scenario type, product type, and time version, providing a reliable data foundation for subsequent systematic analysis.

[0060] Based on any of the above embodiments, a third embodiment of this application is proposed. In this embodiment, step S102, generating the current system operation configuration of the external wealth management subsidiary based on the business scenario data, is refined.

[0061] In this embodiment, the bank's sales agent (SA) and the wealth management subsidiary (TA) need to perform two necessary configurations before startup for business interaction: (1) Basic system operation configuration; (2) Preparation of basic test data for docking test.

[0062] Based on the TA business scenarios imported through the above steps, the system automatically prepares the configuration for each test environment. It can also perform differentiated configuration for different TA business scenarios, reducing manual judgment and configuration costs, and achieving differentiated test configurations with external companies.

[0063] Example: For automated product configuration, the system needs to automatically determine the product data that the current TA needs to prepare based on the parameter values ​​of "Cash Products - Whether to Integrate" and "Regular Products - Whether to Integrate" in the business tag.

[0064] As one implementation method, step S102, based on the business scenario data, generates the current system operation configuration of the external wealth management subsidiary, specifically including: Based on the business scenario data, identify the scope of business scenarios that the external wealth management subsidiary needs to connect with and the difference tags of the business scenarios; Based on the identified scope of business scenarios that the external wealth management subsidiary needs to connect with and the differences in business scenarios, the basic configuration of the test environment and the test data configuration of the external wealth management subsidiary are generated.

[0065] Specifically, the generation of the system runtime configuration consists of two sub-steps: First, business scenario scope and differential label recognition.

[0066] The system reads business scenario data of the target wealth management subsidiary from the database, traverses each node in the tree-structured storage model, and identifies the scope of business scenarios that the wealth management subsidiary actually needs to connect with. The identification logic is as follows: for each business scenario node, it checks whether its associated difference tag contains an identifier with the meaning of "connection required" or similar. For example, for the "fixed-term product subscription" node, if the difference tag "fixed-term product - connection required" is "yes", then the node is included in the scope of business scenarios that need to be connected; if the value is "no", then the node is excluded from the scope of connection. By traversing all nodes, the system can completely identify the scope of business scenarios that the wealth management subsidiary needs to connect with and the specific difference tag information under each scenario.

[0067] Second, the generation of basic test environment configuration and test data configuration.

[0068] After identifying the scope of business scenarios and difference tags of the wealth management subsidiary, the system automatically generates the basic configuration of the test environment and the test data configuration accordingly.

[0069] The basic configuration of the test environment refers to the environmental parameters that need to be set to ensure normal communication and data exchange between the sales agency system and the wealth management subsidiary. This basic configuration includes: communication parameter configuration (such as the network address, communication port number, and connection timeout of the wealth management subsidiary's server) to ensure smooth network connectivity; file transfer path configuration (such as the upload and download directories for wealth management-related protocol files) to ensure the correct sending and receiving of business data files; and interface address configuration (such as the API interface URLs corresponding to each business function) to ensure that transaction requests are routed to the correct server endpoints. These basic configurations are populated based on the specific parameters of the wealth management subsidiary, achieving automated configuration of the runtime environment.

[0070] The test data configuration refers to the basic business data required for performing integration tests, mainly including test product data and test customer data. The preparation logic for test product data is as follows: the system automatically determines which product types of test data need to be prepared based on the identified scope of the integration business scenario and the values ​​of the difference tags.

[0071] Specifically, the system checks the difference tags corresponding to each product type. If the tag value for a certain product type is "integrated" or "yes," the system automatically generates complete test data for that product type; if the tag value is "not integrated" or "no," the system does not generate test data for that product type. The preparation logic for test customer data is similar. Based on the scope of customer transactions in the business scenario, the system automatically generates simulated customer data that meets the testing requirements.

[0072] Through the above steps, this embodiment achieves automated generation of system operation configurations driven by business scenario data. The system no longer requires manual judgment based on documentation to determine which configurations and data need to be prepared; instead, the system automatically completes all decisions and preparations based on difference tags, greatly reducing the cost of manual judgment and the possibility of configuration errors. Furthermore, since the configuration generation logic is completely consistent with the business scenario data, the consistency between the system configuration and business agreements is guaranteed.

[0073] Based on any of the above embodiments, a fourth embodiment of this application is proposed. In this embodiment, step S103, generating test cases to be executed for the external wealth management subsidiary according to the business scenario data and system operation configuration, is refined.

[0074] As one implementation method, step S103 involves generating test cases to be executed for the external wealth management subsidiary based on the business scenario data and system operation configuration, specifically including: Based on the basic configuration of the test environment and the test data configuration, as well as the business scenario data, test cases to be executed are generated for the external wealth management subsidiary according to the preset standard working case template. In the test case generation process, differentiated test cases are generated based on the difference tags of the business scenarios associated with the test cases; the generation of differentiated test cases includes: determining whether test cases need to be generated, and / or determining what kind of test cases to generate.

[0075] In this embodiment, the connection between the bank's sales agent (SA) and the wealth management subsidiary (TA) requires the SA to initiate account-related and fund-related transactions, covering various transaction types across different product categories, to ensure that all types of transactions can be correctly processed by both parties during formal interaction. Automatically generated test cases include: Case generation mode: Since financial management business interactions are conducted on weekdays, the system is designed with a standard weekday case mode to generate daily cases to be executed based on the actual business configuration of the financial advisor (TA) according to the weekday dimension.

[0076] Differentiated case generation: Case nodes are associated with business scenario tags, and differentiated cases are generated based on the content of the scenario tags. This is mainly reflected in: differentiating whether to generate cases and differentiating what kind of cases to generate.

[0077] Example: For instance, regarding regularly released product integration cases, the system determines whether to generate a case based on the "regularly released product - integration status" in the communication business scenario. Similarly, for changes to customer four elements, the system will generate changes to customer four elements that meet the current expectations of the wealth management subsidiary and changes that are outside the expected scope, based on the customer's permitted change scenario patterns, to verify the handling of normal and abnormal changes. Figure 3 As shown, Figure 3 The following is a sample illustration for reference.

[0078] Specifically, the automatic generation of test cases is one of the core components of this application's automation of integration testing. This component unfolds according to the following logic: First, the system includes a pre-set set of standard workday case templates. These templates are a complete case generation framework designed based on the fundamental rules and common scenarios of wealth management business. Using workdays as the time unit, the templates define the various transaction types and their execution order that should be covered on each workday for wealth management business. The template design considers typical workflows in wealth management business interactions; for example, within a workday, it needs to sequentially cover account-related transactions (such as customer account opening and customer information changes), fund-related transactions, and transactions of various product types. The standard templates provide a complete case framework, ensuring full coverage of basic business scenarios.

[0079] Secondly, based on the standard template, the system performs differentiated tailoring and expansion by incorporating the business scenario data (especially differential label information) of the target wealth management subsidiary, generating a customized set of test cases. Specifically, the system iterates through each case node in the standard template, executing the following differentiated judgment logic for each node: Differentiation Judgment 1: Whether test cases need to be generated.

[0080] The system checks whether the business scenario corresponding to the current case node is actually integrated with the target wealth management subsidiary. This determination is made by reading the difference tag associated with the node. If the difference tag value is "integrated" or "yes", the system confirms that the scenario needs to be tested and continues to generate the corresponding test case; if the difference tag value is "not integrated" or "no", the system skips the node and does not generate the case. This mechanism ensures that the test case set accurately matches the actual business scope of the wealth management subsidiary, avoids generating invalid cases, and reduces resource waste.

[0081] Differentiation Judgment 2: What type of test cases are generated?

[0082] For nodes that require test cases, the system further determines the type of test case to generate based on the specific values ​​of the difference labels. This determination includes the following typical scenarios: Scenario 1: For scenarios involving changes to customer information, the system determines the scope of allowed changes to customer information based on the "allowed range of customer information changes" recorded in the difference label. If the difference label indicates "Full change allowed," the system generates two types of test cases: one is a "normal change test case"—providing change data within the allowed range for testing to verify whether the normal change process passes; the other is an "abnormal change test case"—providing change data exceeding the allowed range for testing to verify whether the system correctly intercepts and returns error information in abnormal scenarios. If the difference label indicates "Partial change allowed only," the system generates only normal change test cases within the corresponding range.

[0083] Scenario 2: For scenarios involving file interaction, the system makes a judgment based on the "file mode" recorded in the difference label. If the difference label indicates "specific feedback file mode required," the system adds a corresponding check mark to the test case when generating the test case, indicating that the return data of the specific feedback file needs to be checked additionally during the review process.

[0084] Through the differentiated generation logic described above, the system can automatically generate a set of test cases that precisely match the business characteristics of each wealth management subsidiary within a unified, standardized template framework. Compared to manually designing test cases, this embodiment achieves complete automation of test case generation and can accurately cover both normal and abnormal scenarios, improving the comprehensiveness and accuracy of testing.

[0085] Based on any of the above embodiments, a fifth embodiment of this application is proposed. In this embodiment, the method further includes: After the batch run is completed, a data inspection process is automatically triggered to review the execution results of the test cases.

[0086] The operation of the wealth management system involves multiple process nodes, such as import, settlement, and end-of-day processing. The automation system needs to automatically trigger the process based on the time when the wealth management subsidiary (TA) provides file data and the expected time when the file is exported to the wealth management subsidiary, and check the execution status of each process.

[0087] After automatically completing the liquidation, the system triggers a data check to examine the expected execution results of the corresponding cases. The check methods are categorized as follows based on case classification: Check the execution results directly according to the check logic; The case inspection results need to be associated with scene tags. The corresponding inspection mode is determined based on the differences in scene tags, and the inspection conclusion is drawn.

[0088] Example: For example, the 03B file mode label: If the business conclusion is "04B mode is required", checking the result of the failed deduction requires checking whether the returned data of 04B matches, and also checking whether the status of the transaction data after settlement matches. If 04B mode is not required, it is only necessary to check whether the status after settlement matches.

[0089] The automated process summarizes the daily execution case achievement into an Excel report, which is then exported and pushed to the system user. For cases that are not achieved, manual intervention can be initiated after communication to re-trigger the case execution.

[0090] As one implementation method, during the review process, based on the difference tags associated with the test cases, the corresponding inspection logic is selected for inspection in a differentiated manner to determine whether each test case passes or fails.

[0091] Specifically, after the batch processing is completed, the system automatically enters the case review stage without manual intervention. This review refers to checking whether the actual execution result of each executed test case matches the expected result. To accommodate the differences among various wealth management subsidiaries, the review process also employs differentiated checking logic based on difference tags.

[0092] As one implementation method, the review process is implemented as follows: First, during the execution of each node in the batch processing (including data import node, clearing node, end-of-day node, etc.), the system automatically collects the actual execution data of each test case, including the transaction status (success / failure / processing), data file exchange records between systems, and the transaction record status in the database.

[0093] Secondly, after the batch run is complete, for each test case, the system automatically selects the corresponding inspection logic based on its associated difference tags. The difference inspection logic mainly includes the following scenarios: Scenario 1: Case inspection involving differences in file schemas.

[0094] For cases with the "Requires specific feedback file pattern" difference label, the system performs a two-level check: first, it checks whether the post-transaction settlement data status matches the expectation; second, it additionally checks whether the returned data from the corresponding feedback file matches the expectation. Only when both levels of checks pass is the case deemed "passed." For cases without the "Requires specific feedback file pattern" difference label, the system only performs the first level of check, i.e., only checks whether the post-transaction settlement data status matches the expectation.

[0095] Scenario 2: Case inspection involving abnormal changes.

[0096] When reviewing the generated "abnormal change test cases", the system not only checks whether the system correctly intercepted the abnormal request and returned the error information, but also checks whether the system's error code is consistent with the agreement of the wealth management subsidiary, to ensure that both parties have a consistent understanding and handling of abnormal scenarios.

[0097] Through the differentiated review logic described above, the system can automatically adopt the most appropriate inspection method to verify the results based on the different business rules of different wealth management subsidiaries, eliminating the need for manual judgment and verification. This differentiated review mechanism ensures a precise match between the inspection logic and business agreements, improving the accuracy and efficiency of the review.

[0098] Based on any of the above embodiments, a sixth embodiment of this application is proposed. In this embodiment, the method further includes: Based on the execution conclusions of the test cases for each business scenario being connected, a summary report of the connection test for the external wealth management subsidiary is generated and the test summary report is persistently stored. The stored business scenario data is linked and bound to the test summary report in the system to support joint retrieval and historical backtracking by the name of the wealth management subsidiary, business scenario type, product type and / or time version.

[0099] Specifically, after the review process completes the inspection of all test cases, the system automatically proceeds to the test summary report generation stage. This stage includes the following steps: Step 1: Generation of the test summary report.

[0100] The system aggregates the execution conclusion data of all test cases, statistically organizes it according to the dimensions of business analysis, and generates a structured integration test summary report. The test summary report includes the following: (1) Execution statistics by product type: The system counts the total number of test cases, the number of successful test cases, the number of failed test cases, and the pass rate for each product type. This statistical dimension can clearly show the docking test status of different product types, making it easier to discover potential problems of specific product types.

[0101] (2) Execution details of each transaction type: Under each product type, the system further subdivides and displays the execution status according to the transaction type, which makes it easier to accurately locate the anomalies of the specific transaction type.

[0102] (3) Highlighting abnormal scenarios: For test cases where the execution result is failure, the system will highlight them in red in the report and attach a detailed explanation of the reasons for failure, prompting both the sales agent and the wealth management subsidiary to pay attention to and analyze the reasons.

[0103] Step 2: Persistent storage of the test summary report.

[0104] The system stores the generated test summary reports in the database as structured data, and also supports exporting them to common formats such as Excel for users to view. A complete summary report for each integration test is saved, forming a historical test data archive.

[0105] Step 3: Linking and backtracking business scenario data with test summary reports.

[0106] The system associates and binds stored business scenario data with test summary reports, establishing a mapping relationship between the two. After binding, the system supports users to perform joint searches and historical backtracking according to the following dimensions: Wealth Management Subsidiary Name: Search for all historical connection test reports of a specific wealth management subsidiary; Business scenario type: Query the test results of specific business scenarios in various wealth management subsidiaries and historical versions; Product Type: Query the test pass status of a specific product type in various docking projects; Time Version: Query the integration test results for a specific time point or a specific version number.

[0107] Through the aforementioned association and multi-dimensional search functions, the sales agent can quickly trace back the connection conclusions of any wealth management subsidiary at any point in time, enabling efficient comparative analysis across wealth management subsidiaries and versions. When the business rules of a wealth management subsidiary change and regression testing is required, the system can quickly retrieve historical test data for comparison, identify the scope of the change's impact, and greatly reduce the cost of tracing historical conclusions and analyzing the impact of changes.

[0108] Through the above steps, this embodiment achieves systematic and structured storage and efficient backtracking of test conclusions, completely overcoming the drawbacks of traditional document storage methods, such as data not being easily preserved, difficulty in retrieval, and high analysis costs. The association and binding of test summary reports with business scenario data enables a closed-loop management of "business agreements" and "test verification conclusions," providing a reliable data foundation for subsequent systematic analysis, compliance auditing, and change management.

[0109] Reference Figure 4 As shown, Figure 4 A schematic diagram of the overall system architecture for the business interaction and docking testing method provided in this application embodiment.

[0110] The overall system architecture of the business interaction and docking testing method provided in this embodiment includes: The module includes modules for exporting and entering data for business integration and communication, configuration of automated interaction, automatic generation and execution of test cases, batch processing of automated business processes and case review, and generation of summary reports.

[0111] The overall system process includes: Step 1: Export the standard document for the current TA's business scenario through the business integration communication data export and entry module (generating a fixed-format document based on the hierarchical tree storage scheme of the business scenario). Step 2: Send the standard business scenario integration document to the relevant personnel of the wealth management subsidiary for completion and confirmation; Step 3: Relevant personnel from the wealth management subsidiary fill out and confirm the business scenario communication document, which is then imported into the system. The system stores the document persistently and automatically identifies and records any changes. Step 4: Automatically generate the necessary system operation configuration for the current TA based on the defined business scenario; Step 5: Automatically generate basic test data such as managers, products, and customers required for business integration testing based on the defined business scenarios; Step 6: Automatically generate the test cases to be executed on each integration test workday based on the defined business scenario, and initiate the relevant test transactions; Step 7: Automatically initiate a batch processing flow for the confirmation documents returned by the wealth management subsidiary every day, and check the test results according to the test cases after initiation; Step 8: Test complete. Generate a test summary report based on all business scenarios involved in this integration.

[0112] In summary, the business interaction and integration testing method provided in this application uses a tree-structured hierarchical storage model to structurally store the differentiated business scenarios of different wealth management subsidiaries. It drives end-to-end differentiated adaptation from system configuration and test case generation to execution review through difference tags, and achieves persistent management of integration test conclusions through automatic generation and associated backtracking of test summary reports, thus constructing a complete automated integration testing closed-loop system. This method effectively solves the technical problems of chaotic document storage, high repetitive manual input, and reliance on manual judgment for difference adaptation in traditional integration processes, significantly improving the efficiency, accuracy, and manageability of business interaction and integration among wealth management subsidiaries.

[0113] Compared to existing technologies, current methods for connecting wealth management subsidiaries rely on document storage for business scenarios and test results. This results in inconsistent document styles, disorganized storage, and difficulties in retrieval and retrospection. Furthermore, all wealth management subsidiary connections require manual intervention, necessitating manual differentiation analysis and execution, leading to significant costs. This application utilizes an automated connection system to ensure consistent business records for the connection scenarios between the bank's sales agency and each external wealth management subsidiary. It can automatically conduct differentiated connection tests based on the unique characteristics of different wealth management subsidiaries, automatically summarize test reports based on test results, and archive test data. It also provides clear records of every change, significantly reducing repetitive costs and more clearly and accurately preserving historical test results for analysis and retrospection.

[0114] Furthermore, to achieve the above objectives, this application also proposes a business interaction and docking testing device, such as... Figure 5 As shown, the device includes: Module 10 is used to acquire business scenario data of external wealth management subsidiaries that are interacted with by the wealth management system; Configuration module 20 is used to generate the current system operation configuration of the external wealth management subsidiary based on the business scenario data; The case generation module 30 is used to generate test cases to be executed for the external wealth management subsidiary based on the business scenario data and system operation configuration. The execution module 40 is used to execute the test cases according to the preset batch running process.

[0115] The business interaction and docking testing device provided in this application, employing the business interaction and docking testing method described in the above embodiments, can automatically generate suitable test plans and execute test cases based on the differentiated business characteristics of different wealth management subsidiaries. This reduces repetitive manual input, improves the automation level and accuracy of docking testing, and ultimately achieves systematic and intelligent management of the business interaction and docking process of wealth management subsidiaries. Compared with the prior art, the beneficial effects of the business interaction and docking testing device provided in this application are the same as those of the business interaction and docking testing method provided in the above embodiments, and other technical features in the business interaction and docking testing device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0116] In addition, to achieve the above objectives, this application also proposes a business interaction and docking test device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the business interaction and docking test method described above.

[0117] The following is for reference. Figure 6 The diagram illustrates a structural schematic of a service interaction interoperability test device suitable for implementing embodiments of this application. The service interaction interoperability test device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The business interaction and docking test equipment shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0118] like Figure 6As shown, the business interaction docking test equipment may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the business interaction docking test equipment. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the service interoperability test equipment to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a service interoperability test equipment with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0119] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0120] The business interaction and docking testing equipment provided in this application, employing the business interaction and docking testing method described in the above embodiments, can automatically generate suitable test plans and execute test cases based on the differentiated business characteristics of different wealth management subsidiaries. This reduces repetitive manual input, improves the automation level and accuracy of docking testing, and ultimately achieves systematic and intelligent management of the business interaction and docking process of wealth management subsidiaries. Compared with the prior art, the beneficial effects of the business interaction and docking testing equipment provided in this application are the same as those of the business interaction and docking testing method provided in the above embodiments, and other technical features in this business interaction and docking testing equipment are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0121] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0122] In addition, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the business interaction docking test method described above.

[0123] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0124] The aforementioned computer-readable storage medium may be included in the business interaction and docking test equipment; or it may exist independently and not be assembled into the business interaction and docking test equipment.

[0125] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the business interaction and docking test device, the business interaction and docking test device: acquires business scenario data of the external wealth management subsidiary with which the wealth management system interacts and docks; generates the current system operation configuration of the external wealth management subsidiary based on the business scenario data; generates test cases to be executed for the external wealth management subsidiary based on the business scenario data and the system operation configuration; and executes the test cases according to a preset batch processing flow.

[0126] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0127] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0128] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0129] The readable storage medium provided in this application is a computer-readable storage medium. This medium stores computer-readable program instructions (i.e., computer programs) for executing the aforementioned business interaction and docking testing method. It can automatically generate suitable test plans and execute test cases based on the differentiated business characteristics of different wealth management subsidiaries, thereby reducing repetitive manual input, improving the automation level and accuracy of docking tests, and ultimately achieving systematic and intelligent management of the business interaction and docking process of wealth management subsidiaries. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the business interaction and docking testing method provided in the above embodiments, and will not be repeated here.

[0130] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the business interaction docking test method described above.

[0131] The computer program product provided in this application can automatically generate suitable test plans and execute test cases based on the differentiated business characteristics of different wealth management subsidiaries, thereby reducing repetitive manual input, improving the automation level and accuracy of docking tests, and ultimately realizing the systematic and intelligent management of the business interaction docking process of wealth management subsidiaries. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the business interaction docking test method provided in the above embodiments, and will not be repeated here.

[0132] The one or more technical solutions proposed in this application have at least the following technical effects: acquiring business scenario data of external wealth management subsidiaries with which the wealth management system interacts; generating the current system operation configuration of the external wealth management subsidiary based on the business scenario data; generating test cases to be executed for the external wealth management subsidiary based on the business scenario data and system operation configuration; and executing the test cases according to a preset batch processing flow. This application's solution can automatically generate suitable test plans and execute test cases based on the differentiated business characteristics of different wealth management subsidiaries, thereby reducing repetitive manual input, improving the automation level and accuracy of the interface testing, and ultimately achieving systematic and intelligent management of the business interaction and interface process of wealth management subsidiaries.

[0133] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A business interaction integration testing method, characterized in that, The method includes: Obtain business scenario data from external wealth management subsidiaries that interact with the wealth management system; Based on the business scenario data, the current system operation configuration of the external wealth management subsidiary is generated; Based on the business scenario data and system operation configuration, generate test cases to be executed for the external wealth management subsidiary; The test case is executed according to the preset batch processing flow.

2. The method as described in claim 1, characterized in that, The acquisition of business scenario data from external wealth management subsidiaries that interact with the wealth management system includes: Based on the preset standard business scenario docking documents, business docking communication data is entered according to the preset tree-structured hierarchical storage model to obtain the business scenario data of the external wealth management subsidiary that interacts with the wealth management system and to persist the data. The tree-structured hierarchical storage model is organized according to the hierarchy of business category, business scenario, specific transaction type and difference tag. The difference tag is used to identify the differentiated characteristics of the external wealth management subsidiary relative to the standard business scenario.

3. The method as described in claim 2, characterized in that, The step of generating the current system operation configuration of the external wealth management subsidiary based on the business scenario data includes: Based on the business scenario data, identify the scope of business scenarios that the external wealth management subsidiary needs to connect with and the difference tags of the business scenarios; Based on the identified scope of business scenarios that the external wealth management subsidiary needs to connect with and the differences in business scenarios, the basic configuration of the test environment and the test data configuration of the external wealth management subsidiary are generated.

4. The method as described in claim 3, characterized in that, The step of generating test cases to be executed for the external wealth management subsidiary based on the business scenario data and system operation configuration includes: Based on the basic configuration of the test environment and the test data configuration, as well as the business scenario data, test cases to be executed are generated for the external wealth management subsidiary according to the preset standard working case template.

5. The method as described in claim 3, characterized in that, The step of generating test cases to be executed for the external wealth management subsidiary based on the business scenario data and system operation configuration also includes: During the test case generation process, differentiated test cases are generated based on the difference tags of the business scenarios associated with the test cases.

6. The method as described in claim 5, characterized in that, The generation of differentiated cases includes: The differential determination determines whether test cases need to be generated, and / or, what test cases to generate.

7. The method as described in claim 5, characterized in that, The method further includes: After the batch run is completed, a data inspection process is automatically triggered to review the execution results of the test cases. During the review process, based on the difference tags associated with the test cases, the corresponding inspection logic is selected for inspection to determine whether each test case passes or fails.

8. The method as described in claim 1, characterized in that, The method further includes: Based on the execution conclusions of the test cases for each business scenario being connected, a summary report of the connection test for the external wealth management subsidiary is generated and the test summary report is persistently stored.

9. The method as described in claim 8, characterized in that, The method further includes: The stored business scenario data is linked and bound to the test summary report in the system to support joint retrieval and historical backtracking by the financial subsidiary name, business scenario type, product type and / or time version.

10. A business interaction and docking testing device, characterized in that, The device includes: The acquisition module is used to acquire business scenario data from external wealth management subsidiaries that interact with the wealth management system. The configuration module is used to generate the current system operation configuration of the external wealth management subsidiary based on the business scenario data. The test case generation module is used to generate test cases to be executed for the external wealth management subsidiary based on the business scenario data and system operation configuration. The execution module is used to execute the test cases according to the preset batch processing flow.

11. A business interaction and interface testing device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the business interaction docking test method as described in any one of claims 1 to 9.

12. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the business interaction docking test method as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the business interaction docking test method as described in any one of claims 1 to 9.

Images