知识分享---如何区分前端与后端bug

一、如何区分前端和后端

通俗讲，用户看到的部分都叫前端。

而用户看不到的部分能够统称为后端。

 

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

前端的呈现形式有web端、移动端（ios、安卓）、小程序等。

后端系统通常只有一个，收集不一样前端反馈回来的数据。

 

三、前端和后端工做内容的差异

前端主要是考虑怎样能让用户以为用起来更舒服，考虑界面布局、交互效果、页面加载速度等。

后端更多的是与数据库进行交互以处理相应的业务逻辑。须要考虑的是如何实现功能、数据的存取、平台的稳定性与性能等。

 

四、如何分析bug（bug类型）

当bug出现时，通常来讲分大体3种状况：

（1）数据库层面的：

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

（2）网络层面的：

一般这种都是网络状况较差的时候产生的，好比手机的移动网络信号很差，又或是公司网络不稳定，致使js/css未加载彻底或者请求超时等等，这种问题其实非程序bug形成的，能够不用提交bug，也不用让开发毫无头绪的去查代码的问题。固然若是能够的话也能够当优化建议提给开发，让他优化代码，好比压缩js/css，增长超时时间，超时后的重试机制。

（3）代码层面的：

广泛的bug基本都是代码有问题形成的，排除掉1和2剩下后就能够肯定是程序bug了。对于了解网络架构的人来讲，其实程序也分前端和后端的，通常对于界面显示有问题直接能够判断是前端的问题，好比系统兼容性，浏览器兼容性。

而对于数据或者逻辑上的问题，则须要（检查接口）前端和后台之间是经过接口文件相互联系的，经过抓包工具来进行分析 ：

1）请求未返回数据，多是client（客户端）请求数据错误，多是server端（服务器端）处理错误。

2）请求返回错误的数据，那就是server端处理错误。

 

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

前台的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、根据接口的文件，检查数据是否正确。

若是发送的数据是正确的，可是后台反馈的数据是不符合需求的，那就是后台的问题。

若是前端没有请求接口，或者请求的时候发送数据与需求不符，那这个时候就是前端的问题了。

 

六、如何精准的定位前台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；

浏览器返回的一些错误弹出框。

 

七、如何精准的定位后端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用来筛选数据或直接进行数据修改状态，多用于集成测试过程当中先后流程相链接

 

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

浏览器兼容性测试（偏主流浏览器，如谷歌，火狐，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.测试人员的技术体系