第三方支付介面如何測試 【杭州多測師-申sir】
現在有不少測試朋友做的專案中,可能也會涉及到支付相關的功能。比如:做商城的,做遊戲的以及其他線上交易的網站、APP等。如果支付出了問題,或者使用者拿少的錢通過篡改請求資料購買大金額的商品,如果是實物的話,發貨前還有可能被發現。如果是虛擬商品話費、遊戲幣等就有可能造成損失。
所以,不管是實物也好,虛擬商品也好,涉及到支付功能時,大家在測試的過程中一定要重視,否則,會造成很大損失。之前可能大家也都看到過或者聽過一個bug損失4.6億美金的慘痛教訓或者身邊也有發生過其他因為支付功能的bug導致直接損失的案例。 給大家舉個真實的案例:比如使用支付寶購買虛擬商品,往支付寶跳轉時,篡改了小的金額,結果購買虛擬商品成功了。(原本10元的商品,0.01元就搞定了)。多麼可怕的一個bug啊,當然這個問題可能對於一個做過支付有過經驗的測試朋友來說,可能會想:哎呀,這個問題都發現不了,還做什麼測試?是的,問題是很簡單,對於一個剛入職場的測試朋友或者沒有支付相關經驗的測試朋友來說,很有可能會忽略。 那麼,問題來了,對於支付模組的相關測試,我們應該如何進行呢?比如,針對遊戲來說,使用第三方支付往遊戲充值遊戲幣功能,看起來是不是很簡單,大家主要思考下以下內容: 1、支付都是與第三方支付(支付寶、微信、財付通、QQ錢包、簡訊
先看下流程圖,是否對流程圖有些瞭解,不僅僅是做支付功能相關測試才去搞清楚其中的流程,做其他的測試一樣也要搞清楚流程,只有搞清楚流程,才能更好的評估其中的風險,才能有利於測試用例的設計。當然流程圖中只是提到了商戶與第三方是如何互動的,同樣商戶內部處理的流程也要有所瞭解及資料怎麼儲存的,涉及到哪些DB也要清楚。
流程清楚之後,我們再來看看其中會涉及到哪些介面?這個支付流程圖裡面就涉及到了第三方支付介面: · 下單介面:商戶提交下單請求到第三方支付介面,第三方支付收單成功後返回下單成功結果給到商戶系統。(下單介面的最終處理結果分為下單成功和下單失敗,若未收到明確結果可呼叫單筆訂單查詢介面查詢結果。) · 支付介面:呼叫該介面時指定支付引數,完成買家賬戶向商戶賬戶的支付,採用頁面跳轉互動模式和後臺通知互動模式。(結果分為兩路返回:一路為前臺在return_url頁面跳轉顯示支付結果;一路為後臺在notify_url收到支付結果通知後進行響應。) · 退款介面:呼叫第三方支付的支付請求介面返回付款成功後,在需要做退款處理時呼叫退款請求介面發起退款處理。(退款介面的最終處理結果分為退款成功和退款失敗,若未收到明確結果可呼叫退款查詢介面查詢結果。) · 單筆訂單查詢介面:根據訂單號查詢單筆訂單資訊和狀態。 · 退款訂單查詢介面:呼叫第三方支付的退款介面返回後,在需要查詢退款請求狀態可呼叫退款訂單查詢介面查詢退款訂單的狀態和訂單資訊。 那麼針對第三方的介面,我們大致也有所瞭解了,接下來針對測試過程中涉及到主要的測試點整理如下: 測試過程中需要注意的主要測試點及異常場景: · 首先要保證介面都能正常呼叫; · 生成一筆訂單,支付完成後,同步或非同步重複回撥,只有一次有效; · 生成一筆訂單,複製訂單號和金額,再次生成一筆訂單,用fiddler設定斷點,用第一筆已完成的訂單號和訂單金額去替換現有的訂單號和金額,無法完成支付; · 生成一筆訂單,跳轉到第三方時修改金額,無法到賬,或者如果是遊戲充值遊戲幣的話,到賬為篡改後的金額對應的遊戲幣; · 非同步通知遮蔽,同步有效,進行支付,同步能夠正常到賬; · 同步設定無效,非同步有效,進行支付,非同步能夠正常到賬; · 同步非同步都設定無效,在第三方支付完成後,在重發機制時間範圍內,設定非同步有效,到下次通知時間點時,能夠正常通知到賬(補單機制的驗證,如果商戶收到第三方支付成功的通知後,要告知第三方支付收到了成功的通知,如果第三方支付收到商戶應答不是ok或超時,第三方支付就會認為通知失敗,會在規定的時間內持續呼叫notify_url,一般有時間或次數的限制); · 針對支付訂單在資料庫
當一個支付請求被髮送到支付渠道方,支付渠道會很快返回一個結果。但是這個結果,只是告訴你呼叫成功了,不是扣款成功,這叫同步呼叫。很多新手會拿這個結果當作支付成功了,那就會被坑死,結果就是支付成功率特別高,伴隨著一堆無法解釋的壞賬率,測試人員尤其要注意測試資料的篡改:金額,同步返回結果,訂單號等。
同步請求引數裡面會有一個回撥地址,這個地址是支付渠道在扣款成功後呼叫的,這叫非同步呼叫。一般同步介面僅檢查引數是否正確,簽名是否無誤等。非同步接口才告訴你扣款結果。一般非同步介面有5秒以內的延遲。呼叫不成功會重試。有時候是這邊成功了,但支付渠道側沒收到返回,於是會繼續調。當天的支付到第二天還在被非同步呼叫也都是正常的。這也是開發人員需要特別注意的地方,不要當做重複支付。測試人員也要對重複回撥進行測試,應只有一次有效。這還不是最坑的,一般支付渠道側,只有支付成功了才通知你。要是支付失敗了,壓根兒都不告訴你。 另一方面,如何老收不到非同步結果呢?那就得查查了。同步結果不可靠,非同步呼叫不可靠,那怎麼確定支付結果?最終的殺招就是查單了,反查,一般支付渠道側都會提供反查介面,定時獲取DB中待支付的訂單呼叫支付渠道側的反查介面,最終把支付渠道側扣款成功的訂單完成掉。
微信大致流程為:APP端將訂單資訊提交到後臺,後臺通過微信統一下單介面到微信去下單,微信端返回相關資訊到PHP後臺,後臺先將訂單儲存到資料庫成功後,返回簽名信息給APP端去實現真正的支付
支付寶大致流程為:APP端將訂單資訊提交到後臺,後臺通過支付寶規定的簽名演算法將簽名信息返回給APP端,APP端呼叫支付寶SDK去實現支付