Test system and method suitable for low-code platform

Abstract

The invention provides a test system and method suitable for a low-code platform. The system comprises the low-code platform, a transaction server and a baffle server. Aiming at each third-party system, the low-code platform configures a test rule in the baffle server; the low-code platform replaces the actual address of each third-party system with a test address corresponding to the baffle server according to the baffle opening operation, and sends a first refreshing instruction to the transaction server; when the transaction server receives a first refreshing instruction, refreshing the actual address of each third-party system pre-cached in the transaction server into a test address; when the transaction server receives a test instruction, taking each transaction request as a test request and sending the test request to the baffle server based on a test address; aiming at each test request, the baffle server returns a test response to the transaction server based on the test rule; and the transaction server receives each test response returned by the baffle server, so that the aim of reducing the test development workload is fulfilled.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to a testing system and method suitable for low-code platforms. Background Technology

[0002] Financial trading systems often interact with numerous third-party systems (such as risk control systems, exchanges, etc.). Different third-party systems require different communication protocols and message formats. External factors such as untimely setup of third-party system testing environments and untimely opening of testing interfaces can seriously affect the efficiency of trading testing.

[0003] In existing technologies, test slate tools are testing aids used to simulate different software systems. They help testers simulate and test the behavior of external systems, services, and interfaces without relying on the actual system. By using test slates, testers can focus on specific third-party system interaction functions or services, construct custom scenarios to obtain test results for specific branches of financial transaction processes, and solve the problems of uncertain third-party server startup times and the inability to perform regression testing after component or process changes during regression testing. Currently, most slate testing tools are mock service systems developed to simulate third-party systems, services, and interfaces, often used in unit and regression testing. They abstract the service calls of third-party systems into standard call classes and are mainly suitable for large Java projects.

[0004] In low-code platforms, a financial transaction task typically involves multiple communication components. Each communication component is responsible for communicating with one or more third-party systems, thus involving dozens of third-party systems. Unified and coordinated testing is very difficult. If existing technologies are used to abstract the service calls of third-party systems into standard call classes, and the standard call classes have corresponding simulation classes, the development workload for testing is substantial. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a testing system and method suitable for low-code platforms, so as to reduce the workload of test development.

[0006] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0007] The first aspect of this invention discloses a testing system suitable for a low-code platform, the system comprising: a low-code platform, a transaction server, and a baffle server; the transaction server executes a transaction process pre-generated by the low-code platform, the transaction process including sending transaction requests to one or more third-party systems;

[0008] The low-code platform is used to configure test rules in the shield server for each of the third-party systems; based on the user's shield activation operation, the actual addresses of each of the third-party systems configured in the low-code platform are replaced with the test addresses corresponding to the shield server, and a first refresh command is sent to the transaction server;

[0009] The transaction server is configured to, upon receiving the first refresh instruction, refresh the actual addresses of each of the third-party systems pre-cached in the transaction server to the test address; upon receiving a test instruction input by the user, treat each of the transaction requests as test requests and send each of the test requests to the baffle server based on the test address; and receive test responses corresponding to each of the test requests returned by the baffle server.

[0010] The baffle server is configured to return a corresponding test response to the transaction server for each test request, based on the test rules.

[0011] Optionally, the low-code platform is specifically used for:

[0012] Obtain the cluster IP and default response message corresponding to the transaction process; for each third-party system, obtain the corresponding target request message and target response message; in response to the user's configuration operation, configure the corresponding matching rules for the third-party system selected by the user; based on the cluster IP, the default response message and each matching rule, configure test rules in the baffle server;

[0013] Accordingly, the baffle server is specifically used for:

[0014] For each test request, the server IP and test request message corresponding to the transaction server are extracted from the test request, and the third-party system corresponding to the test request is taken as the target system. When the server IP matches the IP of the cluster to which it belongs, it is determined whether the test request message matches the matching rule corresponding to the target system or the target request message corresponding to the target system. If so, the target response message corresponding to the target system is returned to the transaction server as a test response. If not, the default response message is returned to the transaction server as a test response.

[0015] Optionally, the low-code platform is specifically used for:

[0016] For each of the aforementioned third-party systems, the corresponding target request message and the corresponding target response message are obtained from a preset test case library or historical messages.

[0017] Optionally, the transaction server is also used for:

[0018] After refreshing the actual addresses of the various third-party systems pre-cached on the transaction server to the test addresses, a refresh completion instruction is returned to the low-code platform.

[0019] Accordingly, the low-code platform is also used for:

[0020] When the refresh completion instruction is received, the addresses of each of the third-party systems configured in the low-code platform are replaced with the test addresses back to the actual addresses of each of the third-party systems.

[0021] Optionally, the low-code platform is also used for:

[0022] When the transaction server receives the test response corresponding to each test request, it sends a second refresh command to the transaction server according to the user's closing baffle operation;

[0023] Accordingly, the transaction server is also used for:

[0024] When the second refresh instruction is received, the addresses of each third-party system cached by the transaction server are refreshed from the test addresses to the actual addresses of each third-party system.

[0025] A second aspect of this invention discloses a testing method suitable for low-code platforms, applied to any of the testing systems disclosed in the first aspect of this invention, the method comprising:

[0026] Utilize a low-code platform to configure test rules in the shield server for each third-party system;

[0027] Based on the user's opening of the baffle, the low-code platform replaces the actual addresses of each third-party system configured in the low-code platform with the test address corresponding to the baffle server, and sends a first refresh command to the transaction server.

[0028] When the transaction server receives the first refresh instruction, it refreshes the actual addresses of each of the third-party systems that are pre-cached in the transaction server to the test address;

[0029] When the transaction server receives a test instruction input by the user, it treats each transaction request as a test request and sends each test request to the baffle server based on the test address.

[0030] For each test request, the baffle server returns a corresponding test response to the transaction server based on the test rules.

[0031] The transaction server receives test responses corresponding to each test request returned by the baffle server.

[0032] Optionally, the low-code platform that configures test rules in the baffle server for each of the aforementioned third-party systems using the low-code platform includes:

[0033] The system utilizes a low-code platform to obtain the cluster IP and default response message corresponding to the transaction process; for each third-party system, it obtains the corresponding target request message and target response message; in response to the user's configuration operation, it configures the corresponding matching rules for the third-party system selected by the user; and based on the cluster IP, the default response message, and each matching rule, it configures test rules in the baffle server.

[0034] Accordingly, the step of using the baffle server to return a corresponding test response to the transaction server for each test request based on the test rules includes:

[0035] For each test request, the server IP and test request message corresponding to the transaction server are extracted from the test request, and the third-party system corresponding to the test request is taken as the target system. When the server IP matches the IP of the cluster to which it belongs, it is determined whether the test request message matches the matching rule corresponding to the target system or the target request message corresponding to the target system. If so, the target response message corresponding to the target system is returned to the transaction server as a test response. If not, the default response message is returned to the transaction server as a test response.

[0036] Optionally, obtaining the corresponding target request message and the corresponding target response message for each of the aforementioned third-party systems includes:

[0037] For each of the aforementioned third-party systems, the corresponding target request message and the corresponding target response message are obtained from a preset test case library or historical messages.

[0038] Optionally, the method further includes:

[0039] After refreshing the actual addresses of the various third-party systems pre-cached in the transaction server to the test addresses, the transaction server returns a refresh completion instruction to the low-code platform.

[0040] When the low-code platform receives the refresh completion instruction, it replaces the addresses of each third-party system configured in the low-code platform with the test addresses back to the actual addresses of each third-party system.

[0041] Optionally, the method further includes:

[0042] When the transaction server receives the test response corresponding to each test request, the low-code platform sends a second refresh instruction to the transaction server according to the user's closing baffle operation;

[0043] When the transaction server receives the second refresh instruction, it refreshes the addresses of each third-party system cached by the transaction server from the test addresses to the actual addresses of each third-party system.

[0044] A testing system and method for low-code platforms provided by the above embodiments of the present invention are provided. The system includes: a low-code platform, a transaction server, and a shield server. The transaction server executes a transaction process pre-generated by the low-code platform, the transaction process including sending transaction requests to one or more third-party systems. The low-code platform is used to configure test rules in the shield server for each of the third-party systems. Based on the user's shield activation operation, the actual addresses of each of the third-party systems configured in the low-code platform are replaced with the test addresses corresponding to the shield server, and a first refresh instruction is sent to the transaction server. When the transaction server receives the first refresh instruction, it refreshes the actual addresses of each of the third-party systems pre-cached in the transaction server to the test addresses. When it receives a test instruction input by the user, it treats each transaction request as a test request and sends each test request to the shield server based on the test address. It receives test responses corresponding to each test request returned by the shield server. The shield server is used to return a corresponding test response to the transaction server for each test request based on the test rules. In this solution, by using a shield server and address switching mechanism, the original highly distributed simulation testing that required individual testing on dozens of third-party systems is transformed into standardized testing that is centrally configured on a single platform, thereby reducing the workload of test development. Attached Figure Description

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

[0046] Figure 1 This is an architecture diagram of a testing system suitable for low-code platforms disclosed in an embodiment of the present invention;

[0047] Figure 2 This is a flowchart illustrating the operation of a baffle server according to an embodiment of the present invention.

[0048] Figure 3 This is an interactive flowchart of a testing system suitable for low-code platforms disclosed in an embodiment of the present invention;

[0049] Figure 4 This is a flowchart of a testing method suitable for low-code platforms, as disclosed in an embodiment of the present invention. Detailed Implementation

[0050] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0051] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0052] First, the technical terms appearing in this application will be explained as follows:

[0053] Low-code platforms are development tools that allow businesses to quickly build applications with a visual interface and minimal (or no) code. Their core goal is to simplify the development process, lower the technical barrier to entry, and enable businesses to respond more efficiently to business needs.

[0054] Financial transaction process (i.e. transaction flow): A task flow that connects multiple transaction communication components to complete different financial transactions. As the main business logic in the low-code platform, it is the core development module of the low-code platform.

[0055] Software testing swatches are tools that use simulation or virtualization technology to simulate the operation of different components within a software system. They typically simulate components such as servers, databases, and interfaces to provide an independent and controlled environment for testing. By intercepting and simulating communication between system components, test swatches offer testers a controllable and monitorable environment, enabling them to perform tests more effectively.

[0056] As the background technology shows, in low-code platforms, a financial transaction task process typically involves multiple communication components. Each communication component is responsible for communicating with one or more third-party systems, thus involving dozens of third-party systems. Unified coordination and testing are very difficult. If the existing technology is used to abstract the service calls of third-party systems into standard call classes, and the standard call classes have corresponding simulation classes, the development workload for testing is large.

[0057] Therefore, this invention discloses a testing system and method suitable for low-code platforms. In this solution, by using a stencil server and address switching mechanism, the originally highly dispersed simulation testing that required individual testing of dozens of third-party systems is transformed into standardized testing that is centrally configured on a single platform, thereby reducing the workload of test development.

[0058] like Figure 1 The diagram shown is an architecture diagram of a testing system suitable for a low-code platform disclosed in an embodiment of the present invention. The testing system includes: a low-code platform 1, a transaction server 2, and a baffle server 3.

[0059] In this process, the transaction server 2 executes the transaction process pre-generated by the low-code platform 1, which includes sending transaction requests to one or more third-party systems.

[0060] Low-code platform 1 is used to configure test rules for each third-party system in the shield server 3; based on the user's shield activation operation, the actual addresses of each third-party system configured in low-code platform 1 are replaced with the test addresses corresponding to the shield server 3, and a first refresh command is sent to transaction server 2;

[0061] Transaction server 2 is used to refresh the actual addresses of various third-party systems pre-cached in transaction server 2 as test addresses when it receives the first refresh instruction; when it receives the test instruction input by the user, it treats each transaction request as a test request and sends each test request to the baffle server 3 based on the test address; and receives the test responses corresponding to each test request returned by the baffle server 3.

[0062] Baffle server 3 is used to return a corresponding test response to transaction server 2 for each test request, based on the test rules.

[0063] When the transaction server 2 receives the first refresh instruction, it will refresh the actual address of each third-party system that is pre-cached in the transaction server 2 according to the current address of each third-party system configured in the low-code platform 1 (at this time the corresponding address should be the test address).

[0064] It should be noted that the low-code platform 1 is a development platform that combines and connects various components and processes through drag-and-drop functionality to form a transaction process. A transaction process is generally composed of multiple communication components linked together in the low-code platform 1. Each communication component is responsible for communication with one or more third-party systems (i.e., responsible for message exchange between the transaction server 2 and the third-party systems), and each communication component is configured with the actual address of the corresponding third-party system.

[0065] Specifically, the process of configuring test rules in the shield server 3 for each third-party system includes:

[0066] Obtain the cluster IP and default response message corresponding to the transaction process; for each third-party system, obtain the corresponding target request message and target response message; in response to the user's configuration operation, configure the corresponding matching rules for the third-party system selected by the user; based on the cluster IP, default response message and each matching rule, configure test rules in the baffle server 3.

[0067] In one embodiment, the testing system further includes a database for storing test rules configured in the baffle server 3.

[0068] It should be noted that configuring test rules (i.e., barrier configuration) in barrier server 3 is divided into basic configuration and message configuration. The basic configuration is used to configure information such as the cluster IP, the transaction process for which the barrier functions, and the actual address of the third-party system. The message configuration includes the source message (i.e., the target request message), the destination message (i.e., the target response message), and the matching rules.

[0069] It is understandable that the test rules configured in the shield server 3 only apply to the transaction process executed in the transaction server 2 if the server IP of transaction server 2 matches the IP of the cluster to which it belongs. The matching rules specify the conditions for returning the target response message. Through conditional matching, when the test request message matches the matching rules, the corresponding target response message is returned. If there are no matching rules, a full match is performed by default, meaning a complete match between the test request message and the target request message.

[0070] Assume the target request message A is: <ap> <test1> test1< / test1> <test3> <test4> test4< / test4> < / test3> < / ap> By setting matching rules, it is specified that when a test request message contains the tags test1 and test4 (e.g., ...), ... <test1> test1< / test1> <test4> test4< / test4> If no matching rule is found, the test request message must match the target request message A before the corresponding target response message is returned.

[0071] Optionally, for each third-party system, the corresponding target request message and the corresponding target response message can be obtained from a preset test case library or historical messages.

[0072] The source and destination messages can be entered by the user or imported from the test case library. Simultaneously, the baffle server 3 automatically records historical messages from communication components during the transaction process using message replay technology. The recorded historical messages are precisely located using the component's runtime ID in the message configuration, and the source and destination messages are obtained by replaying the located historical messages. This enriches the test case data sources and saves testers time in writing test cases. Furthermore, recording historical messages based on message replay technology in the message configuration and automatically filling in templates to obtain source and destination messages improves the efficiency of test message generation.

[0073] The matching rules define the conditions for returning the target response message. Using conditional matching, when a test request message matches a matching rule, the corresponding target response message is returned. If no matching rules are specified, a full match is performed by default.

[0074] Please see Figure 2 This is a flowchart of the operation of a baffle server disclosed in an embodiment of the present invention.

[0075] Accordingly, the baffle server 3 is specifically used for:

[0076] For each test request, extract the server IP and test request message corresponding to transaction server 2 from the test request, and take the third-party system corresponding to the test request as the target system; when the server IP matches the IP of the cluster to which it belongs, determine whether the test request message matches the matching rule corresponding to the target system or the target request message corresponding to the target system. If so, return the target response message corresponding to the target system as the test response to transaction server 2; if not, return the default response message as the test response to transaction server 2.

[0077] As explained above, when configuring matching rules for user-selected third-party systems, some of these systems may not have corresponding matching rules. Therefore, this can be explained in two scenarios:

[0078] 1. The target system has corresponding matching rules.

[0079] In this case, if the test request message matches the matching rules of the target system, the target response message of the target system will be returned to the transaction server 2 as the test response; if the test request message does not match the matching rules of the target system, the default response message will be returned to the transaction server 2 as the test response.

[0080] 2. The target system does not have a corresponding matching rule.

[0081] In this case, it is determined whether the test request message fully matches the target request message corresponding to the target system. If so, the target response message corresponding to the target system is returned to transaction server 2 as the test response; otherwise, the default response message is returned to transaction server 2 as the test response.

[0082] It should be noted that after receiving the test response, transaction server 2 will continue to complete the remaining transaction process based on the test response. The test result is determined by observing whether the final execution status of the internal transaction process and the generated business data of transaction server 2 are consistent with expectations after receiving the test response returned by the barrier; at the same time, the correctness of the request and response matching logic is verified by monitoring the message records of the entire interaction process.

[0083] In one embodiment, the transaction server 2 is further configured to: after refreshing the actual addresses of the various third-party systems pre-cached in the transaction server 2 to test addresses, return a refresh completion instruction to the low-code platform 1.

[0084] Correspondingly, the low-code platform 1 is also used to: when a refresh completion instruction is received, replace the addresses of each third-party system configured in the low-code platform 1 with the test addresses and back to the actual addresses of each third-party system.

[0085] It should be noted that after the user performs the operation to enable the shield, the third-party system in the communication component of the low-code platform 1 transaction process is first replaced with the shield IP and Port (i.e. the address of the shield server 3, which is also the test address). After the transaction server 2 refreshes the cache, the low-code platform 1 writes back the original actual address and changes the shield status to the enabled state.

[0086] In one embodiment, when performing the barrier closure operation, the cache of transaction server 2 is first refreshed, that is, the addresses of various third-party systems cached by transaction server 2 are refreshed from the test addresses to the actual addresses of each third-party system, and then the barrier status is changed to closed. The specific implementation is as follows:

[0087] The low-code platform 1 is also used to: when the transaction server 2 receives the test response corresponding to each test request, send a second refresh instruction to the transaction server 2 according to the user's closing baffle operation.

[0088] Correspondingly, transaction server 2 is also used to: when receiving a second refresh instruction, refresh the addresses of each third-party system cached by transaction server 2 from the test addresses to the actual addresses of each third-party system.

[0089] In this embodiment of the invention, by using the immediate replacement and write-back method, the actual address of the third-party system cached by the transaction server 2 is replaced with the address of the baffle server 3. This avoids the impact on other related functions such as import and export caused by actual modifications to component configurations, and does not have a strong intrusive effect on the financial transaction system (transaction server 2) itself.

[0090] Based on the above embodiments of the present invention, a testing system suitable for low-code platforms is disclosed, such as... Figure 3 The diagram shown is an interaction flowchart of a testing system suitable for low-code platforms disclosed in an embodiment of the present invention. The specific interaction flow is as follows:

[0091] Users configure the shield through the low-code platform, obtain test rules and database test rules, and the low-code platform simultaneously synchronizes the test rules to the shield server. After the shield server successfully responds, it returns the saved results.

[0092] When a user performs the operation to enable the shield, the actual addresses of each of the third-party systems configured in the low-code platform are first replaced with the test address corresponding to the shield server, and a refresh command is sent to the transaction server to make it effective on the transaction server. After it takes effect, the low-code platform immediately writes back the actual address.

[0093] After a user initiates a test, the transaction request that was originally sent by the transaction server to the third-party system will be used as a test request and redirected to the block server according to the test address in the transaction server's cache. The block server receives the test request sent by the transaction server, performs rule matching, and returns the corresponding response message to the transaction server according to the matching result to complete the entire transaction process.

[0094] When a user closes the barrier, the cache in the transaction server is refreshed, and the barrier server address in the cache is refreshed to the actual address of each third-party system.

[0095] Based on the above-described embodiments of the present invention, a testing system suitable for low-code platforms is disclosed. In this solution, through a stencil server and address switching mechanism, the originally highly dispersed simulation testing that required individual testing of dozens of third-party systems is transformed into standardized testing that is centrally configured on a single platform, thereby achieving the goal of reducing the workload of test development.

[0096] like Figure 4 The diagram shows a flowchart of a testing method suitable for low-code platforms disclosed in an embodiment of the present invention. This method is applied to any of the low-code platform testing systems disclosed in the above embodiments of the present invention, and includes the following steps:

[0097] Step S401: Utilize a low-code platform to configure test rules in the shield server for each third-party system.

[0098] Step S402: Using the low-code platform, based on the user's opening of the shield, replace the actual addresses of each third-party system configured in the low-code platform with the test address corresponding to the shield server, and send the first refresh command to the transaction server.

[0099] Step S403: When the trading server receives the first refresh instruction, it refreshes the actual addresses of the various third-party systems that are pre-cached in the trading server to the test addresses.

[0100] Step S404: When the transaction server receives the test command input by the user, it treats each transaction request as a test request and sends each test request to the baffle server based on the test address.

[0101] Step S405: For each test request, the baffle server returns the corresponding test response to the transaction server based on the test rules.

[0102] Step S406: The transaction server receives the test responses corresponding to each test request returned by the baffle server.

[0103] In the specific implementation of step S401, the low-code platform is used to obtain the cluster IP and default response message corresponding to the transaction process; for each third-party system, the corresponding target request message and target response message are obtained; in response to the user's configuration operation, the corresponding matching rules are configured for the third-party system selected by the user; based on the cluster IP, default response message and each matching rule, test rules are configured in the baffle server.

[0104] Based on the specific implementation process of step S401, the specific implementation process of step S405 is as follows:

[0105] For each test request, the server IP corresponding to the transaction server and the test request message are extracted from the test request, and the third-party system corresponding to the test request is taken as the target system. When the server IP matches the IP of the cluster to which it belongs, it is determined whether the test request message matches the matching rule corresponding to the target system or the target request message corresponding to the target system. If so, the target response message corresponding to the target system is returned to the transaction server as the test response; otherwise, the default response message is returned to the transaction server as the test response.

[0106] Optionally, for each third-party system, the corresponding target request message and the corresponding target response message can be obtained from a preset test case library or historical messages.

[0107] In one embodiment, after refreshing the actual addresses of each third-party system pre-cached in the transaction server to test addresses, the transaction server returns a refresh completion instruction to the low-code platform. When the low-code platform receives the refresh completion instruction, it replaces the addresses of each third-party system configured in the low-code platform with the actual addresses of each third-party system from the test addresses.

[0108] In one embodiment, when the transaction server receives the test response corresponding to each test request, the low-code platform sends a second refresh instruction to the transaction server based on the user's closing baffle operation; when the transaction server receives the second refresh instruction, it refreshes the addresses of each third-party system cached by the transaction server from the test addresses to the actual addresses of each third-party system.

[0109] Based on the above-described embodiment of the present invention, a testing method applicable to low-code platforms is disclosed. In this solution, by using a stencil server and address switching mechanism, the originally highly dispersed simulation testing that required individual testing of dozens of third-party systems is transformed into a standardized test that is centrally configured on a single platform, thereby achieving the goal of reducing the workload of test development.

[0110] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0111] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0112] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A testing system suitable for low-code platforms, characterized in that, The system includes: a low-code platform, a transaction server, and a baffle server; the transaction server executes a transaction process pre-generated by the low-code platform, the transaction process including sending transaction requests to one or more third-party systems; The low-code platform is used to configure test rules in the shield server for each of the third-party systems; based on the user's shield activation operation, the actual addresses of each of the third-party systems configured in the low-code platform are replaced with the test addresses corresponding to the shield server, and a first refresh command is sent to the transaction server; The transaction server is configured to, upon receiving the first refresh instruction, refresh the actual addresses of each of the third-party systems pre-cached in the transaction server to the test address; upon receiving a test instruction input by the user, treat each of the transaction requests as test requests and send each of the test requests to the baffle server based on the test address; and receive test responses corresponding to each of the test requests returned by the baffle server. The baffle server is configured to return a corresponding test response to the transaction server for each test request, based on the test rules.

2. The system according to claim 1, characterized in that, The low-code platform is specifically used for: Obtain the cluster IP and default response message corresponding to the transaction process; for each third-party system, obtain the corresponding target request message and target response message; in response to the user's configuration operation, configure the corresponding matching rules for the third-party system selected by the user; based on the cluster IP, the default response message and each matching rule, configure test rules in the baffle server; Accordingly, the baffle server is specifically used for: For each test request, the server IP and test request message corresponding to the transaction server are extracted from the test request, and the third-party system corresponding to the test request is used as the target system; When the server IP matches the IP of the cluster to which it belongs, determine whether the test request message matches the matching rule corresponding to the target system or the target request message corresponding to the target system. If so, return the target response message corresponding to the target system as a test response to the transaction server. If not, the default response message will be returned to the transaction server as a test response.

3. The system according to claim 1, characterized in that, The low-code platform is specifically used for: For each of the aforementioned third-party systems, the corresponding target request message and the corresponding target response message are obtained from a preset test case library or historical messages.

4. The system according to claim 1, characterized in that, The transaction server is also used for: After refreshing the actual addresses of the various third-party systems pre-cached on the transaction server to the test addresses, a refresh completion instruction is returned to the low-code platform. Accordingly, the low-code platform is also used for: When the refresh completion instruction is received, the addresses of each of the third-party systems configured in the low-code platform are replaced with the test addresses back to the actual addresses of each of the third-party systems.

5. The system according to claim 1, characterized in that, The low-code platform is also used for: When the transaction server receives the test response corresponding to each test request, it sends a second refresh command to the transaction server according to the user's closing baffle operation; Accordingly, the transaction server is also used for: When the second refresh instruction is received, the addresses of each third-party system cached by the transaction server are refreshed from the test addresses to the actual addresses of each third-party system.

6. A testing method suitable for low-code platforms, characterized in that, The method, applied to the testing system according to any one of claims 1 to 5, comprises: Utilize a low-code platform to configure test rules in the shield server for each third-party system; Based on the user's opening of the baffle, the low-code platform replaces the actual addresses of each third-party system configured in the low-code platform with the test address corresponding to the baffle server, and sends a first refresh command to the transaction server. When the transaction server receives the first refresh instruction, it refreshes the actual addresses of each of the third-party systems that are pre-cached in the transaction server to the test address; When the transaction server receives a test instruction input by the user, it treats each transaction request as a test request and sends each test request to the baffle server based on the test address. For each test request, the baffle server returns a corresponding test response to the transaction server based on the test rules. The transaction server receives test responses corresponding to each test request returned by the baffle server.

7. The method according to claim 6, characterized in that, The low-code platform, which utilizes a low-code platform to configure test rules in the baffle server for each of the aforementioned third-party systems, includes: The system utilizes a low-code platform to obtain the cluster IP and default response message corresponding to the transaction process; for each third-party system, it obtains the corresponding target request message and target response message; in response to the user's configuration operation, it configures the corresponding matching rules for the third-party system selected by the user; and based on the cluster IP, the default response message, and each matching rule, it configures test rules in the baffle server. Accordingly, the step of using the baffle server to return a corresponding test response to the transaction server for each test request based on the test rules includes: For each test request, the server IP and test request message corresponding to the transaction server are extracted from the test request, and the third-party system corresponding to the test request is taken as the target system. When the server IP matches the IP of the cluster to which it belongs, it is determined whether the test request message matches the matching rule corresponding to the target system or the target request message corresponding to the target system. If so, the target response message corresponding to the target system is returned to the transaction server as a test response. If not, the default response message is returned to the transaction server as a test response.

8. The method according to claim 7, characterized in that, For each of the aforementioned third-party systems, obtaining the corresponding target request message and the corresponding target response message includes: For each of the aforementioned third-party systems, the corresponding target request message and the corresponding target response message are obtained from a preset test case library or historical messages.

9. The method according to claim 6, characterized in that, The method further includes: After refreshing the actual addresses of the various third-party systems pre-cached in the transaction server to the test addresses, the transaction server returns a refresh completion instruction to the low-code platform. When the low-code platform receives the refresh completion instruction, it replaces the addresses of each third-party system configured in the low-code platform with the test addresses back to the actual addresses of each third-party system.

10. The method according to claim 6, characterized in that, The method further includes: When the transaction server receives the test response corresponding to each test request, the low-code platform sends a second refresh instruction to the transaction server according to the user's closing baffle operation; When the transaction server receives the second refresh instruction, it refreshes the addresses of each third-party system cached by the transaction server from the test addresses to the actual addresses of each third-party system.

Images