Low-code test system and test method for financial services

Abstract

This application provides a low-code testing system for financial business, applicable to the fields of software testing technology and fintech. The method includes: a business modeling module configured to store a library of financial business-specific components, responsive to drag-and-drop and connection operations on a visual canvas to orchestrate business processes and configure business rules through a graphical interface; a heterogeneous system adaptation module configured to identify the type of the financial system under test and call the corresponding adaptation driver to establish a communication connection with the system; a security and compliance testing module configured to perform data encryption transmission verification, data anonymization verification, access control verification, and financial compliance rule comparison during testing; and an execution analysis module configured to schedule test case execution, record test process data, analyze test failure reasons, and generate a visual test report.

Description

Technical Field

[0001] This application relates to the field of software testing technology, specifically to the field of financial technology, and more specifically to a low-code testing system and testing method for financial business. Background Technology

[0002] As financial business systems become increasingly complex and iterate at an ever-accelerating pace, automated testing has become a crucial means of ensuring software quality. However, among related technologies, test script writing is challenging. Testers are required to write extensive amounts of code in general-purpose programming languages ​​to describe business processes and verification logic, demanding high programming skills and resulting in long test case development cycles and high labor costs. Furthermore, communication protocols and interface specifications differ significantly between different financial systems. Bank core systems, securities trading systems, and mobile financial applications typically employ their own proprietary message formats and interaction methods. Testing tools struggle to quickly adapt to these heterogeneous systems, necessitating the development of separate adaptation code for each system, further complicating test environment setup. Summary of the Invention

[0003] In view of the above problems, embodiments of this application provide a low-code testing system and method for financial business.

[0004] According to a first aspect of this application, a low-code testing system for financial business is provided, comprising: a business modeling module configured to store a library of financial business-specific components, responsive to drag-and-drop and connection operations on a visual canvas for the financial business-specific components, orchestrating business processes, and configuring business rules through a graphical interface; a heterogeneous system adaptation module configured to identify the type of the financial system under test and call the corresponding adaptation driver to establish a communication connection with the financial system under test; a security and compliance testing module configured to perform data encryption transmission verification, data desensitization verification, access control verification, and financial compliance rule comparison during the testing process; and an execution analysis module configured to schedule test case execution, record test process data, analyze test failure reasons, and generate a visual test report.

[0005] According to an embodiment of this application, the business modeling module includes: a component library configured to store banking, securities, and insurance components; wherein the banking components include account opening, fund transfer, and credit approval components; the securities components include stock trading and fund subscription / redemption components; and the insurance components include policy application and claims application components; a process orchestration unit configured to display a visual canvas and orchestrate business processes in response to user drag-and-drop and connection operations, as well as set data transfer rules and business logic judgment conditions between components; and a rule configuration unit configured to display a graphical rule configuration interface and configure financial business rules in response to user-input conditional expressions and formula calculations.

[0006] According to an embodiment of this application, the heterogeneous system adaptation module includes: a type identification unit, configured to identify the type of the financial system under test based on at least one of the communication protocol characteristics, interface specification characteristics, and interface characteristics of the financial system under test; an adaptation driver unit, configured to call the corresponding adaptation driver for different financial system types; the adaptation driver includes at least one of a middleware interface adapter for a bank core system, a secure keyboard adapter for a mobile financial application, and a financial information exchange protocol adapter for a securities trading system; and an environment management unit, configured to switch between a development environment, a testing environment, and a production pre-release environment in response to an environment switching command, and automatically update the corresponding network configuration and interface address.

[0007] According to an embodiment of this application, the type identification unit is further configured to: acquire network communication messages of the financial system under test; extract the protocol identifier field from the network communication message; match the protocol identifier field with protocol features in the financial industry standard protocol feature library, the financial industry standard protocol feature library including SWIFT protocol features and financial information exchange protocol features; and determine the type of the financial system under test based on the matched protocol features.

[0008] According to an embodiment of this application, the type identification unit is further configured to: in the event of a matching failure, obtain the interface definition file and interface source code of the financial system under test; parse the interface definition file and the interface source code to extract data interface specifications, interface element types and layout features; compare the parsing results with the features in the financial system sample library with labeled types, and determine the type with the highest similarity as the identification result.

[0009] According to an embodiment of this application, the security compliance testing module includes: an encryption verification component configured to verify that financial data conforms to standard encryption algorithms during transmission; a desensitization verification component configured to check that sensitive data is desensitized according to preset rules; an access control component configured to simulate user operations and verify that the system access control allocation conforms to the principle of least privilege; and a compliance rule library configured to store financial compliance rules and automatically compare business operations with the financial compliance rules during testing.

[0010] According to an embodiment of this application, the execution analysis module includes: a task scheduling unit configured to schedule test tasks according to the execution mode, priority, and dependencies of test cases and system resources; a defect analysis unit configured to analyze test failure results using natural language processing and machine learning algorithms and generate defect reports; and a report generation unit configured to generate test reports based on test execution results.

[0011] According to a second aspect of this application, a low-code testing method for financial business is provided, comprising: generating test cases in response to visual orchestration and business rule configuration operations of components; identifying the type of the financial system under test and calling the corresponding adapter driver to establish a communication connection with the financial system under test; scheduling the execution of the test cases according to the execution mode, priority, dependency relationship and system resources of the test cases; and analyzing the test results of the test cases to generate a visual test report.

[0012] According to an embodiment of this application, generating test cases in response to the visual orchestration and business rule configuration operations of components includes: determining a target component in response to a component selection instruction; orchestrating a business process in response to drag and connect instructions for the target component; and configuring business rules through a graphical interface in response to a business rule configuration instruction to generate test cases.

[0013] According to an embodiment of this application, identifying the type of the financial system under test and invoking the corresponding adapter driver to establish a communication connection with the financial system under test includes: identifying the type of the financial system under test based on at least one of the communication protocol characteristics, interface specification characteristics, and interface characteristics of the financial system under test; and invoking the corresponding adapter driver according to the type of the financial system under test to establish a communication connection with the financial system under test; wherein the adapter driver includes at least one of a middleware interface adapter for a bank core system, a secure keyboard adapter for a mobile financial application, and a financial information exchange protocol adapter for a securities trading system.

[0014] According to a third aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0016] According to a fifth aspect of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0017] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1 The illustration shows an application scenario diagram of a low-code testing method for financial business according to an embodiment of this application.

[0019] Figure 2 The diagram illustrates a system architecture of a low-code testing system for financial business according to an embodiment of this application.

[0020] Figure 3 The diagram illustrates the interface of the low-code platform in its operational and display states according to embodiments of this application.

[0021] Figure 4 A schematic diagram of the user interface of a low-code platform according to an embodiment of this application is shown.

[0022] Figure 5 A flowchart illustrating a low-code testing method for financial transactions according to an embodiment of this application is shown.

[0023] Figure 6 A block diagram of an electronic device suitable for implementing a transaction risk identification method according to an embodiment of this application is shown schematically. Detailed Implementation

[0024] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0025] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0027] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0028] Figure 1 The diagram illustrates an application scenario of a low-code testing method for financial transactions according to an embodiment of this application. Figure 1 As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, a user can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 through the network 104 to receive or send information, etc.

[0029] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be electronic devices such as smartphones, wearable devices, personal computers, intelligent voice interaction devices, smart home appliances, intelligent vehicles, in-vehicle terminals, aircraft, unmanned vending terminals, and extended reality devices. Extended reality devices can include virtual reality devices, augmented reality devices, and mixed reality devices. A client application for the target application can be installed and run on the terminal devices. This target application can include, but is not limited to, financial transaction applications, payment applications, shopping applications, web browser applications, search applications, instant messaging tools, email clients, and social media platform software (these are just examples). Furthermore, this application embodiment does not limit the form of the target application, and it can include, but is not limited to, applications, mini-programs, etc., installed on the terminal devices, and can also be in the form of web pages.

[0030] Server 105 can be a server providing various services, such as a backend management server supporting websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process received user requests and other data, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and basic cloud computing services such as big data. The server can be the backend server of the aforementioned target application, used to provide backend services to the clients of the target application.

[0031] It should be noted that the low-code testing method for financial business provided in this application embodiment can generally be executed by server 105 and / or terminal devices 101-103. Accordingly, the low-code testing system for financial business provided in this application embodiment can generally be set up in server 105 and / or terminal devices 101-103.

[0032] It should be noted that the low-code testing method for financial business provided in this application embodiment can be used in the field of software testing technology, as well as in the field of fintech, and can also be used in any field other than fintech. The application field of the low-code testing method for financial business provided in this application embodiment is not limited.

[0033] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0034] Figure 2 This diagram schematically illustrates a system architecture diagram of a low-code testing system for financial transactions according to an embodiment of this application. Figure 2 As shown, the low-code testing system provided in this application embodiment may include a business modeling module 210, a heterogeneous system adaptation module 220, a security and compliance testing module 230, and an execution analysis module 240.

[0035] According to an embodiment of this application, the business modeling module 210 is configured to store a library of financial business-specific components, and in response to drag-and-drop and connection operations of the financial business-specific components on a visualization canvas, to orchestrate business processes and configure business rules through a graphical interface.

[0036] In one example, during the testing of a commercial bank's online banking system, testers needed to verify the "interbank transfer" service. Testers opened the front-end interface of the low-code testing system. The business modeling module had pre-loaded a financial business-specific component library containing components such as "login," "transfer and remittance," and "account inquiry." Testers dragged the "login component" onto the visual canvas, entered their test account and password, then dragged the "transfer and remittance component," setting the transfer amount, receiving account, and fee calculation rules (e.g., no fee for amounts less than 50,000 yuan, 0.1% for amounts greater than 50,000 yuan). Finally, they dragged the "account inquiry component" to verify the balance change after the transfer. The three components were connected by a link, and a conditional branch was set on the transfer component: if the transfer was successful, the query was executed; if it failed, the process ended. After configuration, the system automatically generated an executable JSON test case.

[0037] Figure 3 The diagram illustrates the interface of the low-code platform in operation and display states according to embodiments of this application. Figure 4 A schematic diagram of the user interface of a low-code platform according to an embodiment of this application is shown.

[0038] Figure 3 The complete flow of the interface response when a user drags and drops a component is described in the form of a state transition diagram. For example... Figure 3 As shown, the low-code testing platform of this application embodiment has two interactive states during the test case design process: operation state and presentation state.

[0039] In the operation mode, users orchestrate business processes by dragging and dropping components, resizing them, and connecting nodes. The operation mode comprises three sub-phases: Drag Start, triggered when the user selects a component in the component library by pressing the left mouse button. At this time, the system performs the following operations: hides existing auxiliary elements on the current canvas (such as temporarily displayed points, color blocks, and dashed borders) to keep the interface clean; records the coordinates of the drag start point and prepares to generate visual feedback elements during the drag process; and Drag Move, continuously responding to drag move events as the user holds down the left mouse button. During this phase: the position or size of the color block changes in real time: the dragged component moves with the mouse pointer as a semi-transparent color block, and the position or size of the color block (if resizing is performed by dragging) is updated in real time. The position or size of the dashed border changes in real time and is positioned to a nearby point: the system displays a dashed border on the canvas to indicate the placeholder area after the component is released. The position and size of the dashed outline also follow the mouse movement in real time and automatically snaps to the grid intersections or edges of nearby components on the canvas (i.e., "locating to nearby points") to help users align precisely. Continuous dragging: The above feedback continues until the user releases the mouse. Drag end: The user releases the left mouse button, completing the drag operation. At this point, the system performs cleanup and final rendering: Hide canvas: Clears the canvas layer temporarily drawn during dragging (e.g., canvas elements used to display dynamic trajectories). Hide points: Hides auxiliary positioning points displayed during dragging (e.g., grid vertex markers). Hide color blocks: Removes semi-transparent color blocks that follow the mouse. Hide dashed outline: Clears the placeholder dashed outline. Redraw component: Officially draws the complete graphic of the component (including icons, ports, and text labels) at the final release position and updates the internal data structure. At this point, the component has been successfully added to the business process.

[0040] In presentation mode, the platform no longer responds to user editing but instead displays the pre-designed test process and its execution results. Presentation mode also includes several stages: **Display Components:** The complete business process, including all components and their connections, is displayed in read-only mode on the canvas. Components are presented in their final form (with icons, ports, and labels) and cannot be dragged or edited. **Start Operation:** After the user clicks the "Execute" button, the platform begins running the test cases. At this time, each component node in the process dynamically displays its execution status (e.g., highlighting the current execution node and displaying a progress circle). **Final Display:** After execution, the platform displays the final results on the interface, including pass / fail markers for each component, an overall test report (charts, log summaries), and a compliance score. Users can switch to operation mode to modify the process or export the report.

[0041] Figure 3The above states are connected by arrows: the operation state forms a closed loop of drag start → drag move → drag end; the display state is independent of the operation state, and users can switch between the two states through the toolbar button (the switch is indicated by a double-headed dashed arrow in the figure).

[0042] Because the operation mode provides real-time visual feedback such as color block following and dashed frame snapping alignment, users can accurately perceive the landing point of components when dragging them, reducing the error rate and improving the efficiency and accuracy of workflow orchestration. The automatic cleanup and redraw mechanism after dragging ensures the stability of the interface state. The read-only display in the presentation mode and the highlighting of the execution state make the testing process transparent and facilitate problem localization.

[0043] Reference Figure 4 Users drag and drop components from the left-hand component library to the central canvas, set the execution order by connecting them, and configure business rules in the right-hand panel to quickly generate test cases. For example... Figure 4 The front-end interface shown includes a left-side component library panel, a central visualization canvas, a right-side attribute / rule configuration panel, and a top toolbar. The left-side component library panel displays a dedicated library of financial business components in a tree or icon list format. Components are grouped by domain; for example, "Banking Components" includes "Login Component," "Fund Transfer Component," "Account Opening Component," and "Credit Approval Component"; "Securities Components" includes "Stock Trading Component" and "Fund Subscription and Redemption Component"; and "Insurance Components" includes "Policy Application Component" and "Claims Application Component." Each component displays a small icon and name, and can be dragged and dropped.

[0044] The central visualization canvas is an editable area with a grid background used for orchestrating business processes. The canvas supports zooming, panning, undoing, and redoing. The diagram illustrates three components placed on the canvas: the "Login Component" (top left), the "Fund Transfer Component" (center), and the "Fund Transfer Result Query Component" (bottom right). Components are connected by arrowed lines, with the arrow direction indicating the execution order. Conditional branches can be set on each connection (e.g., displaying "if transfer successful then execute query else end" on the connection). Users can access property settings by double-clicking a component or using the right-click menu.

[0045] Right-side configuration panel: When a user selects a component (as shown in the image, the "Transfer & Remittance Component" is selected) or connects a line, the right-side panel dynamically displays the corresponding configuration options. The right-side panel in the image shows the "Transfer Rules Configuration" tab, which includes: "Handling Fee Calculation Rules": A dropdown menu allows selection of "Percentage of Amount" or "Fixed Fee," with an input value of 0.1% and the condition "No handling fee for amounts < 50,000." "Transfer Limit": The input box displays "Single Transaction Limit 50,000 Yuan." "Receiving Account Type": A radio button selects "Same Bank / Interbank." At the bottom are "Save Rules" and "Test Run" buttons.

[0046] Top toolbar: Includes buttons such as "Create New Process", "Open", "Save", "Execute All", "Environment Switch (Development / Test / Pre-Release)", and "Generate Report".

[0047] According to an embodiment of this application, the heterogeneous system adaptation module 220 is configured to identify the type of the financial system under test and call the corresponding adaptation driver to establish a communication connection with the financial system under test.

[0048] In one example, after the test cases are prepared, they need to be executed against the actual system under test. The system under test could be a bank's core system (based on CICS middleware), an online banking front-end (based on HTTP), or a mobile banking app (based on HTTPS + Chinese cryptographic standards). The heterogeneous system adaptation module automatically sends probe packets, captures the protocol headers in the network response, and identifies the system as an "online banking system" (HTTP / 1.1, Server: BankWeb). Subsequently, the module calls the pre-configured "Web adaptation driver," which automatically handles session cookies, SSL certificates, and bank-specific secure keyboard input. After establishing a connection, the module also automatically updates the IP address, port, and database connection string in the test environment to the values ​​of the current environment.

[0049] According to an embodiment of this application, the security compliance testing module 230 is configured to perform data encryption transmission verification, data desensitization verification, access control verification, and financial compliance rule comparison during the testing process.

[0050] In one example, during the execution of a transfer test case, the security and compliance testing module intervened simultaneously. The encryption verification component captured the HTTP request body and verified whether the bank card number field was encrypted using the SM4 algorithm (comparing the ciphertext length and format). The de-identification verification component checked console logs and database records to ensure that the ID number was displayed as "320*************34" instead of plaintext. The authorization verification component attempted to initiate transfers exceeding 1 million yuan using both "ordinary teller" and "supervisor" accounts, verifying that only the supervisor's account could proceed. The compliance rule base includes the "Management Measures for Reporting Large and Suspicious Transactions by Financial Institutions," which automatically triggers an alert and records it in the compliance audit log when the transfer amount exceeds 50,000 yuan.

[0051] According to an embodiment of this application, the execution analysis module 240 is configured to schedule test case execution, record test process data, analyze test failure reasons, and generate a visual test report.

[0052] In one example, the execution analysis module receives a queue of test cases. There are currently 100 test cases, of which 20 are high-priority (involving core transfers), 30 are medium-priority, and 50 are low-priority. The "Login" test case is a dependency of all subsequent test cases. The task scheduling unit prioritizes executing high-priority test cases, and after successful login, executes up to 8 independent test cases in parallel, based on the number of idle CPU cores (8 cores). During execution, the module records the request / response messages, response time, and error codes for each step. When the "Transfer" test case fails, the defect analysis unit captures the error log "ERROR -java.net.SocketTimeoutException: Read timed out," extracts the keyword "SocketTimeout" through natural language processing, associates it with the "Network Adaptation" component, determines that the backend service response timed out, and generates a defect report: "Bank core system interface response exceeds 5 seconds; it is recommended to check network connectivity or increase the timeout period." The report generation unit summarizes all results and generates an HTML visual report that includes the pass rate (85%), defect distribution (5 functional defects, 2 security defects, and 1 performance defect), and compliance score (98 points).

[0053] Because the business modeling module uses visual drag-and-drop and connection methods, testers can complete the modeling of complex financial processes without writing code, improving test case development efficiency. Since the heterogeneous system adaptation module automatically identifies and calls dedicated drivers, there is no need to manually configure communication protocols, shortening test environment setup time. Because the security and compliance testing module automatically performs encryption, de-identification, permission, and compliance rule verification during testing, it can detect data leaks and violations in advance, reducing compliance risks.

[0054] According to an embodiment of this application, the business modeling module includes: a component library configured to store banking, securities, and insurance components; wherein the banking components include account opening, fund transfer, and credit approval components; the securities components include stock trading and fund subscription / redemption components; and the insurance components include policy application and claims application components; a process orchestration unit configured to display a visual canvas and orchestrate business processes in response to user drag-and-drop and connection operations, as well as set data transfer rules and business logic judgment conditions between components; and a rule configuration unit configured to display a graphical rule configuration interface and configure financial business rules in response to user-input conditional expressions and formula calculations.

[0055] In one example, the component library in the business modeling module is divided into three major areas: banking, securities, and insurance. Each area contains multiple standard components: Banking: Account opening component (supports personal / corporate accounts, configurable list of required documents), transfer component (supports intra-bank / inter-bank transactions, configurable fee rates and arrival time), credit approval component (simulates credit scoring models, manual approval processes, and loan confirmation). Securities: Stock trading component (supports simulated buy / sell orders, order cancellation, and transaction feedback), fund subscription / redemption component (supports T+0 / T+1 confirmation, configurable subscription fee rates). Insurance: Policy application component (supports inputting insured information, selecting insurance types, and calculating premiums), claims application component (supports uploading claims materials and simulating the review process). The workflow orchestration unit provides a Visio-like visual canvas. Users can drag and drop components, double-click to set attributes (such as transfer amount range), and add conditional judgments on connections (e.g., "if credit score < 600 then transfer to manual approval"). The rule configuration unit displays a list of rules in tabular form. For example, an anti-money laundering rule can be defined as: "Single transfer amount > 50,000 yuan → Trigger a large transaction report". Users can also use the formula editor, such as "Monthly payment = Loan amount * Monthly interest rate / (1 - (1 + Monthly interest rate)^(-Number of periods))".

[0056] Because the component library covers the three core financial sectors of banking, securities, and insurance, and each component has built-in industry-standard logic, testers can quickly assemble complex business scenarios across products like building blocks, improving component reusability. The process orchestration unit supports conditional branching and data transfer, enabling test cases to cover normal processes, abnormal processes, and boundary conditions, thus improving test coverage. The rule configuration unit supports expressions and formulas, allowing business personnel to modify rates, compliance thresholds, etc., without development intervention, reducing test response time after rule changes from days to hours.

[0057] According to an embodiment of this application, the heterogeneous system adaptation module includes: a type identification unit, configured to identify the type of the financial system under test based on at least one of the communication protocol characteristics, interface specification characteristics, and interface characteristics of the financial system under test; an adaptation driver unit, configured to call the corresponding adaptation driver for different financial system types; the adaptation driver includes at least one of a middleware interface adapter for a bank core system, a secure keyboard adapter for a mobile financial application, and a financial information exchange protocol adapter for a securities trading system; and an environment management unit, configured to switch between a development environment, a testing environment, and a production pre-release environment in response to an environment switching command, and automatically update the corresponding network configuration and interface address.

[0058] In one example, the heterogeneous system adaptation module contains three units:

[0059] Type identification unit: Sends a probe request to the system under test. If the returned message header contains "FIX.4.4", it is determined to be a securities trading system; if the message is in XML format and the root node is... <bankcore>If the page source code contains "online banking login" and a JavaScript encryption function, it is determined to be a bank's core system; if the page source code contains "online banking login" and a JavaScript encryption function, it is determined to be an online banking system.

[0060] Adaptor driver unit: For the core banking system, a middleware interface adapter is loaded to automatically encapsulate requests into fixed-length messages; for mobile financial apps, a secure keyboard adapter is loaded, which can simulate the encryption and decryption process of the national cryptographic standard SM2 / SM4; for securities trading systems, a FIX protocol adapter is loaded, which can automatically generate standard messages such as login (35=A), new order (35=D), and order cancellation (35=F).

[0061] Environment Management Unit: When testers select "Switch to Production Pre-Release Environment" on the interface, the module immediately modifies the database URL in the configuration file, and simultaneously updates the remote dictionary service address, message middleware address, and external interface API Key. After the environment switch, a smoke test is automatically executed to ensure normal connection.

[0062] According to an embodiment of this application, the type identification unit is further configured to: acquire network communication messages of the financial system under test; extract the protocol identifier field from the network communication message; match the protocol identifier field with protocol features in the financial industry standard protocol feature library, the financial industry standard protocol feature library including SWIFT protocol features and financial information exchange protocol features; and determine the type of the financial system under test based on the matched protocol features.

[0063] In one example, the type identification unit initiates the identification process. First, a HEALTH_CHECK request is sent to the default port of the system under test (e.g., port 5000 is typically used by core banking systems). The returned network communication message is captured, and the protocol identifier field in the first 128 bytes is extracted. If the strings "SWIFT", "MT103", or "{1:F01" are detected, it matches the Society for Worldwide Interbank Financial Telecommunication (SWIFT) protocol feature in the financial industry standard protocol feature library, identifying it as an international settlement system. If "FIX", "35=A", or "8=FIX.4.4" are detected, it matches as a securities trading system. If "HTTP / 1.1" is detected and the return body contains the word "bank", it matches as an online banking system. After a successful match, the system type is directly determined, and the identification log is recorded.

[0064] Because it uses a pre-built financial industry standard protocol feature library, the matching process eliminates the need for manual analysis of message formats, thus improving the speed of system type identification. Protocol feature matching is deterministic, avoiding probabilistic misjudgments that may occur with machine learning models, making it particularly suitable for financial compliance testing scenarios with extremely high accuracy requirements. Furthermore, this feature library can be expanded with the introduction of new protocols, exhibiting good maintainability.

[0065] According to an embodiment of this application, the type identification unit is further configured to: in the event of a matching failure, obtain the interface definition file and interface source code of the financial system under test; parse the interface definition file and the interface source code to extract data interface specifications, interface element types and layout features; compare the parsing results with the features in the financial system sample library with labeled types, and determine the type with the highest similarity as the identification result.

[0066] In one example, when the protocol feature library fails to match (e.g., encountering a bank's self-developed proprietary binary protocol), the type recognition unit automatically switches to an alternative recognition method. First, the interface definition file of the system under test is obtained, and its paths, parameter names, and response structures are parsed. If a WSDL is provided, the service name and operation name are extracted. Simultaneously, the system's front-end interface source code is captured using a headless browser, extracting key features: such as whether the login box contains the words "Corporate Online Banking," whether the page contains a "Direct Bank-Enterprise Connection" button, and whether the input box's ID contains keywords like "cardNo" and "amount." Then, these parsed results are compared with a sample library of labeled financial systems (containing over 5000 labeled historical system feature vectors) using similarity calculations (e.g., cosine similarity). The type with the highest similarity is selected as the recognition result; for example, a similarity of 0.92 is determined to be "Corporate Online Banking System."

[0067] By combining interface specification features and user interface characteristics, the system type can be accurately identified even when the protocol is completely unknown or proprietary, thus ensuring the adaptable module's universality covers all financial system types. Based on similarity comparisons using a large-scale sample library, the identification accuracy can still be maintained above 95%, and the sample library can be continuously optimized through machine learning, making the system more accurate with use.

[0068] According to an embodiment of this application, the security compliance testing module includes: an encryption verification component configured to verify that financial data conforms to standard encryption algorithms during transmission; a desensitization verification component configured to check that sensitive data is desensitized according to preset rules; an access control component configured to simulate user operations and verify that the system access control allocation conforms to the principle of least privilege; and a compliance rule library configured to store financial compliance rules and automatically compare business operations with the financial compliance rules during testing.

[0069] In one example, the security compliance testing module contains four components:

[0070] Encryption verification component: Intercepts all outgoing requests and checks whether sensitive fields (such as bank card numbers, ID card numbers, and transaction passwords) use encryption algorithms that comply with relevant standards (AES-256 or SM4). For example, for login requests, the ciphertext length of the verification password field after SM4 encryption is 32 bytes, and the key is a preset national cryptographic key.

[0071] The data masking and verification component captures console output, log files, and database records during test case execution. It uses regular expressions to match ID card numbers (18 digits or X) and bank card numbers (16-19 digits). It checks whether this sensitive information has been replaced with masking symbols such as "*" or "X". For example, an ID card number displayed as "11010110101010101X" should be masked to "110101***********X".

[0072] The permission verification component simulates different user roles (such as tellers, supervisors, and auditors) performing the same operation. For example, a teller attempting to query all customers' account balances should be rejected; a supervisor can query customers within their own branch but not those of other branches; an auditor can query all accounts but cannot modify them. The system verifies whether the permission allocation complies with the principle of least privilege.

[0073] Compliance rule library: Stores rules such as the "Regulations on Anti-Money Laundering by Financial Institutions," the "Specifications for the Protection of Personal Financial Information," and the "General Specifications for Information Security of Online Banking Systems." During transfer testing, if the transfer amount exceeds 50,000 yuan, the "Large Transaction Report" rule is automatically triggered to check whether the system has recorded and reported it; if the system attempts to obtain the customer's facial recognition information, it checks whether there is a separate authorization consent form, otherwise a "Excessive Collection of Personal Information" warning is triggered.

[0074] Encryption verification automatically validates the algorithm's compliance, avoiding the risk of data leakage due to weak encryption. Data masking ensures that sensitive data is not accidentally leaked to logs or the console during testing, complying with the Personal Information Protection Law. Permission verification, based on the principle of least privilege, can detect unauthorized access and prevent unauthorized operations by internal personnel. Dynamic comparison with a compliance rule base helps financial institutions identify potential regulatory violations during the testing phase, reducing the risk of penalties.

[0075] According to an embodiment of this application, the execution analysis module includes: a task scheduling unit configured to schedule test tasks according to the execution mode, priority, and dependencies of test cases and system resources; a defect analysis unit configured to analyze test failure results using natural language processing and machine learning algorithms and generate defect reports; and a report generation unit configured to generate test reports based on test execution results.

[0076] In one example, the analysis module contains three units:

[0077] Task Scheduling Unit: Assume the test task contains 100 test cases, of which 10 have high priority (e.g., core transfer, login), 30 have medium priority, and 60 have low priority. There are dependencies between the test cases; for example, "transfer" depends on "login" and "balance query". The scheduling unit first executes high-priority test cases, and after satisfying dependencies, dynamically executes independent test cases in parallel based on the system's current idle CPU (80%), memory (4GB available), and concurrency limit (maximum 10 threads). When system resources are strained (CPU > 90%), the concurrency level is automatically reduced.

[0078] Defect Analysis Unit: When a transfer use case fails, the error log is captured: "ERROR - com.bank.adapter.TimeoutException: Read timed out after 5000ms". Natural Language Processing extracts key information: "TimeoutException", "Read timed out", and "5000ms". This is correlated with the "adapter-driven" component in the business process, determining it to be an external interface timeout. The defect report includes: defect type (performance), severity (high), and suggested remediation (increasing timeout or optimizing backend processing).

[0079] Report generation unit: Summarizes all test results and generates an interactive HTML report containing the following charts: Test coverage radar chart (module coverage), Business pass rate pie chart (85% pass, 10% fail, 5% block), Defect distribution bar chart (by module: 3 security modules, 7 core transaction modules, 2 adaptation modules), and Compliance score dashboard (95 points).

[0080] Because the task scheduling unit comprehensively considers execution mode, priority, dependencies, and system resources, important test cases are executed first, shortening the overall test execution time. The defect analysis unit uses NLP and machine learning to reduce the average time for manual analysis of each failed test case and can automatically link it to relevant components, providing remediation suggestions. Visualized reports enable the testing team, development team, and management to quickly understand the system quality status, improving decision-making efficiency.

[0081] Figure 5 A flowchart illustrating a low-code testing method for financial transactions according to an embodiment of this application is shown.

[0082] like Figure 5 As shown, it includes steps S310 to S340.

[0083] In step S310, test cases are generated in response to the visual orchestration and business rule configuration operations of the components.

[0084] In step S320, the type of the financial system under test is identified, and the corresponding adapter driver is invoked to establish a communication connection with the financial system under test.

[0085] In step S330, the test cases are scheduled for execution based on their execution mode, priority, dependencies, and system resources.

[0086] In step S340, the test results of the test cases are analyzed to generate a visual test report.

[0087] In one example, taking a testing team needing to verify the online banking transfer function as an example, testers in the low-code testing system select the "Login Component" and "Transfer Component" from the left-hand component library, drag them onto the canvas, and connect them. In the rule configuration panel, they enter "if amount>50000 then needApproval=true". The system automatically converts these operations into a structured test case, including a component list, connection relationships, and rule expressions. The system sends a probe packet to the bank system under test, analyzes the returned HTTP header Server field to find "BankServer / 3.0", and recognizes the keyword "corporate online banking" on the page, identifying it as the "corporate online banking system". Subsequently, the corresponding HTTP adapter driver is automatically loaded, which is configured with the correct BaseURL (https: / / preprod.bank.com / api), API version, and SSL certificate. Based on the test case's "high" priority (because it's a core transaction), lack of dependencies (login has already been executed independently), and the current system CPU idle rate of 70%, a thread is immediately allocated for execution. During execution, the request time, request body, response time, and response status code are recorded. After execution, the system checks the code field in the response; if it is 200, it determines success. If the code is 500, the system analyzes the error stack to pinpoint the cause as "database connection pool full". Finally, a visual report is generated, including the transfer success rate (100% in this execution), average response time (120ms), and security compliance score (98 points).

[0088] Because test case generation uses a visual interface rather than coding, non-programmers can independently design tests, improving test development efficiency. Automatic system type identification and driver loading eliminate the need for manual communication parameter configuration, significantly reducing test environment setup time. Dynamic scheduling improves system resource utilization and shortens overall regression testing time. Automatic failure analysis and report generation reduce defect location time from hours to minutes, significantly shortening the test feedback cycle.

[0089] According to an embodiment of this application, generating test cases in response to the visual orchestration and business rule configuration operations of components includes: determining a target component in response to a component selection instruction; orchestrating a business process in response to drag and connect instructions for the target component; and configuring business rules through a graphical interface in response to a business rule configuration instruction to generate test cases.

[0090] In one example, the tester first clicks on the "Loan Application Component" in the component library. The system highlights the component and prompts the tester to "Drag and drop it to the canvas." After dragging, a rectangle appears on the canvas, displaying "Loan Application." Next, the tester drags the "Credit Assessment Component" to the right and draws a line from the output point of "Loan Application" to the input point of "Credit Assessment." In the pop-up properties window, the data transfer rule is set: "Loan Application.Loan Amount" is passed to "Credit Assessment.Loan Amount." Then, a condition is added by right-clicking on the connection: "Trigger manual approval if credit score < 600." The rule configuration interface is opened, and the formula "Monthly Repayment = Loan Amount * Monthly Interest Rate * (1 + Monthly Interest Rate)^Number of Periods / ((1 + Monthly Interest Rate)^Number of Periods - 1)" is edited. Based on these operations, the system generates a complete test case definition containing nodes, edges, conditions, and formulas.

[0091] According to an embodiment of this application, identifying the type of the financial system under test and invoking the corresponding adapter driver to establish a communication connection with the financial system under test includes: identifying the type of the financial system under test based on at least one of the communication protocol characteristics, interface specification characteristics, and interface characteristics of the financial system under test; and invoking the corresponding adapter driver according to the type of the financial system under test to establish a communication connection with the financial system under test; wherein the adapter driver includes at least one of a middleware interface adapter for a bank core system, a secure keyboard adapter for a mobile financial application, and a financial information exchange protocol adapter for a securities trading system.

[0092] In one example, when the system needs to identify an unknown securities trading system, it first captures its network communication packets. Finding the packet header contains the string "FIX.4.4", it directly identifies it as a FIX protocol system. Then, based on the type mapping table, it selects the "FIX adapter driver". This driver automatically generates a standard FIX login message (35=A, username, password) and sends it to the system's provided receiving port (e.g., 9001). After the system returns login confirmation, the adapter driver maintains a session heartbeat (sending heartbeat messages periodically). When an order instruction needs to be sent, the adapter driver assembles a new order message (35=D, stock code, quantity, price). The entire process requires no understanding of the underlying details of the FIX protocol from the testers.

[0093] Figure 6 A block diagram of an electronic device suitable for implementing a transaction risk identification method according to an embodiment of this application is shown schematically.

[0094] like Figure 6 As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory 602 or a program loaded from a storage portion 608 into a random access memory 603. The processor 601 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0095] Random access memory 603 stores various programs and data required for the operation of electronic device 600. Processor 601, read-only memory 602, and random access memory 603 are interconnected via bus 604. Processor 601 executes various steps of the method flow according to embodiments of this application by executing programs in read-only memory 602 and / or random access memory 603. It should be noted that programs may also be stored in one or more memories other than read-only memory 602 and random access memory 603. Processor 601 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0096] According to embodiments of this application, the electronic device 600 may further include an input / output interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card, such as a local area network card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0097] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0098] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 602 described above, and / or random access memory 603, and / or one or more memories other than read-only memory 602 and random access memory 603.

[0099] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0100] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0101] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by processor 601, it performs the functions defined in the system of embodiments of this application. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0102] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0103] 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 a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may 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.

[0104] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.< / bankcore>

Claims

1. A low-code testing system for financial business, characterized in that, include: The business modeling module is configured to store a library of financial business-specific components. In response to drag-and-drop and connection operations of the financial business-specific components on a visual canvas, it orchestrates business processes and configures business rules through a graphical interface. The heterogeneous system adaptation module is configured to identify the type of the financial system under test and call the corresponding adaptation driver to establish a communication connection with the financial system under test. The security and compliance testing module is configured to perform data encryption transmission verification, data de-identification verification, access control verification, and financial compliance rule comparison during the testing process. The execution analysis module is configured to schedule test case execution, record test process data, analyze test failure reasons, and generate visual test reports.

2. The testing system according to claim 1, characterized in that, The business modeling module includes: The component library is configured to store components for the banking, securities, and insurance sectors. The banking components include account opening, fund transfer, and credit approval components; the securities components include stock trading and fund subscription / redemption components; and the insurance components include policy application and claims processing components. The process orchestration unit is configured to display a visual canvas and respond to user drag-and-drop and connection operations to orchestrate business processes, as well as set data transfer rules and business logic judgment conditions between components. The rule configuration unit is configured to display a graphical rule configuration interface and to configure financial business rules in response to user-input conditional expressions and formula calculations.

3. The testing system according to claim 1, characterized in that, The heterogeneous system adaptation module includes: The type identification unit is configured to identify the type of the financial system under test based on at least one of the communication protocol characteristics, interface specification characteristics, and interface characteristics of the financial system under test. The adapter driver unit is configured to call the corresponding adapter driver for different financial system types; the adapter driver includes at least one of the following: a middleware interface adapter for a bank core system, a secure keyboard adapter for a mobile financial application, and a financial information exchange protocol adapter for a securities trading system. The environment management unit is configured to switch between development, testing, and pre-production environments in response to environment switching commands, and to automatically update the corresponding network configurations and interface addresses.

4. The testing system according to claim 3, characterized in that, The type identification unit is further configured to: Acquire network communication messages of the financial system under test; Extract the protocol identifier field from the network communication message, and match the protocol identifier field with the protocol features in the financial industry standard protocol feature library, which includes the SWIFT protocol features and the financial information exchange protocol features. The type of the tested financial system is determined based on the matched protocol characteristics.

5. The testing system according to claim 4, characterized in that, The type identification unit is further configured to: In the event of a failed match, obtain the interface definition file and interface source code of the financial system under test. The interface definition file and the interface source code are parsed to extract data interface specifications, interface element types, and layout features; The analysis results are compared with the features in the labeled financial system sample library to determine the type with the highest similarity as the identification result.

6. The testing system according to claim 1, characterized in that, The security compliance testing module includes: The encryption verification component is configured to verify that financial data conforms to standard encryption algorithms during transmission; The desensitization verification component is configured to check that sensitive data is desensitized according to preset rules. The permission verification component is configured to simulate user operations and verify that the system permission allocation complies with the principle of least privilege. The compliance rule library is configured to store financial compliance rules and automatically compare business operations with these financial compliance rules during testing.

7. The testing system according to claim 1, characterized in that, The execution analysis module includes: The task scheduling unit is configured to schedule test tasks based on the execution mode, priority, and dependencies of test cases, as well as system resources. The defect analysis unit is configured to analyze test failure results using natural language processing and machine learning algorithms and generate defect reports. The report generation unit is configured to generate a test report based on the test execution results.

8. A low-code testing method for financial business, applied to the testing system according to any one of claims 1 to 7, characterized in that, include: In response to visual orchestration of components and configuration of business rules, test cases are generated; Identify the type of the financial system under test and call the corresponding adapter driver to establish a communication connection with the financial system under test; The test cases are scheduled for execution based on their execution mode, priority, dependencies, and system resources. The test results of the test cases are analyzed to generate a visual test report.

9. The method according to claim 8, characterized in that, The generation of test cases in response to the visual orchestration and business rule configuration operations of components includes: In response to a component selection command, determine the target component; In response to drag-and-drop and connect commands to the target component, orchestrate business processes; and In response to business rule configuration commands, business rules are configured through a graphical interface, and test cases are generated.

10. The method according to claim 8, characterized in that, The step of identifying the type of the financial system under test and calling the corresponding adapter driver to establish a communication connection with the financial system under test includes: The type of the financial system under test is identified based on at least one of the communication protocol characteristics, interface specification characteristics, and interface characteristics of the financial system under test. The corresponding adapter driver is invoked according to the type of the financial system under test to establish a communication connection with the financial system under test; wherein the adapter driver includes at least one of the following: a middleware interface adapter for a bank core system, a secure keyboard adapter for a mobile financial application, and a financial information exchange protocol adapter for a securities trading system.

11. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 8 to 10.

12. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 8 to 10.

13. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 8 to 10.

Images