提示：该文章仅仅是个人面试（测试）总结的一些题目，仅供参考
一、计算机网络基础
1.OSI的七层模型分别是？各自的功能是什么？
- 物理层：利用传输介质为数据链路层提供物理连接，实现比特流的透明传输（0和1的电信号）
- 数据链路层：接收来自物理层的位流形式的数据，并封装成帧，传送到上一层
- 网络层：将网络地址翻译成对应的物理地址，并通过路由选择算法为分组通过通信子网选择最适当的路径
- 传输层：在源端与目的端之间提供可靠的透明数据传输
- 会话层：负责在网络中的两节点之间建立、维持和终止通信
- 表示层：处理用户信息的表示问题，数据的编码，压缩和解压缩，数据的加密和解密
- 应用层：为用户的应用进程提供网络通信服务
说明：一层物理层时数据被称为比特流(Bits)，二层数据链路层时数据被称为帧(Frames)，三层网络层数据被称为包(Packages)，四层即传输层数据被称为段(Segments)
2.说一下一次完整的HTTP请求的过程包含哪些内容
域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户。
3.HTTP长连接和短链接的区别
在HTTP/1.0中默认使用短链接，也就是说客户端和服务端每进行一次HTTP操作，就建立一次连接，任务结束就终端连接；而从HTTP/1.1起，默认使用长连接，用来保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：Connection:keep-alive。
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它也有一个保持时间，可以在不同的服务器中设定这个时间。
4.HTTP请求方法你知道多少？
5.get，post区别，你知道哪些？
- get是获取数据，post是修改数据
- get是把请求的数据放在url上，以？来分割URL和传输数据，参数之间以&相连，所以get不太安全，而post把数据放在HTTP的包体内
- get提交的数据最大是2k(限制实例取决于浏览器)，post理论上没有限制
- get产生一个tcp数据包，浏览器会把http header和data一并发送出去，服务端响应200(返回数据)；post产生两个数据包，浏览器先发送header，服务端响应100 continue，浏览器在发送data，服务端响应200(返回数据)。
- get请求会被浏览器主动缓存，而post不会，除非手动对浏览器设置
所以正因为有这样的区别，所以不应该且不能用get请求对数据做增删改操作
6.在浏览器中输入url地址后显示主页的过程
- 根据域名，进行DNS域名解析
- 拿到解析的IP地址，建立TCP连接
- 向IP地址，发送HTTP请求
- 服务器处理请求，返回响应结果
- 关闭TCP连接
- 浏览器解析HTML，并进行布局渲染
7.在浏览器中输入url回车后，背后有哪些技术步骤
- 查浏览器缓存，看看有没有已经缓存好的，如果没有，检查本机host文件，
- 向DNS服务器发送DNS请求，查询本地DNS服务器，这其中用的是UDP的协议
- 如果在一个子网内采用ARP地址解析协议进行ARP查询如果不在一个子网那就需要对默认网关进行DNS查询，如果还找不到会一直向上找根DNS服务器，直到最终拿到IP地址（全球400多个根DNS服务器，由13个不同的组织管理）
- 这个时候我们就有了服务器的IP地址 以及默认的端口号了，http默认是80 https是 443 端口号，会首先尝试http然后调用Socket建立TCP连接，
- 经过三次握手成功建立连接后，开始传送数据，如果正是http协议的话，就返回就完事了；如果不是http协议，服务器会返回一个5开头的的重定向消息，告诉我们用的是https，那就是说IP没变，但是端口号从80变成443了，好了，再四次挥手，完事
- 还会采用SSL的加密技术来保证传输数据的安全性，保证数据传输过程中不被修改或者替换之类的，这次依然是三次握手，沟通好双方使用的认证算法，加密和检验算法，在此过程中也会检验对方的CA安全证书
- 确认无误后，开始通信，然后服务器就会返回你所要访问的网址的一些数据，在此过程中会将界面进行渲染，直到最后我们看到色彩斑斓的网页
8.谈谈DNS解析过程
- 请求一旦发起，若是chrome浏览器，先在浏览器找之前有没有缓存过的域名所对应的ip地址，有的话，直接跳过dns解析了，若是没有，就会找硬盘的hosts文件，看看有没有，有的话，直接找到hosts文件里面的ip
- 如果本地的hosts文件没有能得到对应的ip地址，浏览器会发出一个dns请求到本地dns服务器，本地dns服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动等
- 查询你输入的网址的DNS请求到达本地DNS服务器之后，本地DNS服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果，此过程是递归的方式进行查询。如果没有，本地DNS服务器还要向DNS根服务器进行查询
- 本地DNS服务器继续向域服务器发出请求，在这个例子中，请求的对象是.com域服务器。.com域服务器收到请求之后，也不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器，你的域名的解析服务器的地址
- 最后，本地DNS服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址对应关系，本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。
9.谈谈HTTP与HTTPS的区别
- http协议传输的数据都是未加密的，因此使用http协议传输隐私信息非常不安全。https协议是由ssl+http协议构建的可进行加密传输，身份认证的网络协议，要比http协议安全
- https协议需要到ca申请证书，一般免费的证书较少，因而需要一定的费用
- http和http使用的是完全不一样的连接方式用的端口也不一样，前者是80，后者是443
10.什么是SSL/TLS
SSL代表安全套接字层。它是一种用于加密和验证应用程序（如浏览器）和Web服务器之间发送的数据的协议。
SSL/TLS协议作用：认证用户和服务，加密数据，维护数据的完整性的应用层协议加密和解密需要两个不同的密钥，故被称为非对称加密；
对称加密：优点在于加密、解密效率通常比较高 ，HTTPS 是基于非对称加密的， 公钥是公开的
11.cookies和session的区别
cookie： cookie是服务器发送到用户浏览器并保存的一小块数据，它会在浏览器之后向同一服务器再次发送请求时被携带上，用于告知服务端两个请求是否来自同一浏览器
session： session时存在在服务端的一小块数据。session 的工作原理是客户端登录完成之后，服务器会创建对应的 session，session 创建完之后，会把 session 的 id 发送给客户端，客户端再存储到浏览器中。这样客户端每次访问服务器时，都会带着 sessionid，服务器拿到 sessionid 之后，在内存找到与之对应的 session 这样就可以正常工作了
区别：
- Cookie和Session都是客户端与服务器之间保持状态的解决方案 。存储的位置不同，cookie：存放在客户端，session：存放在服务端。Session存储的数据比较安全
- 存储的数据类型不同 两者都是key-value的结构，但针对value的类型是有差异的 cookie：value只能是字符串类型，session：value是Object类型
- 存储的数据大小限制不同 cookie：大小受浏览器的限制，很多是是4K的大小， session：理论上受当前内存的限制
- 生命周期的控制 cookie的生命周期当浏览器关闭的时候，就消亡了 ，cookie的生命周期是累计的，从创建时，就开始计时，20分钟后，cookie生命周期结束；session的生命周期是间隔的，从创建时，开始计时如在20分钟，没有访问session，那么session生命周期被销毁
12.三次握手
- 第一次握手：客户端发送请求报文，将SYN=1同步序列号和初始化序列号seq=x发送给服务端，发送完后客户端处于SYN_SEND状态（验证了客户端的发送能力和服务端的接收能力）
- 第二次握手：服务端接收到SYN请求报文后，如果同意连接，会已自己的同步序列号SYN=1、初始化序列号seq=y和确认序列号ack=x+1以及确认号ack=1报文作为应答
- 第三次握手：客户端接收到服务端的SYN+ACK之后，知道可以下次发送了，然后发送同步序列号ack=y+1和数据包的序列号seq=y+1以及确认候ack=1作为应答，客户端转为established状态。
13.为什么需要进行三次握手
- 第一次握手：客户端发送网络包，服务端收到了。 这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
- 第二次握手：服务端发包，客户端收到了。 这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
- 第三次握手：客户端发包，服务端收到了。 这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常
如果是两次握手，则会出现这种情况： 如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源
14.四次挥手
建有一个连接需要三次握手，而终止一个连接要经过四次挥手。这是因为TCP的半关闭造成的，所以半关闭其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力
- 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。 即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
- 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。 即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
- 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。 即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
- 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。 即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态
15.为什么要进行四次挥手
任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束
16.TCP与UDP的区别
- TCP面向连接（如打电话要先拨号建立连接)，UDP是无连接的，即发送数据之前不需要建立连接
- TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达，UDP尽最大努力交付，即不保证可靠交付
- TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流，UDP是面向报文的
- UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
- 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
- TCP首部开销20字节;UDP的首部开销小，只有8个字节
- TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
- UDP是面向报文的，发送方的UDP对应用层交下来的报文，不合并，不拆分，只是在其上面加上首部后就交给了下面的网络层，论应用层交给UDP多长的报文，它统统发送，一次发送一个。而对接收方，接到后直接去除首部，交给上面的应用层就完成任务了。因此，它需要应用层控制报文的大小。TCP是面向字节流的，它把上面应用层交下来的数据看成无结构的字节流会发送，可以想象成流水形式的，发送方TCP会将数据放入“蓄水池”（缓存区），等到可以发送的时候就发送，不能发送就等着TCP会根据当前网络的拥塞状态来确定每个报文段的大小。
17.常见的http状态码
2XX——表明请求被正常处理了
- 200 OK：请求已正常处理。
- 204 No Content：请求处理成功，但没有任何资源可以返回给客户端，一般在只需要从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。
- 206 Partial Content：是对资源某一部分的请求，该状态码表示客户端进行了范围请求，响应报文中包含由Content-Range指定范围的实体内容。
3XX——表明浏览器需要执行某些特殊的处理以正确处理请求
- 301 Moved Permanently：永久性重定向
- 302 Found：临时性重定向
- 303 See Other：资源的URI已更新，你是否能临时按新的URI访问。该状态码表示由于请求对应的资源存在着另一个URL，应使用GET方法定向获取请求的资源。303状态码和302状态码有着相同的功能，但303状态码明确表示客户端应当采用GET方法获取资源，这点与302状态码有区别。
- 304 Not Modified：资源已找到，但未符合条件请求。该状态码表示客户端发送附带条件的请求时，服务端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回304.。
- 307 Temporary Redirect：临时重定向。与302有相同的含义。
4XX——表明客户端是发生错误的原因所在。
- 400 Bad Request：服务器端无法理解客户端发送的请求，请求报文中可能存在语法错误。
- 401 Unauthorized：该状态码表示发送的请求需要有通过HTTP认证（BASIC认证，DIGEST认证）的认证信息。
- 403 Forbidden：不允许访问那个资源。该状态码表明对请求资源的访问被服务器拒绝了。（权限，未授权IP等）
- 404 Not Found：服务器上没有请求的资源。路径错误等。
5XX——服务器本身发生错误
- 500 Internal Server Error：该状态码表明服务器端在执行请求时发生了错误。也有可能是web应用存在bug或某些临时故障。
- 503 Service Unavailable：该状态码表明服务器暂时处于超负载或正在停机维护，现在无法处理请求
二、测试理论
1.在项目中你如何保证软件的质量
软件项目质量是整个团队一起努力的结果，最重要的是我们需要一个规范的项目流程，每个岗位各司其职；产品，保证迭代过程中产品逻辑的严谨性，对可能出现的兼容性问题和用户量的升级要做出预判，并尽早给出解决方案；视觉交互，满足产品表达的同时需要尽量的保证设计的延续性；开发编码设计，开发是产品的细节的践行者，在做技术方案的选型的时候要严谨，要尽量的考虑兼容性和可扩展性，性能安全等因素，并且开发完成之后要充分的自测，严格的遵循软件的开发规范；软件测试是保证质量的最后一关，主要验证产品的逻辑和功能并站在用户的角度对产品的交互进行评估，尽可能的使用各种合理的测试手段去保证软件产品的质量
2.说一说你公司的测试流程
3.支付功能如何测试
三、自动化测试
1.为什么要进行接口测试
- 很多系统都是前后端分离的，前后端的工作进度不一样，为了尽早的介入测试，在前端界面没有开发完成的情况下，只要后端的接口开发完成了就可以提前的做接口测试了，这也叫测试左移，在结合自动化测试的手段也可以极大的提高测试效率
- 基于安全的考虑，只依赖前端的约束限制是不够的，毕竟绕过前端验证比较容易，所以我们还要从接口层面在进行验证
2.项目中实践过的接口测试框架
3.谈一谈你对持续集成的认识
四、linux
1.谈一谈你对linux系统的认识
linux是一种自由和开放源码的类unix操作系统，是一个基于POSIX和UNIX的多用户，多任务，支持多线程和多CPU的操作系统
- linux的基本思想：一切皆文件
- linux完全免费的特性，因为开源，用户可以任意修改其源码
- 多用户和多任务性
- Linux支持多种平台，如X86,ARM等多种处理器平台。此外linux还是一种嵌入式操作系统
- 同时支持图形操作和命令行操作
2.常用的linux基本命令有哪些
五、数据库
1.事务的四大特性（ACID）
- 原子性（Atomicity）：原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响
- 一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏。比如A向B转账，不可能A扣了钱，B却没收到
- 隔离性（Isolation）：隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账
- 持久性（Durability）：持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作