缺陷定位 | 如何精准效率分析推测BUG定位（二）

明天就是除夕了，很多人都回到了老家，吃上了妈妈做的饭菜，这时候应该是最幸福的时刻，我也用年前上班仅剩的几小时把 缺陷定位（二）分享给大家，希望大家能支持，也祝福大家2022新年快乐，幸福健康！！！

往期经典：

缺陷定位 | 测试发现了Bug，还要分析定位Bug？（一）

我觉得BUG分析推理定位很有意思，很像侦破案件，根据用户提供的各种证据信息，分析推理，逐步尝试复原现场，最终还原案发现场，这是最高光的时刻，也是最荣耀的时刻，也是值得他人尊敬和敬佩的，所以BUG定位在我们日常工作中非常重要，也是测试工程师最重要的技术手段。

BUG定位的效率度和准确度与其经验积累有着很大的关系，普通的新人复现BUG是需要花费大量时间的，而有着丰富的经验的人经历的BUG类型比较多，看到BUG表象，可以一眼大致辨识出BUG发生的原因，再根据辨识结果去尝试复现，效率会非常高，如果辨识是错误的，再尝试二次辨识。首先我们一般接到BUG，可以根据情况大致划分是前端问题还是后端问题，是数据问题还是业务逻辑问题，是系统兼容问题还是网络环境问题等，这样就可以更深层次推理复现了，不能是胡乱没有逻辑性的复现BUG，这样既是不效率的也是很难复现出问题的。

如果用户提供了大量的信息（BUG发生的图片、视频、环境、版本号、设备信息、网络环境、场所等），根据用户的操作步骤，尝试测试环境直接复现，如果能复现，说明我们业务确实存在这个BUG；如果无法复现，就与用户同软件版本尝试，能复现，说明与软件的复现版本可能有关系；无法复现，再与用户使用同环境复现，能复现，说明与复现环境可能有关系；无法复现这时就考虑与用户使用同软件版本、同设备信息、同软件进度数据、同网络环境等，能复现，说明与设备信息、软件进度数据、网络环境可能有关系；无法复现，可尝试登录用户账号信息复现，如果能复现，说明与用户账号数据可能有关系；如果还是无法复现，我们就需要进一步分析推理了。

分析BUG发生的时段和范围，如果是最近1-2天才大面积用户发生，可能是最近上了小版本，小版本业务或改了什么逻辑导致的；如果是最近1-2天个别用户发生，可能是最近上了小版本，某些操作逻辑下导致的；如果是个别用户不能重现的偶发现象，可能跟用户账号数据、网路环境、软件版本、设备兼容等有关系。

分析用户账号数据，查看用户的注册时间，判断是否与老账号数据兼容有关系，导致的问题；查看用户操作行为，判断用户时候进行了异常操作导致的问题；与正常用户数据对比，判断是否是错误的数据导致的问题。

看到接口500，一定是后端BUG吗？这个应该不一定吧，确实表象是后端出错了，但不一定是后端BUG导致的，也可能是前端传参错误、异常导致的，也可能是接口A给前端返的错误、异常的数据，导致前端拿错误、异常的参数进行接口B的请求出错了；也可能是前端H5传递给App的参数错误、异常，导致App拿到错误的参数请求接口出错了，都是有可能的，所以BUG的发生需要进一步分析定位和确认，不能盲目的下结论。

实例推理分析：

最近再玩抖音的年度红包活动，正好碰到几个BUG，现场给大家分析推理下

问题1：提现，点立即提现，报错 提现失败，请重试

问题发生步骤：提现成功后返回提现页面，再次点立即提现，报错

我们一眼看到这个问题，能判断应该是后端报错了，大概率不会是设备兼容性问题，也不会是网络环境问题，因为图中网络环境是满格的，我们可以看到提现金额是没有选中的，故猜测是不是没有选中金额，导致App传参错误，后端报错的，再根据推测再去抓包复现。这就是没有进行充分的接口测试导致的问题。

问题2：退货，匹配到了物流派送员，取消退货，选取消原因为其他，点确认，报错 task_fulfillment_pickup_cancel 503取消物流失败

这个问题看起来也是后端报错了，从报错信息可以看出来是取消物流失败了，正常的取消物流不可能失败的，毕竟是抖音大厂啊，推测可能是后端处理了异常或者是前端传了异常的参数，如果传了异常的参数，正常取消也会报错的，再次推测，可能是重复取消导致的报错，已经取消物流成功了，再次取消，报错取消失败，这种问题的发生，验证了我以前提到的状态测试法，很有必要进行测试的。

时间太仓促了，1个小时边想边写，其实心里想的很多，但是实际写出来，真写不出来，感觉写的很low很粗略，大家将就看吧，觉得写得好，记得点赞，转发给更多的朋友，感谢！！！