测试面试篇-印象最深的BUG

印象最深的一个BUG1

描述：

游戏化项目中，可以在后台系统配置多个任务。涉及到任务的创建、删除。
当时验证的时候，创建不同的任务，和删除任务。
创建和删除过程中，参考数据库表一起进行验证。发现多数数据删除正常，有一条记录没有删除成功，数据在页面上还能展示，删除过程中也没有提示错误。

查看服务端日志，也没有查到对应的错误日志。
当时考虑可能这条数据有对应的外键约束，导致删除失败。
通过查看数据库命令： select  @@foreign_key_checks，也没有对应的外键。

又对比了一下删除成功的数据，和删除失败的数据的区别。
发现删除失败的数据 有两条name相同的记录，考虑可能和多条记录有关，修改name不同时，操作删除成功。

查看日志确认，后端的判断逻辑是通过name查询的唯一主键id删除的。由于name对应的id有多条，导致后端拼接的sql语句错误。不能正常执行删除导致。

主要是后端的问题：修改后端的处理逻辑。修改为：通过前端传的id，匹配数据库对应的唯一主键，进行sql语句的拼接，执行删除。
不使用name条件做逻辑判断，解决问题。
通过研发提交的代码查看，判断条件的=也改为in了。容错性更高。

印象最深的一个BUG2

在之前的项目中，我负责测试一款用于银行客户管理的系统。这个系统涉及到客户信息的存储、查询和更新，功能相对复杂，对数据的准确性和完整性要求极高。

在测试过程中，我遇到了一个非常难以捉摸的bug。偶尔在执行客户信息查询操作时，系统会返回错误的数据，但是这个问题并不总是出现，而且似乎没有明显的触发条件。

为了找到这个问题的根源，我首先尝试复现这个bug。我仔细记录了每次查询操作的步骤和环境，包括查询的参数、系统的负载情况、网络状态等，试图找到任何可能的规律。经过多次尝试，我发现当系统负载较高时，这个问题的出现频率会增加。

接下来，我开始分析系统的日志和数据库记录，寻找可能的线索。通过对比正常情况和错误情况下的日志，我发现了一个微妙的差异：在错误情况下，系统的某个查询语句的执行时间明显延长。这可能是因为系统在高负载情况下，数据库的性能下降，导致查询语句执行缓慢，进而引发了数据返回错误的问题。

为了验证我的猜想，我进一步进行了压力测试，模拟系统在高负载情况下的表现。果然，在压力测试下，这个问题出现的频率大大增加。我立即将这个问题反馈给了开发团队，并提供了详细的错误复现步骤和分析结果。

最终，开发团队根据我提供的线索，成功定位并修复了这个bug。原来，在系统高负载情况下，数据库的某个索引失效，导致查询效率下降，进而引发了数据返回错误的问题。通过优化数据库索引和查询语句，这个问题得到了彻底解决。

这次经历让我深刻体会到了测试工作的重要性和挑战性。在面对难以捉摸的bug时，需要保持耐心和细心，通过科学的方法和严谨的分析，才能找到问题的根源并成功解决它。

原文链接：https://blog.csdn.net/qq_32177491/article/details/135559741