关于支付类的一些测试关注点及异常点

　　作了四年多的银行支付系统测试，对支付模式类型略知一二。对于市场上的支付系统，其实原理大同小异。市场上大多数软件系统涉及到支付功能，都会与第三方支付系统交互，跳转到相应的支付系统实现其支付功能，下面说下开展这类型测试以前，须要考虑哪些因素：

　　1，了解第三方支付接口有哪些，系统直接交互如何实现，建议画流程图（题外推荐：流程图可使用chrome插件：Gliffy，我的感受比较好用。），重复熟悉系统实现流程，只有搞清楚流程，才能更好的评估其中的风险，才能有利于测试用例的设计；

　　2，除了主要功能以外，还须要考虑异常场景有哪些；

　　3，有哪些风险？如何规避？

针对测试过程当中涉及到主要的测试点整理以下：

　　 测试过程当中须要注意的主要测试点及异常场景：

　　· 首先要保证接口都能正常调用；

　　· 生成一笔订单，支付完成后，同步或异步重复回调，只有一次有效；

　　· 生成一笔订单，复制订单号和金额，再次生成一笔订单，用fiddler设置断点，用第一笔已完成的订单号和订单金额去替换现有的订单号和金额，没法完成支付；

　　· 生成一笔订单，跳转到第三方时修改金额，没法到帐，或者若是是游戏充值游戏币的话，到帐为篡改后的金额对应的游戏币；

　　· 异步通知屏蔽，同步有效，进行支付，同步可以正常到帐；

　　· 同步设置无效，异步有效，进行支付，异步可以正常到帐；

　　· 同步异步都设置无效，在第三方支付完成后，在重发机制时间范围内，设置异步有效，到下次通知时间点时，可以正常通知到帐（补单机制的验证，若是商户收到第三方支付成功的通知后，要告知第三方支付收到了成功的通知，若是第三方支付收到商户应答不是ok或超时，第三方支付就会认为通知失败，会在规定的时间内持续调用notify_url，通常有时间或次数的限制）；

　　· 针对支付订单在 数据库中存储是否完整和正确进行校验（好比：第三方订单号--方便与第三方对帐和问题排查、订单金额、订单状态等）；

　　· 若是是用户购买实物商品，用户发起退货，要保证退货流程正常，资金能正常返还，要考虑下并发状况的验证以确保安全性；

　　· 若是是用户购买虚拟商品，好比话费、油卡之类的商品，只有在发货失败的时候才能发起退货，注意验证；

　 　遇到过的坑：

　　· 用户购买100元游戏币时，前往第三方支付跳转进行金额的篡改由100元改为0.01元，结果就拿了0.01元充值了100元的游戏币。对订单金额没有作校验致使这样的后果，损失比较大。你们在测试的过程当中必定要注意对服务端进行校验，支付时数据的篡改必定要有校验。

　　· 当同步、异步通知都存在的状况的，异步通知（第三方支付成功后台通知），没有到帐，致使部分用户充值不到帐，引发客诉。当同步、异步并存的时候，必定要分别对同步和异步进行检验，确保都能正常到帐。

　　咱们所作的绝大多少的 互联网产品都会涉及到第三方支付，因此支付功能必然是重要的，做为测试互联网产品的一员，咱们必需要作好支付的安全性。

　　 那么，如何规避支付风险？

　　为了进一步的增强支付功能的安全，也能够适当的增长一些监控机制，好比：订单与第三方订单进行对比，可使用跑批完成，当咱们完成支付的订单从数据库中查出来与经过第三方订单查询接口查询出来的同一个订单金额有异常时，进行报警通知可以及时发现处理，甚至当有异常状况进行建立订单的终止，从而把损失降到最低。