大家好，我是小谭。
判断一个bug是前端问题还是后端问题，是一道非常经典的面试题，很多小伙伴在这道题上栽过跟头。
为什么经典？是因为有经验的面试官，能从这一道题中洞悉面试者的技术水平（抓包、Linux、代码、数据库、环境等等）和他在项目中扮演的角色（细节cover能力、主人翁意识、闭环意识等等）。
那么，日常工作中，该如何判断一个bug是前端问题还是后端问题？
首先，可以抓包，做一些简单的判断。
比如Web程序，可以用F12直接查看请求和响应数据；App程序，可以用Fiddler、Charles、mitmproxy、anyproxy等工具抓包；PC桌面应用，可以复用App的抓包工具，只不过得多走一次代理，使用像Proxifier这类的代理工具。
对于新手来说，前后端bug的判断，可以以接口文档作为区分标准。发现问题后，根据接口文档核对实际接口的请求值和响应值：
- 如果请求值有误，可简单判断为前端问题
- 如果响应值有误，可简单判断为后端问题
- 如果请求值和响应值都没有问题，可简单判断为前端问题
然后分成两条路，一条是前端bug定位，一条是后端bug定位。比如资源获取失败、机型和浏览器兼容、undefined、精度等问题，是Web端比较常见的问题；而崩溃、防重、误操作、交互切换等问题，是App和PC端比较常见的问题。
此外，在大型公司，会有专门的前端和UI团队，去维护前端需要的组件项目库（如下图，一个日期选择框组件），也会有专门测前端组件的测试人员，这种分工会降低前端问题产生的几率，减少不同团队解决同类前端问题的频次。
针对后端bug而言，下一步，你需要到服务器上查请求日志，继续溯源。可以用tail、cat、grep等命令查日志，也可以在服务器单独发起请求——使用curl命令，去调http接口；使用invoke命令，去调dubbo接口，使用trace语句，跟跟服务链路的调用。
此外，你还得花时间梳理系统的架构设计，特别是后端服务之间的调用链路。按照现在常见的系统架构，一个项目中，ABCD……N个系统是各自独立的，再通过配置中心、中间件、网关路由、接口等关联起来。理解系统之前的调用关系，你才能定位到bug的具体范围。然后发现，很多时候，除了自身系统的bug，还经常会发现兄弟系统的bug。
对于自身系统，按照现在常见的后端设计，就一个路径：网页发起请求，请求到达后端，先到Controller层，再由Service处理逻辑，Dao层组装数据。
好多人可能不太理解这三层，我找了个网上的说明，补充了点内容，就能够很好理解了：
- 顾客来到餐厅点餐（在页面操作，向后端发起请求）
- Controller是服务员，顾客点什么菜（发起的哪个接口请求），菜上给几号桌（走到后端的哪个逻辑），都是ta的职责；
- Service是厨师，菜单上的菜全是ta做的（业务逻辑处理，比如求a+b的和）；
- Dao是厨房的小工，和原材料打交道的事情全是ta管（数据的增删查改，比如取a=1，b=2）。
只不过，在这条路径中，你还得搭配着中间件、进程、线程、IO、网络、数据库等知识，因此，才会让bug定位变得更复杂。
总的来说，照此思路，你去实操几次，就能掌握简单的bug定位，满足日常测试的需求。
如果你读完这篇文章，觉得哪哪都陌生，我建议你列个清单出来，在当前的情况下，缺啥，就补啥，去网上找资料挨个做专项，掌握它们；如果找不到，就做一个todo-list，在实际工作中，请开发喝喝奶茶吃吃饭，打好关系，让他教教你，比你自己瞎捉摸管用得多。
实际工作中，请开发喝喝奶茶吃吃饭，打好关系，让他教教你，比你自己瞎捉摸管用得多。
