探索篇 | 新奇测试策略剖析，大家都觉得多此一举(二)

      测试朋友们大家好，最近文章更新的有点慢，由于工作、生活比较忙、还有备战各种考试，所以基本没时间来给大家出文章，如果能出来1篇文章是很珍贵的，希望大家一定要认真看完并转发。

       最近全国各地疫情又严峻起来了，大家出门一定要做好自身防护。    

      今天周六了，前几天准备发的文章一直没发，忙完了今天就分享给大家，并和大家探讨具体问题，最近业务测试中遇到几个问题，和开发产生了分歧，我认为是问题需要处理的，开发认为无关重要，可不做处理或其它方。式避免掉。

案例一

需求：电商系统，管理后台发布打折或不打折商品，如果打折，商品详情显示打折标签、原价和特价；如果不打折，原价和特价一样，商品详情只显示特价，不显示打折标签和原价

BUG：

商品特价大于原价时，商品详情显示了折扣标签、原价和特价，且折扣标签是0折，应不显示折扣标签、原价，只显示特价即可。

处理方案：

修改管理后台创建商品时，特价不能大于原价，这样就不会出现这样的数据，就不会出现此种情况的问题了

想法和意见：

我认为这种处理方式是不合理的，虽然暂时避免了此问题的发生，但是并没有对本业务存在的问题进行处理，也就是说程序只满足了商品特价=<原价的条件、而并未满足商品特价>原价的情况，说明本业务还是存在问题的，可能很多人认为数据来源已经处理了，不会发生了，没必要再去纠结了。但是我认为很有必要去纠结，目前只有1个数据来源入口还好，如果有多个我要进行多个入口数据来源的测试，或者下个版本后续版本有新的入口数据加入，没办法保证下次再去测或其它测试人员知道这种情况测试掉，应该从源头处理问题，避免后顾之忧，如果小于等于、大于逻辑都处理了，那以后无论加多少个数据入口，我都不用管，我能保证我此逻辑肯定没问题的，我一直坚信我的观点，大家对于这种处理想法是如何的？可以公号或wx我探讨

案例二

需求：电商系统，由于微信支付渠道没有对接成功，临时只可支付宝渠道进行支付，故收银台页面不展示微信支付入口

处理方案：

后端新增字段值，区分展示和不展示微信、支付宝，前端根据后端的字段进行判断，如果wechat=0不展示微信入口，wechat=1时展示微信入口

想法和意见：

我认为这种处理方式也是不太合理的，因为前端进入收银台页才会调接口判断是否展示微信入口，那么前端需要考虑默认时展示还是不展示，如果后端给了非0、1时，展示还是不展示，如果我断网进入收银台页，是没有调接口成功的，这时是默认值展示，如果默认值是展示微信和支付宝，通过这种方式也是可以跳转微信去支付的。所以我认为后端无需区分0和1值，前端永远都展示微信和支付宝入口，当选微信支付时，后端进行判断给出提示即可

案例三

需求：电商系统，商品状态status=1-上架售卖中、2-下架、3-商品过期，商品详情展示及操作button都有统一的需求处理

想法和意见：

我认为非1、2、3的状态比如4需要进行容错处理并测试，如果某天后端接口给了status=4或0，商品详情可能展示出错或造成下单出现问题了或app崩溃，再如果下个版本增加了4状态，我们新版本测试都ok了，老版本并未对4进行处理，新版本后端上线后，app需要审核没有同步上线的，这时对应的app还是老版本的没有对4处理的逻辑，这时就可能会出错，但是前一个版本对4进行预处理，处理成什么逻辑呢？没法预知未来逻辑的，你们是怎么做的？可以vx或公号共同探讨！