支付平台是如何測試各種渠道和銀行通道？
作為一個支付平台，接入了快錢、易寶或直連銀行等多家的渠道，內在的產品流程是自己的。業內有什麼比較好的測試辦法，來測試各渠道及其支持的銀行通道呢？作為產品，我自己辦了十幾張銀行卡方便測試，但QA和開發不願意這樣做，怎麼辦呢？
對支付平台而言，與支付渠道相關的測試大致可以分為：測試支付渠道功能、測試支付產品功能。
1、支付渠道功能測試
主要是測試與銀行、銀聯、其他外部支付渠道以及諸如實名認證等非支付類功能的功能。
一般情況下，支付渠道的介面只對第三方支付內部開放，不會直接將支付渠道暴露給外部商戶，對外部商戶都是包裝成支付產品形式提供的。
支付渠道是第三方支付公司最基礎的能力，由於涉及調用外部形形色色的各種介面及服務，各家的渠道提供的測試環境、准生產環境、生產環境要求也不同，同時第三方支付自己也需要維護對應的測試環境、准生產環境、生產環境不同版本的環境，要完整做測試確實挺麻煩。
測試方法：
在內部開發一套統一的測試網關（不管是介面通信協議是socket、http、xml等，一般都統一為http以方便測試），統一各種渠道的測試入口，針對不同的渠道維護對應的介面參數模板，方便測試人員快速輸入並提交原始的支付請求。
提交到支付渠道後，如果支付渠道維護有測試環境、准測試環境，則可以直接用提供的測試賬號完成實際調用支付渠道測試。
如果不提供，只能像題主一樣，針對不同的渠道開通銀行卡、對公賬戶等進行測試。此種情況下一般都以最低限額測試。
測試卡的申請、測試費用出處、日常管理可以根據每家公司實際情況制定對應政策，最好是公司承擔各種費用、簡化相關流程並有對應的激勵措施，例如不要對此類費用還要走極為漫長的報銷流程。
測試目的：
保證支付渠道功能的正確性、完整性、可用性，驗證渠道是否暢通、功能是否正常。
一個典型例子是，原有支付渠道新上線一個功能，生產環境測試發現有問題，要在生產環境完整跑一邊流程極為麻煩，可以用測試或准生產環境穩定版本的測試網關測試，快速定位是上線新版本影響生成功能，還是支付渠道端的問題，或者生產環境網路等問題影響。
這裡的支付產品可以是第三方支付內部的基礎性產品，也可以是對外部商戶提供的產品或介面。
此種情況下，測試重點不是支付渠道的基礎功能，而是支付產品的核心功能。對支付產品而言，可以假設支付渠道是一個黑盒子，黑盒子對外提供的服務是可靠穩定的。
測試方法：
在內部開發一套支付渠道的模擬網關，對各種支付渠道的各個介面功能進行模擬並根據支付請求返回對應的模擬報文。支付請求不用實際提交給外部支付渠道。
一般模擬網關與上面的測試網關會統一開發部署。
首先保證測試環境請求及回調正常，需要注意的是我們走的是公網，肯定會出現一些網路導致的通信異常，此時異常處理機制非常重要，包括主動狀態查詢、日終對賬等。
測試環境驗證通過後，我覺得生產環境只需搞一張銀行卡即可，保證業務流程跑通，其次需與支付機構確認生產環境支持的渠道。理論上你生產環境測一個渠道和測十個渠道沒有什麼區別。
這段時間正好，在做這塊！
其一 通道測試/銀行通道本身
核心是功能測試，印證通道介面是否正確： 發送和接受參數是否精確
返回參數的處理，是否正確，符合當前業務需求
因為這是對接別人通道，基本上只要驗證流通性和異常返回狀態是否完善就可以了，關於性能方面在通道開放方應該要做過驗證的！
其二 在此基礎上的支付產品
除了基礎的功能測試，尤其是數據的準確性和及時性
額外需要注意性能，在高數據量時，或者伺服器在高壓力下時，是否仍然能對數據做出正確的處理！或者其他延遲處理的辦法！
還有安全！ 本身產品在發出請求和請求處理時是否驗證原始數據，否則很容易出現問題的
但是基本上做到這些應該可以達到基本業務使用要求了
開發一套支付渠道的模擬網關，對開發來說工作量不小，中小公司並不願意花費大力氣在這上面，一般只保證功能正常 ，業務流程正常就了事了
可以支付或者匯款一分錢，然後看返回狀態。
推薦閱讀：