如何区分前后端BUG

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

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

在很多项目中，都是前后端分离开发的。通常来说客户端更加注重界面展示、渲染等；而服务端会更加注重服务开发、逻辑处理等。

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

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

以HTTP请求为例子，请求过程如下：

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

看客户端展示，文字、图片、交互、兼容等属于前端BUG。如果是客户端直接闪退也可以看对应操作系统的崩溃日志，或者接入的第三方SDK，比如腾讯的Bugly（移动端）。
确认有无请求接口。可以通过查后段的日志进行确认，复现BUG的时候查看后端日志有无输出相关信息，若无则说明是客户端BUG
确认传参，使用抓包工具抓去客户端对服务端的每个请求。对比通过接口拿到的参数，和客户端实际展示的参数，来确认问题原因。如果说后端传过来的数据正确，但是客户端展示数据错误，则大概率是客户端问题。

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

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

而对于偶现问题，或者线上报过来的问题，我们无法进行抓包，因此只能通过去捞服务端的日志来进行排查。

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

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

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

分析：

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

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

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

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