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

　　所以，不管是實物也好，虛擬商品也好，涉及到支付功能時，大家在測試的過程中一定要重視，否則，會造成很大損失。之前可能大家也都看到過或者聽過一個bug損失4.6億美金的慘痛教訓或者身邊也有發生過其他因為支付功能的bug導致直接損失的案例。 　　給大家舉個真實的案例：比如使用支付寶購買虛擬商品，往支付寶跳轉時，篡改了小的金額，結果購買虛擬商品成功了。（原本10元的商品，0.01元就搞定了）。多麼可怕的一個bug啊，當然這個問題可能對於一個做過支付有過經驗的測試朋友來說，可能會想：哎呀，這個問題都發現不了，還做什麼測試？是的，問題是很簡單，對於一個剛入職場的測試朋友或者沒有支付相關經驗的測試朋友來說，很有可能會忽略。 　　那麼，問題來了，對於支付模組的相關測試，我們應該如何進行呢？比如，針對遊戲來說，使用第三方支付往遊戲充值遊戲幣功能，看起來是不是很簡單，大家主要思考下以下內容： 　　1、支付都是與第三方支付（支付寶、微信、財付通、QQ錢包、簡訊支付等）進行對接，那麼，是否瞭解了第三方介面有哪些？是否都能清楚我們的產品與第三方是如何互動的？是否能畫出流程圖？ 　　2、異常場景有哪些？ 　　3、有哪些風險，如何規避？ 　　第三方支付的流程，與商戶的對接方式基本相似，大同小異。

 

 先看下流程圖，是否對流程圖有些瞭解，不僅僅是做支付功能相關測試才去搞清楚其中的流程，做其他的測試一樣也要搞清楚流程，只有搞清楚流程，才能更好的評估其中的風險，才能有利於測試用例的設計。當然流程圖中只是提到了商戶與第三方是如何互動的，同樣商戶內部處理的流程也要有所瞭解及資料怎麼儲存的，涉及到哪些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去實現支付