跳槽高峰期，作為測試，不管是面試還是筆試，必然要被考驗到的就是”測試思維“。在面試中就是體現在如下面試題中：
“說說你項目中的 xx 模塊你是如何測試的？”
“給你一個購物車，你要怎么測試？”
"你說一下這個產品的登錄功能有哪些測試點？"
“支付功能怎么測試？”
......
所有的這些問題其實都是在考察你的測試思維。我們再回答這類問題的時候有方法可依循的。
今天這篇文章，我就很多同學都覺得難的一個問題“支付功能”作為案例，一起來分析一下如何回答這類的面試題。
測試思維
要分析測試點之前，我們先來梳理一下測試思維。總結來說，任何事物的測試思路都可以總結如下：
第一步：梳理產品的核心業務流程：明白這是個什么項目，實現了什么業務，以及是怎么實現的？
這個步驟一般是參考公司的需求文檔來的，如果產品提供需求文檔的同時提供了業務流程圖，可以遵循流程圖來梳理；如果產品沒有提供流程圖，就需要測試人員根據需求的理解自己畫出流程圖，達到梳理業務的目的。
第二步：根據流程進行模塊細分，然后針對每個功能模塊進行詳細的測試點設計和提取。
這個單個功能的測試點提取要覆蓋一下幾個方面：
正常功能驗證：優先覆蓋正常的業務流程和功能驗證，這其實也是單個功能的冒煙測試。冒煙測試先行，如果不通過，可以直接停止測試等開發修復后繼續測試。
異常功能驗證：為了更加貼近用戶的使用產經，我們也要驗證各種異常的場景，故意操作導致出錯，檢查系統的反饋和提示，保證用戶操作失誤的情況能夠得到系統的友好指示。
因為有很多地方的操作都有可能會導致系統異常和拋錯，所以為了不漏測，我們需要找出所有可能導致異常的輸入項和選項。所以就到了第三步：
第三步：針對具體功能，尋找每個輸入項和步驟，從以下三個角度來分析測試點 。
- 長度，數據類型，必填項，重復
- 需求的約束條件 + 隱形需求
- 功能之間的交互
這其中就需要用到一些用例的具體設計方法了，比如場景法，等價類法，邊界值法，錯誤推測法等等
第四步：考慮非功能測試點，包括界面、易用性、兼容性、安全性、性能壓力
支付功能的測試點
基于上面的測試思路，我們可以分析得出“支付功能”測試點如下：
一、梳理支付的業務流程如下：
點擊支付---> 選擇支付方式 ---> 確認金額---> 輸入密碼 ---> 成功支付
完成這個流程測試，也就是完成了項目的冒煙測試！然后需要測試針對流程中的每個階段和步驟，具體分析可能導致異常的測試點，所以我們按階段和輸入項來進行劃分如下：
1）點擊支付，提交訂單但是取消了，檢查可以取消成功
2）選擇支付方式：
正常：可以支持的支付方式有：信用卡，儲蓄卡，網銀支付，余額，第三方支付（微信，支付寶，京東、百度、聚合支付、組合支付），找人代付，驗證是否支持并且可以正常選擇并支付；
異常: 沒有綁定任何的支付方式時，支付報錯。
**功能交互：**支付時結合優惠券/折扣券/促銷價抵扣進行相關的抵扣，驗證規則正確，并且可以正常抵扣和支付。
3）確認支付金額：這個步驟可以用到等價類和邊界值的用例設計方法
正常：正常金額里用邊界值法去測試點：
最大支付金額（單日最大，單筆最大，余額最大）
最小支付金額
異常：同樣也用邊界值方法提取測試點：
超過支付方式單日最大消費金額/單筆最大/余額最大
異常金額支付：非數字、負數、0，小數點超過 2 位等
4）支付密碼：
正常：可以支持的支付密碼類型有：指紋，人臉識別，賬號密碼，動態獲取驗證碼，手勢，信用卡和支付碼，小額免密等，確認自己的產品所支持的密碼類型，確認可以驗證并支付成功；
異常：輸入錯誤的密碼，檢查有無提示信息且正確；超過密碼錯誤上限，檢查是否凍結等。
5）其他場景測試點：
a、多筆訂單合并支付，是否可以成功；
b、重復點擊支付按鈕，是否會出現多次購買，并同步檢查數據庫的數據帳賬目正確；
c、支付中斷：
主動中斷：可以繼續支付并成功
被動中斷：比如電話、低電量、鬧鐘，斷網、切換后臺、耳機插拔等，驗證可以繼續支付；
d、網絡測試：
驗證各種網絡類型：2G、3G, 4G，5G，wifi 下都可以正常支付；
進行網絡切換，支付功能正常；
弱網測試下支付功能正常：不會重復支付多次，App 不會閃退 崩潰，而且頁面提示友好；
e、使用 fiddler 等抓包篡改價格：不允許抓包或者數據加密，篡改不成功
二、退款流程
**正常：**驗證正常的退款流程，也就是退款的冒煙測試：
1、點擊退款可以退款成功，并且檢查交易狀態是退款，退款金額可以到賬；
2、結合優惠券等抵扣，可以退款實際支付金額；
3、同步檢查數據庫的數據和賬目是正確的；
異常：提交錯誤退款（退款訂單號不對），或者退款金額錯誤，都能夠退款失敗（此處一般會借助工具進行測試，比如進行接口測試）；
三、測試方法
那么以上的測試點在具體公司項目中要怎么進行測試呢？我們有不同的一些測試方法：
1） 小額支付：
需要讓開發修改代碼，不管支付多少錢，實際支付都是 1 分錢；不顧這種方法只能測試小額支付，就有可能會出現產品小額支付沒問題，但是大額支付就錯誤的漏測情況；
2）申請測試金額：
這種方式一般會作為小額支付的一種補充，比如測試完小額支付后，再測試一些大額支付，這就需要跟公司申請測試基金，走報銷流程；
3）沙箱支付：
沙箱支付是一種虛擬的支付，不是真實的金額；這種方法可以驗證小額和大額的支付流程；不過目前只有支付寶沙箱比較成熟可用，其他的支付方法不可用。
四、非功能測試點
測試完以上的功能測試點之后，我們還需要驗證一些非功能測試點，主要包括以下幾個方面：
1）界面
驗證界面的美觀，排版和錯別字等。
2）兼容性
**BS：**如果是 BS 架構的產品，需要測試跟瀏覽器的兼容性；所以就需要根據瀏覽器的內核，選擇一些主流的瀏覽器進行測試；
CS：如果 CS 架構的產品，測試手機移動端的兼容，比如手機型號，系統版本和屏幕大小及分辨率等。
3）易用性
測試站在用戶的角度考慮用戶體驗，使用是否方便等。
4）性能
比如考慮多用戶支付，長時間運行等，關注產品的響應時間等，一般需要借助工具或者代碼進行測試。
5）安全
驗證敏感信息是否加密，是否可以篡改；通過一些工具進行安全掃描，檢查是否有安全漏洞；或者采用一些其他的手段進行專門的安全測試。
