接口测试基础知识
（1）什么是接口测试
接口测试是测试系统组件间接口的一种测试。
接口测试主要用于检测系统内部各个子系统之间、外部系统与系统之间的交互。
测试的重点是检查数据交换，传递和控制管理的过程，以及系统间相互逻辑依赖关系等。
通俗来说接口测试就是接口提供方、接口调用方之间的交互，及逻辑处理的测试。
数据交换：注册
数据传递：将注册数据传递到服务器，调用程序，执行数据库sql语句，往数据表中插入数据
控制管理：在程序中设置字段的长度
系统间相互逻辑依赖关系：注册成功之后调用登录进行登录；共享充电宝是否收取押金依赖芝麻信用分
接口：
1. GUI：图形用户界面，并不是接口测试的重点。
2. API：应用程序接口，接口测试的主要对象。API专门用来提供给其他系统进行调用的程序接口。
Browser/Server、Client/Server架构必然需要前端和服务器进行交互，接口就是它们交互的枢纽。
其本质就是前台发送一个request（请求）报文给服务器，然后服务器响应返回一个response（响应）报文。我们对response报文进行分析，判断是否和我们的预期一致，从而检验业务是否正确实现。
通过输入看输出
模拟实际场景（服务架构（Java、Python、php）、数据场景（CRUD）、业务场景），对接口进行模拟调用，验证其响应性能、输出结果、异常处理等测试点。
HTTP接口测试知识点：
考试系统网址：http://182.92.178.83:8088/student/index.html#/login
Request URL(请求地址)
URL形式: http[s]://host[:port][abs_path][parameter]
比如: http://182.92.178.83:8088/api/student/user/register
Request Headers(请求头):头信息，包含了报文的描述信息
Accept(接收形式): application/json, text/plain, */*
Content-Type(提交形式): application/json
Cookie: JSESSIONID=C68ED1A8DA1A3B2CDACC5612F158467D
# Content-Type的几种形式:
- form-data
- application/x-www-form-urlencoded
- application/json
比如：{"username":"ctt","password":"123456",age:21,"a":[{"b":123},{"c":456}]}
Request Method(提交方法): GET/POST DELETE/PUT
GET: 获取服务器信息的一些操作。一般用于获取数据
比如：
Request URL: http://182.92.178.83:8081/article/all?state=-1&page=1&count=6&keywords=
Request Method: GET
PS：直接在url后面连接参数，url有长度限制。
POST: 一些提交等操作。一般用于提交数据，注册、上传文件。
DELETE: 一般用于删除操作（物理删除）
比如：
Request URL: http://182.92.178.83:8081/admin/category/56
Request Method: DELETE
PUT: 跟post功能一致，但是有一个对等加密的过程，比如两人同时提交就会对比谁先提交，执行先提交的那个操作，后提交的不做处理。比如逻辑删除。（逻辑删除：比如将state=0）
比如：
Request URL: http://182.92.178.83:8081/article/dustbin
Request Method: PUT
这四种形式无论用哪一种都能实现对数据库的增删改查，那么为什么会分四种呢，它更像是一种约定。
（面试题）get和post的区别❓
- 传参方式不同，get是通过url？后面去传参的，post是在请求体里面传参。
- 有些约定里面，get更多的是做获取信息的操作，post更多的是做提交信息的一些操作。
Request Parameters(请求参数)
Status Code(响应状态码)
200(服务器响应成功)
404(找不到路径)
500(服务器内部错误)
Response(响应信息)
（2）为什么要进行接口测试
接口测试相对于UI来说，更加稳定；
也可以说接口测试是一种特殊的单元测试；
当一个系统提供了大量的后台服务，有较少或者基本没有页面操作，比较适合开展接口测试；例如：某个系统大概有100多个对外的接口，每次上线，测试人员不得不一个一个验证，此时如果开展自动化，将大大提高回归的效率和测试的覆盖率。
为什么接口比UI更加稳定：如果接口响应信息都变了，UI也需要变。
🐒前后端分离，一个接口给多个端使用（web端、app端）
🐷什么时候做接口测试？
- 有大量用户的时候，前端页面限制了但是没有限制完。
（3）怎样做接口测试
- 方式一：先拿到接口测试规范文档，再去做接口测试。
- 方式二：抓包（浏览器F12、Charles、fiddler）。
1.接口测试在工作中的流程
-
准备阶段（20%）
拿到开发的接口文档，并理解每个接口的参数及含义；
了解被测系统的业务流程。
-
编写接口测试用例、执行阶段（70%）
测试用例/测试场景执行
测试数据/系统数据收集
-
分析阶段（5%）
数据汇总/日志分析
测试报告
2.接口测试规范文档
接口功能
URL
支持格式
HTTP请求方式
请求参数
🔑为提高接口测试效率，及TDD（测试驱动开发）模式，前期我们需要推动开发规范，接口说明文档。
3.如何获取接口（Charles、fiddler）
抓包工具Charles、fiddler，web端浏览器的F12。
（4）接口测试用例的设计
接口测试用例编写要点：
- 测试每个参数类型不合法的情况。
- 测试每个参数取值范围不合法的情况。
- 测试参数为空的情况。
- 测试参数前后台定义的一致性。
- 测试每个参数的上下限（这里容易出致命的BUG，如果程序员处理不当，可能导致崩溃）。
- 测试每个参数取值不合理的情况（包括取的值不属于自己，取值在这阶段不会出现，取值超出了自己所谓的数量或者范围）。
- 如果两个请求有严格的先后顺序，需要测试调转顺序的情况。
（5）接口测试的流程规范（团队中）
- 与产品、开发一起梳理需求，确定实现哪些接口和功能。
- 编写测试计划（开发人员预估时间、风险预估及解决时间，测试人员用例准备、数据准备、环境准备、与开发产品协调测试时间等）
- 测试计划review。请各部门再进行沟通，确定最终计划。
- 编写用例及自动化脚本。
- 用例review（以该用例为最终验证的用例）。
- 执行测试，提交bug，验证bug。
- 测试总结（包括测试过程、开发过程遇到的问题、解决问题、小组内讨论以后遇到这种问题如何可以处理更快、对自己启发）
