怎樣進行支付測試？

如今，隨著非現金支付手段的不斷推廣和應用，“非現金社會”正在形成。非現金支付已成為日常生活中不可或缺的夥伴。那麼，對於網際網路產品來說，支付也是涉及到公司收入的一個重大環節。對於我們測試人員，支付測試也是測試中的重要一環。下面就結合工作中遇到的問題，來給大家介紹一下常用的支付測試。 　　支付分類 　　首先，根據不同維度，我們可以把支付分為不同的種類。如下圖所示： 　　其次，一般來講，線上支付分為兩種消費模式。一種是直接支付金額，如淘寶，京東等購物網站，或是360雲盤，視訊會員等這種會員服務；另一種是充值購買金豆之類的虛擬幣，在網站中使用虛擬幣進行消費，比如遊戲平臺、花椒等產品。 　　測試方法 　　功能測試

　　通過將邊界值分析、等價類劃分、錯誤推測、因果圖等各種測試方法進行結合，整理出儘可能全面的測試案例，對支付功能及其相關功能進行測試，以確保整個支付流程以及涉及到支付流程的其他流程在任何情況下都能正常進行。 　　介面測試 　　明確整個支付流程所需要呼叫的介面，分清楚商家和第三方支付平臺的介面以及引數和請求方式。包括對介面特定引數的加密，使用異常訂單號模擬支付，對服務端的校驗等等。 　　功能測試 　　支付涉及到金額方面，所以要考慮安全測試方面。支付請求的偽造、金額的惡意篡改、惡意模擬第三方介面來呼叫商家介面等等。這都是我們需要考慮到的問題。 　　支付流程 　　常見的支付流程如下圖所示： 　　測試點 　　支付流程測試點 　　1、付款金額和應付金額是否一致 　　（比如：掃描的支付二維碼，和顯示的應支付金額是否一致）。歪個樓，題主曾經就踩過坑呀，頁面顯示的應付金額通過介面vip.product返回了，前端顯示出來應付金額。但是，支付的二維碼是通過介面vip.getPayUrl這個介面返回的，結果二維碼掃出來的值和顯示的應付金額不一樣呀！！！最後問題是在於，vip.getPayUrl中取的是伺服器快取，導致二維碼顯示的金額跟前端展示的應付金額不一致。所以測試支付還是要走整個支付流程才行，從確認訂單到最後的支付成功，任何一步都有可能有問題。 　　2、同一種支付方式，不同的支付入口 　　(比如：如下圖所示，支付寶有兩個支付入口。即可通過掃描二維碼支付，也可以通過支付寶網頁支付。在測試過程中，兩個入口都要覆蓋到。再歪個樓，題主在測試過程中踩過的坑二：通過支付寶網站支付，支付成功後，頁面沒有跳轉回原服務套餐網頁。最後的原因是服務配置的return_url不正確，導致支付後，沒有跳回原頁面。如果測試用例

覆蓋不到這種場景，那麼將會造成非常嚴重的線上事故。 　　3、支付成功後，產品購買是否成功 　　(比如會員服務產品，購買後會員到期時間是否正常延遲；比如購買商品，支付成功後，訂單狀態是否更改，商品種類和數量是否正確等等) 　　4、支付成功後，使用者的金額是否扣除成功 　　支付金額測試點 　　1.正常金額支付 　　2.金額的最小值：0.01 　　3.無意義的值：0元 　　4.最大金額：設定支付的最大金額 　　5.銀行卡或微信等，設定每日最大消費金額或者單筆最大消費金額 　　6.銀行卡或微信餘額不足時支付 　　支付流程測試點 　　1.正常完成支付流程 　　2.調起訂單後，取消訂單 　　3.支付中斷後，繼續支付 　　4.支付中斷後結束支付 　　5.單筆訂單單筆支付 　　6.多訂單合併支付 　　7.持續點選支付，是否會出現多次購買 　　支付方式測試點 　　1.支付寶支付 　　2.支付寶網頁支付 　　3.微信支付 　　4.銀行卡支付 　　優惠券或折扣（有一定的優惠） 　　支付中使用優惠券/折扣，應付金額和實際支付金額是否正確 　　優惠券/折扣是否是必選，是否可以不選擇折扣 　　支付訂單退款完成後，優惠券/折扣是否還能使用