做了四年多的银行支付系统测试，对支付模式类型略知一二。对于市场上的支付系统，其实原理大同小异。市场上大多数软件系统涉及到支付功能，都会与第三方支付系统交互，跳转到相应的支付系统实现其支付功能，下面说下开展这类型测试之前，需要考虑哪些因素：
　　1，了解第三方支付接口有哪些，系统直接交互如何实现，建议画流程图（题外推荐：流程图可以使用 chrome 插件：Gliffy，个人感觉比较好用。），重复熟悉系统实现流程，只有搞清楚流程，才能更好的评估其中的风险，才能有利于测试用例的设计；
　　2，除了主要功能之外，还需要考虑异常场景有哪些；
　　3，有哪些风险？如何规避？
针对测试过程中涉及到主要的测试点整理如下：
　　测试过程中需要注意的主要测试点及异常场景：
　　· 首先要保证接口都能正常调用；
　　· 生成一笔订单，支付完成后，同步或异步重复回调，只有一次有效；
　　· 生成一笔订单，复制订单号和金额，再次生成一笔订单，用 fiddler 设置断点，用第一笔已完成的订单号和订单金额去替换现有的订单号和金额，无法完成支付；
　　· 生成一笔订单，跳转到第三方时修改金额，无法到账，或者如果是游戏充值游戏币的话，到账为篡改后的金额对应的游戏币；
　　· 异步通知屏蔽，同步有效，进行支付，同步能够正常到账；
　　· 同步设置无效，异步有效，进行支付，异步能够正常到账；
　　· 同步异步都设置无效，在第三方支付完成后，在重发机制时间范围内，设置异步有效，到下次通知时间点时，能够正常通知到账（补单机制的验证，如果商户收到第三方支付成功的通知后，要告知第三方支付收到了成功的通知，如果第三方支付收到商户应答不是 ok 或超时，第三方支付就会认为通知失败，会在规定的时间内持续调用 notify_url，一般有时间或次数的限制）；
　　· 针对支付订单在 [url=] 数据库 [/url] 中存储是否完整和正确进行校验（比如：第三方订单号 -- 方便与第三方对账和问题排查、订单金额、订单状态等）；
　　· 如果是用户购买实物商品，用户发起退货，要保证退货流程正常，资金能正常返还，要考虑下并发情况的验证以确保安全性；
　　· 如果是用户购买虚拟商品，比如话费、油卡之类的商品，只有在发货失败的时候才能发起退货，注意验证；
　　遇到过的坑：
　　· 用户购买 100 元游戏币时，前往第三方支付跳转进行金额的篡改由 100 元改成 0.01 元，结果就拿了 0.01 元充值了 100 元的游戏币。对订单金额没有做校验导致这样的后果，损失比较大。大家在测试的过程中一定要注意对服务端进行校验，支付时数据的篡改一定要有校验。
　　· 当同步、异步通知都存在的情况的，异步通知（第三方支付成功后台通知），没有到账，导致部分用户充值不到账，引起客诉。当同步、异步并存的时候，一定要分别对同步和异步进行检验，确保都能正常到账。
　　我们所做的绝大多少的 [url=] 互联网 [/url] 产品都会涉及到第三方支付，所以支付功能必然是重要的，作为测试互联网产品的一员，我们必须要做好支付的安全性。
　　那么，如何规避支付风险？
　　为了进一步的加强支付功能的安全，也可以适当的增加一些监控机制，比如：订单与第三方订单进行对比，可以使用跑批完成，当我们完成支付的订单从数据库中查出来与通过第三方订单查询接口查询出来的同一个订单金额有异常时，进行报警通知能够及时发现处理，甚至当有异常情况进行创建订单的终止，从而把损失降到最低。