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