性能&接口测试工具----Jmeter

接口测试

什么是接口测试以及为什么要做接口测试

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. 目前市面上的接口测试工具应用场景

1. jmeter + ant + jenkins + git/svn 接口自动化
2. postman + newman + jenkins + git/svn接口自动化
3. 其他: soupUI, apipost, postwoman, fidder, charles
4. 分布式版本控制工具: git github, gitlab, gitee

Jmeter

1. jemter功能

1. 软件压力测试
2. 功能回归测试
3. 性能测试
4. 接口测试
5. 数据库压力测试
6. 批量生产测试数据

2. jmeter文件目录

1. bin目录

1. jmeter.bat windows的启动文件
2. jmeter.sh Linux的启动文件
3. jmeter.log 日志文件
4. jmeter.properties 系统配置文件
5. jmeter - server.bat windows分布式的执行启动文件
6. jmeter - server Linux分布式执行的启动文件\

2. docs目录

1. jmeter的接口api文档的存放位置
2. docs-api-index.html 所有的jmeter接口文档主页, 适用于二次开发

3. printable_docs目录

1. usermanual-index.html jmeter使用手册
2. usermanual-component_reference.html 核心元件帮助文档

4. lib目录

1. 存放jmeter依赖的所有.jar包
2. ext jar包, 第三方插件

3. jemter语言修改

1. 临时修改: Options -> Choose Language -> Chinese(Simple)
2. 永久修改: jmeter.properties -> Language -> 去掉"#", en改成zh_cn

元件与组件

1. 元件: 类似于python中的类

添加在线程组之下(线程组: 相当于模拟的用户)

1. 取样器: 发送请求, 类似于python中request
2. 逻辑控制器: 控制语言的执行顺序, 类似于python中的逻辑控制语句
3. 前置处理器: 在请求发送之前执行, 类似于python中的setup
4. 后置处理器: 在请求发送之后执行.类似于python中的teardown
5. 断言: 对响应结果进行断言, 类似于python中的assert
6. 定时器: 等待一定的时间, 类似于python中的sleep
7. 测试片段: 封装一段代码, 供脚本调用, 不直接执行, 类似于python中自己封装的基础类
8. 配置元件: 参数赋值作用, 类似于python自动化参数化
9. 监听器: 查看脚本运行结果, 类似于python调试窗口的结果打印

2. 组件: 类似于python类中的方法

4. 元件作用域

1. 元件作用域是靠测试计划的树形结构中元件父子关系确定的
2. 核心: 取样器, 其他组件都是以取样器为中心运行的, 组件添加位置不同, 生效的取样器也不同

作用域原则

1. 取样器: 元件不和其他元件相互作用, 因此不存在作用域问题
2. 逻辑控制器: 元件只对其子节点中的取样器和逻辑控制器起作用
3. 其他六大元件: 除了取样器和逻辑控制元件之外, 如果是某个取样器的子节点, 则该元件对其父子结点起作用
4. 如果父节点不是取样器, 则其作用域是该元件父节点下的其他所有后代节点

5. jmeter简单操作步骤

1. 启动jmeter
2. 在测试计划下添加线程组
3. 在线程组下添加HTTP请求取样器
4. 填写HTTP请求的相关请求数据
5. 在线程组下添加查看结果树监听器
6. 点击启动按钮运行,并查看结果

6. 线程组的特点

1. 模拟多人操作
   1. 左键点击线程组, 配置数量
2. 线程组可以添加多个, 多个线程组可以并行或串行
   1. 测试计划 -> 独立运行每个线程组
   2. 如果勾选, 串行执行
   3. 如果不勾选, 并行执行
3. 取样器(请求)和逻辑控制器必须依赖线程组才能使用
4. 线程组下可以添加其他元件下的组件

7. 线程组的分类

setup线程组

先运行该线程组

普通线程组

用于发送业务请求的线程组, 受并行或串行配置影响

teardown线程组

最后运行该线程组

8. 线程组参数

线程数

需要模拟的用户数, 代表并发用户数,体现服务器负载量

Ramp-up时间

模拟的虚拟用户数全部启动所需要的时间
目的: 模拟性能测试场景接近用户使用习惯

循环次数

配置脚本运行时发送请求的次数, 代表执行时间, 不能与线程数进行替换
永远: 无线循环, 一直请求下去. 一般会勾选调度器, 设置持续循环时间

延迟创建线程直到需要

当使用线程发送请求时, 才分配资源, 如果暂未启动该线程, 则不分配, 如果不够选, 在jmeter点击运行时立即分配

调度器配置启动延迟

等待相应的时间才开始启动

9. HTTP请求参数配置

1. 协议

1. HTTP
2. HTTPS

2. 服务器名称和IP

1. IP/域名

3. 端口号

4. 方法

1. GET
2. POST

5. 路径

接口请求URL中IP+port之后的路径部分(GET请求参数也可以)

6. 内容编码

UTF-8

7. 参数

放在请求URL中的参数

8. 消息体数据

放在消息体中的参数

10. 查看结果树

取样器结果, HTTP请求结果

11. 参数化

1. 参数化的常用方式

1. 用户定义的变量
2. 用户参数
3. CSV Data Set Config
4. 函数

1. 用户定义的变量

第一种方式
添加方式: 测试计划 -> 线程组 -> 配置元件 -> 用户定义的变量
使用用户的变量配置被测系统的协议、域名和端口
操作步骤: 添加线程组->添加用户定义的变量->添加HTTP请求->添加查看结果树
HTTP请求中引用：
${ 定义的参数名 }

第二种方式–测试计划
测试计划 -> 用户定义的量
HTTP请求中引用：
${ 定义的参数名 }

2. 用户参数

线程组->前置处理器->用户参数
添加用户: 可以添加多组用户
添加参数: 针对每个用户添加多个参数

3. CSV数据文件配置

测试计划->线程组->配置元件->CSV数据文件设置

步骤

1. 定义CSV数据文件
2. 添加线程组
3. 添加CSV数据文件配置
   1. 文件编码: UTF-8
   2. 变量名称
4. 添加HTTP请求
   1. CSV参数名称
   2. 值: CSV文件配置里的名称
5. 添加查看结果树

4. 通过函数(_counter)方式进行参数化

计数函数, 一般做执行次数统计使用, 生成动态变化的数值
位置: 在菜单中选择->选项->函数助手对话框
在HTTP取样器中,应用counter函数生成的函数字符串,就可以读取counter函数生成的数值

• 如果counter参数设置为: TRUE, 则每个用户分别从1开始计算, 每循环一次加1
• 如果counter参数设置为: FALSE, 则所有用户共用一个计数器, 每发送一个请求时, 取值加1

12. 断言

1. 响应断言

通过自动化的手段对请求的响应数据进行自动校验
步骤

1. 添加线程组
2. 添加HTTP请求
3. 添加响应断言
4. 添加断言结果
5. 添加查看结果树

测试字段–选择要进行校验的部分
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断言

步骤

1. 首先解析JSON数据, 如果不是JSON数据, 则验证失败
2. 使用Jayway JasonPath 1.2.0中的语法搜索指定的路径, 如果找不到路径, 就会失败
3. 如果在文档中找到Json路径, 并且要求对期望值进行验证, 那么它将执行验证操作
4. 添加方式: 测试计划–>线程组–>HTTP请求–>(右键添加)断言–>JSON断言

3. 断言持续时间

添加方式: 测试计划–>线程组–>HTTP请求–>(右键添加)断言–>断言持续时间

13. 关联

当请求间有依赖关系, 一个请求的入参, 需要用到之前请求的响应数据时, 需要用到关联.

1. 正则表达式

1. . : 是通配符, 可以代表任何字符(除了换行和回车)
2. *: 代表前面的字符出现0次或者多次
3. .* : 匹配规则, 左边界值, 左边第一个匹配的值, 右边界值, 最后一个匹配的值
4. ? : 非贪婪匹配, 找到左边界后, 往右边查找右边界, 只要有匹配到的右边界便停止查找, 然后再次查找左右边界

正则表达式提取器
5. 引用名称: 保存提取出的数据变量, 用于后续的请求来引用
6. 正则表达式: 从响应结果中提取出需要的数据内容, 注意: 加括号, 才能提取
7. 模板: 当正则表达式中有多个括号时, 需取第几个括号中值来保存变量
8. 匹配数字: 当一个变量(括号)中有多个值时, 取第几个, 1表示取第一个, -1代表取所有
9. 缺省值: 当没有提取数据时, 返回一个默认值

步骤
10. 添加线程组
11. 添加HTTP请求
12. 添加正则表达式提取器
13. 添加HTTP请求, 引用正则表达式
14. 添加结果树

2. XPath提取器

添加方式: 测试计划->线程组->HTTP请求->(右键添加)后置处理器->Xpath提取器
应用场景: 只能适用于响应消息为HTML格式的情况

1. XML Parsing Options ---- Use Tidy(tolerant parser) 勾选, 才能解析HTML格式文件
2. 引用名称 ---- 定位到指定元素后, 要保存的变量
3. Xpath query ---- xpath路径
4. 匹配数字 ---- 返回匹配的数据, 如果填写1, 则返回第一个数据, 如果填写-1, 则返回所有数据
5. 缺省值: 如果没有匹配的数据, 返回默认值

3. JSON提取器

添加方式: 测试计划->线程组->HTTP请求->(右键添加)后置处理器->JSON提取器
应用场景: 适用于返回的数据类型为JSON格式的情况

1. Names of created variables ---- 提取出的参数要保存的变量名
2. Json Path expression ---- Json数据的路径
3. Match No. ---- json路径对应的数据个数, 一般不用填写, 唯一
4. Default Values ---- 默认值, 如果没有提取出数据, 返回默认值

BeanShell取样器

将JSON提取器提取的值保存为Jmeter属性

操作步骤

1. 添加线程组1
2. 添加HTTP请求
3. 添加JSON提取器
4. 添加Beanshell取样器
5. 添加线程组2
6. 添加另一个HTTP请求
7. 添加查看结果树