性能测试-自学篇

1、性能测试概述

性能：效率

效率特性：

• 时间：指系统处理用户请求的响应时间
• 资源：指系统在运行过程中，系统资源的消耗情况
  • CPU、内存、磁盘IO

性能测试：使用自动化工具，模拟不同场景，对系统各项性能指标进行测试和评估的过程

性能测试测什么：

1、后台代码的性能

2、中间件、数据库、系统架构性能

3、服务器资源（CPU、内存、磁盘、网络）利用率

性能测试目的：

1、评估当前系统的能力

2、寻找性能瓶颈，优化性能

3、评估软件是否能够满足未来需要

性能测试与功能测试对比：

• 焦点不同
  • 功能测试：验证软件系统操作功能是否符合产品功能需求规格，主要焦点在功能（正向、逆向）
  • 性能测试：验证软件系统是否满足业务需求场景，主要焦点是业务场景是否满足（时间、资源）

2、性能测试策略

基准测试

负载测试

稳定性测试

其他：并发测试、压力测试、容量测试

2.1基准测试

狭义：也是单用户测试，测试环境确定以后，对业务模型中的重要业务做单独的测试，获取单用户运行时的各项性能指标（进行基础的数据采集）

广义：是一种测量和评估软件性能指标的活动，可以在某个时刻通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化后再进行一次基准测试以确定哪些变化对性能的影响

基准测试用途：

为用户后续测试提供参考依据

2.2负载测试

通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标下，系统所能够承受的最大负载量的测试

负载：指向服务器发送的请求数量，请求越多，负载越高

2.3稳定性测试

在服务器稳定运行（用户正常的业务负载下）的情况下进行长时间测试，并保证服务器能满足线上业务需求。时长一般为一天、一周等

2.4其他测试策略

并发测试：在极短的时间内，发送多个请求，来验证服务器对瞬时并发的处理能力

压力测试：在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效的发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试可分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试

容量测试：关注软件的极限压力下的各个极限参数值，如最大TPS、最大连接数、最大并发数、最多数据条数

3、性能测试指标

响应时间

并发数

吞吐量

点击数

错误率

资源利用率

3.1响应时间

响应时间 = 网络时间 + 应用程序处理时间（服务器+数据库）

3.2并发数

在同一时间内，向服务器发送请求的用户数量

• 系统用户数：系统注册的用户数
• 在线用户数：某段时间内，访问系统的用户数，这些用户并不一定同时向系统提交请求
• 并发用户数：某一时刻同时向系统提交的用户数

3.3吞吐量（率）

单位时间内处理客户端请求的数量，直接体现软件系统的性能承载能力

常用的参考值：TPS（每秒事务数）、QPS（每秒查询数）

3.4点击数

衡量web服务器处理数据的能力，不是点击的次数，而是当前页面包含的元素向web服务器发送的请求数量

3.5错误率

并发服务器请求中，失败的概率。项目中的错误率应该由产品给出特殊说明，如果没有，默认千分之五---0.5%

3.6资源利用率

系统运行过程中，各种资源的使用情况，项目中的资源利用率应该由产品给出特殊说明，如果没有，默认如下：

CPU <= 75~80%

内存 <= 80%

磁盘内存 <= 90%

网络 <= 80%

4、性能测试流程

需求分析->性能测试计划与方案->性能测试用例->搭建测试工具环境->测试脚本编写->执行测试脚本->性能测试监控->性能分析和调优->性能测试报告总结

4.1 需求分析

• 熟悉被测系统
  • 熟悉业务
  • 熟悉技术架构
• 明确测试内容
  • 业务角度
    • 按用户实际使用频率，使用频率较高的业务，需要展开性能测试
  • 技术角度
    • 逻辑复杂度较高的业务，需要展开性能测试               

• 明确测试策略
  • 基准测试
  • 负载测试
  • 稳定性测试
  • 并发测试......

• 明确测试指标
  • 无明确需求指标
    • 通过查找资料或和类似的系统做对比，以及对未来的预估，确定性能需求指标
  • 有明确需求指标
    • 预期结果与执行结果做对比，如果不满足，需要分析问题所在

4.2 性能测试计划与方案

• 测什么
• 由谁测
• 怎么测

4.3测试用例

4.4 搭建测试工具环境

在进行性能测试前，需要先完成性能测试的环境搭建工作，测试环境一般包括硬件环境、软件环境及网络环境，要求与正式上线的环境一模一样

4.5 测试脚本编写

不推荐使用脚本录制，推荐使用性能测试工具，自己编写脚本

4.6 执行测试脚本编写

先保证脚本调试通过之后，才能进入正式压测阶段。将工具生成的测试脚本，按预设指标设置，执行基准测试和压力测试

4.7 性能测试监控

性能监控就是监控服务器的各项性能指标，如CPU、内存、网络、磁盘IO

4.8 性能分析和调优

使用测试工具或命令，跟踪测试脚本的执行结果，对比预期结果和实际结果，找出性能瓶颈

分析顺序：

硬件问题

网络问题

应用服务器、数据库等配置问题

源代码、数据库脚本（SQL语句）问题

系统架构问题

4.9 性能测试报告总结

• 性能测试图表
• 性能测试需求覆盖情况，测试过程中出现的问题（如何去分析、调优、解决）
• 性能测试过程中遇到各类风险是如何控制的，目前是否存在其他风险

5、jmeter

5.1 元件、作用域和执行顺序

元件：功能相似的一系列组件集合

组件：一个个具体的业务功能

执行顺序

相同的元件，按照书写顺序执行；不同元件按如下顺序：

1.配置原件

2.前置处理程序

3.定时器

4.取样器

5.后置处理程序

6.断言

7.监听器

ex:

1.新建线程组

2.新建HTTP请求

注：发送json格式的数据还需设置Content-Type=application/json

3.新建结果树

5.2 jmeter参数化

5.2.1 用户定义的变量

使用场景：多个请求，使用相同的公共数据时，适用 用户定义的变量

ex:使用用户定义的变量，实现访问百度首页

5.2.2 用户参数

使用场景：并发访问，每个请求要求不同的参数

ex: 访问百度首页，3个用户访问，每个用户携带不同的姓名和年龄

5.2.3 CSV Data Set Config

使用场景：单用户测试，使用大量不同数据发送请求

CSV文件

name,age

user01,18

user02,19

user03,20

jmeter为了方便，可以使用.csv或.txt文件组织数据

ex: 访问百度首页，1个用户循环访问3次，每次携带不同的name和age

注：当不知道.csv文件里有多少行数据需要读取时，设置线程永久循环，且CSV数据文件设置也需要修改

5.2.4 计数函数

场景：在发送请求时，需要提供唯一数据作为请求

ex1: 给京东发送50次请求，每个请求自带序列号，自己是第几次请求

ex2: 给京东发送50次请求，每个请求携带序号不同的用户名

5.3 jmeter断言

5.3.1 响应断言

发送请求，能够获取到响应结果

ex: 发送百度请求，让程序检查响应数据中是否包含“百度一下，你就知道”

如果要判断响应体是否包含字符串，要新建断言，选择测试字段为响应文本（一个响应文本可以包含多个判断字符串）

如果要判断响应状态码，要新建断言，选择测试字段为响应代码

5.3.2 json断言

5.4 jmeter关联

用来解决 请求与请求之间有依赖关系的技术

5.4.1 正则表达式提取器

ex: 将www.itcast.cn网页的<title>内容提取出来，作为www.baidu.com的请求参数使用

先创建itcast请求，再创建baidu请求，在itcast请求下添加正则表达式提取器

为了方便查看正则表达式匹配结果，在线程组添加“调试取样器”

5.4.2 XPath 提取器

X代表xml或xhtml(html可以转为xhtml)

ex:将www.itcast.cn网页中<title>内容提取出来，作为www.baidu.com的请求参数使用

在itcast请求添加XPath提取器

补充：

为了方便查看XPath匹配结果，在线程组添加“调试取样器”

5.4.3 json提取器

当http请求发送，返回的响应为json数据时

ex: 请求获取天气的接口，获取城市名，作为百度搜索接口

在城市请求添加json提取器

为了方便查看json匹配结果，在线程组添加“调试取样器”

5.5 跨线程组

5.5.1 跨线程组使用变量

说明：

• 在jmeter中，线程组内定义的变量，默认不能跨线程组使用
• 在jmeter中，没有所谓的全局变量、环境变量

实现原理：

• 将A线程组内的变量，当成属性设置到 jmeter的配置文件中（jmeter.properties=>使用_setProperty)
• B线程组，从jmeter配置文件中（jmeter.properties=>使用_Property)中读取属性使用

5.6 jmeter数据库

使用数据库的目的：

校验 测试数据：

• 响应数据中，没有包含数据库中变化的数据，比如执行删除操作，数据库中有一个字段为is_deleted，如果执行了删除操作，无法看到该字段值是否发生变化，此时可以操作数据库来观察
• 断言使用中的预期结果可以从数据库中获取

构造 测试数据：

• 发送请求时，使用的数据，可以添加到数据库中。如 ：添加员工使用的手机号、id

5.6.1 连接数据库的步骤

1.添加数据库驱动（jar包）

临时设置（只在当前测试生效）：

永久生效（在所有测试生效）：需要重启jmeter

2.配置数据库连接池属性（IP、port、用户名、密码、数据库名）

3.发送jdbc请求（执行SQL语句）

5.7 逻辑控制器

所有的控制器都是请求的父级

5.7.1 if控制器

ex: 使用“用户定义的变量”定义name变量，值可以是“baidu"或”itcast"，用变量值，控制是否访问对应网站

每一次的HTTP请求都需要一个IF控制器

itcast同理

5.7.2 循环控制器

仅一次循环控制器

此时设置线程组循环2次

结果聚合报告中，

5.7.3 事务控制器

事务对应一个系统中的业务，一个业务可以包含一个请求或多个请求

当需要将多个请求当作一个业务看待，此时需要事务控制器。如下单：登录、搜索、加入购物车、支付

5.7.4 ForEach控制器

ex1:一组关键字【mysql,python,java】，使用用户定义的变量存储它们，依次取出，交给百度搜索

ex2:访问itcast首页，获取黑马各校区名，依次取出交给百度做关键字搜索

5.8 定时器

所有的定时器都是请求的子级

5.8.1 同步定时器

场景：秒杀、微信抢红包、抢购【服务器瞬时访问量暴增】

ex:模拟一个时间点上，100个用户瞬时并发访问百度首页

当同步定时器的用户组为120，线程组线程数为100时

设置超时时间5秒，5秒过后发送了100个线程

设置同步定时器用户组为80，超时时间为5秒，5秒前先发送80个线程，五秒后发送剩余20个线程

5.8.2 常数吞吐量定时器

作用：控制每秒向服务器发送请求的数量，测试当前服务器是否能达到指定的QPS

ex:一个用户以20QPS（20次/s)的频率访问百度首页，持续运行一段时间，统计运行情况

默认QPS=TPS

ex:百度服务器是否能达到80QPS

未设置吞吐量默认情况下TPS为25左右

设置TPS为4800次/min

TPS为30左右

结论：无法达到80QPS

5.8.3 固定定时器

场景：登陆三次错误，延迟登录

5.9 分布式

为什么使用分布式？

• 当前计算机的硬件配置会在性能测试过程中，成为制约数据的重要瓶颈

什么是分布式?

• 将一个测试目标，分布在多个主机上，分开部署执行

分布式原理？

5.9.1 分布式配置

当下一个jmeter最多能发送1000~2000个线程，发送不了3000个

1. 执行机（代理机）配置

（1）配置当前代理机的port

• 修改 分布式测试\执行机\执行机A（和B）\apache-jmeter-5.6.3\bin\jmeter.properties下的server_port

执行机A

执行机B

（2）禁用SSL

• 修改 分布式测试\执行机\执行机A（和B）\apache-jmeter-5.6.3\bin\jmeter.properties下的server.rmi.ssl.disable=true

执行机A

执行机B

（3）启动执行机

执行机A

执行机B

如果启动报错，修改jmeter-server文件，RMI_HOST_DEF=-Djava.rmi.server.hostname=127.0.0.1

2.控制机配置

（1）配置控制机管理的代理机的IP和port

• 修改 分布式测试\执行机\控制机\apache-jmeter-5.6.3\bin\jmeter.properties下的remote_hosts的值。设置代理机的IP和端口，如果有多个用","英文隔开

（2）禁用SSL

• 修改 分布式测试\执行机\控制机\apache-jmeter-5.6.3\bin\jmeter.properties下的server.rmi.ssl.disable=true

(3)启动控制机

上图为执行机终端产生的信息

5.10 性能测试报告

5.10.1  聚合报告

5.10.2 html报告

jmeter下生成测试报告，借助命令实现

• 注意：report目录可以在生成报告时自动创建，但是必须保证report目录为空或者不存在
  •     必须保证生成报告的位置下，没有result.jtl或result.txt

5.11 TPS计算方法

pv:page view,统计用户访问页面的频率，点击或刷新页面pv数增加

uv:user view，统计用户活跃数，点击或刷新页面uv数不增加

二八原则：80%的请求在20%的时间内完成 ------->TPS = 总请求数80% / 总时间20%

同步并发数：TPS = （总体请求数 * 0.8 / 有效时长 * 0.2）* 3（系数）

ex: OA系统，有20万人使用，平均每天使用8小时，进行性能测试，并发数是多少？

TPS= （200000 * 0.8）/（8 * 3600s * 0.2）* 3

5.12 插件

5.12.1 插件管理器的添加

5.12.2 安装插件

安装成功