佬们，就是发现一个 bug 如何分辨是前端 bug 还是后端 bug 呀，新人不是很会分辨
每次录 bug 指给开发都胆颤心惊的
新手还在分辨，老手已经随便 开 了 他们自己会转 的哈哈哈哈
直接指给 CTO，你管他前端后端的呢
哈哈哈 我刚开始也是 你可以 F12 看看前端 和后端参数哪里不对
我一般 F12 控制台 - 有接口报错给后端；console 有报错找前端，报错但没有接口也找前端。或者处好开发测试间关系，问就行了。
web 端的话，可以看接口。如果接口请求正确，响应数据不正确，就是后端的 bug；如果接口请求错误，或者是 UI 显示问题，就是前端 bug。
企微建了个共享文档，解决人那列空着，他们会自己认领和互相 @ 的，还是需要和开发保持着良好关系，有疑问直接问就好了，大概是控制台报错以及页面显示错误找前端，接口报错或数据返回错误找后端
F12 看请求，有些可能是前端没给后端传参，有的可能是后端没给前端返回，，还有就是后端接口直接报错。具体还得凭借经验判断
基本就是 4 楼说的一样，也要看看接口传参，有些明显错误也能分辨出来，要是实在不知道怎么分辨了，就随便指一个，或者两个人都带上
期待一手小黑子的回复
之前有个贴，讨论过
https://testerhome.com/topics/31857
如果模块就是你负责，其实你正常测试设计的时候是会去了解开发的实现逻辑的，基本看着设计文档也会知道是前端还是后端负责。如果你只是执行，直接提给你们小组的 TL，他会去转的。不过一般和开发关系好，爱咋提咋提，培养其实也很简单，自己负责开发的模块这么多 bug，开发对测试一般都是比较感激的，还是比较好培养的。
小公鸡点到谁就选谁，
直接指给对应小组的开发组长啊，自行分配
看接口文档判断吧，如果没文档就全部给前端，鬼知道他是前端传错参数，还是后端逻辑错误呢
实在区分不出来就指给前端，前端是 BUG 路由器，他自己会转发的
没人带你吗 问下带你组长呀
同时给两个端的组长就好，内部消化。同事之间应该挺好相处
这个只能是实际情况实际分析了。你的业务模式跟技术实现方式很大程度上会导致结果的偏差。
从技术手段上来说如果你是网页端跟 APP 的话，区分前后端的 Bug 有个很直接的方法：自己 mock 一个正确的接口返回。（前端如果参数穿错的话应该是能够很直接的看出来）
从流程上来说，你发现的所有 Bug 第一优先提交给前端开发，如果不是直接对接人的问题是会自己转交给下游的。
从个人提升的角度上来说的话，我会劝你深入的了解前后端的技术实现逻辑，架构设计，数据流转等等。
F12 解君愁
业务上，尽量多提升自己的能力和经验，能力到位了，就能判断出来了。工作中，可以跟开发好好沟通一下，说初来乍到，有时候 bug 指错人了，就麻烦转给对应的开发，并且评论一下，bug 是什么原因。你的本职是找出 bug，只要你测试之后线上事故锐减，甚至测试能力确实很强，开发也会认可的。bug 指错人不是问题，找不出 bug 才是问题
想起 22 年实习的我也是这样，很怕提 bug 分配错人，不过部门开发都挺好的
首先要理解前后端的分工，一般情况下，前端只负责展示，没有业务逻辑处理。前端的数据来源是后端，此时你只要确认后端传给前端的接口返回数据是否和预期的一致即可，方法 1：web 端 F12 看接口返回的字段，移动端可以使用抓包工具，如 Fiddler。
跟后端大佬搞好关系，不能确定的就派给他，让他来定位一下，然后分配。
可以学习一下，他是怎么定位的，最常用的就是看日志
具体业务具体分析，但是可以试一下这样做，1.如果是很直观的页面没展示全/字体重叠这种样式 bug，大概率是前端问题，如前楼回复，前端主要负责展示。2.如果拿不定，那么谨记遇到 bug 先抓包，使用 charles 或同款抓包工具，找到对应的接口之后，看传参和返回。3.确认传参是否正确，有没有格式问题，可以找前端同学确认一下。4。看返回的数据是否符合预期，如果返回体很简单无法区分，如只有一个 success，就看能不能登录服务看日志进一步排查，有可能业务代码不对，有可能 redis 和 mysql 之类的问题等等，有可能发出去的消息没有被消费等等，总之如果想排查，就有很多方向排查，要看具体问题。5.以上是大概得怎么做，长久来看还是要梳理业务逻辑和技术实现，这样等下次遇到了，就知道 ‘大概是这里有问题’。6.等到和开发关系很熟了这一步之后，其实都很随意了
7.如果项目很紧急，可以先和开发说一下先指派给他，如果不对再转回给你，这样你就转给另一个人
你直接当面找其中一个现场问，是不是他的问题。这样有好处，你不是怕指错吗，这样可以迅速拉近你和开发的距离，如果不是他的问题，他还可能带你去找另外一个人。相对于盲指，这样做不会引起对方的反感。