测试如何判断是前端的bug还是后端的bug

  软件测试工程师的职责是发现BUG，此外，如何体现个人价值？那么我们试想，只提出问题而不去解决，问题就永远得不到闭环。所以，一个资深的测试人员的基本功应该是这样的：深挖业务和功能需求，找出BUG，定位BUG，提出解决方案。这里我们就来说说，当我们找到了BUG，应该把BUG提交给谁去解决，这属于BUG定位的问题。

一.为什么要区分前端/后端BUG？

  如果是一个多人开发的系统，不能明确定位到这个bug是谁造成的，容易提交给错误的开发人员，我们又不可能把这些bug同时提交给前端和后端一起去解决，同时提交给前后端开发人员，每个人都会有依赖心理，就像我们在家里一样，兄弟姐妹多的，干家务活总会想着给对方做，一样的道理。bug会像皮球一样被开发踢来踢去，耽误开发解决bug的时间。

  另外，如果团队规模较大，或者由各地的项目组拼凑而成，势必会增加沟通成本，这更需要我们在类似禅道或者Jira等项目管理软件中提交bug时，先指明是谁的bug，避免互相踢皮球的现象。

  所以测试必须要自己学会区分出是前端还是后端bug，就好像时下流行的词“垃圾分类”，经过bug分类处理，整个团队的效率都会有所提高。

  但说实话，能真正区分并准确判断是什么错误需要很有经验的测试，并且也需要测试懂开发技能。目前我这方面能力真的欠缺，我也需要加油~。虽然初级中级的测试不能做到完美区分所有bug，但一定要学会简单的区分bug的能力。

  所以，为了提高团队效率，测试人员尤其要做好bug分类。在测试过程中，如何判断是前端的bug还是后端的bug？

二.如何定位前端/后端BUG?

通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口，传参，响应。

1. 请求接口url是否正确

如果请求的接口url错误，为前端的bug

2. 传参是否正确

如果传参不正确，为前端的bug

3. 请求接口url和传参都正确，查看响应是否正确

如果响应内容不正确，为后端bug

4. 也可以在浏览器控制台输入js代码调试进行分析

如果定位为后端的bug，可以进一步通过以下方法精确定位是哪里出bug

1. 查看报错日志，通过日志分析问题点

2. 查看数据库确认数据的正确性

3. 查看缓存是否正确

前后端BUG各有什么样的特点？

前端BUG	后端BUG
界面相关	业务逻辑相关
布局相关	性能相关
兼容性相关	数据相关
交互相关	安全性相关

定位BUG属于前端还是后端，有什么方法？

这里提供了几个方法，可以给大家一个思路，让大家能在学习和工作中了解如何去区分BUG属于前端还是后端。

接口查看法

这种方法是最常用的，我们必须掌握的，常用于查看是后端返回给前端的数据有误，还是前端显示有误。

大多数浏览器都有自带的接口查看工具，如Chrome，FireFox等都可以通过F12开启抓包，在NetWork中可以看到当前页面发送的每个http请求。要想通过接口查看法来判断，你需要先了解Chrome浏览器的Network面板介绍。

日志查看法

当我们发现一个bug，并不确定这个bug属于前端还是后端，可以查看后端服务的日志，复现bug时，查看日志中有没有相关信息。基本可以认为，如果日志没有输出，很可能这个功能并没有与后端交互，也就不存在后端的问题。反之，如果日志有输出，可以进一步查看有无错误日志信息，进一步分析。

经验法

经验法就只能是慢慢积累了。负责的项目多了，自然对功能的实现过程有了解，也就明白如何分类bug了。在平常的工作和实践中慢慢总结，不要只是一味的点点点测测测，总结覆盘很重要。