当我们在测试过程中，遇到了Bug：
- 我们应检查下是否环境问题、操作问题，如是，则一般不是Bug
- 判断是前端还是后端的问题，可使用抓包工具看我们的数据传的是否有问题，如无问题则是后端问题，我们也可进行分析，查看日志
1. 分析问题场景进行预判
先查看页面表象，根据问题表像判断问题可能出现的原因，进行缩小范围，并且准备好录制工具，录制问题
系统页面无法正常访问的提示5开头的找后端，4开头的先检查请求地址或者对应的权限，进入系统页面正常打开，提示异常代码错误的直接找后端
进入系统页面展示异常图片视频相关提示Flash等相关信息进行安装Flash如若还不行找前端，界面UI展示兼容性错误找前端
如若系统访问正常，进入操作页面，功能性报错信息，就进入下面环节，抓包查看对应请求体，看日志等
2. 关注请求体的状态码
4**开头的状态码一般都是客户端（前端）的问题；例如常见的404确认下是否是请求的地址有错，403确认是否有权限访问，具体可百度
5**开头的状态码一般都是服务端（后端）问题，例如常见的500，则表示是服务器内部错误，503网络过载导致服务端延时，502服务器崩溃等，具体可百度
3.关注请求的入参与响应数据
通过访问报错的页面，加载错误请求时我们通过F12进行分析请求包，查看对应的入参以及响应数据
例如：请求入参错误，那么该bug属于前端的错误；入参标准可以根据前端页面的输入的内容或者选择的内容，进行核验，入参格式以及是否必填等可以对应接口文档去进行分析或跟开发确认
例如：请求未响应或者响应数据错误，那么该bug就属于后端的错误；一般是数据库查看报错，例如删了某个表查询报错误空指针等
如果请求的入参或者响应数据都没问题，可以跟开发反馈是不是浏览器解析的问题，可以换个浏览器测试
4. 查看日志
针对服务端类型的报错，我们可以进行登录日志平台或者服务器对应Log目录下查看打印出的日志
常用查看日志命令tail ,/error进行快速检索关键词接口名等相关内容
拿到对应的日志,将日志文件贴进bug单，指派给后端，提高专业性，测试人员也要养成看日志的习惯，看着看着就懂了
5. 经验法则
在系统前端页面当碰见服务器配置相关报错的信息例如Nginx***或者代码以及SQL相关的提示报错信息直接找后端处理，例如JAVA**** 、.PHP、SQL等异常报错前端字符校验、格式校验、等，浏览器界面UI兼容性以及插件，或者APP、小程序类调用手机相关功能拍照、语音无法正常调用直接找前端
记住以上的一些方法以及技巧减少将BUG责任人提错的概率，在提单方面整洁完整一些，长久以来，体现出你的专业性，相信开发会对你竖起大拇指
标签：定位,请求,错误,前端,报错,测试,日志,Bug,页面 From： https://www.cnblogs.com/brf-test/p/16806843.html