會員管理
- 使用者等級
- 使用者列表
商品管理
- 商品分類
- 品牌
- 商品型別
- 商品屬性（規格、顏色、大小）
- 引數（簡介描述）
- 商品評價
促銷管理
- 團購|秒殺
- 優惠券
訂單管理
- 訂單建立（訂單列表）
- 提貨單列表
- 發貨單
- 售後單
- 退貨單
運營管理
- 廣告位
- 文章列表
支付流程：
- 正常的發起一筆流量充值請求，檢查點
- 使用者發過去的資訊有攜帶key值
- 商戶系統本地資料會留存一份使用者的訂單資訊，並且會根據每筆訂單資訊生成一筆支付資訊（同時留存到本地）
- 第三方支付成功，第三方有存支付訂單資訊
- 充值成功，使用者的流量餘額有對應增加
異常用例
- 修改使用者發過去的資料：
- 產品ID 與價值不對等---->檢查點：篡改資料和key，檢查商戶系統報錯：key值不對或者是使用者資料有誤。
- 取消充值流量
- 重複發起流量充值請求
商戶系統-第三方之間：
- 金鑰搞錯-第三方報錯，不接收金鑰
- 提交商戶系統裡面不存在的訂單/支付訂單->第三方這裡也是不能通過請求
- 篡改使用者支付金額-->第三方也要檢查
第三方--使用者之間:
- 支付密碼錯誤/餘額不足
- 取消支付
- 重複支付[對賬--->處理退款]
退款流程
正常的用例：
- 使用者發起退款--->該使用者的訂單以及支付訂單號都要存在。---檢查點：商戶系統/第三方檢查資料沒有問題，可以退款成功--->交易狀態改成退款
異常用例：
- 無故發起退款：提交不存在的訂單號或者支付訂單號 --->訂單號不存在/支付訂單號不存在
- 資訊不匹配發起退款：提交訂單號與支付訂單號不匹配的資料--->訂單號/支付訂單號有誤
- 退款大於實際金額：提交的退款金額大於實際支付訂單的金額-->商戶系統要報錯
- 商戶系統這裡發過去的請求：退款金額大於實際支付金額-->第三方要報錯
分析二：
對於支付模組的相關測試，我們應該如何進行呢？比如，針對遊戲來說，使用第三方支付往遊戲充值遊戲幣功能，看起來是不是很簡單，大家主要思考下以下內容：
- 支付都是與第三方支付（支付寶、微信、財付通、QQ錢包、簡訊支付等）進行對接，那麼，是否瞭解了第三方介面有哪些？是否都能清楚我們的產品與第三方是如何互動的？是否能畫出流程圖？
- 異常場景有哪些？
- 有哪些風險，如何規避？
第三方支付的流程，與商戶的對接方式基本相似，大同小異。（題外推薦：如下流程圖使用的chrome外掛：Gliffy，個人感覺比較好用。） 支付流程：
- 下單介面：商戶提交下單請求到第三方支付介面，第三方支付收單成功後返回下單成功結果給到商戶系統。（下單介面的最終處理結果分為下單成功和下單失敗，若未收到明確結果可呼叫單筆訂單查詢介面查詢結果。）
- 支付介面：呼叫該介面時指定支付引數，完成買家賬戶向商戶賬戶的支付，採用頁面跳轉互動模式和後臺通知互動模式。（結果分為兩路返回：一路為前臺在return_url頁面跳轉顯示支付結果；一路為後臺在notify_url收到支付結果通知後進行響應。）
- 退款介面：呼叫第三方支付的支付請求介面返回付款成功後，在需要做退款處理時呼叫退款請求介面發起退款處理。（退款介面的最終處理結果分為退款成功和退款失敗，若未收到明確結果可呼叫退款查詢介面查詢結果。）
- 單筆訂單查詢介面：根據訂單號查詢單筆訂單資訊和狀態。
- 退款訂單查詢介面：呼叫第三方支付的退款介面返回後，在需要查詢退款請求狀態可呼叫退款訂單查詢介面查詢退款訂單的狀態和訂單資訊。
- 那麼針對第三方的介面，我們大致也有所瞭解了，接下來針對測試過程中涉及到主要的測試點整理如下：
- 測試過程中需要注意的主要測試點及異常場景：
首先要保證介面都能正常呼叫；
- 生成一筆訂單，支付完成後，同步或非同步重複回撥，只有一次有效；
- 生成一筆訂單，複製訂單號和金額，再次生成一筆訂單，用fiddler設定斷點，用第一筆已完成的訂單號和訂單金額去替換現有的訂單號和金額，無法完成支付；
- 生成一筆訂單，跳轉到第三方時修改金額，無法到賬，或者如果是遊戲充值遊戲幣的話，到賬為篡改後的金額對應的遊戲幣；
- 非同步通知遮蔽，同步有效，進行支付，同步能夠正常到賬；
- 同步設定無效，非同步有效，進行支付，非同步能夠正常到賬；
- 同步非同步都設定無效，在第三方支付完成後，在重發機制時間範圍內，設定非同步有效，到下次通知時間點時，能夠正常通知到賬（補單機制的驗證，如果商戶收到第三方支付成功的通知後，要告知第三方支付收到了成功的通知，如果第三方支付收到商戶應答不是ok或超時，第三方支付就會認為通知失敗，會在規定的時間內持續呼叫notify_url，一般有時間或次數的限制）；
- 針對支付訂單在資料庫中儲存是否完整和正確進行校驗（比如：第三方訂單號--方便與第三方對賬和問題排查、訂單金額、訂單狀態等）；
- 如果是使用者購買實物商品，使用者發起退貨，要保證退貨流程正常，資金能正常返還，要考慮下併發情況的驗證以確保安全性；
- 如果是使用者購買虛擬商品，比如話費、油卡之類的商品，只有在發貨失敗的時候才能發起退貨，注意驗證；
遇到過的坑：
- 使用者購買100元遊戲幣時，前往第三方支付跳轉進行金額的篡改由100元改成0.01元，結果就拿了0.01元充值了100元的遊戲幣。對訂單金額沒有做校驗導致這樣的後果，損失比較大。大家在測試的過程中一定要注意對服務端進行校驗，支付時資料的篡改一定要有校驗。
- 當同步、非同步通知都存在的情況的，非同步通知（第三方支付成功後臺通知），沒有到賬，導致部分使用者充值不到賬，引起客訴。當同步、非同步並存的時候，一定要分別對同步和非同步進行檢驗，確保都能正常到賬。
- 我們所做的絕大多少的網際網路產品都會涉及到第三方支付，所以支付功能必然是重要的，作為測試網際網路產品的一員，我們必須要做好支付的安全性。
那麼，如何規避支付風險？
- 為了進一步的加強支付功能的安全，也可以適當的增加一些監控機制，比如：訂單與第三方訂單進行對比，可以使用跑批完成，當我們完成支付的訂單從資料庫中查出來與通過第三方訂單查詢介面查詢出來的同一個訂單金額有異常時，進行報警通知能夠及時發現處理，甚至當有異常情況進行建立訂單的終止，從而把損失降到最低。