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

前言前端

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

背景后端

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

发现spa

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

缘由简历

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

总结程序

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

相关文章
相关标签/搜索