6月23日功能测试Day7

5.6抢购功能测试 

 5.6.1后台需求分析 

 抢购管理列表 

开关位置：后台--页面--页面管理--PC端导航栏

功能位置：后台--营销--常用促销--抢购管理

后台抢购列表管理可以添加抢购活动，编辑抢购活动，删除抢购活动

 规则： 

1.参加抢购的商品必须指明某个具体规格，比如商品的不同颜色

2.抢购活动添加成功后，不允许修改限购数量

3.抢购活动进行中，已有用户下单购买后，不再允许编辑抢购活动信息

抢购活动添加成功后，抢购活动有多种状态：已过期、未开始、进行中、已售空、已结束

 规则： 

1.当前时间达到活动的开始时间，则活动状态由“未开始”变为“进行中”

2.活动的开始时间早于当前时间，结束时间晚于当前时间，则新建的活动状态为“进行中”

3.参加抢购活动的商品售完后，活动的状态变为“已售空”

4.当前时间达到活动的结束时间，则活动的状态由“进行中”变为“已结束“

5.抢购活动的结束时间早于当前时间时，则新建的活动状态为”已过期“

 注意： 

添加后台抢购时候，功能需求为：新增抢购功能

分为三部分：界面类、编辑规则、抢购活动多种状态

界面类、已售空、已结束单独写，其余按照用例描述

 面试题1：当你发现研发实现的结果与需求不一致时怎么办？ 

需求评审的时候，需要确认所有输入类型的校验是 针对单独的输入框 做的还是在 最终提交时 校验。

例如：抢购模块 需求跟实现的内容不一致（跟产品和研发一起确认，研发为什么要做出一个跟需求不匹配的东西，如果说依旧按照需求实现，那提bug给研发进行修改；如果保留现状，产品更改需求）

 面试题2：如果开发不认bug怎么办？ 

1.确认拒绝的理由

2.如果是bug描述不清晰，那我们自己调整；如果是需求理解不一致的问题，参考需求文档

3.如果测试 研发对需求的理解都不一致，并且需求文档没明说，需要找产品经理介入

注意事项：所有线下讨论的结果，都要记录文案。

 5.6.2前台需求分析 

规则：

1.抢购商品加入购物测时，要求会员必须先登录账号

2.会员抢购商品时候，数量不能超过抢购活动要求的单用户限购数量，超出时页面给出提示

3.会员抢购商品时，数量不能超过商品参加抢购活动的库存余量，超出时页面给出提示

4.商品加入购物车时，抢购库存数量不会减少，直到生成订单后，抢购的库存数量才会减少

5.生成订单后，取消订单，订单中的商品数量恢复到抢购的库存中

6.抢购活动结束后，商品的价格恢复原价，库存数量恢复为原价的库存数量（原有库存—销售数量）

问题点：

什么时候要写前提条件：如果没有，那我的执行结果会出现问题吗？

优先级怎么写：如果没有他，会影响用户使用吗？

 5.7添加会员购物用例 

总结来说：

有效用例：多种情况组合

无效用例：一个无效，其余都为有效

今日内容不多，学测试太枯燥了！！

明天开始抓包工具与Http网络学习 

3天内结束功能测试