Java中交互方式分為同步和異步兩種：

同步：指發(fā)出一個請求后，需要等待返回，才能進行下一個請求觸發(fā)，有個等待的過程

異步：指發(fā)出一個請求后，不需要等待返回，隨時可以觸發(fā)下一個請求，不需要等待

區(qū)別：一個需要等待，一個不需要等待，在部分情況下、有的項目開發(fā)中都會優(yōu)先選擇不需要等待的異步交互方式。

哪些情況建議使用同步交互呢？

比如銀行的轉賬系統，對數據庫的保存操作等等，都會使用同步交互操作，其余情況都優(yōu)先使用異步交互。

換種方式也可以這樣理解：

1.用戶（買家）支付完成后，電商平臺需要實時的給用戶一個通知，如支付已經處理等待訂單確認。

2.電商平臺，這塊就需要考慮系統技術方面的各個環(huán)節(jié)，考慮應對復雜多變的并發(fā)用戶量、業(yè)務、流量、網絡環(huán)境等因素，我們需要把可以異步化的任務進行分離，算是保障系統可造性、可用性的一個重要的點。

3.電商網站每秒鐘承接1w、5w、10W交易量甚至更高的時候，實時處理這些請求挑戰(zhàn)很大，但如果把這些請求分離業(yè)務狀態(tài)實現異步化，放入消息系統、異步準實時環(huán)境，進而整體網站的復雜度降低，這就是同步和異步通知存在的意義。

4.第三方支付公司接入文檔上都會有以異步通知為準的約束。

5.其實除了通知這塊，還有一塊會被忽略，就是支付查詢類接口，這一塊的作用如果用好了，對系統業(yè)務層會省很多人力

我們測試一般當完成一個支付請求被發(fā)送到支付渠道方，支付渠道會很快返回一個結果。但是這個結果，只是告訴你調用成功了，不是扣款成功，這叫同步調用。很多人拿這個結果當作支付成功了，那就會被坑死，結果就是支付成功率特別高，伴隨著一堆無法解釋的壞賬率，測試人員尤其要注意測試數據的篡改：金額，同步返回結果，訂單號等。

? ? 同步請求參數里面會有一個回調地址，這個地址是支付渠道在扣款成功后調用的，這叫異步調用。

一般同步接口僅檢查參數是否正確，簽名是否無誤等。

異步接口才告訴你扣款結果（成功或者失?。Ｒ话惝惒浇涌谟?秒以內的延遲。調用不成功會重試。有時候是這邊成功了，但支付渠道側沒收到返回，于是會繼續(xù)調。當天的支付到第二天還在被異步調用也都是正常的。這也是開發(fā)人員需要特別注意的地方，不要當做重復支付。測試人員也要對重復回調進行測試，應只有一次有效。這還不是最坑的，一般支付渠道側，只有支付成功了才通知你。要是支付失敗了，壓根兒都不告訴你。 另一方面，如何老收不到異步結果呢？那就得查查了。同步結果不可靠，異步調用不可靠，那怎么確定支付結果？最終的殺招就是查單了，反查，一般支付渠道側都會提供反查接口，定時獲取DB中待支付的訂單調用支付渠道側的反查接口，最終把支付渠道側扣款成功的訂單完成掉。

交互時候測試人員應該注意：

1，校驗同步接口參數是否正確，簽名是否有誤

2，對重復回調進行測試，應當只有一次有效

3，如果發(fā)送消息，接收消息方失敗，但是未返回給傳送消息者失敗的消息，比如支付失敗，那結果總收不到異步結果，

解決方法：根據提供的反查接口進行反查