【轉載】第三方支付業務如何測試

如今有很多 測試朋友作的項目中，可能也會涉及到支付相關的功能。好比：作商城的，作遊戲的以及其餘在線交易的網站、APP等。若是支付出了問題，或者用戶拿少的錢經過篡改請求數據購買大金額的商品，若是是實物的話，發貨前還有可能被發現。若是是虛擬商品話費、遊戲幣等就有可能形成損失。

　　因此，不論是實物也好，虛擬商品也好，涉及到支付功能時，你們在測試的過程當中必定要重視，不然，會形成很大損失。以前可能你們也都看到過或者聽過一個bug損失4.6億美金的慘痛教訓或者身邊也有發生過其餘由於支付功能的bug致使直接損失的案例。

　　給你們舉個真實的案例：好比使用支付寶購買虛擬商品，往支付寶跳轉時，篡改了小的金額，結果購買虛擬商品成功了。（本來10元的商品，0.01元就搞定了）。多麼可怕的一個bug啊，固然這個問題可能對於一個作過支付有過經驗的測試朋友來講，可能會想：哎呀，這個問題都發現不了，還作什麼測試？是的，問題是很簡單，對於一個剛入職場的測試朋友或者沒有支付相關經驗的測試朋友來講，頗有可能會忽略。

　　那麼，問題來了，對於支付模塊的相關測試，咱們應該如何進行呢？好比，針對遊戲來講，使用第三方支付往遊戲充值遊戲幣功能，看起來是否是很簡單，你們主要思考下如下內容：

　　一、支付都是與第三方支付（支付寶、微信、財付通、QQ錢包、 短信支付等）進行對接，那麼，是否瞭解了第三方接口有哪些？是否都能清楚咱們的產品與第三方是如何交互的？是否能畫出流程圖？

　　二、異常場景有哪些？

　　三、有哪些風險，如何規避？

　　第三方支付的流程，與商戶的對接方式基本類似，大同小異。（題外推薦：以下流程圖使用的chrome插件：Gliffy，我的感受比較好用。）

　　支付流程：

　　退款流程：

　　查詢流程：

　　先看下流程圖，是否對流程圖有些瞭解，不只僅是作支付功能相關測試纔去搞清楚其中的流程，作其餘的測試同樣也要搞清楚流程，只有搞清楚流程，才能更好的評估其中的風險，纔能有利於 測試用例的設計。固然流程圖中只是提到了商戶與第三方是如何交互的，一樣商戶內部處理的流程也要有所瞭解及數據怎麼存儲的，涉及到哪些DB也要清楚。

　　流程清楚以後，咱們再來看看其中會涉及到哪些接口？這個支付流程圖裏面就涉及到了第三方支付接口：

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

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

　　· 退款接口：調用第三方支付的支付請求接口返回付款成功後，在須要作退款處理時調用退款請求接口發起退款處理。（退款接口的最終處理結果分爲退款成功和退款失敗，若未收到明確結果可調用退款查詢接口查詢結果。）

　　· 單筆訂單查詢接口：根據訂單號查詢單筆訂單信息和狀態。

　　· 退款訂單查詢接口：調用第三方支付的退款接口返回後，在須要查詢退款請求狀態可調用退款訂單查詢接口查詢退款訂單的狀態和訂單信息。

　　那麼針對第三方的接口，咱們大體也有所瞭解了，接下來針對測試過程當中涉及到主要的測試點整理以下：

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

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

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

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

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

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

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

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

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

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

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

　　遇到過的坑：

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

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

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

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

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

 

 

 

 

當一個支付請求被髮送到支付渠道方，支付渠道會很快返回一個結果。可是這個結果，只是告訴你調用成功了，不是扣款成功，這叫同步調用。不少新手會拿這個結果看成支付成功了，那就會被坑死，結果就是支付成功率特別高，伴隨着一堆沒法解釋的壞帳率，測試人員尤爲要注意測試數據的篡改：金額，同步返回結果，訂單號等。

同步請求參數裏面會有一個回調地址，這個地址是支付渠道在扣款成功後調用的，這叫異步調用。通常同步接口僅檢查參數是否正確，簽名是否無誤等。異步接口才告訴你扣款結果。通常異步接口有5秒之內的延遲。調用不成功會重試。有時候是這邊成功了，但支付渠道側沒收到返回，因而會繼續調。當天的支付到次日還在被異步調用也都是正常的。這也是開發人員須要特別注意的地方，不要當作重複支付。測試人員也要對重複回調進行測試，應只有一次有效。這還不是最坑的，通常支付渠道側，只有支付成功了才通知你。要是支付失敗了，壓根兒都不告訴你。 另外一方面，如何老收不到異步結果呢？那就得查查了。同步結果不可靠，異步調用不可靠，那怎麼肯定支付結果？最終的殺招就是查單了，反查，通常支付渠道側都會提供反查接口，定時獲取DB中待支付的訂單調用支付渠道側的反查接口，最終把支付渠道側扣款成功的訂單完成掉。

 

 

 微信大體流程爲：APP端將訂單信息提交到後臺，後臺經過微信統一下單接口到微信去下單，微信端返回相關信息到PHP後臺，後臺先將訂單保存到數據庫成功後，返回簽名信息給APP端去實現真正的支付

    支付寶大體流程爲：APP端將訂單信息提交到後臺，後臺經過支付寶規定的簽名算法將簽名信息返回給APP端，APP端調用支付寶SDK去實現支付