软件测试遇到的bug举例

去年冬天，软件我在一个电商项目里碰上个 bug，测试到现在想起来还觉得牙痒。举例用户把商品加入购物车，软件数量选了 3，测试结算时页面显示的举例总价却是 2 件的钱。前端算了一遍，软件后端又算了一遍，测试两边都对不上。举例查了两天，软件最后发现是测试前端在提交订单前做了一次“四舍五入到整数”的处理——开发觉得价格不该有小数，顺手加了 `Math.round`。举例可那件商品单价 19.9 元，软件3 件应该是测试 59.7，被 round 成了 60？举例不，他们 round 的是单价，19.9 变成 20，再乘 3 得 60。但后端拿到的是原始单价乘数量，59.7。两边数据在订单创建接口里打架，取了个最小值，用户就少付了。

这种“开发自作聪明”的 bug 特别常见。另一个例子来自某银行 App 的转账页面。测试同事在弱网环境下反复点击“确认转账”，发现偶尔会生成两笔相同订单。开发第一反应是“用户手抖”，加了防抖按钮。结果测试用自动化脚本模拟 0.3 秒间隔的点击，依然复现。真正的原因藏在网络层：第一次请求超时后，客户端重试机制触发了，但重试时没有带上幂等 token。后端收到两个一模一样的请求，自然扣了两次钱。这跟用户点得多快没关系，是重试逻辑没做去重。后来他们加了个 requestId，问题才消失。

还有一类 bug 纯粹是数据边界没处理好。我参与过一个物流查询系统，输入运单号能查到轨迹。测试拿了个 12 位数字的单号，正常。换成 13 位，页面直接白屏。看日志，后端把运单号当整数解析了，13 位超出了 int 范围。开发辩解“运单号不会那么长”，可实际业务里真有跨境单号是 14 位的。这种 bug 不靠猜，得靠等价类划分和边界值分析去覆盖。测试用例里写“输入 11 位、12 位、13 位、14 位数字”，一跑就露馅。

时间相关的 bug 更隐蔽。有个签到功能，用户每天第一次签到得积分。测试在 23:59 签到成功，等到 00:01 再签，系统提示“今天已签到”。查数据库，签到日期字段用的是 `DATE` 类型，但服务器时区是 UTC，用户在东八区。跨天判断逻辑写的是 `WHERE sign_date = CURRENT_DATE`，UTC 的 CURRENT_DATE 比北京时间晚 8 小时。用户本地 00:01 其实是 UTC 前一天 16:01，数据库里存的还是前一天的日期。改法很简单，统一用 UTC 时间戳存，展示时再转时区。但发现它花了测试整整一个通宵蹲点。

界面上的 bug 有时候看着像玄学。一个下拉框在 Chrome 里正常，在 Safari 里选项文字被截断。开发说“Safari 兼容性问题，不管”。测试不干，用 Safari 的开发者工具看了下，发现是 `line-height` 设了固定像素值，Safari 对字体渲染的基线计算跟 Chrome 不同，文字往下沉了 2px，被容器 overflow 切掉。改 `line-height: normal` 就好了。这种问题不靠自动化能发现，得真机点一遍。

最让人哭笑不得的是一个“删除确认”弹窗。用户点删除，弹窗问“确定删除？”，点“取消”，数据居然没了。开发查了半天，发现取消按钮绑定了两个事件：一个是关闭弹窗，另一个是父组件冒泡上来的删除方法。因为取消按钮没有 `stopPropagation`，点击事件穿透到了底层的删除按钮上。用户以为点了取消，实际触发了删除。修复方案是给取消按钮加 `@click.stop`。这类 bug 在组件库混用时特别容易出，测试的时候不能光看弹窗有没有关，得看数据到底删没删。

写这些不是要吐槽开发。bug 是软件的一部分，就像人会打喷嚏。关键是测试得把场景想全：别只测正常流程，要测异常、测边界、测并发、测时区、测不同浏览器。开发写代码时脑子里的“用户不会这么干”，往往就是 bug 的温床。我现在的习惯是，看到 `Math.round`、`parseInt`、`new Date()`、`setTimeout` 这些地方，都会多瞄两眼。经验告诉我，那里头藏着不少惊喜。