3、 盖亚项目中测试品质保障流程中，自动赔付功能，采用mock异常的方式，成功找到了一个严重的系统bug：
Bug描述如下：
【接口测试】支付宝余额不足冻结支付宝余额失败的情况下，没有去转移保证金，自动赔付失败。
按照之前的设计，在支付宝不足的情况下，也是要继续进行保证金转移的，转移失败了才自动赔付失败转人工。在此，mock调用消保的冻结接口返回余额不足的errorcode来驱动下面的逻辑，结果发现不符合期望，促进开发修改掉了这个bug。
二. 我们线容灾测试的展望
总结我们先所遇到的异常场景，既不是天灾造成的一些异常，也不是由于大访问量造成的压力过大而带来的灾难，我们线的客观情况也注定了我们的访问量也不会达到很夸张的程度，所以也没有像交易线那样的各种开关，流控容灾措施。相应的，我们是依赖其各种线的应用比较多的，所以应用间的强弱依赖关系，对强依赖挂掉和弱依赖挂掉之后或者返回异常的容灾处理应该是我们线容灾测试的重点。
所以我们的目标应该是：在其他依赖挂掉的情况下，不会影响到我们应用的正常运行，所以需要加强这些方面的容灾测试。
第一步是要梳理整个服务线的应用强弱依赖关系图。并针对不同的依赖容灾点进行相应的测试，保证最后达到容灾的目标。
针对这个，已经有同事提供了解决方案，具体实践这种方案，暂时没有看到实例，还需要进一步实践观察。
