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

Posted 2023-04-06 锦都不二

目录

前言

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

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

​

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

​

如何定位前端/后端BUG？

​

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

---

前言

随着开发软件趋向于大型化复杂化，软件测试逐渐成为一个专业，需要运用专门的方法和手段，需要专门人才来管理。但是外面的小道消息总是在传：软件测试就只是找bug的！这个我可就不同意了~

软件测试员是找bug，但也不仅仅是找bug。

首先我们需要了解下什么是软件测试。

软件测试简单点来说是验证软件在功能、性能等方面是否满足用户需求。

在整个软件测试过程中，软件测试狭义上指软件初步发版后，对功能的完备度、对bug的情况进行整体测试；广义上来说，软件的测试应该围绕在软件的整个生命周期当中，对软件的操作和应用都属于软件测试。

软件测试的目的首当其冲就是发现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了。在平常的工作和实践中慢慢总结，不要只是一味的点点点测测测，总结复盘很重要。

假如甘愿平庸，请向自己开炮！

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

如何定位前端/后端BUG?

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

1. 请求接口url是否正确

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

1. 传参是否正确

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

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

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

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

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

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

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

3. 查看缓存是否正确

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

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

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

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

接口查看法

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

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

日志查看法

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

经验法

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

最后为方便大家学习测试，特意给大家准备了一份13G的超实用干货学习资源，涉及的内容非常全面。

包括，软件学习路线图，50多天的上课视频、16个突击实战项目，80余个软件测试用软件，37份测试文档，70个软件测试相关问题，40篇测试经验级文章，上千份测试真题分享，还有2021软件测试面试宝典，还有软件测试求职的各类精选简历，希望对大家有所帮助……

关注我公众号：【程序员二黑】即可获取这份资料了！

如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入我们的群：785128166 大家一起讨论交流，里面也有各种软件测试资料和技术交流。