前言
那么给你一个支付的二维码，如何写测试用例呢？
二维码扫码支付
如下图，给你这个个人收款的二维码，如何测试？
首先要知道什么是二维码？ 二维码实际上就是一个 url 地址，当手机扫码后，会根据二维码上的黑和白(黑色的色素块代表1，白色的色素块代表0)区域解析成 url 地址。
然后再分析下使用场景，这里实际上涉及到一个收款方，一个支付方。收款方生成二维码，支付方拿着手机去扫码。
知道使用场景了，接着拆分功能点，从字面上"二维码扫码支付"， 这7个字可以拆分成3个关键字：二维码，扫码，支付。
二维码场景用例
针对二维码写用例，可以分：
1.生成的二维码是不是能正确识别，支付方拿着手机能扫的出来。
2.二维码的准确性，扫码后的功能对不对（本来是收款码，要是生成付款码，那就不对了）。
3.二维码的尺寸，清晰度。
4.二维码是否会变（一般收款码不会变，付款码会定时刷新）。
扫码场景
扫码是支付方的使用场景了。
1.网络环境，无网络的时候，二维码还能不能扫。
2.扫码的时候，是能自己输入金额，还是固定的支付金额（个人收款是用户随便输入金额，生成的订单扫码是固定金额）。
3.如果是商户生成的固定的订单，用户是否可以串改金额？
4.如果是商户生成的固定的订单，用户支付后，能不能重复支付？
5.多用户同时扫码支付场景，固定订单，只能被支付一次。
支付场景
关于支付场景就复杂了，虽然上面的是二维码扫码支付，其实核心功能在于支付，上面的各种扫码姿势都是停留在表面的点点点。
支付金额场景：
1.支付的金额是否可以为空，为0，负数。
2.支付的金额最多几位小数，一般是2位小数，精确到分。
3.单笔最大金额。
4.单日最大金额。
支付方式：
1.支付方式：余额，余额宝，花呗，信用卡，银行卡。
2.支付顺序，默认的支付顺序是怎样的（或者自己设置的支付顺序）。
3.当第一个支付余额不足的时候，是否能默认用第二顺序的支付，依次类推。
4.不同的支付方式，会有单笔限制，比如不同银行卡会有不同额度。
支付密码：
当用户选择了支付方式，支付金额后，下一步就是输入交易密码。
1.密码支付，还是指纹支付，还是刷脸支付。
2.密码正确，交易成功。
3.密码错误，交易失败。
4.交易失败后，是否能重新支付。
5.用户取消支付。
6.用户不支付，放着让它过期超时。
支付状态：
支付之后，那么就会有支付状态。
1.支付失败，订单状态。
2.支付成功，订单状态。
3.用户取消支付，订单状态。
4.支付超时，订单状态。
对账：
1.支付方支付成功后，钱是不是变少了。
2.收款方收款后，是立即到账，还是延迟到账?
3.收款方如果没网，对方支付成功后，下次联网是否能看到收款记录。
4.当然支付宝还有语言播报：支付宝到账xx元。
退款：
支付方付款后，突然反悔了，那么此时就涉及到退款功能了。
1.退款是原路返回，还是怎样的？
2.立即到账，还是人工处理？
3.退款时候有没有扣手续费？
4.退款后，订单状态变更。
手续费：
说到手续费，如果对方是花呗，信用卡，那么就涉及手续费的问题。
1.对方花呗，信用卡付款，手续费扣比例对不对？
2.退款的时候，手续费会不会算你的？
红包和券
1.如果支付方有平台红包可以用，是否能抵扣平台红包，收款方不受红包影响。
2.还有券的使用，满减券，是否能叠加，还是固定商品使用券。
3.涉及退款的时候，这些红包和券是作废，还是原路返回。
安全与性能
安全和性能是最容易被忽略的，平常都是点点点的，拿着一个测试需求就想着怎么去点了，如果能回答安全和性能的方面是可以加分的。
支付安全性：
如果是一个固定金额的订单，比如100元订单，用户在扫码支付的时候，会从二维码中解析出支付金额。
此时如果我抓包后，篡改了金额，比如改成0.01元了，是否能支付成功呢？
一般这种订单接口都会有sign签名，防止用户篡改请求参数。
性能：
说到性能，必然会扯到高并发，多用户同时调用支付接口并发，会不会有什么问题呢？
这里的并发，不是多个人扫一个二维码，是整个系统比如支付宝用户有xx亿，在一分钟内有1000w用户在使用扫码支付，测试整个系统的性能。
类似于给你一个xxx, 如何测试？这种问题不能停留在表面上，要有全局观，把它当成一个小的项目去测试。
回答问题的思路从UI-功能-接口-业务-场景-安全-性能等方面回答。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
