我就想到在我刚入行不久的时候有一个BUG。当时我们做的是一个CRM客户管理系统，里边有个客户列表，当时按照测试用例去执行的时候，发现出现点击客户删除却无法删除，于是就提了一个单，但是开发后来发现删除客户没问题，又给我打回，后来我去查看服务器日志结合数据库，去进行定位，发现在出现删除异常操作的时候，没有输出日志。这时，又去尝试了一下删除其他人，发现可以删除，同时有日志的输出，抛开日志不谈，当时出现这个问题我第一想法就是是否是数据库里的某一列的参数加了外键，导致删除不了，然后我就去数据库查看，发现并没有，然后我就尝试把出现异常的那条数据里边的参数一个一个去改，尝试是不是能成功删除，当客户名称被改掉后，发现删除成功。经过对比和推断，我推测如果客户名称一样就会无法删除，并且不会输出日志，其他情况删除功能是正常的，然后我把数据库中其中一个客户的名称改掉之后，果然两个都能删掉。接下来我去验证我的想法，我找了一个可以正常删除的这个客户，我看了一下开发打的日志，我们开发在日志里边有打他的SQL语句，我发现他是通过客户名查到了这个客户ID，然后用delete语句去删除，通过where ID等于去删除。那么当名字相同的客户查到了两个ID而代码里删除 delete 的时候用的是等于号，等于两个ID，数据库不支持这样的语法。所以给我提示的是删除异常。那么最后我们的开发进行修复，修修这个bug的方式是将用户进行删除动作的时候，传参改为传前端的点击的客户的ID，让后端直接通过ID去删除，因为这个ID是一个主键全局唯一的不重复的。同时将 delete 语句中的等于号改成了in支持单个删，也支持批量删。从这个BUG中我清楚了在进行BUG提单时，不要一出现BUG立马盲目就进行提单，一定结合需求做多方面分析，结合自己的经验找出BUG的特征，描述准确细致，方便开发去进行复现，再去进行提单，尽量尝试结合日志和数据库去定位BUG，避免开发无法进行复现，从而影响软件质量，从那过后我对自己提的BUG也尝试去进行定位，方便开发，也方便自己，提高整个工作效率。
