接口测试基础学习笔记

一、接口测试理论

1.移动互联网公司技术架构

2.网络协议

tcp与udp的区别：
tcp：面向链接、错误重传、拥塞控制，适用于可靠性高的场景；
udp：不需要提前建立连接，实现简单，适用于实时性高的场景；

3.Restful软件架构风格

Restful：Representational State Transfer
借助于http协议的基本请求方法代表资源的状态切换
post：新增或更新
get：获取资源
put：更新资源
delete：删除资源
github有rest api的详细解释：https://developer.github.com/v3/

4.RPC协议

RPC协议：Remote Procedure Call，以本地代码调用的方式实现远程执行；

支持RPC的开源项目，如下：
Dubbo：
Java上的高性能RPC协议，Apache开源项目，由阿里捐赠
底层应用层协议支持dubbo缺省tcp协议、http、hessian、thrift、grpc等；
gRPC：
高性能通用RPC框架，基于Protocol Buffers（PB）；
PB是一个语言中立、平台中立的数据序列化框架（性能更高）。Google开源项目。
Throft：
与gRPC类似的多语言RPC框架，Apache开源项目。

二、接口协议分析

1.协议分析工具

协议客户端工具：curl、postman

2.tcpdump

常用参数：
-x 十六进制展示
-w file 保存文件
常用表达式：
ip tcp协议
host主机名
port 80
src 来源 dst 目的
and or () 逻辑表达式

用法示例：

例如手机端可以用tcpdump抓包，然后将抓包后文件导出，导入到WireShark里面进行查看和分析。
举例：抓取访问百度的数据包
sudo tcpdump host www.baidu.com -w /tmp/tcpdump.log
curl http://www.baidu.com 访问百度
停止tcpdump
使用wireshark打开/tmp/tcpdump.log

抓包查看tcp协议的三次握手与四次挥手：

三次握手和四次挥手都是由客户端首先发起发起，由服务端回复确认，最后由客户端确认发起请求和结束请求。

3.使用curl命令发送请求

（1）http协议组成

target（通用）：url、protocol、host、port
request（请求体）：
request：get、post、put、delete、head
header：host、cookie、user-agent
get query（get带入参数）
post body：json、xml、form
response（返回体）：
status line
header
body

（2）谷歌浏览器copy as curl的作用

右键左侧请求数据，选择Copy->copy as curl,把浏览器发送的请求真实的还原出来；
附带了认证信息，所以可以脱离浏览器执行；
可以方便开发者重放请求、修改参数调试，编写脚本；

对复制出来的curl命令进行细化，加上"-v"参数可以打印更详细的信息的内容，用"2>&1"将标准错误重定向到标准输出，发送此命令将得到细化后的内容，举例使用方法：curl命令 -v 2>&1 >test.log

（3）客户端常用的模拟请求工具

nc tcp/udp协议发送
curl最常使用的http请求工具
postman综合性的http协议测试工具
代理工具（burpsuite等）、IDE工具、浏览器插件工具

（4）curl常见用法

url=http://www.baidu.com
get请求 curl $url
post请求 curl -d ‘xxx’ $url
proxy使用 curl -x ‘http://127.0.0.1:8080’ $url

（5）curl命令重要参数

参数	说明
-H	-H "Content-Type:application/json"消息头设置
-u	-u username:password用户认证
-d	要发送的post数据 @file表示来自于文件
--data-urlencode	–data-urlencode 'page_size=50’对内容进行url编码
-G	把data数据当成get请求的参数发送，长与–data-urlencode结合使用
-o	写文件
-x	代理 （http代理 socks5代理）
-v	-v verbose打印更详细日志
-s	关闭一些提示输出

curl命令后，可以添加| jq命令可以让json输出格式方便查看；

三、代理工具介绍

1.常用代理工具

2.代理的工作机制

Upstream Proxy Mode:上游代理
Reverse Proxy:反向代理
Transparent Proxy:透明代理
Regular Proxy:正向代理

3.代理工具推荐

（1）优秀代理工具需要具备的功能
代理功能：http/https、socks5
请求模拟工具：拼装请求、重放请求，重复请求
网络环境模拟：限速、超时、返回异常
mock：请求修改、响应修改
fake：用测试环境替代真实环境
（2）推荐工具
charls：开发/测试工程师必备
mitmproxy：测试开发工程师必备
zap：测试工程师安全测试工具
burpsuite：黑客必备渗透测试工具
fiddler：跨平台支持不好，不推荐（不支持mac）
postman：代理功能太弱，不推荐

四、http/https抓包分析（charles为例）

1.代理配置步骤

配置代理、获取证书、安装证书、信任证书

以Charles为例：
配置代理，proxy->proxy settings

浏览器可用SwitchyOmega做代理管理（这里我用的火狐浏览器）

如下链接可以安装证书：
http://chls.pro/ssl
访问百度，查看证书，这样https的包将能够被charls获取；

简单mock：
charles上方，Tools->Rewrite，修改body里某个字段
复杂mock：
charles可以选择某个请求，右键选择map local实现更换返回数据，制造mock数据；（Tools->Map local需要开启）
整体测试环境：
harles可以选择某个请求，右键选择map remote（Tools->Map remote需要开启）

可以使用Linux让文件里的数据不断翻倍，来造大量的测试数据，然后再用Map local导入json文件；
如下对raw文件里的data下的items和items_size翻倍：

2.Android证书信任问题

五、http协议

1.http报文结构

（1）请求报文
HTTP 请求报文由请求行、请求头部、空行 和 请求包体 4 个部分组成，如下图：


（2）响应报文
HTTP 响应报文由状态行、响应头部、空行 和 响应包体 4 个部分组成，如下图：

2.请求报文方法

方法	意义	详细说明
OPTION	请求一些选项信息	用于获取当前URL所支持的方法。若请求成功，会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。
GET	请求读取由URL所标志的信息	传递参数长度受限制，因为传递的参数是直接表示在地址栏中，而特定浏览器和服务器对url的长度是有限制的。因此，GET不适合用来传递私密数据，也不适合拿来传递大量数据
HEAD	请求读取由URL所标志的信息的首部	HEAD跟GET相似，不过服务端接收到HEAD请求时只返回响应头，不发送响应内容。所以，如果只需要查看某个页面的状态时，用HEAD更高效，因为省去了传输页面内容的时间。
POST	给服务器添加信息	POST把传递的数据封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据，对数据量没有限制，也不会显示在URL中
PUT	在指明的URL下存储一个文档	本质上来讲， PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器自己决定。
DELETE	删除指明的URL所标志的资源
TRACE	用来进行环回测试的请求报文	回显服务器收到的请求，主要用于测试或诊断。
CONNECT	用于代理服务器	CONNECT方法是HTTP/1.1协议预留的，能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接与非加密的HTTP代理服务器的通信。

如上有参考：HTTP报文结构和内容（转）

3.常见状态码

状态行有5个大类，由第一位数字进行区分，每个大类下面还有不同的子类，每种子类的长度都是3位，都代表一个状态码，即一种类型的返回的信息。

如下为5大类说明：
1xx：表示通知信息，如请求收到了或正在进行处理;
2xx：表示服务器已成功接收到请求并进行处理，如接受或通知了；
3xx：表示服务器要求客户端重定向，如果要完成请求还必须采取进一步的行动；
4xx：表示客户端的请求有非法内容（客户的差错）;
5xx：表示服务器未能正常处理客户端的请求而出现意外错误（服务器的差错）;

4.session、cookie和token区别

cookie由服务器生成，发送给浏览器，浏览器以KV形式存储到某个目录下的文本文件中，下一次请求同一网站时会把该cookie发送给服务器。

session从字面上讲，就是会话。这个就类似你和一个人交谈，你怎么知道当时和你交谈的是小红而不是小明呢？对方肯定有某种特征表面他是小红；
session也是类似的道理，服务器要知道当前请求发给自己的是谁。为了做这种区分，服务器就是要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发送请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。
至于客户端怎么保存这个“身份标识”，可以有很多方式，对于浏览器客户端，大家都采用cookie的方式。

token也称作令牌，由uid+time+sign[+固定参数];
token的认证方式类似于临时的证书签名，并且是一种服务端无状态的认证方式，非常适合于rest api的场景。所谓的无状态就是服务端并不会保存身份认证相关的数据。

三者的区别：
（1）存储位置不同：cookie数据存放在客户的浏览器上，session数据存放在服务器上。
（2）隐私策略不同：
cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session；
session会在一定时间内保存在服务器上。当访问增多，就会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie；
session是一种http存储机制，为无状态的http提供持久机制；
token就是令牌，比如你授权（登录）一个程序时，她就是个依据，判断你是否已经授权该软件；
session和token并不矛盾，作为身份认证token安全性比session好，因为每一个请求都有签名还能防止监听以及重放攻击，而session就必须依赖链路层来保障通信安全。如上所述，如果你需要实现有状态的回话，仍然可以增加session来在服务端保存一些状态。