一.我們線容災測試現狀和實踐總結
目前工作過程中遇到的一些涉及到容災的場景：
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。
二. 我們線容災測試的展望
總結我們先所遇到的異常場景，既不是天災造成的一些異常，也不是由於大訪問量造成的壓力過大而帶來的災難，我們線的客觀情況也注定了我們的訪問量也不會達到很誇張的程度，所以也沒有像交易線那樣的各種開關，流控容災措施。相應的，我們是依賴其各種線的應用比較多的，所以應用間的強弱依賴關係，對強依賴掛掉和弱依賴掛掉之後或者返回異常的容災處理應該是我們線容災測試的重點。
所以我們的目標應該是：在其他依賴掛掉的情況下，不會影響到我們應用的正常執行，所以需要加強這些方面的容災測試。
第一步是要梳理整個服務線的應用強弱依賴關係圖。並針對不同的依賴容災點進行相應的測試，保證最後達到容災的目標。
針對這個，已經有同事提供了解決方案，具體實踐這種方案，暫時沒有看到例項，還需要進一步實踐觀察。
Rabbitmq業務流程包含容錯排查
一 進入死信佇列 進入死信的三種方式 演示 channel.basicreject message.getmessageproperties getdeliverytag true 拒絕訊息 true 傳送給下乙個消費者 false 誰都不接受，從佇列中刪除 fanoutexchange fanou...
容錯恢復性測試（二）
二種方式 跳轉和跳轉返回。關注點 1.中心服關閉，角色是否還能否從戰鬥服務返回。1.角色在跳轉至中心服時，登入服關閉，是否會產生髒資料 2.center服務 中心服，處理大部分的資料，包含狀態，角色其他操作均在此服務進行。如果沒有fighting服務時，center服務將負責這部分的權責。如果有，進...
容錯恢復性測試（二）
二種方式 跳轉和跳轉返回。關注點 1.中心服關閉，角色是否還能否從戰鬥服務返回。1.角色在跳轉至中心服時，登入服關閉，是否會產生髒資料 2.center服務 中心服，處理大部分的資料，包含狀態，角色其他操作均在此服務進行。如果沒有fighting服務時，center服務將負責這部分的權責。如果有，進...