做了四年多的銀行支付系統測試，對支付模式類型略知一二。對於市場上的支付系統，其實原理大同小異。市場上大多數軟件系統涉及到支付功能，都會與第三方支付系統交互，跳轉到相應的支付系統實現其支付功能，下面說下開展這類型測試之前，需要考慮哪些因素：
1，了解第三方支付接口有哪些，系統直接交互如何實現，建議畫流程圖（題外推薦：流程圖可以使用chrome插件：Gliffy，個人感覺比較好用。），重復熟悉系統實現流程，只有搞清楚流程，才能更好的評估其中的風險，才能有利於測試用例的設計；
2，除了主要功能之外，還需要考慮異常場景有哪些；
3，有哪些風險？如何規避？
針對測試過程中涉及到主要的測試點整理如下：
測試過程中需要注意的主要測試點及異常場景：
· 首先要保證接口都能正常調用；
· 生成一筆訂單，支付完成后，同步或異步重復回調，只有一次有效；
· 生成一筆訂單，復制訂單號和金額，再次生成一筆訂單，用fiddler設置斷點，用第一筆已完成的訂單號和訂單金額去替換現有的訂單號和金額，無法完成支付；
· 生成一筆訂單，跳轉到第三方時修改金額，無法到賬，或者如果是游戲充值游戲幣的話，到賬為篡改后的金額對應的游戲幣；
· 異步通知屏蔽，同步有效，進行支付，同步能夠正常到賬；
· 同步設置無效，異步有效，進行支付，異步能夠正常到賬；
· 同步異步都設置無效，在第三方支付完成后，在重發機制時間范圍內，設置異步有效，到下次通知時間點時，能夠正常通知到賬（補單機制的驗證，如果商戶收到第三方支付成功的通知后，要告知第三方支付收到了成功的通知，如果第三方支付收到商戶應答不是ok或超時，第三方支付就會認為通知失敗，會在規定的時間內持續調用notify_url，一般有時間或次數的限制）；
· 針對支付訂單在
數據庫中存儲是否完整和正確進行校驗（比如：第三方訂單號--方便與第三方對賬和問題排查、訂單金額、訂單狀態等）；
· 如果是用戶購買實物商品，用戶發起退貨，要保證退貨流程正常，資金能正常返還，要考慮下並發情況的驗證以確保安全性；
· 如果是用戶購買虛擬商品，比如話費、油卡之類的商品，只有在發貨失敗的時候才能發起退貨，注意驗證；
遇到過的坑：
· 用戶購買100元游戲幣時，前往第三方支付跳轉進行金額的篡改由100元改成0.01元，結果就拿了0.01元充值了100元的游戲幣。對訂單金額沒有做校驗導致這樣的后果，損失比較大。大家在測試的過程中一定要注意對服務端進行校驗，支付時數據的篡改一定要有校驗。
· 當同步、異步通知都存在的情況的，異步通知（第三方支付成功后台通知），沒有到賬，導致部分用戶充值不到賬，引起客訴。當同步、異步並存的時候，一定要分別對同步和異步進行檢驗，確保都能正常到賬。
我們所做的絕大多少的
互聯網產品都會涉及到第三方支付，所以支付功能必然是重要的，作為測試互聯網產品的一員，我們必須要做好支付的安全性。
那么，如何規避支付風險？
為了進一步的加強支付功能的安全，也可以適當的增加一些監控機制，比如：訂單與第三方訂單進行對比，可以使用跑批完成，當我們完成支付的訂單從數據庫中查出來與通過第三方訂單查詢接口查詢出來的同一個訂單金額有異常時，進行報警通知能夠及時發現處理，甚至當有異常情況進行創建訂單的終止，從而把損失降到最低。