我们最近的项目做的是一个电商的项目,主要包含了首页、购物车、订单管理、个人中心等模块,我们
客户可以通过我们的首页进行商品的选购并提交订单,此时我们系统会调用创建订单的接口,并创建
一笔待支付的订单,将订单的数据落在订单简水表中,然后客户端可以发起支付,进行支付控件的唤醒
和支付方式的选择,在完成本笔订单支付后,商家可以根据支付完成的状态,进行快递单号的录入,这
时候我们会调用三方物流的接口,对快递进行追踪,接下来就是订单完成阶段,订单完成有两个触发
条件,一个是客户主动确认收货,我们平台将订单修改为已完成的状态,另一个是客户没有点击,但是
物流信息显示已签收,经过7*24小时之后,我们平台会强制的将本笔订单修改为已完成的状态,就完成了
本笔交易。在以上的流程中,我们测试工作的开展主要是分为几个方向,第一个是关于功能性的校验,比如
在首页做了一些关于商品的选购的功能,商品的展示和排序规则的校验,以及商品的搜索和分类的功能
测试;在支付阶段做了一些支付控件的唤醒,支付渠道的唯一性选择,涉及到优惠券的情况,我们也会
对预付款金额的最优方案做了一些测试,在商品的确认收货阶段,功能方向主要做了确认收货的功能
处理,以及订单评价的录入等测试;此外还做了对应的接口测试,比如,创建订单的接口、订单查询的
接口、支付的接口,针对接口中的字段的必填、非必填、条件必填、依赖性型字段的入参类型以及长度
做了接口功能的测试,其次,对整个交易链路进行分析,多接口的上下游场景进行组合,比如支付接口
要依赖于订单创建的接口成功/失败/超时等场景,看下支付接口是否能完成支付,对调用下游系统的
成功/超时/失败的场景也要进行分析,针对每一种组合场景的落库情况要进行数据比对,主要关注状态的
流转,以及金额的逻辑对应关系。基本上我们之前的项目是做了以上几个方向的测试工作。
我最近的一个项目是做的,话机世界商城的一个项目。
项目背景是,随着电子商务的发展越来越好,年轻人对于网络购物的需求远远大于线下实体门店的需求,为了
紧跟时代的潮流,增加公司的收益。所以开设了电商平台的业务。
我是负责订单方面的的:
订单方面可以从订单的状态转换方面来考虑,从订单的生成,到待付款,到待收货,到
待评价,到订单完成,最后到售后/退款这几个状态来分析,还要结合后台的数据跟数据库
表的数据来进行验证。
订单的生成,首先从用户权限考虑,没登录的用户无法生成订单,只有登录的用户才可
以进行购买操作: 一个订单的生成也包括几个方面,比如入口的测试,地址的编辑,积分、
优惠券的使用规则,会员优惠,快递,支付方式的选择。
- 入口测试方面,可以从我们通过怎样的操作进入支付页面:
- 地址方面首先要区分之前有无地址,没有地址的情况下我们要先创建地址,有地址的时候我们可以选择其他的地址:
- 积分方面,我们要知道积分的兑换比例,以及积分的使用规则;
- 会员优惠方面要知道有多少种会员,每种会员的优惠力度是怎样的,我们要怎样达到更高的会员:
- 备注信息的话要测试备注输入框的合法性以及必须性:
- 支付方式我们要知道有哪些支付方式,是否可以组合支付,比如积分跟余额,优惠券跟余额,积分跟优惠券之类的组合是否可以使用,还有一个需要详细考虑的是优惠券方面的分析,从有无优惠券,到有哪些种类的优惠券,到每种优惠券的可用、不可用情况的分析,到不同种类的优惠券组合分析:比如满减优惠券,一个无优惠券, 这个不用过多考虑,没优惠券就是现实中没优惠券,但是有优惠券的时候我们要考虑优惠券的分类,像通用满减,品类满减,专属商品满减,比如通用满减券满100减20,我们要分析什么时候是能用的,比如单件商品价格满100,多件商品价格满100,商品价格超过100,我们还要分析什么时候是不可用的,比如已使用过的优惠券我们是不可用的,后台操作优惠券失效后我们也是不可用的,超过使用期限的优惠券也是不可用的,商品价格没达到100的也是不可用的,这个是通用满减优惠券的分析;品类优惠券的话我们不仅要考虑通用优惠券的所有情况,还要考虑商品是不是这个品类的,是的话才可以使用,不是这个品类的话品类辆减优惠券时不能使用的,专 属商品满减券情况类似,最后我们还要分析,如果我们有二种优惠券都有,-件商品价格满100,商品同时是品类商品,专属商品的情况,商品是品类商品,但不是专属商品的情况,商品不.是品类商品,但是是专属商品的情况,还要分析意见商品不是品类商品,不是专属商品的情况,那我只有两种优惠券的情况呢,我们也要一分析到; 无门槛券同理,之后,我们还要考虑满减券跟无广]槛券组合的情况,还有就是我有多张可用的优惠券,是否可以进行切换,我有可用的优惠券,但我不想使用是否可以选择不使用优惠券,还有默认优惠券方式是否正确,这样- -分析下来思路就清晰了,也可以很好的避免遗漏现象的发生。
最后我们还要进行一次 弱网测试跟重复支付测试,订单生成之后要在后台查看是否有这个订单的数据,还要到数据库表里面去查看是否有这个订单的信息生成,尽量做到100%全覆盖测试。待付款方面的话要考虑待付款的订单能保存多久,什么时候会失效,比如般未支付订单15分钟未支付就会失效,订单就会被取消,还有我们自已主动取消订单要进行哪些操作之类的,如果取消订单或者是付款成功,我们还需看看后台的订单是否也同步取消或增加,还要查看数据库表的数据是否增加或者是删除。
然后待发货状态,待收货状态, 已完成状态, 售后/退款状态都是比较简单的,比如说查看订单详情,查看物流,复制订单编号,联系客服,确认收货,删除订单,再次购买都是比较简单的检测点,其中要注意的是每个状态下的退款中,请跟评价以及每种购买情况退款后的返还情况,退款申请跟评价里面有输入柜的地方要测试它的合法性跟空值,照片上传要测试照片的数量上:限跟照片格式还有照片是否必须上传;然后就是退款后的返还情况分析,比如只用积分购买只返回积分,优惠券购买不返回优惠券,余额购买返还余额,组合购买之后.的退款返还情况:最后要记得前后端的数据检查对比,以及数据库表的检查对比,避免前端操作了,后端没有响应,发生重大bug。
- 项目中工作量最大的一部分
就是测试订单的部分,要考虑各种优惠券,打折,组合消费等情况
- 这部分里有意义的bug
2、在计算优惠金额时要注意页面的布局。
服务器默认勾选了最大的优惠券500元。最大的优惠券在第二页(在第一页没有显示)。现在想重新选择优惠券时,进入优惠券页面不进入滑动页面,直接选择优惠券100元。这时优惠券将金额累加起来了变成900。应该是100元。优惠券只能单个使用。(当时没有复现原因,我将默认勾选的优惠券滑到了第一页)。开发说布局只扫了第一页。
测试的测试方法:第一次进来的时候选最底下的一个(第二页),再回到提交订单页,再进入心上优惠页选择第一个,再返回到订单页看结果是否有累加现象。
标签:杭州,多测师,商品,接口,订单,优惠券,测试,支付,电商 From: https://www.cnblogs.com/xiaoshubass/p/16634976.html