【记录】让人淡疼的BUG之参数传送错误
2013-08-05 13:35 Tester Chen 阅读(354) 评论(0) 编辑 收藏 举报前言
面试的时候往往容易被面试官问到:“说说你遇到过的比较重大或经典的Bug有哪些,能说一说吗?”
我被问时脑海的反应是:“尼玛,这个我从来没有刻意记!一时半会咋想得起来,然后还是没想起来或者是随意给了一个并不符合期望的回复”,各种不靠谱。
最近在测试过程中默默然发现一个一直存在、但一直未被人发现的Bug,把它记录起来吧!
背景
我们有金卡服务,针对VIP付费用户。
开通金卡服务后,经理人的简历在被猎头或企业搜索到时,经理人页面会统计“简历被搜索到:*次”,搜索到时次数会+1,统计的数据依据由前端发给后端。
发现
在某次上线测试过程中发现,猎头或企业搜索到我的简历后,我的被搜索到次数并没有增加。
同时,通过查询数据发现:最近5天以内开通金卡的经理人,他们的简历居然没有被任何猎头和企业搜索到,但开通6天以上的经理人有零星的被人搜索到。
到这里,仍然无法解释造成这种现象的原因是什么,最后,通过检查代码发现,发现……
原因
发现,前端向平台发送的数据是错误的。
平台在有一次上线中,将统计简历搜索次数的参数由“简历ID”变成了“用户ID”,而猎头或企业搜索到相关简历时,前端向平台发送的数据仍然是“简历ID”而不是“用户ID”。
这样做通过代码检查是无法看出错误的,因为用户ID和简历ID都是由一串数字组成且长度都同一区间内,所以程序处理十分正常。
同时由于两者有许多重叠的ID,就出现了我们看到的开通6天以上的经理人会零星有被猎头或企业搜索到。
总结
这个问题之所以存在并长时间未被发现,有以下几个问题:
# 底层平台改动后,对于其影响的区域未能准确定位、修改、测试,导致部分数据处理不正确
# 功能项长时间未改动,同时回归测试未能覆盖,导致出现问题时,无法被发现
# 这个问题最特殊、最可怕的不是他们的数据类型一致,而是他们有大部分数据是相同的(使得问题无法暴露)
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 单线程的Redis速度为什么快?
· 展开说说关于C#中ORM框架的用法!
· SQL Server 2025 AI相关能力初探
· Pantheons:用 TypeScript 打造主流大模型对话的一站式集成库