Financial payment transaction test method based on recording and playback

Abstract

The invention relates to the field of software testing, in particular to a financial payment transaction testing method based on recording and playback. The method comprises the following steps: recording an interaction behavior of a user on a front-end interface, capturing back-end request and response data, generating an original operation sequence, and converting the original operation sequence into a parameterized test script; processing parameter variables in the parameterized test script through a dynamic test data generation algorithm, generating test parameters, and further obtaining a dynamic test parameter set; executing an operation instruction based on the parameterized test script and the dynamic test parameter set, and recording actual output; a verification result is generated for the test parameter based on the actual output, and an overall pass rate of the automated test is calculated. The problems that a traditional software test method depends on manual design of test cases and manual test execution, time consumption is long, efficiency is low, and key test scenes are prone to being omitted are solved; all input conditions and abnormal scenes are difficult to cover; a unified automatic process is lacked, and the test process is difficult to reuse.

Description

Technical Field

[0001] The present invention relates to the field of software testing, and particularly to a financial payment transaction testing method based on recording and playback. Background Art

[0002] With the increasing complexity of financial payment systems, especially the rapid development of mobile payment and online payment, ensuring the functional correctness, performance stability, and compatibility of the system has become increasingly important. Traditional manual testing methods usually require a large amount of manpower and time to verify various transaction scenarios, and cannot effectively cover complex factors such as different payment paths, abnormal situations, and system loads, making the testing process not only cumbersome but also prone to missing potential problems.

[0003] To improve testing efficiency and coverage, modern financial payment systems increasingly tend to use automated testing technologies to simulate real user operations; the key advantage of automated testing is that it can significantly improve testing efficiency and maintain stable test coverage under high-frequency business requirement changes. Operations such as user clicks, form filling, and page jumps can be accurately recorded and converted into scripts, ensuring that the same transaction behavior can be reproduced every time during playback. Using this technology, testers can not only efficiently execute conventional transaction scenario verifications but also verify the fault tolerance and exception handling mechanisms of the system by simulating abnormal scenarios (such as payment failures, timeouts, limits, etc.).

[0004] In traditional software testing, especially in complex systems involving front-end interactions and back-end requests (such as financial payment systems), there are also the following problems: relying on manual design of test cases and manual execution of tests, resulting in long time consumption, low efficiency, and being prone to missing key test scenarios due to human negligence; it is difficult to cover all possible input conditions and abnormal scenarios; test cases for different input conditions often need to be designed and executed separately, lacking a unified automated process, making it difficult to reuse or extend the testing process to new scenarios. Summary of the Invention

[0005] The present invention provides a financial payment transaction testing method based on recording and playback to solve the technical problems of traditional software testing methods that rely on manual design of test cases and manual execution of tests, resulting in long time consumption, low efficiency, and being prone to missing key test scenarios due to human negligence; it is difficult to cover all possible input conditions and abnormal scenarios; test cases for different input conditions often need to be designed and executed separately, lacking a unified automated process, making it difficult to reuse or extend the testing process to new scenarios.

[0006] A financial payment transaction testing method based on recording and playback of the present invention specifically includes the following technical solutions: A financial payment transaction testing method based on recording and playback, comprising the following steps: S1. Record the interaction behavior of the user on the front-end interface, capture the backend requests and response data, and generate an original operation sequence; convert the original operation sequence into a parameterized test script; S2. Process the parameter variables in the parameterized test script through a dynamic test data generation algorithm to generate test parameters; combine the test parameters to obtain a dynamic test parameter set; S3. Based on the parameterized test script and the dynamic test parameter set, execute the operation instructions and record the actual output; based on the actual output, generate verification results for the test parameters in the dynamic test parameter set, and calculate the overall pass rate of the automated test.

[0007] Preferably, the S1 specifically includes: Record the interaction behavior of the user on the front-end interface through a recording tool, and capture the backend requests and response data through a proxy server to generate an original operation sequence; the elements in the original operation sequence consist of operations and corresponding parameter sets.

[0008] Preferably, the S1 specifically includes: Map the backend requests in the original operation sequence to a standardized HTTP request template through an automated test tool, and extract the corresponding parameter set as a parameter variable set to generate a parameterized test script.

[0009] Preferably, the S2 specifically includes: The dynamic test data generation algorithm extracts parameter variables from the input parameterized test script, introduces a non-linear amplification coefficient, combines it with an abnormal rule value, and non-linearly adjusts the parameter variables through exponential calculation.

[0010] Preferably, the S2 specifically includes: The dynamic test data generation algorithm, on the basis of non-linearly adjusting the parameter variables, introduces a random perturbation term to generate test parameters, and combines the test parameters to obtain a dynamic test parameter set.

[0011] Preferably, the S3 specifically includes: For each operation instruction in the parameterized test script, select the test parameter corresponding to the operation instruction from the dynamic test parameter set, embed it into the request body of the operation instruction, and send the request body to the server through the HTTP protocol to simulate a real payment transaction request.

[0012] Preferably, the S3 specifically includes: Receive the actual response returned by the server after processing the request through the automated testing tool, and record the actual output; compare the actual output with the predefined expected output to generate verification results for each test parameter.

[0013] Preferably, the step S3 specifically includes: Traverse and accumulate all the verification results item by item to obtain the overall passing rate of the automated test.

[0014] The beneficial effects of the technical solution of the present invention are as follows:

[0015] 1. From manual recording operations to automated generation of the original sequence, and then to script conversion, it reduces the time and complexity of manually writing test scripts, improves the test preparation efficiency. The parameterized test script supports dynamic adjustment of parameters, solves the problem that static recording cannot be reused, makes the test script applicable to multiple scenarios (such as different payment amounts, user IDs), and enhances the adaptability of the test.

[0016] 2. Introduce a dynamic test data generation algorithm to process the parameter variables in the parameterized test script. Through non-linear adjustment and random perturbation, automatically generate diverse test parameters (such as normal payment amounts, extremely large amounts, illegal inputs), covering edge cases that are difficult to design in traditional testing, reducing the risk of missing key defects. The introduction of the random perturbation term simulates the complex and changeable operating conditions in reality, making the test closer to real user behavior, improving the reference value of the test results, and automatically generating diverse parameters without the need for manual design of test cases one by one, saving time and labor costs.

[0017] 3. Automated execution and result comparison replace manual verification, avoiding inefficiency and human errors, significantly shortening the test cycle. The calculation of the overall passing rate provides an intuitive indicator to help developers and testers quickly evaluate the system stability and promote the continuous improvement of software quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a flowchart of a financial payment transaction test method based on recording and playback according to the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0019] In order to further elaborate on the technical means and effects adopted by the present invention to achieve the predetermined invention purpose, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the technical field to which this invention belongs.

[0021] The following specifically describes the specific solution of a financial payment transaction testing method based on recording and playback provided by the present invention in conjunction with the accompanying drawings.

[0022] Refer to the attached Figure 1 , which shows a flowchart of a financial payment transaction testing method based on recording and playback provided by an embodiment of the present invention. The method includes the following steps: S1. Record the interaction behavior of the user on the front-end interface, capture the back-end request and response data, and generate an original operation sequence; convert the original operation sequence into a parameterized test script;

[0023] Use the recording tool Selenium IDE to record the interaction behavior of the user on the front-end interface (web page or mobile application), including click events, form filling, and page jumps. At the same time, use the proxy server Charles to capture the back-end request and response data related to the operation, including the request header (such as Content-Type), the request body (such as the payment amount and user ID), the response status code (such as 200 indicating success), and the response content (such as the payment success prompt), to generate an original operation sequence including front-end and back-end interactions; each element in the original operation sequence consists of an operation and a corresponding parameter set; the parameter set is used to record the specific data related to the operation, and its content includes but is not limited to front-end interaction data, back-end request and response data.

[0024] The original operation sequence is expressed as follows:

[0025] where represents the th operation, which is used to record a specific operation, such as "click the payment button" or "submit a payment request", providing a basis for subsequent script conversion; represents the parameter set of the th operation, which can be an empty set or a key-value pair set; represents the total number of operations in the original operation sequence, which is the actual number of operations counted by the recording tool;

[0026] Since the backend requests recorded in the original operation sequence are static and cannot be directly used for automated testing, in order to achieve repeatable execution and parameterized adjustment, an automated testing tool (such as JMeter) is used to map the backend requests (such as "submit payment request") in the original operation sequence into a standardized HTTP request template, extract the parameter set and mark it as a dynamically adjustable parameter variable set, and generate a parameterized test script; the frontend operation is only used as a recording reference and no executable instructions are generated;

[0027] Parameterized test scripts The expression is as follows:

[0028] in, Indicates that the mapping rule From Operations The converted An operation instruction, which defines a specific HTTP request operation, is a command that can be executed by automated testing tools (such as JMeter), such as "Submit payment request" is converted to "POST / pay"; Represents a mapping rule, which is the logic used by automated testing tools (such as JMeter) to parse the original operation sequence into a parameterized test script; Indicates A set of parameter variables for each operation instruction, which is used to preserve the variability of parameters and support subsequent dynamic adjustment;

[0029] By converting the original operation sequence into a parameterized test script, the test process is transformed from static recording to dynamic execution. The parameterized test script can adjust parameters as needed to simulate different input conditions (such as normal payment, oversized payment or illegal input), thereby covering different test scenarios.

[0030] S2. Processing parameter variables in the parameterized test script by a dynamic test data generation algorithm to generate test parameters; combining the test parameters to obtain a dynamic test parameter set;

[0031] The parameter variables in the parameterized test script are processed by a dynamic test data generation algorithm to generate test parameters, and the test parameters are combined to obtain a dynamic test parameter set;

[0032] The dynamic test data generation algorithm is based on the random test theory. It extracts the parameter variables to be processed from the input parameterized test script and introduces an exception rule value to control the adjustment direction and amplitude of the parameter variables. The exception rule value is a predefined range between -1 and 1, which is used to simulate different transaction scenarios, such as the situation of increasing or decreasing the amount. To achieve non-linear changes, a non-linear amplification coefficient is introduced, with a value range between 0 and 2. It is combined with the exception rule value and used to amplify or reduce the influence of the parameter variables through exponential calculation. Through non-linear adjustment, the complexity of the amount change in reality can be simulated, such as a small increase or a large decrease.

[0033] To further increase the diversity and unpredictability of the parameter variables, a random perturbation term is superimposed on the basis of non-linear adjustment. The amplitude of the perturbation is controlled by the random perturbation coefficient, and the perturbation direction is determined by a random function. The specific implementation formula of the dynamic test data generation algorithm is:

[0034] where, represents the test parameter generated by the th operation instruction using the th exception rule value; represents the value of the th parameter variable of the th operation instruction; represents the exponential function for non-linear adjustment; represents the non-linear amplification coefficient, with a range of , which is used to control the adjustment amplitude and can be specifically set according to the specific implementation scenario and is not limited here; represents the th exception rule value, with a range of , which is used to control the adjustment direction and amplitude of the parameter variables and can be specifically set according to the specific implementation scenario and is not limited here; represents the random perturbation term; represents the random perturbation coefficient, whose dimension is unified with , and the range is , which is used to control the random perturbation amplitude and can be specifically set according to the specific implementation scenario and is not limited here; represents the random function, which returns a uniformly distributed value between , and is used to introduce unpredictability;

[0035] The dynamic test data generation algorithm improves test coverage. By automatically generating diverse parameters, it covers regular transactions, abnormal transactions, and edge scenarios, reducing the risk of missing key issues, enhancing test efficiency, eliminating the need for manual design of test cases one by one, saving time and labor costs. The introduction of random perturbations enhances the authenticity and unpredictability of the parameters, making the test results more valuable for reference;

[0036] S3. Based on the parameterized test script and the dynamic test parameter set, execute the operation instructions and record the actual output; Based on the actual output, generate verification results for the test parameters in the dynamic test parameter set and calculate the overall pass rate of the automated test;

[0037] Based on the parameterized test script and the dynamic test parameter set, use an automated test tool (such as JMeter) to execute the operation instructions one by one; Specifically, for each operation instruction, select the corresponding test parameter from the dynamic test parameter set and embed it into the request body of the operation instruction, and send the request body to the server via the HTTP protocol to simulate a real payment transaction request;

[0038] After the server processes the request, it will return an actual response, such as "Payment successful" or "Amount exceeded error". Receive the response through an automated test tool (such as JMeter) and record the actual output;

[0039] To ensure the correctness of the system behavior, it is necessary to compare the actual output with the predefined expected output; The expected output is preset according to the nature of the test parameters: For example, for regular amounts, the expected output may be "Payment successful"; For abnormal amounts, the expected output may be "Amount invalid error"; Generate verification results for each test parameter based on the comparison result: If the actual output is exactly the same as the expected output, the verification result is marked as "Pass", and if there is any inconsistency, it is marked as "Fail";

[0040] Verification result generation formula:

[0041] where, represents the verification result of the test parameter generated by the th operation instruction using the th abnormal rule value. 1 indicates pass, and 0 indicates fail; represents the th operation instruction using the th abnormal rule value to generate the actual output after executing the th operation instruction; represents the equality comparison operator; represents the th operation instruction using the The test parameters generated by an abnormal rule value for the expected output after executing the th operation instruction;

[0042] Traverse and accumulate all verification results item by item to obtain the overall pass rate of the automated test. The calculation formula is:

[0043] Among them, represents the overall pass rate of the automated test, and the value range is from 0 to 1; represents the double summation, calculating the total number of passed test times; represents the total number of operation instructions multiplied by the number of test parameters for each operation instruction which is the total number of tests;

[0044] By executing the operation instructions one by one through the automated test tool and performing comparison and verification, the test efficiency is improved, the inefficiency and errors of manual statistics are avoided, the time cost is saved, and the defects of the financial payment system are revealed by quantifying the overall pass rate of the automated test, so as to promote the quality assurance and technological progress of the financial payment system.

[0045] In summary, a financial payment transaction test method based on recording and playback is completed.

[0046] The sequence of the invention embodiments is only for description and does not represent the superiority or inferiority of the embodiments. The processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0047] Each embodiment in this specification is described in a progressive manner. For the same or similar parts between each embodiment, reference can be made to each other. Each embodiment focuses on the differences from other embodiments.

[0048] The above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of each embodiment of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A financial payment transaction testing method based on recording and playback, characterized in that It includes the following steps: S1. Record the user's interaction behavior on the front-end interface, capture the backend request and response data, and generate the original operation sequence; convert the original operation sequence into a parameterized test script; S2. Process the parameter variables in the parameterized test script through a dynamic test data generation algorithm to generate test parameters; Combine the test parameters to obtain a dynamic test parameter set; S3. Based on the parameterized test script and the dynamic test parameter set, execute the operation instructions and record the actual output; Based on the actual output, generate verification results for the test parameters in the dynamic test parameter set and calculate the overall pass rate of the automated test.

2. The method for testing financial payment transactions based on recording and playback according to claim 1, wherein The S1 specifically includes: Record the user's interaction behavior on the front-end interface through a recording tool, and capture the backend request and response data through a proxy server to generate the original operation sequence; the elements in the original operation sequence are composed of operations and the corresponding parameter sets.

3. The method for testing financial payment transactions based on recording and playback according to claim 2, wherein The S1 specifically includes: Map the backend requests in the original operation sequence to standardized HTTP request templates through an automated test tool, and extract the corresponding parameter sets as parameter variable sets to generate a parameterized test script.

4. A method for testing financial payment transactions based on recording and playback according to claim 1, characterized in that The S2 specifically includes: The dynamic test data generation algorithm extracts parameter variables from the input parameterized test script, introduces a non-linear amplification coefficient, combines it with the abnormal rule value, and non-linearly adjusts the parameter variables through exponential calculation.

5. The method for testing financial payment transactions based on recording and playback according to claim 4, wherein The S2 specifically includes: The dynamic test data generation algorithm, on the basis of non-linearly adjusting the parameter variables, introduces a random perturbation term, generates test parameters, and combines the test parameters to obtain a dynamic test parameter set.

6. The method for testing financial payment transactions based on recording and playback according to claim 1, characterized in that, The S3 specifically includes: For each operation instruction in the parameterized test script, select the test parameter corresponding to the operation instruction from the dynamic test parameter set and embed it into the request body of the operation instruction, and send the request body to the server through the HTTP protocol to simulate a real payment transaction request.

7. A method for testing financial payment transactions based on recording and playback according to claim 6, characterized in that, The S3 specifically includes: Receive the actual response returned by the server after processing the request through an automated test tool and record the actual output; compare the actual output with the predefined expected output to generate verification results for each test parameter.

8. A method for testing financial payment transactions based on recording and playback according to claim 7, characterized in that, The S3 specifically includes: Traverse and accumulate all the verification results item by item to obtain the overall pass rate of the automated test.

Images