接口测试
什么是接口测试以及为什么要做接口测试
1. 什么是接口?
1. 硬件接口: USB接口, 投影仪接口, 鼠标键盘接口
2. 软件接口: 统称--API(鉴权码: token, key, appkey, csrf_token)
1. 内部接口: 开发人员开发软件接口给当前自身软件调用, 模块与模块之间, 子系统之间
用户接触不到, 对安全性要求不高
2. 外部接口:
1. 系统对外提供的服务接口.(长沙银行项目)
2. 系统调用外部接口
对安全非常重视, 所以测试的覆盖率达到极致, 但只需要测试正例即可
2. 为什么做接口测试
1. 前后端分离
1. 当后端接口开发完成,即可直接进行测试
2. 前端接口开发完成, 但后端还未完成, 需要使用Mock Server
2. 基于安全考虑, UI的JS的验证很容易绕过, 所以需要在接口层面对安全性做考虑
3. 测试左移(前移)的思想
3. 目前市场上的接口架构设计风格以及基于的协议
1. 基于SOAP的接口架构: 轻量级, 简单的, 基于XML协议的规范
webservice协议: 地址后面以?wsdl结尾的
2. 基于RPC的接口架构: 远程调用, 他像调用本地服务一样调用远程服务器的接口服务
1. dubbo协议: 阿里RPC架构, 特点: dubbo://适用于高并发, 数量少的情况下
2. 基于SpringCloud的微服务
3. thrift, RMI, Hessiasn
3. 基于RestFul的接口架构: xml, json, jpg, 所有操作无状态
--附: cookie的工作原理:(HTTP Cookie管理器)
第一步: 在客户端第一次访问服务器的时候, 那么服务器会生成cookie信息, 并且在响应生成的Set-cookie里把cookie的信息传递给客户端
第二步: 从第2至第N次的请求都会在请求头的cookie里自动的带上上面的cookie信息
cookie作用: Cookie鉴权, 证明后面的请求都是同一个客户端
3. 目前市场上接口返回的数据类型
1. xml webservice
2. html http
3. json http, dubbo
4. 开发潜规则: {error_code: 错误码, message: 错误中文说明, data:[]}
4. 目前市面上的接口测试工具应用场景
- jmeter + ant + jenkins + git/svn 接口自动化
- postman + newman + jenkins + git/svn接口自动化
- 其他: soupUI, apipost, postwoman, fidder, charles
- 分布式版本控制工具: git github, gitlab, gitee
Jmeter
1. jemter功能
- 软件压力测试
- 功能回归测试
- 性能测试
- 接口测试
- 数据库压力测试
- 批量生产测试数据
2. jmeter文件目录
1. bin目录
- jmeter.bat windows的启动文件
- jmeter.sh Linux的启动文件
- jmeter.log 日志文件
- jmeter.properties 系统配置文件
- jmeter - server.bat windows分布式的执行启动文件
- jmeter - server Linux分布式执行的启动文件\
2. docs目录
- jmeter的接口api文档的存放位置
- docs-api-index.html 所有的jmeter接口文档主页, 适用于二次开发
3. printable_docs目录
- usermanual-index.html jmeter使用手册
- usermanual-component_reference.html 核心元件帮助文档
4. lib目录
- 存放jmeter依赖的所有.jar包
- ext jar包, 第三方插件
3. jemter语言修改
- 临时修改: Options -> Choose Language -> Chinese(Simple)
- 永久修改: jmeter.properties -> Language -> 去掉"#", en改成zh_cn
元件与组件
1. 元件: 类似于python中的类
添加在线程组之下(线程组: 相当于模拟的用户)
- 取样器: 发送请求, 类似于python中request
- 逻辑控制器: 控制语言的执行顺序, 类似于python中的逻辑控制语句
- 前置处理器: 在请求发送之前执行, 类似于python中的setup
- 后置处理器: 在请求发送之后执行.类似于python中的teardown
- 断言: 对响应结果进行断言, 类似于python中的assert
- 定时器: 等待一定的时间, 类似于python中的sleep
- 测试片段: 封装一段代码, 供脚本调用, 不直接执行, 类似于python中自己封装的基础类
- 配置元件: 参数赋值作用, 类似于python自动化参数化
- 监听器: 查看脚本运行结果, 类似于python调试窗口的结果打印
2. 组件: 类似于python类中的方法
4. 元件作用域
- 元件作用域是靠测试计划的树形结构中元件父子关系确定的
- 核心: 取样器, 其他组件都是以取样器为中心运行的, 组件添加位置不同, 生效的取样器也不同
作用域原则
- 取样器: 元件不和其他元件相互作用, 因此不存在作用域问题
- 逻辑控制器: 元件只对其子节点中的取样器和逻辑控制器起作用
- 其他六大元件: 除了取样器和逻辑控制元件之外, 如果是某个取样器的子节点, 则该元件对其父子结点起作用
- 如果父节点不是取样器, 则其作用域是该元件父节点下的其他所有后代节点
5. jmeter简单操作步骤
- 启动jmeter
- 在测试计划下添加线程组
- 在线程组下添加HTTP请求取样器
- 填写HTTP请求的相关请求数据
- 在线程组下添加查看结果树监听器
- 点击启动按钮运行,并查看结果
6. 线程组的特点
- 模拟多人操作
- 左键点击线程组, 配置数量
- 线程组可以添加多个, 多个线程组可以并行或串行
- 测试计划 -> 独立运行每个线程组
- 如果勾选, 串行执行
- 如果不勾选, 并行执行
- 取样器(请求)和逻辑控制器必须依赖线程组才能使用
- 线程组下可以添加其他元件下的组件
7. 线程组的分类
setup线程组
先运行该线程组
普通线程组
用于发送业务请求的线程组, 受并行或串行配置影响
teardown线程组
最后运行该线程组
8. 线程组参数
线程数
需要模拟的用户数, 代表并发用户数,体现服务器负载量
Ramp-up时间
模拟的虚拟用户数全部启动所需要的时间
目的: 模拟性能测试场景接近用户使用习惯
循环次数
配置脚本运行时发送请求的次数, 代表执行时间, 不能与线程数进行替换
永远: 无线循环, 一直请求下去. 一般会勾选调度器, 设置持续循环时间
延迟创建线程直到需要
当使用线程发送请求时, 才分配资源, 如果暂未启动该线程, 则不分配, 如果不够选, 在jmeter点击运行时立即分配
调度器配置启动延迟
等待相应的时间才开始启动
9. HTTP请求参数配置
1. 协议
- HTTP
- HTTPS
2. 服务器名称和IP
- IP/域名
3. 端口号
4. 方法
- GET
- POST
5. 路径
接口请求URL中IP+port之后的路径部分(GET请求参数也可以)
6. 内容编码
UTF-8
7. 参数
放在请求URL中的参数
8. 消息体数据
放在消息体中的参数
10. 查看结果树
取样器结果, HTTP请求结果
11. 参数化
1. 参数化的常用方式
- 用户定义的变量
- 用户参数
- CSV Data Set Config
- 函数
1. 用户定义的变量
第一种方式
添加方式: 测试计划 -> 线程组 -> 配置元件 -> 用户定义的变量
使用用户的变量配置被测系统的协议、域名和端口
操作步骤: 添加线程组->添加用户定义的变量->添加HTTP请求->添加查看结果树
HTTP请求中引用:
${ 定义的参数名 }
第二种方式–测试计划
测试计划 -> 用户定义的量
HTTP请求中引用:
${ 定义的参数名 }
2. 用户参数
线程组->前置处理器->用户参数
添加用户: 可以添加多组用户
添加参数: 针对每个用户添加多个参数
3. CSV数据文件配置
测试计划->线程组->配置元件->CSV数据文件设置
步骤
- 定义CSV数据文件
- 添加线程组
- 添加CSV数据文件配置
- 文件编码: UTF-8
- 变量名称
- 添加HTTP请求
- CSV参数名称
- 值: CSV文件配置里的名称
- 添加查看结果树
4. 通过函数(_counter)方式进行参数化
计数函数, 一般做执行次数统计使用, 生成动态变化的数值
位置: 在菜单中选择->选项->函数助手对话框
在HTTP取样器中,应用counter函数生成的函数字符串,就可以读取counter函数生成的数值
- 如果counter参数设置为: TRUE, 则每个用户分别从1开始计算, 每循环一次加1
- 如果counter参数设置为: FALSE, 则所有用户共用一个计数器, 每发送一个请求时, 取值加1
12. 断言
1. 响应断言
通过自动化的手段对请求的响应数据进行自动校验
步骤
- 添加线程组
- 添加HTTP请求
- 添加响应断言
- 添加断言结果
- 添加查看结果树
测试字段–选择要进行校验的部分
6. 响应文本 —> 响应体中的数据
7. 响应代码 —> 响应状态码
8. 响应信息 —> 响应状态码对应的信息
9. Response Headers —> 响应头
10. Request Headers —> 请求头
11. URL样本 —> 请求URL
12. Document —> 响应数据的文本格式
13. 忽略状态 —> 勾选后, 如果客户端和服务器端报错, 不主动判定为发送消息失败
14. Request Data —> 请求参数
模式匹配规则
15. 包括/匹配 —> 通过正则表达式方式校验
16. Equals —> 等于
17. Substring —> 包含
18. 否 —> 非, 取反
19. 或者 —> 添加多个数据时, 满足其中一个即可
测试模式
预期结果的数据, 可添加多个
2. JSON断言
步骤
- 首先解析JSON数据, 如果不是JSON数据, 则验证失败
- 使用Jayway JasonPath 1.2.0中的语法搜索指定的路径, 如果找不到路径, 就会失败
- 如果在文档中找到Json路径, 并且要求对期望值进行验证, 那么它将执行验证操作
- 添加方式: 测试计划–>线程组–>HTTP请求–>(右键添加)断言–>JSON断言
3. 断言持续时间
添加方式: 测试计划–>线程组–>HTTP请求–>(右键添加)断言–>断言持续时间
13. 关联
当请求间有依赖关系, 一个请求的入参, 需要用到之前请求的响应数据时, 需要用到关联.
1. 正则表达式
- . : 是通配符, 可以代表任何字符(除了换行和回车)
- *: 代表前面的字符出现0次或者多次
- .* : 匹配规则, 左边界值, 左边第一个匹配的值, 右边界值, 最后一个匹配的值
- ? : 非贪婪匹配, 找到左边界后, 往右边查找右边界, 只要有匹配到的右边界便停止查找, 然后再次查找左右边界
正则表达式提取器
5. 引用名称: 保存提取出的数据变量, 用于后续的请求来引用
6. 正则表达式: 从响应结果中提取出需要的数据内容, 注意: 加括号, 才能提取
7. 模板: 当正则表达式中有多个括号时, 需取第几个括号中值来保存变量
8. 匹配数字: 当一个变量(括号)中有多个值时, 取第几个, 1表示取第一个, -1代表取所有
9. 缺省值: 当没有提取数据时, 返回一个默认值
步骤
10. 添加线程组
11. 添加HTTP请求
12. 添加正则表达式提取器
13. 添加HTTP请求, 引用正则表达式
14. 添加结果树
2. XPath提取器
添加方式: 测试计划->线程组->HTTP请求->(右键添加)后置处理器->Xpath提取器
应用场景: 只能适用于响应消息为HTML格式的情况
- XML Parsing Options ---- Use Tidy(tolerant parser) 勾选, 才能解析HTML格式文件
- 引用名称 ---- 定位到指定元素后, 要保存的变量
- Xpath query ---- xpath路径
- 匹配数字 ---- 返回匹配的数据, 如果填写1, 则返回第一个数据, 如果填写-1, 则返回所有数据
- 缺省值: 如果没有匹配的数据, 返回默认值
3. JSON提取器
添加方式: 测试计划->线程组->HTTP请求->(右键添加)后置处理器->JSON提取器
应用场景: 适用于返回的数据类型为JSON格式的情况
- Names of created variables ---- 提取出的参数要保存的变量名
- Json Path expression ---- Json数据的路径
- Match No. ---- json路径对应的数据个数, 一般不用填写, 唯一
- Default Values ---- 默认值, 如果没有提取出数据, 返回默认值
BeanShell取样器
将JSON提取器提取的值保存为Jmeter属性
操作步骤
- 添加线程组1
- 添加HTTP请求
- 添加JSON提取器
- 添加Beanshell取样器
- 添加线程组2
- 添加另一个HTTP请求
- 添加查看结果树