如何区分前后端BUG

在近几次的面试中，基本都会提及到前后端相关的问题。个人感觉一直回答得都不是很好，而且在平时的工作中也没有系统地梳理过。

趁今天有空，读了几篇文章作一点自己的总结。

在很多项目中，都是前后端分离开发的（游戏项目里说的前端、后端，一般就是客户端、服务端）。通常来说客户端更加注重界面展示、渲染等；而服务端会更加注重数据存储、逻辑处理等。

当测试发现BUG之后，如果无法明确这个BUG该由哪一端的开发来处理，提交BUG的时候就会增加沟通成本。在凝聚力不足的团队里，甚至会出现互相踢皮球的情况，降低BUG的处理效率，同时也会挤占我们的测试时间。

精准定位BUG，一是测试人员的能力体现，二是能积累自己的工作经验。

要定位BUG，先要知道一次请求会经过哪些环节。以HTTP请求为例子，请求过程如下：

当你发现一个BUG，判断这个BUG属于前端还是后端的几种方式：

看客户端展示，文字、图片、交互、兼容等问题一般属于前端BUG（但文字、图片如果是服务端下发的，比如公告、活动配置，也可能是后端的问题）。如果是客户端直接闪退，也可以看对应操作系统的崩溃日志，或者接入的第三方SDK，比如腾讯的Bugly（移动端）。
确认有无请求接口。可以通过查后端的日志进行确认，复现BUG的时候查看后端日志有无输出相关信息，若无则大概率是客户端没有发出请求（也要排除网络问题，或者服务端本来就没打这条日志的情况）
确认传参，使用抓包工具抓取客户端对服务端的每个请求。先看客户端发出的参数对不对，再对比接口返回的数据，和客户端实际展示的内容，来确认问题原因。如果说后端传过来的数据正确，但是客户端展示数据错误，则大概率是客户端问题。

更粗糙一点来说，就是确认服务端返回的数据是否符合预期。如果服务端返回的数据是对的，则大概率是客户端的问题，反之则要再看客户端传的参数：参数没问题，才是服务端的问题。而确认服务器返回数据的方式通常有两个：抓包和看日志。

通过抓包去确认数据，有个前提条件，就是这个BUG可以稳定复现，这样才能通过抓包来进行排查。

而对于偶现问题，或者线上报过来的问题，我们很难抓到包，这时主要靠捞服务端的日志来进行排查，有条件的话再结合客户端日志。

平时工作中注意总结和确认BUG的根本原因。测试人员对自己的项目了解得越深，越容易作出区分。也就是说可以通过自己的经验进行判断。

另外也要注意沟通，有时候测试人员定位半天，不如直接与对应技术沟通。

最后用一个抽卡的例子，把上面的方法串起来。

场景：进行十连抽，抽到了一个SSR，但是背包里只展示了其余的九个道具，没有展示SSR。

分析：
这个场景下，有两个动作，一个是进行十连抽，另一个是查看背包。

首先确认这个BUG是否可以复现，若无法复现，则直接去服务端查询日志。

先测试十连抽：查看客户端抽卡的时候调用的接口是否符合预期，传输的参数是否符合预期（比如传错了卡池ID，导致没法让新的SSR落库）。再看服务端是否把抽卡的结果正确添加到数据库里面。

再测试查看背包：依旧是先看前端调用的接口、传参等是否符合预期，再看后端有没有把符合条件的道具ID列表返回给前端。如果数据交互这方面没有任何问题，则可能是前端的逻辑有问题（比如说某个时间节点前隐藏某个道具的显示），无法正常显示这个SSR道具。