An internet financial service whole-process test method

Abstract

The application relates to an Internet financial service full-process test method, which comprises the following steps: respectively constructing a journey graph, an upstream and downstream system relation graph and a business full-link view to comprehensively cover all test scenes; based on data preparation modularization, interface encapsulation and UI traversal, automatically obtaining to-be-tested data from the current test scene; respectively performing special character and code special test and fund class special test on the to-be-tested data; and outputting test results. Compared with the prior art, the application can cover financial service attributes, Internet product operation attributes and micro-service architecture attribute tests, thereby ensuring product quality and effectively improving delivery efficiency.

Description

Technical Field

[0001] This invention relates to the field of internet data testing technology, and in particular to a method for testing the entire process of internet financial business. Background Technology

[0002] Based on their operational models, internet finance can be subdivided into six major categories: third-party payment, P2P lending, big data finance (supply chain finance), crowdfunding, the Yu'ebao model, and internet finance e-commerce platforms. Among these, internet finance e-commerce platforms have three main characteristics: First, they operate within a microservices framework, involving a large number of microservices that interact through interfaces and are highly coupled. Second, they are internet-based, involving a massive user base, making product operation crucial. This involves various merchants, stores, brands, and products, with diverse business scenarios, complex configuration parameters, and spanning multiple systems, demanding high operational quality and efficiency. Third, they possess financial characteristics, compared to conventional e-commerce, involving various accounting tests, from customer order placement to merchant settlement and bank accounting, involving multiple systems, long chains, and complex computational logic.

[0003] Existing testing methods mainly consist of integration testing and system testing. However, for the microservice architecture of an internet finance e-commerce platform, especially one involving multiple related system projects, existing testing methods may have the following problems:

[0004] I. The product covers a wide range of fields, including operational configuration (customer groups, merchants, brands, products and activities, etc.), customer operations on various client clients (product search, adding to cart, placing orders, payment, refund, logistics tracking, coupon code redemption, in-store payment, etc.), and clearing and settlement, reconciliation and transfer between banks and merchants. There are many end-to-end test scenarios and long links, and test scenarios are easy to be missed.

[0005] Second, the numerous internal and external interconnected systems, with inconsistent system architectures, make it difficult to standardize character encoding, database design, and numerical calculation methods. This can easily lead to the following problems: First, inconsistent character encoding may result in garbled characters when transmitting special characters. Second, differences may exist in the attributes (unit, length, precision) and conversion logic (rounding) of monetary fields, which can easily cause errors in accounting, bill display, and monetary transfer and conversion between multiple systems. Furthermore, testing needs to cover not only field attributes and precision but also complex accounting calculation logic (product type, product quantity, coupon type, cost center, payment type, handling fees, and service fees, etc.), making the test scenarios complex and prone to omissions.

[0006] Third, after product launch, the connection between users and the product is mainly established and maintained through operational methods. For example, content operations primarily expand the customer, merchant, brand, and product reach, while event operations mainly involve conducting various activity modes to attract customers. Therefore, development generally adopts a low-code, configurable design, resulting in less development work. However, each time a new merchant, brand, product, or event is launched, comprehensive testing is required after configuration, making testing a bottleneck for product delivery. Furthermore, internal and external systems interact through interfaces. With numerous interfaces, there are many exception scenarios to test (such as empty strings, excessively long characters, and illegal characters). Combined test case scenarios, such as Cartesian product coverage, result in a large number of test cases, posing certain product quality and testing schedule risks.

[0007] In summary, current testers mainly design test cases from the perspective of system functionality, lacking consideration of customer and operational perspectives in test scenarios. On the one hand, due to a lack of understanding of upstream and downstream related systems, the end-to-end test scenario analysis is often incomplete. On the other hand, automation is mainly for interface testing, lacking diversity and not significantly improving testing efficiency. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the existing technology and provide a full-process testing method for internet finance business, which can cover the testing of financial business attributes, internet product operation attributes and microservice architecture attributes, not only ensuring product quality, but also effectively improving delivery efficiency.

[0009] The objective of this invention can be achieved through the following technical solution: a method for testing the entire process of internet finance business, comprising the following steps:

[0010] S1. Construct a journey diagram, an upstream and downstream system relationship diagram, and a full business link view to comprehensively cover all test scenarios;

[0011] S2. Based on modular data preparation, interface encapsulation, and UI traversal, automatically obtain the test data from the current test scenario;

[0012] S3. Perform special character encoding tests and financial data tests on the test data, and output the test results.

[0013] Furthermore, the journey map in step S1 includes a customer journey map and an operational journey map. The customer journey map is divided according to the stage of customer participation in the business, and the operational journey map is divided according to the stage of operational personnel carrying out the business.

[0014] The customer journey map includes information on customer goals, customer behavior, contact system functions, risk points, and risk control points for each stage.

[0015] The operational journey map includes information on operational goals, operational behaviors, contact system functions, risk points, and risk control points for each stage.

[0016] Furthermore, the process of constructing the upstream and downstream relationship diagram in step S1 is as follows: taking the current system as the center, and drawing the upstream and downstream related systems according to the functions of the system.

[0017] Furthermore, the process of constructing the full-link business view in step S1 is as follows: taking the current business scenario as the center, draw the processes and related functions of each system on the entire business function link from the perspectives of customers and operations, so as to avoid the omission of end-to-end test points.

[0018] Furthermore, step S2 specifically includes the following steps:

[0019] S21. Automatically generate single-interface test data based on preset rules, configured statements, and test scenarios;

[0020] S22. Adopt a modular design for data preparation and an interface encapsulation method to automatically prepare test data;

[0021] S23. Based on UI test automation, traverse the data sources to be tested.

[0022] Furthermore, the single-interface test data in step S21 includes positive example data, negative example data, and abnormal scenario data.

[0023] Furthermore, step S21 specifically includes the following steps:

[0024] S211. Generate interface use cases, including but not limited to editing interface information, interface name, URL, and request method;

[0025] S212. Configure the data model: Configure a positive test data based on the interface parameter template;

[0026] S214. Preset rules: Configure test scenarios for interface test cases, including but not limited to forward rules, reverse rules, empty strings, boundary values, and random values;

[0027] S215, Test Case Logic Control: Configure the logic control and assertions corresponding to the interface test cases to meet the testing needs of more scenarios;

[0028] S216. Generate test data: Automatically generate test data for various scenarios that meet preset rules.

[0029] Furthermore, the specific process of the special character garbled code test in step S3 is as follows:

[0030] The special character set contained in the store, brand and product names configured in the production process is filtered using the regular expression "^[\u4e00-\u9fa5,az,AZ,0-9,]{1,}$".

[0031] For the selected special characters, such as: %.·é? ×の()き& / -°_&()·%#? +.? B【】2:の-×*— / き〔〕Qé。 `、﹢, configure the store, brand and product names in the test environment;

[0032] Test the display on the client-side page to check for any garbled characters.

[0033] Furthermore, in step S3, the specific testing of funds is conducted using a pre-defined test case template for funds.

[0034] Furthermore, the content of the funding-related test case template includes:

[0035] The scenarios are divided into order payment, full refund, and partial refund;

[0036] List the factors that influence payment and settlement amounts in order payment and refund scenarios;

[0037] Design different inputs based on different business scenarios, and calculate the amount payable and the settlement amount;

[0038] Input and output information for monetary-related special tests.

[0039] Compared to existing technologies, this invention comprehensively covers all test scenarios by constructing journey diagrams, upstream and downstream system relationship diagrams, and a full-link business view, avoiding omissions in end-to-end test scenarios. Through modular data preparation, interface encapsulation, and UI traversal, it comprehensively covers interface test scenarios while efficiently preparing test data. Furthermore, the inclusion of specialized tests for special character encoding issues and financial transactions effectively improves testing efficiency and yields accurate test results. This forms a complete testing solution for the entire internet finance business process, covering testing of financial business attributes, internet product operation attributes, and microservice architecture attributes, ensuring product quality while effectively improving delivery efficiency.

[0040] This invention addresses the challenges of microservice framework products, which involve numerous microservices that interact and are highly coupled via interfaces, making comprehensive interface testing difficult. Therefore, it proposes a method to automatically generate single-interface test data using preset rules, configured statements, and test scenarios, covering positive examples, negative examples, and exception scenarios. For interfaces with numerous input parameter fields, this method significantly improves the efficiency of single-interface testing.

[0041] This invention designs special character encoding tests and financial data tests. The special character encoding test can automatically and quickly detect whether there are garbled characters or special characters in the product, so as to fully guarantee the quality of subsequent products. The financial data test uses a financial data test case template that includes the influencing factors of amount calculation. This not only improves the readability and efficiency of the test cases, but also allows the template to be reused. Each test does not require manual calculation, avoiding problems caused by human calculation errors. It also reduces the difficulty of testing and avoids test result deviations caused by misunderstandings among various parties. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the method flow of the present invention;

[0043] Figure 2 This is a diagram illustrating the upstream and downstream system relationships constructed in the embodiment.

[0044] Figure 3 This is a full-link view of the business constructed in the example. Detailed Implementation

[0045] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0046] Example

[0047] A method for testing the entire process of internet finance business includes the following steps:

[0048] S1. Construct a journey map, an upstream and downstream system relationship diagram, and a full business link view to comprehensively cover all test scenarios. The journey map includes a customer journey map and an operational journey map. The customer journey map is divided according to the stage of customer participation in the business (the customer journey map includes information on customer goals, customer behavior, contact system functions, risk points, and risk control points for each stage). The operational journey map is divided according to the stage of operational personnel carrying out the business (the operational journey map includes information on operational goals, operational behavior, contact system functions, risk points, and risk control points for each stage).

[0049] The process of constructing the upstream and downstream relationship diagram is as follows: taking the current system as the center, and drawing the upstream and downstream related systems according to the functions of the current system;

[0050] The process of building a full-link business view is as follows: taking the current business scenario as the center, draw the processes and related functions of each system in the entire business function link from the perspectives of customers and operations, so as to avoid the omission of end-to-end test points;

[0051] S2. Based on modular data preparation, interface encapsulation, and UI traversal, automatically retrieve the test data from the current test scenario. Specifically:

[0052] S21. Automatically generate single-interface test data (including positive example data, negative example data, and abnormal scenario data) through preset rules, configured statements, and test scenarios;

[0053] S22. Adopt a modular design for data preparation and an interface encapsulation method to automatically prepare test data;

[0054] S23. Based on UI test automation, traverse the data source to be tested;

[0055] S3. Perform special character encoding tests and financial data tests on the test data, and output the test results. The specific process of the special character encoding test is as follows:

[0056] The special character set contained in the store, brand and product names configured in the production process is filtered using the regular expression "^[\u4e00-\u9fa5,az,AZ,0-9,]{1,}$".

[0057] For the selected special characters, such as: %.·é? ×の()き& / -°_&()·%#? +.? B【】2:の-×*— / き〔〕Qé。 `、﹢, configure the store, brand and product names in the test environment;

[0058] Test the display on the client-side page to check for any garbled characters.

[0059] Fund-related specific tests are conducted using a pre-defined fund-related test case template. The fund-related test case template includes the following:

[0060] The scenarios are divided into order payment, full refund, and partial refund;

[0061] List the factors that influence payment and settlement amounts in order payment and refund scenarios;

[0062] Design different inputs based on different business scenarios, and calculate the amount payable and the settlement amount;

[0063] Input and output information for monetary-related special tests.

[0064] This embodiment applies the above technical solution and mainly includes the following:

[0065] 1. For internet project products, the design and execution of tests require not only traditional systems thinking but also customer-centric and operational thinking. In terms of system testing, because the business spans multiple systems with long chains, testers are only familiar with the systems they are responsible for and are unfamiliar with upstream and downstream systems and other related systems, which can lead to omissions in end-to-end test scenarios. Therefore, this technical solution proposes a method for sorting out test scenarios by combining journey diagrams, upstream and downstream system relationship diagrams, and a full business chain view, as explained below:

[0066] 1) Journey Map: Constructed from the customer's and operations personnel's perspectives, respectively. The drawing method is as follows:

[0067] The customer journey is divided according to the stages in which the customer participates in the business, while the operations journey is divided according to the stages in which operations personnel conduct the business.

[0068] Customer journey focus: Analyze customer goals, customer behavior, contact system functionalities, risk points, and risk control points at each stage;

[0069] Operational journey focuses on analyzing the operational goals, operational behaviors, system function points, risk points, and risk control points at each stage.

[0070] Customer / operation goals and customer / operation behaviors aim to enable testers to think outside the box when performing requirements analysis and test scenario design;

[0071] Risk points / risk control points: Based on the potential risks and problems, improve the test cases for abnormal scenarios.

[0072] 2) Upstream and downstream system relationship diagram (e.g.) Figure 2 As shown): Taking a certain system as the center, draw the upstream and downstream related systems according to the functions of the system. That is, from the perspective of a certain system, identify the upstream and downstream systems that are related to the functions of different systems, and lay the foundation for drawing a full-link view of the business.

[0073] 3) Full-link view of business (e.g.) Figure 3 As shown): Centered on the business scenario, from the perspective of customers and operations, draw the processes and related functions of each system in the entire business function chain, so as to avoid the omission of end-to-end test points.

[0074] This method allows testers to consider test scenarios from a customer-centric and operational perspective when designing test cases, avoiding the limitations of systems thinking. At the same time, it enhances their understanding of upstream and downstream systems through upstream and downstream relationship diagrams, avoiding omissions of upstream and downstream interaction scenarios. Furthermore, it provides a comprehensive understanding of the systems involved in the entire business chain through a full-link business view, ensuring comprehensive coverage of the business chain.

[0075] 2. Automation diversity

[0076] 1) Automated Generation of Single Interface Test Data: To initiate testing as early as possible and identify defects in advance, interface testing begins during the development phase. However, this faces challenges such as numerous abnormal scenarios (e.g., empty strings, excessively long characters, illegal characters), resulting in a massive number of test cases that are difficult to cover manually with all input parameters. For example, an order interface has 76 fields, making it extremely labor-intensive to manually write automated test scripts, and it's impossible to guarantee full coverage during script development. To address this issue, a tool for automatically generating single interface test data was developed. Through preset rules, configured statements, and test scenarios, it automatically generates single interface test data, covering positive examples, negative examples, and abnormal scenario data. For interfaces with many input parameter fields, this method significantly improves the efficiency of single interface testing. Specific steps are explained below:

[0077] Generate API test cases: Edit API information, including API name, URL, request method, etc.

[0078] Configure the data model: Based on the interface parameter template, configure a positive test data set;

[0079] Preset rules: Configure test scenarios for interface test cases, including: forward rules, reverse rules, empty strings, boundary values, random values, etc.;

[0080] Test case logic control: Configure common logic controls and assertions for interface test cases to meet testing needs in more scenarios, such as:

[0081] Border: Boundary test;

[0082] Correct: Correct input, correct expected output;

[0083] Error: Incorrect input, expected output;

[0084] Design: Script testing logic such as loops like for, while, and do-while, variable assignment, etc.;

[0085] Generate test data: Through a small tool, test data for various scenarios that meet preset rules can be automatically generated.

[0086] 2) Automated Test Data Preparation: API automation mainly focuses on product type and revolves around order placement rules. Its automated implementation faces the following challenges:

[0087] The online store offers a variety of product types with complex configurations. Each order placement rule has specific requirements for the product information data, and the existing data cannot meet all business scenarios. For example, validating the start and end times of product sales requires frequent changes to the corresponding product attributes based on the business scenario.

[0088] The product details information is obtained from the upstream system's Redis by calling the upstream system's service interface. This is not real-time and the test data may be modified, which introduces instability.

[0089] Downstream systems often require upstream systems to cooperate in preparing data for testing, which necessitates extensive communication regarding data requirements and mutual waiting, impacting testing efficiency.

[0090] Through in-depth analysis, this technical solution proposes a modular design for data preparation and an interface encapsulation method. Taking the scenario of purchasing coupons with a single purchase limit as an example, the specific implementation method is explained as follows:

[0091] A. Encapsulation of the upstream Redis system's interface for adding and modifying product information: First, the process of handling product information in the upstream Redis system is encapsulated into a RESTful API. Then, Swagger is used to provide a GUI interface and documentation for the RESTful API. This allows all testers to add or modify product information in Redis to prepare test data.

[0092] B. Configure a product information entry in the upstream system backend;

[0093] C. Configure the data source according to the single-purchase limit business scenario (single-purchase limit quantity is empty, single-purchase limit quantity is 0, single-purchase limit quantity < number of purchases, single-purchase limit quantity = number of purchases, single-purchase limit quantity > number of purchases):

[0094] Step 1: Configure variables in the data source by column dimension. The variables include the input parameter fields of the order placement interface, the initial data, and the fields returned by the interface.

[0095] Step 2: Based on the single purchase limit business scenario, configure the values ​​of the request message input parameter fields, the data initialization values, and the interface return field values ​​in the variable configuration corresponding to the data source. One column of data represents one business scenario.

[0096] Step 3: Write a script to initialize the test data according to the initialization fields configured in the data source, so that the data meets the verification requirements of the current business scenario;

[0097] Step 4: Write a script to call the RESTful API and modify the single purchase limit field attribute value of the product in Redis according to the data source configuration.

[0098] Once the script is written, test data preparation can be completed with a single click, allowing for subsequent test execution. Besides single-purchase quantity limits for products, other product attribute business scenarios can also be automated with a single click through data source configuration and automated scripts. This technological improvement and innovation enables rapid iteration and capability enhancement of test services, lowers the threshold and cost of test data preparation, improves the utilization and quality of test data, and supports efficient and high-quality product delivery.

[0099] 3) Utilizing UI test automation to solve the pain point of traversing massive numbers of stores and products: The online store involves configurations for tens of thousands of stores and products. To ensure the accuracy of all configuration information and that customers can search for stores and place orders normally, it is necessary to traverse and test all products and stores. Due to the large workload and tight schedule, it is impossible to complete full testing manually in a short time. Therefore, this technical solution proposes UI-automated store and product traversal testing:

[0100] A. Export the production data and product information data from the stores to an Excel spreadsheet as the data source;

[0101] B. Script steps:

[0102] Read store information / product information from an Excel data source;

[0103] Identify the search box on the page and enter the store name / product name from the data source into the search box;

[0104] Click the "Search" button;

[0105] In the search results list, click on the store / product you searched for to enter the details page;

[0106] Assert whether the header text in the details page contains the searched store name / product name;

[0107] The process continues in a loop until all store / product information in the Excel data source has been traversed.

[0108] Therefore, in this embodiment, the inspection of hundreds of thousands of stores can be completed in 10 hours. For stores / products with incorrect assertions, the investigation can be carried out. This may be due to incorrect or missing basic parameter configurations, duplicate store / product names, or logical conflicts.

[0109] 3. Specialized Tests:

[0110] 1) Special Character Encoding Test: Due to the large number of interconnected systems and their different character encodings (UTF-8, GBK), special characters in the configured store, brand, and product names may cause garbled characters in the front-end display, affecting customer experience. Therefore, a special character test was conducted. The steps are as follows:

[0111] Due to the large number of special characters, full verification is not possible. Therefore, the special character set contained in the store, brand and product names configured in the production is filtered by the regular expression "^[\u4e00-\u9fa5,az,AZ,0-9,]{1,}$".

[0112] For the selected special characters such as %.·é? ×の()き& / -°_&()·%#? +.? B【】2:の-×*— / き〔〕Qé。 `、﹢, configure the store, brand and product names in the test environment;

[0113] Test the display on the client-side page to check for any garbled characters.

[0114] 2) Funds-related Specialized Test: The main functions of the e-commerce platform are purchasing goods using different types of coupons, refunds, reconciliation, bookkeeping, and settlement. These are all high-risk, key business functions related to funds, involving numerous business scenarios and complex calculation rules. This embodiment involves 121 business scenarios:

[0115] Order placement and payment: Product and coupon usage scenarios = 8 * 10 = 80, with cost centers and payment methods overlapping, totaling 80.

[0116] Full refund: The product and coupon usage scenarios overlap, totaling 8 + 10 = 18.

[0117] Partial refunds: There are multiple products, coupon usage scenarios, cost centers, and payment methods that overlap, totaling 5 + 10 + 3 + 5 = 23.

[0118] Traditional test case templates mainly consist of a case name, preconditions, steps, and expected results. Writing test cases for all scenarios using this template is labor-intensive, lacks readability, and has low execution efficiency. Therefore, this technical solution proposes a test case template for financial transactions:

[0119] The scenarios are divided into order payment, full refund, and partial refund;

[0120] List the factors that influence the payment amount and settlement amount in order payment and refund scenarios, such as the type of goods purchased, the quantity of goods, the scenario in which coupons are used, the amount of coupons used, transaction fees, service fees, cost centers, and payment methods;

[0121] Different inputs are designed based on different business scenarios, such as the type and quantity of goods purchased, cost centers, payment methods, and coupon usage scenarios, to calculate the amount payable and the settlement amount.

[0122] For monetary-related tests, the input and output must cover: scientific notation format for large amounts, 0 yuan, precision, rounding, and unit (yuan / minute).

[0123] This test case template improves the readability and efficiency of test cases. Furthermore, the template is reusable, eliminating the need for manual calculations for each test and avoiding problems caused by human error. It also reduces the difficulty of testing and avoids deviations in test results due to misunderstandings among different parties.

[0124] In summary, this technical solution designs test scenarios from different perspectives for internet project products. By analyzing customer goals, customer behavior, operational goals, and operational behaviors, it transcends the framework of system functions. This not only enables the early detection of problems during the requirements analysis phase and reduces the cost of problem fixing, but also more comprehensively ensures the quality of the launched product.

[0125] From a technical perspective, this solution proposes methods for automated UI traversal testing and uncommon character encoding testing, which can help operations personnel improve operational efficiency and ensure the quality of product operations.

[0126] For financial products, testing of fund-related accounting is a high-risk business. This technical solution proposes a special test for fund-related accounting and uses a templated method by enumerating the influencing factors of the amount calculation to reduce the complexity of testing and improve the efficiency of testing.

[0127] For products with microservice frameworks, there are many microservices that call each other through interfaces and are coupled with each other, making it difficult to fully cover interface testing scenarios. This technical solution proposes a method to automatically generate single interface test data by pre-setting rules, configuring statements and test scenarios.

[0128] This technical solution enables the entire testing process of an internet finance e-commerce platform, covering testing of financial business attributes, internet product operation attributes, and microservice architecture attributes. It not only ensures product quality but also effectively improves delivery efficiency.

Claims

1. A method for testing the entire process of internet finance business, characterized in that, Includes the following steps: S1. Construct a journey diagram, an upstream and downstream system relationship diagram, and a full business link view to comprehensively cover all test scenarios; S2. Based on modular data preparation, interface encapsulation, and UI traversal, automatically obtain the test data from the current test scenario; S3. Perform special character garbled character tests and financial type tests on the test data, and output the test results. Step S2 specifically includes the following steps: S21. Automatically generate single-interface test data based on preset rules, configured statements, and test scenarios; S22. Adopt a modular design for data preparation and an interface encapsulation method to automatically prepare test data; S23. Based on UI test automation, traverse the data source to be tested; Step S21 specifically includes the following steps: S211. Generate interface use cases, including editing interface information, interface name, URL, and request method; S212. Configure the data model: Configure a positive test data based on the interface parameter template; S214. Preset rules: Configure test scenarios for interface test cases, including forward rules, reverse rules, empty strings, boundary values, and random values; S215, Test Case Logic Control: Configure the logic control and assertions corresponding to the interface test cases to meet the testing needs of more scenarios; S216. Generate test data: Automatically generate test data for various scenarios that meet preset rules.

2. The method for testing the entire process of internet finance business according to claim 1, characterized in that, In step S1, the journey map includes a customer journey map and an operational journey map. The customer journey map is divided according to the stage of customer participation in the business, and the operational journey map is divided according to the stage of operational personnel carrying out the business. The customer journey map includes information on customer goals, customer behavior, contact system functions, risk points, and risk control points for each stage. The operational journey map includes information on operational goals, operational behaviors, contact system functions, risk points, and risk control points for each stage.

3. The method for testing the entire process of internet finance business according to claim 1, characterized in that, The process of constructing the upstream and downstream relationship diagram in step S1 is as follows: taking the current system as the center, and drawing the upstream and downstream related systems according to the functions of the system.

4. The method for testing the entire process of internet finance business according to claim 1, characterized in that, The process of constructing the full-link business view in step S1 is as follows: taking the current business scenario as the center, draw the process and related functions of each system on the entire business function link from the perspectives of customers and operations, so as to avoid the omission of end-to-end test points.

5. The method for testing the entire process of internet finance business according to claim 1, characterized in that, The single-interface test data in step S21 includes positive example data, negative example data, and abnormal scenario data.

6. The method for testing the entire process of internet finance business according to claim 1, characterized in that, The specific process of the special character garbled code test in step S3 is as follows: Using regular expressions, filter the special character sets contained in the store, brand, and product names configured by the manufacturer; For the selected special characters, configure the store, brand, and product names in the test environment; Test the display on the client-side page to check for any garbled characters.

7. The method for testing the entire process of internet finance business according to claim 1, characterized in that, In step S3, the specific testing of funds involves using a pre-defined test case template for funds.

8. The method for testing the entire process of internet finance business according to claim 7, characterized in that, The content of the financial test case template includes: The scenarios are divided into order payment, full refund, and partial refund; List the factors that influence payment and settlement amounts in order payment and refund scenarios; Design different inputs based on different business scenarios, and calculate the amount payable and the settlement amount; Input and output information for monetary-related special tests.

Images