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