HTTPS和HTTP的区别主要如下：
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的
网络协议，比http协议安全。
HTTPS的工作原理
我们都知道HTTPS能够加密信息，以免敏感信息被第三方获取，所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。
客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤，如图所示。
（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。
（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。
（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
（5）Web服务器利用自己的私钥解密出会话密钥。
（6）Web服务器利用会话密钥加密与客户端之间的通信。
四、HTTPS的优点
尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：
（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
（4）谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。
五、HTTPS的缺点
虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：
（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
六、http切换到HTTPS
如果需要将网站从http切换到https到底该如何实现呢？
这里需要将页面中所有的链接，例如js，css，图片等等链接都由http改为https。例如：http://www.baidu.com改为https://www.baidu.com
BTW，这里虽然将http切换为了https，还是建议保留http。所以我们在切换的时候可以做http和https的兼容，具体实现方式是，去掉页面链接中的http头部，这样可以自动匹配http头和https头。例如：将http://www.baidu.com改为//http://www.baidu.com。然后当用户从http的入口进入访问页面时，页面就是http，如果用户是从https的入口进入访问页面，页面即使https的。
提到UI级别测试和API测试之间的关键区别？
UI（用户界面）是指测试图形界面，如用户如何与应用程序交互，测试应用程序元素，如字体，图像，布局等。UI测试基本上侧重于应用程序的外观和感觉。
而API可以实现两个独立的软件系统之间的通信。实现API的软件系统包含可由另一软件系统执行的功能或子例程
请详细阐述接口测试和UI测试在测试活动中是如何协同测试的？
接口测试用例的编写要点有哪些？
1）必填字段：请求参数必填项、可选项
2）合法性：输入输出合法、非法参数
3）边界：请求参数边界值等
4）容错能力：大容量数据、频繁请求、重复请求（如：订单）、异常网络等的处理
5）响应数据校验：断言、数据提取传递到下一级接口...
6）逻辑校验：如两个请求的接口有严格的先后顺序，需要测试调转顺序的情况
7）性能：对接口模拟并发测试，逐步加压，分析瓶颈点
8）安全性：构造恶意的字符请求，如：SQL注入、XSS、敏感信息、业务逻辑（如：跳过某些关键步骤；未经验证操纵敏感数据）
* 测试每个参数类型不合法的情况(类型不合法容易遗漏NULL型)
* 测试每个参数取值范围不合法的情况
* 测试参数为空的情况
* 测试参数前后台定义的一致性
* 测试每个参数的上下限(这里容易出致命的BUG，如果程序处理不当，可能导致崩溃)
* 如果两个请求有严格的先后顺序，需要测试调转顺序的情况
接口自动化测试的流程？
基本的接口功能自动化测试流程为：需求分析-->用例设计-->脚本开发-->测试执行-->结果分析
POST和GET有什么区别？
答案
- GET在浏览器回退时是无害的，而POST会再次提交请求。
- GET产生的URL地址可以被保存为书签，而POST不可以。
- GET请求会被浏览器主动cache，而POST不会，除非手动设置。
- GET请求只能进行url编码，而POST支持多种编码方式。
- GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
- GET请求在URL中传送的参数是有长度限制的，而POST没有。
- GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
- GET参数通过URL传递，POST放在请求Body中。
- GET产生一个TCP数据包，POST产生两个TCP数据包。
- GET请求的URL传参有长度限制，而POST请求没有长度限制
- GET请求的参数只能是ASCII码，所以中文需要URL编码，而POST请求传参没有这个限制；
- GET产生一个TCP数据包；POST产生两个TCP数据包
常见的HTTP Header及其作用
答案
常规HTTP头
Request URL: https://www.jintix.com/
Request Method: GET
Status Code: 200 OK
Remote Address: 14.215.177.38:443
相应头：
Cache-Control: private
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Wed, 27 Mar 2019 09:18:39 GMT
Expires: Wed, 27 Mar 2019 09:18:39 GMT
Server: BWS/1.1
Set-Cookie: H_PS_PSSID=26524_1449_21099_28721_28558_28697_28585_28640_26350_28702; path=/
Strict-Transport-Security: max-age=172800
Transfer-Encoding: chunked
X-Ua-Compatible: IE=Edge,chrome=1
请求头：
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cache-Control: max-age=0
Connection: keep-alive
Cookie: BIDUPSID=8B429E47FD1DA3ED78C8389452B0E8C2; PSTM=1529386822
Host: http://www.baidu.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.84 Safari/537.36
HTTP 与 HTTPS 的区别
答案
- HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
- 使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
- HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
- http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
- HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。
Session与Cookie有什么区别?
答案
- 保存位置。SESSION 数据保存在服务器端，Cookie 数据保存在客户端浏览器
- 保存方式。SESSION 默认被存在在服务器的一个文件里，可以手动设置放在文件、数据库、或内存中；Cookie 默认保存在客户端内存中，如果设置了过期时间就保存在硬盘中。
- 依赖关系。SESSION 依赖 Cookie 来识别 session_id，如果浏览器禁用了 Cookie，SESSION 也会失效，此时可以通过 url 传递 session_id。
- 安全性。因为 SESSION 数据保存在服务端，所以 SESSION安全性比Cookie 高。
- 尺寸大小。SESSION 基本上没有大小限制，COOKIE 保存的内容比较小，具体由浏览器决定。
- 服务器性能。SESSION 对服务器的压力会更大一些，而 Cookie 放在客户端，所以对服务器基本没影响
HTTP通讯过程中，是客户端还是服务端主动断开连接？
答案
不考虑keepalive的情况下，
http1.0
- 带content-length，body长度可知，客户端在接收body时，就可以依据这个长度来接受数据。接受完毕后，就表示这个请求完毕了。客户端主动调用close进入四次挥手。
- 不带content-length，body长度不可知，客户端一直接受数据，直到服务端主动断开
http1.1
- 带content-length body长度可知 客户端主动断开
- 带Transfer-encoding：chunked body会被分成多个块，每块的开始会标识出当前块的长度，body就不需要通过content-length来指定了。但依然可以知道body的长度 客户端主动断开
- 不带Transfer-encoding：chunked且不带content-length 客户端接收数据，直到服务端主动断开连接。
即 ：如果能够有办法知道服务器传来的长度，都是客户端首先断开。如果不知道就一直接收数据。知道服务端断开。
HTTP有哪些请求方法？
HTTP 共有如下7种请求方式，每种都可以发送 Header和 Body：
- GET
- POST
- PUT
- DELETE
- OPTIONS
- HEAD
- PATCH
Cookie 保存在哪里？
答案
- 如果设置了过期时间，Cookie 保存在硬盘中。
- 如果没有设置过期时间，Cookie 保存在内存中。
简述TCP/IP的三次握手和四次挥手
答案
三次握手
起初，服务器和客户端都为 CLOSED 状态。
在通信开始前，双方都得创建各自的传输控制块（TCB）。
服务器创建完 TCB 后遍进入 LISTEN 状态，此时准备接收客户端发来的连接请求。
第一次握手
客户端向服务端发送连接请求报文段。该报文段的头部中SYN=1，ACK=0，seq=x。请求发送后，客户端便进入SYN-SENT状态。
- PS1：SYN=1，ACK=0表示该报文段为连接请求报文。
- PS2：x为本次TCP通信的字节流的初始序号。
- TCP规定：SYN=1的报文段不能有数据部分，但要消耗掉一个序号。
第二次握手 服务端收到连接请求报文段后，如果同意连接，则会发送一个应答：SYN=1，ACK=1，seq=y，ack=x+1。该应答发送完成后便进入SYN-RCVD状态。
- PS1：SYN=1，ACK=1表示该报文段为连接同意的应答报文。
- PS2：seq=y表示服务端作为发送者时，发送字节流的初始序号。
- PS3：ack=x+1表示服务端希望下一个数据报发送序号从x+1开始的字节。
第三次握手
当客户端收到连接同意的应答后，还要向服务端发送一个确认报文段，表示：服务端发来的连接同意应答已经成功收到。该报文段的头部为：ACK=1，seq=x+1，ack=y+1。
客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接的建立完成！
四次挥手
TCP连接的释放一共需要四步，因此称为『四次挥手』。
我们知道，TCP连接是双向的，因此在四次挥手中，前两次挥手用于断开一个方向的连接，后两次挥手用于断开另一方向的连接。
第一次挥手
若A认为数据发送完成，则它需要向B发送连接释放请求。该请求只有报文头，头中携带的主要参数为： FIN=1，seq=u。此时，A将进入 FIN-WAIT-1 状态。
- PS1：FIN=1表示该报文段是一个连接释放请求。
- PS2：seq=u，u-1是A向B发送的最后一个字节的序号。
第二次挥手
B收到连接释放请求后，会通知相应的应用程序，告诉它A向B这个方向的连接已经释放。此时B进入CLOSE-WAIT状态，并向A发送连接释放的应答，其报文头包含： ACK=1，seq=v，ack=u+1。
- PS1：ACK=1：除TCP连接请求报文段以外，TCP通信过程中所有数据报的ACK都为1，表示应答。
- PS2：seq=v，v-1是B向A发送的最后一个字节的序号。
- PS3：ack=u+1表示希望收到从第u+1个字节开始的报文段，并且已经成功接收了前u个字节。
A收到该应答，进入FIN-WAIT-2状态，等待B发送连接释放请求。
第二次挥手完成后，A到B方向的连接已经释放，B不会再接收数据，A也不会再发送数据。但B到A方向的连接仍然存在，B可以继续向A发送数据。
第三次挥手
当B向A发完所有数据后，向A发送连接释放请求，请求头：FIN=1，ACK=1，seq=w，ack=u+1。B便进入LAST-ACK状态。
第四次挥手
A收到释放请求后，向B发送确认应答，此时A进入TIME-WAIT状态。
该状态会持续2MSL时间，若该时间段内没有B的重发请求的话，就进入 CLOSED 状态，撤销TCB。
当B收到确认应答后，也便进入 CLOSED 状态，撤销 TCB。
为什么A要先进入TIME-WAIT状态，等待2MSL时间后才进入 CLOSED 状态？为了保证B能收到A的确认应答。若A发完确认应答后直接进入 CLOSED 状态，那么如果该应答丢失，B等待超时后就会重新发送连接释放请求，但此时A已经关闭了，不会作出任何响应，因此B永远无法正常关闭。
TCP和UDP有什么区别
答案
- TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
- TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
- TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
- 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
- TCP首部开销20字节;UDP的首部开销小，只有8个字节
- TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
什么是TCP/IP？
答案
TCP/IP，也就是互联网协议套件（英语：Internet Protocol Suite，缩写IPS）是一个网络通信模型，以及一整个网络传输协议家族，为网际网络的基础通信架构。
因为该协议家族的两个核心协议：TCP（传输控制协议）和IP（网际协议）为该家族中最早通过的标准，所以它常被通称为TCP/IP协议族，简称TCP/IP。
由于在网络通讯协议普遍采用分层的结构，当多个层次的协议共同工作时，类似计算机科学中的堆栈，因此又被称为TCP/IP协议栈。
TCP/IP提供点对点的链接机制，将数据应该如何封装、定址、传输、路由以及在目的地如何接收，都加以标准化。
它将软件通信过程抽象化为四个抽象层，采取协议堆栈的方式，分别实现出不同通信协议。
协议族下的各种协议，依其功能不同，被分别归属到这四个层次结构之中，常被视为是简化的七层OSI模型。
1.json和字典的区别？-对基础数据类型的考察
2.测试的数据你放在哪？-数据与脚本分离
3.参数化 - 数据驱动模式
4.下个接口请求参数依赖上个接口的返回数据 - 参数关联
5.依赖于登录的接口如何处理 -token和session的管理
6.依赖第三方的接口如何处理 -mock模拟数据返回
7.不可逆的操作，如何处理，比如删除一个订单这种接口如何测试 -造数据
8.接口产生的垃圾数据如何清理 - 数据清理
9.一个订单的几种状态如何全部测到，如：未处理，处理中，处理失败，处理成功 - 造数据，改数据库订单状态
10.python如何连接数据库操作？
11.其它的就是运行出报告、代码管理（git）、运行策略和持续集成jenkins相关了
1.json和字典dict的区别？
现在自动化培训烂大街，是个人都能说的上几个框架，面试如果问框架相关问题，求职者只需一瓶82年的雪碧，会吹的让你怀疑人生！
所以面试官为了更清楚的知道你是停留在表面上的花拳绣腿还是有扎实的基础，就不会问框架这种东西了。基本上问几个数据类型的基础就知道有没货了。
那么json和字典到底有什么区别呢?初学者连python的基础数据类型都没搞清楚，直接撸框架，有的人学了几个月可能都迷迷糊糊的，以为json就是字典。这个是肯定不对的。
首先python里面的基础数据类型有：int、str、 float、list、bool、tuple、dict、set这几种类型，里面没json这种数据类型。
JSON(JavaScript Object Notation, JS 对象简谱) 是一种轻量级的数据交换格式。它基于 ECMAScript (欧洲计算机协会制定的js规范)的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得 JSON 成为理想的数据交换语言。易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。
由于你的代码是python写的（也有可能是php,java,c，ruby等语言）,但是后端接口是java写的（也有可能是其它语言），不同的语言数据类型是不一样的（就好比中国的语言和美国的语言数据类型也不一样，中国的一般说一只羊，一头牛，美国都是 a /an这种单位），所以就导致你提交的数据，别的开发语言无法识别，这就需要规范传输的数据（传输的数据都是一个字符串），大家都遵循一个规范，按一个标准的格式去传输，于是就有就json这种国际化规范的数据类型。
json本质上还是字符串，只是按key：value这种键值对的格式来的字符串
import json
# a是字典dict
a = {"a": 1, "b": 2, "c": True}
# b是json
b = '{"a": 1, "b": 2, "c": true}'
print(type(a))
print(json.dumps(a)) # a转json
运行结果
<class 'dict'>
{"a": 1, "b": 2, "c": true}
<class 'str'>
{'a': 1, 'b': 2, 'c': True}
2.测试的数据你放在哪?
测试数据到底该怎么放，没有标准的答案，可以放到excel，也可以放到json，yaml文件里，也可以放到.py脚本，也有的说放ini配置文件，
以下两个大忌不能回答：
- 测试的数据是不能写死到代码里面的，这个是原则问题，也是写代码的大忌（你要是回答写在代码里面，估计就是回去等通知了）
- 测试数据放到.py的开头，这种其实很方便，对于少量的，固定不变的数据其实是可以放的，但是面试时候，千万不能这样说，面试官喜欢装逼的方法
测试数据存放总结：
1.对于账号密码，这种管全局的参数，可以用命令行参数，单独抽出来，写的配置文件里（如ini）
2.对于一些一次性消耗的数据，比如注册，每次注册不一样的数，可以用随机函数生成
3.对于一个接口有多组测试的参数，可以参数化，数据放yaml,text,json,excel都可以
4.对于可以反复使用的数据，比如订单的各种状态需要造数据的情况，可以放到数据库，每次数据初始化，用完后再清理
5.对于邮箱配置的一些参数，可以用ini配置文件
6.对于全部是独立的接口项目，可以用数据驱动方式，用excel/csv管理测试的接口数据
7.对于少量的静态数据，比如一个接口的测试数据，也就2-3组，可以写到py脚本的开头，十年八年都不会变更的
总之不同的测试数据，可以用不同的文件管理
3.什么是数据驱动，如何参数化？
参数化和数据驱动的概念这个肯定要知道的，参数化的思想是代码用例写好了后，不需要改代码，只需维护测试数据就可以了，并且根据不同的测试数据生成多个用例
python里面用unittest框架
import unittest
import ddt
# 测试数据
datas = [ {"user": "admin", "psw": "123", "result": "true"},
{"user": "admin1", "psw": "1234", "result": "true"},
{"user": "admin2", "psw": "1234", "result": "true"},
{"user": "admin3", "psw": "1234", "result": "true"},
{"user": "admin4", "psw": "1234", "result": "true"},
{"user": "admin5", "psw": "1234", "result": "true"},
{"user": "admin6", "psw": "1234", "result": "true"},
{"user": "admin7", "psw": "1234", "result": "true"},
{"user": "admin8", "psw": "1234", "result": "true"},
{"user": "admin9", "psw": "1234", "result": "true"},
{"user": "admin10", "psw": "1234", "result": "true"},
{"user": "admin11", "psw": "1234", "result": "true"}]
@ddt.ddt
class Test(unittest.TestCase):
@ddt.data(*datas)
def test_(self, d):
print("测试数据：%s" % d)
if __name__ == "__main__":
unittest.main()
unittest框架还有一个paramunittest也可以实现
import unittest
import paramunittest
import time
@paramunittest.parametrized(
{"user": "admin", "psw": "123", "result": "true"},
{"user": "admin1", "psw": "1234", "result": "true"},
{"user": "admin2", "psw": "1234", "result": "true"},
{"user": "admin3", "psw": "1234", "result": "true"},
{"user": "admin4", "psw": "1234", "result": "true"},
{"user": "admin5", "psw": "1234", "result": "true"},
{"user": "admin6", "psw": "1234", "result": "true"},
{"user": "admin7", "psw": "1234", "result": "true"},
{"user": "admin8", "psw": "1234", "result": "true"},
{"user": "admin9", "psw": "1234", "result": "true"},
{"user": "admin10", "psw": "1234", "result": "true"},
{"user": "admin11", "psw": "1234", "result": "true"},
)
class TestDemo(unittest.TestCase):
def setParameters(self, user, psw, result):
'''这里注意了，user, psw, result三个参数和前面定义的字典一一对应'''
self.user = user
self.user = psw
self.result = result
def testcase(self):
print("开始执行用例：--------------")
time.sleep(0.5)
print("输入用户名：%s" % self.user)
print("输入密码：%s" % self.user)
print("期望结果：%s " % self.result)
time.sleep(0.5)
self.assertTrue(self.result == "true")
if __name__ == "__main__":
unittest.main(verbosity=2)
如果用的是pytest框架，也能实现参数化
# content of test_canshu1.py
# coding:utf-8
import pytest
@pytest.mark.parametrize("test_input,expected",
[ ("3+5", 8),
("2+4", 6),
("6 * 9", 42),
])
def test_eval(test_input, expected):
assert eval(test_input) == expected
if __name__ == "__main__":
pytest.main(["-s", "test_canshu1.py"])
pytest里面还有一个更加强大的功能，获得多个参数化参数的所有组合，可以堆叠参数化装饰器
import pytest
@pytest.mark.parametrize("x", [0, 1])
@pytest.mark.parametrize("y", [2, 3])
def test_foo(x, y):
print("测试数据组合：x->%s, y->%s" % (x, y))
if __name__ == "__main__":
pytest.main(["-s", "test_canshu1.py"])
4.下个接口请求参数依赖上个接口的返回数据
这个很容易，不同的接口封装成不同的函数或方法，需要的数据return出来，用一个中间变量a去接受，后面的接口传a就可以了
参考这篇【python接口自动化26-参数关联和JSESSIONID(上个接口返回数据作为下个接口请求参数)】
5.依赖于登录的接口如何处理
登录接口依赖token的，可以先登录后，token存到一个yaml或者json，或者ini的配置文件里面，后面所有的请求去拿这个数据就可以全局使用了
参考之前分享的一篇python接口自动化24-有token的接口项目使用unittest框架设计
如果是cookies的参数，可以用session自动关联
s=requests.session()
后面请求用s.get()和s.post()就可以自动关联cookies了
6.依赖第三方的接口如何处理
这个需要自己去搭建一个mock服务，模拟接口返回数据，参考【python笔记25-mock-server之moco】(https://www.cnblogs.com/yoyoketang/p/9348552.html)
moco是一个开源的框架，在github上可以下载到https://github.com/dreamhead/moco
moco服务搭建需要自己能够熟练掌握，面试会问你具体如何搭建 ，如何模拟返回的数据，是用的什么格式，如何请求的
7.不可逆的操作，如何处理，比如删除一个订单这种接口如何测试
此题考的是造数据的能力，接口的请求数据，很多都是需要依赖前面一个状态的
比如工作流这种，流向不同的人状态不一样，操作权限不一样，测试的时候，每种状态都要测到,就需要自己会造数据了。
平常手工测试造数据，直接在数据库改字段状态。那么自动化也是一样，造数据可以用python连数据库了，做增删改查的操作
测试用例前置操作，setUp做数据准备
后置操作，tearDown做数据清理
8.接口产生的垃圾数据如何清理
跟上面一样，造数据和数据清理，需用python连数据库了，做增删改查的操作
测试用例前置操作，setUp做数据准备
后置操作，tearDown做数据清理
9.一个订单的几种状态如何全部测到，如：未处理，处理中，处理失败，处理成功
跟上面一样，也是考察造数据，修改数据的状态
10.python如何连接数据库操作？
详情参考教程http://www.runoob.com/python3/python3-mysql.html
#!/usr/bin/python3
# 查询EMPLOYEE表中salary（工资）字段大于1000的所有数据：
import pymysql
# 打开数据库连接
db = pymysql.connect("localhost","testuser","test123","TESTDB" )
# 使用cursor()方法获取操作游标
cursor = db.cursor()
# SQL 查询语句
sql = "SELECT * FROM EMPLOYEE \
WHERE INCOME > %s" % (1000)
try:
# 执行SQL语句
cursor.execute(sql)
# 获取所有记录列表
results = cursor.fetchall()
for row in results:
fname = row[0]
lname = row[1]
age = row[2]
sex = row[3]
income = row[4]
# 打印结果
print ("fname=%s,lname=%s,age=%s,sex=%s,income=%s" % \
(fname, lname, age, sex, income ))
except:
print ("Error: unable to fetch data")
# 关闭数据库连接
db.close()
其它的就是运行出报告、代码管理（git）、运行策略和持续集成jenkins相关了，这个所以的自动化但是一样的，后面会单独讲一篇jenkins持续集成相关
在API测试中测试的常用协议是什么？
HTTP
JMS
REST
SOAP
UDDI
接口测试的步骤有哪些？
1）发送接口请求
2）测试接口获取返回值
3）断言：判断实际结果是否符合预期
接口测试中依赖登录状态的接口如何测试？
依赖登最状态的接口，本质上是在每次发送请求时需要带上存储有账户有效信息的Session或Cookie才能发送成功，在构建POST请求时添加必要的Session或Cookie
依赖于第三方数据的接口如何进行测试？
可以利用一些MOCK工具（如：JSON Server、Easy Mock）来模拟第三方的数据返回，最大限度的降低对第三方数据接口的依赖
解释什么是SOAP？
SOAP代表简单对象访问控制，它是一种基于XML的协议，用于在计算机之间交换信息。
解释什么是REST API？
这是开发人员执行请求并接收响应的一组功能。在REST API中，通过HTTP协议进行交互
REST - 代表状态转移，它正快速成为API创建的标准。
API Builder如何工作？
API Builder是一个由四个SQL文件组成的PLSQL程序
要设置API参数并启动该过程，一个文件是负责的
为临时表和主包创建两个文件以创建输出的代码
第四个文件将代码的“假脱机”输出创建为一个名为“output_script_.sql”的文件
解释什么是TestApi？
TestApi是一个实用程序和测试API库，可让测试人员和开发人员为.NET和Win32应用程序创建测试工具和自动测试。它提供了一套常见的测试构建块，类型，数据结构和算法。
什么是使用runscope的API测试？
Runscope是一个Web应用程序，它提供后端服务和易于使用的界面来测试API。
解释API测试设计的原理是什么？
API测试设计的原理是
安装：创建对象，启动服务，初始化数据等
执行：执行API或场景的步骤，也记录日志
验证：比较预期结果和实际结果
报告：查看执行情况，通过，失败或阻止
清理：回到最初的测试状态
API测试发现的Bug类型是什么？
缺少或重复的功能
无法正常处理错误条件
强调
可靠性
安全
未使用的标志
未实现错误
错误处理不一致
性能
多线程问题
错误不正确
我们测试的接口属于哪一类？
服务器接口（基于HTTP协议的接口）
大多数人常说的接口测试，通常是 B/S架构，由客户端（浏览器）调用，或模拟客户端（浏览器）调用服务器提供的请求接口，由服务器完成处理并返回一个应答的过程。
例如：Webservice接口，http接口，jms接口，hessian接口。
TCP长连接和短连接的区别
TCP长连接和短连接的区别
当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次挥手，所以说每个连接的建立都是需要资源消耗和时间消耗的
长连接：
所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，一般需要自己做在线维持（不发生RST包和四次挥手）。
连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接（一个TCP连接通道多个读写通信）；
这就要求长连接在没有数据通信时，定时发送数据包(心跳)，以维持连接状态；
TCP保活功能，保活功能主要为服务器应用提供，服务器应用希望知道客户主机是否崩溃，从而可以代表客户使用资源。如果客户已经消失，使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，则服务器将应远等待客户端的数据，保活功能就是试图在服务器端检测到这种半开放的连接。
如果一个给定的连接在两小时内没有任何的动作，则服务器就向客户发一个探测报文段，客户主机必须处于以下4个状态之一：
- 客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常的，服务器在两小时后将保活定时器复位。
- 客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。服务端将不能收到对探测的响应，并在75秒后超时。服务器总共发送10个这样的探测 ，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。
- 客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
- 客户机正常运行，但是服务器不可达，这种情况与2类似，TCP能发现的就是没有收到探查的响应。
短连接：
短连接是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接（管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段）；
连接→数据传输→关闭连接；
应用场景：
长连接多用于操作频繁（读写），点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
而像WEB网站的http服务一般都用短链接（http1.0只支持短连接，1.1keep alive 带时间，操作次数限制的长连接），因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好；
Session和cookie的区别
cookie
cookie的原理和作用
cookie的原理
什么是cookie
分类两种
内存cookie
相关的cookie信息存放在浏览器的缓存中
如果浏览器关闭后，cookie信息被释放
硬盘cookie
cookie信息是保存在客户端机器的硬盘中
永久保存，可以反复读取，除非用户执行删除操作
易用性好
安全性差
为什么要有cookie，它的作用是什么？
cookie有什么作用？
cookie可以解决http的无状态的问题，与服务器进行交互，作为http规范存在。它具有极高的简便性、可扩展性和可用性，也可以通过加密和SSL技术来提高其安全性。因此推荐使用cookie作为标识而不是身份验证的工具。
其中cookie的作用就是为了解决HTTP协议无状态的缺陷所作出的努力
cookie测试点
Cookie测试的测试点
1.禁止使用Cookie
设置浏览器禁止使用Cookie，访问网页后，检查存放Cookie文件中未生成相关文件；
2.Cookie存储路径
按照操作系统和浏览器对Cookie存放路径的设置，检查存放路径是否与设置一致；
3.Cookie过期检查
按照Cookie过期时间，检查存放文件该Cookie是否被自动删除
4.检查浏览器中Cookie选项
通过不同浏览器，设置是否接受Cookie文件，如同意接受Cookie，检查存放路径中是否存在Cookie文件
5.浏览器删除Cookie
通过浏览器的设置，删除Cookie文件
6.Cookie加密
提交敏感信息时，数据应加密
7.Cookie保存信息
验证Cookie能正常工作
8.篡改Cookie
修改Cookie内容，查看系统功能是否出现异常，或数据错乱
9.Cookie的兼容性
使用不同类型，或同一类型不同版本的浏览器，检查cookie文件的兼容性
10.刷新操作对cookie的影响
进行刷新操作后，是否重新生成cookie文件或是对cookie文件进行修改
11.检查cookie内容存储是否完整正确
若cookie进行了加密，先对cookie文件内容进行解密，然后检查是否按照设计要求存储了相关所有的cookie记录信息。
12.对应硬盘存储空间没有空闲时，是否能进行cookie内容的有效存储
13.多次做相同的操作或设置，检查是否更新或添加了新的cookie文件
按照设计要求进行判断
14.如果使用cookie来统计次数，则要检测是否统计正确
例如通过用户登录次数进行统计
1,访问网站，每次都需要输入用户名和密码
分第一次登陆还是非第一次登录
cookie的缺点
（1） 大小和数目受限制。浏览器对一个域cookie的条目数有上限要求，且每个cookie的大小不得超过4kb。
（2）存在安全性问题，易被人拦截。
（3）需要指定域，不可以跨域
（4）浪费带宽，因为我每次请求一个新的页面，cookie都会被自动发送过去。
（5）有的移动端浏览器不支持cookie或浏览器禁用cookie
（6）有些状态不可能保存在客户端。例如，为了防止重复提交表单，我们需要在服务器端保存一个计数器。如果我们把这个计数器保存在客户端，那么它起不到任何作用。
session
session的作用
1，为什么要是用cookie
a:方便用户进行登录
b：收集用户的相关登录时间，时长，使用习惯
2，为什么要是使用session
s1：登录网站后
s2：跳转到其他页面
其他协议
无状态协议
不记录用户身份信息
产生的问题
1，只要
2，任意人都
s3：产生了session技术处理
3，session的原理
1：当用户注册后
2，在本地生成cookie文件，保留用户信息
3，用户登录
1，系统检查本地是否存在cookie文件
若不存在，等待登录后，
在本地创建cookie文件
2，若已存在，系统在用户登录的同时，由服务器端口自动随机分配一个sessionID传入cookie文件
4，若用户打开某个需要权限设置的页面，系统回去检查对应的sessionID是否存在有效正确
session机制则是又一种在客户端与服务器之间保持状态的解决方案。
session的测试点
用户登录系统时，服务器给发送随机的sessionID
页面跳转时进行身份的验证
测试前沟通准备工作
cookie与session的区别：
1、cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
5、所以个人建议：
将登陆信息等重要信息存放为session
其他信息如果需要保留，可以放在cookie中