您现在的位置是：首页 >其他 >测试如何定位判断是前端的bug还是后端bug网站首页其他

以下是自己的一些认知和总结，希望可以帮到大家

第一：前后端分离的优点是什么？

彻底解放前端。前端不再需要向后台提供模板或是后台在前端HTML嵌入后台代码

提高工作效率，分工更加明确。前端只关注前端的事，后台只关心后台的的话，两者开发可以同时进行，在后台还没有时间提供接口的时候，前端可以将数据写死或者调用本地的JSON文件即可，页面的增加和路由的修改也不必再去麻烦后端，开发更加灵活

局部性能提升。通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升

降低维护成本。通过目前主流的前端MTV框架，我们可以非常快速的定位 及发现问题的所在，客户端的问题不再需要后台人员参与及调式，代码重构及可维护增强

实现高内聚低耦合

第二：为什么要区分前端/后端BUG？

现在，市场上很多应用都是前后端分离开发的。如果是一个多人开发的系统。不能明确定位到这个BUG是谁造成的，任意提交给错误的开发人员，我们又不可能把这些bug同时提交给前端和后端一起去解决，同时提交给提交给前后端开发人员，每个人都会有依赖心理，就像'三个和尚没水喝的道理是一样的'。同样的道理，Bug会像皮球一样被开发踢来踢去，耽误解决bug时间，影响项目进度。

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

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

第三：如何定位前端/后端BUG？

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

1.请求接口Url是否正确

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

2.传参是否正确

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

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

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

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

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

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

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

查看缓存是否正确

前后端bug各有什么样的特定？

| | 前端bug | 后端bug |

| | :--------: | :----------: |

| | 界面相关 | 业务逻辑相关 |

| | 布局相关 | 性能相关 |

| | 兼容性相关 | 数据相关 |

| | 交互相关 | 安全性相关 |

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

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

接口查看法

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

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

日志查看法

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

经验法

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