Someone once asked me this question: As a payment platform, it has access to multiple channels such as Kuaiqian, YeePay, or direct bank, and its internal product process is its own. What better testing methods are there in the industry to test each channel and the bank channels it supports?
Answer: For payment platforms, tests related to payment channels can be roughly divided into: testing payment channel functions, testing payment product functions
I also prepared a software testing video tutorial, which is placed at the end of the article. If you need it, you can watch it directly, or click the small card at the end of the article to get the information document for free
Payment channel function test
Mainly to test functions with banks, UnionPay, other external payment channels, and non-payment functions such as real-name authentication.
Under normal circumstances, the interface of the payment channel is only open to the third-party payment internally, and will not directly expose the payment channel to external merchants. It is packaged as a payment product for external merchants. The payment channel is the most basic capability of a third-party payment company. Since it involves invoking various external interfaces and services, the requirements for the test environment, quasi-production environment, and production environment provided by each channel are also different. At the same time, the third-party payment itself also needs It is really troublesome to maintain the corresponding test environment, quasi-production environment, and different versions of the production environment. It is really troublesome to complete the test.
Test Methods
Develop a unified test gateway internally (no matter the interface communication protocol is socket, http, xml, etc., it is generally unified as http to facilitate testing), unify the test entrances of various channels, and maintain corresponding interface parameters for different channels Templates for testers to quickly enter and submit original payment requests.
After submitting to the payment channel, if the payment channel maintains a test environment or quasi-test environment, you can directly use the provided test account to complete the actual payment channel test.
If you don’t provide it, you can only open bank cards and corporate accounts through different channels for testing like the subject. In this case, the minimum limit is generally tested.
The application of the test card, the source of the test fee, and the daily management can formulate corresponding policies according to the actual situation of each company. It is best for the company to bear various expenses, simplify related processes and have corresponding incentives. For example, do not continue to pay for such expenses Extremely lengthy reimbursement process.
Testing purposes
Ensure the correctness, completeness and availability of payment channel functions, and verify whether the channels are unblocked and the functions are normal.
A typical example is that a new function of the original payment channel is launched, and the production environment test finds that there is a problem. It is very troublesome to run the process in the production environment. You can use the test or the stable version of the test gateway test in the quasi-production environment. The quick positioning is to go online. The new version affects the generation function, or the problem of the payment channel, or the problem of the production environment network.
Pay for Product Functional Testing
The payment products here can be the basic products inside the third-party payment, or they can be products or interfaces provided to external merchants. In this case, the focus of the test is not the basic functions of the payment channel, but the core functions of the payment product. For payment products, it can be assumed that the payment channel is a black box, and the services provided by the black box are reliable and stable.
Test Methods
Internally develop a set of simulation gateways for payment channels, simulate each interface function of various payment channels and return corresponding simulation messages according to payment requests. Payment requests are not actually submitted to external payment channels. Generally, the simulation gateway and the above test gateway will be developed and deployed in a unified manner.
Payment test idea
Before analyzing the test points, let's sort out the test thinking first. In summary, the testing ideas for anything can be summarized as follows:
The first step: sort out the core business process of the product: understand what kind of project this is, what kind of business is realized, and how is it realized?
This step is generally based on the company’s requirements documents. If the product provides the business flow chart along with the requirements document, it can be sorted out by following the flow chart; Flow chart to achieve the purpose of sorting out business.
Step 2: Carry out module subdivision according to the process, and then carry out detailed test point design and extraction for each functional module.
The test point extraction of this single function should cover the following aspects:
Normal function verification: priority is given to covering normal business processes and function verification, which is actually a smoke test of a single function. The smoke test is performed first, and if it fails, the test can be stopped directly and the test can be continued after development and repair.
Abnormal function verification: In order to be closer to the user's use of the product, we also need to verify various abnormal scenarios, intentional operation leads to errors, check the system's feedback and prompts, and ensure that the user's operation errors can get friendly instructions from the system.
Because operations in many places may cause system exceptions and error reports, in order not to miss detection, we need to find out all possible input items and options that may cause exceptions. So it's the third step:
Step 3: For specific functions, find each input item and step, and analyze the test points from the following three angles.
1. Length, data type, required items, repeat
2. Demand constraints + invisible demand
3. Interaction between functions
Among them, some specific design methods of use cases are needed, such as scenario method, equivalence class method, boundary value method, error guessing method, etc.
Step 4: Consider non-functional test points, including interface, usability, compatibility, security, performance pressure
Based on the above test ideas, we can analyze the "payment function" test points as follows
The business process of combing payment is as follows
Click to pay ---> select the payment method ---> confirm the amount ---> enter the password ---> successful payment
Completing this process test means completing the smoke test of the project! Then we need to test for each stage and step in the process, and analyze the test points that may cause exceptions in detail, so we divide it by stage and input as follows:
In the era of non-cash payment, non-cash payment has become an indispensable part of life. We only need a mobile phone to travel all over the country (the premise is Alipay, WeChat is rich <00>), so as a tester, pay the test It is also a very important part, so let me combine some problems encountered in my work and summarize the common payment tests:
One: The classification of payment
Generally speaking, online payment is divided into two consumption modes. One is to pay the amount directly, such as Taobao, Jingdong and other shopping websites; the other is to recharge to buy virtual currency such as Jindou, and use virtual currency to consume in the website, such as game platforms and other products!
Two: functional testing
The next step is the testing work. The first thing to do is functional testing. Then I combined various testing methods such as boundary value, class division, error guessing, and causality diagram to sort out a relatively comprehensive set of test cases. The payment function is tested to ensure that the entire payment process and the payment processes involved are usable under all circumstances.
Three: interface test
Clarify the interface that needs to be called in the entire payment process, distinguish the interface of the merchant and the third-party platform and the request method of parameters, including the encryption of specific parameters of the interface, the use of abnormal order numbers to simulate payment, the inspection of the server, etc.
Four: Security testing
The payment will involve the amount, so we need to consider the aspect of security testing, forgery of payment requests, malicious tampering of the amount, malicious simulation of third-party interfaces to call merchant interfaces, etc., are all issues that we need to consider clearly
Five: Test point
Payment Process Test Point
1. Is the payment amount consistent with the payable amount?
(For example: whether the scanned payment QR code is consistent with the displayed amount to be paid). Payment still needs to go through the entire payment process. From confirming the order to the final successful payment, there may be problems in any step.
2. The same payment method, but different payment portals
(For example: as shown in the figure below, Alipay has two payment entrances. You can pay by scanning the QR code or through the Alipay webpage. During the test, both entrances must be covered.
3. After the payment is successful, whether the product purchase is successful
(For example, membership service products, whether the membership expiration time is normally delayed after purchase; such as purchasing goods, after successful payment, whether the order status has changed, whether the product type and quantity are correct, etc.)
4. After the payment is successful, is the user's amount deducted successfully?
Payment Amount Test Point
-
normal amount payment
-
Minimum amount: 0.01
-
Meaningless value: 0 yuan
-
Maximum Amount: Set the maximum amount paid
-
Bank card or WeChat, etc., set the maximum daily consumption amount or single maximum consumption amount
-
Pay when the bank card or WeChat balance is insufficient
Payment Process Test Point
-
Complete the payment process normally
-
After calling the order, cancel the order
-
After the payment is interrupted, continue to pay
-
End payment after payment interruption
-
Single order single payment
-
Combined payment for multiple orders
-
Continuous click to pay, whether there will be multiple purchases
Payment Method Test Point
-
Pay with Ali-Pay
-
Alipay web payment
-
WeChat payment
-
bank card payment
-
Coupons or discounts (with certain offers)
-
Whether the coupon/discount is used in the payment, the payable amount and the actual payment amount are correct
-
Whether the coupon/discount is mandatory or not
-
After the payment order refund is completed, can the coupon/discount still be used?
In the end, I compiled a set of software testing interview documents for you , with a total of 212 pages . It should be of great help to friends who want to change jobs for interviews, get promoted and raise salaries, get rid of professional difficulties, and improve their skills. I hope everyone can have a bright future. Kam. [Click on the small card at the end of the article to get a full set of software testing materials for free]
Where to watch the video tutorial:
https://www.bilibili.com/video/BV1nd4y1M7BX/?vd_source=74d0257ec7066cc4f9013524f0bb7013