精华内容
下载资源
问答
  • 如何区分前端BUG和后端BUG 1、如何区分前端和后端 通俗讲,用户看到的部分都叫前端。 而用户看不到的部分可以统称为后端。 2、前端和后端的呈现形式 前端的呈现形式有web端、移动端(ios、安卓)、小程序等。 后端...

    如何区分前端BUG和后端BUG

    1、如何区分前端和后端

    通俗讲,用户看到的部分都叫前端。
    而用户看不到的部分可以统称为后端。

    2、前端和后端的呈现形式

    前端的呈现形式有web端、移动端(ios、安卓)、小程序等。
    后端系统一般只有一个,收集不同前端反馈回来的数据。

    3、前端和后端工作内容的差别

    前端主要是考虑怎样能让用户觉得用起来更舒服,考虑界面布局、交互效果、页面加载速度等。
    后端更多的是与数据库进行交互以处理相应的业务逻辑。需要考虑的是如何实现功能、数据的存取、平台的稳定性与性能等。

    4、如何分析bug(bug类型)

    当bug出现时,一般来说分大致3种情况:
    (1)数据库层面的:
    可能少某个字段,或者字段值为空等等,这些可能在设计数据库时就埋下了错误的种子,导致程序调用数据库错误的数据产生bug,这一类问题不算普遍,但也是最容易忽视的一种情况,有时候从数据库入手定位bug说不定还能发现数据库的设计缺陷。
    (2)网络层面的:
    通常这种都是网络情况较差的时候产生的,比如手机的移动网络信号不好,又或是公司网络不稳定,导致js/css未加载完全或者请求超时等等,这种问题其实非程序bug造成的,可以不用提交bug,也不用让开发毫无头绪的去查代码的问题。当然如果可以的话也可以当优化建议提给开发,让他优化代码,比如压缩js/css,增加超时时间,超时后的重试机制。
    (3)代码层面的:
    普遍的bug基本都是代码有问题造成的,排除掉1和2剩下后就可以确定是程序bug了。对于了解网络架构的人来说,其实程序也分前端和后端的,一般对于界面显示有问题直接可以判断是前端的问题,比如系统兼容性,浏览器兼容性。
    而对于数据或者逻辑上的问题,则需要(检查接口)前端和后台之间是通过接口文件相互联系的,通过抓包工具来进行分析 :
    1)请求未返回数据,可能是client(客户端)请求数据错误,可能是server端(服务器端)处理错误。
    2)请求返回错误的数据,那就是server端处理错误。

    5、如何区分前端问题和后端问题

    前台的bug通常是功能、界面和兼容性等有关;
    后台的bug与逻辑、性能和安全性有关。
    与数据相关的错误、排序问题大多是后台问题;
    对于APP页面toast提示可能是后台给的,可能是APP给的。
    (1)检查接口
    前端和后台之间是通过接口文件相互联系的,测试人员可以通过查看接口文件,来区分前端和后台bug。
    (2)情况分析
    a、检查请求的数据是什么?反馈的数据又是什么?
    通过抓包工具来进行抓包分析。
    大多数的浏览器都有自带的抓包插件,如 FireFox 的 FireBug 插件,Chrome、360急速模式、搜狗高速模式自带的 DevelopTools 插件(F12开启),在 NetWork 中可以看到当前页面发送的每一个http请求。请求接口、传参、响应三部分来判断Bug,另外,也可以在浏览器的控制台进行js代码调试定位。
    1)请求接口URL是否正确
    如果请求接口URL不正确,为前端Bug;
    2)http请求中的参数是否正确
    如果http请求中的参数不正确,为前端Bug;
    3)如果接口URL和参数都正确,查看响应内容是否正确
    如果这种情况下响应内容不正确,则为后端Bug。
    4)如果JS基础比较好的话,也可以在浏览器的控制台中输入JS代码进行调试。
    b、根据接口的文件,检查数据是否正确。
    如果发送的数据是正确的,但是后台反馈的数据是不符合需求的,那就是后台的问题。
    如果前端没有请求接口,或者请求的时候发送数据与需求不符,那这个时候就是前端的问题了。

    6、如何精准的定位前台bug并且描述bug?

    (1)按F12在 console(控制台)中查看报错信息,对于出错的 js 可以在 Sources 下查看对应报错的资源文件,截图放入bug单,bug定位策略:

    1)网站前台的权限控制:没有权限的用户是不能直接输入url的方式来进行访问的,必须进行登录。涉及到权限的测试,一定不能漏掉url的方式也需要验证一下。而在单个页面进行W3C测试时则需要去掉该权限控制。
    2)网站前台的title,对于这个也很容易忽视。进入到不同的功能页面,title显示应该是有,并且要和你进入的页面一致。title就是在浏览器最左上角看到的那些文字
    3)http和https的注意点:https是一种安全链接,它是需要证书的,而http就是普通链接,所以在你的系统中客户会要求某些关键的地方加上这种安全连接,那么此时你需要注意的是,对于不需要安全链接的地方也要去重点测试,有些开发会很容易忽略这一点。要打开HTTPS开头的网站,前提是该网站安装了SSL证书,只有安装了SSL证书的网站,并且开启了 443 端口,你才可以通过HTTPS加密协议无访问。如果没有则不能访问。

    (2)前端bug主要分为3个类别:HTML,CSS,Javascript 三类问题:

    一)出现文本的问题基本都是html的bug
    二)出现样式的问题基本都是CSS的bug
    三)出现交互类的问题基本都是Javascript的bug

    一)HTML

    最常见的HTML的问题—就是标签的问题了,最常见的排查和解决办法就是查看页面源代码,然后通过检查标签的工具,现在暂时提供 idea.exe 进行检查,有其他更好的工具再进行推荐。
    常见问题类别:
    1.标签闭合—>>> 表象,页面中出现大范围的混乱,就是少了标签的情况,导致标签未闭合。
    2.标签浮出—>>> 例如鼠标移动到文本位置,浮出全名的这种浮出形式都属于标签浮出的问题。
    3.标签在不同的浏览器的一种解析方式的不同导致的前端bug,例如如下结构:
    该部分可以看做为一个大的框即是标签 内嵌标题的标签

    ,里面再有这些个内容,那么在不同的浏览器中,可能ie和FF的解析会产生不同,假设IE解析为

    的一种形式,但在FF下可能解析为

    的两行的形式从而导致前端在 ing 里面的格式产生混乱。 4.页面定点的问题->>> 最明显的前端功能,在于点击某个链接将页面位置定位到对应的位置。 我们可以通过右键,查看元素的工具进行定位到毛点所定位到的位置,如果出现问题这种问题很直观,并且能通过这种方法直接定位到问题。 5.页面的跳转,也属于html的问题,大家在出现点击未跳转或者跳转方式不正确的问题,直接可以定位到跳转属性的问题,找到对应的跳转对应的块提供给开发人员即可。

    二)CSS,产生样式问题。

    例如:排版,布局,颜色,背景等,分:

    1.兼容型bug
    a) 表现:仅在少数几个浏览器上出现
    b) 原因:浏览器的解析不一致
    c) 解决:根据实际情况进行前端代码的通用性
    d) 类别:
    脚本兼容型bug:在出现对应交互的问题就基本可以定位到脚本兼容型bug,例如 DIV 的显示和层结构。实际可以参考聚划算的几个商品鼠标移动到小图的时候,对应大图展示的功能。
    页面样式兼容型bug:直接表象在样式上,都是基于框架的页面展示错误,很容易定位
    2.业务性bug
    a) 表现:在所有浏览器下都有该问题
    b) 原因:对业务不熟悉
    c) 解决:根据需求进行修改达到业务要求
    d) 总结:该类型的定位,主要在和实现的要求不一致,最直接表现在页面的友好型,用户的可用性的bug,可以定位为该类型
    3.内容型bug
    a) 表现:前端自测正确,但在填入内容后,出现的错误,内容消失等
    b) 原因:扩展性未考虑周全
    c) 解决:进行overflow test
    d) 总结:输入内容的长度限制等功能可定位为内容型bug

    三)Javascript

    a) 最直接的判断方法,刷新页面,出现滞后显示的一些模块基本都为脚本的输出块。该部分的一些问题可以参照兼容型 bug 中类别的 脚本兼容型bug。
    b) 有产生交互类的问题,大多数都可以定位到是属于javascript产生的问题,该部分大多不会报错
    c) 有如下错误提示类的都属于javascript的bug:
    页面左下方有出现javascript的错误提示;
    有弹出错误信息提示的bug;
    浏览器返回的一些错误弹出框。

    7、如何精准的定位后端bug并且描述bug?

    (1)根据后台日志文件定位:
    1)查看报错日志
    查看报错日志,通过日志分析,有利于帮助开发更好地定位问题,初期 bug单 可以携带日志一起发送指给开发。
    2)查看数据库的数据
    了解所测功能的数据表结构,测试过程中,查看数据库的数据,确认数据的正确性。
    3)查看缓存(如 Memcache、apc、redis 等缓存)是否正确

    (2)后端部署在liunx系统使用secureCRT进行日志获取,常见问题分类:
    1)编码问题:tomcat是新的,需要改编码 修改tomcat的server.xml文件,特别是windows下的项目重新部署到linux系统下。
    2)空指针:程序问题,一般没有考虑到为空情况,或者主外键约束的数据为空,或者删除关联数据,导致为空。
    3)长度过长:超过最大长度,测试环境修改数据库字段长度后生产环境未修改,导致报错。
    4)非法数据:特殊字符,是否对特殊字符进行容错处理。
    5)内存溢出:重启。
    重启的一般情况:
    1)热部署 (新增部分功能,或者修改部分bug)
    2)发布新版本 (整个系统)
    3)内存溢出,此时重启服务器即可
    4)由于项目中有线程程序,./shutdown脚本关闭tomcat程序,不能把启动的线程全部关闭,造成服务器启动线程未关闭的错误。
      Linux系统中重启Tomcat的一般步骤:(一般是先关闭进程,然后进行重启 ,如果 /要删除某个文件:rm 文件名,或者不为空的文件夹:rm -rf 文件夹名)
      cd usr/local/ //测试服务器名称/bin
      ps -exf //看测试服务器下运行的项目的主进程(最前面的数字为PID进程号)
      kill -9 PID //强制关闭某一项目的主进程
      ./startup.sh // ./**.sh 即执行重启shell脚本文件 ,此时在测试服务器的bin下面,直接执行即可,其余的加上 chmod a+x shell脚本文件,也可用./执行
      ps aux 和 ps -ef命令区别:
      ps aux 是用BSD的格式来显示java这个进程
      显示的项目有:USER,PID,%CPU,%MEM,VSZ,RSS,TTY,STAT,START,TIME,COMMAND
      ps -ef 是用标准的格式显示java这个进程
      显示的项目有:UID,PID,PPID,C,STIME,TTY,TIME,CMD

    (3)一般的问题原因总结:
      1)程序:为空判断,增删改查,不同公众号调用的接口也不一样
      2)数据初始化:数据库表结构和数据初始化,权限配置,特别注意生产环境上的用户数据修改,此时用户在使用,很重要!!!
      3)故障无法重现时:
      a)看日志,根据日志定位原因,则在测试环境中按照日志提示构造条件相同的测试案例测试,尝试在测试环境中将问题重现。
      b)测试环境和配置与实际的工程环境和配置有哪些差异等等。同时主动与开发负责人、工程实施人员以及有经验的项目经理讨论,分析可能导致的原因。
       c)测试环境ok,生产环境新增时保存失败,查看后台日志报长度溢出,数据库内容字段要求和生产环境不一致。

    (4)如何查看日志(tail -f)?
    一台服务器可以部署多个应用:
      cd usr/local/测试服务器名称/logs//查看先进入到服务器的logs目录下
      tail -f catalina.out//监视catalina.out 文件的尾部内容(默认10行)

    (5)辅助工具:linux和SQL
     linux查看日志
     SQL用来筛选数据或直接进行数据修改状态,多用于集成测试过程中前后流程相连接

    8、浏览器兼容性和网页规范标准测试

    浏览器兼容性测试(偏主流浏览器,如谷歌,火狐,IE8以上):
    https://dev.windows.com/en-us/microsoft-edge/tools/staticscan/
    W3C网页验证:(判断网页书写是否符合规范,记住此处必须去掉权限控制,单个单元页面url需要跟参数)
    https://validator.w3.org/
      W3C手机端页面检测(如手机微信菜单下的页面):
    https://validator.w3.org/mobile-alpha/

    9、互联网与传统测试互联网测试与传统测试的区别

    (1)最大的不同:互联网产品需要自己部署和运营,用户使用瘦客户端(浏览器,app或一个需要安装的client),核心的数据和业务逻辑在互联网公司的机房,在IDC,在云端。
    如:我们做的系统用户只需一个浏览器,服务器用的阿里云,部署和运营只需要一个运维人员即可。
     考虑现网(生产环境)存在下面两个问题:
      1)如何发布功能到现网?
      互联网测试完一般可直接发布,测试周期短,有时候需要进行灰度发布,先让部分用户用起来,发布完做生产验证。
      2)如何保证测试环境和生产环境同步?
      测试环境比较难搞,牵扯的系统平台比较多,用到很多微信平台的接口,这个很难自己搭建或者用mock。
    另外保证测试环境和到生产环境都是好的,需要代码和数据库,以及环境配置都要保持一致,这需要相应的机制和工具来验证和同步。

    (2)互联网产品节奏很快
      有的软件公司,基本是进行二次开发,周期长,每次都需要经过下面几个完整的测试流程:
      客户提出需求>>>BA和客户沟通,确定出需求和解决方案>>>测试人员根据需求说明书和解决方案编写测试用例>>>进行概要评审>>>进行详细设计评审>>>开始测试>>>回归测试>>>生产验证。
      现在的互联网产品测试基本为:
      产品经理确定好测试需求>>>开发人员写详设>>>(此阶段可以进行设计bug检查)>>>开发人员开发>>>测试人员测试,上线
      弊端:来不及测试设计,来不及自动化,短时间内如何保证测试的覆盖率和质量?>>>(探索式测试应势而生)

    (3)更多的人参与到测试中
      互联网公司有专门的测试团队的比较少,一般开发和测试比例:7:1,如何保证质量?
      1)开发人员的自测
      开发人员进行单元测试,测试用例的通过率,同一个版本拉代码的次数
      2)产品或运营人员的体验
      在这里基本我就相当于用户,进行产品体验,或者根据免费试用者反馈的意见进行优化
      3)发布之前的评审
      注意环境,配置,数据方面的问题

    (4)有一些是免测试的
      并不是所有发布到生产环境的东西都需要在测试环境检验,如:图片样式改动,小bug修复,但是哪些免测是个复杂的问题

    (5)海量用户带来的挑战
      1)性能方面
      如何做轻量级的性能测试
      2)浏览器的兼容性
      现在的系统大多基于主流的火狐,谷歌,IE8以上,放弃浏览器兼容就等于放弃一部分客户。

    (6)测试工具和技术方面
      传统的企业花钱购买商业软件,如QTP,loadrunner,或者自己开发的项目管理工具
      大部分的互联网公司使用开源或自主研发的,如 selenium,appium,robotium,monkeyrunner,jmeter
      相同点:
      1.都需要非常熟悉产品和业务
      2.都需要了解产品的技术(深度测试方面性能分析,内存泄露,web服务器,cache,代理)
      3.具体的测试技术
      4.测试设计的方法
      5.测试人员的技术体系

    展开全文
  • 怎么区分前/后端bug? 举个栗子,按以下步骤操作: 打开浏览器,输入url:https://www.jianshu.com/sessionst,打开了简书的登录页 不输入账号密码直接点击登录。 系统提示“手机号码/邮箱地址或密码不能为空...

    怎么区分前/后端bug?

    举个栗子,按以下步骤操作:

    1. 打开浏览器,输入url:https://www.jianshu.com/sessionst,打开了简书的登录页

    2. 不输入账号密码直接点击登录。

    3. 系统提示“手机号码/邮箱地址或密码不能为空”。
      请思考一下这里的提示信息是前端返回给我们的还是后台返回给我们的?
      答案:前端。因为啥也没输入,根本没有必要发给后端来做校验,直接在前端就可以给校验不通过了。

    4. 账号输入13333333333,密码输入123456。点登陆,弹出提示信息如下图.
      思考一下这个地方的信息是前端还是后端返回给我们的?

    答案:后端。因为前端也不知道咱数据库里有啥账号啊。

    所以总结起来,B/S架构的登录功能数据交互过程是这样滴:
    ① 数据进来之后,先在前端进行数据合法性校验。
    ② 只有前端数据合法性校验通过后,才会将数据发送到服务器进行处理(后端服务)。
    ③ 前端合法性校验通过后,还会在后端进行一次数据合法性校验。以防不法分子绕过前端(比如使用发包工具)直接访问后台。
    ④ 如果后端数据合法性校验通过,才会查询数据库:

    • 如果账号不存在,返回给前端“手机号/邮箱/密码不正确巴拉巴拉”
    • 如果账号存在,则开始进行密码匹配,如果密码不匹配,也会返回一个“手机号/邮箱/密码不正确巴拉巴拉”
    • 如果密码匹配,则返回登录成功。
      ⑤然后信息从后台返回到前端,前端收到信息后进行数据展示。如果是登录成功,则跳转到首页。

    所以判断一个bug属于前端问题还是后端问题,按上面的思路走一圈就差不多可以分析出来了。


    软件测试工程师一只,也在不断的学习阶段,平时的小经验不定期分享。
    博主经验有限,若有不足,欢迎交流,共同改进~
    有意可加Q群 908417285 交流学习。
    乾坤未定,你我皆是黑马
    
    展开全文
  • 如何快速定位bug是前端还是后端呢?对于一个优秀的测试工程师来说,区分bug属于前端还是后端是尤为重要的。 一个页面的请求过程: 弄清楚如何定位和分类bug之前,需要了解一个页面的请求过程,以http请求为例: 1、...

    如何快速定位bug是前端还是后端呢?

    45cadf4a1599a621f673da766e8fa35a.png

    对于一个优秀的测试工程师来说,区分bug属于前端还是后端是尤为重要的。

    ebad05d97fe568f6a72a2ef653aeca34.png

    一个页面的请求过程:

    598e868a4617265e081fed0375be14bb.png

    弄清楚如何定位和分类bug之前,需要了解一个页面的请求过程,以http请求为例: 1、用户在前端页面操作,如点击某个提交按钮 2、页面携带数据进行请求,访问具体功能接口 3、由后端服务执行相应的业务逻辑,如涉及数据,再去请求并组装数据返给前端 4、前端页面进行渲染和展示对应的页面和数据 前后端bug各有什么特点?

    前端bug特点 1, 界面相关 2,布局相关 3,兼容性相关

    后端bug特点 1,业务逻辑相关 2,性能相关 3,数据相关 4,安全性相关

    定位前后端bug,有什么方法? 1、经验法 软件测试人员应不断精进自己的技能,负责的项目多了,自然对功能的实现过程有了解,也就明白如何分类bug了。 例如: 网页上的某个图片的分辨率不对,如果我们了解实现过程,可以想到一般情况下,是根据某个地址去服务器取图片的,数据库一般只保存地址,那么图片能正确显示,就说明后端的基本功能是满足需求的。如果具体图片分辨率有误,最可能的原因是前端显示过程出了差错。

    adc64dc4bc0bd9bc409fcdb7349cd600.png

    2、查日志 当我们发现一个bug,并不确定这个bug属于前端还是后端,可以查看后端服务的日志,复现bug时,查看日志中有没有相关信息。基本可以认为,如果日志没有输出,很可能这个功能并没有与后端交互,也就不存在后端的问题。反之,如果日志有输出,可以进一步查看有无错误日志信息,进一步分析。

    e8523360966db0b9fa475714370d8f2a.png

    3、查接口 这种方法常用于查看是后端返回给前端的数据有误,还是前端显示有误。 大多数浏览器都有自带的接口查看工具,如Chrome,FireFox等都可以通过F12开启抓包,在NetWork中可以看到当前页面发送的每个http请求。 我们需要对比通过后端接口拿到的数据和前端显示的数据,来确认问题出在哪里。如果数据错了,页面显示是错的,也是正常的,先从后端入手去解决。如果数据对了,但是显示错了,就需要问问前端的开发人员了。 沟通很重要 我们在定位BUG的过程中,最不能忽略的一个问题是和开发人员的沟通,有时候忙活半天,不如一问一答。经验和技术的成长也都离不开合理高效的沟通。 经验和小结 出现样式的问题基本都是CSS的BUG 出现文本的问题基本上都是html的BUG 出现交互类的问题基本上都是Javascript的BUG 其他问题先沟通,再定位

    116abd50a152f9121c44c448ba358111.png
    展开全文
  • 如何区分前端bug还是后端bug

    千次阅读 2020-11-02 18:12:58
    软件测试工程师的职责是发现BUG,此外,如何体现个人价值?那么我们试想,只提出问题而不去解决,问题就永远得不到闭环。所以,一个资深的测试人员的基本功应该是这样的:深挖业务和功能需求,找出BUG,定位BUG,...

    软件测试工程师的职责是发现BUG,此外,如何体现个人价值?那么我们试想,只提出问题而不去解决,问题就永远得不到闭环。所以,一个资深的测试人员的基本功应该是这样的:深挖业务和功能需求,找出BUG,定位BUG,提出解决方案。这里我们就来说说,当我们找到了BUG,应该把BUG提交给谁去解决,这属于BUG定位的问题。
    试想:
    根据需求,用户头像应是圆形,但结果是方形,是谁的BUG?
    保存用户信息时,无法保存成功,也没有错误提示,最可能是谁的BUG?
    显然,工作过程中,我们不可能把这些BUG提交给同一个人去解决。我们应该至少区分出是前端还是后端BUG,就好像时下流行的词“垃圾分类”,经过BUG分类处理,整个团队的效率都会有所提高。
    一.什么是前端/后端?
    目前多数互联网项目都是前后端分离开发的,那么什么是前端?什么是后端?简言之,前端侧重于页面设计,后端侧重于服务开发。
    比如要保存一个用户信息,前端把界面显示给用户,让用户按需填写,当用户点击“保存”按钮时,数据会通过网络被提交给后端服务,由后端服务处理是否需要进一步运算,并且把数据保存在哪一个数据库的哪一张表里。
    二.为什么要区分前端/后端BUG?
    目前多数项目都是多人协作开发的,如果不能明确这个BUG是谁造成的,容易提交给错误的开发人员,会大大降低BUG的解决效率。
    另外,如果团队规模较大,或者由各地的项目组拼凑而成,势必会增加沟通成本,这更需要我们在类似禅道或者Jira等项目管理软件中提交BUG时,先指明是谁的BUG,避免互相踢皮球的现象。
    所以,为了提高团队效率,测试人员尤其要做好BUG分类。
    三.如何定位前端/后端BUG?
    对于一个优秀的软件测试工程师来说,区分BUG属于前端还是后端是尤为重要的。
    页面请求过程
    弄清楚如何定位和分类BUG之前,需要了解一下页面请求的过程,以 http 请求为例,请求过程如下:
    用户在前端页面操作,如点击某个功能
    页面携带数据进行请求,访问具体功能接口
    由后端服务执行该接口相应的业务逻辑,如涉及数据,再去请求并组装数据返回给前端
    前端页面进行渲染和展示对应的页面和数据
    前后端BUG各有什么样的特点?
    前端BUG
    – 界面相关
    – 布局相关
    – 兼容性相关
    后端BUG
    – 业务逻辑相关
    – 性能相关
    – 数据相关
    – 安全性相关
    定位BUG属于前端还是后端,有什么方法?
    这里提供了几个方法,可以给大家一个思路,让大家能在学习和工作中了解如何去区分BUG属于前端还是后端。
    经验法
    软件测试人员应不断精进自己的技能,负责的项目多了,自然对功能的实现过程有了解,也就明白如何分类BUG了。
    例如:
    网页上的某个图片的分辨率不对,如果我们了解实现过程,可以想到一般情况下,是根据某个地址去服务器取图片的,数据库一般只保存地址,那么图片能正确显示,就说明后端的基本功能是满足需求的。如果具体图片分辨率有误,最可能的原因是前端显示过程出了差错。
    日志查看法
    当我们发现一个BUG,并不确定这个BUG属于前端还是后端,可以查看后端服务的日志,复现BUG时,查看日志中有没有相关信息。基本可以认为,如果日志没有输出,很可能这个功能并没有与后端交互,也就不存在后端的问题。反之,如果日志有输出,可以进一步查看有无错误日志信息,进一步分析。
    接口查看法
    这种方法常用于查看是后端返回给前端的数据有误,还是前端显示有误。
    大多数浏览器都有自带的接口查看工具,如Chrome,FireFox等都可以通过F12开启抓包,在NetWork中可以看到当前页面发送的每个http请求。
    通过Chrome看到的接口情况如下
    在这里插入图片描述
    可以在Response中查看响应数据
    在这里插入图片描述
    我们需要对比通过后端接口拿到的数据和前端显示的数据,来确认问题出在哪里。如果数据错了,页面显示是错的,也是正常的,先从后端入手去解决。如果数据对了,但是显示错了,就需要问问前端的开发人员了。
    四.经验和总结
    沟通很重要
    我们在定位BUG的过程中,最不能忽略的一个问题是和开发人员的沟通,有时候忙活半天,不如一问一答。经验和技术的成长也都离不开合理高效的沟通。
    经验和小结
    出现样式的问题基本都是CSS的BUG
    出现文本的问题基本上都是html的BUG
    出现交互类的问题基本上都是Javascript的BUG
    其他问题先沟通,再定位

     

    本文转自:https://blog.csdn.net/qq_37823386/article/details/81736548?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.channel_param

    展开全文
  • 如何定位前端bug和后端bug

    千次阅读 多人点赞 2019-10-08 09:34:24
    今天就来跟大家分享“如何定位前端bug和后端bug” 正文 1、样式问题 关于布局和兼容性问题,举个例子:同个界面,在15寸电脑上可以看到完整的内容,但是在13.3的电脑上只能看到部分;再举个例子:在Android 9.3...
  • 如何区分前端Bug与后端Bug

    千次阅读 2021-01-26 14:25:52
    3、非必现的Bug也要全部提交 4、为每个缺陷单独提交一份缺陷报告 5、仔细编写缺陷报告的标题 6、像编写测试用例编写重现步骤 7、使用缺陷模板来提交缺陷 8、编写缺陷报告时,要考虑到日后的查询关键词 9、如有同类或
  • 如何快速定位bug是前端还是后端呢?对于一个优秀的测试工程师来说,区分bug属于前端还是后端是尤为重要的。 一个页面的请求过程: 弄清楚如何定位和分类bug之前,需要了解一个页面的请求过程,以http请求为例: 1、...
  • 在测试过程中,作为软件测试工程师,经常会遇到bug定位问题,也是其中一个重要的问题就是到底如何判断自己提交的bug属于前端问题还是属于后端问题? 要知道自己提交的bug属于前端还是后端问题,那么首要需要理解...
  • wfr=spider&for=pc (仅供自学) 软件测试工程师的 职责是发现BUG,此外,如何体现个人价值?...这里我们就来说说,当我们找到了BUG,应该把BUG提交给谁去解决,这属于BUG定位 的问题。 为什么要
  • 1、如何区分前端和后端通俗讲,用户看到的部分都叫前端。而用户看不到的部分可以统称为后端。2、前端和后端的呈现形式前端的呈现形式有web端、移动端(ios、安卓)、小程序等。后端系统一般只有一个,收集不同前端反馈...
  • 1、如何区分前端和后端通俗讲,用户看到的部分都叫前端。而用户看不到的部分可以统称为后端。2、前端和后端的呈现形式前端的呈现形式有web端、移动端(ios、安卓)、小程序等。后端系统一般只有一个,收集不同前端反馈...
  • web测试中,如何判断是前端的bug还是后端bug呢?

    万次阅读 多人点赞 2019-01-23 16:25:28
    web测试中,如何判断是前端的bug还是后端的bug呢? 通常可以利用抓包工具来进行分析。可以从三个方面进行分析:请求接口,传参,响应。...如果响应内容不正确,为后端bug 4.也可以在浏览器控制台输入js代码调试进...
  • 软件测试工程师的职责是发现BUG,此外,如何体现个人价值?那么我们试想,只提出问题而不去解决,问题就永远得不到闭环。...为什么要区分前端/后端BUG?如果是一个多人开发的系统,不能明确定位到这个bug是谁造成的...
  • 软件测试工程师的职责是发现BUG,此外,如何体现个人价值?那么我们试想,只提出问题而不去解决,问题就永远得不到闭环。所以,一个资深的测试人员的基本功应该是这样的:深挖业务和功能需求,找出BUG,定位BUG,...
  • 后端日常bug、笔记

    2019-10-18 11:35:53
    修饰符作用域 映射文件中的SQL语句取值时报错 Shiro框架验证用户登录的时候的两种异常 使用spring自动创建对象出错 小小面试题 ...在编写yml文件的时候,不能使用tab键对齐,只能使用空格对齐 ...
  • 志汇同城 10.9.4 前端后端齐全无BUG 志汇同城 10.9.4 前端后端齐全无BUG
  • bug描述 当搜索结果总页数小于当前所在页码,会显示“暂无数据”,实际上有数据 产生原因:我们搜索的时候向接口查询数据,传的currentpage是当前的,但是想搜索的数据并没有那么多页,所以会无法显示数据 解决...
  • bugtracker-后端-源码

    2021-03-04 05:41:41
    bugtracker-后端
  • ... 2、页面携带数据进行请求,访问具体功能接口 3、由后端服务执行相应的业务逻辑,如涉及数据,再去...后端bug特点1,业务逻辑相关 2,性能相关 3,数据相关 4,安全性相关 定位前后端bug,有什么方法?1、经验法...
  • 使用做好的网页,修复一下出现的bug 使用spring cache +redis时出现的问题 他成功从缓存中读取到了数据,但是好像时缺少含有全部参数的构造函数的问题,缺少参数的构造函数在这个上面没有用处,所以就在每一个类上...
  • 有一次在做接口测试的时候、测用户贷款详情列表接口的时候、刷 新页面的时候一直报:"接口参数异常"的错误、但是通过fiddler抓包 发现前端传递的接口参数是没有问题的、也是按照接口文档去传的、... 这个属于后端bug
  • 为什么要区分前端/后端BUG? 如果是一个多人开发的系统,不能明确定位到这个bug是谁造成的,容易提交给错误的开发人员,我们又不可能把这些bug同时提交给前端和后端一起去解决,同时提交给前后端开发人员
  • 前端bug特点 :1、界面相关 2、布局相关 3、兼容性相关后端bug特点 :1、业务逻辑相关 2、性能相关 3、数据相关 4、安全性相关定位前后端bug:1、经验法:软件测试人员应不断精进自己的技能,负责的项目多了,自然对...
  • 软件测试工程师的职责是发现BUG,此外,如何体现个人价值?那么我们试想,只提出问题而不去解决,问题就永远得不到闭环。所以,一个资深的测试人员的基本功应该是这样的:深挖业务和功能需求,找出BUG,定位BUG,...
  • <div><h3>Issue description 我是艾佳生活公司的开发,使用apisix时遇到如下问题,具体如下图,在1.5版本中,配置域名的时候,在目标服务器接收到的是ip,...
  • 趣图:前端 VS 后端

    2018-06-07 18:23:46
    前端 VS 后端 @IT程序猿 微博网友评论:@HanerLee:前端光鲜亮丽,后端bug满地@90后晚年大叔:哈哈哈哈 形象 @何其然也:人心两面 @睡不醒了c:那...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,096
精华内容 838
关键字:

后端bug