CN115934515A - Internet financial business full-process testing method - Google Patents

Internet financial business full-process testing method Download PDF

Info

Publication number
CN115934515A
CN115934515A CN202211471173.2A CN202211471173A CN115934515A CN 115934515 A CN115934515 A CN 115934515A CN 202211471173 A CN202211471173 A CN 202211471173A CN 115934515 A CN115934515 A CN 115934515A
Authority
CN
China
Prior art keywords
test
data
service
graph
interface
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211471173.2A
Other languages
Chinese (zh)
Inventor
铁锦程
章晓岚
吴天天
陈嘉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Pudong Development Bank Co Ltd
Original Assignee
Shanghai Pudong Development Bank Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Pudong Development Bank Co Ltd filed Critical Shanghai Pudong Development Bank Co Ltd
Priority to CN202211471173.2A priority Critical patent/CN115934515A/en
Publication of CN115934515A publication Critical patent/CN115934515A/en
Pending legal-status Critical Current

Links

Images

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The invention relates to a method for testing the whole process of internet financial business, which comprises the following steps: respectively constructing a journey graph, an upstream and downstream system relation graph and a service full link view to comprehensively cover all test scenes; automatically acquiring data to be tested from a current test scene based on data preparation modularization, interface packaging and UI traversal modes; and respectively carrying out special character messy code special test and fund special test on the data to be tested, and outputting to obtain a test result. Compared with the prior art, the method can cover tests of financial business attributes, internet product operation attributes and micro-service architecture attributes, not only ensures product quality, but also effectively improves delivery efficiency.

Description

Internet financial business full-process testing method
Technical Field
The invention relates to the technical field of Internet data testing, in particular to a full-flow testing method for Internet financial services.
Background
Internet finance can be subdivided into six categories of third party payments, P2P credit, big data finance (supply chain finance), crowd funding financing, balance treasure model, internet finance mall, depending on the mode of operation. Wherein, internet financial mall mainly has three characteristics: firstly, under the framework of the micro-services, the number of the micro-services is large, the micro-services are mutually called through interfaces, and the micro-services are mutually coupled. Secondly, the internet characteristic relates to the huge number of users, the operation of products is key, and the product relates to the configuration of various different merchants, stores, brands, commodities and the like, has many service scenes and complex configuration parameters, spans a plurality of systems, and has high requirements on the quality and efficiency of operation. Thirdly, the financial characteristics, compared with the conventional e-commerce, the method also relates to the testing of various accounts, from the ordering of the customer to the clearing and settlement of the merchant and then to the bank account, and the related systems are multiple, the link length is long, and the calculation logic is complex.
The existing testing method mainly comprises integrated testing and system testing, and for a mall microservice architecture of internet finance, particularly relating to a plurality of associated system projects, the existing testing method may have the following problems:
1. the product has wide field of product design, covers operation configuration (customer group, commercial tenant, brand, commodity and activity and the like), is operated by the customer at various different client sides (commodity searching, shopping cart adding, order placing, payment, refund, logistics inquiry, ticket code verification and sale, shop purchase order and the like), is cleared, checked and paid between a bank and the commercial tenant, has multiple end-to-end test scenes, long links and is easy to omit test scenes.
2. The internal and external correlation systems are multiple, the system architectures are inconsistent, and the uniform specification of character coding, database design, numerical calculation methods and the like is difficult, so the following problems are easy to occur: firstly, the condition that the transfer of special characters is disordered due to the inconsistency of coded characters is caused, and secondly, the attribute (unit, length and precision) and the conversion logic (rounding) of the amount field can be different, such as accounting, bill display and the error-prone amount transfer and conversion among multiple systems. In addition, the test needs to cover complex accounting calculation logic (commodity type, commodity quantity, ticket type, cost center, payment type, handling fee, service fee and the like) besides the field attribute and precision, and the test scene is complex and easy to miss.
3. After the product is on line, the contact between the user and the product is established and maintained mainly through operation means, such as: the content operation mainly expands customers, merchants, brands and commodities, and the activity operation mainly develops various activity modes to attract the customers. Therefore, the development generally adopts a low-code and configuration design, the development workload is less, but new merchants, brands, commodities and activities are online each time, and the comprehensive test is carried out after the configuration is completed, so that the test can become the bottleneck of product delivery. In addition, the internal and external systems interact through interfaces, the interfaces are multiple, abnormal scenes needing to be tested (such as empty, overlong characters, illegal characters and the like) are multiple, combined case scenes such as Cartesian product coverage are carried out, the number of test cases is large, and certain product quality risks and test progress risks exist.
In summary, the current testers mainly design test cases from the perspective of system functions, and the test scenes lack consideration from the perspective of customers and operation, so that on one hand, the carding of end-to-end test scenes is often incomplete due to lack of understanding of upstream and downstream associated systems, and on the other hand, automation mainly is interface testing, and the test cases lack diversity and have little effect on test.
Disclosure of Invention
The invention aims to overcome the defects in the prior art and provide a method for testing the whole process of the internet financial service, which can cover the tests of the financial service attribute, the internet product operation attribute and the micro-service architecture attribute, not only ensure the product quality, but also effectively improve the delivery efficiency.
The purpose of the invention can be realized by the following technical scheme: a method for testing the whole flow of Internet financial business comprises the following steps:
s1, respectively constructing a journey graph, an upstream and downstream system relation graph and a service full link view so as to comprehensively cover all test scenes;
s2, automatically acquiring data to be tested from the current test scene based on the modes of data preparation modularization, interface packaging and UI traversal;
and S3, respectively carrying out special character messy code special test and fund special test on the data to be tested, and outputting to obtain a test result.
Further, the trip graph in step S1 includes a customer trip graph and an operation trip graph, the customer trip graph is divided according to the stage that the customer participates in the business, and the operation trip graph is divided according to the stage that the operator performs the business;
the customer trip graph includes customer goals, customer behavior, contact system function points, risk control point information for each phase;
the operation journey graph comprises operation targets, operation behaviors, contact system function points, risk points and risk control point information of each phase.
Further, the construction process of the upstream-downstream relationship diagram in step S1 is as follows: and drawing an upstream and downstream related system by taking the current system as a center and according to the functions of the system.
Further, the process of constructing the service full link view in step S1 is as follows: the current service scene is taken as the center, and the flows and related functions of all systems on the whole service function link are drawn respectively from the client and the operation direction, so that the omission of end-to-end test points is avoided.
Further, the step S2 specifically includes the following steps:
s21, automatically generating single-interface test data through a preset rule, configured sentences and test scenes;
s22, automatically preparing test data by adopting a data preparation modular design and an interface packaging mode;
and S23, traversing the data source to be tested based on a UI test automation mode.
Further, the single-interface test data in step S21 includes positive example data, negative example data, and abnormal scenario data.
Further, the step S21 specifically includes the following steps:
s211, generating an interface use case, including but not limited to editing interface information, an interface name, a URL (uniform resource locator) and a request mode;
s212, configuring a data model: configuring a piece of forward test data according to the interface parameter template;
s214, presetting a rule: configuring a test scenario of an interface use case, including but not limited to a forward rule, a backward rule, a null string, a boundary value and a random value;
s215, use case logic control: configuring logic control and assertion corresponding to the interface use case so as to meet the test of more scenes;
s216, generating test data: and automatically generating test data of various scenes meeting the preset rule.
Further, the specific process of the special character messy code special test in the step S3 is as follows:
screening special character sets contained in store, brand and commodity names configured on production through a regular expression '[ \ u4e00- \ u9fa5, a-Z, A-Z,0-9, ] {1, } $';
aiming at the screened special characters, for example: ? X () peripheral angle, { 1236565,% > -), (-) -) - #? Is turned over? B [ 2 ]: peripheral- [ x ]/12365. ' shop, brand and commodity name configuration is carried out in a test environment;
and testing by combining with the page display of the client to detect whether the messy codes exist.
Further, the fund-type special test in the step S3 is specifically a test by using a set fund-type test case template.
Further, the content of the fund type test case template comprises:
the scene comprises order payment, total refund and partial refund;
enumerating the influence factors of the payment amount and the clearing amount in the ordering payment and refund scene;
designing different inputs according to different service scenes, and calculating the amount to be paid and the clearing amount;
the money special item tests input and output information.
Compared with the prior art, the method can comprehensively cover all test scenes by constructing the journey graph, the upstream and downstream system relation graph and the service full link view, and avoids omission of end-to-end test scenes; test data can be prepared efficiently while an interface test scene can be covered comprehensively by means of data preparation modularization, interface packaging and UI traversal; in addition, the special character messy code special test and the fund special test are combined, so that the test efficiency can be effectively improved, and an accurate test result can be obtained. Therefore, a set of internet financial service full-flow test scheme is formed, tests of financial service attributes, internet product operation attributes and micro-service architecture attributes can be covered, product quality is guaranteed, and delivery efficiency is effectively improved.
The invention provides a method for automatically generating single-interface test data through preset rules, configured sentences and test scenes to cover positive example data, negative example data and abnormal scene data in consideration of the fact that the micro services are large in number, the micro services are mutually called and coupled through interfaces, and the interface test scenes are difficult to cover comprehensively for products of a micro service framework. For the interfaces with more reference fields, the method can greatly improve the efficiency of single-interface testing.
The special character messy code special test and the fund special test are designed, wherein the special character messy code special test can automatically and quickly test whether the product has messy codes or special characters so as to fully ensure the quality of subsequent products; the fund special test is realized by setting a fund test case template which contains influence factors of money calculation, so that the readability and the test efficiency of the test case are improved, in addition, the template can be repeatedly used, manual calculation is not needed again in each test, the problem caused by artificial calculation errors is avoided, the test difficulty is reduced, and the test result deviation caused by the understanding deviation of all parties is avoided.
Drawings
FIG. 1 is a schematic flow diagram of the process of the present invention;
FIG. 2 is a diagram of the relationship between upstream and downstream systems constructed in the example;
fig. 3 is a view of a full service link constructed in the embodiment.
Detailed Description
The invention is described in detail below with reference to the figures and specific embodiments.
Examples
A full-process testing method for Internet financial services comprises the following steps:
s1, respectively constructing a journey graph, an upstream and downstream system relation graph and a business full link view to comprehensively cover all test scenes, wherein the journey graph comprises a customer journey graph and an operation journey graph, the customer journey graph is divided according to the phases of business participation of customers (the customer journey graph comprises customer targets, customer behaviors, contact system function points, risk points and risk control point information of each phase), and the operation journey graph is divided according to the phases of business development of operators (the operation journey graph comprises operation targets, operation behaviors, contact system function points, risk points and risk control point information of each phase);
the construction process of the upstream and downstream relationship graph comprises the following steps: taking the current system as a center, and drawing an upstream and downstream related system according to the function of the system;
the construction process of the service full link view comprises the following steps: the method comprises the steps that a current service scene is taken as a center, the flow and related functions of each system on a whole service function link are drawn from a client and an operation direction respectively, and therefore end-to-end test points are prevented from being omitted;
s2, automatically acquiring data to be tested from the current test scene based on the modes of data preparation modularization, interface packaging and UI traversal, specifically:
s21, automatically generating single-interface test data (including positive example data, negative example data and abnormal scene data) through preset rules, configured statements and test scenes;
s22, adopting a data preparation modular design and an interface packaging mode to automatically prepare test data;
s23, traversing the data source to be tested based on a UI test automation mode;
s3, respectively carrying out special character messy code special test and fund special test on the data to be tested, and outputting to obtain a test result, wherein the specific process of the special character messy code special test is as follows:
screening special character sets contained in store, brand and commodity names configured on production through a regular expression '[ \ u4e00- \ u9fa5, a-Z, A-Z,0-9, ] {1, } $';
aiming at the screened special characters, for example: ? X () peripheral angle, { 1236565,% > -), (-) -) - #? Is turned over? B [ 2 ]: peripheral- [ x ]/12365. "+, shop, brand and commodity name configuration is performed in the test environment;
testing by combining with the page display of the client to detect whether the messy codes exist or not;
the fund special test is performed by adopting a set fund test case template, and the content of the fund test case template comprises the following steps:
the scene comprises order payment, total refund and partial refund;
enumerating the influence factors of the payment amount and the clearing amount in the ordering payment and refund scene;
designing different inputs according to different service scenes, and calculating the amount to be paid and the clearing amount;
the money special item tests input and output information.
The embodiment applies the above technical solution, and mainly includes the following contents:
1. the design and implementation of internet project products, testing, requires both customer thinking and operational thinking in addition to traditional system thinking. In the aspect of system testing, because the service spans a plurality of systems, the link is long, a tester is only familiar with the responsible system, and is not familiar with the upstream and downstream systems and other related systems, and the omission of end-to-end test scenes can be caused. Therefore, the technical scheme provides a method for combing test scenes by combining a journey graph, an upstream and downstream system relation graph and a service full link view, and the method is described as follows:
1) Journey graph: the construction is carried out from the perspective of customers and the perspective of operation respectively by taking customers and operators as centers. The drawing method comprises the following steps:
the customer itinerary is divided according to the stage that the customer participates in the business, and the operation itinerary is divided according to the stage that the operator carries out the business;
customer trip attention: analyzing a client target, a client behavior, a contact system function point, a risk point and a risk control point of each stage;
operation journey attention: analyzing an operation target, an operation behavior, a contact system function point, a risk point and a risk control point of each stage;
customer/operation target, customer/operation behavior: the aim is to enable a tester to jump out of a thinking framework of system functions when performing demand analysis and test scene design;
risk point/risk control point: according to the possible problem risks, the test case of the abnormal scene is better improved.
2) Upstream-downstream system relationship diagram (as shown in fig. 2): by taking a certain system as a center, according to the functions of the system, drawing an upstream and downstream related system, namely standing at the view angle of the certain system, identifying the upstream and downstream systems related to different system functions, and laying a foundation for drawing a service full link view.
3) Traffic full link view (as shown in fig. 3): the method takes a service scene as a center, stands at the angles of customers and operation, and draws the flow and related functions of each system on the whole service function link, thereby avoiding the omission of end-to-end test points.
By the method, when a tester designs a test case, a test scene is considered from customer thinking and operation thinking, limitation of system thinking is avoided, understanding of upstream and downstream systems is enhanced through the upstream and downstream relation graph, omission of upstream and downstream interaction scenes is avoided, systems related to a whole service chain are known through a service full link view, and comprehensive coverage of the service chain is ensured.
2. Automated diversity
1) Automatically generating single-interface test data: in order to develop the test as early as possible and find the defect in advance, the interface test is started in the development stage, but the following problems are faced: the abnormal scenes are many (such as empty, overlong characters, illegal characters and the like), the magnitude of the cases is huge after combination, and the full-amount access data coverage is difficult to carry out manually. Such as: the order interface has 76 fields, the workload of manually writing the automatic test script is huge, and the full coverage in the process of writing the automatic test script cannot be ensured. In order to solve the problem, a tool for automatically generating the single-interface test data is developed, and the single-interface test data is automatically generated through preset rules, configured statements and test scenes, so that the positive example data, the negative example data and the abnormal scene data are covered. For the interfaces with more parameter fields, the method greatly improves the efficiency of single-interface testing. The specific steps are as follows:
generating an interface case: editing interface information, interface names, URLs, request modes and the like;
configuring a data model: configuring a piece of forward test data according to the interface parameter template;
presetting a rule: the test scenario for configuring the interface use case comprises the following steps: forward rules, reverse rules, null strings, boundary values, random values, and the like;
and (3) case logic control: some logic controls, assertions and the like commonly used for configuring interface use cases meet the test of more scenes, such as:
border: testing the boundary;
correct: correct input, correct expected output;
error: wrong input, expected output;
design: script test logics such as for, while, do-while and other loops, variable assignment and the like;
generating test data: and automatically generating test data of various scenes meeting the preset rules through the compiled small tools.
2) Automated test data preparation: API automation is mainly developed around ordering rules with the commodity type as latitude. The following difficulties exist in the automatic implementation of the method:
the shopping mall has various different commodity types and complicated commodity configuration, the commodity information data related to each ordering rule has specific requirements, and the stock data cannot meet all business scenes. If the commodity sale starting and ending time is checked, the corresponding attribute of the commodity needs to be frequently changed according to the service scene;
the commodity detail information is obtained from redis by calling an upstream system service interface, is non-real-time, and the test data of the commodity detail information can be modified, so that an instability factor exists;
the downstream system often needs the upstream system to cooperate with the prepared data for testing, and needs to perform sufficient communication and mutual waiting of data requirements, which affects the testing efficiency.
Through in-depth analysis, the technical scheme provides a method for modular design and interface packaging of data preparation. Taking a single-stroke purchase-limited scene under a ticket purchase as an example, the specific implementation method is described as follows:
A. and (3) packaging a commodity information newly-added modification interface in the upstream system redis: the process of processing the redis commodity information of the upstream system is packaged into RESTful API, and then a GUI interface and a document are provided for the RESTful API by combining Swagger. Therefore, all testers can add or modify commodity information in the redis by calling the API to prepare test data.
B. Configuring a piece of commodity information in an upstream system background;
C. configuring a data source according to a single-stroke limited purchase service scene (the single-stroke limited purchase quantity is null, the single-stroke limited purchase quantity is 0, the single-stroke limited purchase quantity < purchase quantity, the single-stroke limited purchase quantity = purchase quantity, and the single-stroke limited purchase quantity > purchase quantity):
the method comprises the following steps: the data source is provided with variables in a dimension configuration by taking columns as the variables, wherein the variables comprise a configuration lower single interface input parameter field, initialization data and an interface return field;
step two: according to a single-limit purchase service scene, a variable configuration request message corresponding to a data source is entered with a parameter field value, a data initialization value and an interface return field value, and a column of data is a service scene;
step three: compiling a script, and carrying out initialization operation on test data according to an initialization field configured in a data source so that the data meets the verification of the current service scene;
step four: and writing a script, calling RESTful API, and modifying the attribute value of the single purchase limit field of the commodity in the redis according to the configuration of the data source.
After the script is compiled, test data preparation can be completed through one-key execution, and then subsequent test execution work is carried out. Except the limited purchase quantity of the commodity single stroke, the service scenes of other commodity attributes can realize automatic one-key coverage by configuring a data source and an automatic script in a similar mode. Through the technical improvement and innovation, the rapid iteration and the capacity improvement of the test service are realized, the threshold and the cost of test data preparation are reduced, the utilization rate and the quality of the test data are improved, and the high-efficiency and high-quality delivery of products is supported.
3) And the UI test automation is utilized, so that the problem of traversing mass store and commodity pain points is solved: the shopping mall relates to the configuration of thousands of shops and commodities, and in order to ensure that the whole configuration information is accurate and correct, customers can normally search the shops and place orders, and traversal tests are required to be performed on all the commodities and the shops. Due to large workload and short scheduling period, the whole test can not be completed manually in a short time. Therefore, the technical scheme provides a UI automation store commodity traversal test:
A. exporting excel from the data of the production store and the commodity information data as data sources;
B. a script step:
reading store information/commodity information in an excel data source;
identifying a page search box, and inputting the store name/commodity name in the read data source in the search box;
click the "search" button;
clicking the searched store/commodity in the searched result list, and entering a detail page;
judging whether the head element text in the detail page contains the searched store name/commodity name;
and continuously circulating until all store information/commodity information in the excel data source is traversed.
Therefore, in this embodiment, the inspection of stores of hundreds of thousands of orders can be completed in 10 hours, and the inspection is performed on the stores/commodities with wrong assertions, which may be the problems of wrong configuration or missing configuration of basic parameters, duplication of store/commodity names, or logic conflicts.
3. Special tests:
1) Special test for special character messy codes: because the number of the associated systems is large, the code characters of the systems are different (UTF-8 and GBK), and if special characters exist in configured shops, brands and names of commodities, the condition that messy codes are displayed at the front end possibly exists, and the customer experience is influenced, the special character test is developed, and the method comprises the following steps:
because of more special characters and incapability of carrying out full-scale verification, a regular expression "\ u4e00- \ u9fa5, a-Z, A-Z,0-9, ] {1, }" is used for screening special character sets contained in store, brand and commodity names configured on production;
for the special characters screened out, e.g.? ×) peripheral () \\ 1236565 &/- ° & () #? Is turned over? B [ 2 ]: peripheral- [ x ]/12365. "shop, brand and commodity name configuration in test environment;
and testing by combining with the page display of the client to detect whether the messy codes exist.
2) Fund special item test: the main functions of the mall are commodity purchase, refund, account checking, bookkeeping and settlement by using different types of coupons, all belong to capital high-risk key business functions, and are multiple in business scenes and complex in calculation rules. The service scenarios related to this embodiment include 121 types:
paying by placing a bill: commodity and coupon use scenes =8 × 10=80, and cost centers and payment modes adopt cross coverage, and the total number is 80;
all refunds: the usage scenes of the commodities and the coupons are crossed and covered, and the total number of the commodities and the coupons is 8+ 10=18;
partial refund: multiple commodities + tickets use scene + cost center + payment mode cross coverage, and total number is 5+10+3+5= 23.
The main contents of the traditional test case template are case names, preconditions, steps and expected results, test cases of all scenes are compiled according to the template, the workload is large, the readability is not high, and the execution efficiency is low. Therefore, the technical scheme provides a fund type test case template:
the scene comprises order payment, all refunds and partial refunds;
enumerating the influence factors of payment amount and clearing amount in the ordering payment and refund scene, such as the type of purchased goods, the quantity of goods, the scene of using tickets, the amount of using tickets, transaction handling fee, service fee, cost center, payment mode and the like;
according to different service scenes, such as the types of purchased commodities, the quantity of the commodities, a cost center, a payment mode, a ticket using scene and the like, different inputs are designed, and the amount to be paid and the clearing amount are calculated;
the input and output of the special test for the amount of money need to be covered: large amount of money scientific counting format, 0 yuan, precision, rounding, unit (yuan/minute).
By the test case template, the readability and the test efficiency of the test case can be improved; in addition, the template can be repeatedly used, manual calculation is not needed for each test, the problem caused by artificial calculation errors is avoided, the test difficulty is reduced, and test result deviation caused by the fact that all parties understand the deviation is avoided.
In conclusion, aiming at internet project products, the technical scheme designs test scenes from different angles, and jumps out of a thinking framework of system functions through analysis of client targets, client behaviors, operation targets and operation behaviors, so that problems can be found as early as possible in a demand analysis stage, the cost of problem repair is reduced, and the quality of on-line products can be more comprehensively guaranteed.
According to the technical scheme, a UI automatic traversal test and rarely-used word messy code test method is provided from the technical perspective, so that operators can be helped to improve operation efficiency, and the product operation quality is guaranteed.
For financial products, the test of capital accounts belongs to high-risk business, the technical scheme provides a special test of capital, and customizes a templating method by enumerating influence factors of amount calculation, so that the test complexity is reduced, and the test efficiency is improved.
For the product of the micro-service framework, the number of micro-services is large, the micro-services are mutually called and coupled through interfaces, and the interface test scene is difficult to cover comprehensively.
According to the technical scheme, the whole process testing process of the internet financial mall is achieved, the tests of the financial service attribute, the internet product operation attribute and the micro-service architecture attribute are covered, the product quality can be ensured, and meanwhile the delivery efficiency is effectively improved.

Claims (10)

1. A method for testing the whole flow of Internet financial business is characterized by comprising the following steps:
s1, respectively constructing a journey graph, an upstream and downstream system relation graph and a service full link view so as to comprehensively cover all test scenes;
s2, automatically acquiring data to be tested from the current test scene based on the modes of data preparation modularization, interface packaging and UI traversal;
and S3, respectively carrying out special character messy code special test and fund special test on the data to be tested, and outputting to obtain a test result.
2. The method for testing the whole flow of the internet financial service according to claim 1, wherein the trip graph in the step S1 includes a customer trip graph and an operation trip graph, the customer trip graph is divided according to the stage of the customer participating in the service, and the operation trip graph is divided according to the stage of the operator developing the service;
the customer trip graph includes customer goals, customer behavior, contact system function points, risk control point information for each phase;
the operation journey graph comprises operation targets, operation behaviors, contact system function points, risk points and risk control point information of each phase.
3. The internet financial service full-process testing method according to claim 1, wherein the construction process of the upstream-downstream relationship graph in the step S1 is as follows: and drawing an upstream and downstream related system by taking the current system as a center and according to the functions of the system.
4. The method for testing the whole process of the internet financial service according to claim 1, wherein the construction process of the service whole link view in the step S1 is as follows: the current service scene is taken as the center, and the flows and related functions of all systems on the whole service function link are drawn respectively from the client and the operation direction, so that the omission of end-to-end test points is avoided.
5. The internet financial transaction full-flow testing method according to claim 1, wherein the step S2 specifically comprises the following steps:
s21, automatically generating single-interface test data through a preset rule, configured sentences and test scenes;
s22, automatically preparing test data by adopting a data preparation modular design and an interface packaging mode;
and S23, traversing the data source to be tested based on a UI test automation mode.
6. The internet financial transaction full-flow testing method according to claim 5, wherein the single-interface test data in step S21 includes positive case data, negative case data and abnormal scenario data.
7. The internet financial transaction full-flow testing method according to claim 5, wherein the step S21 specifically comprises the following steps:
s211, generating an interface use case, including but not limited to editing interface information, an interface name, a URL and a request mode;
s212, configuring a data model: configuring a piece of forward test data according to the interface parameter template;
s214, presetting a rule: configuring a test scenario of an interface use case, including but not limited to a forward rule, a backward rule, a null string, a boundary value and a random value;
s215, case logic control: configuring logic control and assertion corresponding to the interface use case so as to meet the test of more scenes;
s216, generating test data: and automatically generating test data of various scenes meeting the preset rule.
8. The internet financial service full-process testing method according to claim 1, wherein the specific process of the special character messy code special test in the step S3 is as follows:
screening special character sets contained in store, brand and commodity names configured on production through a regular expression '[ \ u4e00- \ u9fa5, a-Z, A-Z,0-9, ] {1, } $';
aiming at the screened special characters, for example: ? X () peripheral angle, { 1236565,% > -), (-) -) - #? Is turned over? B [ 2 ]: peripheral- [ x ]/12365. "+, shop, brand and commodity name configuration is performed in the test environment;
and testing by combining with the page display of the client to detect whether the messy codes exist.
9. The method as claimed in claim 1, wherein the fund-specific test in step S3 is performed by using a set fund-specific test case template.
10. The internet financial transaction full-flow testing method of claim 9, wherein the content of the fund-like test case template comprises:
the scene comprises order payment, total refund and partial refund;
enumerating the influence factors of payment amount and clearing amount in the ordering payment and refund scene;
designing different inputs according to different service scenes, and calculating the amount to be paid and the clearing amount;
and inputting and outputting information by the money special test.
CN202211471173.2A 2022-11-23 2022-11-23 Internet financial business full-process testing method Pending CN115934515A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211471173.2A CN115934515A (en) 2022-11-23 2022-11-23 Internet financial business full-process testing method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211471173.2A CN115934515A (en) 2022-11-23 2022-11-23 Internet financial business full-process testing method

Publications (1)

Publication Number Publication Date
CN115934515A true CN115934515A (en) 2023-04-07

Family

ID=86696866

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211471173.2A Pending CN115934515A (en) 2022-11-23 2022-11-23 Internet financial business full-process testing method

Country Status (1)

Country Link
CN (1) CN115934515A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116822754A (en) * 2023-08-30 2023-09-29 亿家商业科创产业管理(湖北)有限公司 Data specification analysis system based on modularized classification of enterprise service items

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116822754A (en) * 2023-08-30 2023-09-29 亿家商业科创产业管理(湖北)有限公司 Data specification analysis system based on modularized classification of enterprise service items
CN116822754B (en) * 2023-08-30 2023-12-15 亿家商业科创产业管理(湖北)有限公司 Data specification analysis system based on modularized classification of enterprise service items

Similar Documents

Publication Publication Date Title
US11062132B2 (en) System and method for identification of missing data elements in electronic documents
Tewoldeberhan et al. An evaluation and selection methodology for discrete-event simulation software
JP2002163106A (en) Basic business integrated application system, basic business support method, and computer readable storage medium storing program executing the method on computer
US20140019256A1 (en) Selecting advertisement for presentation using previously stored data corresponding to identified customer
CN106845781A (en) The generation system and method for scene and flow for operational trials
CN115934515A (en) Internet financial business full-process testing method
Andriani et al. Designing a Web-Based Inventory Application at General Steel Supplier Using Extreme Programming Method:-
CN114969127B (en) Reconciliation method, reconciliation system and storage medium for automatically combining reconciliation transactions
CN115660607B (en) Automatic generation method and device for approval chain and computer storage medium
CN109219809A (en) The method and system for automatically generating data reporting based on electronic document
KR102382379B1 (en) System and method for providing ai bigdata estimation based on clutch engine
TWI492173B (en) Order system pricing method
Dahiru Design and implementation of an inventory management System for walid halal spices
Lee et al. Quantified benefit of implementing enterprise resource planning through process simulation
Berti et al. Analyzing interconnected processes: using object-centric process mining to analyze procurement processes
Rajagopal et al. Robotic Process Automation: The Key to Reviving the Supply Chain Processes
Syaifudin et al. Point of Sale Framework-Based Code Igniter and Model View Controller Using Lighthouse Testing
Rachmaniah et al. PayPOS user experience improved small and medium sized micro business existence in the disruptive era
Mohan et al. Cloud Based Pos with Online Purchase
Becker et al. Towards a semantic data quality management-using ontologies to assess master data quality in retailing
CN110516195B (en) Financial time vector integrating method and time vector integrator
WO2022074793A1 (en) Data processing device, data processing method, and program
CN109154949A (en) Analysis is provided in real time based on non-structured electronic document
Erdmann et al. On Application Potential of Robotic Process Automation in Small Enterprises.
KR102234130B1 (en) An apparatus and method for managing transaction information providing automatic matching between accounts receivables and deposit information

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination