定位bug思路

定位问题大致思路：用户层面问题-->web页面/软件界面-->中间件-->后端服务-->代码-->数据库

————————————————

说明 1 : js是静态资源，会缓存到浏览器的客户端，为了清除缓存，需要强制刷新页面，所有的东西强制的到服务器上拿一下

说明 2 ：http状态码，服务器响应的一个状态码，标记不同的处理结果

说明 3 ：浏览器是如何同远程服务器交互的

前端页面的数据 -> js收集->js发起接口请求->服务器响应请求，返回数据->前端页面js处理数据->页面再展示出来

说明4 : 前端请求一个接口，服务器怎样处理？根据接口地址映射到对应的处理函数，函数处理完后就会返回数据

 

• js报错，直接导致前端没有发起接口请求
• 400 ： 客户端提交的参数不合格，必须提供的参数或字段没有提供
• 401 : 没有登录的情况下，访问需要登录的接口
• 403 ：没有权限
• 404： not found，js错误属于前端报错，一般是由于url地址写错，或者url地址没错，但是后面接口名和文件名改了
• 500 : 服务器内部异常
• 502 : 服务器错误，可能ngix没配置好
• 5xx均为服务器报错，直接提bug好了
• 最后一条，发现bug了，要先看看是不是自己的原因，先把案发现场保留好，然后判断前后端bug+尝试复现

————————————————————————

1.用户层面问题：用户自己的环境问题或操作问题，比如环境不通或者操作不正确。这种问题一般不是bug,如果要考虑构建更加健壮的软件，那么可以根据实际情况来决定要不要处理。

2.web页面问题：这类问题一般通过观察以及利用一些常识可发现，比如样式问题一般是css问题，交互问题一般是是js的问题，文本问题一般是HTML的问题。

3.web页面操作后，比如发出一个请求，可能会进入中间件这个层面。这里的中间件是广义上的，比如LVS、CDN、各种缓存服务器等等。

4.后端服务层：服务会转发到真正的后端服务层，WEB服务器、应用服务器比如nginx、tomcat会收到请求。如果发现内存溢出，那么就可能定位到是Tomcat配置问题；如果请求返回404，也可能是nginx配置不当。这个时候可能会遇到一些环境问题，比如测试环境没有问题，到线上就有了，很可能是环境原因，比如jdk版本不同、Tomcat版本不同、jar包版本不同等等。

5.最后一层是数据库：也可能会有代码没有问题，不代表软件没有问题。数据库层面各种问题，比如字段的约束问题等。假如一个文本框的前端校验和接口校验的文本长度是50，但数据表字段设定的是VARCHAR（30），那么在存数据的时候肯定会报错。再比如测试环境没有，到线上却有了，也可能是数据库版本不同导致的。

有的问题会直接暴露在用户面前，有些可能需要分析日志。

1.状态码查看4xx状态码一般表示客户端问题（当然也有可能是服务器端配置问题），比如401要看一下是否带了正确的身份验证信息；403看下是否有访问权限；404看下对应的URL是否真实存在。

2.5xx一般表示服务器端问题，500服务器内部错误，需要配合服务器log进行定位，502可能是服务器挂了，503可能是网络过载导致，504可能是程序执行时间过长导致。

3.看服务器日志

如果发生5xx问题，或者检查后端接口执行的sql是否正确，最常见的排查方法就是去看服务器日志，比如Tomcat日志，开发人员一般会打印出关键信息和报错信息，从而找到问题所在。

5.接口的请求和返回以及js执行是否报错。如果接口返回了200，就一定正常吗?

假设要测试一个翻页控件，翻到第二页的时候，发现内容和第一页完全一样，接口请求返回的是200，该怎么排查？

这个时候就要看前端发送的参数正不正常，后端返回的内容正不正常，即接口的请求和返回。

请求URL不正确是前端bug，传参不正确是前端bug，响应内容不正确则是后端bug，如果是响应内容不正确的后端问题，那就要继续深挖，是接口吐数据时出错还是数据库中的数据就错了，还是缓存中的数据错了（如果用到缓存的话），经常见到后端开发人员有的负责接口，有的负责写入数据库，有的负责缓存。

6.看需求文档