你能说说“拼多多优惠券”怎么测试么?

本贴最后更新于 1185 天前,其中的信息可能已经时移世易

前言

最近几个月都处于找工作黄金期-金九银十,所以柠檬班的学员很多都收到了offer。从学员的反馈回来的面试中,我们发现除了像“测试工具”、“自动化测试”、“性能测试”等这些提升技能之外,必然要面试官考验到的一个技能就是“测试方法”和”测试思维“。

为了帮助大家的测试面试,今天我给大家整理一篇问到频率比较高的软件测试方法,就是经常被薅羊毛的优惠券要如何测试?

为什么企业面试喜欢问优惠券怎么测试呢?还不是因为这些曾经大家都熟知的优惠券事故么?

1、京东优惠券事故:2020年1月7日,京东优惠券设置错误,导致的大量产品以0元超低价格成交,并且发货,小家电被薅羊毛24万件,损失金额高达7000多万。

2、2018年12月17日,星巴克上线“星巴克APP注册新人礼”营销活动,遭受黑灰产羊毛党大规模攻击。他们利用大量手机号注册星巴克APP的虚假账号,并成功领取活动优惠券,导致星巴克的营销活动两天即停止。

3、2019年1月20日凌晨,大量用户可以免费领取拼多多“无门槛100元券”,可以用来充值话费Q币等,这个‘薅羊毛’事件,导致拼多多巨额资金损失。

所以这种京东、拼多多的优惠券如何测试,我们具体要怎么回答呢?我来给大家总结分析一下。

测试思维

测试任何事物的测试思路可以总结如下:

第一步:梳理产品的核心业务流程:明白这是个什么项目,实现了什么业务,以及是怎么实现的?

这个步骤一般是参考公司的需求文档来的,如果产品提供需求文档的同时提供了业务流程图,可以遵循流程图来梳理;如果产品没有提供流程图,就需要测试人员根据需求的理解自己画出流程图,达到梳理业务的目的。

第二步:根据流程进行模块细分,然后针对每个功能模块进行详细的测试点设计和提取。

这个单个功能的测试点提取要覆盖一下几个方面:

正常功能验证:优先覆盖正常的业务流程和功能验证,这其实也是单个功能的冒烟测试。冒烟测试先行,如果不通过,可以直接停止测试等开发修复后继续测试。
异常功能验证:为了更加贴近用户的使用产经,我们也要验证各种异常的场景,故意操作导致出错,检查系统的反馈和提示,保证用户操作失误的情况能够得到系统的友好指示。

因为有很多地方的操作都有可能会导致系统异常和抛错,所以为了不漏测,我们需要找出所有可能导致异常的输入项和选项。所以就到了第三步:

第三步:针对具体功能,寻找每个输入项和步骤,从以下三个角度来分析测试点 。
  1. 长度,数据类型,必填项,重复
  2. 需求的约束条件+隐形需求
  3. 功能之间的交互

这其中就需要用到一些用例的具体设计方法了,比如场景法,等价类法,边界值法,错误推测法等等

第四步:考虑非功能测试点,包括界面、易用性、兼容性、安全性、性能压力

优惠券功能的测试点

基于上面的测试思路,我们可以分析得出“优惠券的功能”测试点如下:

一、梳理抖音直播的业务流程如下:

图片.png

**冒烟测试:**后台添加正确优惠券,并审批通过,前端用户领取并成功抵扣付款。

然后我们再进行各个功能模块的具体细化。根据刚刚上面的业务流程分析,我们不难发现,抖音直播只要分为后端发布优惠券和前端使用优惠券两个部分,所以这两个部分我们要分别进行测试。

我们先看看后台发布优惠券的基本需求:

图片.png

基本信息

优惠券名称:必填项。限制15字 :1~15
优惠券副标题:非必填项。限制15字
优惠类型:必填项。主要有满减(满多少减多少)、立减、折扣券
发放数量:必填项。限制1000000份
使用说明:必填项。限制500字。

基本规则

用户类型:必填项。新用户、老用户、不同等级用户、不限
每人限领:必填项。默认1次。
有效期:a、固定日期:开始时间、结束时间 b、领取后,当天生效,有效天数:例如30天
跳转链接:必填项。优惠券页面

优惠券审批 : 一般财务审批后优惠券ID生成。

优惠券发布后的约束条件
后台管理

优惠券基本信息: 优惠券id、面值、使用期限、发放量
已领取数量、已使用数量更新:
过期优惠卷处理: 删除

用户使用场景

用户已领取已使用
用户已领取已过期
用户已使用订单取消/退款

所以,根据以上的需求我们先做一个基本的冒烟测试:后台添加正确优惠券,审批通过,前端用户领取并成功抵扣付款。

发布优惠券测试点

基本信息测试
优惠券名称(必填项,限制15字):

有效等价类:1,15

无效等价类:小于1(0),大于15(16),为空,负数

优惠券副标题

有效等价类:1,15

无效等价类:小于1(0),大于15(16),为空,负数

优惠券类型

满减(满多少减多少):例如满200减50,验证前端功能正常

立减:例如设置立减50的优惠券,验证前端功能正常

折扣券: 1-9折的折扣券,验证前端功能正常

为空: 验证必填项,前端有基本检查并报错信息友好

发放数量

有效等价类:1~1000000范围的数字输入

无效等价类:小于1(0),大于1000000(10000001),非数字(字母,汉字 字符...),0,负数,为空

使用说明

有效等价类:1-500(1,500)

无效等价类:0,超出500,为空

优惠券的基本规则

用户类型:

新用户类型优惠券:前端验证新用户可以使用抵扣,老用户不能使用抵扣;

老用户类型优惠券:前端验证老用户可以使用抵扣,老用户不能使用抵扣;

用户等级优惠券:前端验证不同等级用户对应使用场景,匹配的等级可以使用抵扣,否则不可以抵扣;

无限制优惠券:任何用户都可以使用并抵扣

商品类型限制

指定区域优惠券:验证对应用户使用场景,匹配的区域可以领取并使用,否则不可以使用;

商品品类优惠券:验证对应用户使用场景,匹配的商品类型可以领取并使用抵扣,否则不可以使用;

不限商品类型优惠券:验证对应用户使用场景,所有商品都可以使用该类型的优惠券。

每人限领优惠券

设置默认每人限制领取1张:前端验证不能多次重复领取,只能领取一次;

设置每人限制领取不限张数:前端验证可以多次领取并使用抵扣

限制张数不输入为空:有友好的提示信息。

优惠券有效期验证
选择固定日期过期:

有效等价类:开始日期<结束日期,并覆盖跨年,跨月等特殊时间,开始日期=结束日期

无效等价类:开始日期>结束日期,开始日期或者结束日期为空验证,提示报错

优惠券审批验证

财务审批通过:验证审批通过后,优惠券可以在前端使用

财务审批不通过: 优惠券无法在前端显示和使用

优惠券发布后验证

后台管理优惠券

优惠券基本信息查看:优惠券id、面值、使用期限、发放量

优惠券已领取已使用数量更新:

用户领取后,已领取的数量更新

用户领取后,已使用的数量更新

用户优惠券过期

支持删除,显示状态正确;删除之后,确认能否重复领取

用户使用场景验证
用户已领取已使用:
  1. 可以按照优惠券的规则进行抵扣
  2. 验证是否可以叠加使用
  3. 验证是否可以重复使用
用户已领取已过期

过期状态失效,状态变灰;

即将过期的优惠券是否有提醒

用户已使用取消订单/退款/支付失败

取消支付:优惠券返回账户

退款:优惠券返还或者作废, 然后退还的支付金额为实际支付金额

支付失败:优惠券返回账户

1 操作
tricy 在 2021-09-23 15:03:47 更新了该帖
回帖
请输入回帖内容 ...