現在有不少測試朋友做的項目中，可能也會涉及到支付相關的功能。比如：做商城的，做游戲的以及其他在線交易的網站、APP等。如果支付出了問題，或者用戶拿少的錢通過篡改請求數據購買大金額的商品，如果是實物的話，發貨前還有可能被發現。如果是虛擬商品話費、游戲幣等就有可能造成損失。
所以，不管是實物也好，虛擬商品也好，涉及到支付功能時，大家在測試的過程中一定要重視，否則，會造成很大損失。之前可能大家也都看到過或者聽過一個bug損失4.6億美金的慘痛教訓或者身邊也有發生過其他因為支付功能的bug導致直接損失的案例。
給大家舉個真實的案例：比如使用支付寶購買虛擬商品，往支付寶跳轉時，篡改了小的金額，結果購買虛擬商品成功了。（原本10元的商品，0.01元就搞定了）。多么可怕的一個bug啊，當然這個問題可能對於一個做過支付有過經驗的測試朋友來說，可能會想：哎呀，這個問題都發現不了，還做什么測試？是的，問題是很簡單，對於一個剛入職場的測試朋友或者沒有支付相關經驗的測試朋友來說，很有可能會忽略。
那么，問題來了，對於支付模塊的相關測試，我們應該如何進行呢？比如，針對游戲來說，使用第三方支付往游戲充值游戲幣功能，看起來是不是很簡單，大家主要思考下以下內容：
1、支付都是與第三方支付（支付寶、微信、財付通、QQ錢包、短信支付等）進行對接，那么，是否了解了第三方接口有哪些？是否都能清楚我們的產品與第三方是如何交互的？是否能畫出流程圖？
2、異常場景有哪些？
3、有哪些風險，如何規避？
第三方支付的流程，與商戶的對接方式基本相似，大同小異。（題外推薦：如下流程圖使用的chrome插件：Gliffy，個人感覺比較好用。）
支付流程：
退款流程：
查詢流程：
先看下流程圖，是否對流程圖有些了解，不僅僅是做支付功能相關測試才去搞清楚其中的流程，做其他的測試一樣也要搞清楚流程，只有搞清楚流程，才能更好的評估其中的風險，才能有利於測試用例的設計。
當然流程圖中只是提到了商戶與第三方是如何交互的，同樣商戶內部處理的流程也要有所了解及數據怎么存儲的，涉及到哪些DB也要清楚。
流程清楚之后，我們再來看看其中會涉及到哪些接口？這個支付流程圖里面就涉及到了第三方支付接口：
· 下單接口：商戶提交下單請求到第三方支付接口，第三方支付收單成功后返回下單成功結果給到商戶系統。（下單接口的最終處理結果分為下單成功和下單失敗，若未收到明確結果可調用單筆訂單查詢接口查詢結果。）
· 支付接口：調用該接口時指定支付參數，完成買家賬戶向商戶賬戶的支付，采用頁面跳轉交互模式和后台通知交互模式。（結果分為兩路返回：一路為前台在return_url頁面跳轉顯示支付結果；一路為后台在notify_url收到支付結果通知后進行響應。）
· 退款接口：調用第三方支付的支付請求接口返回付款成功后，在需要做退款處理時調用退款請求接口發起退款處理。（退款接口的最終處理結果分為退款成功和退款失敗，若未收到明確結果可調用退款查詢接口查詢結果。）
· 單筆訂單查詢接口：根據訂單號查詢單筆訂單信息和狀態。
· 退款訂單查詢接口：調用第三方支付的退款接口返回后，在需要查詢退款請求狀態可調用退款訂單查詢接口查詢退款訂單的狀態和訂單信息。
那么針對第三方的接口，我們大致也有所了解了，接下來針對測試過程中涉及到主要的測試點整理如下：
測試過程中需要注意的主要測試點及異常場景：
· 首先要保證接口都能正常調用；
· 生成一筆訂單，支付完成后，同步或異步重復回調，只有一次有效；
· 生成一筆訂單，復制訂單號和金額，再次生成一筆訂單，用fiddler設置斷點，用第一筆已完成的訂單號和訂單金額去替換現有的訂單號和金額，無法完成支付；
· 生成一筆訂單，跳轉到第三方時修改金額，無法到賬，或者如果是游戲充值游戲幣的話，到賬為篡改后的金額對應的游戲幣；
· 異步通知屏蔽，同步有效，進行支付，同步能夠正常到賬；
· 同步設置無效，異步有效，進行支付，異步能夠正常到賬；
· 同步異步都設置無效，在第三方支付完成后，在重發機制時間范圍內，設置異步有效，到下次通知時間點時，能夠正常通知到賬（補單機制的驗證，如果商戶收到第三方支付成功的通知后，要告知第三方支付收到了成功的通知，如果第三方支付收到商戶應答不是ok或超時，第三方支付就會認為通知失敗，會在規定的時間內持續調用notify_url，一般有時間或次數的限制）；
· 針對支付訂單在數據庫中存儲是否完整和正確進行校驗（比如：第三方訂單號--方便與第三方對賬和問題排查、訂單金額、訂單狀態等）；
· 如果是用戶購買實物商品，用戶發起退貨，要保證退貨流程正常，資金能正常返還，要考慮下並發情況的驗證以確保安全性；
· 如果是用戶購買虛擬商品，比如話費、油卡之類的商品，只有在發貨失敗的時候才能發起退貨，注意驗證；
遇到過的坑：
· 用戶購買100元游戲幣時，前往第三方支付跳轉進行金額的篡改由100元改成0.01元，結果就拿了0.01元充值了100元的游戲幣。對訂單金額沒有做校驗導致這樣的后果，損失比較大。大家在測試的過程中一定要注意對服務端進行校驗，支付時數據的篡改一定要有校驗。
· 當同步、異步通知都存在的情況的，異步通知（第三方支付成功后台通知），沒有到賬，導致部分用戶充值不到賬，引起客訴。當同步、異步並存的時候，一定要分別對同步和異步進行檢驗，確保都能正常到賬。
我們所做的絕大多少的互聯網產品都會涉及到第三方支付，所以支付功能必然是重要的，作為測試互聯網產品的一員，我們必須要做好支付的安全性。
那么，如何規避支付風險？
為了進一步的加強支付功能的安全，也可以適當的增加一些監控機制，比如：訂單與第三方訂單進行對比，可以使用跑批完成，當我們完成支付的訂單從數據庫中查出來與通過第三方訂單查詢接口查詢出來的同一個訂單金額有異常時，進行報警通知能夠及時發現處理，甚至當有異常情況進行創建訂單的終止，從而把損失降到最低。
一個支付流程要考慮到哪些測試點？
1.從買家選擇支付方式開始，選擇網上銀行或者信用卡支付，一直到支付結束，這個過程要考慮到哪些測試點？
卡與帳號一致與否，帳號與驗證碼一致與否，扣款金額與應付金額是否一致，扣款帳號與應扣款帳號是否一致等等
2.支付寶充值功能測試用例設計？
假設一種通過銀行卡充值的場景 可以寫幾條
1）,通過網銀充值10元（標題） 然后請自己描述詳細操作步驟
預期結果 支付寶帳戶中增加10元（前提是不考慮網絡延時，或各網銀的出帳延時）
2,）通過網銀充值時 網銀余額不足
預期結果 充值失敗 不影響支付寶中帳戶金額
3,）通過網銀充值時，在任意操作步驟中（建議是最后一步）取消該服務
預期結果 充值失敗 不影響支付寶中帳戶金額
4,）充入0元 （基本上不會同意充0的操作的吧）
預期結果 充值失敗 提示輸入大於0的金額
5）,充入n元（N= 支付寶每次限制的最大充值金額）
預期結果 支付寶帳戶中增加n元
6 ）充入N+1元 (與第5條一樣，都是邊界值法。但是要分開寫成兩條）
預期結果 充值失敗/提示金額大出限制
3.如何進行銀聯支付測試？
主要是功能方面要正確，涉及到金錢，都要測試小心了，不能有任何計算的錯誤。
另外，可以考慮下安全測試方面，支付請求的偽造、金額的篡改、惡意模擬銀聯來調用你們的接口……