BUG 定位分析方法

Posted 2022-02-01 danhuang

为了能够更好的协助大家定位疑难 bug 问题，这里总结一些自我的经验给到大家，希望对大家有所帮助

对于简单的 bug 大家轻松定位解决就可以了，但是对于疑难复杂的 bug 这里我们分为 5 个核心流程方法，其中包括：梳理流程、日志分析、最小路径、猜测排除、独立验证。

最小路径

遇到问题后，要第一时间了解该问题重现的最小路径，通过最小路径来判断该问题的严重性以及影响面。如果重现路径复杂，那么可以思考影响面应该比较小，如果重现路径简单，那么该问题影响面应该很大，必须要尽快解决。

梳理流程

磨刀不误砍柴工，不要以为自己非常了解自己写的代码逻辑，往往是太熟悉了反而丢失了细节。在遇到疑难病症之前，一定要重现梳理逻辑流程，绘制出相应的逻辑流转图，根据业务逻辑重现梳理一遍。这样可以协助自己更快的定位到问题。如果觉得麻烦，可以直接使用脑图来绘制，更为简单快捷。比如像这样

日志分析

在业务出现一些异常情况时，需要增加日志信息了辅助定位，需要在逻辑分叉处以及外部调用增加日志即可。比如 if else、catch 、接口调用、SDK 调用等等。比如下面这段伪代码，为了检查问题，增加了各种日志信息。

if(!id)
  log.info('id is not exist');
  return -1;

let mainInfo = api.get('main-info');
if(!mainInfo)
   log.error('get main info come out error, pls check');
   return -2;

let picList = api.get('pic-list');
if(!picList)
  log.error('get pic list come out error, pls check');

let commentList = api.get('comment-list');
if(!commentList)
  log.error('get comment list come out error, pls check');

return mainInfo;

猜测排除

在遇到问题后，要大胆的猜测，应该怀着任何都有可能出现问题的猜测，比如第三方库、系统调用等等，不要带着这部分肯定不会有问题的想法，把有可能出现问题的场景都列举出来。

猜测点	猜测说明	验证情况
for 循环异常	中途抛异常退出
SDK 调用返回异常	facebook 返回数据接口异常
获取系统 API 返回异常	获取定位信息系统存在缓存，导致更新不及时

独立验证

拿到猜测列表后，就逐一进行验证，这里需要注意的是所有的验证都必须是独立的，不能多项同时进行验证。

如果遇到不能重现的问题，无法找到最小重现路径的，因为影响面是可控的，因此只需要增加日志加强定位辅助判断即可，对于核心重要的模块应该加强跟进。