面试官问“你能说说支付功能怎么测试吗?”该怎么回答

跳槽高峰期 , 作为测试 , 不管是面试还是笔试 , 必然要被考验到的就是”测试思维“ 。在面试中就是体现在如下面试题中:
“说说你项目中的 xx 模块你是如何测试的?”
“给你一个购物车 , 你要怎么测试?”
"你说一下这个产品的登录功能有哪些测试点?"
“支付功能怎么测试?”
......
所有的这些问题其实都是在考察你的测试思维 。我们再回答这类问题的时候有方法可依循的 。
今天这篇文章 , 我就很多同学都觉得难的一个问题“支付功能”作为案例 , 一起来分析一下如何回答这类的面试题 。
测试思维
要分析测试点之前 , 我们先来梳理一下测试思维 。总结来说 , 任何事物的测试思路都可以总结如下:
第一步:梳理产品的核心业务流程:明白这是个什么项目 , 实现了什么业务 , 以及是怎么实现的?
这个步骤一般是参考公司的需求文档来的 , 如果产品提供需求文档的同时提供了业务流程图 , 可以遵循流程图来梳理;如果产品没有提供流程图 , 就需要测试人员根据需求的理解自己画出流程图 , 达到梳理业务的目的 。
第二步:根据流程进行模块细分 , 然后针对每个功能模块进行详细的测试点设计和提取 。
这个单个功能的测试点提取要覆盖一下几个方面:
正常功能验证:优先覆盖正常的业务流程和功能验证 , 这其实也是单个功能的冒烟测试 。冒烟测试先行 , 如果不通过 , 可以直接停止测试等开发修复后继续测试 。
异常功能验证:为了更加贴近用户的使用产经 , 我们也要验证各种异常的场景 , 故意操作导致出错 , 检查系统的反馈和提示 , 保证用户操作失误的情况能够得到系统的友好指示 。
因为有很多地方的操作都有可能会导致系统异常和抛错 , 所以为了不漏测 , 我们需要找出所有可能导致异常的输入项和选项 。所以就到了第三步:
第三步:针对具体功能 , 寻找每个输入项和步骤 , 从以下三个角度来分析测试点。

  1. 长度 , 数据类型 , 必填项 , 重复
  2. 需求的约束条件 + 隐形需求
  3. 功能之间的交互
这其中就需要用到一些用例的具体设计方法了 , 比如场景法 , 等价类法 , 边界值法 , 错误推测法等等
第四步:考虑非功能测试点 , 包括界面、易用性、兼容性、安全性、性能压力
支付功能的测试点
基于上面的测试思路 , 我们可以分析得出“支付功能”测试点如下:
一、梳理支付的业务流程如下:
点击支付---> 选择支付方式 ---> 确认金额---> 输入密码 ---> 成功支付
完成这个流程测试 , 也就是完成了项目的冒烟测试!然后需要测试针对流程中的每个阶段和步骤 , 具体分析可能导致异常的测试点 , 所以我们按阶段和输入项来进行划分如下:
1)点击支付 , 提交订单但是取消了 , 检查可以取消成功
2)选择支付方式:
正常:可以支持的支付方式有:信用卡 , 储蓄卡 , 网银支付 , 余额 , 第三方支付(微信 , 支付宝 , 京东、百度、聚合支付、组合支付) , 找人代付 , 验证是否支持并且可以正常选择并支付;
异常: 没有绑定任何的支付方式时 , 支付报错 。
**功能交互:**支付时结合优惠券/折扣券/促销价抵扣进行相关的抵扣 , 验证规则正确 , 并且可以正常抵扣和支付 。
3)确认支付金额:这个步骤可以用到等价类和边界值的用例设计方法
正常:正常金额里用边界值法去测试点:
最大支付金额(单日最大 , 单笔最大 , 余额最大)
最小支付金额
异常:同样也用边界值方法提取测试点:
超过支付方式单日最大消费金额/单笔最大/余额最大
异常金额支付:非数字、负数、0 , 小数点超过 2 位等
4)支付密码:
正常:可以支持的支付密码类型有:指纹 , 人脸识别 , 账号密码 , 动态获取验证码 , 手势 , 信用卡和支付码 , 小额免密等 , 确认自己的产品所支持的密码类型 , 确认可以验证并支付成功;


推荐阅读