前两天我公布了一个京东微信端截取到的三张图。并简单阐述了这三张图中的bug发现过程:前端
有朋友的评价是图中这种,可实际上。他应该是没有看出来这个bug表明的内容有多少。今天心血来潮决定具体写一下。展示一下老程序猿的酸腐气质!swift
京东微信端可以签到获取金币,天天一次一个金币,结果没有不论什么提醒,签到积累30金币的时候就不能签到了,我一直不知道怎么回事。微信
这一天决定兑换一下这种100-10的券。因为提示是早上9点開始,此前9点多点击。都没有抢到,我仅仅是认为奇怪。google
今天我仍然在9点多进行了点击兑换,系统提演示样例如如下图所看到的:orm
系统告诉我兑换优惠券需要花费10金币,我点击立刻兑换。游戏
结果系统显示说,手速太慢。券已经被抢光了哦!开发
明天记得早点来抢哦!同步
可是我明明记得抢光了应该是灰色的。而这时候是红色的。form
注意。不是上面已领取得券。而是金币30下方的券。class
10点多。意外过来看了一眼,点了一下,居然兑换成功了,我连点了两次,结果扣了我20金币,系统告知仅仅能抢一张,我没有太注意,也忘记截图了。
下午最终看到系统表示券已经被抢完了。截了张图例如如下。
这里才是抢光的结果。这时候,我看了一眼100-10的券。确实仅仅有一张。晚上又看了一次,发现变成两张了,具体这里就先不分析这个问题了。因为要分析,我需要积累超过20金币之后才干进行这项測试。
如下咱们来分析一下为何会发生上面的状况,或者说。什么状况下会发生上面的状况。
如下逐项进行相关bug的分析描写叙述。
实际可以兑换的时间是10点,而界面提示是9点。
从这个现象可以看到例如如下问题:
1, 京东的測试团队是分离的
业务逻辑測试团队和界面測试团队应该不是同一我的或者同一组人。
这在互联网软件測试中是有问题的。固然也可能就是同一我的,这我的太过于粗心了。只是,从常理来看通常不至于犯这种错误。
2。 代码层面上界面推送和逻辑推断没有同步
这个问题很是严重,常规来讲应该有两种实现方式:
一种是懂一些技术的业务人员进行后台设定和前台页面改动,固然,最大的多是一開始就考虑是9点。结果一个需求变动认为是10点,而开发者忘记对页面进行改动。測试因为是两批人在作。也没有完毕同步。
或者说,京东研发測试团队的需求跟踪作得不到位,需求变动发生后没有对所有涉及到该需求的点进行全面检视。
还有一种是经过后台逻辑代码进行业务实现的设定和界面设定。
这种方式应该是最好的方式。也最easy避免这类问题。但,很是明显京东没有这样作,多是人力不足。也多是仓促上线。可是上线已经半年的系统仍是这样。就有点奇怪了。
Btw:我仅仅能说京东的开发团队问题实在不是通常得多,你们可能会说,我靠打击京东来宣传本身,抱歉。假设这样说,我四年前给几个大学作的演讲中对腾讯的批评不少其它,当中涉及到腾讯游戏内部的很是多管理问题和开发问题的推演分析结果,这些结果都是获得了腾讯游戏集团级专家人员的认可。
明显应该是灰色的时候才应该提示:手速太慢,券已经被抢光了哦!明天记得早点来抢哦!
却在早上9点尚未開始抢的时候作出了这种提示。
这里能看出来,京东研发中的任意性,提示是默认设定的,而不是与逻辑关联的。
或者说,提示仅仅是前端的推送和后台业务全然无关。
这种设定会使得推送的结果因为前端程序猿的偷懒或者疏忽等问题而形成没必要要的麻烦。甚至可能应该是每一个页面单独写提示。而不是系统进行的统一提示告警处理模块完毕的。
对于成熟的系统。所有的异常和提示信息应该是同一模块统一完毕的。要依据不一样的逻辑展示不一样的提示结果,不至于让用户认为很是奇怪。
固然,这里很是有多是为了下降先后台的交互而刻意作的提示结果,也就是我前面提到的。前端程序猿疏忽或者偷懒就进行了默认设定。结果測试人员ye没有測出来或者不负责任就直接经过上线执行了。
金币最多30枚。超过就不能领用。一个简单的提示都没有作,更可以看到京东系统的薄弱和问题所在。
这种系统逻辑错误放在十多年前咱们研发的电信行业业务系统中都是不可容忍的,京东的实际业务处理水平确实是至关得有问题。
仍是3.2问题的一个延续。
9点多点击,提示:兑换优惠券需花费10金币。说明这个业务逻辑没有走后台推断。
而被拒绝后,前台没有获取业务逻辑推断的提醒代码或者说没有代码。仅仅是给了一个拒绝信息,因而仅仅能提示用户:手速太慢。券已经被抢光了哦!明天记得早点来抢哦!
这说明后台逻辑的推送要么没有异常处理,要么就是先后台分离开发后,前台对后台的异常处理作了简单化地响应处理。
这在业务逻辑上是不可能被容忍的。而这种错误居然都检查不出来,京东的測试团队的能力不是通常得弱小。