jmeter,性能测试,Locust

一。性能测试的概念

1.性能：就是软件质量属性中的 “ 效率 ” 特性

2.效率特性：

时间特性：指系统处理用户请求的响应时间

资源特性：指系统在运行过程中，系统资源的消耗情况

CPU

内存

磁盘IO（磁盘的写入Input和读取 Output ，简称 IO ）

3.什么是性能测试？

性能测试概念：使用自动化工具，模拟不同的场景，对软件各项性能指标进行测试和评估的过程就是性能测试。

1. 后台处理程序的性能（代码性能）

2. 中间件、数据库、架构设计等是否存在瓶颈

3. 服务器资源消耗（ CPU 、内存、磁盘、网络）

中间件：是提供系统软件和应用软件之间连接的软件。如：Tomcat 、 Apache...

4.性能测试目的

1. 评估当前系统能力

- 例如：验收第三方提供的软件

- 例如：获取关键的性能指标，与其他类似产品进行比较

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

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

5.性能测试与功能测试

区别：

功能测试：验证软件系统操作功能是否符合产品功能需求规格，主要焦点在功能（正向、逆向）；

性能测试：验证软件系统是否满足业务需求场景，主要焦点是业务场景的满足(时间、资源 ) ；

关系：

功能测试和性能测试是相辅相成的，对于一款优秀的软件产品来讲，它们是不可减少的2个重要测试环节；

注意：一般新项目中，先功能测试通过后，再进行性能测试。

二。性能测试的策略

性能测试的种类：

1.基准测试

2.负载测试

3.稳定性测试

4.其他：并发测试，压力测试，容量测试

1.基准测试：

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

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

基准测试数据的用途：

1. 为多用户并发测试和综合场景测试等性能分析提供参考依据

2. 识别系统或环境的配置变更对性能响应带来的影响

3. 为系统优化前后的性能提升/下降提供参考指标

2.负载测试

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

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

注意：负载测试关注的重点是逐步增加压力

3.稳定性测试

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

4.其他测试策略

性能测试中，测试策略其实有很多种，但是掌握基础的用法后，其他不同名称的测试策略只是基础用法的一个变形用法。

a.并发测试：并发测试是指在极短的时间内，发送多个请求，来验证服务器对并发的处理能力。如：抢红包、抢购、秒杀活动等。

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

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

三。性能测试指标

指标：一些经过运算得出的结果，来衡量某种操作性能统称；比如：错误率 0.5%

性能指标

1. 响应时间

2. 并发数

3. 吞吐量

4. 点击数

5. 错误率

6. 资源利用率

7. PV和 UV

1.响应时间：

说明：响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的结果，整个过程所耗费的时间。

组成：响应时间 = 网络时间 + 应用程序处理时间

2.并发数：

说明：并发测试的用户数

扩展：

系统用户数：系统注册的总用户数据

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

并发用户数：某一物理时刻同时向系统提交请求的用户数

3.吞吐量

说明：吞吐量（Throughput ）指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力

注意：

1. 从业务角度来看，吞吐量也可以用 “ 业务数 / 小时 ” 、 “ 业务数 / 天 ” 、 “ 访问人数 / 天 ” 、 “ 页面访问量 / 天 ” 来衡量

2. 从网络角度来看，还可以用 “ 字节数 / 小时 ” 、 “ 字节数 / 天 ” 等来衡量网络的流量

3. 从技术指标来看，可以用每秒事务数（ TPS ）和每秒查询数（ QPS ）来衡量服务器具体性能处理能力

4.TPS

说明：Transactions Per Second ，每秒事务数 ( 单位时间内系统处理的客户端请求的事务次数 )

计算：TPS = 并发数 / 平均响应时间

事务：就是业务请求，对应一个或者多个操作。如支付请求，包括服务器查询用户余额，支付安全校验等多个操作。一个业务请求发送给服务器后，最终会定位到服务器对应的业务请求的代码，既有可能是一段代码也有可能是多段代码。

TPS归属吞吐量

QPS

说明： QPS(Query Per Second) 每秒查询数

应用：控制服务器每秒处理指定请求数（如：控制服务器达到每秒 60QPS ，服务器的性能各项性能指标是否正常）。（衡量 web

服务器处理能力一个重要指标）

2.4 点击数

说明：点击数是衡量 Web 服务器处理能力的一个重要指标。

提示：

1. 点击数不是通常一般人认为的访问一个页面就是１次点击数，点击数是该页面包含的元素（图片、链接、框架等）向 Web 服

务器发出的请求数量。

2. 通常我们也用每秒点击次数（ Hits per Second ）指标来衡量 Web 服务器的处理能力。

注意：只有 web 项目才有此指标。

2.5 错误率

说明：错误率指系统在负载情况下，失败业务的概率。错误率＝ ( 失败业务数 / 业务总数 )*100% 。

提示：

1. 不同系统对错误率要求不同，但一般不超过千分之五；

2. 稳定性较好的系统，其错误率应该由超时引起，即为超时率。

2.6 资源利用率

说明：是指系统各种资源的使用情况，一般用 “ 资源的使用量 / 总的资源可用量 ×100%” 形成资源利用率的数据。

提示：通常，没有特殊需求的话

1). 建议 CPU 不高于 80%(±5)

2). 内存不高于 80%

3). 磁盘不高于 90%

4). 网络不高于 80%

四。性能测试流程

1. 性能测试需求分析

2. 性能测试计划及方案

3. 性能测试用例

4. 测试脚本编写 / 录制

5. 建立测试环境

6. 执行测试脚本

7. 性能测试监控

8. 性能分析和调优

9. 性能测试报告总结

提示：使用不同的性能测试工具时，主要流程是不变的

1.性能需求分析

说明：性能需求分析是整个性能测试工作开展的基础，性能需求分析做的好不好直接影响到性能测试的结果。

性能需求分析的目标：明确被测系统，测试内容，测试策略，测试指标

1. 熟悉被测系统

熟悉被测系统的业务功能

熟悉被测系统的技术架构

2. 明确性能测试内容

a.从业务角度明确测试内容

确定关键业务。即：用户使用频率较高的业务功能

b.从技术角度明确测试内容

如：通常逻辑复杂度较高的业务也是CPU密集运算较大的地方，考量服务器CPU 在预定性能指标下是否达标

如：通常数据量较大的业务很占用系统内存，考量服务器内存在预定性能指标下是否达标

3. 明确性能测试策略

负载测试

稳定性测试

并发测试

4. 明确性能测试的指标

a.无明确需求指标

通过查找相关资料，和类似的系统对比，以及对未来流量的预估，确定性能测试需求的指标

b.有明确需求指标

例如，类似如下指标

下订单业务并发20个用户

平均响应时间要小于等于3s

事务成功率为100%

CPU使用率小于等于85%

只需要根据执行分析结果与预期指标做对比，如果有不满足的，就需要分析问题所在

2.性能测试计划及方案

说明：性能测试实施第一份文档，也是最重要的一份文档。

主要内容：

1. 项目背景

2. 测试目的

3. 测试范围

4. 测试策略

5. 风险控制

6. 交付清单

7. 进度与分工

3.性能测试用例

4.测试脚本编写和录制

说明：性能测试用例编写完成以后，接下来就需要结合用例的需要，进行测试脚本的编写工作。

提示：录制或编写，根据不同的工具要注意代码冗余。

5 建立测试环境

说明：在进行性能则试之前，需要先完成性能测试环境的搭建工作，测试环境一般包括硬件环境、软件环境及网络环境

提示：一般情况下可以要求运维和开发工程师协助完成

6.执行测试脚本

说明：先保证脚本调试通过之后，才能进入正式压测阶段

执行测试脚本时，要先进行性能运行场景的设置，再运行脚本

7.性能测试监控

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

8.性能分析和调优

说明：性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈。

提示：

1. 调优人员 ( 开发人员、数据库管理员、系统管理员、网络管理员、性能测试分析人员 ) 相关人员对系统进行调整 ;

2. 验证 - 性能测试人员继续进行第二轮、第三轮 …… 的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升。

注意 :

系统调优由易到难的先后顺序如下：

1. 硬件问题

2. 网络问题

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

4. 源代码、数据库脚本问题

5. 系统构架问题

9 .性能测试报告总结

性能测试总结要包含以下内容：

1. 性能测试需求覆盖情况，测试过程回顾，及测试中出现的问题（如何去分析、调优、解决的） --- 基本要求

2. 性能测试过程中遇到各类风险是如何控制的 ; 目前是否还有其他的性能风险存在

3. 经过该项目性能测试后，有那些经验和教训等内容

五。性能测试工具

1. 主流性能测试工具

LoadRunner

JMeter

1.1 LoadRunner

HP LoadRunner是一种工业级标准性能测试负载工具，可以模拟上万用户实施测试，并在测试时可实时检测应用服务器及服务器硬件各种数据，来确认和查找存在的瓶颈

支持多协议：Web(HTTP/HTML) 、 Windows Sockets 、 FTP 、 ODBC 、 MS SQL Server 等协议

最初是 Mercury 公司采用 C 语言编写 , 现被 HP 公司收购

优点：

1. 多用户（支持数量单位万）

2. 详细分析报表

3. 支持 ip 欺骗

缺点：

1. 收费

2. 体积庞大（单位 GB ）

3. 无法定制功能

1.2 JMeter

JMeter是 Apache 组织开发的基于 Java 的开源软件，用于对系统做功能测试和性能测试。

它最初被设计用于 Web 应用测试，但后来扩展到其他测试领域，例如静态文件、 Java 程序、 shell 脚本、数据库、 FTP 、 Mail等。

优点：

1. 免费

2. 开源

3. 小巧（最新版 -50MB 左右）

4. 丰富学习资料及扩展组件

5. 应用广泛

6. 易上手

缺点：

1. 不支持 ip 欺骗

2. 分析和报表能力相对于 lr 欠缺精度

六。Jmeter

1. JMeter文件目录介绍

1.1 bin 目录

存放可执行文件和配置文件

jmeter.bat ： windows 的启动文件

jmeter.log ：日志文件

jmeter.sh ： linux 的启动文件

jmeter.properties ：系统配置文件

jmeter-server.bat ： windows 分布式测试要用到的服务器配置

jmeter-serve ： linux 分布式测试要用到的服务器配置

1.2 docs 目录

docs ：是 JMeter 的 api 文档，可打开 api/index.html 页面来查看

1.3 printable_docs 目录

printable_docs 的 usermanual 子目录下的内容是 JMeter 的用户手册文档

usermanual 下 component_reference.html 是最常用到的核心元件帮助文档。

提示： printable_docs 的 demos 子目录下有一些常用的 JMeter 脚本案例，可以作为参考

1.4 lib 目录

该目录用来存放 JMeter 依赖的 jar 包和用户扩展所依赖的 jar 包

2. 修改默认配置

2.1 汉化配置

实现 JMeter 界面的汉化包含两种方式：

1. 临时性

2. 永久性

临时性：启动 JMeter-> 选择菜单 ‘Options’->Choose Language->Chinese (Simplified)

永久性：

找到 jmeter 安装目录下的 bin 目录，

打开 jmeter.properties 文件，把第 37 行修改为 “language=zh_CN” ，

重启 JMeter 即可

19 2.2 修改主题

JMeter 默认主题是黑色的，可以通过以下步骤修改：

启动 JMeter -> 选择菜单 ‘ 选项 ’ -> 外观 -> Windows( 选择自己喜欢的主题即可 )

2.JMeter元件作用域和执行顺序

2.1元件的基本介绍

元件：多个类似功能组件的容器（类似于类）。

常见的元件类型有：

1. 取样器

2. 逻辑控制器

3. 前置处理器

4. 后置处理器

5. 断言

6. 定时器

7. 测试片段

8. 配置元件

9. 监听器

组件：实现独立的某个功能（类似于方法）

2.2元件作用域

在 JMeter 中，元件的作用域是靠测试计划的树形结构中元件的父子关系来确定的。

提示 : 核心是取样器，其他组件都是以取样器为核心运行的，组件添加的位置不同，生效的取样器也不同。

作用域的原则

1. 取样器：元件不和其他元件相互作用，因此不存在作用域的问题 ;

2. 逻辑控制器：元件只对其子节点中的取样器和逻辑控制器作用 ;

3. 其他六大元件：除取样器和逻辑控制器元件外，如果是某个取样器的子节点，则该元件对其父子节点起作用；

4. 如果其父节点不是取样器，则其作用域是该元件父节点下的其他所有后代节点（包括子节点，子节点的子节点等）;

2.3. 元件执行顺序

1. 配置元件 (config elements)

2. 前置处理程序 (Per-processors)

3. 定时器 (timers)

4. 取样器 (Sampler)

5. 后置处理程序 (Post-processors)

6. 断言 (Assertions)

7. 监听器 (Listeners)

提示 :

1. 前置处理器、后置处理器、断言等元件功能对取样器起作用（如果在它们的作用域内没有任何取样器，则不会被执行）

2. 如果在同一作用域范围内有多个同一类型的元件，则这些元件按照它们在测试计划中的上下顺序依次执行