第一种思路:
首先,作为开发也好,测试也好,定位问题有一个总的思路,而这个思路是和数据的走向一致的。大致是这样:
用户层面问题 -> Web页面/软件界面 -> 中间件 -> 后端服务 -> 代码 -> 数据库
以下都以Web页面举例说明。
(1)用户层面问题:
指的是用户自己的环境问题或者操作问题,比如环境不通,或者操作不正确。
这种问题一般不是bug,当然,如果要考虑构建更加健壮的软件,那么可以根据实际情况来决定要不要处理这类问题。
(2)Web端软件界面:
用户在Web页面进行正常操作时,也可能会发现问题。
比如样式问题一般是css的问题,交互问题一般是js的问题,文本问题一般是html的问题(当然有可能是其他问题,例如js生成html)。
(3)中间件:
Web页面操作后,比如发出一个请求,可能会进入中间件这个层面。
我这里说的中间件是广义上的,比如LVS、CDN、各种缓存服务器等等。
我们遇到过一个问题,发现刚刚上传的图片进行读取展示时就读不到,那么可以想到可能是负载均衡时将上传照片和读取照片两个请求分配到了不同的服务器导致的,也就是我们常说的会话保持。
当然,中间件问题有时候是和开发相关的,有时候是公司其他团队负责的,比如360公司就是OPS在负责。当然,中间件也不仅仅会出现在这一步,实际的项目中可能还会用到更多的基础设施,比如消息中间件、数据存取中间件等,如果发现了相应的问题也就需要有对应的思路去排查。
(4)后端服务:
服务会转发到我们真正的后端服务层,web服务器、应用服务器比如nginx、tomcat会收到请求。
如果发现内存溢出,那么就可能会定位到是tomcat配置的问题;
如果请求返回404,也可能是nginx配置不当。
当然,这个时候可能会遇到一些环境问题,比如测试环境没有的问题,到线上就有了,很可能是环境原因,比如jdk版本不同、tomcat版本不同、jar包版本不同等等。
(5)数据库
最后一层是数据库。代码没有问题,不代表软件没有问题。数据库层面也可能会有各种各样的问题,比如字段的约束问题等等。假如一个文本框的前端校验和接口校验的文本长度最大是50,但数据表字段设定的是varchar(30),那么在存数据的时候肯定会报错。再比如之前发现一个数据库的问题,测试环境没有,到线上却有了,那么也可以看下是不是数据库版本不同导致的。
上面我们说的是问题定位的一个大致思路。每一个环节都有可能出现bug,既可能是response的问题,也可能是前端回调处理的问题。有的问题可能会直接暴漏在用户面前,有些则可能需要我们去分析日志。
当然,很多时候我们不需要这样一层一层去定位,经验丰富的开发或者测试根据现象可能马上能定位到究竟哪里出了问题。
第二种思路:
1、前端出现的问题:
页面的展示和渲染:元素的位置、间距、颜色、按钮
页面上发起的行为:点击、输入、长按、鼠标行为、提示方式、输入框、选择框等
以上问题:定位到前端开发—UI开发工程师
2、后端出现的问题:
接口:数据处理
功能:支付、登录、加购物车、定投基金
5开头的状态码:一定是服务端的问题
4开头的状态码:和接口文档对比:一致:服务端的问题;不一致:客户端的问题;
3、安卓/ios
客户端闪退;
发现BUG的页面是不是H5页面