接口测试三要素及案例
- 接口测试介绍
- 接口预定义
- 接口测试的主要作用
- 测试接口流程如下
- 接口测试三要素
- 接口测试分类
- RESTful架构风格
- RESTful架构三要素
- 要素一
- 要素二
- 要素三
- RESTful架构风格实现
- restful架构案例
- 接口测试流程
- 接口测试原则
- 功能测试
- 自动化测
- 性能测试
- 复习复盘
接口测试介绍
接口介绍
不同主体之间进行通信的通道,它应具有一套规范/标准 (分类 硬件接口:USB接口 网线接口; 软件接口)
软件接口
1.软件系统中,前端和后端是两大重要组成部分
2.前端主要用于与用户交互,用户通过前端可以提交数据并查看响应的结果
3.后端主要处理用户提交的数据产生相应
比如:百度搜索,思考前后端分工前后端通过某个通道完成数据交互 搜索12306时,https://www.baidu.com/s?wd=12306
访问路径包括/s,建立通信管道 参数包括wd=12306符合标准
采用接口的好处
(实现了前后端分离)为了数据交互同时,
1.前后端都可以使用自己熟悉的技术
2.缩短了研发周期
3.保证代码安全
4.拓展性更好
接口预定义
落实到文档,该文档称之为API文档
前后端编码时,1.需要参考API文档/
2.前人总结的相关规范 如:RESTful架构风格
举例:
编写登录接口的API文档
描述:登录接口
URL:http://www.xxx.com/login
请求方式:POST
提交数据:账号 usename
密码 password
响应结果: 成功true 失败 false
前端实现:
后端实现:
1.获得用户提交的数据 2.查询结果相应数据(true/false)
接口测试的主要作用
主要作用 1.更好的辅助定位bug(前/后端) 2.发现程序中的安全隐患 3.提高测试效率
测试接口流程如下
1.绕过前端 2.通过URL定位接口资源 3.提交测试数据 4.判断响应是否满足预期
接口测试三要素
- 定位接口资源 2.提交测试资源 3.判断相应资源
接口测试分类
1.B/S测试(web形式的接口测试): 1.服务器接口测试->自实现接口 2.外部接口测试 如支付宝接口,微信测试
2.C/S模块之间的接口测试
RESTful架构风格
为什么要学习RESTful架构风格?
避免千人千面, 使API文档风格统一
RESTful架构是一种接口设计架构, 约束了接口实现的规范
架构的作用:提高了文档的可读性
RESTful架构的设计在API文档中关于接口的描述也是围绕三要素展开的:
描述: 实现用户的登录功能
流程:
1、登录表单的数据提交到服务器: http://www.xxx.com/login, 请求方式 POST
2、提交的数据格式: username=xxxx&password=yyyy
3、响应结果:
200 {“msg”:“登录成功”}
200 {“msg”:“登录失败”}
注意: 一般响应结果的msg中, 提示信息很可能是英文
RESTful架构三要素
要素一
组成
- URL(统一资源定位符), 例如: http://www.baidu.com/s
- 协议: 常见的有 http/ https/ ftp/ ftps
- IP: 服务器 IP 地址
- 端口: http默认端口一般是80, https默认端口一般是443
- 路径: 一个资源路径映射一个接口实现
- 请求方式: 常见GET/POST/PUT/DELETE 分别对应 查/增/改/删 四种操作
get 和 post 的区别
- 提交方式不同
- get 提交的数据显示在地址栏
- post 是隐式提交, 更安全
- 可提交的数据量不同
- get 提交的数据量有限制
- post 无限制
- 执行效率不同
- get 的效率比 post 高
要素二
两种常见的数据提交格式
- 键值对格式
- JSON格式(类似于 python 中的字典)
一般情况下, 使用 get 方式进行提交时, 使用的是键值对格式 使用 post 方式进行提交时, 使用的是JSON格式
要素三
状态码
- 1xx 请求正常, 但是无响应, 只在实验状态下使用
- 2xx 请求正常, 响应正常, 如: 200 201 204…
- 3xx 以其他方式获取响应, 如: 302 重定向 304 取本地缓存
- 4xx 浏览器端异常, 如: 404 资源路径有误
- 5xx 服务器端异常, 如: 500 服务器运行异常
响应体
常见的接口的响应体有两种类型
- 响应 html 文档, 例如: 访问百度搜索接口
- 响应 JSON 格式数据
RESTful架构风格实现
RESTful 只是一种规则, 并不是标准, 换言之, 不是硬性约束
restful架构案例
一.查询
1.1 学员-查询所有
请求方法：GET
请求地址：http://127.0.0.1:8000/api/students
1.2 学员-查询指定单个
请求方法：GET
请求地址：http://127.0.0.1:8000/api/students?s_id=S001
(注: s_id 为参数名称; S001,S005,S088 为学员ID;)
1.3 学员-查询指定多个
请求方法：GET
请求地址：http://127.0.0.1:8000/api/students?s_id=S001,S005,S088
(注: s_id 为参数名称; S001,S005,S088 为学员ID;)
1.4 学员-组合查询
请求方法：GET
请求地址：http://127.0.0.1:8000/api/students?chengji=A&banji=B01
(注: chengji：成绩; banji：班级;)
二.新增
2.1 学员-新增
1) 请求方法：POST
2) 请求地址：http://127.0.0.1:8000/api/newstudents/
3) 请求JSON报文：
4) 调用传入的json串如下（可新增多条，之间用,隔开）：
{
"data": [
{
"s_id":"S009",
"s_name":"zhangsanfeng",
"banji":"B01",
"chengji":"A"
}
]
}
- 新增成功返回报文：
{
"already_exist": {
"results": [],
"count": 0
},
"create_success": {
"results": [
{
"s_id":"S009",
"s_name":"zhangsanfeng",
"banji":"B01",
"chengji":"A"
}
],
"count": 1
}
}
6) 新增失败id已存在-返回报文：
{
"already_exist": {
"results": [
{
"s_id":"S009",
"s_name":"zhangsan",
"banji":"B02",
"chengji":"B"
}
],
"count": 1
},
"create_success": {
"results": [],
"count": 0
}
}
7) 新增失败json格式错误：
{
"status_code": 400,
"detail": "请求体参数格式错误。"
}
三.更新
3.1 学员-更新
1). 请求方法：PUT
2). 请求地址：http://127.0.0.1:8000/api/updatestudents/S009/
(注：1：为学院ID)
3). 请求JOSN报文：
{
"data": [
{
"s_id":"S009",
"s_name":"zhangsanfeng",
"banji":"B01",
"chengji":"A"
}
]
}
4). 修改成功返回：
{
"s_id":"S009",
"s_name":"zhangsanfeng",
"banji":"B01",
"chengji":"A"
}
四.删除
4.1 学员-删除单个
请求方法：DELETE
请求地址：http://127.0.0.1:8000/api/deletestudents/S003/
(注:S003为学员ID)
s_id":"S009",
"s_name":"zhangsanfeng",
"banji":"B01",
"chengji":"A"
}
接口测试流程
-
制定测试计划: 分配任务
- 任务名称: 按模块去划分
- 任务描述: 说明具体任务内容
- 责任人
- 工期: 以天为单位 开始日期—结束日期
- 进度: 进行中/未开始
- 备注
-
从 API 文档中提取接口清单
接口清单是对 API 文档的精简
- API文档为了保证易读性, 说明信息较多, 导致测试过程中, API 文档内容稍显冗余
- 需要从 API 文档提取测试必须的数据, 摒弃冗余数据 (提取的结果: 接口清单)
-
设计测试用例并参数化覆盖测试用例
-
编写脚本实现, 导入设计的测试数据
-
生成测试报告
- 接口功能名称
- 接口用例描述
- 预期结果
- 实际结果
- 是否Bug
- 备注
接口测试原则
功能测试
应用场景
模拟用户的多样性操作, 查看实际结果是否符合预期
原则
1.设计各种正向 + 逆向的测试用例 2.接口覆盖率达到100%
自动化测
应用场景
程序升级
- 新功能(接口)可能会影响原有的功能(接口)
- 新版本上线前, 需要测试确保原有接口能够正常运行
- 版本迭代比较频繁, 使用自动化测试可以提高效率
原则
- 接口覆盖率没必要100%, 只需要测试重要的和被重复调用的接口
- 只需要提交正向的测试用例
- 自动化脚本需要保证可以重复执行
- 一个线程组建议对应一个取样器
性能测试
应用场景
高并发 :如, 模拟100个用户同时访问服务器资源, 要求平均响应时间在3s以内, 且错误率小于1%
高频率 :如, 模拟2个用户以20QPS的频率访问服务器资源持续15s, 要求平均响应时间在3s以内, 错误率为0
区间多用户:如, 模拟半个小时内 1000 个用户访问服务器资源, 要求平均响应时间在3s内, 且错误率为0
原则
1 线程组: 增删改查每个功能, 都需要单独的线程组, 而且避免在同一个线程组内有多个取样器
2 参数化: 参数化尽量避免从外部(csv文件)读取数据, 而是用函数生成测试数据
3 查看结果树: 必须清除单个请求内的查看结果树组件, 建议一个测试计划就一个查看结果树
4 报告: 性能测试报告可根据实际需求选择, 建议使用 聚合报告
5 分布式
扩展
实际登录场景
-
早高峰时段 8:50~9:10, 5000用户登录
- 业务量: 5000个
- 时间: 6020 = 1200s
平均每秒处理 4.1个登录请求/每秒
性能场景分析
二八原则
指80%的业务量是在20%的时间内完成的
计算吞吐量: 实际吞吐量 = 业务量80% / (时间段*20%) = 4000 / 240s = 16.7/s
- 备注
实际上, 登录请求数分布是一个正态分布, 最高峰时肯定比 4.1/s 更高, 峰时段实际上完成了80%的业务量, 却只花了20%的时间
注意
1 二八原则计算的结果不是并发用户数, 是系统应该达到的处理能力(吞吐量)
2 如果你的系统性能要求更高, 也可以选择一九原则或者更严格的算法, 二八原则比较通用
复习复盘
1.接口的概念是什么?
2.接口的作用是什么?
3.如何实现接口的通道?
4.如何预定义接口规则?
5.接口测试的概念是什么?
6.接口测试的作用是什么?
7.接口测试三要素是什么?
8.接口测试可以怎样分类?
9.RESTful三要素
10.接口测试流程是什么?
11.执行接口测试前都做了什么工作?
12.接口测试报告你们是怎么写的?
13. 注意不要忘记结论: 接口测试是否通过
14 接口功能测试的原则是什么?
15 接口自动化测试的使用场景是什么?
16接口自动化测试需要注意什么?
17接口性能测试包括哪些场景?
18请举例说明如何分析性能测试场景?
