前言
面试的时候往往容易被面试官问到：“说说你遇到过的比较重大或经典的Bug有哪些，能说一说吗？”
我被问时脑海的反应是：“尼玛，这个我从来没有刻意记！一时半会咋想得起来，然后还是没想起来或者是随意给了一个并不符合期望的回复”，各种不靠谱。
最近在测试过程中默默然发现一个一直存在、但一直未被人发现的Bug，把它记录起来吧！
背景
我们有金卡服务，针对VIP付费用户。
开通金卡服务后，经理人的简历在被猎头或企业搜索到时，经理人页面会统计“简历被搜索到：*次”，搜索到时次数会+1，统计的数据依据由前端发给后端。
发现
在某次上线测试过程中发现，猎头或企业搜索到我的简历后，我的被搜索到次数并没有增加。
同时，通过查询数据发现：最近5天以内开通金卡的经理人，他们的简历居然没有被任何猎头和企业搜索到，但开通6天以上的经理人有零星的被人搜索到。
到这里，仍然无法解释造成这种现象的原因是什么，最后，通过检查代码发现，发现……
原因
发现，前端向平台发送的数据是错误的。
平台在有一次上线中，将统计简历搜索次数的参数由“简历ID”变成了“用户ID”，而猎头或企业搜索到相关简历时，前端向平台发送的数据仍然是“简历ID”而不是“用户ID”。
这样做通过代码检查是无法看出错误的，因为用户ID和简历ID都是由一串数字组成且长度都同一区间内，所以程序处理十分正常。
同时由于两者有许多重叠的ID，就出现了我们看到的开通6天以上的经理人会零星有被猎头或企业搜索到。
总结
这个问题之所以存在并长时间未被发现，有以下几个问题：
# 底层平台改动后，对于其影响的区域未能准确定位、修改、测试，导致部分数据处理不正确
# 功能项长时间未改动，同时回归测试未能覆盖，导致出现问题时，无法被发现
# 这个问题最特殊、最可怕的不是他们的数据类型一致，而是他们有大部分数据是相同的（使得问题无法暴露）