天天被开发怼？4个方法区分bug前后端归属，我再也不背锅了！

“开发都这么不友善吗？”

有朋友跟我说，刚上岗经常分不清bug是前端还是后端，一直需要开发帮忙重新指派，甚至还会被开发拿来吐槽....

其实不是开发态度不好，而是对于前后端分离的应用，既需要进行功能测试，还需要进行接口测试，并且在进行功能测试是还需要分析bug是前端还是后端的问题。

测试掌握bug的归属问题，就像时下要求掌握‘垃圾分类‘一样，经过bug分类管理，整个团队的效率都会有所提高。

今天就着这个朋友的吐槽，来跟大家分享一些区分前后端BUG的技能，来帮助大家快速定位bug的归属问题。

1 前后端bug特征

前端主要负责显示数据，后端主要负责处理数据、存储数据，前后端通过接口进行数据的交换

前端bug的特征：

界面显示类问题：如文字大小不一、控件颜色不搭、控件不整齐、静态文字错误等界面展示不友好类问题

页面布局类问题：如文字排版没有统一、行间距太小、重叠、显示不全等

交互类问题：如没有点击、拖拽事件等基本都是JS的问题

兼容性问题：不同环境下（如不同浏览器，不同配置手机）的界面显示类问题和页面布局类问题

后端bug的特征：

业务逻辑类问题：如正确的用户名和密码无法登录，支付后扣款成功，但是显示支付失败等

数据类问题：如新增成功的数据没有显示等

性能类问题：如页面、表单打开缓慢，提交表单一直显示提交中等

安全类问题：如越权、sql注入等

2 判断前后端bug方法

分析日志

当我们发现一个bug时，可以在复现bug时抓取后端服务日志，并查看分析后端服务的日志。

如果日志中没有相关信息，基本可以认为是前端bug，因为这个bug跟后端没有交互，所以才没有相关日志输入。

反之如果日志有相关信息输出，可以进一步查看是否有错误日志信息，进一步分析，如果明确有报错信息，则基本断定为后端bug，可以将日志和bug一并提交给开发。

抓包工具+报文分析

当我们发现一个bug时，可以在复现bug时可以通过F12、Fiddler抓包前后端交互的报文并进行分析：

报文中如果前端没有发出请求，就是前端bug。

报文中前端发出了请求，但是请求的参数有错误，也是前端bug

报文中前端发出了请求，参数没有问题，后端没有响应，没有数据，就是后端bug

报文中前端发出了请求，参数没有问题，后端返回数据有问题(返回数据错误)，就是后端bug

报文中后端返回了且数据也是正确的，但是前端界面没有正确显示，那就是前端bug

数据库分析

了解所测功能的数据表结构，测试过程中，查看数据库的数据，确认数据的正确性。

比如：在注册成功，但是登录时（数据正确）提示登录失败，这时我们可以通过查询数据库的数据来确认。

首先查询用户表中没有插入注册成功的数据，如果没有数据则是后端bug；

如果插入数据成功，那就要结合抓包工具+报文分析的方法来进一步确认。

经验法

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

另外，多和开发人员沟通，有助于了解具体的业务模块，再加上自己对业务足够熟悉，也会更加容易判断bug的归属了。

行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群： 320231853，里面有各种软件测试+开发资料和技术可以一起交流学习哦。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！