本篇文章主要从支付系统设计入手进行测试，针对界面功能测试容易忽略但是又十分重要的逻辑。关于支付密码、验证码、银行卡绑定等等能从界面入手测试的，下文也不讲述，如果有兴趣可以留言，后面整理。

　　1、APP支付结果查询是否合理

　　假设你测试的系统支持微信支付，在微信支付成功点击完成返回被测APP，这时候APP的订单状态需要更新，就会向服务器发起查询，如果因为网络问题没查到返回结果，APP需要展示给用户一个支付处理中的页面，请用户等待并再次发起查询，但是这个等待和查询不能是无期限的，需要有次数限制，如果最后还是没有查询到，需要提示用户稍后查询，如果查询到支付结果，则需要展示给用户对应的结果。

　　2、通知接口测试

　　如果是支付的时候微信系统因为某些问题不能及时把支付结果给到我们的系统，那么在微信在处理好支付订单的时候通常会给我们的系统发通知，告知这笔订单的状态，服务器拿到通知后更新数据库，客户端再发起查询的时候就可以拿到支付结果了，如果通知接口有问题，那就无法正常处理微信的支付通知。这个接口测试通常是RPC接口，可能需要开发帮忙模拟。

　　3、定时任务

　　除了靠微信调回调接口进行通知外，支付系统还需要设置定时任务去定时同步订单，商户系统需要有定时任务去查询支付系统，支付系统也需要有定时任务查询渠道系统，可以通过把数据库的订单状态由终态手动改为中间态，然后触发定时任务，看是否能同步到终态，如在数据库把支付完成的订单改成支付中，再去触发定时任务，查看是否能再同步为支付成功。

　　4、金额计算&取整

　　有些支付系统涉及到抽佣，一笔支付订单可能会付到不同的账户中，如果又涉及到部分退款的情形，金额的计算就会比较复杂，计算是先乘后除，还是先除后乘，保留是四舍五入保留，还是向上取证还是向下取整呢。假设有这样一个场景，用户向商家支付0.66元，系统用的单位是分，那就是66分，平台抽成33分，如果这时候用户申请退款80分，那这80分怎样从商家和平台出款呢？

　　如果是先除后乘，再四舍五入那就是：80/（33+66）≈0.8, 商家退：66*0.8=52.8≈53, 平台退 33*0.8=26.4≈26，那么问题来了，53+26=79，少退了一分，这里因为先除后乘，在除的时候损失了精度，再乘以一个数值，损失的精度就更大了。

　　如果是先乘后除，保留一样的小数点再四舍五入，就可以避免这个问题了。但是也要注意，先乘后除，会不会溢出呢？如果再采用向上取整或者向下取整，也会有问题，所以涉及到金额，除了考虑单位外，还要考虑合适的取整和计算方法，不然都会导致精度丢失。

　　5、订单超时处理

　　如果用户一直没有支付，商户系统和支付系统都需要及时将订单置为关闭的终态，否则定时任务仍然会去查询，浪费系统资源。

　　除了超时关闭外，定义的订单的各种状态都需要覆盖对应的场景去测试。

　　6、退款

　　如果订单未支付、支付中、支付失败、订单关闭、退款成功，则都不能退款成功，退款时需要查询订单的状态，校验退款的金额，不能支付50，但是申请退款100。

　　7、优惠券、红包超发

　　在出现大量并发请求时，优惠券和红包发放是否存在线程安全问题，可以通过写一个多线程并发请求脚本或性能测试工具来发起大量并发请求。

　　8、账户异常

　　支付账户被冻结、被风控、余额不足的情况，系统需要给出对应的返回。