問(wèn)題描述:

          前文中描述了基于aop的容錯測試解決方法, 我們可以結合具體的業(yè)務(wù),使用場(chǎng)景來(lái)編寫(xiě)腳本進(jìn)行測試.但是實(shí)際工作中,隨著(zhù)業(yè)務(wù)復雜度的不斷提高,系統間的相互依賴(lài)更加復雜,完全依賴(lài)測試人員一個(gè)個(gè)編寫(xiě)針對性的容錯測試腳本來(lái)保證系統的容錯能力,會(huì )越來(lái)越困難.我們需要一個(gè)更”自動(dòng)化”的解決方案.

再仔細分析一下淘寶的實(shí)際使用場(chǎng)景,淘寶的應用這件的依賴(lài)關(guān)系類(lèi)似下圖:

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

    應用提供的服務(wù)如果有異常，對于服務(wù)的使用方來(lái)說(shuō)就是調用HSF時(shí)拋異常，比如在hsf服務(wù)調用超時(shí)，在使用方收到的就是HSFTimeOutException.

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

解決方案：

1. 1.     自動(dòng)的對hsf服務(wù)注入異常.
2. 2.     執行已有的接口測試集,通過(guò)正常測試腳本在mock hsf服務(wù)的環(huán)境下運行,來(lái)研究系統對異常的處理能力。
3. 3.     對錯誤進(jìn)行分析，找出容錯方面的問(wèn)題.

方案結構圖如下：

實(shí)現細節：

方案中測試集的調度，結果報表輸出等內容非本文的重點(diǎn)，不在這里詳述了，重點(diǎn)來(lái)描述一下如何實(shí)現HSF mock對象的自動(dòng)切入.

1. 1.     改寫(xiě)HSF的類(lèi)HSFSpringConsumerBean,定義HSFProxyFactory來(lái)實(shí)現HSFSpringConsumerBean的功能。示例代碼如下：

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

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

總結:

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

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