1. 性能测试概述
1.1 性能测试基础
1.1.1 什么是性能测试
概念：测试软件的性能
- 后端处理性能–响应时间
- 服务器硬件资源（CPU、内存、磁盘）
- 中间件、网络、数据库、架构设计等是否存在瓶颈
中间件：提供系统软件和应用软件之间连接的软件。简称：应用服务器，如：Tomcat、Apache…
1.1.2 性能测试目的
- 评估当前系统能力–发布时
- 寻找性能瓶颈，优化性能–线上出问题，定位问题时使用
- 预估是否满足未来性能要求–为将来做准备
1.1.3性能测试与功能测试
-
焦点
-
功能测试：验证软件系统操作功能是否符合产品功能需求规格，主要焦点在功能（正向、逆向）
-
性能测试：验证软件系统是否满足业务需求场景，主要焦点是业务场景的满足（时间、空间）
注：
时间：软件的响应时间
空间：服务器的磁盘使用率，CPU使用率、内存空闲率…
-
-
关系：
- 功能测试和性能测试是相辅相成的，对于一款优秀的软件产品来讲，他们是不可减少的2个重要测试环境
1.2 性能测试分类
基准测试
基准测试策略：无论选取之前的任何一种测试方式，都需要先进行基准测试，作为后续测试结果的对比
- 基准测试的概念
狭义上讲：就是单用户测试。测试环境确定后，对业务模型中的重要业务做单独的测试，获取单用户运行时的各项性能指标
广义上讲：是一种测量和评估软件性能指标的活动，你可以在某个时刻通过基准测试建立一个已知的性能基准线，当系统的软硬件环境发生变化之后在进行一次基准测试以确定变化对性能的影响
-
基准测试的用途
-
基准测试不会单独存在
-
为多用户并发测试和综合场景测试等提供参考依据
-
为系统/环境配置、系统优化前后的性能提升/下降提供参考指标
-
- 负载测试
- 压力测试
- 并发测试
- 稳定性测试
1.2.1 负载测试
通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量的测试
1.2.2 压力测试
通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统处于失效状态
1.2.3 并发测试
通过模拟用户并发访问，测试多用户同时访问同一应用、模块或数据，观察系统是否存在问题
1.2.4 稳定性测试
给系统加载一定的业务压力的情况下，运行一段时间（24h，3X24h，7X24h）检查系统是否稳定
1.3 性能测试指标
- 吞吐量
- 并发数
- 响应时间
- 点击数
- 资源利用率
- 错误率
- TPS
- QPS
1.3.1 吞吐量
单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力
通常情况下，吞吐量用“请求数/秒”或者“页面数/秒”来衡量
从业务角度来看，吞吐量也可以用“业务数/小时"、“业务数/天”、”访问人数/天“、”页面访问量/天“来衡量
从网络角度看，吞吐量还可以用”字节数/小时“、”字节数/天“等来衡量网络的流量
每秒事务数（TPS）和每秒查询数（QPS）归属吞吐量，区别在于TPS\QPS描述服务器具体性能处理能力
1.3.2并发数
并发测试的用户数
并发用户数：某一物理时刻同时向系统提交请求的用户数
在线用户数：某段时间内访问系统的用户数，这些用户不一定同时向系统提交请求
系统用户数：系统注册的总用户数据
1.3.3 响应时间
响应时间指从客户端发起一个请求开始，到客户端接受到服务器端返回结果整个过程所耗费的时间
组成：响应时间=服务器处理时间+网络传输时间
响应时间分为前端展示时间和系统响应时间两部分。
前端展示时间指的是客户端收到服务器返回的数据后渲染前端页面，所耗费的时间。
系统的响应时间，分为web服务器，应用服务器，数据库服务器，等各种服务器之间通信和处理请求的时间。
前端展示时间（用户响应时间）：服务器发起请求到收到响应这段时间
N1+A1+N2+A2+N3+A3+N4
**系统响应时间（请求响应时间)：**服务器收到请求到发出响应这段时间
A1+N2+A2+N3+A3
影响一个软件响应时间的因素：网络带宽、数据库性能、服务器处理性能、软件算法逻辑
1.3.4 点击数
点击数是衡量web服务器处理能力的一个重要指标
注：
- 点击数不是通常以为的访问一个页面就是一次点击数，点击数是该页面包含的元素（如：图片、链接、框架等）向web服务器发出的请求数数量
- 通常我们也用每秒点击次数（Hits per Second）指标来衡量Web服务器的处理能力
- 只有web服务器才有此指标
1.3.5 资源利用率
指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量*100%”形成资源利用率的数据
提示：通常，没有特殊需求的话
- 建议CPU不高于80%（+—5）
- 内存不高于80%
- 磁盘不高于90%
- 网络不超过80%
1.3.6 错误率
错误率指系统在负载情况下，失败交易的概率。错误率=（失败交易数/交易总数）*100%
提示：
- 不同系统对错误率要求不同，但一般不超过（成功率为6到8个9）
- 稳定性较好的系统，其错误率应该由超时引起，即为超时率
1.3.7 TPS
Transaction Per Second，每秒事务数（单位时间内系统处理的客户端请求的事务次数）
计算：TPS= 并发数/平均响应时间
事务：业务站在代码角度的统称，可以理解为一段或多段代码
提示：TPS归属吞吐量
1.3.8 QPS
Query Per Second，每秒查询数（衡量web服务器处理能力的重要指标）
1.4 性能测试流程
- 性能测试需求分析
- 性能测试计划
- 性能测试用例
- 测试脚本编写/录制
- 搭建场景
- 运行脚本
- 系统性能调优
- 性能测试报告总结
功能测试流程
- 需求评审
- 测试计划（测试什么时候开始与结束，谁来测、怎么测）
- 测试设计（编写测试用例、开发测试工具、用例评审）
- 执行用例
- 缺陷管理
- 测试报告
1.4.1 性能测试需求分析
- 明确被测系统
- 熟悉被测系统的业务功能
- 熟悉被测系统的技术架构
- 明确测试内容
- 从业务角度明确测试内容
- 确定关键业务。即：用户使用频率较高的业务功能
- 从技术角度明确测试内容
- 如：通常逻辑复杂度较高的业务也是CPU密集运算较大的地方，考量服务器CPU在预定性能指标下是否达标
- 如：通常数据量较大的业务很占用系统内存，考量服务器CPU在预定性能指标下是否达标
- 从业务角度明确测试内容
- 明确测试策略
- 负载测试
- 压力测试
- 稳定性测试
- 并发测试
- 明确测试指标
1.4.2 性能测试计划与方案
说明：性能测试实施第一份文档，也是最重要的一份文档
主要内容：
-
项目背景
-
测试目标
- 确定此次性能测试的目标
-
人员安排
- 明确性能测试的时间，计划需要多少人来进行测试
-
时间进度
| 性能测试 | 工作日 | 开始时间 | 结束时间 |
|---|---|---|---|
| 测试用例设计 | |||
| 测试环境搭建 | |||
| 测试数据准备 | |||
| 脚本开发及执行 | |||
| 测试结果分析 |
-
性能测试环境
原则：尽量与生产环境保持一致
- 系统架构
- 软硬件配置
- 测试数据
-
测试工具
- 性能测试工具、监控工具
-
测试策略
- 确定性能测试类型
- 负载测试
- 压力测试
- 稳定性测试
- 并发测试
- 确定性能测试场景
- 单一场景：
- 服务器同一时刻只进行同一业务操作。如抢红包
- 混合场景：
- 服务器同一时刻处理多个不同业务操作。如网上商城搜索商品、加入购物车、下订单、支付。
- 单一场景：
- 确定性能测试类型
-
风险控制
1.4.3 性能测试用例
用例应覆盖到测试需求，主要包括（测试步骤、并发数、目标值、场景策略）
1.4.4 测试脚本编写/录制
性能测试用例编写完成以后，接下来就需要结合用例的需要，进行测试脚本的编写工作。
1.4.5 搭建场景
测试场景的设计一个重要的原则就是依据测试用例，把测试用例设计的场景展现出来
提示：
- 虚拟用户数量及启动虚拟用户方式
- 场景的相关设置（如：集合点）
- 脚本是否存在依赖关系（登陆与注册）
1.4.6 运行脚本
运行脚本就是运行场景
注意：
- 负载的测试机不能够运行设定的虚拟用户数
- 没有“预热过程”
- 没有模拟用户的真实环境
- 性能用例运行次数过少
1.4.7 系统性能调优
性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈
提示：
- 调优人员（开发人员、数据库管理员、系统管理员、网络管理员、性能测试分析人员）相关人员对系统进行调整
- 验证-性能测试人员继续进行第二轮、第三轮的测试，与以前的测试结果进行对比，从而确定经过调整以后，系统的性能是否有提升
注意：
系统调优由易到难的先后顺序如下：
- 硬件问题
- 网络问题
- 应用服务器、数据库等配置问题
- 源代码、数据库脚本问题
- 系统架构问题
1.4.8 性能测试报告总结
- 性能测试需求覆盖情况，性能测试过程中出现的问题，如何去分析、调优、解决的
- 测试人员、进度控制与实际执行偏差和性能测试过程中遇到各类风险是如何控制的
- 经过该项目性能测试后，有哪些经验和教训等内容
功能测试报告总结
2. 性能测试工具
2.1 常用性能测试工具
-
LoadRunner
- HP LoadRunner是一种工业级标准性能负载工具，可以模拟上万用户实施测试，并在测试时可实时检测应用服务器及服务器硬件各种数据，来确认和查找存在的瓶颈
- 支持多协议：Web（HTTP/HTML)\windows Sockets、FTP、ODBC、MS SQL Server等协议
- 最初是Mercury公司采用C语言编写，现被HP公司收购
缺点
- 收费
- 体积庞大
- 无法定制功能
优点
- 多用户（支持数量单位万）
- 详细分析报表
- 支持ip欺骗
-
Jmeter
- JMeter是Apache组织基于Java开发的一款性能测试软件。
- 多协议（HTTP/HTTPS、JDBC、JAVA……）
缺点：
- 不支持ip欺骗
- 分析和报表能力相对于lr欠缺精度
优点：
- 开源
- 免费
- 丰富的扩展组件
- 应用广泛
- 易上手
2.2 JMeter
JMeter环境搭建
JMeter启动方式
- 双击 jmeter.bat
- 双击 ApacheJMeter.jar 选择使用java程序打开
- 命令行输入：java -jar ApacheJMeter.jar
JMeter功能概要
JMeter文件目录介绍
-
bin目录
存放可执行文件和配置文件
jmeter.bat : windows的启动文件
jmeter.log : 日志文件
jmeter.sh : linux的启动文件
jmeter.properties : 系统配置文件
jmeter-server.bat : windows分布式测试要用到的服务器配置
jmeter-serve : linux分布式测试要用到的服务器配置
-
docs目录
- docs：是Jmter的api文档，可打开api/index.html页面来查看
-
printable_docs目录
-
printable_docs的usermanual子目录下的内容是Jmeter的用户手册文档
-
index.html是用户手册文档的目录
-
usermanual下component_reference.html是最常用到的核心元件帮助文档
提示：printable_docs的demos子目录下有一些常见的JMeter脚本案例，可以作为参考
-
-
lib目录
该目录用来存放JMeter依赖的jar包和用户扩展所依赖的jar包
JMeter基本使用流程
需求：使用JMeter访问百度首页接口，并查看请求和响应信息
操作步骤：
- 启动JMeter
- 在“测试计划”下添加”线程组“
- 在”线程组“下添加”HTTP请求“取样器
- 填写”HTTP请求“的相关请求数据
- 在”线程组下添加“查看结果树”监听器
- 点击“启动”按钮运行，并查看结果
JMeter基本元件
元件：多个类似功能组件的容器统称
组件：实现独立某个功能的统称（类似于函数）
取样器：不同协议实现的组件
-
线程组：模拟用户的
-
配置元件：进行测试环境和测试数据的初始化，类似于自动化脚本中的setup
-
前置处理器：对要发送的请求进行预处理，类似于自动化脚本中的参数化
-
取样器：往服务器发送请求，类似于自动化脚本中的发送请求的代码
-
后置处理器：对收到的服务器的响应进行数据提取，类似于自动化脚本中获取响应中特定字段的语句
-
断言：将收到的响应结果与预期结果进行对比
-
监听器：查看测试脚本运行的结果和日志，类似于自动化脚本中的测试报告
-
定时器：等待一段时间，类似于自动化脚本中的测试报告
-
测试片段：封装基本功能，不单独执行，需要通过脚本调用才能执行，类似于自动化脚本中封装的函数
线程组
线程组是控制Jmeter将用于执行测试的线程数，也可以把一个线程理解为一个测试用户
线程组的特点
- 设定线程数（模拟多人操作）
- 取样器（请求）和逻辑控制器必须依赖线程组才能使用
- 线程组可以添加多个，多个线程组可以串行或并行
- 默认情况下线程组为并行执行，如果要修改为串行，需要到测试计划里勾选独立运行每个线程组
- 线程组下可以添加其他元件下组件
线程组分类
- 线程组
普通的、常用的线程组，可以看作一个虚拟用户组，线程组的每一个线程都可以理解为一个虚拟用户
- setUp线程组
一种特殊类型的线程组，可用于执行预测试操作
- tearDown线程组
一种特殊类型的线程组，可用于执行测试后工作
线程组参数详解
- 线程数：模拟虚拟用户数
- Ramp-up时间：虚拟用户启动所需要的时间
- 循环次数：
- 配置指定次数：控制脚本循环执行的次数
- 配置循环永远
- 需要调度器配置使用
- 运行时间：脚本执行的时间
- 延迟启动时间：脚本等待特定的时间才能开始运行
- 线程数m和循环次数n的关系：
- 如果同时配置，实际发送的http请求数应该为m*n
- 虽然发送请求的次数相同，但是不能相互替换
- 线程组：代表并发用户数，是服务器的负载量
- 循环次数：代表执行时间
JMeter元件作用域和执行顺序
在Jmeter中，元件的作用域是靠测试计划的树形结构中元件的父子关系来确定的
- 核心是取样器，其他组件都是以取样器为核心运行的，组件添加的位置不同，生效的取样器也不同
作用域的原则
- 取样器：元件不和其他元件相互作用，因此不存在作用域的问题
- 逻辑控制器：元件只对其子节点中的取样器和逻辑控制器作用
- 其他六大元件：除取样器和逻辑控制器元件外，如果是某个取样器的子节点，则该元件对其附子节点起作用
- 如果其父节点不是取样器，则其作用域是该元件父节点下的其他所有后代结点（包括子节点，子节点的子节点等）
元件执行顺序
- 配置元件
- 前置处理程序
- 定时器
- 取样器
- 后置处理程序
- 断言
- 监听器
提示：
- 前置处理器、后置处理器、断言等元件功能对取样器起作用（如果在他们的作用域内没有任何取样器，则不会被执行）
- 如果在同一作用域范围内有多个同一类型的元件，则这些元件按照他们在测试计划中的上下顺序依次执行
JMeter参数化
参数化常用方式
-
用户定义的变量
-
添加方式：测试计划->线程组->配置元件->用户自定义的变量
-
场景
请求：https://www.baidu.com:443
要求：使用用户定义的变量配置被测系统的协议、域名和端口 -
操作步骤：
- 添加线程组
- 添加用户定义的变量，定义变量
- 添加http请求，使用变量
- 添加查看结果树
-
-
用户参数
-
添加方式：测试计划->线程组->前置处理器->用户参数
-
场景
请求：https://www.baidu.com:443/?name=KaTeX parse error: Expected 'EOF', got '&' at position 7: {name}&̲age={age}
要求：使用用户参数配置的用户信息（姓名、年龄） -
操作步骤：
- 添加线程组
- 添加用户参数，定义参数
- 添加http请求，使用参数
- 添加查看结果树
-
运行结果：
-
CSV Data Set Config
-
添加方式：测试计划->线程组->配置元件->CSV数据文件设置
-
场景：
请求：https://www.baidu.com:443/?name=KaTeX parse error: Expected 'EOF', got '&' at position 7: {name}&̲age={age}
要求：循环3次，每次请求附带参数值不同 -
操作步骤：
- 编写CSV数据文件（.csv作为后缀）
- 配置csv数据文件设置
- 文件名：填写csv文件的路径，建议使用相对路径
- 文件编码：UTF-8
- 变量名称：从csv数据文件中读取的数据需要保存的变量名，有多个变量时用逗号分割
- 忽略首行：是否从csv数据文件第一行开始读取
- 分隔符：要求与csv数据文件中多列的分隔符一致
- 遇到文件结束符再次循环：默认true
- 遇到文件结束符是否停止线程：当前一个参数为False，该参数有效，一般设置为True
- 在请求中引用csv定义的变量
运行结果：
-
-
函数(_counter)
- 使用：菜单->工具->函数助手对话框
运行结果：
JMeter断言
响应断言
-
添加方式：测试计划->线程组->HTTP请求->（右键添加）断言->响应断言
-
配置：
- 测试字段：需要检查的字段
- 模式匹配规则：需要使用什么规则来进行检查
- 测试模式：需要校验的值
JSON断言
-
该组件用来对JSON文档进行验证，验证步骤如下：
- 首先解析JSON数据，如果数据不是JSON，则验证失败
- 使用Jayway JsonPath1.2.0 中的语法搜索指定的路径。如果找不到路径，就会失败
- 如果在文档中找到JSON路径，并且要求对期望值进行验证，那么它将执行验证操作
-
添加方式：测试计划 --> 线程组 --> HTTP请求 --> （右键添加）断言 – > JSON断言
-
案例：
场景：
- 请求：http://www.weather.com.cn/data/sk/101010100.html
- 检查：让程序检查相应的JSON数据中，city对应的内容是否为“上海”
持续时间断言（Duration Assertion）
-
添加方式：测试计划 --> 线程组 --> HTTP请求 --> （右键添加）断言 – > JSON断言
-
案例：
场景：
- 请求：http://www.baidu.com
- 检查：程序响应时间是否大于500ms
JMeter关联
当多个请求之前有依赖关系，后一个请求的参数需要使用前一个请求的相应数据时，需要用到关联
分类：
- 正则表达式提取器
- xpath提取器
- JSON提取器
正则表达式提取器
<title>百度一下，你就知道</title><title>百度一下，你就知道</title>
<title>.*?</title> -- 查找结果 <title>百度一下，你就知道</title>
<title>.*</title> -- 查找结果 <title>百度一下，你就知道</title><title>百度一下，你就知道</title>
. : 是通配符，可以代表任意字符（除换行回车）
* : 代表前面的字符出现0次或者多次
? : 代表非贪婪匹配，找到左边界后，往右查找匹配右边界，只要有匹配的右边界就停止查找。再次查找左边界和右边界
-
添加方式：测试计划->线程组->HTTP请求->（右键添加）后置处理器->正则表达式提取器
-
案例：
请求：http://106.54.9.13/index.php/Admin/Admin/login,获取网页的title值
请求：https://www.baidu.com/，把获取到的title作为参数
-
步骤
- 添加正则表达式提取器，并配置
- 要检查的响应字段：默认主体
- 引用名称：匹配后的数据要存储的变量名
- 正则表达式：
(.*?) ()里是要保存的数据 - 模版：
1
1
1
- 数字1代表上面正则表达式中第几个（）
- 匹配数字：0代表随机值，1代表第一个结果，-1代表所有结果
- 缺省值：没有匹配的时候的变量的缺省值
-
变量的引用
运行结果：
- 添加正则表达式提取器，并配置
-
Debug Sampler 查看所有匹配的字符串
-
XPATH提取器
-
添加方式：测试计划->线程组—>HTTP请求->（右键添加）后置处理器->XPATH提取器
-
场景
请求：http://106.54.9.13/index.php/Admin/Admin/login,获取网页的title值
请求：https://www.baidu.com/，把获取到的title作为请求参数
-
操作步骤
-
添加Xpath提取器并配置
- Use Tidy （tolerant parser）：如果勾选此项，则使用Tidy将HTML响应解析为XHTML。当需要处理的页面是HTML格式时，必须选中该选项，当需要处理的页面是XML或XHTML格式（例如：RSS返回）时，取消选中该选项
- 引用名称：存放提取出的值的参数
- XPath Query：用于提取值的XPath表达式
- 匹配数字：如果XPath路径查询导致许多结果，则可以选择提取哪个作为变量
- 0：随机
- -1：表示提取所有的结果
- X：表示提取第X个结果，如果X大于匹配项的数量，则不返回任何内容。将使用默认值
- 缺省值：参数的默认值
-
-
-
JSON提取器
-
添加方法：测试计划->线程组->HTTP请求->（右键添加）后置处理器->XPath提取器
-
场景：
请求获取天气的接口：http://www.weather.com.cn/data/sk/101010100.html
获取返回结果中的城市名称
请求：https://www.baidu.com/s?wd=北京，把获取到的城市名称作为请求参数
-
步骤：
- 添加JSON提取器，配置
- 引用名称：匹配后的数据要存储的变量名
- JSON path:$.weatherinfo.city
- 引用变量名
- 添加JSON提取器，配置
-
JMeter逻辑控制器
if控制器
if控制器用来控制它下面的测试元素是否运行
-
添加方式：测试计划-> 线程组 -> （右键添加）逻辑控制器 -> if控制器
-
案例
需求：
- 使用“用户定义的变量”定义一个变量city，city的值可以是"北京"或"上海"
- 根据name的变量值实现对应网站的访问
-
步骤
-
添加if控制器并配置
- 使用js语法：“${name}”==‘baidu’
- 使用jmeter函数的方式：
-
-
循环控制器
通过设置循环次数，来实现循环发送请求
-
添加方式：测试计划->线程组->（右键添加）逻辑控制器->循环控制器
-
案例
需求：循环访问百度十次
-
操作步骤
- 添加循环控制器，并配置
-
循环控制器中的循环次数配置m与线程组中的循环次数n配置对比
- 如果同时配置，循环控制器下HTTP请求实际的执行次数应该是m*n
- 区别：作用域不同
-
-
ForEach控制器
ForEach控制器一般和用户自定义变量或者正则表达式提取器一起使用，其在用户自定义变量或者从正则表达式提取器的返回结果中读物一系列相关的变量。该控制器下的采样器或控制器都会被执行一次或多次，每次读取不同的变量值
-
添加方式：测试计划->线程组->（右键添加）逻辑控制器->ForEach控制器
-
案例
- 有一组关键字[hello,python,测试],使用用户定义的变量存储
- 要一次取出关键字，并在百度搜索，例如：https://www.baidu.com/?wd=hello
-
步骤
-
添加ForEach控制器，并配置
-
用户定义的变量
变量名：固定前缀+连续数字
-
ForEach控制器
- 变量前缀：用户定义的变量中配置的固定前缀
- 起始数字：连续数字的最小值-1
- 结束数字：连续数字的最大值
- 输出变量名称：自定义变量名
-
-
-
与正则表达式的配合使用
- 步骤
- 先通过正则表达式提取器，提取出请求中所有满足条件的数据
- 添加ForEach控制器，并配置提取出所有满足条件的数据，并保存为变量
- 在其子节点下，添加HTTP请求并引用变量，则可循环读取正则表达式中匹配的所有数据
- 步骤
-
JMeter定时器
1. 同步计时器（Synchronizing Timer）
在JMeter中叫做同步定时器，在其他软件中又叫集合点
- 介绍
SyncTimer地目的是阻塞线程，直到阻塞了n个线程，然后立即释放它们
同步定时器相当于一个储蓄池，累积一定的请求，在当规定的时间内达到一定的线程数量，这些线程会在同一个时间点一起并发，所以可以用来做大数据量的并发请求
- 添加方式：测试计划->线程组->HTTP请求->(右键添加)定时器->Synchronizing Timer
- 案例
模拟100个用户同时访问必应 (bing.com)，统计高并发情况下平均响应时间以及错误率
-
操作步骤
-
添加同步定时器并配置
-
并发数：同时达到多少用户才开始发送请求
-
超时时间：
超过多少时间就发送请求（不管并发数有没有达到）
必须配置：否则当线程数无法被模拟用户组的数量整除时，就会有部分的用户挂起无法执行
配置不能太短：必须比模拟用户组的数量加载的时间要长，否则无法达到并发数的要求，数据就会被释放掉
-
-
常数吞吐定时器（Constant Throughput Timer）
常数吞吐量定时器可以让JMeter以指定数字的吞吐量（以每分钟的样本数为单位，而不是每秒）执行。吞吐量计算的范围可以指定为当前线程、当前线程组、所有线程组
添加方式：测试计划->线程组->HTTP请求->(右键添加)定时器->Constant Throughput Timer
-
案例
场景：一个用户以20QPS（20次/s）的频率访问https://cn.bing.com/，持续一段时间，统计服务器的平均响应时间
-
操作步骤
添加并配置常数吞吐量定时器
JMeter分布式测试
在使用JMeter进行性能测试时，如果并发数比较大（比如项目需要支持10000并发），单台电脑的（CPU和内存）可能无法支持。这时可以使用JMeter提供的分布式测试的功能。
应用场景
- 当测试机无法模拟用户需要的业务负载量时，需要使用多台测试机配合测试
原理
- 分布式测试时分为一台控制机和多台代理机
- 控制机负责发布测试任务给代理机
- 代理机接收任务并向服务器发送请求，并接收服务器返回的响应，然后将测试结果返回给控制机
- 由控制机对测试结果进行汇总统计
Apache JMeter - Apache JMeter Distributed Testing Step-by-step
分布式相关注意事项
- 系统上的防火墙已关闭或正确的端口已打开。
- 所有客户端都位于同一子网上。
- 如果使用 192.x.x.x 或 10.x.x.x IP 地址，则服务器位于同一子网中。 如果服务器不使用 192.xx 或 10.xx IP 地址，则应该没有任何问题。
- 确保 JMeter 可以访问服务器。
- 确保在所有系统上使用相同版本的 JMeter 和 Java。混合版本将无法正常工作。
- 您已为 RMI 设置或禁用了 SSL。
代理机（Agent）配置
- Agent机上安装JMeter
- 修改服务端口（非必须，只要保证套接字唯一就行）
打开bin/jmeter.properties文件，修改“server_port"
-
关闭RMI.SSL开关
打开bin/jmeter.properties文件，修改“rmi.ssl" 为disable
-
运行
jmeter-server.bat
控制机（Controller）配置
-
控制机上安装jmeter
-
配置remote_server:所有代理机的IP+port,有多台代理机时，用逗号分割
-
关闭RMI.SSL开关
打开bin/jmeter.properties文件，修改“rmi.ssl" 为disable
-
运行
jmeter.bat
JMeter测试报告
JMeter性能测试常用图标
3. 接口性能实战
项目搭建
项目API介绍
接口清单梳理
接口脚本设计
场景搭建与执行
测试报告及分析
4.web性能实战
JMeter实现web测试前置知识
JMeter脚本录制
在没有接口文档的就项目中，快速录制web页面产生的http接口请求，帮助编写接口测试脚本
录制原理
录制时，JMeter作为代理服务器来拦截和转发请求与响应数据
操作步骤
- 添加http代理服务器，并进行配置
添加：测试计划（右键）->非测试元件->HTTP代理服务器
- 开启windows操作系统的浏览器代理
- 启动代理服务器，开始录制
4.录制好的接口脚本就存放在指定路径下
1508
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
