軟體測試之“支付功能”測試
軟體測試之“支付功能”測試
01測試思維
要分析測試點之前，我們先來梳理一下測試思維。總結來說，任何事物的測試思路都可以總結如下：
第一步：梳理產品的核心業務流程：明白這是個什麼專案，實現了什麼業務，以及是怎麼實現的？
這個步驟一般是參考公司的需求文件來的，如果產品提供需求文件的同時提供了業務流程圖，可以遵循流程圖來梳理；如果產品沒有提供流程圖，就需要測試人員根據需求的理解自己畫出流程圖，達到梳理業務的目的。
第二步：根據流程進行模組細分，然後針對每個功能模組進行詳細的測試點設計和提取。
這個單個功能的測試點提取要覆蓋以下幾個方面：
正常功能驗證：優先覆蓋正常的業務流程和功能驗證，這其實也是單個功能的冒煙測試。冒煙測試先行，如果不通過，可以直接停止測試等開發修復後繼續測試。
異常功能驗證：為了更加貼近使用者的使用產品，我們也要驗證各種異常的場景，故意操作導致出錯，檢查系統的反饋和提示，保證使用者操作失誤的情況能夠得到系統的友好指示。
因為有很多地方的操作都有可能會導致系統異常和報錯，所以為了不漏測，我們需要找出所有可能導致異常的輸入項和選項。所以就到了第三步：
第三步：針對具體功能，尋找每個輸入項和步驟，從以下三個角度來分析測試點 。
-
長度，資料型別，必填項，重複
-
需求的約束條件 + 隱形需求
-
功能之間的互動
這其中就需要用到一些用例的具體設計方法了，比如場景法，等價類法，邊界值法，錯誤推測法等等
第四步：考慮非功能測試點，包括介面、易用性、相容性、安全性、效能壓力
02
支付功能的測試點
基於上面的測試思路，我們可以分析得出“支付功能”測試點如下：
一、梳理支付的業務流程如下：
點選支付---> 選擇支付方式 ---> 確認金額---> 輸入密碼 ---> 成功支付
完成這個流程測試，也就是完成了專案的冒煙測試！然後需要測試針對流程中的每個階段和步驟，具體分析可能導致異常的測試點，所以我們按階段和輸入項來進行劃分如下：
非現金支付時代，非現金支付已經成為了生活不可或缺的一部分，我們只需要一臺手機便可走遍全國各地（前提是支付寶，微信有錢<00>）,那麼作為測試人員，支付測試也是非常重要的一環，那麼下面我就結合一下我的工作中遇到的一些問題，總結一下常見的支付測試：
一：支付的分類：
首先，根據不同維度，通常我們可以把支付分為如下圖所示的種類：
其次，一般來講，線上支付分為兩種消費模式。一種是直接支付金額，如淘寶，京東等購物網站，或是360雲盤，視訊會員等這種會員服務；另一種是充值購買金豆之類的虛擬幣，在網站中使用虛擬幣進行消費，比如遊戲平臺、花椒等產品！
二：功能測試
接下來就是測試方面的工作了，首先進行的是功能測試，那麼我將邊界值、等類劃分、錯誤推測，因果圖等各種測試方法相結合，整理出來了一套相對全面的測試案例，對支付功能進行測試，從而確保整個支付流程和涉及到的支付流程在任何情況下都能使用。
三：介面測試
明確整個支付流程所需要呼叫的介面，分清楚商家和第三方平臺的介面以及引數的請求方式，包括對介面特定引數的加密，使用異常單號模擬支付，對服務端的檢驗等等
四：安全測試
支付都會涉及到金額，那麼就需要考慮安全測試這個方面，支付請求的偽造，金額的惡意篡改，惡意模擬第三方介面來呼叫商家介面等，均是我們需要考慮清楚的問題
五：支付流程：如下圖
六：測試點
支付流程測試點
1、付款金額和應付金額是否一致，（比如：掃描的支付二維碼，和顯示的應支付金額是否一致）。支付還是要走整個支付流程才行，從確認訂單到最後的支付成功，任何一步都有可能有問題。
2、同一種支付方式，不同的支付入口(比如：如下圖所示，支付寶有兩個支付入口。即可通過掃描二維碼支付，也可以通過支付寶網頁支付。在測試過程中，兩個入口都要覆蓋到。
3、支付成功後，產品購買是否成功
(比如會員服務產品，購買後會員到期時間是否正常延遲；比如購買商品，支付成功後，訂單狀態是否更改，商品種類和數量是否正確等等)
4、支付成功後，使用者的金額是否扣除成功
支付金額測試點
1.正常金額支付
2.金額的最小值：0.01
3.無意義的值：0元
4.最大金額：設定支付的最大金額
5.銀行卡或微信等，設定每日最大消費金額或者單筆最大消費金額
6.銀行卡或微信餘額不足時支付
支付流程測試點
1.正常完成支付流程
2.調起訂單後，取消訂單
3.支付中斷後，繼續支付
4.支付中斷後結束支付
5.單筆訂單單筆支付
6.多訂單合併支付
7.持續點選支付，是否會出現多次購買
支付方式測試點
1.支付寶支付
2.支付寶網頁支付
3.微信支付
4.銀行卡支付
優惠券或折扣（有一定的優惠）
支付中使用優惠券/折扣，應付金額和實際支付金額是否正確
優惠券/折扣是否是必選，是否可以不選擇折扣
支付訂單退款完成後，優惠券/折扣是否還能使用
坑一：頁面顯示的應付金額通過介面vip.product返回了，前端顯示出來應付金額。但是，支付的二維碼是通過介面vip.getPayUrl這個介面返回的，結果二維碼掃出來的值和顯示的應付金額不一樣呀！！！最後問題是在於，vip.getPayUrl中取的是伺服器快取，導致二維碼顯示的金額跟前端展示的應付金額不一致。所以測試支付還是要走整個支付流程才行，從確認訂單到最後的支付成功，任何一步都有可能有問題。
坑二：通過支付寶網站支付，支付成功後，頁面沒有跳轉回原服務套餐網頁。最後的原因是服務配置的return_url不正確，導致支付後，沒有跳回原頁面。如果測試用例覆蓋不到這種場景，那麼將會造成非常嚴重的線上事故
來源:圖文來自網路，如有侵權請聯絡刪除