调查的bug的手段有哪些?

极客神灯

1、打log,看日志

代码log的重要性和代码本身是一样的。在关键的逻辑和判断条件处添加日志,最好做到即使不做debug也可以了解代码运行逻辑。如果不知道哪些地方应加日志,简单的方式就是所有的自定义函数的入口和出口都添加上日志。可以使用切面编程或者代理,自己封装一个log的框架,利用切面或代理操作就会简单很多,对原始的代码入侵也小。

日志中不仅要有流程的标记,还有有状态信息,比如:时间、线程号或用户id、关键的参数信息。能说明谁在什么时间什么条件下做了一件什么事情,把这个事情说清楚就行。

这样的日志量可能会很大,日志的分级处理也很重要,trace、debug、info、warn、error等信息分别表示。error信息中除了异常时的运行栈信息,还需要有一些关键的内存参数信息,比如当前方法的参数或者逻辑的关键条件等。

2、用户访谈

要不要做用户访谈?打电话还是与用户见面?这个要看工程师的个人沟通能力。有的人和用户沟通亲切且专业,沟通能力强,有说话的技巧,用户不反感,那就可以做用户访谈,和用户了解清楚当时发生问题,做了什么操作。很多奇怪的问题都是和特定的操作环境甚至操作流程有关系,做用户访谈要问清楚的几件事:

  1. 当时的操作环境,系统,运行环境
  2. 网络环境,如果是网络问题,和用户沟通一下能不能接入他们网络复现问题
  3. 当时的操作过程,操作顺序
  4. 一些特殊的操作习惯

记下基本的信息,最好用脑子记,当时不要打字或用写下来,这样会给用户压迫感,感觉太正式了,说的内容就会自己提前处理一下。很多操作的细节就是在无意中提到的,所以访谈的时候可以适当随意些,但是注意聆听,如果有细节感觉有点不太一样,先记在心里,不要打断用户,让他顺畅的说完,再提问。

3、代码review,画流程图

梳理清楚代码逻辑,多看几遍代码,一边看代码,一边和需求/逻辑对比,发现异常的地方。如果逻辑比较复杂,层次比较深,看一遍记不住所有逻辑,那最好画出流程图,逻辑梳理找到漏洞或可疑点。运气不好,还要增加log,测试调试。

4、用google

这个成本最低,可以先做。把问题、异常信息贴到google里面,先看看其他人遇到类似的情况了吗?60%的问题这种方式就能解决。

5、用工具分析运行状态

如果可以复现问题了,就可以使用一些内存分析工具,检查发生问题的状态。不同技术都有内存分析工具,jmap, jstack等等,多多利用,学习怎么使用这样工具会让解决问题效率提升很多。

6、评估危害

没有不存在bug的程序,评估bug的危害和解决成本就很重要。
有没有直接影响到了用户体验,影响到支付流程,影响到了生命安全,影响到用户比例有多少。

有的问题频率虽然不高,但是很致命;有到虽然不会伤害生命,但是规模大;有的规模不大,也不致命,但用户发生一次就被劝退了。这些都很严重。

危害的评估,主要是三个方面:规模频率、严重程度、危害是否可逆。

阅读 243

为了获得勋章才写的

320 声望
5 粉丝
0 条评论
你知道吗?

为了获得勋章才写的

320 声望
5 粉丝
宣传栏