方法一:分解法
【适用场景】:最终结果依赖与其他用应用或者产品线的请求响应。
【方法】:先排查发出的请求是否正确;在排查响应端的响应结果是否正确;最后分解,缩小排查范围,帮助开发有效定位bug。
【举例】:
Bug描述:多次请求,每次返回的推荐关键字均不相同。
问题定位:
(1) 通过查看源码,分词正常成功发送匹配请求
(2) 通过firfox找到请求的响应
(3) 通过向该suggest链接重发请求发现,suggest对相同的分词匹配到的数据,时有时无
因此判断,问题不是出现前端应用, 而是出现在suggest不稳定。
方法二:代码走读debug法
【适用场景】:数据,环境正常,对应代码可见
【方法】:先走读整个代码,重点review与操作功能对应的处理代码;很多隐蔽性的bug通过第一步的review是查不出来的,这个时候就需要debug代码
【举例】:
Bug描述:批量处理进入市场的时候失败。
问题定位:
(1) Review对应的方法,业务逻辑正确,没有问题
(2) 在代码中设置断点,使用问题数据,进行debug,发现
即map定义为了string,string型,而变量market却是Long型,因此获取market获取时,没有认识long型的market,做了空值处理。
方法三:排除法
【适用场景】:没有任何的头绪,errormassage不能提供任何有用的信息,拿不到对应的代码
【方法】:先排除掉自己想到的可能性,步步为营,层层分离,剩下不确认的,一般便是问题所在,即便是不能完全定位到问题,但是也可以有效的缩小需要进一步定位的范围。
【举例】:
Bug描述:在相同条件下,发布可成功,但编辑失败。
定位过程:
(1)数据库中校验当前数据正常
(2) 查看用户信息正常
(3) 同一个用户可发布成功
(4) 排除上面的各个因素之后,可以推测到:在发布和编辑接口对用户信息的处理不一致
(5) 而发布和编辑都调用的同一个c,应该是c的问题