提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档
目录
博主是一枚新进测试的小菜鸟,如有遗漏点,请指出,谢谢大佬了(*^_^*)
前言
这篇文章是为了督促自我进步和学习测试思维的一篇文章
文章出处:转载自:守护往昔 - 博客园
目的:对自我的升级,加深自我的知识和思路。
这篇文章会诞生的原因:每个人的成就和知识,都不是与生俱来的,人都是可以通过后天的学习来不断的对自我进行一个升级。JOJO:人类是有极限的,所以我不做人(*^_^*)。
咳咳,开个玩笑话,回归正题。俗话说:活到老,学到老。虽然大家都是人,但人与人之间也并不相同。
拿学习一个新东西来举例:
人家:哦,不愧是你啊,陆老师!学到了,赶快记下来。
我:哦,有点东西啊,陆老师!学到了,进收藏夹(吃灰)。
时间一长,就可以看出人家在进步,我在原地踏步。为了改变这个现象,因此我也准备写下来,毕竟,好记性不如烂笔头嘛
一、测试点的分析基本原则(通用)
第一步:先了解产品的基本业务流程(逻辑):是什么项目,做什么的,怎么工作的?
- 画出流程图,进行业务逻辑梳理
第二步:细分模块,针对每个小功能模块进行详细的划分:
- 正常:覆盖正常核心的业务流程--优先测试?--带个功能冒烟测试
- 异常:各种异常?--贴近用户的使用场景,确保产品的正确处理,提示友好!
- 注意:确保不会遗漏,列出输入项异常
第三步:针对具体功能,寻找每个输入项,从以下角度来进行具体分析测试点
- 长度,数据类型(特殊字符),必填项(null),重复
- 需求的约束条件+隐形需求
- 结合业务流程的步骤
- 功能交互——交叉
第四步:考虑非功能测试点:
- 界面、易用性、兼容性、安全性、性能压力
以京东为例:核心业务流程
购物车的流程分析:
京东购物车入口:
购物车界面:
未登录进入购物车:
购物车为空:
购物车的功能点:
1、入口测试:我的购物车,去购物车结算
2、用户类型:登录的用户,未登录的用户
3、商品清单:
- 按店铺展示商品清单,包括图片、名称、单价、数量、小计等;
- 显示店铺合计金额、商品总结金额
- 购买数量可进行增减-- 等价类、边界值
- 商品支持删除、移到关
4、选择商品
- "全选"
- 单个勾选、部分选;
- 删除选中商品,移入关注,清理购物车
5、去结算
- 点击“去结算”
- 跳转至订单确认界面--交互验证
6、空页面处理
- 当购物车商品为空时, 可选择“去购物”
购物车如何测试:功能点
以上内容为转载,出自:守护往昔 - 博客园
第一步界面测试
- 打开页面后,通过直观的观察页面的布局是否合理,显示是否完整;
- 不同卖家的商品在不同的table区域显示,区分明显;
- 商品的最下面显示失效的商品;
- 页面的功能按钮可以正常显示;
- 页面的最低端显示“你可能喜欢”;
- 向下滑动页面,在购物车顶端展示“购物车”;
- 购物车中如果存在有商品降价、库存不足、限购件数等,在商品详情的下面,会有对应的字体展示;
第二步功能测试:
1、若未登录,点击购物车,则提示用户输入用户名和密码,或者提示其他的非注册用户购物方式;
2、所有页面链接功能正常,可以点击到正确页面;
3、从商品信息页面添加的商品能显示在购物车中;
4、购物车页面刷新后,新的商品能显示;新加入购物车商品排序(添加购物车中存在店铺的商品和购物车中不存在店铺的商品);
5、商品未勾选的状态下,结算按钮是灰色无法点击的;·勾选商品,点击结算按钮后,进入确认订单信息页面;勾选商品后,已选商品的总价会显示,结算按钮变高亮可点击工作价格总计是否正确;
6、购物车页面中,可以对添加的商品信息做信息的修改,并自动保存成功;
7、购物车商品总数是否有限制;
8、商品总数是否正确;全选功能是否好用;
9、商品文字太长时是否显示完整;店铺名字太长时是否显示完整;
10、不要的商品,可以删除;商品删除后商品总数是否减少;
11、购物车有商品降价或者库存告急的,那么点击对应的tab,降价或者告急商品会归类后显示;购物车中下架的商品是否有特殊标识;
第三步性能测试:
1、打开购物车页面要多久;
2、结算时间需要多久;
3、增加删除商品响应时间;
第四步兼容测试:
1、不同浏览器上的测试功能是否正常;
2、相同浏览器的不同版本测试功能是否正常;
第五步易用性测试:
1、删除功能是否有提示;是否有回到顶部的功能;
2、商品过多时结算按钮是否可以浮动显;
总结
首先,你需要明白购物车的作用,他在系统设计中主要是用于用户临时存放有意向购买的商品,因此在设计中,除了界面美观,好用之外,还要引导用户去进行付款操作。因此该模块还会和多数模块如:用户,商品,订单,支付等模块有复杂的关联,所以购物车模块的测试除了要保障基本的功能的实现,还需要进行考虑和其他模块之间的业务的关联及影响。最后还要考虑整体的兼容性及性能等等方面。