代码改变世界

【记录】让人淡疼的BUG之参数传送错误

2013-08-05 13:35  Tester Chen  阅读(188)  评论(0编辑  收藏

前言

面试的时候往往容易被面试官问到:“说说你遇到过的比较重大或经典的Bug有哪些,能说一说吗?”
我被问时脑海的反应是:“尼玛,这个我从来没有刻意记!一时半会咋想得起来,然后还是没想起来或者是随意给了一个并不符合期望的回复”,各种不靠谱。
最近在测试过程中默默然发现一个一直存在、但一直未被人发现的Bug,把它记录起来吧!

背景

我们有金卡服务,针对VIP付费用户。
开通金卡服务后,经理人的简历在被猎头或企业搜索到时,经理人页面会统计“简历被搜索到:*次”,搜索到时次数会+1,统计的数据依据由前端发给后端。

发现

在某次上线测试过程中发现,猎头或企业搜索到我的简历后,我的被搜索到次数并没有增加。
同时,通过查询数据发现:最近5天以内开通金卡的经理人,他们的简历居然没有被任何猎头和企业搜索到,但开通6天以上的经理人有零星的被人搜索到。
到这里,仍然无法解释造成这种现象的原因是什么,最后,通过检查代码发现,发现……

原因

发现,前端向平台发送的数据是错误的。
平台在有一次上线中,将统计简历搜索次数的参数由“简历ID”变成了“用户ID”,而猎头或企业搜索到相关简历时,前端向平台发送的数据仍然是“简历ID”而不是“用户ID”。
这样做通过代码检查是无法看出错误的,因为用户ID和简历ID都是由一串数字组成且长度都同一区间内,所以程序处理十分正常。
同时由于两者有许多重叠的ID,就出现了我们看到的开通6天以上的经理人会零星有被猎头或企业搜索到。

总结

这个问题之所以存在并长时间未被发现,有以下几个问题:
# 底层平台改动后,对于其影响的区域未能准确定位、修改、测试,导致部分数据处理不正确
# 功能项长时间未改动,同时回归测试未能覆盖,导致出现问题时,无法被发现
这个问题最特殊、最可怕的不是他们的数据类型一致,而是他们有大部分数据是相同的(使得问题无法暴露)