Payment module testing methods and precautions

Payment flow diagram:

1, pay the normal process

In accordance with the requirements specification for regular payment operations. Expectations, successful payment, and without any error situation.

(1) order the payment amount is an integer

(2) an order to pay the amount of decimals

(3) Category demolition of the transaction: the transaction is split, the split send details

(4) were used to make payments wifi and 4G

 

2, abnormal payment process

1.1 configuration verification

  (1) corresponding to the channel not activated pay switch

  (2) is not configured to pay corresponding to the channel parameter class

  (3) is not installed corresponding to the channel APP (Alipay, micro-letters, etc.)

  (4) landed not correspond to channel APP

1.2 basis of payment verification

  (1) order the payment amount is less than the current account balance

  (2) split class trading: Split amount equal to the total amount not 

  (3) simulated users make a payment, use tools such as fiddler, will modify order amount

  Does not need to input the request is completed without the input (4) payment password (typically pay channels requires a password to successful payment, but swept payment interface, micro-channel and Alipay scan code of a class has free dense payment, the amount of <= 1000 passwords, enter the password you need to enter large amounts)

  (5) to enter a password when paying, directly off the page (including the pc end payment, APP end payment)

  (6) the payment request is completed, enter the wrong password (usually this case by the party's control channel, it will prompt for password error, re-enter your password)

  (7) scan code type of transaction: to generate two-dimensional code does not scan, view the result of payment

  (8) scan code types of transactions: Using the wrong payment code for payment (for example: micro-channels use the PayPal payment letter code)

  (9) timeout test: Some channels have to pay timeout, timeout until after payment

1.3 Repeat pay

  (1) re-enter the password wrong payment

  (2) duplicate payments when payment unresponsive

  (3) return to the payment page after the payment is complete, re-pay

  (4) Single order people to pay

  (5) Single order a person to pay multiple devices (such as mobile phones and pc can log micro letter / Alipay)

  (6) orders fast single button click to pay pay

1.4 server class

  (1) After completion of payment, the asynchronous notification is not received, server failure we

  (2) After completion of payment, the asynchronous notification is not received, the server side channel failure

  (3) After the completion of the payment is not received notification to the front desk, we server failure

  (4) After completion of the payment is not received notification to the front, side channel server failure

  (3) the payment process, has been placed, the payment is not successful, the channel party server failure

  (4) initiate a payment, our server failure

  (5) initiate a payment, the channel party server failure

1.5 Network Problems

  (1) weak network environment, overtime payment request to see whether the payment order has to generate, view payments

  Request timed out (2) a weak network environment, enter the password after successful payment, return to the relevant page or APP, view orders payments

  (3) the payment process, the network switching device, the switching such as WiFi 4G / 4G switching WiFi, Check payments

  (4) a user clicks on pay, the payment process issues affecting appear abnormal network, database to see if the payment orders to be generated

  (5) user clicks on pay, pay and other network anomalies appear affecting the recovery process issues, verify whether the page is refreshed, user whether to continue to make payments

  (6) the user to enter a password to pay, upon notification has not been received successfully, the emergence of abnormal payment processes affecting network issues, to see if the database that your order success

  (7) the user to enter a password to pay, upon notification has not been received successfully, the emergence of the impact of network anomalies and other payment issues after recovery process, see if the user receive future payments result notification page

 

The results related to the payment terms of users, so when abnormal know to be clear and obvious and non-payment page error, can not have a garbled situation. In terms of user interaction can be tested according to the general test specifications page.

After payment interface, you need to have the perfect query mechanism, leading to problems in the network or the server can not receive asynchronous notification of successful payment after the order is successful, the results need to modify the payment system by querying reconciliation.

 

Guess you like

Origin www.cnblogs.com/deliaries/p/11858384.html