3、容灾测试的数据准备

　　容灾测试的数据准备一定要全，不全的数据非常容易遗漏测试场景。可以结合不同的业务测试同学分别准备，既可以保证数据的准确和完整性，也保证了效率。

　　4、测试环境的协调

　　容灾项目的测试无法和普通的业务测试共用一套环境，需要准备独立的环境来进行。不同的测试同学在共用这一套环境时，切换不同的容灾开关需要及时知会到所有人，以防对他人造成影响。当然，如果条件允许，多备几套容灾测试环境自然更好，那样大家可以完完全全的并行测试了。

　　5、容灾测试和普通业务项目测试的不同以及注意事项

　　- 测试容灾点时，需要同步分析日志。因为容灾一般都是测试的异常场景，我们的测试环境经常不稳定，出现各种异常，所以测试时一定要仔细结合日志分析，确认当前展示的结果是否是由于我们的容灾代码生效而出现的。

　　- 对于开发新增的业务代码要尤其注意，重视并配合开发一起做好新代码的容灾工作

　　- 不同系统之间的容灾设计、以及同一个系统中的不同容灾场景的设计需要仔细评估，对潜在可能相互关联的容灾点要重点测试，预防互相影响，导致在极端情况下，出现无法预料的结果。

　　6、代码review

　　容灾项目的代码review非常重要。因为测试工作量大，涉及点多且咋，测试会重点关注已知的容灾点测试，对于未知的场景，只有通过代码review来发现。比如本次的容灾项目中，研发同学通过代码review发现了我们的流控拦截代码将不该拦截的业务代码也给拦截了，而这个如果期望依靠测试来发现，成本将会高很多很多。

　　7、容灾测试的自动化

　　容灾测试的自动化工作是势在必行的。各种大促活动不断的涌入，每次大量的人力成本投入容灾测试着实一种资源浪费。思考了一下后期自动化开展的方式和问题，有待实践论证，这里简单列一下：

　　业务降级/数据备份/请求拦截/自动流控：可以直接选择Ruby自动化或者接口测试来实现，只需提前将对应的开关设置为相应状态即可。但是需要一套独立的环境，不能和正常的业务测试环境共用一套，会相互干扰。

　　强弱依赖设计：需要提前配置一套正确的环境，对环境要求非常高。并且不同的容灾场景无法连续执行，需要手工在机器上执行不同的命令以模拟断网或者流量控制。实现难度较大。远程执行脚本也许可以解决这个问题，有待具体实践。

　　8、容灾线上演练

　　容灾线上演练是容灾项目中特有的一个流程，在前期准备和演练过程中需要注意以下几点：

　　- 提前准备好所有的生产环境测试数据。因为演练一般从夜里凌晨开始，短短的几个小时时间需要演练较多的开关，测试数据准备的充分，可以大大提高演练的效率。

　　- 提前在测试环境做充分的测试，演练的效率才会高。

　　- 开关切换时间尽量短。虽然是在深夜，也依然有很多用户在使用我们的系统，所以每个开关的切换都要考虑到对当前用户的影响。开关生效时间尽量缩短。

　　- 每个开关切换后都一定要切回并再次验证。必要时演练结束后将所有系统全部重启。

　　- 不同系统之间的同业务的开关执行顺序需要提前沟通好。

　　业务容灾的测试在我产品线尝试已有两年之余，但是只有今年的容灾测试才开始趋于系统。经验尚浅，大家如有其他建议或异议，非常欢迎能多沟通交流，期望业务容灾的测试工作能在不断的实践和沟通过程中越来越完善。