1、atpp_case_remote case遠程通信插件測試，容災場景：
a、消息發送端在網絡異常場景下，第一次發送消息失敗之后的處理。
手段：拔網線模擬；
結果：開發設計之初沒有考慮這種場景，后增加一個google的queue依賴
解決這個問題。實現方式是，當第一次發送失敗后會將發送數據保存一份到本地文件中，然后不斷進行重試發送，直到發送成功；
2、法網狙擊項目暴露了很多異常測試和容災測試方面的考慮欠缺：
a、 PMC流程某個節點服務調用異常的情況下，系統的處理。
按照開發的設計，需要在此時進行調用重試，每2分鐘一次，共重試5次，最后失敗才生成小二任務。
手段：日常下，利用TCC工具對azeroth里面的代碼進行異常注入，使代碼運行到該方法時拋出異常，從而模擬異常場景。
結果：發現從開始使用PMC開始，就沒有對這些異常情況進行考慮，所有的異常都是馬上生成了小二任務進行處理，甚至有一些流程就這樣一直卡住，沒有任何補救措施。
解決：修改PMC的配置，添加異常重試的處理，按照之前的設計進行。
b、 調用消保的凍結、解凍、轉移保證金接口，發生不同的異常場景，返回不同的ERROE CODE，最后本系統進行處理的細節考慮不全。
系統間交互容易出現的問題（針對hsf調用）：
（異常場景）
1、超時時拋出超時異常；
2、序列化/反序列化失敗時拋出HSF異常；
3、沒有可用的目標服務地址時拋出HSF異常；
4、服務端拋出業務異常，返回同樣的業務異常；
5、依賴應用封裝了下一級應用的異常，返回相應的ERROE_CODE；
6、調用的目標服務地址有通信問題，自動嘗試有限次數重新選址；
（并發場景）
1、識別可能存在并發的場景，模擬依賴應用返回并發的ERROR_CODE
（冪等調用）
1、如何模擬冪等調用？？看對方是怎樣判斷冪等性的，如果無法真實模擬對方返回冪等調用結果的場景，則mock掉真實的調用情況，直接返回冪等調用時候的ERROR_CODE。
解決方案：
測試場景應該細化考慮異常場景，包括，超時異常，hsf異常以及各種業務異常返回的處理，而不僅僅是類似系統異常（RuntimeException然后看系統是否重試這么簡單而已）
采用的方式，mockHsf服務調用的返回。之前的方式（bugfix的時候）通過開發在日常debug，修改服務調用返回值來處理。
第一步，先梳理所有調用到消保接口的類和方法；
第二步，每個調用到的地方都嘗試進行mock超時、hsf異常返回的處理，并且明確其他業務異常的返回和處理。
第三部，補充接口腳本覆蓋這些場景。
3、 蓋亞項目中測試品質保障流程中，自動賠付功能，采用mock異常的方式，成功找到了一個嚴重的系統bug：
Bug描述如下：
【接口測試】支付寶余額不足凍結支付寶余額失敗的情況下，沒有去轉移保證金，自動賠付失敗。
按照之前的設計，在支付寶不足的情況下，也是要繼續進行保證金轉移的，轉移失敗了才自動賠付失敗轉人工。在此，mock調用消保的凍結接口返回余額不足的errorcode來驅動下面的邏輯，結果發現不符合期望，促進開發修改掉了這個bug。
二. 我們線容災測試的展望
總結我們先所遇到的異常場景，既不是天災造成的一些異常，也不是由于大訪問量造成的壓力過大而帶來的災難，我們線的客觀情況也注定了我們的訪問量也不會達到很夸張的程度，所以也沒有像交易線那樣的各種開關，流控容災措施。相應的，我們是依賴其各種線的應用比較多的，所以應用間的強弱依賴關系，對強依賴掛掉和弱依賴掛掉之后或者返回異常的容災處理應該是我們線容災測試的重點。
所以我們的目標應該是：在其他依賴掛掉的情況下，不會影響到我們應用的正常運行，所以需要加強這些方面的容災測試。
第一步是要梳理整個服務線的應用強弱依賴關系圖。并針對不同的依賴容災點進行相應的測試，保證最后達到容災的目標。
針對這個，已經有同事提供了解決方案，具體實踐這種方案，暫時沒有看到實例，還需要進一步實踐觀察。