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