给你一个扫码支付的二维码，如何写测试用例？

前言

面试的时候，经常会临场出题：给你一个xxx, 如何测试, 或者说如何写测试用例？xxx可以是圆珠笔，水杯，电梯等生活中常见的场景。

那么给你一个支付的二维码，如何写测试用例呢？

二维码扫码支付

如下图，给你这个个人收款的二维码，如何测试？

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

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！