web 接口测试基本概念

这篇是参考了临渊的博客 https://www.cnblogs.com/superhin/p/10338915.html

接口概念

接口又称API（Application Programming Interface,应用程序编程接口），是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。
（通俗的来说）：
首先我有一些功能（功能函数）
你不用关心我怎么实现的（屏蔽细节）
我会给你一个我的地址（接口地址）
你按照地址找到我，按照我规定的格式（请求类型）告诉我所需要的信息（参数）就行
我会给你个反馈（响应信息）

常见接口类型

HTTP接口：通过HTTP协议传输的接口，可以传输文本表单数据，也可以传输Json类型的对象数据或xml类型的数据
RPC: 远程方法调用，随着分布式系统的出现，当你需要调用部署到其他服务器上的方法时，需要用到RPC。RPC只是提出了这样一个问题，有很多种解决方案，比如WebService(基于SOAP协议)， REST(基于HTTP协议）。
SOAP: 简单面向对象协议，基于HTTP，使用xml作为默认传输格式
Web Service: 基于SOAP协议的一种RPC实现方案。相比传统的HTTP接口只传输文本请求和文本相应，通过Web Service可以直接拿到远程的一个对象，并能够直接调用该对象的属性和方法，比HTTP更高级。
REST/RESTful API: REST，表述性状态转移。一种HTTP接口的设计风格，将一切接口视为资源，要求接口路径同意管理，分版本管理，规定了GET/POST等请求以及HTTP状态码的使用规范，默认使用JSON格式传输。RESTful API即满足REST风格即设计规范的API接口

什么是接口测试？

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个
子系统之间的交互点。测试的重点是要检查数据的交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
为什么要做接口测试？

接口测试介于单元测试与系统测试之间，单元测试一般由开发完成（不要相信开发）
接口是各种系统功能的基础，一旦接口出现问题可能会引起许多系统功能的问题并且不容易定位
开展接口测试可以及早发现问题，有效降低测试成本
接口一般较UI相对稳定，利于进行自动化和持续集成

接口测试和业务测试在设计测试和执行测试过程中的差异点:在接口测试中，我们通过单个接口测试完成了全部异常状态的覆盖；而在业务流程中，我们更需要关心业务流和数据流的关系，并不需要再过度关心如何用业务流的方法覆盖更多的代码逻辑异常。
接口测试的思维先从单个接口的测试开始，保障单个接口的正确性和健壮性，然后通过单个接口的测试完成多个接口的业务逻辑串联，站在业务逻辑的角度完成业务逻辑的正确性检测。

网络基础知识：IP,域名, DNS及端口

IP地址

IP地址是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址。

image.png

查看IP命令
Windows: ipconfig
Linux: ifconfig
tip num.isdigit()可以判断num是否只由数字组成

端口

"端口"是英文port的意译，可以认为是设备与外界通讯交流的出口。
如果把IP地址比作一间房子，端口就是出入这间房子的门。一个IP地址的端口可以有65536（即：2^16）个
公认端口：从0到1023，紧密绑定于一些服务
注册端口：人1024到49151，许多服务绑定这些端口，这些端口同样用于许多其它目的。
动态或私有端口：从49152到65535。理论上，不应为服务分配这此端口。实际上，机器通常从1024起分配动态端口。
常见软件默认端口
Apache/Nginx(HTTP服务): 80
Tomcat: 8080
Oracle: 1521
MySQL: 3306
SQL Server: 1433
PostgreSQL: 5432
MongoDB: 27017
Redis: 6379
Memcached: 11211
查看端口命令
Windows: netstat -ano
Linux: netstat -ntlp
解决端口占用问题
Windows: netstat -ano | findstr "8080",找到占用端口的程序的PID -> 打开任务管理器 -> 设置显示PID -> 找到并结束对于程序
Linux: netstat -ntlp | grep "8080", 找到对应的程序 -> ps -ef | grep "程序名" 找到对于的pid -> kill 相应的id

域名及DNS

由于IP地址不容易记忆，为IP地址赋予了一个利于记忆的别名，称为域名
如，百度的ip为： 61.135.169.125，对应的域名为 www.baidu.com
如何查看域名所对于的ip？
Windows/Linux: ping www.baidu.com

DNS

DNS即域名解析系统，域名和IP地址相互映射的一个分布式数据库，提供域名转到对应ip的服务

网络基础知识：OSI七层模型及TCP协议

OSI七层模型

OSI即开放系统互连参考模型，一种网络架构，分为7层。

image.png

TCP及UDP协议

TCP和UDP都是传输层的协议

TCP：传输控制协议
UDP: 数据报文协议
TCP和UDP的区别
UDP的特点如下：
1.无链接
2.UDP使用尽最大努力交付，不保证可靠性
3.UDP是面向报文的，UDP对应用层交付下来的报文，既不合并，也不拆分，而是保留这些报文的边界。应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文

UDP没有拥塞控制
UDP支持一对一、一对多、多对一和多对多的交互通信
UDP的首部开销小，只有8字节

TCP的特点：

TCP是面向连接的
每条TCP连接只能用于两个断点，一对一
TCP提供可靠交付的服务：连接传输数据、无差错、不丢失、不重复、并且按序到达
TCP提供全双工通信
面向字节流。TCP根据对方给出的窗口和当前网络拥塞的程度来决定一个报文应该包含多少个字节

三次握手和四次挥手

三次握手

简单理解，不一定准确：

client首先将SYN标志位置1并指明客户端打算连接的服务器的端口，然后发送给服务端，客户端进入SYN_SENT状态等待服务端确认。
服务端收到SYN=1的信号后知道要连接，将标志位SYN和ACK都置为1，产生一个随机序列一并都发送回客户端确认连接，服务端进入SYN_RCVD状态。
客户端收到服务端信号后确认ACK是否为1，为1后将TCP标志位ACK置1发送回服务端，服务端确认后连接成功。
三次握手的意义
若不采用三次握手，那么只要server发出确认，新的连接就建立了，但有可能这个信号是client在很早之前发出的请求信号，在某个网络节点滞留了，不需要连接时才到达server，这样导致client不会理睬server的这次确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。

四次挥手

挥手请求可以是Client端，也可以是Server端发起的，我们假设是Client端发起：

第一次挥手： Client端发起挥手请求，向Server端发送标志位是FIN报文段，设置序列号seq，此时，Client端进入FIN_WAIT_1状态，这表示Client端没有数据要发送给Server端了。
第二次分手：Server端收到了Client端发送的FIN报文段，向Client端返回一个标志位是ACK的报文段，ack设为seq加1，Client端进入FIN_WAIT_2状态，Server端告诉Client端，我确认并同意你的关闭请求。
第三次分手： Server端向Client端发送标志位是FIN的报文段，请求关闭连接，同时Client端进入LAST_ACK状态。
第四次分手： Client端收到Server端发送的FIN报文段，向Server端发送标志位是ACK的报文段，然后Client端进入TIME_WAIT状态。Server端收到Client端的ACK报文段以后，就关闭连接。此时，Client端等待2MSL的时间后依然没有收到回复，则证明Server端已正常关闭，那好，Client端也可以关闭连接了。
四次挥手的意义
主要是因为TCP是全双工模式
建立连接时因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。所以建立连接只需要三次握手。
由于TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议，TCP是全双工模式。
这就意味着，关闭连接时，当Client端发出FIN报文段时，只是表示Client端告诉Server端数据已经发送完毕了。当Server端收到FIN报文并返回ACK报文段，表示它已经知道Client端没有数据发送了，但是Server端还是可以发送数据到Client端的，所以Server很可能并不会立即关闭SOCKET，直到Server端把数据也发送完毕。
当Server端也发送了FIN报文段时，这个时候就表示Server端也没有数据要发送了，就会告诉Client端，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

HTTP协议

HTTP：超文本传输协议，是用于从WWW服务器传输超文本到本地浏览器的传输协议。
HTTP协议是一种无状态协议，主要包含请求和相应两大部分：
请求原始格式-GET（Raw格式：Fiddler抓包得到）

GET https://www.sojson.com/open/api/weather/json.shtml?city=%E5%8C%97%E4%BA%AC HTTP/1.1
Host: www.sojson.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: __cfduid=dccd65c484a7657b468327b66023fefc41534934250; yjs_id=59d1c42afa817b578b4b562d1f72651f; ctrl_time=1

第1行：请求方法接口地址 HTTP协议版本
第2-N行：请求headers(如果有Cookie，最后一行为Cookie)
空一行
请求数据（POST等方法使用，此处为空）
请求原始格式-POST请求（Raw格式：Fiddler抓包得到）

POST http://openapi.tuling123.com/openapi/api/v2 HTTP/1.1
Content-Type: application/json
cache-control: no-cache
Postman-Token: 1a39439e-61c8-4e59-82a1-736a362c5962
User-Agent: PostmanRuntime/7.2.0
Accept: */*
Host: openapi.tuling123.com
accept-encoding: gzip, deflate
content-length: 468
Connection: keep-alive

{
    "reqType":0,
    "perception": {
        "inputText": {
            "text": "附近的酒店"
        },
        "inputImage": {
            "url": "imageUrl"
        },
        "selfInfo": {
            "location": {
                "city": "北京",
                "province": "北京",
                "street": "信息路"
            }
        }
    },
    "userInfo": {
        "apiKey": "ec961279f453459b9248f0aeb6600bbe",
        "userId": "206379"
    }
}

URL

URL：统一资源定位符，接口的访问地址（包含服务器地址+接口地址）
URL组成格式
*协议\: 服务器地址:端口号\资源路径?参数1=值1&参数2=值2
如：https://www.sojson.com/open/api/weather/json.shtml?city=北京

请求方法

序号方法描述
1 GET 请求指定的页面信息，并返回实体主体
2 POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）数据被包含在请求体中
3 HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
4 PUT 从客户端向服务器传送的数据取代指定的文档的内容
5 DELETE 请求服务器删除指定的页面
6 CONNECT 预留给能够将连接改为管道方式的代理服务器
7 OPTIONS 允许客户端查看服务器的性能
8 TRACE 回显服务器收到的请求，主要用于测试或诊断

请求参数（URL参数）

上个url中的city=北京，参数为"city"，值为"北京"。

请求Headers(请求头)

请求头说明

请求数据(又称为Request Body 或 Data)

请求数据类型（Content-Type）（重点）
application/x-www-form-urlencoded：网页表单格式（默认）
application/json：REST接口常用格式
text/xml：xml格式，RPC接口，Dubbo接口常用格式
test/html： html格式
multipart/form-data: 混合表单，支持上传图片
数据编码就不再赘述

响应（Response)

接口返回的信息，包含HTTP状态码，响应头和相应信息
原始相应数据（Raw格式，Fiddler抓包）

HTTP/1.1 200 OK
Date: Thu, 23 Aug 2018 06:32:26 GMT
Transfer-Encoding: chunked
Connection: keep-alive

{"intent":{"actionName":"","code":10005,"intentName":"","parameters":{"lon":"","checkout_date":"2018-08-25","star":"0","city":"北京","days":"1","order":"","price_range":"","nearby_place":"酒店","brand":"","checkin_date":"2018-08-24","place":"信息路","lat":"","needgeo":"0"}},"results":[{"groupType":1,"resultType":"url","values":{"url":"http://m.elong.com/hotel/0101/nlist/#indate=2018-08-24&outdate=2018-08-25&keywords=%E4%BF%A1%E6%81%AF%E8%B7%AF"}},{"groupType":1,"resultType":"text","values":{"text":"亲，已帮你找到相关酒店信息"}}]}

HTTP状态码

1** 信息，服务器收到请求，需要请求者继续执行操作
2** 成功，操作被成功接收并处理
3** 重定向，需要进一步的操作以完成请求
4** 客户端错误，请求包含语法错误或无法完成请求
5** 服务器错误，服务器在处理请求的过程中发生了错误

HTTP与HTTPS

HTTP协议传输的数据都是未加密的，HTTPS协议是由HTTP+SSL协议构建的可进行加密传输、身份认证的网络协议，要比HTTP协议安全。
HTTPS和HTTP的区别

HTTPS协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的SSL加密传输协议。
HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
HTTP的连接很简单，是无状态的；HTTPS协议是由HTTP+SSL协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。

Cookie和Session

Cookie/Cookies: 是指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据（通常经过加密）。
Session：服务端为客户端访问所建立和维持的会话，通常会生成一个唯一的id，会话有一定的有效期。
由于HTTP是无状态的，即服务器不知道用户上一次做了什么，默认也无法识别用户身份。
比较流行的做法是：
用户访问时服务端建立会话（Session）
将会话id（Session ID）随响应返回，并保存在客户端的Cookies里
后续的访问中，服务器通过辨识，客户端请求时携带的Cookies内容来识别用户
Cookie和Session的区别
cookie是存在客户端（浏览器）的进程内存中和客户端所在的机器硬盘上
cookie只能能够存储少量文本，大概4K大小
cookie是不能在不同浏览器之间共享
Session存在服务器端，存在网站进程的内存中
Session在初次设置session的时候，会在session池中实例化一个session对象，以sessionid 的值作为key，同时会将key以cookie的形式保存到客户端的内存中
Session的作用域只存在当前浏览器的会话中，当浏览器关闭以后就会将sessionid丢失，但是服务器的Session对象要20分钟以后才会回收

授权与加密

常见的接口安全策略：

Session/Cookie机制：即需要登录，登录后可访问各个接口，最常用的一种策略，适用于内部接口。
固定appid模式：用户注册时会生成一个唯一的appid，用户调用接口时需要携带appid，适用于公开接口，安全性较差。
动态token模式： token即身份令牌，用户访问接口需要使用个人appid临时申请一个token，token有一定有效期，适用于公开接口，安全性较appid模式好。
开放协议： Basic Auth/ Oauth1.0 / Oauth2.0: 适用于开放接口。
数字签名：将所有请求参数及参数值进行排列拼接，加上用户私钥，再进行Md5或其他加密生成一个请求的签名（sign）,请求是需要携带签名，服务器收到请求后，会对请求重新计算签名并核实与请求所携带签名是否一致。安全性较高，可以有效防止请求被篡改。适用于内部接口及微服务接口。

缓存

HTTP 缓存机制作是 web 性能优化的重要手段，当用户第一次请求服务器资源时，服务器将资源缓存到客户端本地，在一定时间内（缓存有效期内）当用户再次向服务器请求同样的资源时，可以直接从缓存中读取，而不用从服务器下载。
接口测试中缓存相关注意点

在更新或调试接口是，注意是否需要清理缓存（或临时禁用缓存）
缓存有一定的有效期
接口性能测试中会关注缓存的命中率