定位问题大致思路：用户层面问题-->web页面/软件界面-->中间件-->后端服务-->代码-->数据库
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.看需求文档