软件测试工程师怎样搞定一个神奇的BUG

前两天在BearyChat收到这样的一个报警消息:

　409 ？Conflict ？ 平时很少遇到这样的错误，貌似很严重的样子，吓得我赶紧查看到底发生了什么。

仔细查看错误详情发现是因为使用同一个邮箱账号多次注册导致后面的请求数据库直接报错。

但是，不应该啊！我们是事先有做检查的。如果该邮箱已经被注册，会提醒并且不让注册的。难道对方直接调用API发请求？如果是这样那就更加危险了，我们已经被盯上了！

可是这样做也没什么好处啊，并且IP显示为国内地址，如果真的好歹用国外的地址吧。想了想，还是仔细分析到底出了什么问题吧。

再往下一看，发现自己完全是多想了，下面的用户行为就把他给完全暴露了！

　　这些用户行为记录默认按照倒序排列，我们可以从下往上一条条看用户的使用轨迹。通过用户行为可以得知出错前的整个操作流程：

• 打开我们网站的首页

• 点击“免费试用“进入注册页面

• 输入邮箱

• 输入密码

• 再次出入密码

• 点击创建团队

• 点击创建团队

• 团队创建成功

• 报错

那么问题来了：有没有什么异常的行为？

答：有！他点击了创建团队两次。

凭着我敏锐的嗅觉意识到可能是由于用户快速点击"创建团队"按钮两次导致。通过时间记录发现第一次点击是在1.86m，第二次在1.87m。也就是说：用户在很短的时间内快速点击了两次。

刚刚的用户行为记录过滤了网络请求，接下里我们结合网络请求一起分析：

可以发现有两个/members/email的GET请求，并且都成功返回404，这里代码的意思是指该邮箱尚未被注册，可以被使用。一个/members/create请求成功返回200，表示账户创建成功。最后报错的/members/create请求失败返回409。

到这里基本确定出错原因就是由于用户快速点击创建团队导致。

有没有这种可能呢，尝试复现一下看看呗！于是，我打开了注册页面，输入邮箱和密码，然后以超快的手速点击创建团队N次。哈哈哈哈，不出所料，被我成功复现了！

只要能够成功复现，这个BUG基本上就算被解决了，接下来就是去分析如何优化代码防止出现这种情况了。有两个思路：1. 用户点击之后，设置被点击的按钮无效直到点击请求完全被处理；2. 将验证邮箱是否存在的和创建团队两个异步事件想办法合并为一个原子操作。综合考虑，决定使用第一种方案。因为实现简单，对现有代码改动不大。

总的来说：当在没有堆栈信息或者报错信息难以理解的时候，Fundebug记录的用户行为真的很有用。