BUG 定位分析方法
Posted danhuang
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了BUG 定位分析方法相关的知识,希望对你有一定的参考价值。
为了能够更好的协助大家定位疑难 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 返回异常 | 获取定位信息系统存在缓存,导致更新不及时 |
独立验证
拿到猜测列表后,就逐一进行验证,这里需要注意的是所有的验证都必须是独立的,不能多项同时进行验证。
如果遇到不能重现的问题,无法找到最小重现路径的,因为影响面是可控的,因此只需要增加日志加强定位辅助判断即可,对于核心重要的模块应该加强跟进。
以上是关于BUG 定位分析方法的主要内容,如果未能解决你的问题,请参考以下文章