目前的项目大多数都是前后端分离的，当我们发现bug后不知道指派给哪位开发，指派错了不仅影响解决bug 的效率，还容易被开发怼。最主要的是人家会认为你不专业，不专，不专呀。废话少说，上干货（踩过的坑）！
测试中发现问题不要着急提bug，首先确定我们测试的这个系统是不是开发提测最新的一个版本，比如开发自己发现了这个bug，然后又提测一版，但我们还用的上一个版本。这时候把bug提上去，开发会把bug直接打过来（附带一句：这个bug已经解了，用新包。。。）。
然后排除测试环境的干扰（如：网络环境，配置项）在测试的时候我们往往开启网络代理对数据进行拦截，导致某些数据加载失败，所以确保网络环境是正常的。再比如我们在测试环境后台添加的数据，在正式环境测试，会出现数据匹配不上的问题，所以要确保环境一致。有些app要开启手机系统权限如：悬浮窗、开启消息通知、获取相机权限等，如果这些权限不开启，会出现收不到消息和系统权限，所以我们要确保这些权限是开启的。
最后，如果以上两个步骤都没问题，我们再根据测试用例、需求文档、接口文档、UE等确定功能模块，开开心心的提bug了。这时候就要展示你的神通了，该用的工具全部用上如：fiddler，浏览器的开发者模式，wireshark，linux命令，SQL语句等，努力复现出现bug的步骤。总结如下：
1、通过抓包或者开发者模式过滤信息定位bug
a、传入参数错误（缺参、错参等），导致的问题往往是前端bug；
b、传入的参数与接口文档一致，数据返回正确，界面显示错误（字段取错），往往是前端的bug；
c、传入参数正确，数据返回错误，往往是后端的bug。
d、根据响应状态码：404客户端请求路径错误，500服务器内部错误
2、根据前后端的bug特点来定位问题
a、前端bug特点：界面相关（文本问题可能是html产生的bug）、布局相关（样式问题可能是css产生的bug，图片尺寸分辨率等）、兼容性相关
b、后端bug特点：业务逻辑相关（排序、分页）、数据相关、性能相关、安全性相关。
3、查询系统日志
如果查不到错误日志前端的问题概率大，反之后台的问题。
4、通过sql语句查询数据，是否有数据入库。
有些项目接口与接口之间存在相互调用，不同的接口是不同的开发人员负责，我们可以通过查询数据的方式来区分哪个接口问题。比如：在A模块添加一条数据，但是在B模块没有展示，这时我们 通过查询数据库的数据来确认，是A模块没有插入数据，还是B模块没有查询到数据来缩小问题的范围。
5、根据测试经验确定谁的bug
软件测试人员应不断精进自己的技能，负责的项目多了，自然对功能的实现过程有了解，也就明白如何分类BUG了。再就是与开发人员多沟通，熟悉业务，每个模块是哪个开发负责的。
总之，要对自己发现的问题负责，确保每一个bug都能被开发人员理解和修改。学无止境，我们不要怕踩坑，踩过的坑再踩才很可怕。
