为什么找到网站中的bug后还要去分析它到底是属于前端bug还是后端bug，3个原因： 1、一个系统是由前端和后端共同开发出来的，因此在分配bug的时候，不同模块的bug一般都会指派给对应的负责团队乃至于个人。 2、提bug的时候，如果能尽量提供有价值的信息给开发人员，来缩小定位范围。 如果能够直接协助定位到bug出在哪里，那么开发人员将更容易fix掉bug，从而降低了测试和开发之间的沟通成本，提高了工作效率。 3、bug提的好从侧面也能体现测试人员具备了较高的技术专业性，而不是只会点点点，个人形象在项目团队中也会得到迅速提升。 页面的请求过程，以http请求为例： 1、用户在前端页面操作，如点击某个提交按钮 2、页面携带数据进行请求，访问具体功能接口 3、由后端服务执行相应的业务逻辑，如涉及数据，再去请求并组装数据返给前端 4、前端页面进行渲染和展示对应的页面和数据 前后端bug各有什么特点？ 前端和后端bug特点
| 前端BUG | 后端BUG |
| 界面相关 | 业务逻辑相关 |
| 布局相关 | 性能相关 |
| 兼容性相关 | 数据相关 |
| 交互相关 | 安全性相关 |
1、查接口 这种方法常用于查看是后端返回给前端的数据有误，还是前端显示有误。 大多数浏览器都有自带的接口查看工具，如Chrome，FireFox等都可以通过F12开启抓包，在NetWork中可以看到当前页面发送的每个http请求。也可以使用Charles、Fiddler抓包工具。
我们需要对比通过后端接口拿到的数据和前端显示的数据，来确认问题出在哪里。 如果数据错了，页面显示是错的，先从后端入手去解决。 如果数据对了，但是显示错了，就需要问问前端的开发人员了。 出现样式的问题基本都是CSS的BUG，出现文本的问题基本上都是html的BUG，出现交互类的问题基本上都是Javascript的BUG，其他问题先沟通，再定位。 通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口，传参，响应。 （1）请求接口url是否正确 如果请求的接口url错误，为前端的bug （2）传参是否正确 如果传参不正确，为前端的bug （3）请求接口url和传参都正确，查看响应是否正确 如果响应内容不正确，为后端bug2、查日志 当我们发现一个bug，并不确定这个bug属于前端还是后端，可以查看后端服务的日志，复现bug时，查看日志中有没有相关信息。基本可以认为，如果日志没有输出，很可能这个功能并没有与后端交互，也就不存在后端的问题。反之，如果日志有输出，可以进一步查看有无错误日志信息，进一步分析。
3、经验法 。负责的项目多了，自然对功能的实现过程有了解，也就明白如何分类bug了。在平常的工作和实践中慢慢总结，不要只是一味的点点点测测测，总结复盘很重要。
BUG举例分析： （1）界面相关 注意：测试页面兼容性时注意看一下win10、XP、一体机； （2）条件限制问题： SAASJM3-1329 - 连锁采购：总部：门店退货申请单-列表-查询条件-单据编号-长度在100以外可正常输入，应该在100以内； 新建 单据编号-长度在100以外可正常输入，应该在100以内； （3）页面显示条数问题： SAAS30-6363 - 促销：促销管理-满件赠，添加商品每页显示100条，实际商品数据仅显示20条； 新建 以上均属于前端问题； 2、数据不显示问题 （1）详情页整个页面数据均不显示： SAAS30-9345 - 连锁采购：总部：采购管理-采购入库单，点击入库，进入详情页不显示对应记录，应该正常显示记录； 新建 ； 该问题属于前端问题； （2）页面部分字段不显示： SAAS30-9306 - 连锁采购：总部：退货管理-门店退货入库单，查询列表，入库时间、备注、入库员均为空，应该返回对应数据； 关闭 ；该问题属于后端问题； 3、导出模板问题 SAAS30-8830 - 新返券规则：运营后台-智慧脸3.0-达标商家返券明细查询，excel导出 HUV列字段名字有误； 新建 ：excel导出 HUV列字段名字有误，后端问题； 4、后端接口报错，如下图报错：直接找user同学解决即可； 5、接口响应时间过长 SAASJM3-2147 - tab页签-近效期预警-一条数据查询时长超过十秒 新建 ，后端问题； 标签：分析,前端,前后,接口,bug,数据,BUG,页面 From： https://www.cnblogs.com/wangyutest/p/bug-analysis.html