精华内容
下载资源
问答
  • 如何区分前端BUG后端BUG

    千次阅读 多人点赞 2020-06-09 16:50:10
    1、如何区分前端后端 通俗讲,用户看到的部分都叫前端。 而用户看不到的部分可以统称为后端。 2、前端后端的呈现形式 前端的呈现形式有web端、移动端(ios、安卓)、小程序等。 后端系统一般只有一个,...

    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,例如如下结构:

    该部分可以看做为一个大的框即是标签<a> 内嵌标题的标签<p>,里面再有这些个内容<ing>,那么在不同的浏览器中,可能ie和FF的解析会产生不同,假设IE解析为<a><p><ing></ing></a></p>的一种形式,但在FF下可能解析为

    <a><ing></ing></a>

    <p></p>

    的两行的形式从而导致前端在 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文件<Connector port="8080" URIEncoding="UTF-8"/>,特别是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.测试人员的技术体系

    展开全文
  • 大数据篇:如何区分流处理批处理 今天我们来讲讲大数据的处理模式:批处理(Batching Processing)流处理(Streaming Processing)。 这几年大规模的物联网(IoT)数据监控系统视频流系统等的大数据系统出现,...

    大数据篇:如何区分流处理和批处理

    今天我们来讲讲大数据的处理模式:批处理(Batching Processing)和流处理(Streaming Processing)。

    这几年大规模的物联网(IoT)数据监控系统和视频流系统等的大数据系统出现,已经是必然现象了,我相信在5G的推动下,这类些系统会越来越多。

    在我们开发过程中也会时常的跟这些数据打交道,所以明白其处理方式也是必要的。

    这些数据被抽象成两种数据,分别是有边界数据(Bounded Data)和无边界数据(UnBounded Data)

    有边界数据和无边界数据

    无边界数据

    无边界数据,其实就是一种可增长,无限的数据集。

    我们无法判断他到底会在什么时候结束。例如:我们生活中的支付宝中的交易数据,每时每刻都会有数据产生,无法判断它什么时候会停止发送。

    在这里插入图片描述

    我们也可以称他为”流数据(Streaming Data)“。

    有边界数据

    有边界数据,其实就是一种保存好了的数据,例如数据库中的数据或者csv中的数据等

    拿我们之前的交易数据来说,如果按照一定的时间窗口,拿取一小部分数据,那么提取出来的数据也是有边界数据了。例如我提取2019年08月19日这天地数据来做处理,我们提取出来地这份数据就是有边界数据。

    这里说到了时间窗口,那么我们下面就介绍下两个关于时间的时域吧,他们分别是事件时间处理时间

    事件时间和处理时间

    事件时间(Event Time)指的是一个数据实际产生的时间,处理时间(Precessing Time)指的是这条数据实际被处理数据的系统接收的时间。

    下面我们通过一个例子更了解事件时间和处理时间。

    例如:我打开淘宝准备购物,在12点05分下了单,由于进入车库没信号,导致这个订单一直在重试支付,直到我离开车库,提示支付成功,这时的时间是12点08分。这里的12点05分就是事件时间,而12点08分就是处理时间,这样你是否明白了呢?

    下面我们就进入主题批处理流处理

    批处理和流处理

    批处理

    数据的批处理,可以理解为一系列相关的任务按顺序或并行的,一个接一个地执行。批处理地输入是在一段时间内收集好地数据。每次批处理地输出都可以是下次批处理地输入。

    大部分情况下,批处理地输入数据和输出数据都是有边界数据。所以在批处理中,我们更关注地事件事件。

    举个例子,你在年初的时候,很多“大厂”都会对你这一年所做的事情做一次分析,得到一些有趣的事情。下面我们以网易云音乐为例子:

    在这里插入图片描述

    每年的网易云音乐都会将我们过去一年中听取的歌曲记录存储起来,作为批处理的数据来源,经过一系列的分析计算得到一份有趣的数据作为数据输出。

    在大部分情况,批处理任务会被安排,并在预先设定好的事件间隔来执行。例如:一年、一个月、一天的特定时间。

    网易云音乐的日推也是根据批处理系统,以预先设定好的一天的时间间隔运行,而产生出来的。

    批处理的系统架构通常会被设计在以下这些应用场景中:

    • 日志分析:日志系统是在一定时间段内收集的。而日志系统的数据处理分析是在不同的时间内执行的,以得到系统的关键性指标(例如之前说的准确性和系统容量等)。
    • 计费的应用程序:计费应用程序会计算出一段时间内一项服务的使用程度,并生成计费信息,例如支付宝花呗的还款账单。
    • 数据仓库:数据仓库的主要目标是根据收集好的数据事件时间,将数据信息合并为静态快照(static snapshot),并将它们聚合为每周、每月、每季度的报告等。

    像现在的Apache Hadoop或者是Apache Spark等开源框架都是支持这种大数据批处理架构的。

    由于批处理一般都具有高延迟性,有可能计算需要几小时、几天甚至是几周的时间。所以对实时性比较有要求,那么应该考虑使用流处理的方式处理数据。

    流处理

    数据的流处理可以理解为系统需要接收并处理一系列连续不断变化的数据。例如,音视频的实时推荐、周边推荐等。

    流处理的输入基本都是无边界数据。而流处理系统中是关心事件时间还是处理时间一般是随应用场景而定的。

    例如,像网页监控系统这样的流处理系统要计算网站的QPS,它关心的更多是处理时间,也就是网页请求数据被监控系统接收到的时间,而计算QPS。而在一些医疗护理监控系统的流处理系统中,他们则关心数据的事件时间,这种系统不会因为网络延迟而忽略系统原本产生的时间。

    流处理的特点应该是足够快、低延迟、以及来自各种数据源的大规模数据。流处理所需的响应时间更应该以毫秒(或秒)来进行计算。向我们平时用到的搜索引擎,系统必须在用户输入关键字后以毫秒级的延时返回搜索结果给用户。

    流处理快的原因,是因为他是在数据未达到磁盘时计算的,也就是在内存中计算的。

    当流处理架构拥有一定时间间隔(毫秒)内产生逻辑上正确的结果,这种架构可以被定义为实时处理(Real-time Processing)。

    当一个系统可以接收以分钟为单位的数据处理时间延时,我们可以把它定义为准实时处理(Near Real-time Processing)。

    还记得我们说过批处理架构的不足之处吗?没错,那就是高延迟性。而我们的流处理架构恰恰拥有低延迟和高吞吐等特点。

    下面介绍几个流处理的应用场景:

    • 实时监控:捕获和分析各种来源发布的数据,入传感器,新闻源,点击网页等。
    • 实时商业只能:智能汽车,智能家居,智能病人护理等。
    • 销售终端(POS)系统:像是股票价格的更新,允许用户实时完成付款的系统。

    如今开源的生态圈中,入Apache Kafka、Apache Storm、Apache Flink、Apache Samza等都是流行的流处理架构平台。

    经过介绍你不难发现,无论是批处理模式还是流处理模式,在现实中都是广泛的被使用,而采用哪种处理模式,则应当由使用场景决定。

    总结

    像是对不需要实时分析结果的情况下,其实批处理是一个很好的选择。特别是业务逻辑十分复杂,数据量大的时候,更容易从数据中挖掘到有用的信息。

    而对应用的实时分析处理有要求的情况下,或者数据传输的结束时间、数据量无法确定的情况下,就可以采用流处理的处理架构来完成这件事情

    名言:难走的路,从不拥挤

    下一章:Workflow设计模式

    展开全文
  • 前端后台BUG区分方法

    千次阅读 多人点赞 2019-06-13 12:01:45
     即便提交给对的开发,开发也未必能查到bug产生的原因和代码有问题的地方,因此不一定能修复bug,往往修改了自己认为可能有问题的地方,然后测试发现还有问题,继续发回给开发,开发继续查,来来回回耽误解决bug的...

    测试工程师不只是负责发现问题,除了发现问题这种基本功外,定位问题,提出解决方案,提出预防方案也是要掌握的技能。这里先说定位问题的要求,定位问题要向深入,前提当然是对功能、产品的流程、开发方案、开发人员非常熟悉了,以我们部门为例,定位bug至少要到下面这种程度。

      首先确定是界面显示问题还是功能问题,

      如果是界面问题,如贴图错误,文字错误,样式错误,则需要截图

      如果是功能问题:

      控制台的问题至少定位到:www的问题还是数据库问题,如果是www问题至少要定位到是前端还是后端问题;如果是数据库问题至少要定位到是服务端接口问题还是中间件问题

      客户端的问题至少定位到:哪个dll模块或者逻辑出的问题

      服务端的问题至少定位到:什么接口出的问题,导致数据库哪里不对

      另外,

      1)测试时不要全按照用例走,要多发散思维

      2)测试时要尽量考虑得更全面,把一些多用户多终端或其他极端的情况都考虑到。

      最后,

      跟进重点问题的修改进度和方案,询问开发时如何修改的,反思开发的修改方案是否存在漏洞

      为何要学会区分前端和后台BUG?

      如果是一个多人开发的系统,不能明确定位到这个bug是谁造成的,容易提交给错误的开发人员,于是bug会像皮球一样被开发踢来踢去,耽误开发解决bug的时间。

      即便提交给对的开发,开发也未必能查到bug产生的原因和代码有问题的地方,因此不一定能修复bug,往往修改了自己认为可能有问题的地方,然后测试发现还有问题,继续发回给开发,开发继续查,来来回回耽误解决bug的时间。

      再退一步来说,如果开发水平很高,没有1和2的问题,对于测试来说也很容易提交重复的bug,因为可能很多bug都是由于一个地方引起的,只是表现出问题不一样,但本质却是一样的,这样也是耽误了测试时间。

      当然能遇到的远远不止以上3种情况,所以对于测试来说仅仅提交bug是不够的,无论对于测试自身的提高积累,还是对于项目进度推进都是非常重要的。

      要怎么样才能定位bug呢?

      当bug出现时,一般来说分大致3种情况,

      数据库层面的:可能少某个字段,或者字段值为空等等,这些可能在设计数据库时就埋下了错误的种子,导致程序调用数据库错误的数据产生bug,这一类问题不算普遍,但也是最容易忽视的一种情况,有时候从数据库入手定位bug说不定还能发现数据库的设计缺陷呢。

      网络层面的:通常这种都是网络情况较差的时候产生的,比如手机的移动网络信号不好,又或是公司网络不稳定,导致js/css未加载完全或者请求超时等等,这种问题其实非程序bug造成的,可以不用提交bug,也不用让开发毫无头绪的去查代码的问题。当然如果可以的话也可以当优化建议提给开发,让他优化代码,比如压缩js/css,增加超时时间,超时后的重试机制。

      代码层面的:普遍的bug基本都是代码有问题造成的,排除掉1和2剩下后就可以确定是程序bug了。对于了解网络架构的人来说,其实程序也分前端和后端的,一般对于界面显示有问题直接可以判断是前端的问题,比如系统兼容性,浏览器兼容性。

      而对于数据或者逻辑上的问题,则需要(检查接口)前端和后台之间是通过接口文件相互联系的,通过抓包工具来进行分析 :

      1)请求未返回数据,可能是client(客户端)请求数据错误,可能是server端处理错误。

      2)请求返回错误的数据,那就是server端(服务器端)处理错误。

      3)请求返回正确的数据,那就是前端处理server端(服务器端)返回数据有错误

      定位bug就像这样抽丝剥茧一层层排除,从而把最后剩下的可能性给找出来,说难其实也不难,但需要有足够的逻辑思维能力来推断,也需要足够的耐心去寻找bug的根源。

      什么是前端和后台?

      常常说到的一个IT项目,包括前端开发,后台开发,软件测试,架构,项目经理,产品需求。那么对于一位优秀的软件测试工程师来说,需要区分前端和后台的工作就显得尤为重要。

      简而言之,前端一般是指界面的设计居多,他们往往需要调用后台的一个接口,进行一个HTTP请求,根据后台反馈回来的数据,渲染到页面上。从而实现按钮(如果前端只是画了页面,接口未调试,点击页面按钮是无反应的),数据显示的正常。

      测试工程师如何区分前端和后台的BUG----------- 前台的bug通常是功能、界面和兼容性等有关;后台的bug与逻辑、性能和安全性有关。与数据相关的错误、排序问题大多是后台问题,对于APP页面toast提示可能是后台给的,可能是APP给的

      1、检查接口

      前端和后台之间是通过接口文件相互联系的,同样,测试人员也是可以看到这个一接口文件,很多人以为,这一点都不重要,那你大错特错了。因为这是区分前端和后台bug的关键。

      2、情况分析

      a、检查请求的数据是什么,反馈的数据又是什么

      可以通过抓包工具来进行抓包分析。

      大多数的浏览器都有自带的抓包插件,如FireFox的FireBug插件,Chrome、360急速模式、搜狗高速模式自带的DevelopTools插件,F12开启抓包后,在NetWork中可以看到当前页面发送的每一个http请求。

      通常情况下,我们可以通过请求接口、传参和响应三部分来判断Bug,另外,也可以在浏览器的控制台进行代码调试定位。

      (1)请求接口URL是否正确

      如果请求接口URL不正确,为前端Bug;

      (2)http请求中的参数是否正确

      如果http请求中的参数不正确,为前端Bug;

      (3)如果接口URL和参数都正确,查看响应内容是否正确

      如果这种情况下响应内容不正确,则为后端Bug。

      (4)如果JS基础比较好的话,也可以在浏览器的控制台中输入JS代码进行调试

      HTTP请求中,如果是get请求,那么表单参数以name=value&name1=value1的形式附到url的后面,如果是post请求,那么表单参数是在请求体中,也是以name=value&name1=value1的形式在请求体中。通过chrome的开发者工具可以看到如下(这里是可读的形式,不是真正的HTTP请求协议的请求格式):

      get请求:

       RequestURL:http://127.0.0.1:8080/test/test.do?name=mikan&address=street      -------请求参数

      Request Method:GET

      Status Code:200 OK

      Request Headers

      Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

      Accept-Encoding:gzip,deflate,sdch

      Accept-Language:zh-CN,zh;q=0.8,en;q=0.6

      AlexaToolbar-ALX_NS_PH:AlexaToolbar/alxg-3.2

      Connection:keep-alive

      Cookie:JSESSIONID=74AC93F9F572980B6FC10474CD8EDD8D

      Host:127.0.0.1:8080

      Referer:http://127.0.0.1:8080/test/index.jsp

      User-Agent:Mozilla/5.0 (Windows NT 6.1)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.149 Safari/537.36

      Query String Parameters

      name:mikan

      address:street

      Response Headers

      Content-Length:2

      Date:Sun, 11 May 2014 10:42:38 GMT

      Server:Apache-Coyote/1.1

      Post请求:

       RequestURL:http://127.0.0.1:8080/test/test.do

      Request Method:POST

      Status Code:200 OK

      Request Headers

      Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

      Accept-Encoding:gzip,deflate,sdch

      Accept-Language:zh-CN,zh;q=0.8,en;q=0.6

      AlexaToolbar-ALX_NS_PH:AlexaToolbar/alxg-3.2

      Cache-Control:max-age=0

      Connection:keep-alive

      Content-Length:25

      Content-Type:application/x-www-form-urlencoded

      Cookie:JSESSIONID=74AC93F9F572980B6FC10474CD8EDD8D

      Host:127.0.0.1:8080

      Origin:http://127.0.0.1:8080

      Referer:http://127.0.0.1:8080/test/index.jsp

      User-Agent:Mozilla/5.0 (Windows NT 6.1)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.149 Safari/537.36

      Form Data--------其中显示请求的参数

      name:mikan

      address:street

      Response Headers

      Content-Length:2

      Date:Sun, 11 May 2014 11:05:33 GMT

      Server:Apache-Coyote/1.1

      这里要注意post请求的Content-Type为application/x-www-form-urlencoded,参数是在请求体中,即上面请求中的Form Data。

      通过chrome的开发者工具看到请求头如下:

       RequestURL:http://127.0.0.1:8080/test/test.do

      Request Method:POST

      Status Code:200 OK

      Request Headers

      Accept:*/*

      Accept-Encoding:gzip,deflate,sdch

      Accept-Language:zh-CN,zh;q=0.8,en;q=0.6

      AlexaToolbar-ALX_NS_PH:AlexaToolbar/alxg-3.2

      Connection:keep-alive

      Content-Length:28

      Content-Type:text/plain;charset=UTF-8

      Cookie:JSESSIONID=C40C7823648E952E7C6F7D2E687A0A89

      Host:127.0.0.1:8080

      Origin:http://127.0.0.1:8080

      Referer:http://127.0.0.1:8080/test/index.jsp

      User-Agent:Mozilla/5.0 (Windows NT 6.1)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.149 Safari/537.36

      Request Payload-------其中显示参数

      name=mikan&address=street

      Response Headers

      Content-Length:2

      Date:Sun, 11 May 2014 11:49:23 GMT

      Server:Apache-Coyote/1.1

      注意请求的Content-Type为text/plain;charset=UTF-8,而请求表单参数在RequestPayload中。

      下面是后台响应参数,

      b、根据接口的文件,检查数据是否正确,至于如何分析,这个就看个人的基础了,如果发送的数据是正确的,但是后台反馈的数据是不符合需求的,那就是后台的问题;如果前端没有请求接口,或者请求的时候发送数据与需求不符,那这个时候就是前端的问题了。总而言之,这种情况很多,需要各位自己多多总结经验。一位优秀的测试开发工程师,当然也离不开好的编程基础。

      前台bug定位:按F12在console中查看报错信息,对于出错的js可以在Sources下查看对应报错的资源文件,写入禅道提交给开发即可

      2.后端的Bug,如何准确的定位问题在哪里,如何精准的描述Bug?

      (1)查看报错日志

      查看报错日志,通过日志分析,需要有一定的经验,并且有一定的代码基础,才能更好地定位问题。

      (2)查看数据库的数据

      了解所测功能的数据表结构,测试过程中,查看数据库的数据,确认数据的正确性。

      (3)查看缓存(如Memcache、apc、redis等缓存)是否正确

      现在来分析bug可能是前台还是后台:

      case1:文本框输入不合法的内容,点击提交按钮, 如果不合法的内容提交成功, 那应该是前后台没有做校验, 前后台都有这个bug

      case2:文本框输入合法的内容,点击提交按钮, 查看数据库中的数据和输入的内容不一致, 这个时候需要看前台传的数据是否正确,使用fiddler抓包, 查看请求头里面的数据是否和输入一致,如果一致就是后台的问题, 如果不一致,就是前台的bug

      case3:界面展示不友好, 重复提交 这些都是前台的bug

      前台定位方法:

      前台bug定位:按F12在console中查看报错信息,对于出错的js可以在Sources下查看对应报错的资源文件,写入禅道提交给开发即可

      前台bug注意以下三个方面:

      (1)网站前台的权限控制:没有权限的用户是不能直接输入url的方式来进行访问的,必须进行登录。以后涉及到权限的测试,一定不能漏掉url的方式也需要验证一下。而在单个页面进行W3C测试时则需要去掉该权限控制。

      (2)网站前台的title,对于这个也很容易忽视。进入到不同的功能页面,title显示应该是有,并且要和你进入的页面一致。title就是在浏览器最左上角看到的那些文字

      (3)http和https的注意点:https是一种安全链接,它是需要证书的,而http就是普通链接,所以在你的系统中客户会要求某些关键的地方希望加上这种安全连接,那么此时你需要注意的是,对于不需要的安全链接的地方千万也要去重点测试,有些开发会很容易忽略这一点。

      你要打开HTTPS开头的网站,前提是该网站安装了SSL证书,只有安装了SSL证书的网站,并且开启了443端口,你才可以通过HTTPS加密协议无访问。如果没有则不能访问。

      你可要测试,比如在某个网站http协议后面加个s去访问,看能否访问成功,能成功,会显示绿色安全小锁,否则就不能访问。给你举几个安装了ssl证书,可要https访问的网站,1号店,天猫,淘宝,支付宝,百度,沃通CA,工信部网站等等

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

      给个最大的区别方式方法:

      出现样式的问题基本都是CSS的bug

      出现文本的问题基本都是html的bug

      出现交互类的问题基本都是Javascript的bug

      现在以淘宝的前端人员工作为例进行相关bug定位的剖析

      判断前后台问题的区分方法:

      F12, 打开错误控制台console

      区分前后台交互:查看网络请求

      a) Html中如果有链接,有相应的情况下,基本可以定位到是属于前端的问题

      b) 如果为空,或者有出现error错误信息,我们就可以定位到属于后台开发的问题

      TMS对应的VM模板,出现的一些截断控制,转换功能都属于前端的问题

      一、HTML

      最常见的HTML的问题—就是标签的问题了,最常见的排查和解决办法就是查看页面源代码,然后通过检查标签的工具,现在暂时提供idea.exe进行检查,有其他更好的工具再进行推荐。

      常见问题类别:

      标签闭合—表象,页面中出现大范围的混乱,就是少了标签的情况,导致标签未闭合

      标签浮出—例如鼠标移动到文本位置,浮出全名的这种浮出形式都属于标签浮出的问题

      标签在不同的浏览器的一种解析方式的不同导致的前端bug例如如下结构

      该部分可以看做为一个大的框即是标签<a> 内嵌标题的标签<p>,里面再有这些个内容<ing>,那么在不同的浏览器中,可能ie和FF的解析会产生不同,假设IE解析为<a><p><ing></ing></a></p>的一种形式,但在FF下可能解析为

      <a><ing></ing></a>

      <p></p>

      的两行的形式从而导致前端在复古鞋/板鞋这块ing里面的格式产生混乱

      结构可看为:

      页面定点的问题:最明显的前端功能,在于点击某个链接将页面位置定位到对应的位置

      a) 我们可以通过右键,查看元素的工具进行定位到毛点所定位到的位置,如果出现问题这种问题很直观,并且能通过这种方法直接定位到问题

      页面的跳转,也属于html的问题,大家在出现点击未跳转或者跳转方式不正确的问题,直接可以定位到跳转属性的问题,找到对应的跳转对应的块提供给开发人员即可

      二、CSS,产生样式问题。例如:排版,布局,颜色,背景等

      css的bug主要分为:兼容型bug 、业务性bug 和 内容型bug

      兼容型bug

      a) 表现:仅在少数几个浏览器上出现

      b) 原因:浏览器的解析不一致

      c) 解决:根据实际情况进行前端代码的通用性

      d) 类别:

      脚本兼容型问题:在出现对应交互的问题就基本可以定位到脚本兼容型bug,例如DIV的显示和层结构。实际可以参考聚划算的几个商品鼠标移动到小图的时候,对应大图展示的功能。

      页面样式兼容型问题:直接表象在样式上,都是基于框架的页面展示错误,很容易定位

      业务性bug

      a) 表现:在所有浏览器下都有该问题

      b) 原因:对业务不熟悉

      c) 解决:根据需求进行修改达到业务要求

      该类型的定位,主要在和实现的要求不一致,最直接表现在页面的友好型,用户的可用性的bug,可以定位为该类型

      内容型bug

      a) 表现: 前端自测正确,但在填入内容后,出现的错误,内容消失等

      b) 原因: 扩展性未考虑周全

      c) 解决: 进行overflow test

      输入内容的长度限制等功能可定位为内容型bug

      三、Javascript

      最直接的判断方法,刷新页面,出现滞后显示的一些模块基本都为脚本的输出块。该部分的一些问题可以参照兼容型bug中类别的脚本兼容型bug。

      有产生交互类的问题,大多数都可以定位到是属于javascript产生的问题,该部分大多不会报错

      有错误提示类的。页面左下方有出现javascript的错误提示;有弹出错误信息提示的bug;浏览器返回的一些错误弹出框都属于javascript的bug

      后台bug定位:根据后台日志文件

      系统使用secureCRT进行日志获取

      (1)编码问题:tomcat是新的,需要改编码 修改tomcat的server.xml文件<Connector port="8080" URIEncoding="UTF-8"/>

      特别是windows下的项目重新部署到linux系统下,

      (2)空指针:程序问题,一般没有考虑到为空情况,或者主外键约束的数据为空,或者删除关联数据,导致为空

      (3)长度过长,超过最大长度,测试环境修改数据库字段长度后生产环境未修改,导致报错!!

      (4)非法数据:

      (5)内存溢出:重启

      系统使用secureCRT进行日志获取,或者服务器控制方面的操作(关闭和重启)

      重启的一般情况:

      1)热部署 (新增部分功能,或者修改部分bug)

      2)发布新版本 (整个系统)

      3)内存溢出,此时重启服务器即可

      由于项目中有线程程序,./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.如何查看日志?

      一台服务器可以部署多个应用:

      cd usr/local/测试服务器名称/logs               //查看先进入到服务器的logs目录下

      tail -f catalina.out                         //监视catalina.out 文件的尾部内容(默认10行)

      4.日志中常见的问题

      获取日志文件中常遇到的问题:

      1)编码问题:tomcat是新的,需要改编码 修改tomcat的server.xml文件<Connector port="8080" URIEncoding="UTF-8"/>

      特别是windows下的项目重新部署到linux系统下,

      2)空指针:程序问题,一般没有考虑到为空情况,或者主外键约束的数据为空,或者删除关联数据,导致为空

      3)长度过长,超过最大长度,测试环境修改数据库字段长度后生产环境未修改,导致报错!!

      4)非法数据:

      5)内存溢出:重启

      5.一般的问题原因总结:

      程序:为空判断,增删改查,不同公众号调用的接口也不一样

      数据初始化:数据库表结构和数据初始化,权限配置,

      特别注意生产环境上的用户数据修改,此时用户在使用,很重要!!!

      故障无法重现时:

      1)看日志,根据日志定位原因,则在测试环境中按照日志提示构造条件相同的测试案例测试,尝试在测试环境中将问题重现。

      2)测试环境和配置与实际的工程环境和配置有哪些差异等等。同时主动与开发负责人、工程实施人员以及有经验的项目经理讨论,分析可能导致的原因。

      测试环境ok,生产环境新增时保存失败,查看后台日志报长度溢出,数据库内容字段要求和生产环境不一致!!

      6.辅助工具:linux和SQL

      linux查看日志

      SQL用来筛选数据或直接进行数据修改状态,多用于集成测试过程中前后流程相连接

      三.浏览器兼容性和网页规范标准测试

      浏览器兼容性测试(偏主流浏览器,如谷歌,火狐,IE8以上):

      https://dev.windows.com/en-us/microsoft-edge/tools/staticscan/

      W3C网页验证:(判断网页书写是否符合规范,记住此处必须去掉权限控制,单个单元页面url需要跟参数)

      https://validator.w3.org/

      W3C手机端页面检测(如手机微信菜单下的页面):

      https://validator.w3.org/mobile-alpha/

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

      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.测试人员的技术体系:

      实战

      图中参数city code 为空此时不应该为空,为空就可能导致前端看不到该数据

      后台返回的一条数据没有----后台BUG

    展开全文
  • 如何区分前端BUG后台BUG

    千次阅读 多人点赞 2019-06-03 14:54:46
    即便提交给对的开发,开发也未必能查到bug产生的原因和代码有问题的地方,因此不一定能修复bug,往往修改了自己认为可能有问题的地方,然后测试发现还有问题,继续发回给开发,开发继续查,来来回回耽误解决bug的...

    测试工程师不只是负责发现问题,除了发现问题这种基本功外,定位问题,提出解决方案,提出预防方案也是要掌握的技能。这里先说定位问题的要求,定位问题要向深入,前提当然是对功能、产品的流程、开发方案、开发人员非常熟悉了,以我们部门为例,定位bug至少要到下面这种程度。

    首先确定是界面显示问题还是功能问题

    • 如果是界面问题,如贴图错误,文字错误,样式错误,则需要截图。
    • 如果是功能问题,控制台的问题至少定位到:www的问题还是数据库问题,如果是www问题至少要定位到是前端还是后端问题;如果是数据库问题至少要定位到是服务端接口问题还是中间件问题。
    • 客户端的问题至少定位到:哪个dll模块或者逻辑出的问题
    • 服务端的问题至少定位到:什么接口出的问题,导致数据库哪里不对

    另外,

    1. 测试时不要全按照用例走,要多发散思维
    2. 测试时要尽量考虑得更全面,把一些多用户多终端或其他极端的情况都考虑到。
      最后,跟进重点问题的修改进度和方案,询问开发时如何修改的,反思开发的修改方案是否存在漏洞。

    为何要学会区分前端和后台BUG?

    如果是一个多人开发的系统,不能明确定位到这个bug是谁造成的,容易提交给错误的开发人员,于是bug会像皮球一样被开发踢来踢去,耽误开发解决bug的时间。

    即便提交给对的开发,开发也未必能查到bug产生的原因和代码有问题的地方,因此不一定能修复bug,往往修改了自己认为可能有问题的地方,然后测试发现还有问题,继续发回给开发,开发继续查,来来回回耽误解决bug的时间。

    再退一步来说,如果开发水平很高,没有1和2的问题,对于测试来说也很容易提交重复的bug,因为可能很多bug都是由于一个地方引起的,只是表现出问题不一样,但本质却是一样的,这样也是耽误了测试时间。

    当然能遇到的远远不止以上3种情况,所以对于测试来说仅仅提交bug是不够的,无论对于测试自身的提高积累,还是对于项目进度推进都是非常重要的。


    测试工程师如何区分前端和后台的BUG
    前台的bug通常是功能、界面和兼容性等有关;后台的bug与逻辑、性能和安全性有关。与数据相关的错误、排序问题大多是后台问题,对于APP页面toast提示可能是后台给的,可能是APP给的

    通常情况下,我们可以通过请求接口、传参和响应三部分来判断Bug,另外,也可以在浏览器的控制台进行代码调试定位。

    1. 请求接口URL是否正确,如果请求接口URL不正确,为前端Bug
    2. http请求中的参数是否正确,如果http请求中的参数不正确,为前端Bug
    3. 如果接口URL和参数都正确,查看响应内容是否正确,如果这种情况下响应内容不正确,则为后端Bug
    4. 如果JS基础比较好的话,也可以在浏览器的控制台中输入JS代码进行调试

    根据接口的文件,检查数据是否正确,至于如何分析,这个就看个人的基础了,如果发送的数据是正确的,但是后台反馈的数据是不符合需求的,那就是后台的问题;如果前端没有请求接口,或者请求的时候发送数据与需求不符,那这个时候就是前端的问题了。
      前台bug定位:按F12在console中查看报错信息,对于出错的js可以在Sources下查看对应报错的资源文件,写入禅道提交给开发即可。

    后端的Bug,如何准确的定位问题在哪里,如何精准的描述Bug?

    1. 查看报错日志,通过日志分析,需要有一定的经验,并且有一定的代码基础,才能更好地定位问题。
    2. 查看数据库的数据,了解所测功能的数据表结构,测试过程中,查看数据库的数据,确认数据的正确性。
    3. 查看缓存(如Memcache、apc、redis等缓存)是否正确

    前台bug注意以下三个方面:

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

    你可要测试,比如在某个网站http协议后面加个s去访问,看能否访问成功,能成功,会显示绿色安全小锁,否则就不能访问。给你举几个安装了ssl证书,可要https访问的网站,1号店,天猫,淘宝,支付宝,百度,沃通CA,工信部网站等等
    前端bug主要分为3个类别:HTML,CSS,Javascript三类问题

    • 给个最大的区别方式方法:
    1. 出现样式的问题基本都是CSS的bug
    2. 出现文本的问题基本都是html的bug
    3. 出现交互类的问题基本都是Javascript的bug
    展开全文
  • Web前端后端之区分

    千次阅读 2013-05-21 17:40:09
    在我们实际的开发过程中,... 2)后端开发人员:会写Java代码,会写SQL语句,能做简单的数据库设计,会SpringiBatis,懂一些设计模式等。  现在来看,我们对前后端的要求还是蛮低的,尤其是后端,新员工经过培
  • Web前端后端之区分,以及面临的挑战

    万次阅读 多人点赞 2016-08-25 17:20:01
     2)后端开发人员:会写Java代码,会写SQL语句,能做简单的数据库设计,会SpringiBatis,懂一些设计模式等。  现在来看,我们对前后端的要求还是蛮低的,尤其是后端,新员工经过培训之后都是可以参与到后端开发
  • 从原理的视角,一文彻底区分MOS MOSFET NMOS PMOS CMOS

    万次阅读 多人点赞 2019-07-19 13:56:11
    从原理的视角,一文彻底区分MOS MOSFET NMOS PMOS傻傻分不清由基础说起MOSFET登场NMOS电路抽象PMOS电路抽象 本文为原创作品,转载请注明出处! 如果本文对你有帮助,请记得回复个好评,增加我继续分享的动力,呵呵。...
  • Hibernate的对象有3种状态,分别为:瞬...处于持久态的对象也称为PO(Persistence Object),瞬时对象脱管对象也称为VO(Value Object)。 瞬时态  由new命令开辟内存空间的java对象,  eg. Person person = new
  • 这里是按照我的想法来猜测语言设计时的一些特性,如果有高人能进一步指点,不胜感激~其实一直对字符串数组与字符串指针都抱有很多疑问,因为它用起来整型指针相比完全不是一个风格。比如char *str =”char test”;...
  • 一笔画: 表现绘画过程的美

    万次阅读 多人点赞 2018-09-23 23:48:19
    书画同源就表现为画作上的题字吗?编程绘画有毛关系?看完本文,定能获得清晰的解答。 对比分析了大量案例,既讲画理,也谈书法,讨论了诸多有关书法与绘画关系的问题,提出一种“一笔画”的画法,综合了绘画、...
  • 读写时需要同时指定逻辑块号块内偏移。应用程序对NAND芯片操作是以“块”为基本单位。NAND闪存的块比较小,一般是8KB,然后每块又分成页,页的大小一般是512字节。要修改NAND芯片中一个字节,
  • 股票连续跌停后开板表现

    千次阅读 2019-05-09 21:15:55
    分析此种策略收益,同时为了进一步获得高收益,可对跌停原因进行分析,是短期噩耗还是长期消息,比如财务造假等会对企业造成本质伤害等需区分   以下代码可基于ricequant import pandas as pd stocks =...
  • 对要平衡低精确率与低召回率的情况,你可以调整区分正负类别的概率临界值(probability threshold) 。 对低精确率可以提高概率临界值 ,以使模型在指定正类别时更为保守。反之, 遇到低召回率时可以降低概率临界值 ...
  • 十五年学不会英语的原因

    万次阅读 多人点赞 2018-09-18 10:17:22
    原因只有一个——就是我们的学习能力太差了!!我们的老师太笨了!!!  这篇文章主要是给大家讲英语的基本结构, 看了这篇文章,你们会突然就明白,英语怎么会如此简单!!  首先我们来看下面这两张地图...
  • JAVA重写重载的区别

    万次阅读 多人点赞 2018-07-11 22:04:05
    实质表现就是多个具有不同的参数个数或者类型的同名函数(返回值类型可随意,不能以返回类型作为重载函数的区分标准)同时存在于同一个类中,是一个类中多态性的一种表现(调用方法时通过传递不同参数个数参数类型...
  • SQL Server死锁产生原因及解决办法

    千次阅读 2014-09-27 10:54:25
    表现一:  一个用户A 访问表A(锁住了表A),然后又访问表B,另一个用户B 访问表B(锁住了表B),然后企图访问表A,这时用户A由于用户B已经锁住表B,它必须等待用户B释放表B,才能继续,好了他老人家就只好老老实实...
  • React诞生的历史原因

    千次阅读 2018-04-24 21:29:41
    React诞生的原因 React是Facebook开发的一款的JS库,那么Facebook为什么要创造React? Facebook认为MVC无法满足他们的扩展需求,由于他们非常巨大的代码库庞大的组织,使得MVC很快变得复杂,每当需要添加一项新...
  • 在Android 中的卡顿丢帧原因概述 - 应用篇[1]这篇文章中我们列举了应用自身原因导致的手机卡顿问题 , 这一篇文章我们主要列举一些由 Android 平台自身原因导致的卡顿问题....
  • sqlserver 死锁原因及解决方法

    千次阅读 2014-03-28 16:59:03
    其实所有的死锁最深层的原因就是一个:资源竞争   表现一:  一个用户A 访问表A(锁住了表A),然后又访问表B,另一个用户B 访问表B(锁住了表B),然后企图访问表A,这时用户A由于用户B已经锁住表B,它必须等待...
  • CAN协议分析,120欧姆电阻原因

    千次阅读 2019-05-29 15:09:50
    CAN接120欧姆终端电阻的原因分析 工程师谭军 发表于 2018-10-10 10:06:06 接口/总线/驱动 +关注  本文主要是关于CAN总线的相关介绍,并着重对CAN接120欧姆终端电阻的原因进行了详尽的阐述。  CAN总线  CAN...
  • 误差原因(Error):用于测量模型性能的基本指标。 在模型预测中,模型可能出现的误差来自两个主要来源,即:因模型无法表示基本数据的复杂度而造成的偏差(bias),或者因模型对训练它所用的有限数据过度敏感而造成...
  • B+树比B树更适合做文件索引的原因

    万次阅读 多人点赞 2017-03-18 10:47:23
    B+树比B树更适合做文件索引的原因
  • 总结下之前遇到的错误以及导致Xpath定位失败的原因,在网上找的资料特此整理如下:&lt;h3&gt;一、Xpath定位方法深入探讨&lt;/h3&gt;(1)常用的Xpath定位方法及其特点&lt;h6&gt;使用绝对...
  • 过拟合产生的原因: 1.神经网络的学习能力过强,复杂度过高。 2.训练时间太久。 3.激活函数不合适。 4.数据量太少。 解决办法: 1.降低模型复杂度,dropout。 2.即时停止。 3.正则化。 4.数据增强。 ...
  • Android UI卡顿原因及解决办法

    千次阅读 2017-07-24 18:38:04
    View Hierarchy中包涵了太多的没有用的view,这些view根本就不会显示在屏幕上面,一旦触发测量布局操作,就会拖累应用的性能表现。那么我们就需要利用工具进行分析。 如何找出里面没用的view呢?或者减少不必要...
  • 数据库服务器CPU负载突然升高,持续二十分钟后自行自动下降原因诊断分析
  • 1. Debug Release 编译方式的本质区别  2. 哪些情况下 Release 版会出错  2. 怎样“调试” Release 版的程序  --------------------------------------  关于DebugRelease之本质区别的讨论  一、...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 85,891
精华内容 34,356
关键字:

如何区分表现和原因