一、功能测试点1、支付流程测试1、发起订单正常进行支付（支付成功）2、发起订单调取支付之后取消支付3、支付过程中断之后是否支持重新支付4、发起订单调取支付之后取消支付，之后取消订单5、发起订单之后多次点击支付是否会出现多次支付页面6、单笔订单支付7、合单支付2、支付结果验证1、支付成功之后扣款金额是否正确2、支付成功商品扣除库存是否正确3、支付成功之后支付结果跳转页面是否正确4、支付成功之后订单状态是否正确5、支付失败之后是否扣除库存 6、支付失败之后订单状态是否正确7、支付失败之后页面跳转是否正确3、支付金额测试1、支付金额与订单应付金额是否一致2、订单未负金额或0金额支付3、最小值支付（0.01）4、最大金额支付（应付金额超出银行卡/微信当天剩余可支付额度）5、支付时余额不足4、支付方式测试1、免密支付2、指纹支付3、密码支付（1、密码正确2、支付过程中输入密码错误可多次尝试支付超出3次密码错误支付失败）4、二维码支付（提供个人付款码）5、扫码支付（主动扫商户的收款码）5、容错性测试1、支付成功之后是否支持退款2、支付过程中断网3、支付金额不足时是否支持更换支付方式4、支付过程中刷新页面是否需要重新开始二、兼容性&安全&性能测试点1、是否支持在不同设备不同操作系统进行支付2、不同网络下支付是否正常，支付成功所需时间3、支付过程中输入密码是否可见4、支付完成之后是否有对应订单信息提醒

1.修改商品编号如果业务是通过商品编号来判断价格的话，可能存在只修改A商品编号为B商品编号，做到以A商品的价格购买B商品通常思路：先准备2个商品的编号，将其中一个改为另一个条件竞争通过条件竞争使余额达到负数，从而买多个商品通常思路：支付处，多线程请求付款确认，结果如果余额为负数，则存在该漏洞2.金额修改金额直接写在了post或者get请求中，对其进行修改达到修改了商品金额的效果通常思路：抓包修改金额的字段3.商品数量修改在购买时，如果一个商品为负数，那么它的价格则会是负数，如果购买多种商品，将其中一个设为负数，降低整体的价格通常思路：购物车里选取多个商品，修改其中一个商品的数量，在购买后查看最终的价格4.通过前端限制限购商品有些商品限购1个，但是判定是通过前端，因此可以抓包后修改数量通常思路：抓取限购数量内的包，抓取后修改个数，重放5.充值中放弃订单未失效在充值中选取大额充值订单，放弃订单，获得订单号，之后充值小额订单，拿到充值成功的界面，将订单号修改为放弃的大额订单，观察是否成功通常思路：看看充值的时候是否有订单号字段，如果有在成功界面修改为未支付的订单号，观察充值是否成功

首先要保证接口都能正常调用;生成一笔订单，支付完成后，同步或异步重复回调，只有一次有效;生成一笔订单，复制订单号和金额，再次生成一笔订单，用fiddler设置断点，用第一笔已完成的订单号和订单金额去替换现有的订单号和金额，无法完成支付;生成一笔订单，跳转到第三方时修改金额，无法到账，或者如果是游戏充值游戏币的话，到账为篡改后的金额对应的游戏币;异步通知屏蔽，同步有效，进行支付，同步能够正常到账;同步设置无效，异步有效，进行支付，异步能够正常到账;同步异步都设置无效，在第三方支付完成后，在重发机制时间范围内，设置异步有效，到下次通知时间点时，能够正常通知到账(补单机制的验证，如果商户收到第三方支付成功的通知后，要告知第三方支付收到了成功的通知，如果第三方支付收到商户应答不是ok或超时，第三方支付就会认为通知失败，会在规定的时间内持续调用notify_url，一般有时间或次数的限制);针对支付订单在数据库中存储是否完整和正确进行校验(比如：第三方订单号--方便与第三方对账和问题排查、订单金额、订单状态等);如果是用户购买实物商品，用户发起退货，要保证退货流程正常，资金能正常返还，要考虑下并发情况验证以确保安全性;如果是用户购买虚拟商品，比如话费、油卡之类的商品，只有在发货失败的时候才能发起退货，注意验证。