前面的文章里講了接口測試通用的一些方法微信訂單系統(tǒng)，同樣也適用于支付系統(tǒng)，下面的內(nèi)容為上一篇接口測試的補充，實際項目中都需要覆蓋到，上篇文章有的下面就不贅述了。上文的鏈接 Belle公主：接口測試沒思路？一篇幫你搞定面試。下面文章主要從支付系統(tǒng)設(shè)計入手進行測試，針對界面功能測試容易忽略但是又十分重要的邏輯。關(guān)于支付密碼、驗證碼、銀行卡綁定等等能從界面入手測試的，下文也不講述，如果有興趣可以留言，后面整理。
1、APP支付結(jié)果查詢是否合理
假設(shè)你測試的系統(tǒng)支持微信支付，在微信支付成功點擊完成返回被測APP，這時候APP的訂單狀態(tài)需要更新，就會向服務器發(fā)起查詢，如果因為網(wǎng)絡(luò)問題沒查到返回結(jié)果，APP需要展示給用戶一個支付處理中的頁面，請用戶等待并再次發(fā)起查詢，但是這個等待和查詢不能是無期限的，需要有次數(shù)限制，如果最后還是沒有查詢到，需要提示用戶稍后查詢，如果查詢到支付結(jié)果，則需要展示給用戶對應的結(jié)果。
2、通知接口測試
如果是支付的時候微信系統(tǒng)因為某些問題不能及時把支付結(jié)果給到我們的系統(tǒng)，那么在微信在處理好支付訂單的時候通常會給我們的系統(tǒng)發(fā)通知，告知這筆訂單的狀態(tài)，服務器拿到通知后更新數(shù)據(jù)庫微信訂單系統(tǒng)，客戶端再發(fā)起查詢的時候就可以拿到支付結(jié)果了，如果通知接口有問題，那就無法正常處理微信的支付通知。這個接口測試通常是RPC接口，可能需要開發(fā)幫忙模擬。
3、定時任務
除了靠微信調(diào)回調(diào)接口進行通知外，支付系統(tǒng)還需要設(shè)置定時任務去定時同步訂單，商戶系統(tǒng)需要有定時任務去查詢支付系統(tǒng)，支付系統(tǒng)也需要有定時任務查詢渠道系統(tǒng)，可以通過把數(shù)據(jù)庫的訂單狀態(tài)由終態(tài)手動改為中間態(tài)，然后觸發(fā)定時任務，看是否能同步到終態(tài)，如在數(shù)據(jù)庫把支付完成的訂單改成支付中，再去觸發(fā)定時任務，查看是否能再同步為支付成功
4、金額計算&取整
有些支付系統(tǒng)涉及到抽傭，一筆支付訂單可能會付到不同的賬戶中，如果又涉及到部分退款的情形，金額的計算就會比較復雜，計算是先乘后除，還是先除后乘，保留是四舍五入保留，還是向上取證還是向下取整呢。假設(shè)有這樣一個場景，用戶向商家支付0.66元，系統(tǒng)用的單位是分，那就是66分，平臺抽成33分，如果這時候用戶申請退款80分，那這80分怎樣從商家和平臺出款呢？
如果是先除后乘，再四舍五入那就是：80/（33+66）≈0.8, 商家退：66*0.8=52.8≈53, 平臺退 33*0.8=26.4≈26，那么問題來了，53+26=79，少退了一分，這里因為先除后乘，在除的時候損失了精度，再乘以一個數(shù)值，損失的精度就更大了
如果是先乘后除，保留一樣的小數(shù)點再四舍五入，就可以避免這個問題了。但是也要注意，先乘后除，會不會溢出呢？如果再采用向上取整或者向下取整，也會有問題，所以涉及到金額，除了考慮單位外，還要考慮合適的取整和計算方法，不然都會導致精度丟失
5、訂單超時處理
如果用戶一直沒有支付，商戶系統(tǒng)和支付系統(tǒng)都需要及時將訂單置為關(guān)閉的終態(tài)，否則定時任務仍然會去查詢，浪費系統(tǒng)資源。
除了超時關(guān)閉外，定義的訂單的各種狀態(tài)都需要覆蓋對應的場景去測試
6、退款
如果訂單未支付、支付中、支付失敗、訂單關(guān)閉、退款成功，則都不能退款成功，退款時需要查詢訂單的狀態(tài)，校驗退款的金額，不能支付50，但是申請退款100
7、優(yōu)惠券、紅包超發(fā)
在出現(xiàn)大量并發(fā)請求時，優(yōu)惠券和紅包發(fā)放是否存在線程安全問題，可以通過寫一個多線程并發(fā)請求腳本或性能測試工具來發(fā)起大量并發(fā)請求
8、賬戶異常
支付賬戶被凍結(jié)、被風控、余額不足的情況，系統(tǒng)需要給出對應的返回
免責聲明：部分文章信息來源于網(wǎng)絡(luò)以及網(wǎng)友投稿，本站只負責對文章進行整理、排版、編輯，出于傳遞更多信息之目的，并不意味著贊同其觀點或證實其內(nèi)容的真實性，如本站文章和轉(zhuǎn)稿涉及版權(quán)等問題，請作者在及時聯(lián)系本站，我們會盡快為您處理。
