一、接口

1. 概念

系统与系统之间，组件与组件之间，数据传递交互的通道。

2. 接口的类型

• 按协议划分：http、tcp、IP
• 按语言划分：C++、java、php 。。。
• 按范围划分：
  1）系统之间：
  多个内部系统之间；
  内部系统与外部系统之间；
  2）程序之间：
  方法与方法之间，函数与函数之间，模块与模块之间

二、接口测试

1.概念

接口测试就是，对系统或组件之间的接口进行测试。校验传递的数据正确性和逻辑依赖关系的正确性！

2. 原理

接口测试，主要针对的测试目标 —— 服务器

• 怎么测？
  模拟客户端，向服务器发送请求。
• 用什么测？
  工具：fiddler、postman、jmter
  代码：python + UnitTest框架 + Requests框架
• 测什么？
  测试 服务器针对客户端请求，回发的响应数据是否与预期结果一致！
  人眼对比
  断言

3. 特点

符合质量控制前移的理念；
可以发现一些页面操作发现不了的问题；
接口测试低成本高效益；
接口测试是从用户的角度对系统进行检测；

4. 实现方式

工具：JMeter、Postman、fiddler
代码：Python + Requests + UnitTest

什么是自动化接口测试？
借助工具、代码，模拟客户端发送请求给服务器，借助断言自动判断 预期结果 和 实际结果 是否一致！
==HTTP协议==

协议：就是规则。要求通信的双方必须严格遵守！

三、HTTP协议简介

1. HTTP

• HTTP：（HyperText Transfer Protocol）超文本传输协议，是一个基于请求与响应模式的、应用层的协议，也是互联网上应用最为广泛的一种网络协议。
• 特征：
  1. 支持客户端/服务器模式
  2. 简单快速
  3. 灵活
  4. 无连接
  5. 无状态

2. URL格式

• 概念：（Uniform Resource Locator）统一资源定位符

• 作用：在网络环境中，唯一的定义一个数据资源

  
  

3. HTTP请求

3.1 作用

客户端(app、浏览器)，发送请求给服务器时，使用的协议 —— http请求协议。
规定 发送给服务器的数据传输的语法格式。

3.2 整体格式

请求格式

请求示例

3.3 请求行

• http 请求方法：大小写均可
  GET：查询。 —— 没有请求体
  POST：添加。（登录时常用）
  put: 修改。
  delete: 删除。 —— 没有请求体

3.4 请求头

• 数据格式：k：v
• Content-Type：
  application/json： JSON数据格式
  application/x-www-form-urlencoded： form表单数据

3.5 请求体

GET和DELETE 没有
PUT 和POST有
数据类型受 Content-Type 值影响

4. HTTP响应

4.1 作用

服务器端，针对客户端发送的 http请求，回发响应数据。—— http应答！
规定 回发给客户端的数据组织格式。

4.2 整体格式

响应格式

响应示例

4.3 状态行

• 状态码：
  1xx：代表指示信息。表示请求已经被接收，等待继续处理。
  2xx：代表请求成功被处理、接收。 常见：200、201
  3xx：重定向，待访问的资源，需求重新指定路径访问。
  4xx：代表客户端错误。常见：404、 403
  5xx：服务器端错误。
• 状态码描述：一般与状态码 唯一对应。 200 —— ok； 404 —— file not found

4.4 响应头

语法格式：k：v
Content-Type：值为 响应体 的数据类型。
Content-Length: 响应体的大小。可以不写，浏览器会自动求取。一旦写，必须准确！

4.5 响应体

回发给客户端的 消息内容。常见的有 html网页、xml、json

四、接口风格

1. 传统风格接口

特点：
请求方法，只使用 get 和 post 即可。
URL 不唯一。同一个操作可以对应不同的 URL
状态码的使用较单一。200 最常见。

2. RESTful 风格接口

特点：

1. 每一个URL代表一种资源；
2. 客户端和服务器之间，传递这种资源的某种表现层；
   • 表现层：数据的不同表现形式（如：图片、文字表现同一个数据对象）
3. 客户端通过四个HTTP动词（GET、post、delete、put），对服务器端资源进行操作，实现"表现层状态转化"；

4. 接口之间传递的数据最常用格式为JSON。

   
   

五、接口测试流程

1. 分析需求，产生需求文档（产品）。
2. （开发产生接口文档）解析接口文档。
3. 产生 接口测试用例（送审）。
4. 执行 测试用例
   • 工具：postman、jmeter、fidller
   • 代码：python + Requests +UnitTest
5. 提交、跟踪缺陷。
6. 生成 测试报告。
7. （可选）接口自动化持续集成

六、接口文档

由开发人员编写，描述接口信息的文档。开发团队按接口文档进行开发工作，并要一直维护遵守。

1. 作用

1. 能够让前端开发与后台开发人员更好的配合，提高工作效率。（有一个统一参考的文件）
2. 项目迭代或者项目人员更迭时，方便后期人员查看和维护
3. 方便测试人员进行接口测试

2.展现形式

• word 文档形式
• Excel 表格式形式
• pdf 文档形式。

3. 结构

• 基本信息：
   资源路径 （协议和域名在 “系统信息”中）
   请求方法
   接口描述
• 请求参数：
  请求头：
   Content-Type 描述请求体的数据类型
  请求体：
   实现该接口使用的 数据及对应类型。
• 返回数据：
  状态码： 200
  错误码（自定义状态码）：
   码值
   描述信息

4. 接口文档解析

接口文档的解析本质：从接口文档中，找出 http 请求所需要的 数据信息。
主要包含：请求方法、URL 、请求头、请求体、响应状态码、描述。
以 “登录” 为例：
 请求方法：POST
 URL：http://ihrm-test.itheima.net/api/sys/login
 请求头：Content-Type ：application/json
 请求体：{“mobile”:”13800000002”, “password”:”123456”}
 响应状态码：200
 错误码：
  10000：操作成功！
  20001：用户名或密码错误
  99999：抱歉，系统繁忙，请稍后重试！

请求示例

响应示例

七、接口用例设计

设计接口用例原因：

1. 防止测试点漏测，条理清晰
2. 方便分配工作，评估工作量和时间

1. 接口测试的测试点

测试点称之为测试维度

1.1 功能测试

1.1.1 单接口功能

手工测试中的单个业务模块，一般对应一个接口。
- 登录业务 ——> 登录接口
- 加入购物车业务 ——> 加入购物车接口
- 订单业务 ——> 订单接口
- 支付业务 ——> 支付接口
- 借助工具、代码。绕开前端界面，组织接口所需要的数据，展开接口测试。

1.1.2 业务场景功能

按照用户实际 使用场景，梳理 接口业务 场景。
- 组织业务场景时，一般只需做 正向 测试即可（与手工一致）。
- 一般建议用最少的 用例 覆盖最多的业务场景。
- 登录 —— 搜索商品 —— 加购物车 —— 下单 —— 支付 —— 评价

1.2 性能测试

• 响应时长
• 吞吐量
• 并发数量
• 服务器资源利用率

1.3 安全测试

• 攻击安全。 —— 由专业安全测试工程师完成
• 业务安全。 —— 测试的方向

• 敏感数据是否加密

  
  
  敏感数据加密
• SQL注入：在用户能输入数据的位置，写入SQL语句
• SQL注入安全，用户恶意写入的SQL语句，不会执行查询数据库

2. 设计方法与思路

2.1 与手工设计相同之处

手工测试 对应的 功能测试点，与接口测试对应的功能 完全一致。

示例：tpshop商城 登录 页面，手工功能测试用例设计要点：

1. 页面布局是否符合需求；
2. 测试 用户名 输入框，输入的数据是否正确；
3. 测试 密码 输入框，输入的数据是否正确；
4. 测试 验证码 输入框， 输入的数据是否正确；

tpshop商城 登录 页面，接口测试用例设计要点：

1. 测试 用户名 输入框对应的 username 的值 是否正确；
2. 测试 密码 输入框对应的 password 的值，是否正确；
3. 测试 验证码 输入框对应的 verify_code 的值，是否正确；

2.2 与手工设计不同之处

手工测试，测写入到输入框中的数据是否正确。
接口测试测 参数 对应的 参数值 是否正确。
接口测试，不单单针对 参数值进行，还可以针对 参数本身 进行测试。
- 正向参数：
必选参数：所有的 必选（必填）都包含
组合参数：所有的 必选 + 任意一个或多个可选参数
全部参数：所有的 必选 + 所有的 可选参数
- 反向参数：
多参：多出一个或多个必选参数 （可以任意指定）
少参：缺少一个或多个必选参数
无参：没有必选参数
错误参数：参数名输入错误

3. 单接口测试用例

手工 测试用例文档 8 大要素：
编号、用例名称（标题）、模块、优先级、预置条件、测试数据、操作步骤、预期结果

接口 测用例文档 10 要素：
编号、用例名称（标题）、模块、优先级、预置条件、请求方法、URL、请求头、请求体(请求数据)、预期结果

3.1 分析接口文档

以 登录接口 为例：

• 请求方法：post
• URL： “系统信息” 中的 协议和域名 + /api/sys/login
• 请求头：Content-Type : application/json
• 请求体：{"mobile":"13800000002","password":"123456"}
• 预期结果： {"success":true,"code":10000,"message":"操作成功！","data":"f5050a1b-7919-444c-9ec4-3c1a7286536d"}
• data：值为登录成功生成的 令牌数据。该数据 会定时变化。

3.2 登录模块的接口测试用例测试点

1）数值
正向
- 登录成功
反向
- 用户名为空
- 用户名包含特殊字符、字母
- 用户名超过11位（12位）
- 用户名不足11位（10位）
- 用户名未注册
- 密码为空
- 密码包含特殊字符、字母
- 密码为1位
- 密码为100位
- 密码错误
2）参数
正向
- 必选参数：正确用户名 + 正确密码
- 组合参数：忽略
- 全部参数：正确用户名 + 正确密码
反向
- 多参：多 abc：“123”
- 少参（少mobile）：没有用户名，正确密码
- 无参：没有任何参数
- 错误参数(手机号参数名错误)：abc:1381234567, password:”123456”

用户名相关 5 条：

密码相关 5 条：

参数相关：

3.3 业务场景测试用例

• 用户怎么用，怎样设计业务。

• 用最少的测试用例，尽量覆盖最多的接口
  1）分析测试点
  针对 员工管理 业务场景：
  登录 —— 添加员工 —— 查询员工 —— 修改员工 —— 再次查询 —— 删除员工 —— 查询员工列表
  2）添加员工

• 请求方法：post

• URL： {协议+域名}/api/sys/user

• 请求头：
  Content-Type： application/json
  Authorization： Bearer f5050a1b-7919-444c-9ec4-3c1a7286536d （具体数据 来源 登录成功返回的 响应体中的 data的值）

• 请求体（请求数据）：{"username":"爱因斯坦","mobile":"17289432100","timeOfEntry":"2021-07-12","formOfEmployment":1,"departmentName":"测试0607","departmentId":"1412421425733664768","workNumber":"234","correctionTime":"2021-07-30T16:00:00.000Z"}

• 预期结果：

  • 状态码：200
  • {"success":true,"code":10000,"message":"操作成功！", "data":{"id":"113749504"}}

3）查询员工

• 请求方法：GET
• URL： {协议+域名}/api/sys/user/:target
• 请求头：
  Content-Type： application/json
  Authorization： Bearer f5050a1b-7919-444c-9ec4-3c1a7286536d （具体数据 来源 登录成功返回的 响应体中的 data的值）
• 请求体:
  无
• 返回数据：
  状态码：200

      "code": 10000,
      "message": "操作成功！",
      "data": { 所查询的员工的详细信息} }```
  
  

4）修改员工

返回数据中的 id ，代表 修改的员工id （是一个会变化的数据）。
5）删除员工

6）查询员工列表