如何判断BUG是属于前端还是后端（抓包/日志定位分析）

（我的公众号“墨石测试攻略”，关注可免费获取整套接口测试实战项目！）

有的BUG看一眼就知道是前端还是后端的，而有些BUG则需要借助抓包工具（Fiddler、Charlers、浏览器的F12等）、日志进行分析了。

一般界面上的像错别字/字体大小、按钮显示、输入框超出边界等问题，不要犹豫、不要徘徊，肯定是前端问题；

界面报404的八成是前端写错了请求地址，指给前端开发；报500的，一般是后端问题，指给后端开发。

还有些问题，不太好判断的，可以用抓包工具来进行分析。

举例：一个查询接口，输入查询条件后，界面上没有数据展示出来。如何去分析这个问题呢？

首先，确保数据库里有符合条件的数据。

然后，可以使用工具Fiddler抓包，总结下来，就是三步走策略：

找到对应的请求包→看请求信息→看响应结果。

一、找到对应的请求包

怎么抓到目的包，也就是问题对应的包？
建议先停止抓包，并清除之前的记录，然后在客户端进行操作，这样Fiddler上抓到的基本上是当前操作的记录，然后再对抓包数据进行分析。

二、看请求信息

从上图可以看出，请求方式是POST，POST的信息分四部分，请求行、请求头、空一行、Body（GET请求是没有Body的）。Raw存放的是原始数据，其他的项是分析请求中的某一种数据。

// 抓包分析：

对照接口文档，看对应的接口有没有触发请求，如果没有请求（没有调用接口）或请求有问题，那就是前端的BUG。

三、看响应结果

HTTP响应主要由状态行、消息报头、响应正文（和消息报头之间空一行）组成。

// 抓包分析：

如果前端请求没问题，那么看响应。

先看响应的状态码，如果返回报错，看报错的状态码是什么，然后进行原因排查（参考公号“墨石测试攻略”中的这篇文章《接口测试常见的状态码》）；如果状态码为200，表示响应成功了，要具体分析后端返回的报文。

根据接口文档，看前端传参是否正确，如果是前端传参不对导致后端返回错误，那就是前端问题；如果传参正确，后端处理不正确，那可能就是后端问题。

如果后端响应了且数据和接口文档一致，那就是前端展示的问题。

总结：按前端→后端→前端的顺序进行分析。

类似的问题：比如一个登录界面，输入用户名密码后点击【登录】发现无响应怎么回事；一个支付功能，支付成功后在我的订单里却没有显示；打开一个网页，显示空白怎么回事等等，都可以按上述进行分析。

还有些问题，可以借助系统日志（Log）来分析。

为什么会有日志这种东东？一般为了便于查找、分析问题，开发人员会写很多日志来记录系统运行过程中的错误、异常或者系统处理过的事件。

我之前就遇到过这样一个问题：A系统对接B系统做数据同步，但是到达同步时间后，数据并没有同步过来。

我通过数据库查询到B系统中要同步的数据已经放到同步队列中了。然后我去查询了同步日志，日志记录了每一笔要同步的数据信息，发现有一笔数据一个字段的长度超限了，那么这笔数据肯定是无法同步过来的，但是理论上不应影响后面数据的同步。

原来是后端的代码错误地加了顺序的判断，导致了这个问题。

问题解决了，不仅定位到了BUG，也帮助开发分析了BUG的原因。

现在很多公司都将产品部署到Linux系统，小伙伴们要熟悉Linux常用的命令，学会用tail等命令去查询日志。

（我的公众号“墨石测试攻略”，关注可免费获取整套接口测试实战项目！）