本文由 发布，转载请注明出处，如有问题请联系我们！ 发布时间: 2021-05-16『居善地』接口测试 — 2、接口和接口文档概念
加载中『居善地』接口测试 — 2、接口和接口文档概念
目录- 1、接口的概念
- 2、为什么要使用接口
- 3、接口文档介绍
- 4、接口文档要素
- 5、分层的自动化测试
1、接口的概念
接口又叫API，全称application programming interface：应用程序接口（规范），也就是我们经常会听说Web接口，APP接口。
详细说明：
APP是一种基于C/S架构的应用程序，如抖音、微信等。完整的体验是基于APP客户端和后台云服务端共同作用的结果。
客户端和服务端的数据传递，也就是指客户端向服务端发送请求，服务端响应客户端的过程。
这一系列的通讯都是基于web协议通讯构成的，在利用web协议通讯的时候，企业内通常都会规定客户端和服务端的数据交换格式，这种格式可以是企业内部规定的，也可以是使用webservice国际通用标准，这样一来客户端和服务端就使用同一套标准进行接口间的通讯。
同样的道理，web接口也是如此，web应用通常是B/S架构，客户端是我们熟悉的浏览器。
总结概括：接口就是客户端与服务端之间的标准，或者是共同遵守的一套数据交互的规范。（一般由项目负责人/架构师来制定接口）
总结：接口是连接客户端和服务端之间的桥梁，规定了客户端和服务端之间数据交换的格式。
2、为什么要使用接口
在项目中未采用接口时：
- 研发标准不统一，团队磨合难度高。
- 研发周期长。
- 可扩展性差。
在项目中使用接口的优点：
- 统一设计标准。
- 扩展性灵活。
- 前后端开发相对独立，前后端都可以使用自己熟悉的技术。
3、接口文档介绍
接口规范以接口文档的形式进行体现，我们做接口测试也是依据接口文档进行测试。
在项目开发中，web项目的前后端分离开发，APP开发，需要由前后端工程师共同定义接口，编写接口文档，之后大家都根据这个接口文档进行开发，到项目结束前都要一直维护。
接口文档基本形式如下：
| 名称 | 添加发布会 |
|---|---|
| 描述 | 添加发布会 |
| URL | http://127.0.0.1:8000/api/add_event/ |
| 调用方式 | POST |
| 请求参数 | eid # 发布会 idname # 发布会标题 limit # 限制人数 status # 状态 address # 地址 start_time # 发布会时间 |
| 返回值 | {'status':200,'message':'add event success'} |
| 状态码 | 每一个状态码要有一条用例。{'status':10021,message':'parameter error'} {'status':10022,message':'event id already exists'} {'status':10023,'message':'event name already exists'} {'status':200,'message':'add event success'} |
| 说明 | 说明参数传入方式，签名校验方式，加密方式等等。 |
4、接口文档要素
一般情况下，开发前就有相应的接口文档，接口文档的形式有很多种，以Excel表格或者Word文档或者使用接口管理工具（如swagger等）输出，接口文档包含以下主要的内容：
（1）接口名称
| 接口详情 | 说明 |
|---|---|
| 接口名称 | 添加发布会 |
| 接口描述 | 调用该接接口会创建一个发布会 |
（2）接口URL
| 名称 | 说明 |
|---|---|
| 请求协议 | http或者https |
| 接口URL | 127.0.0.1:8000/api/add_event/ |
| 请求方式 | 新增(post) 修改(put) 删除(delete) 获取(get)等 |
提示：接口URL也可以形成URI的形式，就是把服务器地址省略掉，例如：/api/add_event/
（3）请求参数
| 字段 | 说明 | 类型 | 是否必填 | 备注 |
|---|---|---|---|---|
| eid | 发布会 | Number | 是 | 默认：10001 |
| idname | 发布会标题 | String | 是 | 默认：填写发布会标题 |
| start_time | 发布会时间 | Date | 是 | 格式：2018-02-06 10:30:00 |
提示：一般数据类型为
String、Number、Object、Array、Date几种类型。
（4）返回值
例如：{'status':200,'message':'add event success'}，还可以有其他所需字段。
| 字段 | 说明 | 类型 | 是否必须返回 | 备注 |
|---|---|---|---|---|
| code | 接口状态码 | Number | 是 | 成功：200 失败：其他状态码 |
| message | 接口信息 | String | 是 | 成功：sucess 失败：提示信息 |
提示：
正常请求参数返回值（必有）。
错误请求参数返回值（看公司要求）。
5、分层的自动化测试
测试金字塔的概念由敏捷大师Mike Cohn在他的Successding with Agile一书中首次提出。
他的基本观点是：我们应该有更多低级别的单元测试，而不仅仅是通过用户界面运行高层的端对端的测试。
如下图所示：
Martin Fowler大师在测试金字塔模型的基础上提出分层自动化测试的概念。
在自动化测试之前加了一个分层的概念，有别于传统自动化测试。
那么什么是传统的自动化测试？为何要提倡分层自动化测试的思想呢？
所谓传统的自动化测试我们可以理解为，基于产品UI层的自动化测试，它是将黑盒功能测试转化为，由程序或工具执行的一种自动化测试。
在目前的大多数研发组织当中，都存在开发与测试团队割裂（部门墙）。
如果公司采用传统的自动化测试，这可能导致两个恶果：
- 一是UI自动化测试维护成本相对较高，因为UI是非常易变的；
- 二是测试团队规模的急剧膨胀。
分层自动化测试倡导的是从黑盒（UI）单层到黑白盒多层的自动化测试体系，从全面黑盒自动化测试到对系统的不同层次进行自动化测试。
在实际公司中开发人员一般不做单元测试， 所以为了更早的接入项目就需要完成接口测试。
