CN106354628A - Payment app test method and device thereof - Google Patents

Abstract

The present disclosure relates to a testing method and device for a payment application. The method includes: receiving the test environment information corresponding to the payment channel to be tested in the payment application to be tested; receiving test instructions; executing the payment test case corresponding to the payment channel to be tested, so as to simulate the user according to the preset account information in the Perform all the operational steps in the payment application to be tested; determine whether there is a fault in the payment channel to be tested according to whether the current payment result is consistent with the benchmark test result corresponding to the test case. This technical solution can automatically test whether there is a fault in the payment channel to be tested, so that the tester avoids the need to manually test the payment channel to be tested, reduces the consumption of human resources, and this automated test method can also effectively shorten the test time. , improve the accuracy and efficiency of test results.

Description

Method and device for testing payment application

technical field

The present disclosure relates to the technical field of testing, in particular to a testing method and device for payment applications.

Background technique

At present, after developing an application that can complete various payment functions, before releasing the application, it is necessary to test the application to determine whether its various payment functions are normal, so as to avoid causing great inconvenience to users in the later stage. Inconvenient, but the tests in related technologies are all manually tested on various payment channels such as bank cards, Alipay, WeChat, and various payment products such as recharge, consumption, cash withdrawal, and transfer, which greatly wastes human resources. The test time is also relatively long, and the content and use cases required to be tested by different payment channels are roughly the same, which will lead to a lot of useless work.

Contents of the invention

Embodiments of the present disclosure provide a testing method and device for a payment application. Described technical scheme is as follows:

According to the first aspect of the embodiments of the present disclosure, a payment application testing method is provided, including:

Receive test environment information corresponding to the payment channel to be tested in the payment application to be tested, wherein the test environment information includes: preset account information and a payment test case corresponding to the payment channel to be tested, and the payment test case For recording all operational steps related to the payment channel to be tested that can be executed in the payment application to be tested according to the preset account information;

Receive test instructions;

Executing the payment test case corresponding to the payment channel to be tested to simulate the user performing all the operational steps in the payment application to be tested according to the preset account information;

According to whether the current payment result is consistent with the benchmark test result corresponding to the test case, it is determined whether there is a fault in the payment channel to be tested.

In one embodiment, determining whether there is a fault in the payment channel to be tested according to whether the current payment result is consistent with the benchmark test result corresponding to the test case includes:

When the current payment result is consistent with the benchmark test result, it is determined that there is no fault in the payment channel to be tested.

In one embodiment, determining whether there is a fault in the payment channel to be tested according to whether the current payment result is consistent with the benchmark test result corresponding to the test case includes:

When the current payment result is inconsistent with the benchmark test result, it is determined that there is a fault in the payment method to be tested;

Prompt fault information.

In one embodiment, the method also includes:

When the preset execution condition is met, re-execute the payment test case or execute the payment test case modified according to the current payment result until the current payment result of the payment test case is consistent with the benchmark test result , to determine that there is no fault in the payment channel to be tested,

Wherein, the preset execution conditions include at least one of the following conditions:

It is monitored that the payment test case or the program corresponding to the payment channel to be tested is modified;

receiving a test instruction to re-test the payment channel to be tested;

The current time reaches the preset test time for retesting the payment channel to be tested.

In one embodiment, the method also includes:

After adding a new payment channel to the payment application to be tested, receiving test environment information corresponding to the new payment channel.

In one embodiment, the method also includes:

After adding a new payment product to the payment application to be tested, receiving the test environment information of the new payment product under each payment channel to be tested;

Obtain benchmark results corresponding to the new payment product.

According to the second aspect of the embodiments of the present disclosure, there is also provided a payment application testing device, including:

A deployment module, configured to receive test environment information corresponding to a payment channel to be tested in a payment application to be tested, wherein the test environment information includes: preset account information and a payment test case corresponding to the payment channel to be tested, and The payment test case is used to record all operable steps related to the payment channel to be tested that can be executed in the payment application to be tested according to the preset account information;

A control module, configured to receive a test instruction, and execute a payment test case corresponding to the payment channel to be tested, so as to simulate the user performing all the operational steps in the payment application to be tested according to the preset account information;

The verification module is configured to determine whether there is a fault in the payment channel to be tested according to whether the current payment result is consistent with the benchmark test result corresponding to the test case.

In one embodiment, the verification module includes:

The first determining submodule is configured to determine that there is no fault in the payment channel to be tested when the current payment result is consistent with the benchmark test result.

In one embodiment, the verification module includes:

The second determining submodule is used to determine that there is a fault in the payment channel to be tested when the current payment result is inconsistent with the benchmark test result;

Prompt sub-module, used to prompt fault information.

In one embodiment, the device also includes:

An execution module, configured to re-execute the payment test case or execute the payment test case modified according to the current payment result when the preset execution condition is satisfied, until the current payment result of the payment test case is consistent with the benchmark When the test results are consistent, it is determined that there is no fault in the payment channel to be tested,

Wherein, the preset execution conditions include at least one of the following conditions:

It is monitored that the payment test case or the program corresponding to the payment channel to be tested is modified;

receiving a test instruction to re-test the payment channel to be tested;

The current time reaches the preset test time for retesting the payment channel to be tested.

In one embodiment, the device also includes:

The first receiving module is configured to receive test environment information corresponding to the new payment channel after adding the new payment channel to the payment application to be tested.

In one embodiment, the device also includes:

The second receiving module is configured to receive the test environment information of the new payment product under each payment channel to be tested after adding the new payment product to the payment application to be tested;

An acquisition module, configured to acquire benchmark test results corresponding to the new payment product.

According to a third aspect of the embodiments of the present disclosure, a payment application testing device is provided, including:

processor;

memory for storing processor-executable instructions;

Wherein, the processor is configured as:

Receive test environment information corresponding to the payment channel to be tested in the payment application to be tested, wherein the test environment information includes: preset account information and a payment test case corresponding to the payment channel to be tested, and the payment test case For recording all operational steps related to the payment channel to be tested that can be executed in the payment application to be tested according to the preset account information;

Receive test instructions;

Executing the payment test case corresponding to the payment channel to be tested to simulate the user performing all the operational steps in the payment application to be tested according to the preset account information;

According to whether the current payment result is consistent with the benchmark test result corresponding to the test case, it is determined whether there is a fault in the payment channel to be tested.

The technical solutions provided by the embodiments of the present disclosure may include the following beneficial effects:

After receiving the test environment information corresponding to the payment channel to be tested in the payment application to be tested, if a test instruction is received, the payment test case can be automatically executed, and according to the actual current payment result of the payment test case and the payment test case Whether the corresponding benchmark test results are consistent can accurately determine whether there is a fault in the payment channel to be tested, and this automatic test method for testing whether there is a fault in the payment channel to be tested enables testers to avoid the need to manually test the payment channel to be tested. It reduces the consumption of human resources, and at the same time, this automated testing method can also effectively shorten the test duration and improve the accuracy and efficiency of test results.

The technical solutions provided by the embodiments of the present disclosure, it should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure.

Description of drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description serve to explain the principles of the disclosure.

Fig. 1 is a flowchart showing a method for testing a payment application according to an exemplary embodiment.

Fig. 2A is a flow chart showing another payment application testing method according to an exemplary embodiment.

Fig. 2B is a flow chart showing another method for testing a payment application according to an exemplary embodiment.

Fig. 3 is a block diagram showing a test device for a payment application according to an exemplary embodiment.

Fig. 4 is a block diagram of another payment application testing device according to an exemplary embodiment.

Fig. 5 is a block diagram of another payment application testing device according to an exemplary embodiment.

Fig. 6 is a block diagram of another payment application testing device according to an exemplary embodiment.

Fig. 7 is a block diagram of another payment application testing device according to an exemplary embodiment.

Fig. 8 is a block diagram of another payment application testing device according to an exemplary embodiment.

Fig. 9 is a block diagram showing a test device suitable for payment applications according to an exemplary embodiment.

detailed description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatuses and methods consistent with aspects of the present disclosure as recited in the appended claims.

At present, after developing an application that can complete various payment functions, before releasing the application, it is necessary to test the application to determine whether its various payment functions are normal, so as to avoid causing great inconvenience to users in the later stage. Inconvenient, but the tests in related technologies are all manually tested on various payment channels such as bank cards, Alipay, WeChat, and various payment products such as recharge, consumption, cash withdrawal, and transfer, which greatly wastes human resources. The test time is also relatively long, and the content and use cases required to be tested by different payment channels are roughly the same, which will lead to a lot of useless work.

In order to solve the above technical problems, an embodiment of the present disclosure provides a payment application testing method, which can be used in a payment application testing program, system or device, as shown in Figure 1, the method includes steps S101 to S104:

In step S101, the test environment information corresponding to the payment channel to be tested in the payment application to be tested is received, wherein the test environment information includes: the default account information and the payment test case corresponding to the payment channel to be tested, and the payment test case uses To record all operational steps related to the payment channel to be tested that can be executed in the payment application to be tested according to the preset account information.

The payment application to be tested can be any application developed with payment functions, and the payment channel to be tested can be various payment channels such as WeChat payment channel, Alipay payment channel, bank card payment channel or intimate payment payment channel.

Secondly, the preset account information can be simulated login account information for logging into the payment application to be tested, the simulated contact information of the user corresponding to the login account information, and the simulated login account information. Binding Alipay account, bank card account, WeChat account, bus card account and other payment accounts that enable the payment application under test to complete the payment function.

In addition, the payment test case is an automated test script for testing whether the payment channel to be tested is faulty, and in order to enable the payment test case to perform a comprehensive automated test on the payment channel to be tested, the coverage of the payment test case should be as large as possible For example, the payment test case may include: opening and logging into the payment application to be tested, and then completing the payment operation steps for various existing payment products such as consumption, transfer, and recharge under the payment channel to be tested. Of course, the The payment test case may also include using different payment accounts such as different bank cards to complete the payment operation steps for the above-mentioned existing payment products under the same payment channel to be tested.

Finally, the test environment information includes but is not limited to the default account information and the payment test case corresponding to the payment channel to be tested, for example: it can also include preparing the database (wherein, the specific steps of preparing the database can be: use DDL (Data Definition Language) before deleting Data Definition Language) to create a data storage table for storing various historical data, use DDL to recreate a new storage table for storing test environment information, and use DML (Data Manipulation Language Data Manipulation Language) to load the test environment information to the created new storage table, etc.), and even include: a program for simulating sending feedback information to the user, such as a program for simulating the bank sending the transfer information to the user or simulating the bank sending the paid funds to the user, or It is a program for simulating the operator sending the recharge amount to the user, etc.

In step S102, a test instruction is received.

In step S103, the payment test case corresponding to the payment channel to be tested is executed to simulate the user performing all operational steps in the payment application to be tested according to preset account information.

When the test instruction is received, by executing the payment test case corresponding to the payment channel to be tested, it can be simulated that the user performs all the operational steps corresponding to the payment method to be tested on the application to be tested according to the preset account information, that is, the simulation In the application to be tested, the user completes a series of payment operations such as consumption, transfer, and recharge through the payment channel to be tested.

In step S104, according to whether the current payment result is consistent with the benchmark test result corresponding to the test case, it is determined whether there is a fault in the payment channel to be tested.

According to whether the actual current payment result of the payment test case is consistent with the benchmark test result corresponding to the payment test case, it can be accurately determined whether there is a fault in the payment channel to be tested, and this automatic test method for testing whether there is a fault in the payment channel to be tested, It avoids the need for testers to manually test the payment channel to be tested, reducing the consumption of human resources. At the same time, this automated testing method can also effectively shorten the test duration and improve the accuracy and efficiency of test results.

In addition, because testers can finally determine whether there is a fault in the payment channel to be tested according to whether the payment result is consistent with the benchmark test result, there is no need to check the intermediate link of the payment operation. Therefore, the test logic of the present disclosure is simpler and the test efficiency is improved. higher.

In one embodiment, the above step S104 in FIG. 1 may be executed as:

When the current payment result is consistent with the benchmark test result, it is determined that there is no fault in the payment channel to be tested.

When the current payment result is consistent with the benchmark test result, it means that the automated test result is the same as the expected benchmark test result. Therefore, it can be automatically determined that there is no fault in the payment channel to be tested, that is, the corresponding program of the payment channel to be tested in the application to be tested , the port used and other information are correct.

In one embodiment, the above step S104 in FIG. 1 can also be executed as:

When the current payment result is inconsistent with the benchmark test result, it is determined that there is a fault in the payment channel to be tested.

The current payment result of the payment test case is inconsistent with the benchmark test result, which means that the current payment result of the payment test case is different from the expected benchmark test result, for example: when the payment test case is to log in to the application to be tested, search for product A, select price B When using the XX bank account in the Alipay payment channel to purchase the A product, the benchmark test result is that the A product is successfully purchased using Alipay, and Alipay and XX bank will each feed back a consumption of B yuan. Therefore, in On the basis that the balance in the XX bank account is not less than B yuan, if the automated test result of the payment test case (that is, the current payment result) is that the product A at the price B cannot be successfully purchased, or the simulated Alipay program or XX has not been received The information of spending B yuan fed back by the bank payment program indicates that the current payment result of the payment test case is inconsistent with the benchmark test result.

Fault information is prompted, wherein the fault information may include the current payment result, and may also include the correct payment result, that is, the benchmark test result.

When the current payment result is inconsistent with the expected benchmark test result, it means that there is a problem with the preparation of the payment test case or the program corresponding to the payment channel to be tested has a problem, which leads to the failure to correctly process the payment channel under the test. The payment is completed. Therefore, by prompting the fault information, the tester can be prompted to modify the payment test case or the program corresponding to the payment channel to be tested according to the current payment result.

In addition, when prompting the fault information, the prompt fault information can be prompted in the form of logs, so that it is convenient for testers to analyze the problem by viewing the error log, that is, to analyze whether it is an error in the payment test case or the program corresponding to the payment channel to be tested Errors, or program errors in other parts of the application to be tested, and the latter two types of errors are the errors to be analyzed mainly, and relate to the errors of the application to be tested itself.

In one embodiment, the method also includes:

When the preset execution conditions are met, re-execute the payment test case or execute the payment test case modified according to the current payment result until the current payment result of the payment test case is consistent with the benchmark test result, and determine that there is no fault in the payment channel to be tested.

Among them, the preset execution conditions include at least one of the following conditions:

It is monitored that the payment test case or the program corresponding to the payment channel to be tested is modified.

Received a test order to retest the payment channel to be tested.

The current time reaches the preset test time for retesting the payment channel to be tested.

When at least one of the above conditions is met, it means that the payment channel to be tested needs to be tested again. Therefore, the payment test case can be re-executed or the payment test case modified by the tester according to the current payment result can be re-executed until the payment test case is completed. When the current payment result is consistent with the benchmark test result, it can be determined that there is no fault in the payment channel to be tested, so as to stop retesting the payment channel to be tested, and not re-execute the payment test case or the modified payment test case.

As shown in Figure 2A, in one embodiment, the above-mentioned method shown in Figure 1 may further include:

In step S201, after a new payment channel is added to the payment application to be tested, test environment information corresponding to the new payment channel is received.

After adding a new payment channel to the payment application to be tested, by receiving the test environment information corresponding to the new payment channel, the new payment channel can be automatically tested by paying for existing payment products in the application to be tested .

Secondly, the test environment information corresponding to the new payment channel may include: new account information and a new payment test case that the new payment channel needs to use, wherein the new payment test case is used to record Account information and/or all operable steps related to the new test payment channel that can be performed in the payment application to be tested by the new account information, for example: if the new test channel is XX bank card and the existing payment product is For recharge business, the new account information should be a simulated XX bank card number, and the new payment test case can record the operation steps of using the XX bank card number to pay for the recharge product in the payment application to be tested .

In addition, even if there is a difference between the payment steps of different payment channels, it is necessary to redeploy new test environment information when adding a new payment channel, but because there may be some same steps between the payment steps of different payment channels , therefore, when testers redeploy new test cases in the new test environment information, they can learn from the existing payment test cases, and carry out the existing test cases according to the difference payment steps between the two payment channels Adaptive modification, you can get new test cases that are compatible with the newly added payment channels, thereby enhancing the compatibility and scalability of test cases, and reducing the complexity of testers' operations and work, for example:

When using Alipay and WeChat to pay for the same payment product (such as recharge, consumption, etc.), since all the previous operation steps in the payment operation process of the two are the same, the difference is limited to the final choice of Alipay The payment channel is still the WeChat payment channel. Therefore, the difference between the test cases corresponding to the Alipay payment channel and the WeChat payment channel is limited to the final payment step (that is, whether to choose the Alipay payment channel or the WeChat payment channel, and when choosing different A series of operations after the payment channel), therefore, the test cases corresponding to the two payment channels can learn from each other and make a slight adaptive adjustment, so that the tester does not need to completely rewrite the test case, which also enhances the test Compatibility and scalability of use cases, and reduce the operation and work complexity of testers.

As shown in Figure 2B, in one embodiment, the above-mentioned method shown in Figure 1 may further include:

In step S202, after a new payment product is added to the payment application to be tested, the test environment information of the new payment product under each payment channel to be tested is received.

New payment products can be various payment products such as recharge, consumption, cash withdrawal or transfer, and consumption refers to the purchase of various products in the application to be tested (among them, the products that can be purchased include: commodities, tickets and other items) The payment operation or the operation of sending red envelopes.

In step S203, the benchmark test results corresponding to the new payment product are acquired.

After adding a new payment product to the payment application to be tested, by receiving the test environment information of the new payment product under each payment channel to be tested and obtaining the benchmark test results corresponding to the new payment product, according to the new The test environment information of the payment product under each payment channel to be tested is used for automated testing of the new payment product, and the benchmark test results corresponding to the new payment product are used to verify whether the new payment product is faulty.

Wherein, the test environment information of the new payment product under each payment channel to be tested may include: a new payment test case for performing a payment test on the new payment product under each payment channel to be tested.

In addition, testers are deploying the new payment test case. If the payment steps between the new payment product and the original payment product in the payment application to be tested are similar, they can also The difference payment steps between the original payment products, adaptive modification of the existing payment test cases, so that the testers do not need to completely rewrite the test cases, to enhance the compatibility and scalability of the test cases, and reduce the test Operation and work complexity of personnel.

In addition, due to the different fund flow status of different payment products such as recharge, consumption, cash withdrawal and transfer, such as positive/negative fund flow, the types of accounts with fund flow are different, and even the number of accounts with fund flow is also different. For example: when the payment channel to be tested is the debit card fast payment channel of XX bank, when the debit card of XX bank is used to recharge SIM card A, the capital flow in the debit card of XX bank is negative, The fund flow in the user balance M corresponding to the debit card in the payment application to be tested is positive, the deduction step is completed, and the fund changes of the debit card and the user balance M are received, and then the fund flow of the user balance M is received negative, the operator’s merchant’s capital balance flow is positive, and at the same time initiates a recharge request to the operator, and the operator responds and completes the recharge step. Therefore, it will receive the user’s balance M and the operator’s capital change again; and when using When the debit card under XX Bank transfers money to the user account N in the payment application to be tested by another simulated user, the capital flow in the debit card is negative, and the capital flow in the user balance M is positive. The fund change of the bank card and user balance M has completed the deduction step, and then the fund flow of the user balance M is negative, and the fund balance flow of the user account N is positive, and the transfer step is completed. Therefore, the user balance will be received again The fund changes of M and user balance N, so when deploying the benchmark test results, testers can formulate according to the fund flow status in the preset account information under the new payment product. After the fund flow status in the account information has been established, in order to ensure the accuracy and credibility of the benchmark test results, it is also possible to further manually verify whether the benchmark test results are correct, and only after the verification is correct will the It is used as a benchmark result to verify that the new payment product is not malfunctioning.

Finally, the benchmark test results can use json ((JavaScript Object Notation, a lightweight data exchange format), yaml (Yet Another Markup Language, another markup language), xml (Extensible Markup Language, Extensible Markup Language ) and other markup languages to facilitate compatibility with more systems.

Corresponding to the above-mentioned payment application testing method provided by the embodiment of the present disclosure, the embodiment of the present disclosure also provides a payment application testing device, as shown in FIG. 3 , the device includes:

The deployment module 301 is configured to receive test environment information corresponding to the payment channel to be tested in the payment application to be tested, wherein the test environment information includes: default account information and payment test cases corresponding to the payment channel to be tested, and the payment test The use case is configured to record all operational steps related to the payment channel to be tested that can be executed in the payment application to be tested according to the preset account information.

The control module 302 is configured to receive a test instruction and execute a payment test case corresponding to the payment channel to be tested, so as to simulate the user performing all operational steps in the payment application to be tested according to preset account information.

The verification module 303 is configured to determine whether there is a fault in the payment channel to be tested according to whether the current payment result is consistent with the benchmark test result corresponding to the test case.

According to whether the actual current payment result of the payment test case is consistent with the benchmark test result corresponding to the payment test case, it can be accurately determined whether there is a fault in the payment channel to be tested, and this automatic test method for testing whether there is a fault in the payment channel to be tested, It avoids the need for testers to manually test the payment channel to be tested, reducing the consumption of human resources. At the same time, this automated testing method can also effectively shorten the test duration and improve the accuracy and efficiency of test results.

As shown in FIG. 4, in one embodiment, the above verification module 303 shown in FIG. 3 may include:

The first determination sub-module 3031 is configured to determine that there is no fault in the payment channel to be tested when the current payment result is consistent with the benchmark test result.

When the current payment result is consistent with the benchmark test result, it means that the automated test result is the same as the expected benchmark test result. Therefore, it can be automatically determined that there is no fault in the payment channel to be tested, that is, the corresponding program of the payment channel to be tested in the application to be tested , the port used and other information are correct.

As shown in FIG. 5, in one embodiment, the above verification module 303 shown in FIG. 3 may include:

The second determination sub-module 3032 is configured to determine that there is a fault in the payment channel to be tested when the current payment result is inconsistent with the benchmark test result.

The prompting submodule 3033 is configured to prompt fault information.

When the current payment result is inconsistent with the expected benchmark test result, it means that there is a problem with the preparation of the payment test case or the program corresponding to the payment channel to be tested has a problem, which leads to the failure to correctly process the payment channel under the test. The payment is completed. Therefore, by prompting the fault information, the tester can be prompted to modify the payment test case or the program corresponding to the payment channel to be tested according to the current payment result.

As shown in Figure 6, in one embodiment, the device shown in Figure 3 above may further include:

The execution module 601 is configured to re-execute the payment test case or execute the payment test case modified according to the current payment result when the preset execution condition is met, until the current payment result of the payment test case is consistent with the benchmark test result, determine The test payment channel is not faulty,

Among them, the preset execution conditions include at least one of the following conditions:

It is monitored that the payment test case or the program corresponding to the payment channel to be tested is modified.

Received a test order to retest the payment channel to be tested.

The current time reaches the preset test time for retesting the payment channel to be tested.

When at least one of the above conditions is met, it means that the payment channel to be tested needs to be tested again. Therefore, the payment test case can be re-executed or the payment test case modified by the tester according to the current payment result can be re-executed until the payment test case is completed. When the current payment result is consistent with the benchmark test result, it can be determined that there is no fault in the payment channel to be tested, so as to stop retesting the payment channel to be tested, and not re-execute the payment test user or the modified payment test case.

As shown in Figure 7, in one embodiment, the device shown in Figure 3 above may further include:

The first receiving module 701 is configured to receive test environment information corresponding to the new payment channel after adding the new payment channel to the payment application to be tested.

After adding a new payment channel to the payment application to be tested, by receiving the test environment information corresponding to the new payment channel, the new payment channel can be automatically tested by paying for existing payment products in the application to be tested .

As shown in Figure 8, in one embodiment, the device shown in Figure 3 above may further include:

The second receiving module 801 is configured to receive the test environment information of the new payment product under each payment channel to be tested after adding the new payment product to the payment application to be tested.

The obtaining module 802 is configured to obtain benchmark test results corresponding to the new payment product.

After adding a new payment product to the payment application to be tested, by receiving the test environment information of the new payment product under each payment channel to be tested, and obtaining the benchmark test results corresponding to the new payment product, the new payment product can be Payment products are automated tests to verify whether the new payment product is faulty.

According to a third aspect of the embodiments of the present disclosure, a payment application testing device is provided, including:

processor;

memory for storing processor-executable instructions;

where the processor is configured as:

Receive test environment information corresponding to the payment channel to be tested in the payment application to be tested, wherein the test environment information includes: preset account information and a payment test case corresponding to the payment channel to be tested, and the payment test case For recording all operational steps related to the payment channel to be tested that can be executed in the payment application to be tested according to the preset account information;

Receive test instructions;

Executing the payment test case corresponding to the payment channel to be tested to simulate the user performing all the operational steps in the payment application to be tested according to the preset account information;

According to whether the current payment result is consistent with the benchmark test result corresponding to the test case, it is determined whether there is a fault in the payment channel to be tested.

The processors described above can also be configured to:

According to whether the current payment result is consistent with the benchmark test result corresponding to the test case, determining whether there is a fault in the payment channel to be tested includes:

When the current payment result is consistent with the benchmark test result, it is determined that there is no fault in the payment channel to be tested.

The processors described above can also be configured to:

According to whether the current payment result is consistent with the benchmark test result corresponding to the test case, determining whether there is a fault in the payment channel to be tested includes:

When the current payment result is inconsistent with the benchmark test result, it is determined that there is a fault in the payment method to be tested;

Prompt fault information.

The processors described above can also be configured to:

The method also includes:

When the preset execution condition is met, re-execute the payment test case or execute the payment test case modified according to the current payment result until the current payment result of the payment test case is consistent with the benchmark test result , to determine that there is no fault in the payment channel to be tested,

Wherein, the preset execution conditions include at least one of the following conditions:

It is monitored that the payment test case or the program corresponding to the payment channel to be tested is modified;

receiving a test instruction to re-test the payment channel to be tested;

The current time reaches the preset test time for retesting the payment channel to be tested.

The processors described above can also be configured to:

The method also includes:

After adding a new payment channel to the payment application to be tested, receiving test environment information corresponding to the new payment channel.

The processors described above can also be configured to:

The method also includes:

After adding a new payment product to the payment application to be tested, receiving the test environment information of the new payment product under each payment channel to be tested;

Obtain benchmark results corresponding to the new payment product.

Fig. 9 is a block diagram showing a test device 900 for a payment application according to an exemplary embodiment, and the device is suitable for a terminal device. For example, the apparatus 900 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, and the like.

9, device 900 may include one or at least two of the following components: processing component 902, memory 904, power supply component 906, multimedia component 908, audio component 910, input/output (I/O) interface 912, sensor component 914, and communication component 916 .

The processing component 902 generally controls the overall operations of the device 900, such as those associated with display, telephone calls, data communications, camera operations, and recording operations. The processing component 902 may include one or at least two processors 920 to execute instructions to complete all or part of the steps of the above method. Additionally, the processing component 902 may include one or at least two modules to facilitate interaction between the processing component 902 and other components. For example, processing component 902 may include a multimedia module to facilitate interaction between multimedia component 908 and processing component 902 .

The memory 904 is configured to store various types of data to support operations at the device 900 . Examples of such data include instructions for any stored objects or methods operating on device 900, contact user data, phonebook data, messages, pictures, videos, and the like. The memory 904 can be implemented by any type of volatile or non-volatile memory device or their combination, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), Magnetic Memory, Flash Memory, Magnetic or Optical Disk.

The power supply component 906 provides power to various components of the device 900 . Power supply components 906 may include a power management system, one or at least two power supplies, and other components associated with generating, managing, and distributing power to device 900 .

The multimedia component 908 includes a screen that provides an output interface between the device 900 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or at least two touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense a boundary of a touch or swipe action, but also detect duration and pressure associated with the touch or swipe action. In some embodiments, the multimedia component 908 includes a front camera and/or a rear camera. When the device 900 is in an operation mode, such as a shooting mode or a video mode, the front camera and/or the rear camera can receive external multimedia data. Each front camera and rear camera can be a fixed optical lens system or have focal length and optical zoom capability.

The audio component 910 is configured to output and/or input audio signals. For example, the audio component 910 includes a microphone (MIC) configured to receive external audio signals when the device 900 is in operation modes, such as call mode, recording mode and voice recognition mode. Received audio signals may be further stored in memory 904 or sent via communication component 916 . In some embodiments, the audio component 910 also includes a speaker for outputting audio signals.

The I/O interface 912 provides an interface between the processing component 902 and a peripheral interface module. The peripheral interface module may be a keyboard, a click wheel, a button, and the like. These buttons may include, but are not limited to: a home button, volume buttons, start button, and lock button.

Sensor assembly 914 includes one or at least two sensors for providing various aspects of status assessment for device 900 . For example, the sensor component 914 can detect the open/closed state of the device 900, the relative positioning of components, such as the display and keypad of the device 900, and the sensor component 914 can also detect a change in the position of the device 900 or a component of the device 900 , the presence or absence of user contact with the device 900 , the device 900 orientation or acceleration/deceleration and the temperature change of the device 900 . Sensor assembly 914 may include a proximity sensor configured to detect the presence of nearby objects in the absence of any physical contact. Sensor assembly 914 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor component 914 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor or a temperature sensor.

The communication component 916 is configured to facilitate wired or wireless communication between the apparatus 900 and other devices. The device 900 can access wireless networks based on communication standards, such as WiFi, 2G or 3G, or a combination thereof. In one exemplary embodiment, the communication component 916 receives broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 916 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wide Band (UWB) technology, Bluetooth (BT) technology and other technologies.

In an exemplary embodiment, apparatus 900 may be implemented by one or at least two Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable A programmable gate array (FPGA), controller, microcontroller, microprocessor or other electronic component implementation for performing the methods described above.

In an exemplary embodiment, there is also provided a non-transitory computer-readable storage medium including instructions, such as the memory 904 including instructions, which can be executed by the processor 920 of the device 900 to implement the above method. For example, the non-transitory computer readable storage medium may be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like.

A non-transitory computer-readable storage medium, when the instructions in the storage medium are executed by the processor of the above-mentioned device 900, the above-mentioned device 900 can execute a method for testing a payment application, including:

Receive test environment information corresponding to the payment channel to be tested in the payment application to be tested, wherein the test environment information includes: preset account information and a payment test case corresponding to the payment channel to be tested, and the payment test case For recording all operational steps related to the payment channel to be tested that can be executed in the payment application to be tested according to the preset account information;

Receive test instructions;

Executing the payment test case corresponding to the payment channel to be tested to simulate the user performing all the operational steps in the payment application to be tested according to the preset account information;

According to whether the current payment result is consistent with the benchmark test result corresponding to the test case, it is determined whether there is a fault in the payment channel to be tested.

In one embodiment, determining whether there is a fault in the payment channel to be tested according to whether the current payment result is consistent with the benchmark test result corresponding to the test case includes:

When the current payment result is consistent with the benchmark test result, it is determined that there is no fault in the payment channel to be tested.

In one embodiment, determining whether there is a fault in the payment channel to be tested according to whether the current payment result is consistent with the benchmark test result corresponding to the test case includes:

When the current payment result is inconsistent with the benchmark test result, it is determined that there is a fault in the payment method to be tested;

Prompt fault information.

In one embodiment, the method also includes:

When the preset execution condition is met, re-execute the payment test case or execute the payment test case modified according to the current payment result until the current payment result of the payment test case is consistent with the benchmark test result , to determine that there is no fault in the payment channel to be tested,

Wherein, the preset execution conditions include at least one of the following conditions:

It is monitored that the payment test case or the program corresponding to the payment channel to be tested is modified;

receiving a test instruction to re-test the payment channel to be tested;

The current time reaches the preset test time for retesting the payment channel to be tested.

In one embodiment, the method also includes:

After adding a new payment channel to the payment application to be tested, receiving test environment information corresponding to the new payment channel.

In one embodiment, the method also includes:

After adding a new payment product to the payment application to be tested, receiving the test environment information of the new payment product under each payment channel to be tested;

Obtain benchmark results corresponding to the new payment product.

Other embodiments of the present disclosure will be readily apparent to users skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any modification, use or adaptation of the present disclosure, and these modifications, uses or adaptations follow the general principles of the present disclosure and include common knowledge or conventional technical means in the technical field not disclosed in the present disclosure . The specification and examples are to be considered exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It should be understood that the present disclosure is not limited to the precise constructions which have been described above and shown in the drawings, and various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims (13)

1. A method for testing a payment application, comprising: Receive test environment information corresponding to the payment channel to be tested in the payment application to be tested, wherein the test environment information includes: preset account information and a payment test case corresponding to the payment channel to be tested, and the payment test case For recording all operational steps related to the payment channel to be tested that can be executed in the payment application to be tested according to the preset account information; Receive test instructions; Executing the payment test case corresponding to the payment channel to be tested to simulate the user performing all the operational steps in the payment application to be tested according to the preset account information; According to whether the current payment result is consistent with the benchmark test result corresponding to the test case, it is determined whether there is a fault in the payment channel to be tested. 2. The method of claim 1, wherein, According to whether the current payment result is consistent with the benchmark test result corresponding to the test case, determining whether there is a fault in the payment channel to be tested includes: When the current payment result is consistent with the benchmark test result, it is determined that there is no fault in the payment channel to be tested. 3. The method according to claim 1 or 2, characterized in that, According to whether the current payment result is consistent with the benchmark test result corresponding to the test case, determining whether there is a fault in the payment channel to be tested includes: When the current payment result is inconsistent with the benchmark test result, it is determined that there is a fault in the payment method to be tested; Prompt fault information. 4. The method according to claim 1, wherein the method further comprises: When the preset execution condition is met, re-execute the payment test case or execute the payment test case modified according to the current payment result until the current payment result of the payment test case is consistent with the benchmark test result , to determine that there is no fault in the payment channel to be tested, Wherein, the preset execution conditions include at least one of the following conditions: It is monitored that the payment test case or the program corresponding to the payment channel to be tested is modified; receiving a test instruction to re-test the payment channel to be tested; The current time reaches the preset test time for retesting the payment channel to be tested. 5. The method according to claim 1, wherein the method further comprises: After adding a new payment channel to the payment application to be tested, receiving test environment information corresponding to the new payment channel. 6. The method according to claim 1, further comprising: After adding a new payment product to the payment application to be tested, receiving the test environment information of the new payment product under each payment channel to be tested; Obtain benchmark results corresponding to the new payment product. 7. A test device for payment application, comprising: A deployment module, configured to receive test environment information corresponding to a payment channel to be tested in a payment application to be tested, wherein the test environment information includes: preset account information and a payment test case corresponding to the payment channel to be tested, and The payment test case is used to record all operable steps related to the payment channel to be tested that can be executed in the payment application to be tested according to the preset account information; A control module, configured to receive a test instruction, and execute a payment test case corresponding to the payment channel to be tested, so as to simulate the user performing all the operational steps in the payment application to be tested according to the preset account information; The verification module is configured to determine whether there is a fault in the payment channel to be tested according to whether the current payment result is consistent with the benchmark test result corresponding to the test case. 8. The device of claim 7, wherein: The verification module includes: The first determination submodule is configured to determine that there is no fault in the payment channel to be tested when the current payment result is consistent with the benchmark test result. 9. Apparatus according to claim 7 or 8, characterized in that The verification module includes: The second determining submodule is used to determine that there is a fault in the payment channel to be tested when the current payment result is inconsistent with the benchmark test result; Prompt sub-module, used to prompt fault information. 10. The device according to claim 7, further comprising: An execution module, configured to re-execute the payment test case or execute the payment test case modified according to the current payment result when the preset execution condition is satisfied, until the current payment result of the payment test case is consistent with the benchmark When the test results are consistent, it is determined that there is no fault in the payment channel to be tested, Wherein, the preset execution conditions include at least one of the following conditions: It is monitored that the payment test case or the program corresponding to the payment channel to be tested is modified; receiving a test instruction to re-test the payment channel to be tested; The current time reaches the preset test time for retesting the payment channel to be tested. 11. The device according to claim 7, further comprising: The first receiving module is configured to receive test environment information corresponding to the new payment channel after adding the new payment channel to the payment application to be tested. 12. The device according to claim 7, further comprising: The second receiving module is configured to receive the test environment information of the new payment product under each payment channel to be tested after adding the new payment product to the payment application to be tested; An acquisition module, configured to acquire benchmark test results corresponding to the new payment product. 13. A test device for a payment application, comprising: processor; memory for storing processor-executable instructions; Wherein, the processor is configured as: Receive the test environment information corresponding to the payment channel to be tested in the payment application to be tested, wherein the test environment information includes: preset account information and the payment test case corresponding to the payment channel to be tested, and the payment test case It is used to record all operable steps related to the payment channel to be tested that can be executed in the payment application to be tested according to the preset account information; Receive test instructions; Executing the payment test case corresponding to the payment channel to be tested to simulate the user performing all the operational steps in the payment application to be tested according to the preset account information; According to whether the current payment result is consistent with the benchmark test result corresponding to the test case, it is determined whether there is a fault in the payment channel to be tested.