如何判定一个bug是前端bug还是后端bug
首先需要了解一个页面的请求过程：
以http请求为例：
1、用户在前端页面操作，如点击某个提交按钮
2、页面携带数据进行请求，访问具体功能接口
3、由后端服务执行相应的业务逻辑，如涉及数据，再去请求并组装数据返给前端
4、前端页面进行渲染和展示对应的页面和数据
前后端bug各有什么特点？
前端bug特点 1， 界面相关 2，布局相关 3，兼容性相关
后端bug特点 1，业务逻辑相关 2，性能相关 3，数据相关 4，安全性相关
一、前端问题
1、界面相关
常见的界面相关问题有：排版错乱、文字错误、数据错误、兼容性问题
文字错误的问题又包含功能文字及提示文字，功能文字即对话框或弹框中的标题文字；提示文字即前端给出的文案提示；
数据错误的问题又包含列表字段错误、表单字段错误等，这种情况下可以查看前端是否参与计算，或是有无进行过字段配置管理，一般情况下可以先提交给前端；
浏览器兼容问题比较常见，如果使用了UI框架 ，则前端问题常见于框架问题。
2、功能相关
功能相关的又包含功能实现错误或不完整以及逻辑错误等。
功能问题可以通过抓包查看请求的方式来初步判断，如无请求，则初步判断为前端Bug；若抓包中有请求，则可以通过不同的状态码来判断，有请求的情况下可以初步判断为后端Bug
逻辑错误问题需要与开发人员沟通确认
3、性能相关
常见的问题如页面打开较慢，表单打开慢等，一般情况下可以通过抓包来查看请求，如果请求耗时较小，则初步断定为前端问题；否则可以结合其他信息排查为后端问题。另外，性能相关的问题出现后建议通过工具来评估整体的性能，可以进一步定位是哪个部分的问题。
二、后端问题
通常后端问题常见于业务逻辑、数据问题以及安全相关的问题与性能问题
如果前端功能实现导致后端返回的数据出错，则可以初步判断为前端问题；但如果查看后端返回的接口数据不一致或是出现报错信息，则判断为后端问题；
另外，后端问题多数可以通过查询错误日志信息来排查原因，若没有输出日志，则可能为前端问题；不存在交互的情况下更多偏向于前端问题。有些信息不会展示在前台，需要结合服务端日志信息一起排查定位了。在定位的过程中可以记录下相关SQL的问题，服务端的问题以及代码问题，以便于日后查看。
1、经验法
例如： 网页上的某个图片的分辨率不对，如果我们了解实现过程，可以想到一般情况下，是根据某个地址去服务器取图片的，数据库一般只保存地址，那么图片能正确显示，就说明后端的基本功能是满足需求的。如果具体图片分辨率有误，最可能的原因是前端显示过程出了差错。
2、查日志
当我们发现一个bug，并不确定这个bug属于前端还是后端，可以查看后端服务的日志，复现bug时，查看日志中有没有相关信息。基本可以认为，如果日志没有输出，很可能这个功能并没有与后端交互，也就不存在后端的问题。反之，如果日志有输出，可以进一步查看有无错误日志信息，进一步分析
3、查接口
这种方法常用于查看是后端返回给前端的数据有误，还是前端显示有误。 大多数浏览器都有自带的接口查看工具，如Chrome，FireFox等都可以通过F12开启抓包，在NetWork中可以看到当前页面发送的每个http请求。 我们需要对比通过后端接口拿到的数据和前端显示的数据，来确认问题出在哪里。如果数据错了，页面显示是错的，也是正常的，先从后端入手去解决。
测试用例的内容
1.用例编号（命名）
2.所属模块
3.用例标题（某人在某种情况下做了什么，得到什么结果）
4.优先级
5.前置条件
6.操作步骤
7.测试数据
8.预期结果
9.实际结果
10.辅助内容
a、通过与否
b、bugid
c、编写人员
d、编写时间
d、测试人员测试时间
e、备注
缺陷的严重程度
1.严重
2.一般
3.次要
4.轻微
缺陷报告的核心要素
1.缺陷编号
2.缺陷状态
3.缺陷标题
4.重现步骤
5.严重程度
6.优先级
7.缺陷类型
8.测试环境