问题描述:

          前文中描述了基于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