测试基础优惠券测试用例编写

测试新人 · 2024年01月24日 · 最后由测试新人回复于 2024年01月24日 · 2979 次阅读

前言

常规练下测试的核心技能：测试用例编写

看社区近几年几乎没有人讲测试用例编写，尝试说下写用例的过程，不一定对，大家可以参考下，当乐子看

都知道边界值、等价类划分、错误推断、场景图是写用例的好方法
但实际工作中的难点是找出有效测试点来套这些测试方法

测试用例编写难点：

复杂的业务涉及多个组件或者模块，需要梳理出流程并编写全面有效的用例
分析业务流程，从中找出隐藏业务逻辑缺陷
熟悉开发业务实现逻辑（如异步操作、外部依赖等），编写有效测试场景找出代码处理缺陷
需要站在用户的角度，尽量覆盖用户的操作，减少客诉
需要应对代码中的不确定性和变动性，同步维护用例

场景：电商优惠券需求

没有详细的产品需求，就假设是从 0 到 1 的场景，发散性看能想到多少。实际测试工作中，也很少有产品能把文档写得面面俱到的，因此测试如果具备相关的业务产品知识，就可以在需求评审中给到合乎实际场景的意见。

用例编写思路：

第一步：了解项目的背景和目的

每接到一个需求，去了解背景和目的主要是起到三个作用：
1> 可以尽量避免将时间和人力浪费在跟当前项目核心利益无关的需求上
2> 部分旧功能可以满足核心利益的，可以直接拿来修改复用，节约时间成本
3> 针对目的和背景，可以发现需求文档未提及，但是实际场景中需要的需求

背景和目的的关系：因 XXXX 的情况/背景，所以需要做 XXXX 的需求
优惠券的作用是什么？：引流、拉客单、促活、拉复购、降低节假日对日销的影响、活动范围限制
优惠券绑定的活动类型有哪些？：特价/折扣/满减/满赠/新用户/回流用户/限时/连续签到等等
在产品提出优惠券需求时，测试这边就要知道当前这期的目的是什么？
第一期的目的如果是为了【复购】，那发券的主要场景在用户购买完后进行赠券。
如果是【引流】，那就得细问下是内部引流还是外部引流，具体对应的活动方式，内部引流需要对用户进行新老用户区分，通常对新用户的优惠力度比较大，因此次数限制机制和领取渠道场景需要着重注意等。
如果是【促活】，那用户画像还得进行进一步的细分，细分就要询问产品是根据购买时间间隔还是根据消费频次还是根据消费力度等。
产品要是没概念，想要一次实现优惠券的全部赋能，那测试这边就可以评估工作量和时间，然后及时阻止。
接着需要知道产品此次的目的是基于什么背景，如果是因为上期做了全品类自动发放的优惠券，但是用户使用率不高，所以想增加个用户消费频次类型的再细分。但是用户使用率不高可能是活动力度不够或者是消息提醒不足等其他愿意造成，再细分用户可能意义不大，那就可以先把这个需求搁置，让 app 多几个 push 或者短信内容提醒或者加大券的额度来看下。又假如说产品为了提高客单量，决定大量发放无门槛全品类券，那就要问下产品接不接受可能出现的大量 0 元购订单

当然实际情况中产品会出现回答不出、概念模糊、或者核心目的就是为了 PPT 数据报告好看、又或者测试是最后一个知道需求的，我们有这个概念，现实中再随机应变了。

第二步：画出事件流程提取测试点

1. 总流程：

优惠券的生命周期是怎样的？
- 创建->投放->领取->使用
优惠券的发收是谁？
- 零售商 --券--> 用户
从测试的角度看，架构怎样的：
- 运营位和活动渠道就是后面需要验证的场景
- 有风控接入：需要注意被风控的人的交互实现

大致流程怎样？：

从中提取信息：
- 主要需要测试【优惠券创建】【运营活动】两个配置系统和【优惠券领取、使用、支付】的功能逻辑验证
- 优惠券存在审核阶段，需要提前申请好测试物料，防止测试阻塞
- 优惠券和支付都属于真金白银，测试过程中需要做好记录，方便后面报销和报备
- 提前联系好风控组的同学加白名单，防止验证优惠券异常场景阶段被系统拉黑
- 测试场景中需要覆盖不同的渠道和运营位

2. 优惠券创建：

从现网中的优惠券了解优惠券有哪些参数的组成

画出创建流程

运营人员特点提取优化点：

优惠券管理测试点：

优惠券配置系统测试点🠓：
- 测试用例完善方向
  - 填写框的类型限制、文本长度、打折类型的填写规范等
  - 表单字段名是否正确
  - 表单里有包含嵌套的配置信息的，生成的数据层级是否正确、是否一致
  - 表单非必填项未填写，生成的数据是否正确
  - 单选和多选的逻辑一定要确定清楚，如优惠券的分类的选项，是否可以多个选择等