如何做好網際網路產品的支付測試？入坑前先搞懂這5個要點！

現在有不少測試朋友做的專案中，可能也會涉及到支付相關的功能。比如：做商城的，做遊戲的以及其他線上交易的網站、APP等。如果支付出了問題，或者使用者拿少的錢透過篡改請求資料購買大金額的商品，如果是實物的話，發貨前還有可能被發現。如果是虛擬商品話費、遊戲幣等就有可能造成損失。

所以，不管是實物也好，虛擬商品也好，對於網際網路產品而言，支付是涉及到公司收入的一個重大環節，對於測試人員來說，支付測試是測試中的重要一環。失誤或者輕視，可能會造成很大損失。之前可能大家也都看到過或者聽過一個bug損失4.6億美金的慘痛教訓或者身邊也有發生過其他因為支付功能的bug導致直接損失的案例。

那麼，問題來了，對於支付模組的相關測試，我們應該如何進行呢？且聽我細細道來！

一、測試方法

功能測試

透過將邊界值分析、等價類劃分、錯誤推測、因果圖等各種測試方法進行結合，整理出儘可能全面的測試案例，對支付功能及其相關功能進行測試，以確保整個支付流程以及涉及到支付流程的其他流程在任何情況下都能正常進行。

介面測試

明確整個支付流程所需要呼叫的介面，分清楚商家和第三方支付平臺的介面以及引數和請求方式。包括對介面特定引數的加密，使用異常訂單號模擬支付，對服務端的校驗等等。

功能測試

支付涉及到金額方面，所以要考慮安全測試方面。支付請求的偽造、金額的惡意篡改、惡意模擬第三方介面來呼叫商家介面等等。這都是我們需要考慮到的問題。

二、支付流程

常見的支付流程如下圖所示：

主流：支付請求->第三方支付->第三方支付返回值->App根據返回值判斷支付成功或失敗。

之前：支付請求->第三方支付完成->返回到App前呼叫支付成功介面來判斷支付是否成功或失敗。

真實案例：

用12306買了一張火車票，支付寶支付的，支付完成後從支付寶返回到12306時，發現12306並未提示我支付完成，且在訂單介面顯示我的訂單未支付，我就著急了（2011年，12306剛出來的時候，我有一次買票，票沒買到，錢扣了的經歷，後來經過客服把錢退回來了），重新整理了好多次，還是未支付，正當我有點小焦慮的時候，簡訊通知我訂票成功了。

三、支付分類

支付方式：充值支付、網銀支付、銀聯支付、微信、支付寶，賬戶支付/掃碼支付

資金流向：

1、網銀支付：

流程：直接點選訂單-》網銀支付-》跳轉到銀行主頁-》輸入卡號，手機驗證碼，密碼支付-》

支付完成跳轉到return_url介面(同步回執)，支付狀態一般為已支付-》銀行打款成功，對方收到(非同步回執)-》修改資料庫裡面訂單狀態為支付完成

虛資金變化：我的銀行餘額減少，對方餘額增加

實資金變化：我的錢少了訂單金額，對方增加了訂單金額

資金流向：

假如你是在平臺購買商品，然後錢最終是付給商家，採用的是網銀支付：

你的銀行卡賬戶->平臺備付金賬戶->商戶賬戶

如果平臺商就是商家：

你的銀行卡賬戶->平臺備付金賬戶

2、充值支付：

把錢從你的銀行卡充值到平臺賬戶，支付時，使用平臺賬戶上的餘額進行支付

資金流向：

充值：你的銀行卡->平臺賬戶

支付：平臺賬戶->商家賬戶

提現：平臺賬戶->你的銀行卡（通常收費）

轉賬：你的銀行卡->對方銀行卡

3、微信支付：

流程：購物平臺生成訂單->選擇支付方式（微信支付）->跳轉到微信介面->輸入密碼支付->生成收款二維碼->掃碼支付

這裡分為兩種：

1、微信餘額支付

2、銀行卡支付

資金流向：

1、微信備付金->平臺備付金賬戶->商戶賬戶

2、銀行卡->微信備付金->平臺備付金賬戶->商戶賬戶

支付中涉及的物件有哪些？

我（使用者）、賣家（商戶）、平臺、銀行、第三方支付平臺（如支付寶、微信等）

概念：

虛資金：虛擬貨幣或者虛擬的金額，比如網上查詢銀行卡餘額

實資金：實實在在的錢

支付時會涉及到虛資金和實資金的轉換。

四、支付介面

流程清楚之後，我們再來看看其中會涉及到哪些介面？這個支付流程圖裡面就涉及到了第三方支付介面：

· 下單介面：商戶提交下單請求到第三方支付介面，第三方支付收單成功後返回下單成功結果給到商戶系統。（下單介面的最終處理結果分為下單成功和下單失敗，若未收到明確結果可呼叫單筆訂單查詢介面查詢結果。）

· 支付介面：呼叫該介面時指定支付引數，完成買家賬戶向商戶賬戶的支付，採用頁面跳轉互動模式和後臺通知互動模式。（結果分為兩路返回：一路為前臺在return_url頁面跳轉顯示支付結果；一路為後臺在notify_url收到支付結果通知後進行響應。）

· 退款介面：呼叫第三方支付的支付請求介面返回付款成功後，在需要做退款處理時呼叫退款請求介面發起退款處理。（退款介面的最終處理結果分為退款成功和退款失敗，若未收到明確結果可呼叫退款查詢介面查詢結果。）

· 單筆訂單查詢介面：根據訂單號查詢單筆訂單資訊和狀態。

· 退款訂單查詢介面：呼叫第三方支付的退款介面返回後，在需要查詢退款請求狀態可呼叫退款訂單查詢介面查詢退款訂單的狀態和訂單資訊。

五、測試點（側重於App與第三方的互動）

1、檢查請求介面（傳參的方式）、特定引數（訂單號、金額、數量等等）加密。

2、修改請求引數”訂單號”，使用已重複訂單號，支付未支付的訂單。

3、修改請求引數”金額”（改小、改大、負數）。

4、修改請求引數”數量”（改小、改大、負數）。

5、檢查訂單提交請求、支付交易的按鈕，要做阻斷式操作，點選一次則要等待返回值，不能多次觸發。

6、檢查重要欄位為空（不點選輸入框的情況下），做提交的操作。

7、檢查未安裝第三方支付應用，走網頁版測試流程。

8、檢查透過限速，造成提交網路請求超時，確認該訂單是否生成成功。

9、檢查透過限速，造成提交請求成功但資料請求回傳給App網路請求超時，重新整理檢查訂單是否生成成功。

10、檢查透過限速，造成支付網路請求超時，確認該訂單是否支付成功。

11、檢查透過限速，造成支援成功但資料請求回傳給App網路請求超時，重新整理檢查訂單是否支付成功。

12、支付測試過程中容易忽視的測試點，方便大家查缺補漏。