测试过程中遇到的经典bug

那年冬天，测试项目组在凌晨两点集体沉默。过程屏幕上那个订单金额显示为 -0.01 元，中遇而用户账户里明明扣了 19.9。经典这个 bug 不崩溃、测试不报错，过程只是中遇悄悄让公司每笔交易多赔两毛。测试环境跑了三千条用例全绿，经典生产环境一上线就翻车。测试后来查出来是过程浮点数精度问题——0.1 + 0.2 在 JavaScript 里不等于 0.3，而我们的中遇优惠券计算用了连续减法。经典吗？经典太经典了，经典到每个电商团队都该在代码库里刻上“别用浮点数算钱”的测试墓志铭。

另一个让我记了五年的过程 bug 跟时间有关。测试同学在 23:59 提交表单，中遇页面显示“提交成功”，数据库里却存成了第二天的日期。开发说“本地复现不了”，因为他的机器时区是 UTC，测试机是东八区。跨时区、跨天、跨年，这类 bug 专挑凌晨和月末跑出来。你写用例时只想着“正常日期”，它偏在 2 月 29 日、12 月 31 日、夏令时切换那天给你惊喜。后来我们养成了习惯：任何跟时间相关的功能，必须用 fake timer 把系统时间拨到边界再跑一遍。

并发问题更阴。有个抽奖接口，单线程测试永远只中一次，用 JMeter 开 50 个线程同时打，奖品库存直接变负数。开发加了 synchronized 关键字，测试环境又过了。上线后大促流量一冲，还是超卖。为什么？因为服务部署了三个节点，synchronized 只锁得住一个 JVM。分布式锁没加，Redis 扣减也没用 Lua 脚本。这个 bug 教会我一件事：测试并发不能只测接口，得测整个部署架构。你本地跑得再欢，生产环境是集群，锁的粒度、缓存的失效、消息队列的重试，每一个环节都能让“通过”变成“偶然”。

还有一类 bug 纯粹是“人的问题”。产品文档写“用户可上传头像”，开发做了 jpg/png 校验，测试传了张 10MB 的图，接口超时。开发改成异步上传，测试又传了张 0 字节的空文件，后端直接抛 500。再后来有人传了个 .exe 改后缀成 .jpg，服务器存下来还能被解析执行——这就是安全漏洞了。你问为什么没早发现？因为测试同学默认“用户会正常操作”。可真实世界里，用户会传截图、传表情包、传从网上随便下的图，甚至故意传奇怪的东西。测试用例里加一行“异常文件类型”，比写一百行“正常上传”更有价值。

最让人哭笑不得的 bug 往往出现在“我以为没问题”的地方。比如删除按钮，测试点了确认删除，数据没了，用例通过。但没人测“取消删除”——点取消后数据居然也没了。因为前端把取消按钮和确认按钮绑了同一个事件。这种 bug 不靠自动化，靠的是测试人员多问一句：“如果我点这个，会发生什么？” 自动化能覆盖 80% 的回归，剩下 20% 的边界和异常，得靠人脑去“找茬”。

说这些不是要否定测试的价值。恰恰相反，每个经典 bug 背后都是一次认知升级。浮点数精度逼我们写了金额计算规范，时区问题催生了时间工具类，并发超卖让我们引入了分布式锁测试方案。bug 不会消失，但每次踩坑后留下的检查清单、代码规约、测试策略，才是团队真正的资产。下次再看到 -0.01 元，至少你知道该去查哪一行代码了。