关于接口测试
“接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。”
为使得测试前移，在后台接口完成后，在前端功能完成之前，进行接口测试来验证功能性、可靠性、安全性和性能方面是否能达到预期。接口测试前置，很多bug在功能测试过程无法发现，例如相同接口重复调用，会占用服务器资源，会占用带宽；权限未处理，比如越权操作，更改参数后非管理员就可以控制；返回明文验证码，导致秘密泄漏；前端没有任何报错，功能响应正常，但是接口却返回500，要判断内容是否正确，是否合理等。
反观一下公司项目现状，项目大多采用V模型，即需求分析→设计→代码实现→单元测试→集成测试→系统测试→验收上线，RD跟QA串行，公司大部分的web/app测试也是需要全部开发完毕后RD才能进行提测，进而QA进行测试。若增加接口测试，V模型即变成W模型，既然开发前开发书已产生，W模型的方案就可以进行（RD/QA并行，在需求设计过程输出开发书跟产品说明书给QA；接口设计过程接口文档输出给QA进行接口功能的case编写；后端的老师们完成接口开发之后进行接口测试；由于后端接口开发的过程，前端也在同步开发，前端开发后提测QA，QA做集成测试），一方面，就目前前后端分离来言，后端提供数据，不再渲染页面，APP只搭建界面框架、UI设计、以及各种组件，从产品纬度还需要考虑用户交互体验等等等，前后端耦合较低的项目进行分离测试效果较好；另一方面，早介入测试，并行后，不仅缩短周期，也会在早期发现问题。
有同学就有疑问了，这样搞，那会不会测试出现重复？理论上是不会的，只要Testcase设计合理，搞清楚接口跟功能的测试范围，那就不仅不会不重复，而且覆盖点还会更全面。
如下图，根据大类区分了一下app测试范围与接口测试的范围。
关于Http
概念
就是一种应用层协议，跟“不能拿着前朝的剑杀本朝的官”道理一样，以下是wiki中的讲述：
超文本传输协议（英语：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议[1]。HTTP是万维网的数据通信的基础。
设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。
HTTP的发展是由蒂姆·伯纳斯-李于1989年在欧洲核子研究组织（CERN）所发起。HTTP的标准制定由万维网协会（World Wide Web Consortium，W3C）和互联网工程任务组（Internet Engineering Task Force，IETF）进行协调，最终发布了一系列的RFC，其中最著名的是1999年6月公布的 RFC 2616，定义了HTTP协议中现今广泛使用的一个版本——HTTP 1.1。
原理
web端也好，app端也好，举个简单的登陆例子，例如账号登陆，在输入账号密码的过程，点击提交，服务器处理，直到返回登陆成功。这一切的幕后，中间http做了什么工作呢？（使用Wireshark，借助Wireshark可直观的发现各网络层的关系，不仅仅Charles所捕捉的应用层，还包含物理层、数据链路层、传输层TCP UDP等等，彻底打开数据传输的大门，等我吃透了拿实例再给大家讲）
输入账号、密码点击提交时，请求的接口地址会经过DNS服务器解析
DNS解析层层解析后，建立Socket链接（三次握手，四次挥手）
链接建立成功后，客户端向服务器发起Http请求
服务器响应并返回给客户端数据，关闭TCP链接
客户端解析数据后呈现给前端页面
构成部分
请求报文（Request）
请求行（request line）：请求方法（Method）、URL和HTTP协议版本（HTTP-Version）
例如：
POST /api/v1/thing/device/1218/w/properties/0/1000 HTTP/1.1（打开1218工位的灯光）
请求头（request header）：
例如：
Host smart-office.yeedev.com
Content-Length 37
Accept application/json, text/plain, /
Authorization Basic eWVlbGlnaHRfcG9ydGFsOkdKSzIzNEhKS0xTKkhKSzIzI1BMUQ==
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36
Content-Type application/json;charset=UTF-8
Origin http://smart-office.yeedev.com
Referer http://smart-office.yeedev.com/QRCode.html?deviceId=1218
Accept-Encoding gzip, deflate
Accept-Language zh-CN,zh;q=0.9
Connection keep-alive
空行：请求头之后是一个空行，发送回车符和换行符，通知服务器之后不再有请求头
请求体（body）：
例如：
post请求方式，请求体就会有具体的请求参数，比如上述开灯的
{
"delay": 0,
"duration": 1000,
"on": true
}
get请求方式，参数会拼接在URL后，?接参数，&对不同参数进行拼接，比如获取1218的灯光状态
http://smart-office.yeedev.com/QRCode.html?deviceId=1218
响应报文（Response）
响应行（response line）
例如：
HTTP/1.1 200
响应头（response header）
Server nginx/1.16.1
Date Thu, 20 Aug 2020 11:08:31 GMT
Content-Type application/json
Content-Length 87
Proxy-Connection keep-alive
响应体（）
例如：服务器返回打开1218的响应结果
{
"code":"200",
"data":{},
"errorMsg":null,
"msg":"处理成功",
"success":true
}
文档先行
接口文档一般是后端定义，并且是在理清需求规范、业务逻辑基础之上开始编写的。
开发提供接口文档后，先看一下提供的后台接口功能
如下面的例子，创建房屋（接口描述）
版本号、版本修改内容、版本修改时间、修改人需要提供
查看请求的地址、请求方式以及请求的参数（下面文档如果补全的话，参数是否必填、参数说明也需要提供，以及返参说明。像这样较简单的接口文档，测试起来确实很麻烦，接口文档未写清楚或接口设计评审阶段QA未参与的话，理解起来确实很费力）
例如对内文档：
创建房屋
URL/project/house/add
请求类型POST
参数说明参数名参数类型示例值
projectId项目id{
"projectId":5,
"name":"房屋①",
"layout":"两室一厅",
"area":"100㎡"
}
name房屋名称(50字以内)
layout房屋户型
area房屋面积
响应字段参数名含义
id房屋id
例如对外文档：
新零售8/18需求，百度短信接口文档的调整，后台hotfix，验证直接上线
简单消息服务SMS
接口测试工具
Postman
“The Collaboration Platform for API Development，Postman is a collaboration platform for API development. Postman's features simplify each step of building an API and streamline collaboration so you can create better APIs—faster.” ——摘自Postman官网
下载Postman，https://www.postman.com/downloads/
安装后建立一个新的链接
选择请求方式，输入请求的URL
输入上文中的headers，输入请求的body（token可能会过期，这个以实际token生成规则为主）
点击Send，查看响应结果，查看灯是否变亮
Save后可保存当前接口到指定目录，用作一条记录
Postman扩展
可根据多个服务器通过改变地址切换测试环境，即在dev/test/stage/pro之间进行切换
可进行批量接口测试
可对测试的接口用例集进行导入、导出
可捕获web端跟移动端请求（android6.0以下）
可通过使用Newman脚本生成测试报告
抓包工具
Charles
有些情况下，在被测接口不完整，比如上述的接口文档，或没有明确的接口文档给出时，需要我们借助抓包工具来帮助测试，利用抓包工具可以获得业务过程中所有的项目接口以及包含调用的第三方接口，进而通过截取请求和请求结果来达到分析抓包的目的。常见的抓包工具有Charles和Fiddler， Fiddler只能用在Windows平台， 而Charles可用于Windows、 Mac、iOS以及Android等多平台。
Charles原理（以下是Https，Http无需进行设置，三次握手四次挥手理解后，Http+s(ssl)，就可以理解成Https了，Charles可以设置SSL代理）
客户端向服务器发起Https请求
服务器向“客户端”（实际上是Charles）返回服务器的CA证书
Charles拦截服务器的响应，获取服务器证书公钥，然后自己制作一张证书，将服务器证书替换后发送给客户端。（这一步，Charles拿到了服务器证书的公钥，相当于套牌复制）
客户端接收到“服务器”（实际上是Charles）的证书后，生成一个对称密钥，用Charles的公钥加密，发送给“服务器”（Charles）
Charles拦截客户端的响应，用自己的私钥解密对称密钥，然后用服务器证书公钥加密，发送给服务器。（这一步，Charles拿到了对称密钥）
服务器用自己的私钥解密对称密钥，向“客户端”（Charles）发送响应
Charles拦截服务器的响应，替换成自己的证书后发送给客户端
至此，连接建立，Charles拿到了服务器证书的公钥和客户端与服务器协商的对称密钥，之后就可以解密或者修改加密的报文了
最后，再回顾一下，Charles模拟了中间人（SSL层）的角色，就好比A有一个带密码的保险箱，需要通过邮局邮寄到B，Charles就充当了邮局的角色，将密码跟保险箱转换成自己的的密码跟保险箱，然后把保险箱里面的文件也重新放到了自己的保险箱里，最后再寄到B
Charles下载
根据系统下载https://www.charlesproxy.com/download/
Charles基本配置
进入Proxy--macOS Proxy勾选，查看本地请求
配置代理服务器，查看移动端请求
进入Proxy--Proxy Settings，设置HTTP Proxy端口号，勾选 Enable transparent HTTP proxying
手机端与PC处于同一局域网，在iPhone上找到当前网络并设置HTTP代理，设置为[手动]，服务器填写PC的IP地址，端口写Charles配置的代理端口（设置好之后，打开 iPhone 上的任意联网的程序，就可以看到 Charles 弹出 iPhone 请求连接的确认菜单，点击 “Allow” 即可完成设置。）
若抓取Https，手机端需要安装证书，步骤参考Help--SSL Proxying--Install Charles Root Certificate on a Mobile Device or Remote Browse
设置好证书后，重启Charles，就OK了
Charles扩展
可以打断点，在请求的任意列表数据右击选择breakpoints
可以模拟网速请求，Proxy--Throttle Settings进行设置，可以保存模版下次继续使用
可以修改服务器返回内容，在修改基础上发送
可以查看接口的性能体现，选择Structure--Chart
可以进行简单的压力测试，Tools--Advanced Repeat（并发测试还是推荐Jmeter/QTP，怎么专业怎么来，怎么有效怎么来）
接口测试
接口文档评审
QA参与需求评审后，与case不一样，QA充当了参与者身份，参与接口文档评审，评审角度也不一样
接口文档是否规范（上述已讲述，像设计原则是开发的事儿了）
接口文档是否阅读方便
接口文档是否易用
接口文档的业务逻辑对比需求文档是否清晰
接口是否覆盖异常情况
接口测试用例
为了大家混淆测试类型，优先引入两个概念，分别是并发测试、压力测试。
压力测试：
打个比方，一个桥在要求满足100个人来回走10年也不会跨，桥的绳子的承受力、地面的质量是否可以满足。
压力测试更多的是指的是性能指标，在持续的请求过程中，服务端是否能稳定、可靠。
并发测试：
打个比方，2个人同时上桥，不拥挤，很快上桥；3个人同时上桥，并排走，同时上桥；10个上桥，有一个可能就在别人屁股后面了（这里会引入一个MQ消息队列的概念，并发测试会遇到，以后会讲），100个人上桥就更拥挤了，可能第10分钟后才能完全都上桥。
并发更多的是查看能否在一定时间内把所有的事件都处理完毕，查看服务端的吞吐量、内存CPU是否正常，是否在高并发的情况下负载均衡，响应时间是否及时。
测试用例模版（待补充）
Testcase包含两部分内容
编号、用例名称、用例标题、优先级、模块
接口地址、请求方式、前置条件、请求头、请求参数、状态码、期望结果
Testcase根据需求文档、业务逻辑编辑，与正常写case是一样的，如模版中“工位控制”模块中的Control1、Control2、Ccontrol3
需要覆盖逆向的Testcase，请求为空，或者请求超出正常范围，例如Control4、Control5
根据实际业务需求，可进行并发请求，当然这个case没有必要测试并发，例如Control6
根据实际业务需求
进行并发测试（在评估的并发用户后，可测试并发数是否能满足业务要求）