Bug分析

• 1、如何分析Bugli>
• • 1）抓包接口定位分析
  • 2）看系统日志

1、如何分析Bugh1>

1）抓包接口定位分析

web项目的话，一般工作中使用方式比较多的是使用浏览器自带的F12抓包看接口请求。
如果是app客户端之类的，一般采用fiddler等工具进行抓包接口。
不管哪种方式，目的都是通过查看接口，去定位分析属于前端问题还是后端问题。

比如你在淘宝上边购买了一件商品，并且成功支付，但是在我的订单里面却没有记录，你应该如何去分析定位这个问题p>

首先需要搞明白的是这个场景的数据流调用的逻辑关系，不过这个问题比较简单。

整体来说就是前端购买商品，支付成功，会把这条数据的商品信息加支付信息都落入数据库中。

然后点击我的订单，会调后端接口，后端从数据库取相关信息，然后前端渲染展示商品和支付信息。

搞明白这个场景的数据流转就很容易定位分析这个bug了，可以使用抓包工具抓包这个我的订单调后端的接口。

如果抓不到这个接口，就是前端没有发出请求，显然是前端问题。

如果有请求并且响应了，就查看这个接口响应信息，如果返回 错了，则需要具体分析 错内容。

这个时候既有可能是前端入参传的不对，导致后端 错。也有可能是前端传对了，后端处理错误，需要具体分析是前端问题还是后端问题。

如果后端成功响应了且返回信息跟接口文档定义的一致，那么大概率是前端展示的问题，这个时候需要找前端同事。

以上，就是定位一个bug是属于前端还是后端的分析思路。

2）看系统日志

既然可以抓包定位看接口返回了，为什么还需要查日志系统呢r> 这是因为对于一家公司来说，一般不止一个系统。很多公司都是根据业务不同划分出不同的组，不同系统共同完成公司一个项目。

举个例子，比如一家保险公司，可能有系统是负责用户下单的就是交易系统，管理保单变更比如退保之类的就是保单系统，负责收钱的就是财务系统，负责赔钱的就是理赔系统……

每个系统就是一个组，一般二三十人不等。每个组有开发，测试，产品，具体看公司了。

那么这些系统是怎么交互合作的呢通过接口来交互，这也是接口测试比较复杂的地方，涉及到多个系统多个接口的逻辑调用。

理解完这个，再说到为什么要查看日志的问题p>

比如页面调后端系统接口 错了，但是你知道整个流程能有多长吗p>

页面可能直接调用的是系统A接口，但是这时候系统A又调用了系统B，系统B又调用了系统C。页面上看到的接口返回 错结果，本质上可能是系统C接口 错返回的。

这个时候仅仅通过抓包就无能为力了，你需要去查看系统日志，去一层层去分析，究竟是哪个系统 错了，然后定位到问题。把 错信息和日志截图丢给那个系统同事。

一般我发送错误，协调处理时都会发下面几样东西，调对方接口的url，入参信息，返回 错信息。

再简单描述下调用接口业务场景，如果对方很熟悉的话一看url就知道了，这时候就不用描述了。

再来说下系统日志是怎么一回事p>

日志本质上就是开发写在项目中的代码， 错会抛出异常信息，以及打印一些接口返回信息等等。

有的公司会有专门的日志查询系统，有的公司是通过xshell工具连接上linux系统再查找日志，这就看公司了。

因为现在公司系统一般是linux系统，所以查询日志的命令自然就是linux命令了。

我一般用的比较多的是grep，tail这两个命令，前者是精确查找，后者是动态查找，大家可以百度学习下这两个命令。

说一下精确查找，就是根据开发代码中打印的关键字信息去精确查找日志，一般是requestid，证件 或者订单 之类的。

这个可以提测后问下开发，查找日志的关键字是什么，日志文件名是什么，以及去哪个服务里面去查找。

因为现在一般是微服务架构，不同的服务处理不同的业务，存储不同的日志。不同公司可能不太一样，但是方式大同小异。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92479 人正在系统学习中