取样器、断言、监听器
前置处理器、配置原件、后置处理器
控制器
定时器
线程组
元件：
测试计划：用来管理一个脚本代码
线程组：用来产生负载，管理测试任务现成数据等
取样器：向服务器发送请求任务，接受返回的响应结果
监听器：用来记录测试结果
逻辑控制器：控制执行条件或执行次数等逻辑
配置原件：实现参数化等需要使用
定时器：模拟并发、延时等场景
断言：验证响应数据与预期一致
前置处理器：请求发送之前对即将发出的请求与进行的处理
后置处理器：在响应返回后处理返回的数据状态
测试片段：封装一段脚本，类似一个函数
作用域：

  • 取样器一定会被执行，不存在作用域问题
  • 逻辑控制器只对它的后代节点有效
  • 取样器下级所有元件作用域就是一个取样器
  • 线程组下级所有元件作用域就是一个线程组

执行顺序：

  • 配置元件
  • 前置处理器
  • 定时器
  • 取样器
  • 后置处理器
  • 断言
  • 监听器

规则：

  • 如果元件的作用对象不存在，则其不会被执行
  • 同一作用域范围内存在多个同一类型的元件，则这些元件按其树中的上下顺序依次执行
  • 如果循环控制器设置为永远循环，那么线程只会永远执行该节点下的元件，其后面所有的元件不会被执行

配置元件：

  • http cookie管理器
  • http 信息头管理器
  • http 请求默认值
  • csv data set config
  • 用户定义的变量

header和cookie

  • header就是消息头，包含请求头和响应头
    • header包含了cookie和session、编码、协议类型、返回类型、提交的参数、客户端信息等
  • cookie存储在用户本地终端上的数据
    • cookie作为一种标识符，有服务器创建，存储在浏览器客户端
  • cookie与header联系
    • 客户端发送的请求头，包含提交的cookie等各种参数信息
    • 服务器响应的响应头，包含返回的数据结构和生成cookie等参数信息

http cookie管理器

  • 应用场景：当借口测试，多个接口之间的关联性，比如第二个接口测试要获取第一个接口的cookie，使用http cookie管理方式，可以看到具体的cookie值
    • 比如登录后修改用户信息，正常情况下要修改用户信息得先登录成功
    • 通过http cookie管理器实现业务关联

http cookie管理器特性：

  • 能够像web浏览器一样存储和发送cookie，若有一个http请求和响应包含一个cookie，cookie管理器会自动存储该cookie，并且能够通过cookie保会话
  • jmeter的每个线程都有自己的cookie存储区，所以，如果正在测试一个使用cookie来存储会话信息的网站，name每个jmeter线程都有自己的会话
  • 注意cookie不会在cookie管理器中 展示出来，但是可以通过查看结果树中看到他们
  • 可以手动天机一个cookie后，这个cookie将呗所有jmeter的线程贡献
  • 控制的cookie默认被忽略掉
  • 还需要注意的是cookie的名称必须是唯一的，如果一个cookie名称与已有cookie同名，他将被取代原有的cookie
  • 跨域的cookie不能被存储

http 信息头管理器：

  • http 信息头管理器是用来定制和管理http请求头信息的一个元件，可以在这里设置user-agent connection content-type accpect cookie localtion等信息
  • 作用：传递cookie、token或其他信息
    • 将所需的头信息以键值对的方式添加进去，能使你能够更真实的模拟该接口的访问，后边的http请求发送时这些请求头信息会随着我们的http请求一起发送到服务器

应用场景：

  • 传输cookie、token
  • 伪造请求头时使用

头部信息合并与覆盖原则

  • 头部管理器允许添加或覆盖http请求头，jmeter支持多个头部管理器
  • 不同作用域下，存在多个头部管理器，头部信息会合并
  • 若有重名的信息头名称，则优先取下级的信息头管理器
  • 同一个作用域下，不论添加多少个头部管理器，只会取第一个管理器的值，不合并
  • http请求下的信息头管理器的优先级高于线程组下的信息头管理器

常见的性能指标：

  • 性能测试过程中需要手机各种配置下的性能指标的数据
  • 主要需要监控的数据
    • 客户端数据
    • 服务器端数据
    • 数据库数据
    • 网络资源数据
  • 最后测试结果报告会记录压力大时一些关键数据的变化
    • 并发数、吞吐量、响应时间、系统资源、时间

性能指标：

  • 恒量测试结果是否符合预期要求的重要数据
  • 如果这些数据大于需求要求，就需要进行性能优化
  • 性能优化一般分为：
    • 业务指标
    • 系统资源指标，帮助分析系统性能瓶颈，为优化系统提供帮助

业务性能指标：

  • 响应时间（rt），服务器响应一次请求的花费的时间
  • 并发用户数，在某一时间点，服务器正在处理的请求数
  • 吞吐量/吞吐率/每秒事务数（TPS/RPS），系统每秒能处理的请求数/总时间
    • 测试执行总时间：最后一个样本结束时间-第一个样本开始时间
  • 错误率，指系统在负载情况下，失败交易的概率
    • 错误率（失败交易数/交易总数）*100%
    • 行业参考标准，不同系统对错误率的要求不同，一般不超过千分之六，即成功率不低于99.4%

常见的系统资源性能指标：

  • CPU占用率
  • 内存占用率
  • 硬盘占用率
  • 网络带宽占用率
  • 注意：一般不大于70~80%

响应时间：

  • 发送请求到收到最后的响应所有花费的时间
    • 在性能测试中，单个请求的响应时间并没有参考键值，通常考虑的是完成所有请求的平均响应时间及中卫数时间或大部分请求花费的时间（90%请求花费的时间）
    • 有时需要经常考虑的最大/最小响应时间，不包括渲染请求所花费的时间，同时也不包括处理客户端脚本所花费的时间
    • 响应时间=网络传输时间+应用服务器处理时间+数据服务器处理时间
    • 不同行业不同业务可接受的响应时间是不同的，一般情况
      • 互联网企业：500毫秒以下
      • 金融行业：1s以下，复杂业务3秒以下
      • 保险行业：3s以下
      • 制造业：5秒以下

用户数：

  • 注册用户数：数据库里的用户数
  • 在线用户数：在一定的时间范围内，最大的同时在线用户数量
    • 在线用户数=每秒请求数（TPS）+并发连接数+平均用户思考时间
  • 并发用户数：同时做操作的用户数
  • 最大并发用户数：
    • 最多允许多少个用户同时对系统进行访问并且响应时间不超过性能要求，强调同时性
    • 对一个系统来说，我们应该确保系统的最大并发用户数要大于系统需要承载的峰值负载
  • 平均并发用户数：
    • 平均并发数=平均每天访问用户数*一天内用户从登陆到退出的平均时间/一天内多长时间有用户使用系统
  • 并发用户数峰值：
    • 并发用户数峰值=平均并发用户数+3*根号下平均并发用户数

用户状态

  • 沉睡状态：在非工作时间不登录
  • 片刻状态 上升：在开始工作的时候，人们开始登陆系统，在线的数量不断增加
  • 稳定器：在线用户数保持稳定
  • 片刻状态 回落：工作时间结束，人们退出系统，在线人数减少的

预估并发用户峰值的步骤

  • 根据经验来估计稳定期的时间段
  • 故居在稳定期的登录用户数
  • 根据公式计算平均并发用户数
  • 运用公式计算高峰并发用户数
  • image.png

事务：

  • 就是用户某一步或几步操作的集合
    • 比如用户对某一个页面的一次请求，用户对某系统的一次登录，淘宝用户对商品额一次确认支付过程等
  • 作用：可以用于测试执行一组请求所花费的总时间，相当于用户进行一系列操作的测试，只有整个事务控制器定义的事务成功，才算成功

事务控制器：

  • 线程组—-添加—逻辑控制器—事务控制器

吞吐量：

  • 吞吐量是指一次性能测试过程中网络上传的数据的总和（服务器返回数据包大小 字节数）
  • 对于交互应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力

吞吐率（每秒事务数、TPS）

  • 每秒钟系统处理的数据量，他也可以指每秒钟系统能够处理事务或交易的请求数量
  • 他是衡量系统处理器能力的重要指标，一个项目达到几十个事务/秒
  • 吞吐率单位：
    • 从业务角度看，单位可以用：请求数/秒，页面数/秒，人数/天或处理业务数/小时等单位来衡量
    • 从网络角度看，单位可以用：字节/秒来衡量
  • 以不同方式表达的吞吐量可以说明不同层次的问题
    • 以字节数/秒方式可以表示要是受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈
    • 以请求数/秒的方式表示还需要是受应用服务器和应用代码的制约体现出的瓶颈

吞吐量和吞吐率计算

  • 当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系
    • 吞吐量/率=虚拟用户个数*每个虚拟用户发出的请求数/（最后一个脚本结束时间-第一个脚本开始时间）

每个虚拟用户发出的请求数

  • 每个虚拟用户发出的请求数=性能测试所用的时间/思考时间

估算预期TPS:

  • 如果当前没有用户数、请求数等数据提供参考，可以根据经验结合二八定律估算TPS

    1. 如果要完成日活30万笔交易的任务，如何设计预期TPS
    2. 二八定律：80% 的任务 在20%的时段完成
    3. （300000*80%）/（24*60*60*20%）=13.89笔交易/秒

    吞吐量要素：

  • 一个系统的吞吐量（承压能力）与请求对CPU的小号、外部接口、IO等紧密关联

  • 单个请求对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高

系统资源指标：

  • 也称为性能计算器
  • 是描述服务器或操作系统性能的一些数据指标，如使用内存数，进程时间
  • 在性能测试中发挥这监控和分析的作用，尤其是在分析系统可扩展性、进行性能瓶颈定位时有着非常关键的通

系统资源使用率：

  • 资源利用率：指系统各种资源的使用情况，CPU中央处理器、Mermory内存、DIsk磁盘等都是系统管理的资源
  • 一般主要关注CPU和内存，一般使用资源实际使用/总的资源可用量，行程资源利用率
  • 如果压力增大，会导致资源警长，引起性能瓶颈
    • CPU使用率一般不允许超过70%
    • 内存使用率一般不允许超过80%
    • windowsimage.png
    • linux：top

思考时间：

  • 从业务角度看，这个时间指用户进行操作时每个请求之间的时间间隔，而且在做性能测试时，为了模拟这样的时间间隔，引入思考时间的这个概念，用来更加真实的模拟用户的操作

聚合报告

  • 为测试中每个不同名称的请求创建一个表记录
  • 性能测试中，数据收集很重要，但是更重要的是快速抓住关键数据，读懂数据的含义，聚合报告就是用于测试数据统计与分析的力气
  • 对于每个请求，他统计了响应信息并提供请求技术，最小值、最大值、平均值、错误率、吞吐率和每秒千字节吞吐量image.png
  • Label取样器别名，如果勾选在标签汇总包含组名称？则会添加线程组的名称作为前缀

  • 样本 取样器运行的次数

  • 平均值：请求的平均响应时间
  • 中位数：50%用户的响应时间
  • 90%百分位：90%用户的响应时间
  • 95%百分位：95%用户的响应时间
  • 99%百分位：99%用户的响应时间
  • 最小值：请求的最小响应时间
  • 最大值：请求的最大响应时间
  • 异常%：事务错误率
  • 吞吐量：也就是TPS，默认情况下标识每秒完成的请求数，静思园工时请求数/总时间
  • 接受KB/SEC每秒从服务器端接收到的千字节数据量，即收到的千字节每秒的吞吐量测试
  • 发送KB/SEC每秒从客户端发送的请求的千字节数据量，即发送的千字节每秒的吞吐量测试

响应时间

  • 聚合报告中响应时间单位为毫秒，响应时间越小效果越好，标识接口响应快
  • 但实际工作中我们一般会关注90%百分位这个值，标识90%的响应时间小于特定好描述
  • 标识性能符合预期要求

吞吐量：

  • 是聚合报告中TPS，标识服务器分/秒处理请求数或任务数
  • 值越大越好，标识服务器处理能力强

错误率：

  • 聚合报告中是指错误率
  • 错误率=错误请求的数量/请求的总数
  • 错误率越低越好，为0标识没有异常请求
  • 对于一般项目来说错误率要在万分之一以下
  • 对于一般项目来说错误率要在万分之一以下

接受：

  • 从服务器接收返回数据所占用网络带宽
  • 这个值越小越好，越小占用宽带越小，间接标识服务器端返回数据较小
  • 一般内网环境，也就是前兆带宽，如果该值过大时，需要考虑优化

调优方案：

  • CPU核数，服务器节点数—-硬件调优
  • 该换具有高频CPU的服务器—-硬件调优
  • 调整业务逻辑效率——逻辑调优
  • 刘勇数据库索引、缓存等技术—-逻辑调优
  • 服务器容量、线程池大小、最大连接数、内存空间
  • 网络带宽、路由器效率等，对于数据密集性能服务而言，网络带宽很可能成为瓶颈

取样器：

  • 在线程组里必须添加取样器
    • HTTP请求
    • FTP请求
    • JDBC请求
    • JAVA请求
    • Junit请求
    • Beanshell取样器

HTTP请求

  • 协议
    • 向服务器发送HTTP请求协议，可以是HTTP或HTTPS，默认为HTTP
  • 服务器名称或IP
    • HTTP请求发送的目标服务器名称或IP
  • 端口号
    • 目标服务器的端口号，默认值为80
  • 方法
    • 发送HTTP请求的方法，可用方法包括GET、POST、HEAD、PUT、DELETE等
  • 路径
    • 目标URL路径（URL中去掉服务器地址、端口及参数后剩余部分）

  • 内容编码

    • 字符集编码方式，默认为IOS-8859-1编码
      1. 访问双创管理系统接口
      2. 接口地址：http：//39.104.25.201:8080/integration/manage
      3. 请求方法：get
      image.png
      监听器

  • 为了记录测试信息并且可以使用Jmeter提供的可视化界面查看测试结果

  • 查看结果树、汇总报告、聚合报告、图形结果、断言结果

运行调试脚本

  • 运行前首先保存脚本
  • 运行：绿色运行三级哦啊按钮、运行中点击启动、快捷使用ctrl+r

查看结果树

  • 查看请求结果

HTTP请求里的配置信息

  • 配置协议、服务器名称、Ip、端口号、路径、内容编码等
  • 应用场景：
    • 多条HTTP请求有相同的很多配置，可以考虑使用HTTP请求默认值来进行设置
    • 每次创建HTTP请求时就不用再传入必填项了
    • 如果前面设置了请求默认值，后面的HTTP请求里写了另一个配置信息，就会覆盖前面的默认值

HTTP请求的参数传入方式：

  • 路径方式

    1. 参数格式： ？key1=value1&key2=value2
    1. - 在get或put请求中发送的URL参数写在路径里
    2. - 在post请求中如果数据格式是默认格式也可以使用路径描述

  • 参数方式

    1. 参数格式   key1=value1&key2=value2
    1. - 在get或put请求中发送的url参数在第一个选项卡参数里点击下方添加，输入url里携带的参数名称和对应的值，我们可以将url中所有参数设置在本表中，表中每行为一个参数
    2. - 在post请求中如果数据格式是默认格式也可以使用
  • 消息体数据方式
    1. - post请求时携带的数据格式如果是json格式时，使用消息体数据来准备json格式数据
  • 文件上传方式
    1. - http模式上传文件配置
  • 注意：参数与消息体数据的方式两个不同同时使用，当一种方式下有数据就无法使用另一种，必须清空才能使用