首先要知道什么是二维码？ 二维码实际上就是一个 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-功能-接口-业务-场景-安全-性能等方面回答。