A financial payment transaction testing method based on recording and playback

Abstract

The present invention relates to the field of software testing, and in particular to a method for testing financial payment transactions based on recording and playback. The method includes: recording user interaction 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 using a dynamic test data generation algorithm to generate test parameters, thereby obtaining a dynamic test parameter set; executing operation instructions based on the parameterized test script and the dynamic test parameter set, and recording actual output; generating verification results for the test parameters based on the actual output, and calculating the overall pass rate of the automated test. This method solves the problems of traditional software testing methods, which rely on manually designed test cases and manual test execution, which are time-consuming, inefficient, and prone to missing key test scenarios; are difficult to cover all input conditions and abnormal scenarios; and lack a unified automated process, making the test process difficult to reuse.

Description

Technical Field

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

[0002] With the increasing complexity of financial payment systems, especially with the rapid development of mobile and online payments, ensuring system functional correctness, performance stability, and compatibility has become increasingly important. Traditional manual testing methods typically require significant manpower and time to verify various transaction scenarios. They also fail to effectively account for complex factors such as different payment paths, anomalies, and system load, making the testing process not only cumbersome but also prone to missing potential issues.

[0003] To improve testing efficiency and coverage, modern financial payment systems are increasingly using automated testing technology 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 changes in business needs. For example, user clicks, form filling, page jumps, and other operations can be accurately recorded and converted into scripts, ensuring that the same transaction behavior can be reproduced each time it is replayed. Using this technology, testers can not only efficiently perform routine transaction scenario verification, but also verify the system's fault tolerance and exception handling mechanism by simulating abnormal scenarios (such as payment failures, timeouts, limits, etc.).

[0004] In traditional software testing, especially when it comes to complex systems involving front-end interactions and back-end requests (such as financial payment systems), the following problems still exist: reliance on manual design of test cases and manual execution of tests results in a long time, low efficiency, and the possibility of 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, and the lack of a unified automated process makes it difficult to reuse the test process or expand it 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 that traditional software testing methods rely on manually designed test cases and manual test execution, which is time-consuming, inefficient, and 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, and there is a lack of a unified automated process, which makes it difficult to reuse or expand the testing process to new scenarios.

[0006] The present invention provides a financial payment transaction testing method based on recording and playback, which specifically includes the following technical solutions:

[0007] A financial payment transaction testing method based on recording and playback includes the following steps:

[0008] S1. Record user interaction on the front-end interface and capture back-end request and response data to generate the original operation sequence; convert the original operation sequence into a parameterized test script;

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

[0010] 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.

[0011] Preferably, the S1 specifically includes:

[0012] The user's interactive behavior on the front-end interface is recorded through a recording tool, and the back-end request and response data are captured through a proxy server to generate an original operation sequence; the elements in the original operation sequence are composed of operations and parameter sets corresponding to the operations.

[0013] Preferably, the S1 specifically includes:

[0014] The automated testing tool maps the backend requests in the original operation sequence into a standardized HTTP request template, extracts the corresponding parameter set as a parameter variable set, and generates a parameterized test script.

[0015] Preferably, the S2 specifically includes:

[0016] The dynamic test data generation algorithm extracts parameter variables from the input parameterized test script, introduces a nonlinear amplification coefficient, and combines it with the abnormal rule value to perform nonlinear adjustment on the parameter variables through exponential calculation.

[0017] Preferably, the S2 specifically includes:

[0018] The dynamic test data generation algorithm introduces random disturbance terms on the basis of nonlinear adjustment of parameter variables to generate test parameters, and combines the test parameters to obtain a dynamic test parameter set.

[0019] Preferably, the S3 specifically includes:

[0020] For each operation instruction in the parameterized test script, the test parameters corresponding to the operation instruction are selected from the dynamic test parameter set and embedded into the request body of the operation instruction. The request body is sent to the server via the HTTP protocol to simulate a real payment transaction request.

[0021] Preferably, the S3 specifically includes:

[0022] The automated testing tool receives the actual response returned by the server after processing the request and records the actual output; compares the actual output with the pre-defined expected output to generate a verification result for each test parameter.

[0023] Preferably, the S3 specifically includes:

[0024] All verification results are traversed and accumulated one by one to obtain the overall pass rate of the automated test.

[0025] The beneficial effects of the technical solution of the present invention are:

[0026] 1. From manual recording of operations to automated generation of original sequences and then to script conversion, the time and complexity of manually writing test scripts are reduced, and test preparation efficiency is improved. Parameterized test scripts support dynamic parameter adjustment, solving the problem of static records being unable to be reused, making test scripts applicable to a variety of scenarios (such as different payment amounts and user IDs), and enhancing test adaptability.

[0027] 2. A dynamic test data generation algorithm is introduced to process parameter variables in parameterized test scripts. Through nonlinear adjustment and random perturbations, diversified test parameters (such as normal payment amounts, oversized amounts, and illegal inputs) are automatically generated. This covers edge cases that are difficult to design for traditional tests and reduces the risk of missing key defects. The introduction of random perturbation items simulates complex and changeable operating conditions in reality, making the test closer to real user behavior and improving the reference value of the test results. There is no need to manually design test cases one by one, and diversified parameters are automatically generated, saving time and labor costs.

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

[0029] Figure 1 This is a flow chart of a financial payment transaction testing method based on recording and playback described in the present invention. DETAILED DESCRIPTION

[0030] In order to further illustrate the technical means and effects adopted by the present invention to achieve the predetermined purpose of the invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

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

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

[0033] Refer to the attached Figure 1 , which shows a flow chart of a financial payment transaction testing method based on recording and playback provided by one embodiment of the present invention, the method comprising the following steps:

[0034] S1. Record user interaction on the front-end interface and capture back-end request and response data to generate the original operation sequence; convert the original operation sequence into a parameterized test script;

[0035] Use the recording tool Selenium IDE to record user interactions on the front-end interface (webpage or mobile application), including click events, form filling, and page jumps. At the same time, use the proxy server Charles to capture back-end request and response data related to the operation, including request headers (such as Content-Type), request bodies (such as payment amount and user ID), response status codes (such as 200 for success), and response content (such as payment success prompts). Generate a raw operation sequence that includes front-end and back-end interactions. Each element in the raw operation sequence consists of an operation and a corresponding parameter set. The parameter set is used to record specific data related to the operation, including but not limited to front-end interaction data and back-end request and response data.

[0036] Original operation sequence The expression is as follows:

[0037]

[0038] in, Indicates the An operation is used to record specific operations, such as "clicking the payment button" or "submitting a payment request", to provide a basis for subsequent script conversion; Indicates the The parameter set of an operation, which can be an empty set or a key-value pair set; Indicates the total number of operations in the original operation sequence, which is the actual number of operations counted by the recording tool;

[0039] Because the backend requests recorded in the original operation sequence are static and cannot be directly used for automated testing, to achieve repeatable execution and parameterized adjustment, an automated testing tool (such as JMeter) is used to map the backend requests in the original operation sequence (such as "Submit Payment Request") to a standardized HTTP request template. The parameter set is extracted and marked as a dynamically adjustable parameter variable set to generate a parameterized test script. The frontend operations are only used as a recording reference and no executable instructions are generated.

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

[0041]

[0042] in, Indicates that the mapping rule From Operations The converted generated An operation instruction, which defines a specific HTTP request operation and 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 the A set of parameter variables for each operation instruction, used to preserve the variability of parameters and support subsequent dynamic adjustments;

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

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

[0045] Processing parameter variables in parameterized test scripts through dynamic test data generation algorithms to generate test parameters, and combining the test parameters to obtain a dynamic test parameter set;

[0046] The dynamic test data generation algorithm, based on random testing theory, extracts parameter variables to be processed from the input parameterized test script and introduces exception rule values ​​to control the adjustment direction and amplitude of the parameter variables. The exception rule value is a predefined range between -1 and 1, used to simulate different transaction scenarios, such as an increase or decrease in the amount of money. To achieve nonlinear changes, a nonlinear amplification factor is introduced, with a value between 0 and 2. This factor is combined with the exception rule value to exponentially amplify or reduce the impact of the parameter variables. This nonlinear adjustment can simulate the complexity of real-world changes in amount of money, such as small increases or large decreases.

[0047] In order to further increase the diversity and unpredictability of parameter variables, a random disturbance term is superimposed on the basis of nonlinear adjustment. The amplitude of the disturbance is controlled by the random disturbance coefficient, and the disturbance direction is determined by a random function. The specific implementation formula of the dynamic test data generation algorithm is:

[0048]

[0049] in, Indicates the The operation instruction uses Test parameters generated by abnormal rule values; Indicates the The first operation instruction The value of the parameter variable; Represents an exponential function, used for nonlinear adjustment; Represents the nonlinear amplification factor, ranging from , used to control the adjustment range, which can be set according to the specific implementation scenario and is not limited here; Indicates the Exception rule values, range , used to control the adjustment direction and amplitude of parameter variables, which can be set according to the specific implementation scenario and is not limited here; represents the random disturbance term; represents the random perturbation coefficient, dimension and Keep it unified, the range is , used to control the amplitude of random disturbance, which can be set according to the specific implementation scenario and is not limited here; Represents a random function that returns Uniformly distributed values ​​between , used to introduce unpredictability;

[0050] The dynamic test data generation algorithm improves test coverage by automatically generating diverse parameters to cover regular transactions, abnormal transactions, and edge scenarios, reducing the risk of missing key issues and improving testing efficiency. It eliminates the need to manually design test cases one by one, saving time and labor costs. The introduction of random perturbations enhances the authenticity and unpredictability of parameters, making test results more valuable.

[0051] 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;

[0052] Based on parameterized test scripts and dynamic test parameter sets, automated testing tools (such as JMeter) execute operation instructions one by one. Specifically, for each operation instruction, the corresponding test parameters are selected from the dynamic test parameter set and embedded into the request body of the operation instruction. The request body is then sent to the server via the HTTP protocol to simulate a real payment transaction request.

[0053] After processing the request, the server returns an actual response, such as "Payment successful" or "Amount exceeded error." Automated testing tools (such as JMeter) receive the response and record the actual output.

[0054] To ensure the correctness of system behavior, the actual output needs to be compared with a predefined expected output. The expected output is preset based on the nature of the test parameter. For example, for a normal amount, the expected output might be "Payment Successful"; for an abnormal amount, the expected output might be "Amount Invalid Error". Based on the comparison results, a verification result is generated for each test parameter: if the actual output is completely consistent with the expected output, the verification result is marked as "Passed"; if there is any inconsistency, it is marked as "Failed".

[0055] Verification result generation formula:

[0056]

[0057] in, Indicates the The operation instruction uses The verification result of the test parameter generated by the exception rule value, 1 means pass, 0 means fail; Indicates the The operation instruction uses The test parameters generated by the exception rule value are executed in the The actual output after an operation instruction; Represents the equality comparison operator; Indicates the The operation instruction uses The test parameters generated by the exception rule value are executed in the The expected output after the operation instruction;

[0058] All verification results are traversed and accumulated one by one to obtain the overall pass rate of the automated test. The calculation formula is:

[0059]

[0060] in, Indicates the overall pass rate of automated testing, with a value range of 0 to 1; Represents double summation, calculating the total number of passed tests; Indicates the total number of operation instructions The number of test parameters for each operation instruction The product of is the total number of tests;

[0061] By using automated testing tools to execute operation instructions one by one and conduct comparative verification, testing efficiency is improved, the inefficiency and errors of manual statistics are avoided, time costs are saved, and the defects of the financial payment system are revealed by quantifying the overall pass rate of automated testing, thereby promoting the quality assurance and technological advancement of the financial payment system.

[0062] In summary, a financial payment transaction testing method based on recording and playback has been completed.

[0063] The order in which the embodiments of the invention are presented is for illustrative purposes only and does not necessarily represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0064] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments.

[0065] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A financial payment transaction testing method based on recording and playback, characterized in that: The following steps are involved: S1. Record user interaction on the front-end interface and capture back-end request and response data to generate the original operation sequence; convert the original operation sequence into a parameterized test script; S2. Processing parameter variables in the parameterized test script through a dynamic test data generation algorithm; In the implementation of the dynamic test data generation algorithm, nonlinear amplification coefficients and abnormal rule values ​​are introduced to perform nonlinear adjustment on parameter variables through exponential calculation. At the same time, random disturbance terms are introduced, the amplitude of the disturbance is controlled by the random disturbance coefficient, and the disturbance direction is determined by a random function to generate test parameters. The test parameters are combined to obtain a dynamic test parameter set. S3. Based on the parameterized test script and 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. A financial payment transaction testing method based on recording and playback according to claim 1, characterized in that: Said S1 specifically includes: The user's interactive behavior on the front-end interface is recorded through a recording tool, and the back-end request and response data are captured through a proxy server to generate an original operation sequence; the elements in the original operation sequence are composed of operations and parameter sets corresponding to the operations.

3. A financial payment transaction testing method based on recording and playback according to claim 2, characterized in that: Said S1 specifically includes: The automated testing tool maps the backend requests in the original operation sequence into a standardized HTTP request template, extracts the corresponding parameter set as a parameter variable set, and generates a parameterized test script.

4. The financial payment transaction testing method based on recording and playback according to claim 1 is characterized in that: Said S3 specifically includes: For each operation instruction in the parameterized test script, the test parameters corresponding to the operation instruction are selected from the dynamic test parameter set and embedded into the request body of the operation instruction. The request body is sent to the server via the HTTP protocol to simulate a real payment transaction request.

5. A financial payment transaction testing method based on recording and playback according to claim 4, characterized in that: Said S3 specifically includes: The automated testing tool receives the actual response returned by the server after processing the request and records the actual output; compares the actual output with the pre-defined expected output to generate a verification result for each test parameter.

6. A financial payment transaction testing method based on recording and playback according to claim 5, characterized in that: Said S3 specifically includes: All verification results are traversed and accumulated one by one to obtain the overall pass rate of the automated test.

Images