支付-补偿的测试场景及测试方法

补偿的场景在多数系统交互及业务场景中都会出现，为了保证测试质量、产品质量，对于补偿的测试也就显得尤其重要，下面是测试过程中总结的对于补偿的测试场景及方法；

补偿可能的发生的业务场景，其实是所有业务都有可能发生，比如：绑卡、下单、支付、退款、长款、短款、代付、退汇等等。

场景及测试方法总结：

1、调下游异常：

kill掉被调系统的服务，上游发起交易请求；

2、调下游超时：

方法一：改变被调用的接口信息；

方法二：将下游系统调用时间改短一些

3、下游未回调、回调超时、回调异常；

        方法一：请RD帮忙注释回调的代码；

        方法二：模拟下游未响应或回调

                a、完成一笔回调成功，上游也消费成功的交易

                b、更改上游系统数据库状态为需要的状态（一般为处理中）

                c、根据业务场景，决定是从上游手动重发交易触发补偿还是等待系统自动task定时补偿，或者通过curl的方式触发补偿；

  方法三：模拟下游未回调

                a、将下游系统配置文件里地址改为错误的配置，回调失败

         b、根据业务场景，决定是从上游手动重发交易触发补偿还是等待系统自动task定时补偿，或者通过curl的方式触发补偿；

4、下游响应或回调后，上游更新数据库失败或连接数据库超时；

         方法一：请RD帮忙更改代码，数据库更新的部分写错逻辑或注释掉更新数据库的代码；

  方法二：模拟数据库状态更新失败或未进行更新

         a、成功完成一笔交易

         b、不改动下游的订单信息，将上游数据库信息进行更改（包括订单表、流水表及账务信息），模拟更新数据库失败或超时；

         c、根据业务场景，决定是从上游手动重发交易触发补偿还是等待系统自动定时补偿，或者通过curl的方式触发补偿；

  方法三：模拟数据库状态未进行更新

         a、成功完成一笔交易

         b、上下游订单数据库信息都进行更改（包括订单表、流水表及账务信息），改为处理中；

         c、更改上游配置文件里的数据库地址，然后curl下游的响应或回调；

         d、根据业务场景，决定是从上游手动重发交易触发补偿还是等待系统自动定时补偿，或者通过curl的方式触发补偿；

5、下游未落单

  方法一：

                a、完成一笔正常交易

                b、删除（没有删除权限就修改单号）下游订单、流水及记账信息

                c、更改上游订单状态及记账

                d、据业务场景，决定是从上游手动重发交易触发补偿还是等待系统自动定时补偿，或者通过curl的方式触发补偿。

  方法二：

                a、将下游系统的防火墙打开

 方法三：

                a、将下游系统调用时间改短一些，调用超时，即会落单失败；