How to test the payment

In general, we can consider from four directions: payment process , refund process , non-functional test points, and payment test methods .

 

 

One

Payment process

 

Paying 测试流程: Click to pay --> select payment method --> confirm amount --> enter password --> successful payment. It needs to be tested separately for each stage and step in the payment process.

 

(1) Payment: Click to pay and then cancel the order. Can it be cancelled normally?

(2) Choice of payment method: It can be considered from the perspective of normal and abnormal.

Normal: The payment methods that can be supported are: credit card, debit card, online banking payment, balance, third-party payment (WeChat, Alipay, JD, Baidu, aggregate payment, combined payment), find someone to pay, verify whether it is supported and can be selected normally And pay

 

abnormal:

① When paying, combine coupons/discount coupons/promotion price deductions for relevant deductions, verify that the rules are correct, and can be deducted and paid normally.

② When there is no WeChat, Alipay and other APP installed on the mobile phone, select the corresponding payment method and how the system handles it;

 

(3) Confirm payment amount:

Normal: Use the boundary value method in the black box test to test the normal amount.

• Maximum payment amount (the largest single day, the largest single transaction, the largest balance);

• The minimum payment amount.

   

Anomaly: The boundary value method is also used to extract test points.

• Exceeds the maximum daily consumption amount of the payment method/the largest single transaction/the largest balance;

• Abnormal amount payment: non-number, negative number, 0, decimal point more than 2 digits, format error, balance is less than the actual amount that needs to be paid, etc.

 

 

(4) Payment password:

Normal: The types of payment passwords that can be supported are: fingerprints, face recognition, account passwords, dynamic access verification codes, gestures, credit cards and payment codes, small amount exemption, etc., confirm the password types supported by your product, and confirm that you can verify And the payment is successful;

 

abnormal:

①Enter the wrong password, check whether there is any prompt information and it is correct;

②Exceed the upper limit of password error, check whether it is frozen, etc.

 

(5) Test points in other scenarios:

① Whether the combined payment of multiple orders can be successful;

②If you repeatedly click the payment button, whether there will be multiple purchases, and synchronously check whether the data account of the database is correct;

③How to make up and refund the order after the payment fails.

④ Payment interruption:

• Active interruption: you can continue to pay and succeed;

• Passive interruption: such as phone calls, low battery, alarm clock, disconnection, background switching, headset plugging and unplugging, etc., verification can continue to pay.

⑤Use Fiddler to capture packets to tamper with the price: packet capture or data encryption is not allowed, and tampering is unsuccessful.

 

 

 

two

Refund process

 

Normal: The verification is normal 退款流程, that is, the smoke test of the refund.

• Click Refund to make the refund successful, and check that the transaction status is refund, the refund amount can be credited to the account;

• Combined with discount coupons and other deductions, the actual paid amount can be refunded;

• Synchronously check that the data and accounts of the database are correct;

   

Exception: If you submit a wrong refund (the refund order number is incorrect), or the refund amount is wrong, the refund can fail (here we usually use tools for testing, such as interface testing);

 

 

 

three

Non-functional test points

 

In our usual tests, in addition to functional testing, we also need to consider other aspects of testing (non-functional testing), including the following aspects:

(1) UI test:

1. Whether the payment button is obvious enough;

2. Whether the payment interface is simple, beautiful, and conforms to the public's aesthetics;

3. Whether the font size of the payment page is reasonable.

 

(2) Compatibility test:

BS: If it is a BS architecture product, you need to test the compatibility of the browser, so you need to select some mainstream browsers for testing according to the browser's kernel;

APP: Test the compatibility of mobile phones, such as phone model, system version, screen size and resolution, etc.

 

(3) Usability test:

1. Whether to support the shortcut key function;

2. Click the payment button to see if there is a reminder;

3. Cancel the payment, whether there is a reminder;

4. Whether the input box is aligned and whether the size is moderate.

 

(4) Performance test:

1. When the payment button is clicked multiple times, whether there will be multiple deductions;

2. If there are multiple deductions, how to return it through the original payment channel;

3. If there is a peak payment period such as Double Eleven and Double Twelve, will there be a queue when paying?

4. Will the response time out;

5. If the response times out, will it return a friendly prompt?

 

(5) Safety test:

• Verify that sensitive information is encrypted and can be tampered with;

• Perform security scans through some tools to check whether there are security loopholes or use some other means to conduct special security tests;

• Forgery of payment requests, malicious tampering of the amount, maliciously simulating a third-party interface to call the merchant interface, etc., are all issues that we need to consider clearly.

 

(6) Network test:

1. Verify various network types: 2G, 3G, 4G, 5G, and wifi can be paid normally;

2. The network is switched and the payment function is normal;

3. The payment function is normal under the weak network test: the payment will not be repeated multiple times, the APP will not crash, and the page prompts are friendly;

 

 

four

testing method

 

Some test partners often ask, how do I test the payment function, do I need real money? There are four kinds of ideas we provide:

(1) Small payment:

Let developers modify the code, no matter how much money is paid, the actual payment is 1 cent; but this method can only test small payments, it may appear that there is no problem with product small payments, but large payments will miss the test by mistake Happening;

 

(2) Apply for the test amount and follow the reimbursement process:

This method is generally used as a supplement to micropayments. For example, after testing the micropayments, test some large payments. This requires the company to apply for a test fund and go through the reimbursement process;

 

(3) Change the payee to your own account number:

In this way, you can pay by yourself, collect your own money, and avoid wasting your money to do payment tests for company projects. But this is also risky. What should I do if the deduction is successful, but the paid amount does not arrive in the account?

 

(4) Sandbox payment:

Sandbox payment is a virtual payment, not a real amount; this method can verify small and large payment processes; currently Alipay sandbox is relatively mature and recommended.