問題描述:

          前文中描述了基于aop的容錯測試解決方法, 我們可以結合具體的業務,使用場景來編寫腳本進行測試.但是實際工作中,隨著業務復雜度的不斷提高,系統間的相互依賴更加復雜,完全依賴測試人員一個個編寫針對性的容錯測試腳本來保證系統的容錯能力,會越來越困難.我們需要一個更”自動化”的解決方案.

再仔細分析一下淘寶的實際使用場景,淘寶的應用這件的依賴關系類似下圖:

一個淘寶的應用，依賴幾十個其他應用提供的服務是很正常的現象。依賴系統之間使用HSF服務(淘寶內部的分布式的服務框架,RPC解決方案)來進行相互調用,在調用方進行如下的配置，就可以調用遠程的hsf服務.

    應用提供的服務如果有異常，對于服務的使用方來說就是調用HSF時拋異常，比如在hsf服務調用超時，在使用方收到的就是HSFTimeOutException.

   目前的方案，淘寶在一些大型活動前，比如雙11，雙12前會進行錯誤預演，比如進行模擬某個應用掛機，其他的依賴它的應用是否正常.但是這樣的活動成本比較大，需要影響正常的業務流程，不能成為常態化的手段。如何有一個能夠在任何機器上都能運行的（甚至服務都不需要部署）分布式系統容錯測試方案是本文討論的目標.

解決方案：

1. 1.     自動的對hsf服務注入異常.
2. 2.     執行已有的接口測試集,通過正常測試腳本在mock hsf服務的環境下運行,來研究系統對異常的處理能力。
3. 3.     對錯誤進行分析，找出容錯方面的問題.

方案結構圖如下：

實現細節：

方案中測試集的調度，結果報表輸出等內容非本文的重點，不在這里詳述了，重點來描述一下如何實現HSF mock對象的自動切入.

1. 1.     改寫HSF的類HSFSpringConsumerBean,定義HSFProxyFactory來實現HSFSpringConsumerBean的功能。示例代碼如下：

1. 2.  在測試腳本的bean配置中增加BeanFactoryPostProcessor接口的實現類HsfMockProcess,用來修改ApplicationContext,把容器中的HSFSpringConsumerBean配置替換成HSFProxyFactory.示例代碼如下：

1. 3.     接下去只要運行mvn命令，選擇你希望mock的hsf服務，就可以在錯誤注入的情況下運行測試集了。mvn test –DmockHsfName=****

總結:

利用已有的測試腳本，再通過自動注入想要的對象，我們可以以最小成本達到“故障演練”的目的.但是考慮到依賴的服務量n比較大，腳本量m也比較大,實際在運行過程中需要考慮不同的調度策略，以及m*n集合如何展示，如何更有效&更清晰得報表顯示等問題，在本文中就不一一闡述了，對這塊內容感興趣的同學可以聯系我，后續我們一起來完善

原文轉自：http://www.taobaotesting.com/blogs/2444