關於支付類的一些測試關注點及異常點

　　作了四年多的銀行支付系統測試，對支付模式類型略知一二。對於市場上的支付系統，其實原理大同小異。市場上大多數軟件系統涉及到支付功能，都會與第三方支付系統交互，跳轉到相應的支付系統實現其支付功能，下面說下開展這類型測試以前，須要考慮哪些因素：

　　1，瞭解第三方支付接口有哪些，系統直接交互如何實現，建議畫流程圖（題外推薦：流程圖可使用chrome插件：Gliffy，我的感受比較好用。），重複熟悉系統實現流程，只有搞清楚流程，才能更好的評估其中的風險，纔能有利於測試用例的設計；

　　2，除了主要功能以外，還須要考慮異常場景有哪些；

　　3，有哪些風險？如何規避？

針對測試過程當中涉及到主要的測試點整理以下：

　　 測試過程當中須要注意的主要測試點及異常場景：

　　· 首先要保證接口都能正常調用；

　　· 生成一筆訂單，支付完成後，同步或異步重複回調，只有一次有效；

　　· 生成一筆訂單，複製訂單號和金額，再次生成一筆訂單，用fiddler設置斷點，用第一筆已完成的訂單號和訂單金額去替換現有的訂單號和金額，沒法完成支付；

　　· 生成一筆訂單，跳轉到第三方時修改金額，沒法到帳，或者若是是遊戲充值遊戲幣的話，到帳爲篡改後的金額對應的遊戲幣；

　　· 異步通知屏蔽，同步有效，進行支付，同步可以正常到帳；

　　· 同步設置無效，異步有效，進行支付，異步可以正常到帳；

　　· 同步異步都設置無效，在第三方支付完成後，在重發機制時間範圍內，設置異步有效，到下次通知時間點時，可以正常通知到帳（補單機制的驗證，若是商戶收到第三方支付成功的通知後，要告知第三方支付收到了成功的通知，若是第三方支付收到商戶應答不是ok或超時，第三方支付就會認爲通知失敗，會在規定的時間內持續調用notify_url，通常有時間或次數的限制）；

　　· 針對支付訂單在 數據庫中存儲是否完整和正確進行校驗（好比：第三方訂單號--方便與第三方對帳和問題排查、訂單金額、訂單狀態等）；

　　· 若是是用戶購買實物商品，用戶發起退貨，要保證退貨流程正常，資金能正常返還，要考慮下併發狀況的驗證以確保安全性；

　　· 若是是用戶購買虛擬商品，好比話費、油卡之類的商品，只有在發貨失敗的時候才能發起退貨，注意驗證；

　 　遇到過的坑：

　　· 用戶購買100元遊戲幣時，前往第三方支付跳轉進行金額的篡改由100元改爲0.01元，結果就拿了0.01元充值了100元的遊戲幣。對訂單金額沒有作校驗致使這樣的後果，損失比較大。你們在測試的過程當中必定要注意對服務端進行校驗，支付時數據的篡改必定要有校驗。

　　· 當同步、異步通知都存在的狀況的，異步通知（第三方支付成功後臺通知），沒有到帳，致使部分用戶充值不到帳，引發客訴。當同步、異步並存的時候，必定要分別對同步和異步進行檢驗，確保都能正常到帳。

　　咱們所作的絕大多少的 互聯網產品都會涉及到第三方支付，因此支付功能必然是重要的，做爲測試互聯網產品的一員，咱們必需要作好支付的安全性。

　　 那麼，如何規避支付風險？

　　爲了進一步的增強支付功能的安全，也能夠適當的增長一些監控機制，好比：訂單與第三方訂單進行對比，可使用跑批完成，當咱們完成支付的訂單從數據庫中查出來與經過第三方訂單查詢接口查詢出來的同一個訂單金額有異常時，進行報警通知可以及時發現處理，甚至當有異常狀況進行建立訂單的終止，從而把損失降到最低。