補償：

• 調下游異常：kill掉被調系統的服務，上游發起交易請求；

• 調下游超時：改變被呼叫介面資訊；

• 下游未回撥、回撥超時、回撥異常：

        1、請RD幫忙註釋回撥的程式碼；

        2、模擬下游未回撥：

                a、完成一筆回撥成功，上游也消費成功的交易
                b、更改上游系統資料庫狀態為需要的狀態（成功失敗or處理中）
                c、根據業務場景，決定是從上游手動重發交易觸發補償還是等待系統自動定時補償

                d、將下游系統配置檔案裡地址改為錯誤的

        3、模擬下游未落單：

                a、完成一筆正常交易
                b、刪除（沒有刪除許可權就修改單號）下游訂單、流水及記賬資訊
                c、更改上游訂單狀態及記賬
                d、據業務場景，決定是從上游手動重發交易觸發補償還是等待系統自動定時補償，或者通過curl的方式觸發補償。

                e、將下游系統的防火牆開啟

                f、將下游系統呼叫時間改短一些

• 上游更新資料庫失敗或連線資料庫超時：

        1、請RD幫忙更改程式碼，資料庫更新的部分寫錯邏輯；
        2、模擬資料庫更新失敗或為進行更新：

            a、成功完成一筆交易
            b、不改動下游的內容，將上游資料庫資訊進行更改（包括訂單表、流水錶及賬務資訊）
            c、根據業務場景，決定是從上游手動重發交易觸發補償還是等待系統自動定時補償，或者通過curl的方式觸發補償。

            d、在檢索記錄的時間裡改配置檔案裡的資料庫地址

• 對成功的訂單進行curl補償

回撥：

• 回撥正常：

正常回調測試，包括下游處理中、下游成功、下游失敗等情況的回撥。

• 回撥異常：

        a、請RD幫忙將回調的地址改為錯誤的
        b、不配置MQ或配置錯誤的MQ-TOPIC
        c、回撥先於同步通知
        d、通過curl的方式模擬回撥

冪等：

• 併發
• 併發情況下的MQ重複消費；

• 已成功的訂單進行重發交易

• 已經預下單的訂單進行重發交易，根據不同場景分析是可以繼續支付還是堵重（例如：交易引擎系統的處理是可以在原單基礎上進行支付，pgw的處理是下單失敗）

• 如果是重發簡訊，需要關注1分鐘內的次數限制

定時任務：

• 定時任務關閉，關注是否跑定時；
• 定時任務的配置（是否可以手動觸發）；
• 定時任務開啟，定時任務是否生效並關注定時週期；
• 對賬跑批的定時任務關注時間設定；
• 手動改資料庫狀態後跑task；