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

前言

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

背景

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

发现

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

缘由

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

总结

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