網際網路產品接入支付功能如何測試?

2022-08-29 04:18:12 字數 2816 閱讀 5740

網際網路產品接入支付功能如何測試?

現在有不少測試所以,不管是實物也好,虛擬商品也好,涉及到支付功能時,大家在測試的過程中一定要重視,否則,會造成很大損失。之前可能大家也都看到過或者聽過乙個bug損失4.6億美金的慘痛教訓或者身邊也有發生過其他因為支付功能的bug導致直接損失的案例。

給大家舉個真實的案例:比如使用支付寶購買虛擬商品,往支付寶跳轉時,篡改了小的金額,結果購買虛擬商品成功了。(原本10元的商品,0.01元就搞定了)。多麼可怕的乙個bug啊,當然這個問題可能對於乙個做過支付有過經驗的測試朋友來說,可能會想:哎呀,這個問題都發現不了,還做什麼測試?是的,問題是很簡單,對於乙個剛入職場的測試朋友或者沒有支付相關經驗的測試朋友來說,很有可能會忽略。

支付等)進行對接,那麼,是否了解了第三方介面有哪些?是否都能清楚我們的產品與第三方是如何互動的?是否能畫出流程圖?

2、異常場景有哪些?

3、有哪些風險,如何規避?

第三方支付的流程,與商戶的對接方式基本相似,大同小異。(題外推薦:如下流程圖使用的chrome外掛程式:gliffy,個人感覺比較好用。)

支付流程:

退款流程:

查詢流程:

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

流程清楚之後,我們再來看看其中會涉及到哪些介面?這個支付流程圖裡面就涉及到了第三方支付介面:

· 下單介面:商戶提交下單請求到第三方支付介面,第三方支付收單成功後返回下單成功結果給到商戶系統。(下單介面的最終處理結果分為下單成功和下單失敗,若未收到明確結果可呼叫單筆訂單查詢介面查詢結果。)

· 支付介面:呼叫該介面時指定支付引數,完成買家賬戶向商戶賬戶的支付,採用頁面跳轉互動模式和後台通知互動模式。(結果分為兩路返回:一路為前台在return_url頁面跳轉顯示支付結果;一路為後台在notify_url收到支付結果通知後進行響應。)

· 退款介面:呼叫第三方支付的支付請求介面返回付款成功後,在需要做退款處理時呼叫退款請求介面發起退款處理。(退款介面的最終處理結果分為退款成功和退款失敗,若未收到明確結果可呼叫退款查詢介面查詢結果。)

· 單筆訂單查詢介面:根據訂單號查詢單筆訂單資訊和狀態。

· 退款訂單查詢介面:呼叫第三方支付的退款介面返回後,在需要查詢退款請求狀態可呼叫退款訂單查詢介面查詢退款訂單的狀態和訂單資訊。

測試過程中需要注意的主要測試點及異常場景:

· 首先要保證介面都能正常呼叫;

· 生成一筆訂單,支付完成後,同步或非同步重複**,只有一次有效;

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

· 生成一筆訂單,跳轉到第三方時修改金額,無法到賬,或者如果是遊戲充值遊戲幣的話,到賬為篡改後的金額對應的遊戲幣;

· 非同步通知遮蔽,同步有效,進行支付,同步能夠正常到賬;

· 同步設定無效,非同步有效,進行支付,非同步能夠正常到賬;

· 同步非同步都設定無效,在第三方支付完成後,在重發機制時間範圍內,設定非同步有效,到下次通知時間點時,能夠正常通知到賬(補單機制的驗證,如果商戶收到第三方支付成功的通知後,要告知第三方支付收到了成功的通知,如果第三方支付收到商戶應答不是ok或超時,第三方支付就會認為通知失敗,會在規定的時間內持續呼叫notify_url,一般有時間或次數的限制);

· 針對支付訂單在資料庫中儲存是否完整和正確進行校驗(比如:第三方訂單號--方便與第三方對賬和問題排查、訂單金額、訂單狀態等);

· 如果是使用者購買實物商品,使用者發起退貨,要保證退貨流程正常,資金能正常返還,要考慮下併發情況的驗證以確保安全性;

· 如果是使用者購買虛擬商品,比如話費、油卡之類的商品,只有在發貨失敗的時候才能發起退貨,注意驗證;

遇到過的坑:

· 使用者購買100元遊戲幣時,前往第三方支付跳轉進行金額的篡改由100元改成0.01元,結果就拿了0.01元充值了100元的遊戲幣。對訂單金額沒有做校驗導致這樣的後果,損失比較大。大家在測試的過程中一定要注意對服務端進行校驗,支付時資料的篡改一定要有校驗。

· 當同步、非同步通知都存在的情況的,非同步通知(第三方支付成功後台通知),沒有到賬,導致部分使用者充值不到賬,引起客訴。當同步、非同步並存的時候,一定要分別對同步和非同步進行檢驗,確保都能正常到賬。

我們所做的絕大多少的網際網路產品都會涉及到第三方支付,所以支付功能必然是重要的,作為測試網際網路產品的一員,我們必須要做好支付的安全性。

那麼,如何規避支付風險?

為了進一步的加強支付功能的安全,也可以適當的增加一些監控機制,比如:訂單與第三方訂單進行對比,可以使用跑批完成,當我們完成支付的訂單從資料庫中查出來與通過第三方訂單查詢介面查詢出來的同乙個訂單金額有異常時,進行報警通知能夠及時發現處理,甚至當有異常情況進行建立訂單的終止,從而把損失降到最低。

註明:以上內容摘自網路

網際網路產品接入支付功能如何測試?

所以,不管是實物也好,虛擬商品也好,涉及到支付功能時,大家在測試的過程中一定要重視,否則,會造成很大損失。之前可能大家也都看到過或者聽過乙個bug損失4.6億美金的慘痛教訓或者身邊也有發生過其他因為支付功能的bug導致直接損失的案例。給大家舉個真實的案例 比如使用支付寶購買虛擬商品,往支付寶跳轉時,...

網際網路產品

我今天用文字,是為了讓大家能夠清晰的看到乾貨內容,所以我選擇了文字。3 搞成交 有了前面兩步,賺錢就很容易了,你只需要把你的產品進行價值包裝,就可以輕鬆賣出去。如何進行價值包裝呢?我有一本 價值包裝秘笈 可以送給大家。大家如何獲取這本秘笈呢?非常簡單,本文到你的朋友圈,然後私聊找我要,我會免費送你電...

網際網路產品秘籍

很多人都在講 以使用者和市場為中心 但實際上還是 以公司為中心 不能為使用者創造價值。在網際網路領域創業的人越來越多,但究竟怎樣才能打造出一種成功的網際網路產品,一直存在著理解的誤區,也困擾著很多創業者。從我個人多年的實踐中,我認為網際網路產品有幾個容易被忽視的特點 第一,網際網路產品要有乙個靈魂,...