测试如何定位判断是前端的bug还是后端bug
测试如何定位判断是前端的bug还是后端bug
软件测试⼯程师的职责是发现BUG，此外，如何体现个⼈价值，只是提出问题⽽不去解决，问题就永远得不到闭环。所以，⼀个资深的测试⼈员的基本功应该是这样的：深挖业务和功能需求，出BUG，定位BUG，提出解决⽅案。这⾥我们就来说说，当我们到了BUG，应该把BUG提交给谁去解决，这属于BUG定位的问题
前后端分离的优点是什么？
1. 彻底解放前端。前端不再需要向后台提供模板或是后台在前端HTML嵌⼊后台代码
2. 提⾼⼯作效率，分⼯更加明确。前端只关注前端的事，后台只关⼼后台的的话，两者开发可以同时进⾏，在后台还没有时间提供接⼝的时候，前端可以将数据写死或者调⽤本地的
JSON⽂件即可，页⾯的增加和路由的修改也不必再去⿇烦后端，开发更加灵活
3. 局部性能提升。通过前端路由的配置，我们可以实现页⾯的按需加载，⽆需⼀开始加载⾸页便加载⽹站的所有的资源，服务器也不再需要解析前端页⾯，在页⾯交互及⽤户体验上
有所提升
4. 降低维护成本。通过⽬前主流的前端MTV框架，我们可以⾮常快速的定位及发现问题的所在，客户端的问题不再需要后台⼈员参与及调式，代码重构及可维护增强
5. 实现⾼内聚低耦合
为什么要区分前端/后端BUG？
现在，市场上很多应⽤都是前后端分离开发的。如果是⼀个多⼈开发的系统。不能明确定位到这个BUG是谁造成的，任意提交给错误的开发⼈员，我们⼜不可能把这些bug同时提交给前端和后端⼀起去解决，同时提交给提交给前后端开发⼈员，每个⼈都会有依赖⼼理，就像'三个和尚没⽔喝的道理是⼀样的'。同样的道理，Bug会像⽪球⼀样被开发踢来踢去，耽误解决bug时间，影响项⽬进度。
另外，如果团队规模较⼤，或者由各地的项⽬组拼凑⽽成，势必会增加沟通成本，这更需要我们类似禅道或者Jira等项⽬管理软件中提交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了。在平常的⼯作和实践中慢慢总结，不要只是⼀味的点点点测测测，总结复盘很重要。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。