业务容错测试总结

业务容错测试总结

　一. 我们线容灾测试现状和实践总结

　　目前 工作过程中遇到的一些涉及到容灾的场景：

　　 1、atpp_case_remote  case远程通信插件测试，容灾场景：

　　a、消息发送端在网络异常场景下，第一次发送消息失败之后的处理。

　　手段：拔网线模拟；

　　结果：开发设计之初没有考虑这种场景，后增加一个google的queue依赖

　　解决这个问题。实现方式是，当第一次发送失败后会将发送数据保存一份到本地文件中，然后不断进行重试发送，直到发送成功；

　 　2、法网狙击项目暴露了很多异常测试和容灾测试方面的考虑欠缺：

　　a、 PMC流程某个节点服务调用异常的情况下，系统的处理。

　　按照开发的设计，需要在此时进行调用重试，每2分钟一次，共重试5次，最后失败才生成小二任务。

　　手段：日常下，利用TCC工具对azeroth里面的代码进行异常注入，使代码运行到该方法时抛出异常，从而模拟异常场景。

　　结果：发现从开始使用PMC开始，就没有对这些异常情况进行考虑，所有的异常都是马上生成了小二任务进行处理，甚至有一些流程就这样一直卡住，没有任何补救措施。

　　解决：修改PMC的配置，添加异常重试的处理，按照之前的设计进行。

　　b、 调用消保的冻结、解冻、转移保证金接口，发生不同的异常场景，返回不同的ERROE CODE，最后本系统进行处理的细节考虑不全。

　　系统间交互容易出现的问题（针对hsf调用）：

　　（异常场景）

　　1、超时时抛出超时异常；

　　2、序列化/反序列化失败时抛出HSF异常；

　　3、没有可用的目标服务地址时抛出HSF异常；

　　4、服务端抛出业务异常，返回同样的业务异常；

　　5、依赖应用封装了下一级应用的异常，返回相应的ERROE_CODE；

　　6、调用的目标服务地址有通信问题，自动尝试有限次数重新选址；

　　（并发场景）

　　1、识别可能存在并发的场景，模拟依赖应用返回并发的ERROR_CODE

　　（幂等调用）

　　1、如何模拟幂等调用？？看对方是怎样判断幂等性的，如果无法真实模拟对方返回幂等调用结果的场景，则mock掉真实的调用情况，直接返回幂等调用时候的ERROR_CODE。

　　 解决方案：

　　测试场景应该细化考虑异常场景，包括，超时异常，hsf异常以及各种业务异常返回的处理，而不仅仅是类似系统异常（RuntimeException然后看系统是否重试这么简单而已）

　　采用的方式，mockHsf服务调用的返回。之前的方式（bugfix的时候）通过开发在日常debug，修改服务调用返回值来处理。

　　第一步，先梳理所有调用到消保接口的类和方法；

　　第二步，每个调用到的地方都尝试进行mock超时、hsf异常返回的处理，并且明确其他业务异常的返回和处理。

　　第三部，补充接口脚本覆盖这些场景。

　　3、 盖亚项目中测试品质保障流程中，自动赔付功能，采用mock异常的方式，成功找到了一个严重的系统bug：

　　 Bug描述如下：

　　【接口测试】支付宝余额不足冻结支付宝余额失败的情况下，没有去转移保证金，自动赔付失败。

　　按照之前的设计，在支付宝不足的情况下，也是要继续进行保证金转移的，转移失败了才自动赔付失败转人工。在此，mock调用消保的冻结接口返回余额不足的errorcode来驱动下面的逻辑，结果发现不符合期望，促进开发修改掉了这个bug。

　　 二. 我们线容灾测试的展望

　　总结我们先所遇到的异常场景，既不是天灾造成的一些异常，也不是由于大访问量造成的压力过大而带来的灾难，我们线的客观情况也注定了我们的访问量也不会达到很夸张的程度，所以也没有像交易线那样的各种开关，流控容灾措施。相应的，我们是依赖其各种线的应用比较多的，所以应用间的强弱依赖关系，对强依赖挂掉和弱依赖挂掉之后或者返回异常的容灾处理应该是我们线容灾测试的重点。

　　所以我们的目标应该是：在其他依赖挂掉的情况下，不会影响到我们应用的正常运行，所以需要加强这些方面的容灾测试。

　　第一步是要梳理整个服务线的应用强弱依赖关系图。并针对不同的依赖容灾点进行相应的测试，保证最后达到容灾的目标。

　　针对这个，已经有同事提供了解决方案，具体实践这种方案，暂时没有看到实例，还需要进一步实践观察。