CN117493156A

CN117493156A - Payment system testing method and device, electronic equipment and readable storage medium

Info

Publication number: CN117493156A
Application number: CN202310746351.6A
Authority: CN
Inventors: 王爽; 赵国庆; 吴鹏; 蒋宁; 罗展松
Original assignee: Mashang Xiaofei Finance Co Ltd
Current assignee: Mashang Xiaofei Finance Co Ltd
Priority date: 2023-06-21
Filing date: 2023-06-21
Publication date: 2024-02-02

Abstract

The disclosure provides a testing method and device of a payment system, electronic equipment and a readable storage medium, which are used for improving testing efficiency and accuracy. The method comprises the following steps: acquiring payment test parameters; wherein the payment test parameters include: a payment object parameter, and a payment status parameter; generating virtual user information corresponding to the payment object parameters, and sending a payment test request containing the payment object parameters and the virtual user information to a payment system; under the condition that the payment system passes the verification of the payment test request, state feedback information is sent to the payment system according to the payment state parameters; the payment system is used for updating the payment data table according to the payment state parameters contained in the state feedback information; generating a test abnormality notification message under the condition that the data value in the updated payment data table is not matched with a preset standard value; the preset standard value is determined according to the payment object parameter and the payment state parameter.

Description

Payment system testing method and device, electronic equipment and readable storage medium

Technical Field

The disclosure relates to the technical field of testing, and in particular relates to a testing method and device of a payment system, electronic equipment and a readable storage medium.

Background

A payment system is a set of systems for providing financial services. With the increasing development of the internet and the popularization of electronic payment, the payment system can realize various financial related operations such as commodity payment, borrowing, repayment and the like in an online mode. Typically, the payment system interfaces not only with the user's end to provide financial services to the user, but also with a third party financial institution (i.e., payment channel) to achieve synchronization of financial data with the third party financial institution.

Since the payment system involves a large number of business processes, in order to ensure the reliability of the payment system, the payment system needs to be verified in advance. In the related art, it is often necessary to manually create a test order by a test user in order to verify the accuracy of the payment system by means of the test order.

However, the manner in which the test order is manually created is time consuming, labor consuming, and error prone. Moreover, the payment state of the manually created test order is difficult to predict, and various types of payment states cannot be covered, so that the test process is difficult to comprehensively verify whether the processing flow of the payment system for the various types of payment states is correct. Therefore, a more efficient and accurate test method is needed.

Disclosure of Invention

The disclosure provides a testing method and device of a payment system, electronic equipment and a readable storage medium, which are used for improving testing efficiency and accuracy.

In a first aspect, the present disclosure provides a method for testing a payment system, comprising the steps of:

acquiring received payment test parameters; wherein the payment test parameters include: a payment object parameter, and a payment status parameter;

generating virtual user information corresponding to the payment object parameters, and sending a payment test request containing the payment object parameters and the virtual user information to the payment system;

sending state feedback information to the payment system according to the payment state parameters under the condition that the payment system verifies the payment test request; the payment system is used for updating a payment data table according to the payment state parameters contained in the state feedback information;

generating a test abnormality notification message under the condition that the data value in the updated payment data table is not matched with a preset standard value; the preset standard value is determined according to the payment object parameter and the payment state parameter.

In a second aspect, the present disclosure provides a testing device for a payment system, comprising:

the acquisition module is suitable for acquiring the received payment test parameters; wherein the payment test parameters include: a payment object parameter, and a payment status parameter;

the generation module is suitable for generating virtual user information corresponding to the payment object parameters and sending a payment test request containing the payment object parameters and the virtual user information to the payment system;

the sending module is suitable for sending state feedback information to the payment system according to the payment state parameters under the condition that the payment system verifies the payment test request; the payment system is used for updating a payment data table according to the payment state parameters contained in the state feedback information;

the notification module is suitable for generating a test abnormality notification message under the condition that the data value in the updated payment data table is not matched with a preset standard value; the preset standard value is determined according to the payment object parameter and the payment state parameter.

In a third aspect, the present disclosure provides an electronic device comprising: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, one or more of the computer programs being executable by the at least one processor to enable the at least one processor to perform the above-described method.

In a fourth aspect, the present disclosure provides a computer readable storage medium having stored thereon a computer program, wherein the computer program when executed by a processor/processing core implements the above-described method.

In an embodiment provided by the present disclosure, first, a received payment test parameter is obtained, where the payment test parameter includes a payment object parameter and a payment status parameter; then, generating virtual user information corresponding to the payment object parameters, sending a payment test request containing the payment object parameters and the virtual user information to a payment system, and sending state feedback information to the payment system according to the payment state parameters under the condition that a verification passing message is received; and finally, under the condition that the data value in the updated payment data table is not matched with the preset standard value, generating a test abnormality notification message. Therefore, in the mode, on one hand, virtual user information can be automatically generated according to the received payment test parameters, manual creation of a user is not needed, and the test efficiency is improved; on the other hand, the state feedback information sent by the third party payment channel can be simulated according to the payment state parameters contained in the payment test parameters, so that the payment system updates the payment data table according to the state feedback information, and accordingly, whether the function of the payment system is abnormal can be judged by matching the updated payment data table with a preset standard value. The parameter values of the payment state parameters can be flexibly adjusted, so that various payment states (such as successful payment, failure payment and the like) can be flexibly configured, and the accuracy of the payment system in processing various payment states can be comprehensively verified.

It should be understood that the description in this section is not intended to identify key or critical features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following specification.

Drawings

The accompanying drawings are included to provide a further understanding of the disclosure, and are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the description serve to explain the disclosure, without limitation to the disclosure. The above and other features and advantages will become more readily apparent to those skilled in the art by describing in detail exemplary embodiments with reference to the attached drawings, in which:

FIG. 1 is a flow chart of a method of testing a payment system provided in one embodiment of the present disclosure;

FIG. 2 shows a flow diagram of one specific example of a testing method of the payment system of the present application;

FIG. 3 shows a flow diagram of some technical details in one specific example of a testing method of the payment system of the present application;

FIG. 4 is a block diagram of a testing device of a payment system provided by an embodiment of the present disclosure;

fig. 5 is a block diagram of an electronic device according to an embodiment of the present disclosure.

Detailed Description

For a better understanding of the technical solutions of the present disclosure, exemplary embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which various details of the embodiments of the present disclosure are included to facilitate understanding, and they should be considered as merely exemplary. Accordingly, one of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Embodiments of the disclosure and features of embodiments may be combined with each other without conflict.

As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The terms "connected" or "connected," and the like, are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

The method for testing the payment system according to the embodiments of the present disclosure may be performed by an electronic device such as a terminal device or a server, where the terminal device may be a vehicle-mounted device, a User Equipment (UE), a mobile device, a User terminal, a cellular phone, a cordless phone, a personal digital assistant (Personal Digital Assistant, PDA), a handheld device, a computing device, a vehicle-mounted device, a wearable device, or the like; the server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing cloud computing service. The method may in particular be implemented by means of a processor calling a computer program stored in a memory.

In the related art, it is often necessary to manually create a test order by a test user in order to verify the accuracy of the payment system by means of the test order. However, in the manner of manually creating the test order, various pieces of user information are manually input, which is time-consuming, labor-consuming and prone to errors. Moreover, the payment status of the manually created test order is usually generated according to the system test result, so that the payment status is difficult to predict, and various types of payment status cannot be covered (for example, the payment status of a plurality of test orders may be the same), which results in that it is difficult for the test process to comprehensively verify whether the processing flow of the payment system for the various types of payment status is correct. Therefore, a more efficient and accurate test method is needed. In order to solve the problems, the application provides a testing method of a payment system, which can automatically generate virtual user information without manual input of a user, so that the testing efficiency is greatly improved; in addition, the method can flexibly configure the payment state parameters (the value of the payment state parameters can be configured according to actual test requirements), so that the state feedback information sent by a third party payment channel can be simulated according to the payment state parameters contained in the payment test parameters, so that the payment system can update the payment data table according to the state feedback information, and accordingly, whether the function of the payment system is abnormal can be judged by matching the updated payment data table with a preset standard value. Because the payment state parameters are input by the user, various payment states (such as successful payment, failure payment and the like) can be flexibly configured, so that the accuracy of the payment system in processing various payment states can be comprehensively verified.

Fig. 1 is a flowchart of a testing method of a payment system according to an embodiment of the present disclosure. Referring to fig. 1, the method includes:

step S110: acquiring received payment test parameters; wherein the payment test parameters include: a payment object parameter, and a payment status parameter.

Wherein the payment test parameters may be entered through a test configuration entry included in the test configuration interface. For example, the test configuration interface at least includes an object class configuration entry for inputting payment object parameters and a state class configuration entry for inputting payment state parameters. The payment object parameter is used for representing contents such as specific names, attributes and the like of the payment object, and the payment object can be a product to be paid, such as a borrowed product, an order product and the like. The payment status parameter is used to characterize a target processing status (also called expected payment status), and is used to preset a payment status that should appear in the test, such as successful payment or failure payment. In short, through the payment state parameter, the expected payment state can be preset, so that various types of payment states can be flexibly covered. In the actual business processing process, the actual payment state is determined by a business system, and the specific result is influenced by various factors such as network state, data transmission reliability and the like. The expected payment state is a preset payment state corresponding to the current test process, so that the expected payment state can be flexibly configured by a user and is not influenced by factors such as network state, data transmission reliability and the like. By pre-configuring payment state parameters corresponding to the expected payment state, the payment state can be pre-set, thereby facilitating comprehensive verification for various payment states.

Step S120: virtual user information corresponding to the payment object parameters is generated, and a payment test request containing the payment object parameters and the virtual user information is sent to the payment system.

Because the payment process needs to have a corresponding payment user, the manner of manually inputting the real user information is time-consuming and labor-consuming, and the batch-efficient execution of multiple tests is not possible. Therefore, in the present embodiment, virtual user information corresponding to the payment object parameter is generated according to a preset user information generation rule so as to transmit a payment test request including the payment object parameter and the virtual user information to the payment system.

Wherein the virtual user information generally includes: virtual user number (e.g., virtual phone number, virtual account number, etc.), virtual user address, etc. Taking the virtual user number as an example, the generation rule can be set according to rules such as standard digit of the user number, combination of the first 3 digits and the like, so that the virtual user number meeting the number checking specification is automatically generated. Because the virtual user information is not the user information which exists actually but is the information which is simulated for meeting the verification requirement of the payment system, the generation speed is high, the mode is simple, and the user does not need to manually input various contents in the real user information.

In addition, the payment test request is used for providing verification to the payment system, and specific verification may include various ways of user identity verification, payment object verification, and the like. For example, in user authentication, it is mainly verified whether virtual user information meets the specification of user information; in payment object verification, it is mainly verified whether the payment object is a product actually existing in the payment system.

Step S130: under the condition that the payment system passes the verification of the payment test request, state feedback information is sent to the payment system according to the payment state parameters; the payment system is used for updating the payment data table according to the payment state parameters.

In a specific implementation manner, after the payment system verifies the payment test request, a verification passing message is returned, and correspondingly, the test platform sends state feedback information to the payment system according to the payment state parameters under the condition that the verification passing message is received.

Under the condition that the payment system passes the verification of the payment test request, the payment operation request is usually sent to a payment channel (such as a bank, a payment APP and the like), and because the application runs in a test environment, the test platform intercepts the payment operation request and simulates the payment channel to send state feedback information to the payment system. The payment state parameters in the state feedback information are preconfigured by the user, so that various types of payment state parameters can be flexibly selected, and the processing capacity of the payment system for various types of payment states can be comprehensively verified.

In addition, the payment system is used for updating the payment data table according to the payment state parameters contained in the state feedback information. The payment data table is used for maintaining payment detail records corresponding to various payment objects, for example, the payment data table at least needs to record various detail information such as income amount, residual amount, expenditure amount and the like, so as to ensure that the content in the payment data table can be dynamically adjusted according to business conditions.

Step S140: generating a test abnormality notification message under the condition that the data value in the updated payment data table is not matched with a preset standard value; the preset standard value is determined according to the payment object parameter and the payment state parameter.

Specifically, in this step, the data value of each field in the updated payment data table needs to be acquired, and the acquired data value is matched with a preset standard value. The preset standard value is calculated according to the payment object parameter and the payment state parameter. For example, in the case where the amount corresponding to the payment object, the payment method, and the payment status are known, the exact value of the relevant field in the payment data table can be automatically calculated according to the payment rule. Correspondingly, whether the data value in the updated payment data table is updated correctly can be checked according to the preset standard value, namely: and verifying whether the updating operation of the payment data table executed by the payment system according to the payment state parameters is accurate or not. If the data value in the updated payment data table is not matched with the preset standard value, the fact that the payment system is in error in the process of executing the updating operation is indicated, and therefore a test abnormality notification message is generated to notify a tester to update and maintain the payment system; if the data value in the updated payment data table is detected to be matched with the preset standard value, the fact that the payment system is not wrong in the process of executing the updating operation is indicated, and therefore a test normal notification message is generated to notify a tester that the payment system can be formally put into a production environment for use.

In specific implementation, a user can configure multiple groups of payment test parameters in batch to test the processing flows of multiple payment states in batch, so that the test efficiency is improved.

Therefore, in the mode, on one hand, virtual user information can be automatically generated according to the received payment test parameters, manual creation of a user is not needed, and the test efficiency is improved; on the other hand, the state feedback information sent by the third party payment channel can be simulated according to the payment state parameters contained in the payment test parameters, so that the payment system updates the payment data table according to the state feedback information, and accordingly, whether the function of the payment system is abnormal can be judged by matching the updated payment data table with a preset standard value. Because the payment state parameters are input by the user, various payment states (such as successful payment, failure payment and the like) can be flexibly configured, so that the accuracy of the payment system in processing various payment states can be comprehensively verified.

Various modifications and alterations to the above described embodiments will be apparent to those skilled in the art, and the specific implementation details of the above described embodiments are not intended to be limiting.

In an alternative implementation, considering that multiple version numbers may exist in the payment system and the actual usage environment may be complex and variable, in order to facilitate testing of the payment system for each version number to comprehensively reflect the payment performance under each condition, in this embodiment, multiple test environments may be configured in advance, where each test environment corresponds to a unique test environment identifier. Correspondingly, the test configuration interface also comprises an environment configuration inlet for inputting a test environment identifier. Thus, the payment test parameters also include: and (5) testing the environment identification. Correspondingly, before generating the virtual user information corresponding to the payment object parameters, further querying a system call interface corresponding to the test environment identifier in the configuration file. In the configuration file, system call interfaces corresponding to the respective test environment identifiers are stored in advance, different test environment identifiers correspond to different system call interfaces, and different system call interfaces correspond to different version numbers of the payment system. It can be seen that the payment system of the corresponding version can be called for testing by querying the system call interface corresponding to the current testing environment identifier from the configuration file. Optionally, the system call interface at least includes: the system comprises a first calling interface and a second calling interface, wherein the first calling interface is used for receiving the payment test request, and the second calling interface is used for receiving the state feedback information. Correspondingly, when a payment test request containing payment object parameters and virtual user information is sent to a payment system, the payment test request is realized by calling the first calling interface; and when the state feedback information is sent to the payment system, the state feedback information is realized by calling the second calling interface.

In an alternative implementation, in order to improve the test efficiency, the test may be performed in a concurrent manner. Correspondingly, the payment test parameters further include: and the concurrency quantity parameter is used for representing how many test cases running in parallel need to be created. Correspondingly, when generating virtual user information corresponding to the payment object parameters and sending a payment test request containing the payment object parameters and the virtual user information to the payment system, the method is specifically realized by the following steps of: firstly, generating a plurality of virtual user information corresponding to the concurrency quantity parameter according to the concurrency quantity parameter; then, a plurality of payment test requests are sent in parallel to the payment system, wherein virtual user information contained in each payment test request is different. In this manner, a concurrency configuration entry for inputting a concurrency number parameter is also included in the test configuration interface. By means of the concurrent configuration inlet, multiple test pipelines can be created, so that multiple types of test cases can be tested in parallel, for example, parallel tests can be conducted aiming at different test environments, and test efficiency is improved.

In yet another alternative implementation, it is contemplated that multiple payment channels may exist in the actual business, for example, the user may pay through different banks, which correspond to different payment channels; as another example, the user may pay through different payment APPs, which also correspond to different payment channels. Because the message formats corresponding to different payment channels are different, even if the payment system is detected to be capable of correctly processing the payment channel a, it cannot be ensured that the payment system is capable of correctly processing the payment channel B. Thus, in order to fully verify whether the payment system is able to respond correctly to the respective payment channel, in this embodiment, the payment test parameters may further include: payment channel parameters. For example, a channel configuration entry for entering payment channel parameters is also included in the test configuration interface. Accordingly, before sending status feedback information to the payment system according to the payment status parameters, the following operations are further performed:

First, channel format information matching the payment channel parameters is obtained from the profile. The method comprises the steps of storing channel format information corresponding to each payment channel parameter in a configuration file in advance, wherein the channel format information comprises a coding mode, field number, field names and the like adopted by a payment channel. For example, when feeding back status feedback information of the same type, the encoding mode adopted by different payment channels may be different, and the number of fields, the field names and the field orders contained in the status feedback information may be different, so that a configuration file needs to be queried to obtain channel format information matched with the current payment channel parameters.

Then, format conversion processing is carried out on the payment state parameters according to the channel format information, and state feedback information is generated according to the payment state parameters after format conversion processing. The payment status parameter is used for describing a target payment status expected by the test, such as successful payment, failure payment, overdue payment, and the like. The payment status parameter is configured by the user to force the payment system to conduct a test of the corresponding status. Therefore, in order to achieve the above objective, the test platform needs to perform format conversion processing on the payment status parameter according to channel format information corresponding to the current payment channel parameter, and generate status feedback information according to the format conversion processing result. The format conversion process may include: conversion of the encoding format, numerical padding for each field, and the like. In summary, the purpose of format conversion is to: and matching the number of fields, the field names and the field orders contained in the state feedback information with channel format information corresponding to the current payment channel parameters. Correspondingly, when state feedback information is sent to the payment system according to the payment state parameters, channel identifiers corresponding to the payment channel parameters are specifically acquired, so that the payment channels corresponding to the channel identifiers are simulated to send the state feedback information to the payment system. For example, the obtained channel identifier may be added to the status feedback information, so that the payment system decrypts the status feedback information according to the decoding mode corresponding to the channel identifier, thereby testing whether the payment system can correctly process the information of the payment channel. For example, in practical situations, the payment channel may dynamically update the channel format information, for example, the number of fields contained in the status feedback information may be adjusted (such as adding fields or deleting fields), the field order may be adjusted, or the field name may be replaced, and accordingly, the payment system needs to update the channel format information synchronously with each payment channel, so as to ensure that the payment system can parse according to the latest format specification of each payment channel. If the payment system fails to update in time after the payment channel is updated, the payment system cannot accurately analyze the state feedback information fed back by the payment channel, so that the subsequent data table updating operation is wrong, and therefore the occurrence of the problems can be avoided by respectively verifying the processing accuracy of the payment system for each payment channel.

In the above-mentioned concurrent testing manner, the testing environments and/or payment channels corresponding to the multiple concurrent payment test requests may be identical, for example, the multiple concurrent payment test requests are used for testing the testing result of the same payment object (such as a borrowed product) corresponding to the same payment channel under the same testing environment, and since each payment test request is affected by abnormal factors such as a network state and a data transmission state, an error may occur in the testing process, and the inaccurate testing condition caused by the network abnormality can be avoided to the greatest extent through the multiple concurrent payment test requests. In addition, the test environments and/or payment channels corresponding to the multiple concurrent payment test requests can be different, so that the multiple test environments and/or payment channels are verified in parallel, and the test efficiency is improved. Accordingly, the concurrent quantity parameter is used to characterize a total number of the plurality of payment test requests concurrently performed, and the payment test parameter further includes: the environment concurrency configuration parameters and/or the channel concurrency configuration parameters. The environment concurrency configuration parameters are used for representing the corresponding relation between the plurality of payment test requests which are executed concurrently and the test environment, and the channel concurrency configuration parameters are used for representing the corresponding relation between the plurality of payment test requests which are executed concurrently and the payment channels. For example, the environment concurrency configuration parameter may be the number of payment test requests corresponding to each test environment, for example, in the case that the total number of the plurality of payment test requests that are executed concurrently is 15, it is assumed that the 15 payment test requests correspond to 3 test environments (i.e., test environment 1, test environment 2, test environment 3), respectively, and the environment concurrency configuration parameter is 5;5, a step of; 5 (specifically for characterizing the number of requests per environment), then it indicates that there are 5 payment test requests per test environment; alternatively, assume that the environment concurrency configuration parameter is 1:1:1 (a ratio specifically representing the number of requests between multiple environments) also represents that each test environment corresponds to 5 payment test requests. For simplicity and convenience of description, the description is only given by taking the example that the number of payment test requests corresponding to each test environment is equal, in an actual case, in the case that a plurality of payment test requests correspond to a plurality of test environments, the number of payment test requests corresponding to each test environment may also be unequal, and in particular, the payment test requests may be flexibly configured according to actual service requirements. The configuration mode of the channel concurrency configuration parameters is similar to the environment concurrency configuration parameters, and is used for specifically configuring the number of payment test requests corresponding to each payment channel, and is not repeated here. In addition, it should be emphasized that, in the case that at least two payment test requests correspond to the same test environment and respectively correspond to different payment channels, since channel calling interfaces corresponding to different payment channels are different, in order to avoid a conflict problem caused by testing at least two payment test requests corresponding to different payment channels in the same test environment, in this embodiment, channel calling interfaces of each payment channel may be further configured through channel concurrency configuration parameters, so that at least two payment test requests corresponding to the same test environment and corresponding to different payment channels respectively call channel calling interfaces of different payment channels through different threads, thereby realizing isolation processing of payment channel dimensions and further avoiding a conflict problem. The channel calling interface is used for simulating the corresponding payment channel to send state feedback information, and specifically, the channel calling interface can be replaced by other forms such as channel calling parameters or channel calling addresses, so long as the purpose that different payment test requests trigger state feedback information through different payment channels can be achieved.

It can be seen that by the above manner, the concurrency quantity corresponding to each payment channel and the concurrency quantity corresponding to each testing environment can be respectively configured by the user. In a word, because the test configuration interface comprises a plurality of configuration inlets, a plurality of groups of test cases can be configured in batches, so that concurrent tests aiming at different test environments and different payment channels can be realized, and the test efficiency is greatly improved.

In the related art, one payment test request corresponds to one test pipeline, and thus, in the case where two payment test requests correspond to the same test environment, two payment test requests belonging to the same test environment have to be sequentially executed due to the non-configuration environment and the concurrent configuration parameters, that is: only after the first payment test request is completed, the party may execute the second payment test request, thereby resulting in inefficiency of the test. Similarly, in the related art, if two payment test requests correspond to the same payment channel, two payment test requests belonging to the same payment channel have to be sequentially executed because the channels are not configured with configuration parameters. In this embodiment, by setting the environment concurrency configuration parameter and/or the channel concurrency configuration parameter, a plurality of concurrently executed processes or threads can be set, and each process or thread invokes a different test environment interface and/or payment channel interface, so that a plurality of test requests corresponding to the same test environment or payment channel do not conflict with each other, and can be executed in parallel, thereby greatly improving the test efficiency.

In yet another alternative implementation, considering that the number of tables of the payment data table is numerous and the number of fields is also very large, in order to improve the matching efficiency, the target list and the target field matched with the currently tested payment status parameter are extracted from the plurality of list data tables included in the payment data table, so as to reduce the subsequent matching range and improve the matching efficiency. For example, in a staged payment scenario, the payment test parameters further include: the payment term parameter is used for representing how many times the user needs to pay, such as a year payment corresponding to 12 months, a two year payment corresponding to 24 months, and so on. Accordingly, the payment status parameters include at least one of: a successful payment state, a failed payment state, a successful and n+1-th payment failure state (where N is a natural number), an overdue payment state, and the like. Correspondingly, the payment data table comprises: a plurality of payment tables respectively corresponding to different payment states and/or payment objects, and each payment table comprises a plurality of fields. For example, in the case where the payment test request is a borrowed payment request, the payment data table includes at least one of: a borrowing data table, a repayment data table, a transaction detail table and the like. Accordingly, after sending the status feedback information to the payment system according to the payment status parameter, the following operations are further performed:

First, a target list associated with a payment status parameter and a payment object parameter is screened from a plurality of payment lists according to the payment status parameter and the payment object parameter. For example, in two different states of payment success and payment failure, the payment details table and the fields in the table that need to be updated are different; when different payment objects are to be paid, the payment method, payment term, payment amount, and the like of the different payment objects are different, and thus the payment statement and the fields in the table to be updated are also different. Therefore, according to the data table updating mode and the updating range corresponding to the payment state parameter and the payment object parameter, the target detail table associated with the payment state parameter and the payment object parameter can be screened from the plurality of payment detail tables. Accordingly, the payment system only needs to update the screened target list in the test process, and does not need to operate on the rest list.

Then, the target field associated with the payment status parameter and the payment object parameter is screened from a plurality of fields contained in the target detail table. Since the target list generally contains a plurality of fields, some of which are not required to be updated in the current test process, the target fields associated with the payment status parameter and the payment object parameter are further filtered from the plurality of fields contained in the target list, thereby further reducing the matching range.

And finally, judging whether the data value in the updated payment data table is matched with a preset standard value or not according to the field data value of the target field in the target detail table. Specifically, field data values of target fields in the target detail table are matched with preset standard values, so that the test result of the payment system is judged to be normal or abnormal according to the matching result. Therefore, the abnormal problems in the current test process can be accurately positioned by means of limiting the data table and the field range.

In yet another alternative implementation manner, when the test anomaly notification message is generated in the case that the data value in the updated payment data table does not match the preset standard value, the method is specifically implemented by the following steps: firstly, determining a target field which is not matched with a preset standard value as an abnormal field, and acquiring a comparison result between a field data value of the abnormal field and the preset standard value. Then, according to the exception field and the comparison result, determining the exception type, and generating a test exception notification message according to the exception type. Wherein the comparison result generally comprises: the field data value of the abnormal field is greater than a preset standard value, the field data value of the abnormal field is less than a preset standard value, or the field data value of the abnormal field is null, and accordingly, according to the specific situation of the comparison result, it can be determined what type of the abnormal type is, for example, may include: various types such as untimely updating of the payment system, repeated updating of the payment system, or error updating of the payment system. Correspondingly, the test abnormality notification message is sent to the payment system, so that the payment system can adjust and optimize according to the test abnormality notification message.

In yet another alternative implementation, to improve the security of the system, before sending a payment test request containing the payment object parameters and the virtual user information to the payment system, the following operations are further performed: first, an identity authentication request is sent to an authentication module included in a payment system according to virtual user information. The authentication module is used for verifying the virtual user information according to the format specification of the user information. Then, in the case that the identity authentication passes, an object authentication request is transmitted to an object authentication module included in the payment system according to the payment object parameter. The object verification module is used for matching the payment object parameters with pre-stored payment object identifiers and judging whether verification is passed or not according to a matching result; the payment test request is sent if the object verification passes. The object verification module is also called an air control module, and is configured to verify whether a payment object parameter input by a user points to a certain pre-stored payment object identifier, for example, in a case that the payment system is capable of providing multiple payment objects (also called payment products), the payment object parameter input by the user must be matched with the payment object provided by the payment system, or otherwise, the payment object is prompted to be absent. By means of the authentication module and the object verification module, the problem of abnormal testing caused by incorrect configuration of payment testing parameters can be avoided, and reliability of the testing process is improved. The authentication module and the object verification module may be a sub-module included in the payment system, or may be a third party module independent of the payment system, which is not limited in this application.

In an alternative implementation, the virtual user information includes at least one of: virtual number information, virtual name information, virtual certificate information, virtual address information, virtual contact information, virtual bank card information, and the like.

In a word, the embodiment can automatically generate virtual user information according to the received payment test parameters without manual creation of a user, so that the test efficiency is improved; and the third party payment channel can be simulated to send state feedback information according to the payment state parameters contained in the payment test parameters, so that the payment system can update the payment data table according to the state feedback information, and accordingly, whether the function of the payment system is abnormal can be judged by matching the updated payment data table with a preset standard value. Because the payment state parameters are input by the user, various payment states (such as successful payment, failure payment and the like) can be flexibly configured, so that the accuracy of the payment system in processing various payment states can be comprehensively verified. In addition, the embodiment can flexibly configure different test environments and payment channels, so that whether the processing flows under the different test environments and the different payment channels are correct or not can be comprehensively verified. In addition, the method also supports concurrent testing of a plurality of test cases, and can greatly improve the testing efficiency by means of the concurrent testing method.

For ease of understanding, fig. 2 shows a schematic flow chart of a specific example, and next, taking this example as an example, specific implementation details of the testing method of the payment system in the present application will be described in detail:

in this example, the payment object is a borrowed payment product, which may specifically be provided by the payment APP. In the related art, in order to verify whether the payment system can correctly process the borrowed payment product, the user needs to manually download the payment APP, manually fill in registration information, completely fill in the identity information of the user, upload the contents such as the front and back photos of the identity card and the handheld photo, fill in the home address, the contact person, the bank card information and the like, and manually trigger various requests, so that the process is complicated and time-consuming. In the related art, it takes about 5 minutes on average to complete a single feed. The average time for completing single-stroke feeding by using the test platform in the example is about 15 seconds, so that the operation time is greatly saved, and the operation efficiency is improved.

As shown in fig. 2, this example specifically includes the steps of:

step S201: and acquiring payment test parameters input through a test configuration inlet included in the test configuration interface.

The payment test parameters may specifically include various parameters mentioned in the foregoing embodiments, for example, may include a payment channel parameter, a concurrency quantity parameter (for example, may be a borrowing number), a test environment parameter (for example, may be test1, test2, and test 3), a payment object parameter (for example, may be a borrowing product number+a repayment period number), and a payment status parameter (for example, a target final state "success in withdrawal", "failure in withdrawal", "success before failure in withdrawal", "overdue"), and so on. Wherein the payment object is a borrowed payment product, and thus, the payment object parameters may include: product identification of the borrowed payment product, etc. In the case where the borrowing payment product is a staged payment product, the payment status parameters may include: the payment in the M period is in a normal state, the payment in the N period is in a overdue state, the payment is in a successful state, the payment is in a failed state, the payment is in a successful-before-failed state, and the like. Wherein M, N is a natural number, and the withdrawal refers to the operation of paying money from a bank. In a word, since the borrowing payment product relates to various complex conditions such as bank paying operation, user paying operation (particularly, each period of paying condition), interest rate calculating operation and the like, the types and the quantity of the payment test parameters can be flexibly varied. Step S202: the test platform generates virtual user information corresponding to the payment object parameters contained in the payment test parameters, and sends an identity authentication request to an authentication module contained in the payment system according to the virtual user information.

Wherein the virtual user information includes at least one of: virtual number information, virtual name information, virtual certificate information, virtual address information, virtual contact information, and virtual bank card information.

For example, taking virtual number information as an example, the test platform can automatically generate 11-bit random numbers as virtual number information through a random number module (the first three digits conform to the rule of mobile phone numbers). After randomly generating at least one piece of virtual number information, inquiring whether the virtual number information exists in a registry from a test database, if so, registering the virtual number information, if so, regenerating the virtual number information (so as to prevent conflict with registered real user numbers), if not, calling a registration interface to complete registration, and then continuing to execute subsequent operations. After the virtual number information is successfully registered, a request header in a response message returned by the registration interface is obtained, a token value after the corresponding mobile phone number is registered is determined according to the request header, and the token value is stored as a variable, so that the variable is used for carrying out authentication operations such as real-name authentication, certificate authentication and the like in a subsequent authentication interface. For example, the generated mobile phone number is stored in a variable registNo, a random number module is used for randomly generating a 5-bit letter, storing the 5-bit letter in a variable rand5zm, randomly generating a 4-bit number, storing the 4-bit number in a variable rand4num, and then taking a 13-bit timestamp and storing the 13-bit timestamp in a variable timeNow. Next, the date of the day is saved in 8-bit digital format into variable today, and the real name authentication data is generated by combination. The real-name authentication data comprises various contents for representing mobile phone numbers, certificate photos, home addresses, contacts and bank card information of users. The certificate number ensures the uniqueness of the numerical value, url=real-name authentication interface address of the request, the request mode is post, if the request is successful, the request is continued, if the request fails, the test platform is automatically recorded, and the authentication failure of the mobile phone number is recorded in the production line. Address authentication, contact authentication, bank card authentication, etc. are similar. The address and the contact person information do not need to be checked for uniqueness, and the bank card number needs to be checked for uniqueness. For example, the authentication may be assisted with a 13-bit timestamp+6-bit random number at the time of authentication. In addition, the certification process of the certificate is special, and the URL address of the local picture needs to be written in the request data (the test environment does not need the real certificate), such as { ' kycImg ': (1. Jpg ', open (r ' D: \pic\1.Jpg ', ' rb '), ' image/jpeg '), ' custNo ': (None, custNo), ' kycType ': (N one, '10070001 ') } and the like. After all authentication interfaces respond successfully, the authentication interfaces pass all the authentication, if only one authentication interface responds wrongly, the authentication interfaces fail, the test platform records the failed mobile phone numbers, counts the number of the failures, and stops the subsequent steps.

Step S203: and under the condition that the identity authentication is passed, the test platform sends an object authentication request to an object authentication module contained in the payment system according to the payment object parameters.

The object verification module is also called an air control module and is used for judging whether the business risk exists. Specifically, the object verification module is mainly used for verifying whether the payment object parameters are matched with the prestored payment object identifiers. For example, the payment object identifier may be a product number of the borrowed product, and if the payment object parameter input by the user is consistent with the product number of the prestored borrowed product, the verification is passed; otherwise, the verification is not passed. Step S204: and under the condition that the object verification is passed, the test platform sends a payment test request containing payment object parameters and virtual user information to a payment module in the payment system.

Wherein in this example the payment test request may also be referred to as a withdrawal request for applying for a cash deposit.

Step S205: a payment module in the payment system processes the payment test request and generates a test order corresponding to the payment test request.

Wherein the payment module creates a test order corresponding to the payment test request in the order database to track an order status of the test order by an order number. In order data of the test order, various contents such as an order number, order attribute data and the like need to be stored. Wherein the order number is used to uniquely identify an order, and the order attribute data includes the contents of the above-mentioned payment test parameters and the like, so as to perform subsequent status verification operations.

In practical situations, the payment module needs to send a request for applying for paying money to a corresponding payment channel, and in this example, since the payment module operates in a test environment, the payment module does not need to actually send the request for applying for paying money.

Step S206: and the test platform sends state feedback information to the payment system according to the payment state parameters contained in the payment test parameters.

Specifically, the test platform queries the created test order in the order database, determines the payment state parameters contained in the corresponding payment state parameters according to the order attribute data of the queried test order, and sends state feedback information to the payment system. The state feedback information is sent by simulating the corresponding payment channel, and specifically needs to include the channel identifier of the payment channel and the payment state (such as success or failure).

Step S207: and the payment system updates the payment data table according to the payment state parameters contained in the state feedback information.

After receiving the status feedback information sent by the test platform in the callback mode, the payment system modifies the order status according to the payment status parameters contained in the status feedback information, for example, modifies the order status to be successful or failed. The payment data table is then updated in real time. In this example, the payment data table specifically includes a plurality of payment detail tables, respectively: a borrowing information list, a transaction flow water list, a transaction detail list, a repayment schedule list, a financial receivability detail list, a borrowing flow subject list, a payable detail list and a real payment detail list. For example, the borrowing data in the borrowing information table is updated, the borrowing status is updated from "to-be-presented" to "normal", the transaction status in the transaction sequence and the transaction detail table is updated to "successful", and a repayment schedule table is generated, and the repayment date, the current period number, the amount to be returned, and the like are filled out. In addition, the financial accounts receivable list and the financial accounts receivable list are written, and details such as the total amount to be received, the principal to be received, the interest to be received, the commission to be received and the like are specifically filled. In addition, the principal amount and the subject number, interest amount and subject number, commission amount and subject number, and the like are required to be recorded in the borrowing running water subject table; the payable list is written with the details data such as the amount of money to be paid by the system to the user, and the payable list is written with the details data such as the amount of money to be actually paid to the user and the payment time.

Step S208: and judging whether the data value in the updated payment data table is matched with a preset standard value.

And the test platform acquires the updated detail tables and verifies the correctness of the data in the detail tables. In specific implementation, the data of each relevant table is queried in turn, for example: for the product with the single borrowing number 25002400 (7 days of single borrowing period, principal 500, interest 40, commission 10, single total 550), a calculation function is called to verify whether the data of the following tables are correct:

borrowing information table: whether the field value of the borrowing amount field is=500, and whether the borrowing state is=normal;

transaction flow meter and transaction detail table: whether the transaction status=successful, whether the transaction amount=500;

repayment schedule: whether the repayment date is=the current date+7, whether the current period number is=1, and whether the amount to be repayed is=550;

financial receivables and receivables details: whether the total amount to be collected is 550, whether principal to be collected is 500, whether interest to be collected is 40, and whether commission to be collected is 10;

borrowing flow subject list: whether principal subject amount and subject number=500 and 1000000, interest subject amount and subject number=40 and 1000011, commission subject amount and subject number=10 and 2000001;

Payable details table: whether the amount=500;

pay detail table: whether the amount=500, and whether the status=successful.

If all the data in the tables pass verification, the data representing the single-period borrowing products and payment channels can be normally cleared and settled in real time, the test platform generates a data record of successful money release, otherwise, the data record of failure money release is recorded.

Step S209: and generating a test abnormality notification message under the condition that the data value in the updated payment data table is not matched with the preset standard value.

If the data value in the updated payment data table is not matched with the preset standard value, it is indicated that the payment system is abnormal, and therefore a test abnormality notification message is generated to promote the payment system to perform optimization adjustment.

In addition, in the above example of step S206, if the number of test orders is large, the test platform may periodically poll the status of each order in the order database, obtain, for the order whose status has changed, the data content corresponding to the order whose status has changed from the payment statement in step S207, and perform matching determination:

for example, if an order with status updated as "failure in withdrawal" is polled regularly, a payment channel such as a simulated bank sends status feedback information with failed payment status to a payment system, specifically, the status feedback information can be sent through a callback interface with failed withdrawal, and after receiving the status feedback information, the payment system changes the successfully withdrawn order data into failure withdrawal and rolls back the data information and status.

In addition, in the case where the test platform polls for an order with a failed proposal, it is further necessary to verify whether the order data is rolled back correctly. For example, the test platform verifies by querying the various payment tables described above: for example, for a single borrowing number 25002400 product (7 days of the single borrowing period, principal 500, interest 40, commission 10, single total 550), the following individual details are validated using the individual calculation functions in sequence:

borrowing information table: whether borrowing status=to be presented;

transaction flow meter and transaction detail table: whether the transaction state=pending, whether the transaction amount=500;

repayment schedule: the borrowing data is deleted;

financial receivables and receivables details: the borrowing data is deleted;

a borrowing flow subject list, wherein the borrowing data is deleted;

payable details table: the borrowing data is deleted;

pay detail table: status = pending. If all the information passes verification, the data representing the single-period borrowing product and the payment channel A is correctly rolled back. If one of the verifications fails, the rollback representing the single-period borrowing product and the payment channel A data fails. Whether the verification is passed or not, the test platform records the test result and the corresponding information such as the mobile phone number, the borrowing number and the like, and if the verification is not passed, the verification failure table is required to be recorded, and the actual result difference and the expected result difference correspond to the mobile phone number and the borrowing number.

Under the condition that a plurality of test orders exist, namely, under the condition that the numerical value of the concurrent quantity parameter is larger, the parallelization batch processing of a plurality of test orders is realized by calling batch processing tasks (such as 'daily final batch processing scheduling tasks') in a pipeline of the test platform. For example, the loan status is updated in batches, and the amount of late funds is written in batches into a plurality of data tables, or the like. The test platform verifies whether the processing result of the daily final batch processing scheduling task is correct or not by inquiring the data of each payment detail table.

For example, for a single borrowing number 25002400 product (7 days of the single borrowing period, principal 500, interest 40, commission 10, single total 550), a calculation function (e.g., assuredly equal function) is used in order to verify that the data in the following tables are correct:

borrowing information table: whether the borrowing amount is=500, and whether the borrowing state is=overdue;

transaction flow meter and transaction detail table: no change, whether the transaction status=successful, whether the transaction amount=500;

repayment schedule: whether the repayment date=the current date+7, whether the current future number=1, whether the amount to be refund=550, whether the late fee=principal×5% of the overdue days (current date+batch number of days-repayment day);

Financial receivables and receivables details: whether the total amount to be received is=550, whether principal to be received is=500, whether interest to be received is=40, whether commission to be received is=10, whether principal to be received is 5% of overdue days;

borrowing flow subject list: whether the principal amount and the subject number are=500 and 1000000, whether the interest amount and the subject number are=40 and 1000011, whether the commission amount and the subject number are=10 and 2000001, whether the late principal amount and the subject number are=5% of the overdue days and 3000001;

payable details table: no change, whether the amount=500;

pay detail table: no change, whether the amount=500, and status=successful.

In summary, through the implementation manner in this example, at least the following beneficial effects can be achieved:

firstly, in the traditional manual operation mode, APP with different test environments needs to be downloaded and installed, mobile phone number registration and login are manually filled in, personal identity information is filled in, front and back sides of an identity card and hand-held photos are uploaded, home address and contact person phenomena, bank card number information and the like are filled in, various interfaces need to be manually called, the flow is complicated, time and labor are consumed, and information such as payment channels corresponding to the APP needs to be manually switched from a background management system. Moreover, the verification process for the data table also needs to be manually implemented, and manually querying each table to verify the data is particularly time-consuming and prone to omission or error. The average time for manually completing single-stroke feeding is about 5 minutes, the average time for single-stroke feeding of the test platform to be lifted into power consumption is about 20 seconds, the test verification time is greatly saved, and the accuracy and the high efficiency of the test verification data table are improved.

Secondly, a plurality of pipelines can be established, and the correctness of the data table of various borrowed products can be constructed and verified in parallel in a plurality of test environments. Such as whether the data of successful and then failed withdrawal of the single-period borrowing product rolls back, whether the late register calculation of overdue after successful withdrawal of the multi-period borrowing product is correct, etc., in a word, can be nimble quick verify various financial data content, verify that the content is comprehensive and accurate.

Finally, for a more thorough understanding of the specific details of the above example, some of the details of the above example are described in conjunction with FIG. 3. As shown in fig. 3, the test platform is a python test platform that needs to be tested for the expected payment status as follows: the method comprises a single-period borrowing normal state, a three-period borrowing normal state, a single-period borrowing overdue state, a three-period borrowing overdue state and a first successful and then failed state of withdrawal. Correspondingly, the test platform firstly completes the number of the input interface through the interface adjustment, and generates single-period borrowing products (borrowing state is normal), three-period borrowing products (borrowing state is normal), single borrowing (overdue) and withdrawal failure data of the appointed number. The test platform completes daily batch processing by calling a daily final batch processing scheduling task, changes the borrowing state from normal to overdue, and writes late deposit into a plurality of data tables (including a borrowing information table, a repayment schedule table, a receivable and receivable detail table because of sum and borrowing state fields) and changes the multi-table borrowing state to overdue. The loan flow schedule is written with the late fee schedule number and the late fee amount, and the single-stage and multi-stage payment schedule data are different and the rest are similar. The specific contents of each data table are as follows:

Borrowing and borrowing information table: recording basic borrowing information, such as: the information of the fields such as credit amount, deposit amount, borrowing period number, borrowing state, clearing time and the like;

repayment schedule: recording field information such as borrowing period number, repayment day, repayment state and the like;

receivability and receivability details table: recording field information such as receivable amount, repayment day, state and the like;

lending and running water subject list: recording field information such as subject numbers, borrowing period numbers, transaction amounts, borrowing directions and the like;

the test platform can establish a plurality of pipelines of different test environments to construct and verify borrowing data in parallel, so that test verification time is greatly saved. For example, a pipeline basically operates as follows: selecting a certain test environment test1, test2 or test3, filling in the borrowing number, selecting a payment channel A, a payment channel B or a payment channel C, selecting a borrowing product number such as 25002400 (7 days in a single period), 10000001 (7 days in each three periods), selecting a target final state of 'successful withdrawal' or 'failed before successful withdrawal' or 'overdue', clicking a page execution button, and filling in a corresponding interface for execution by a pipeline according to configuration files to complete the whole flow withdrawal operation. The pipeline name is automatically generated according to the combination of the environment name, the payment channel, the product number, the success of the promotion and the execution time stamp.

The method comprises the steps of establishing and executing a plurality of pipelines, wherein the establishment and execution of the pipelines are to finish simultaneously and concurrently constructing borrowing and withdrawal data of different payment channels and different final states in different test environments, and the establishment and execution of the next pipeline can be performed only after the execution of the previous pipeline is finished. Of course, only one pipeline may be established to complete successful withdrawal of the borrowed data item and verification of the financial data.

Such as:

the pipeline with the pipeline name of 'test 1+ A +25002400+ successful withdrawal + execution time stamp', abbreviated as pipeline 1, selects test environment test1, feeds 2 batches of data successfully withdrawn by the single-term borrowing + payment channel A, and verifies related 11 pieces of table data.

The pipeline with the pipeline name of 'test 2+ A +25002400+ and the pipeline of success before failure + execution time stamp' is called as pipeline 2 for short, test environment test2 is selected, two and three-period borrowing and payment channels A are fed in batches to extract data of success before failure, and 11 pieces of related table data are verified.

The pipeline with the pipeline names of test3+B+25002400 +overdue+execution time stamp is abbreviated as pipeline 3, a test environment test3 is selected, 2 batches of data overdue after the single-term borrowing and payment channel B is successfully presented, and related 11 pieces of table data are verified.

In general, if one pipeline selects test1, payment channel a and other parameters, in the "executing" state, one pipeline with different payment channels in the same test environment test1 cannot be executed any more, but a save can be established and not executed. Because if the 2 nd pipeline selects the same test environment, the pipeline is switched to the payment channel B, the conflict is caused, so that the payment channel A is used when the python simulation is used for presenting a successful interface in the 1 st pipeline, and the payment service judges that the current payment channel is wrong, so that the success cannot be presented. The method comprises the steps that 2 pipelines with the same test environments and different payment channels cannot be operated at the same time, and when clicking and executing in the pipelines, whether 1 pipeline test environments are the same and different in payment channels exist currently is checked through an interface, and after the fact that the 2 nd pipeline cannot be successfully executed and an error prompt is sent, namely that the pipeline operation of the payment channel A with the test environment test1 exists is indicated. Therefore, the number of the stored pipelines or the payment channels are not limited by tasks, but when the pipelines are executed, whether 1 pipeline testing environments exist in the current state or not is judged, if yes, an error prompt is reported, and if no, normal execution is carried out. Of course, in order to solve the above-mentioned problems, the conflict can also be avoided by setting the above-mentioned environment concurrency configuration parameters and/or channel concurrency configuration parameters.

Different test environments are distinguished in the environment configuration file of the test platform, for example:

test1, namely, the service domain name information 1 of the incoming service, the domain name information 1 of the payment service, the connection configuration information 1 of the database of the incoming and financial mysql and the payment channel information A, B, C;

test2, package service domain name information 2, payment service domain name information 2, package and finance mysql database connection configuration information 2, payment channel A, B, C;

test3, package service domain name information 3, payment service domain name information 3, package and finance mysql database configuration connection information 3, payment channel A, B, C.

The front-end pipeline of the test platform can use the environment configuration only by selecting a certain test environment name.

For example, using python test platform batch number manufacturing verification, selecting test1 when establishing the pipeline, filling in borrowing number 2 needing number manufacturing, selecting payment channel A, selecting borrowing product number as 25002400, single-period borrowing period 7 days, principal 500, interest 40, commission 10, single-period total sum 550, final state selection presenting success, storing the platform to generate a piece of pipeline data, wherein the state is 'to be executed', clicking execution, prompting that the state is changed into 'executing', and the executing state is not finished and the successful and failed number and corresponding mobile phone number cannot be checked. When the pipeline data is in operation, the pipeline is divided into 2 threads, an 11-bit number is generated by using a random module (the first three digits meet the rule of mobile phone numbers), after 2 mobile phone numbers are randomly generated, the pymysql module is connected with a test database to inquire whether the 2 mobile phone numbers exist or not through a registry, the existence represents that the mobile phone numbers are registered, the random mobile phone numbers are regenerated when the mobile phone numbers are registered, the registration is continuously completed when the mobile phone numbers are not registered, a registration interface is called by using a requests module, and the subsequent steps are continuously carried out when the interface returns to be successful.

After the registration is successful, a request head in the response of the registration interface is obtained, the token value after the mobile phone number is logged in is stored in a variable token, and the variable is used in a subsequent interface, such as 5 authentication interfaces including real-name authentication, certificate authentication and the like, and application and verification and confirmation application and application upgrading interfaces.

The generated mobile phone number is stored in a variable registNo, a random 5-bit letter is generated and stored in a variable rand5zm through a random module, a random 4-bit number is stored in a variable rand4num, a 13-bit timestamp is taken and stored in a variable timeNow, a date of day is taken and stored in a 8-bit digital format and stored in a variable today, and real-name authentication data are generated by combination, for example: { "appName": "LP", "appNo": "201", "certNo": rand4num+timeNow, "custFirstName": "wang", "custLastName": "test", "custMiddleName": "mm", "reduction": "1019006", "marriage": "10050001", "panNo": st5zm+rand4num "," registNo ":" sex ":"10030001"," usemail ":" autotest@gmail.co m "," useLang ":"90000001"}, rand4 num+timeNow=cerNo, cerNo. The certificate number ensures that the value is unique, url=real name authentication interface address of the request, the request mode post is continued if successful, the failure is automatically recorded to the test platform, and the number of the mobile phone in the production line fails to operate. The address authentication, the contact authentication and the bank card authentication interface are similar, the address and the contact information are not verified to be unique, the bank card number is verified to be unique, 13-bit timestamp+6-bit random number is used for storing the variable cardno. the certificate authentication is special, local pictures url (the test environment does not need real certificate) such as { 'kycImg', '1.Jpg', 'open (r' D: \pic\1.Jpg ',' rb ',' image/jpeg ',' custNo ',' None, custNo ',' kycType ',' N one, '10070001') need to be written in the request data

After all interfaces of the 5 authentications are successfully responded, representing that all authentications pass, if only one interface response fails, the interfaces fail, the test platform records the failed mobile phone number and the number of statistical failures, and the subsequent steps are stopped. After all the 5 items pass the authentication, the request module calls an interface for applying for withdrawal, and the interface responds to the borrowing number and writes borrowing data into a borrowing information table, so that the state is to be withdrawn. The application presenting interface only needs to transmit the previous variable custNo and set a post request mode.

Then, an order to be presented is scanned in the wind control process, and after a decision tree strategy, the wind control automatically passes (if a product number exists, the wind control automatically passes), and the order entering service automatically changes the state of the order into a product to be matched.

After the mysql database is connected in the test platform assembly line through the pymysql module, a storage process of product matching is called, after the product matching is successful, the system matches the subject information of the borrowed product, such as principal, interest, commission and the like, and corresponding data information is written into a payable, payable list and a lending flow subject list, and the state is 'to be processed' or 'in transaction'.

The request module is used for calling and initiating a confirmation presentation interface in the test platform pipeline, and interface parameters are as follows: { "custNo": custNo "," instNum ": instNum", "lotaAmt": lotaAmt "," prodNo ": prodNo }

custNo refers to the custNo client number returned by the real name authentication interface response

instNum refers to the period 1 (7 days) of borrowing period

Loanamt refers to the borrowing amount 500 yuan, and is presented to account 500 yuan

ProdNOs refers to the borrowing product number 25002400, after the request is initiated to the payment service, the response is successful, and the financial database generates a proposal application order in the state of "pending".

The test platform pipeline is periodically polled for pending proposal application orders. The simulated bank truly returns to the payment service, and the payment channel is specified in the front, the required interface parameters are different, and the state is successful in proposing, such as the payment channel A:

{"result":{"amount":500,"beneficiaryIfsc":None,"beneficiaryName":"wangmmmmtest","co mmissionAmount":"0.00","createdOn":"13-04-202208:05:09","isCachedData":None,"mid":"NA RAIN39025689320637","nextRetryTime":"13-04-202208:10:13",

"orderId":1234322,"paytmOrderId":787878222,"processedOn":"13-04-202208:05:13","retr yCount":None,"reversalReason":None,"scheduleOn":None,"tax":"0.00"},"status":SUCCESS,sta tusCode":"DE_001","statusMessage":"SuccessfuldisbursaltoWalletisdone"}

note that: status, FAILURE-simulation to extract FAILURE state, SUCCESS-simulation to extract SUCCESS state, current: the present amount, beneficiaryName: account name, orderld: order number.

Such as payment channel B:

{"entity":"","account_id":"","event":"payout.processed","created_at":0,"contains":[""],"pay load":{"payout":{"entity":{"id":tran_order_no,"entity":"","account_number":"","fund_account_i d":"","amount":500,

"currency":"","debit":0,"balance":0,"notes":{},"fees":0,"tax":0,"status":1,"purpose":"","utr":"","mode":"","reference_id":{},"narration":"","batch_id":{},"failure_reason":"","created_at":0}},"tr ansaction":{"entity":{"id":"","entity":"","account_number":"","amount":0,"currency":"","debit":0,"balance":0,"source":{"id":"","entity":"","fund_account_id":"","amount":0,"notes":{},"fees":0,"tax":0,"status":"","utr":"","mode":"","created_at":0}}}}}

note that: tran_order_no: trade serial number, amount: transaction amount, status: transaction status 1-presentation success, 0-presentation failure.

After receiving the callback information, the payment service processes and updates the state of the application order to be successful, and performs real-time clearing and updating of the data of 11 tables: the borrowing information table data is updated, and the borrowing state is updated from 'to be presented' to 'normal'; transaction flowing and transaction detail table: the transaction status is updated to "successful"; generating a written repayment schedule table: payment date, current period number, amount to be returned, etc.; writing a financial account receivable table and an account receivable detail table: the total amount to be collected, principal to be collected, interest to be collected, commission to be collected and the like; the loan and loan flow list records the principal amount and number, interest amount and number, commission amount and number, etc., and the payable and payable list writing system writes the payable and payable list into the user's payable amount and other detailed data, and the payable and payable list writes the actual payable amount, time, etc.

And verifying the correctness of the successfully presented financial table data according to the data in the test platform assembly line. By linking the mysql database, the relevant 11 pieces of table data are queried sequentially, for example: for borrowing with a single borrowing number of 25002400 (7 days of single borrowing period, principal 500, interest 40, commission 10, single total 550), the assuredly borrowed borrowing information table is verified by sequentially using assetequal function: whether the borrowing amount is=500, whether the borrowing state is=normal, a transaction flow meter and a transaction detail table: whether the transaction status=successful, whether the transaction amount=500, repayment schedule: whether the repayment date is=the current date+7, whether the current period number is=1, and whether the amount to be repayed is=550; financial receivables and receivables details: whether the total amount to be collected is=550, whether principal to be collected is=500, whether interest to be collected is=40, whether commission to be collected is=10, and the lending running list of subjects: whether principal subject amount and subject number=500 and 1000000, interest subject amount and subject number=40 and 1000011, commission subject amount and subject number=10 and 2000001, pays and pays the list: whether the amount=500, pays in fact and pays in fact list: whether the amount=500, and whether the status=successful. All the verification passes, the representative single-period borrowing products and the payment channel A can be normally cleared in real time, and 11-table data are correct. The test platform records a piece of data of successful money release of the number of the manufacturer, otherwise, the test platform records failure of the number of the manufacturer, and the mobile phone number is attached.

The test platform pipeline is periodically polled for an order with 'successful proposal'. The simulated bank truly calls back to the my payment service, where payment channels have been previously specified, with the status of the offer specified as "failed offer". And after receiving the callback information, the payment service changes the successfully-presented data into the failed-presented callback interface and rolls back the data information and the state.

And the test platform pipeline polls the data with the failure in the proposal and verifies whether the data is rolled back correctly. The test platform verifies by looking up 11 the table: for example: for borrowing with a single borrowing number of 25002400 (7 days of single borrowing period, principal 500, interest 40, commission 10, single total 550), the assuredly borrowed borrowing information table is verified by sequentially using assetequal function: whether borrowing status=to be presented, transaction flow meter and transaction detail table: whether the transaction status=pending, whether the transaction amount=500, repayment schedule: the borrowing data is deleted; financial receivables and receivables details: the borrowing data is deleted; lending line item list, which is a list of payable and payable details, with the borrowed data deleted: the borrowing data is deleted, real payment and real payment details list: status = pending. All of these verifications pass, the data is correctly rolled back on behalf of the single borrowing product and payment channel A. If one of the verification fails, the rollback of the data representing the single-period borrowing product and the payment channel A fails. Whether the test platform passes or fails, the test platform records the test result and the corresponding mobile phone number, borrows the number, and fails to pass the table with record failure verification, and the test result and the corresponding mobile phone number are actually and expected.

The test platform pipeline realizes batch change of borrowing states to overdue and writing of multi-table diapause amount through date adjustment and batch processing of scheduling tasks, namely a storage process. The test platform verifies that the date final batch processing scheduling task processing borrowing data is correct by inquiring 11 pieces of table data. For example: for borrowing with a single borrowing number of 25002400 (7 days of single borrowing period, principal 500, interest 40, commission 10, single total 550), the assuredly borrowed borrowing information table is verified by sequentially using assetequal function: whether the borrowing amount=500, whether the borrowing status=overdue, transaction flow meter and transaction detail table: no change, whether transaction status = successful, transaction amount = 500, repayment schedule: whether the repayment date=the current date+7, whether the current future number=1, whether the amount to be refund=550, whether the late fee=principal×5% of the overdue days (current date+batch number of days-repayment day); financial receivables and receivables details: whether the total amount to be received=550, whether principal to be received=500, whether interest to be received=40, whether commission to be received=10, whether principal to be received=5% of principal, the number of overdue days, the loan flow subject table: whether principal subject amount and subject number=500 and 1000000, interest subject amount and subject number=40 and 1000011, commission subject amount and subject number=10 and 2000001, late principal subject amount and subject number=principal 5% overdue days and 3000001, pays and pays the list of details: no change, amount = 500, pays in fact and pays in fact details table: no change, whether the amount=500, and status=successful. All the verification passes, and after the date batch processing scheduling task overdue the borrowing, the multi-table borrowing state is changed to overdue, and the written multi-table diapause is all correct. If one verification fails, the program is indicated to be problematic, and the test platform records the problem point. All the verification passes, and the test platform also records and attaches the mobile phone number and the borrowing number.

In summary, according to the method shown in fig. 3, the python test platform is capable of performing test verification on the single-term borrowing normal state, the triple-term borrowing normal state, the single-term borrowing overdue state, the triple-term borrowing overdue state, and the borrowing state with success before failure. Specifically, for the single-period borrowing normal state and the three-period borrowing normal state, the clear settlement result is analyzed and verified from 11 tables which are clear settlement, the result corresponds to the result without late deposit, and after the subject information is checked according to the product number, the test result is verified according to the 11 tables. The 11 tables mainly refer to 11 tables for real-time settlement of borrowing, and fig. 3 illustrates a borrowing information table, a transaction flow water meter, a transaction statement table, a repayment schedule table, a financial receivability statement table, a borrowing flow subject table, a payable statement table, a real payment statement table, etc., wherein specific numbers and names of the 11 tables can be flexibly set by those skilled in the art, and the invention is not limited herein. Similarly, for the single-term borrowing overdue state and the three-term borrowing overdue state, the clear settlement result is analyzed and verified from 11 clear settlement tables, corresponds to the result with the late fee, and after subject information is checked according to the product number, the test result is verified according to the 11 tables. In addition, for the borrowing data of which the withdrawal is successful and then fails, the condition of rollback and state change of the data needs to be verified, wherein the states of 5 data tables should be updated to fail, the state data of 6 data tables should be rolled back to be processed or deleted, and the automatic test can be realized by verifying whether the data states in 11 data tables are the same as the expected states. In addition, in order to facilitate the user to check, the test report can be further generated according to the clearing result without the late gold, the clearing result with the late gold and the results of data rollback and state change, so as to facilitate the user to inquire.

Fig. 4 shows a block diagram of a testing device of a payment system provided by an embodiment of the present disclosure.

Referring to fig. 4, an embodiment of the present disclosure provides a testing device 30 of a payment system, the testing device 30 of the payment system including:

an acquisition module 31 adapted to acquire the received payment test parameters; wherein the payment test parameters include: a payment object parameter, and a payment status parameter;

a generation module 32 adapted to generate virtual user information corresponding to the payment object parameters, and to send a payment test request containing the payment object parameters and the virtual user information to the payment system;

a sending module 33 adapted to send status feedback information to the payment system according to the payment status parameter if the payment system verifies the payment test request; the payment system is used for updating a payment data table according to the payment state parameters contained in the state feedback information;

a notification module 34 adapted to generate a test anomaly notification message in case the data value in the updated payment data table does not match the preset standard value; the preset standard value is determined according to the payment object parameter and the payment state parameter.

In an alternative implementation, the payment test parameters further include: testing an environment identifier;

and, the generation module is further adapted to: inquiring a system call interface corresponding to the test environment identifier in a configuration file; the system call interface corresponding to each test environment identifier at least comprises: the first call interface and the second call interface;

the generation module is specifically adapted to: invoking the first invoking interface, and sending a payment test request containing the payment object parameters and the virtual user information to the payment system;

the transmitting module is specifically adapted to: invoking the second invoking interface and sending state feedback information to the payment system;

wherein different test environment identifications correspond to different system call interfaces, and different system call interfaces correspond to different version numbers of the payment system.

In an alternative implementation, the payment test parameters further include: concurrent quantity parameters;

the generation module is specifically adapted to:

generating a plurality of virtual user information corresponding to the concurrency quantity parameter according to the concurrency quantity parameter;

and sending a plurality of payment test requests to the payment system in parallel, wherein virtual user information contained in each payment test request is different.

In an alternative implementation, the payment test parameters further include: payment channel parameters;

the transmitting module is specifically adapted to:

channel format information matched with the payment channel parameters is obtained from the configuration file;

performing format conversion processing on the payment state parameters according to the channel format information, and generating the state feedback information according to the payment state parameters after format conversion processing;

and obtaining channel identifiers corresponding to the payment channel parameters, and simulating the payment channels corresponding to the channel identifiers to send the state feedback information to the payment system.

In an alternative implementation, the payment test parameters further include: a payment term parameter; and the payment status parameter includes at least one of: a payment success state, a payment failure state, an nth stage payment success and an n+1th stage payment failure state; wherein N is a natural number;

and, the payment data table includes: a plurality of payment lists respectively corresponding to different payment states and/or payment objects, wherein each payment list comprises a plurality of fields;

the transmitting module is further adapted to:

screening a target list associated with the payment state parameter and the payment object parameter from a plurality of payment lists according to the payment state parameter and the payment object parameter;

Screening a plurality of fields contained in the target detail table for target fields associated with the payment status parameter and the payment object parameter;

and judging whether the data value in the updated payment data table is matched with a preset standard value or not according to the field data value of the target field in the target detail table.

In an alternative implementation, the notification module is specifically adapted to:

determining a target field which is not matched with the preset standard value as an abnormal field, and acquiring a comparison result between a field data value of the abnormal field and the preset standard value;

determining an abnormality type according to the abnormality field and the comparison result, and generating the test abnormality notification message according to the abnormality type;

the test abnormality notification message is used for being sent to the payment system so that the payment system can adjust according to the test abnormality notification message.

In an alternative implementation, the generating module is further adapted to:

according to the virtual user information, an identity authentication request is sent to an authentication module contained in the payment system;

under the condition that the identity authentication is passed, according to the payment object parameters, an object authentication request is sent to an object authentication module contained in the payment system; the object verification module is used for matching the payment object parameters with pre-stored payment object identifiers, and judging whether object verification passes or not according to a matching result.

In an alternative implementation, the virtual user information includes at least one of: virtual number information, virtual name information, virtual certificate information, virtual address information, virtual contact information, and virtual bank card information;

and, the payment test request includes: a borrowing type payment request; the payment data table includes at least one of: a borrowing data table, a repayment data table and a transaction detail table.

An embodiment of the present disclosure provides an electronic device with reference to fig. 5, including: at least one processor 501; at least one memory 502, and one or more I/O interfaces 503, coupled between the processor 501 and the memory 502; wherein the memory 502 stores one or more computer programs executable by the at least one processor 501, the one or more computer programs being executable by the at least one processor 501 to perform the above-described method of testing a payment system.

The disclosed embodiments also provide a computer readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor/processing core, implements the above-described method of testing a payment system. The computer readable storage medium may be a volatile or nonvolatile computer readable storage medium.

Embodiments of the present disclosure also provide a computer program product comprising computer readable code, or a non-transitory computer readable storage medium carrying computer readable code, which when run in a processor of an electronic device, performs the method of testing a payment system described above.

Those of ordinary skill in the art will appreciate that all or some of the steps, systems, functional modules/units in the apparatus, and methods disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between the functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed cooperatively by several physical components. Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer-readable storage media, which may include computer storage media (or non-transitory media) and communication media (or transitory media).

The term computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable program instructions, data structures, program modules or other data, as known to those skilled in the art. Computer storage media includes, but is not limited to, random Access Memory (RAM), read Only Memory (ROM), erasable Programmable Read Only Memory (EPROM), static Random Access Memory (SRAM), flash memory or other memory technology, portable compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical disc storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer. Furthermore, as is well known to those of ordinary skill in the art, communication media typically embodies computer readable program instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and may include any information delivery media.

The computer readable program instructions described herein may be downloaded from a computer readable storage medium to a respective computing/processing device or to an external computer or external storage device over a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers and/or edge servers. The network interface card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium in the respective computing/processing device.

Computer program instructions for performing the operations of the present disclosure can be assembly instructions, instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, c++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, aspects of the present disclosure are implemented by personalizing electronic circuitry, such as programmable logic circuitry, field Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), with state information of computer readable program instructions, which can execute the computer readable program instructions.

The computer program product described herein may be embodied in hardware, software, or a combination thereof. In an alternative embodiment, the computer program product is embodied as a computer storage medium, and in another alternative embodiment, the computer program product is embodied as a software product, such as a software development kit (Software Development Kit, SDK), or the like.

Various aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable medium having the instructions stored therein includes an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Example embodiments have been disclosed herein, and although specific terms are employed, they are used and should be interpreted in a generic and descriptive sense only and not for purpose of limitation. In some instances, it will be apparent to one skilled in the art that features, characteristics, and/or elements described in connection with a particular embodiment may be used alone or in combination with other embodiments unless explicitly stated otherwise. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the disclosure as set forth in the appended claims.

Claims

1. A method of testing a payment system, comprising:

2. The method of claim 1, wherein the payment test parameters further comprise: testing an environment identifier; before the generating of the virtual user information corresponding to the payment object parameters, the method further comprises: inquiring a system call interface corresponding to the test environment identifier in a configuration file; the system call interface corresponding to each test environment identifier at least comprises: the first call interface and the second call interface;

the sending a payment test request containing the payment object parameters and the virtual user information to the payment system includes: invoking the first invoking interface, and sending a payment test request containing the payment object parameters and the virtual user information to the payment system;

the sending status feedback information to the payment system includes: invoking the second invoking interface and sending state feedback information to the payment system;

Wherein different test environment identifiers correspond to different system call interfaces, and different system call interfaces correspond to different version numbers of the payment system.

3. The method of claim 2, wherein the payment test parameters further comprise: concurrent quantity parameters;

the generating virtual user information corresponding to the payment object parameters, and the sending a payment test request containing the payment object parameters and the virtual user information to the payment system includes:

4. A method according to claim 3, wherein the payment test parameters further comprise: payment channel parameters;

before the state feedback information is sent to the payment system according to the payment state parameters, the method further comprises the following steps:

The sending status feedback information to the payment system according to the payment status parameter includes: and obtaining channel identifiers corresponding to the payment channel parameters, and simulating the payment channels corresponding to the channel identifiers to send the state feedback information to the payment system.

5. The method of claim 4, wherein the concurrent quantity parameter is used to characterize a total number of multiple payment test requests concurrently performed, and wherein the payment test parameter further comprises: the environment concurrency configuration parameters and/or the channel concurrency configuration parameters;

the environment concurrency configuration parameters are used for representing the corresponding relation between the plurality of payment test requests executed concurrently and the test environment, and the channel concurrency configuration parameters are used for representing the corresponding relation between the plurality of payment test requests executed concurrently and the payment channels.

6. The method of claim 1, wherein the payment test parameters further comprise: a payment term parameter; and the payment status parameter includes at least one of: a payment success state, a payment failure state, an nth stage payment success and an n+1th stage payment failure state; wherein N is a natural number; the payment data table includes: a plurality of payment lists respectively corresponding to different payment states and/or payment objects, wherein each payment list comprises a plurality of fields;

After the state feedback information is sent to the payment system according to the payment state parameter, the method further comprises the following steps:

7. The method of claim 6, wherein generating the test anomaly notification message if the data value in the updated payment data table does not match the preset standard value comprises:

8. The method of claim 1, wherein prior to sending a payment test request containing the payment object parameters and the virtual user information to the payment system, further comprising:

under the condition that the identity authentication is passed, according to the payment object parameters, an object authentication request is sent to an object authentication module contained in the payment system; the object verification module is used for matching the payment object parameters with pre-stored payment object identifiers, and judging whether object verification passes or not according to a matching result;

the sending a payment test request containing the payment object parameters and the virtual user information to the payment system includes: and sending a payment test request containing the payment object parameters and the virtual user information to the payment system under the condition that the object verification is passed.

9. The method of claims 1-8, wherein the virtual user information comprises at least one of: virtual number information, virtual name information, virtual certificate information, virtual address information, virtual contact information, and virtual bank card information; the payment test request includes: a borrowing type payment request; the payment data table includes at least one of: a borrowing data table, a repayment data table and a transaction detail table.

10. A testing device for a payment system, comprising:

11. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores one or more computer programs executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.

12. A computer readable storage medium, on which a computer program is stored, which, when being executed by a processor, implements the method according to any of claims 1-9.