做了四年多的銀行支付系統測試，對支付模式型別略知一二。對於市場上的支付系統，其實原理大同小異。市場上大多數軟體系統涉及到支付功能，都會與第三方支付系統互動，跳轉到相應的支付系統實現其支付功能，下面說下開展這型別測試之前，需要考慮哪些因素：
1，了解第三方支付介面有哪些，系統直接互動如何實現，建議畫流程圖（題外推薦：流程圖可以使用chrome外掛程式：gliffy，個人感覺比較好用。），重複熟悉系統實現流程，只有搞清楚流程，才能更好的評估其中的風險，才能有利於測試用例的設計；
2，除了主要功能之外，還需要考慮異常場景有哪些；
3，有哪些風險？如何規避？
測試過程中需要注意的主要測試點及異常場景：
· 首先要保證介面都能正常呼叫；
· 生成一筆訂單，支付完成後，同步或非同步重複**，只有一次有效；
· 生成一筆訂單，複製訂單號和金額，再次生成一筆訂單，用fiddler設定斷點，用第一筆已完成的訂單號和訂單金額去替換現有的訂單號和金額，無法完成支付；
· 生成一筆訂單，跳轉到第三方時修改金額，無法到賬，或者如果是遊戲充值遊戲幣的話，到賬為篡改後的金額對應的遊戲幣；
· 非同步通知遮蔽，同步有效，進行支付，同步能夠正常到賬；
· 同步設定無效，非同步有效，進行支付，非同步能夠正常到賬；
· 同步非同步都設定無效，在第三方支付完成後，在重發機制時間範圍內，設定非同步有效，到下次通知時間點時，能夠正常通知到賬（補單機制的驗證，如果商戶收到第三方支付成功的通知後，要告知第三方支付收到了成功的通知，如果第三方支付收到商戶應答不是ok或超時，第三方支付就會認為通知失敗，會在規定的時間內持續呼叫notify_url，一般有時間或次數的限制）；
· 針對支付訂單在資料庫中儲存是否完整和正確進行校驗（比如：第三方訂單號--方便與第三方對賬和問題排查、訂單金額、訂單狀態等）；
· 如果是使用者購買實物商品，使用者發起退貨，要保證退貨流程正常，資金能正常返還，要考慮下併發情況的驗證以確保安全性；
· 如果是使用者購買虛擬商品，比如話費、油卡之類的商品，只有在發貨失敗的時候才能發起退貨，注意驗證；
遇到過的坑：
· 使用者購買100元遊戲幣時，前往第三方支付跳轉進行金額的篡改由100元改成0.01元，結果就拿了0.01元充值了100元的遊戲幣。對訂單金額沒有做校驗導致這樣的後果，損失比較大。大家在測試的過程中一定要注意對服務端進行校驗，支付時資料的篡改一定要有校驗。
· 當同步、非同步通知都存在的情況的，非同步通知（第三方支付成功後台通知），沒有到賬，導致部分使用者充值不到賬，引起客訴。當同步、非同步並存的時候，一定要分別對同步和非同步進行檢驗，確保都能正常到賬。
我們所做的絕大多少的網際網路產品都會涉及到第三方支付，所以支付功能必然是重要的，作為測試網際網路產品的一員，我們必須要做好支付的安全性。
那麼，如何規避支付風險？
為了進一步的加強支付功能的安全，也可以適當的增加一些監控機制，比如：訂單與第三方訂單進行對比，可以使用跑批完成，當我們完成支付的訂單從資料庫中查出來與通過第三方訂單查詢介面查詢出來的同乙個訂單金額有異常時，進行報警通知能夠及時發現處理，甚至當有異常情況進行建立訂單的終止，從而把損失降到最低。
web測試的一些關注點
測試內容 詳細描述 頁面跳轉檢查 每乙個鏈結點選後是否有對應的頁面，以及切換後頁面是否正確 開啟新的頁面時，新頁面的初始化是否有異常 許可權系統中，無許可權是否能跳轉過去 滑鼠移動到鏈結上時，是否有變化 相關性檢查 刪除資料前,如該資料有關聯，則提示 增加資料前，如增加前需要有前置條件，則提示 多級...
為什麼要進行介面測試及介面測試的關注點
我的理解 1 為什麼要做介面測試？l 提前發現缺陷，解決問題靠前 l 提前發現業務測試不易測出的缺陷 l 通過邊界值 異常測試等保障介面的健壯性 l 解決黑盒測試無法測試的場景，如測試userid為空或異常值的場景 2 做介面測試的條件？l 完善的api文件 資料型別 必填項 邊界值 預設值 響應資...
關於效能測試的一些關注指標
ps 本文提出的數值不做為判斷標準,數值的大小是根據介面的業務而定的,不同的場景會有的不同的標準.首先應該關注介面的rps 跟平均耗時,這邊壓測工具以locust做為資料提供工具 效能工具很多以適合自己為標準 在使用者上來後關注rps是否滿足1000以上,然後關注介面耗時是否在100ms之內,複雜介...