摘要
接口,就是程序之间的交流方式。它像人与人之间的语言一样,让不同的程序能够相互理解、协作。接口文档则是这种交流方式的规范,让程序员们能够更好地理解和使用接口。
正文
『居善地』接口测试 — 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)单层到黑白盒多层的自动化测试体系,从全面黑盒自动化测试到对系统的不同层次进行自动化测试。
在实际公司中开发人员一般不做单元测试, 所以为了更早的接入项目就需要完成接口测试。
关注不迷路
扫码下方二维码,关注宇凡盒子公众号,免费获取最新技术内幕!
评论0