• 判断前端和后端bug,赶紧来扫个盲!


    大家好,我是小谭。

    判断一个bug是前端问题还是后端问题,是一道非常经典的面试题,很多小伙伴在这道题上栽过跟头。

    为什么经典?是因为有经验的面试官,能从这一道题中洞悉面试者的技术水平(抓包、Linux、代码、数据库、环境等等)和他在项目中扮演的角色(细节cover能力、主人翁意识、闭环意识等等)。

    那么,日常工作中,该如何判断一个bug是前端问题还是后端问题?

    首先,可以抓包,做一些简单的判断。

    比如Web程序,可以用F12直接查看请求和响应数据;App程序,可以用Fiddler、Charles、mitmproxy、anyproxy等工具抓包;PC桌面应用,可以复用App的抓包工具,只不过得多走一次代理,使用像Proxifier这类的代理工具。

    对于新手来说,前后端bug的判断,可以以接口文档作为区分标准。发现问题后,根据接口文档核对实际接口的请求值和响应值:

    • 如果请求值有误,可简单判断为前端问题
    • 如果响应值有误,可简单判断为后端问题
    • 如果请求值和响应值都没有问题,可简单判断为前端问题

    然后分成两条路,一条是前端bug定位,一条是后端bug定位。比如资源获取失败、机型和浏览器兼容、undefined、精度等问题,是Web端比较常见的问题;而崩溃、防重、误操作、交互切换等问题,是App和PC端比较常见的问题。

    此外,在大型公司,会有专门的前端和UI团队,去维护前端需要的组件项目库(如下图,一个日期选择框组件),也会有专门测前端组件的测试人员,这种分工会降低前端问题产生的几率,减少不同团队解决同类前端问题的频次。

    image-20220624163027019

    针对后端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,在实际工作中,请开发喝喝奶茶吃吃饭,打好关系,让他教教你,比你自己瞎捉摸管用得多。

    实际工作中,请开发喝喝奶茶吃吃饭,打好关系,让他教教你,比你自己瞎捉摸管用得多。

  • 相关阅读:
    LeetCode #83. 删除排序链表中的重复元素
    蓝桥杯练习题——多路并归
    一篇文章带你用动态规划解决打家劫舍问题
    高等数学--微分方程的求解(sympy库)
    GBase8s jdbc连接超时参数说明
    KGAT推荐系统
    【JS】常用数组方法
    跑步耳机哪种好,推荐五款在运动中值得佩戴的耳机推荐
    04 后端增删改查【小白入门SpringBoot + Vue3】
    docker的基础使用步骤
  • 原文地址:https://blog.csdn.net/wukonginsight/article/details/125626334