软件测试印象深刻的bug.docxVIP

购物车结算的一个bug

背景描述：

在我参与的一个电商项目中，有一个购物车功能模块。在一次版本迭代后，我负责测试购物车的结算功能。

Bug的具体表现：

在测试过程中，我发现当用户添加多个商品到购物车并尝试结算时，结算金额显示异常。具体表现为，当购物车中有超过10件商品时，结算金额会比实际金额少10%。

发现过程：

我通过边界值分析的方法，测试了购物车中不同数量的商品（如1件、5件、10件、11件等）。当商品数量超过10件时，问题复现。

分析与定位：

我查看了前端请求和后端响应的数据，发现后端在处理购物车商品数量时，使用了一个错误的算法。当商品数量超过10件时，系统错误地应用了一个折扣逻辑，导致结算金额计算错误。

后端在处理购物车商品数量时，使用了一个错误的算法。当商品数量超过10件时，系统错误地应用了一个折扣逻辑，导致结算金额计算错误。

解决与验证：

开发团队修复了算法问题后，我重新测试了购物车结算功能，确保问题已解决，并进行了回归测试，验证了其他相关功能未受影响。

总结与反思：

这个bug让我意识到边界值测试的重要性，尤其是在处理数量、金额等关键数据时。

同时，我也学到了如何更好地与开发团队沟通，快速定位问题根源。

总结

通过这样的回答，你不仅能展示你的测试技能和思维，还能体现你的问题解决能力和团队协作能力。确保你的回答简洁明了，重点突出，给面试官留下深刻印象。

用户收藏的笔记莫名消失--偶发线上bug

凌晨1点收到用户投诉：收藏夹里的美妆教程突然全没了！（复现率仅5%，安卓/iOS随机出现，堪称测试噩梦…）

破案过程堪比悬疑剧

↓?以为是缓存问题→清理缓存后短暂恢复，3分钟后数据再次消失

??怀疑接口报错→抓包发现200成功但data字段为空??

?灵机一动检查埋点→发现用户操作时存在「双跳请求」！（前端重复提交收藏/取消，但服务端没加互斥锁??）

?深挖日志发现更可怕：第三方SDK在断网时会把失败操作「逆序执行」...??

真相：前端防抖失效+服务端无幂等校验+SDK补偿机制冲突→三方漏洞组合拳！??

解决：

给收藏按钮加「操作锁」防止连点

2.服务端增加请求唯一ID校验

3.修改SDK失败重试逻辑

4.添加异常状态UI提示（emoji哭脸+安抚文案）

总结：?永远对低概率bug保持警惕?多端日志联查才是王道?优雅的异常提示能拯救用户体验！

高峰期楼层请求分配异常的Bug

具体表现为：在早高峰期间，多个楼层同时呼叫电梯时，系统会将多部电梯集中调度到某一楼层，导致其他楼层长时间等待，用户体验极差。

Bug现象与影响

现象：模拟测试时，当10个楼层同时发出上行请求时，系统错误地将3部电梯全部调度到中间楼层（如5楼），而高楼层（如15楼）和低楼层（如1楼）请求被忽略超过2分钟。

影响：用户等待时间远超设计指标（设计要求不超过30秒），投诉率上升，项目交付面临风险。

排查过程（体现分析能力）

步骤1：复现问题搭建压力测试环境，通过自动化脚本模拟多楼层并发请求，100%复现问题。

步骤2：日志分析发现调度算法在计算“最近空闲电梯”时，错误地将电梯的“当前负载”权重设为0，导致系统优先调度空载电梯，而忽略了电梯的物理位置。

步骤3：代码审查与开发排查发现，算法中有一个隐藏的逻辑边界条件未处理：当电梯负载低于20%时，权重计算公式的分母可能为0，导致计算结果溢出。

解决方案（体现协作与推动力）

技术修复：

-修正权重计算逻辑，引入电梯位置、负载、方向综合评分机制。

-增加分母为0时的异常保护，避免计算崩溃。

-验证方法-使用JMeter模拟100个并发请求，验证电梯分配均匀性。

-加入蒙特卡洛随机测试，覆盖更多极端场景。

-团队协作：推动开发团队在代码中增加关键日志埋点，便于后续问题追踪。

改进措施：

-在需求评审阶段，增加对“边界条件”的讨论（如零值、极端并发）。

-推动团队在自动化测试中补充“非功能场景”（如压力、随机干扰测试）。

-个人收获学会通过“分阶段隔离变量法”定位复杂问题，例如先通过日志锁定算法模块，再逐步排除硬件、网络等干扰因素。通过这类问题，面试官希望看到你不仅是“找Bug”，而是能推动问题闭环并沉淀经验。

测试地址管理的一个bug

在测试地址管理的时候，偶然发现当我对已添加的地址，进行删除和修改的时候页面都显示操作成功，但是修改后数据没有发生变化，删除后数据也依旧存在。我当时就感觉非常奇怪，反复的复测几次，最后得知，当我对地址进行添加、查看功能数据都是正常的，删除、修改的时候页面提示删除成功、修改成功，但是还是原来的数据。

我看了一下前端传参也没有问题，我又拿着前端穿的I