当前位置：首页 > news >正文

测试 - 4 （ 9000 字详解）

news 来源：原创 2025/5/15 15:17:27

一：性能测试

1.1 什么是性能测试

性能测试和功能测试虽然都在系统测试阶段进行，但两者有本质区别。功能测试主要关注系统“能否完成特定功能”，例如一辆车是否具备四个轮子、方向盘、挡风玻璃，以及是否能够正常行驶。而性能测试则关注系统“完成功能的质量和效率”，例如五菱与法拉利在座椅材质、加速时间等方面的差异。简单来说，功能测试回答的是“能不能用”，而性能测试回答的是“用得好不好”。

性能测试是为了发现系统性能问题或获取相关指标而进行的测试。通常在真实环境和特定负载条件下，通过工具模拟软件系统的运行和操作，同时监控性能指标（如响应时间、吞吐量、资源利用率等）。最终，通过分析测试结果，评估系统在性能方面的表现和优化空间。

1.2 常见的性能指标

1.2.1 并发数

并发用户数是衡量系统同时服务用户能力的重要指标。从业务层面来看，并发用户数指的是同时实际使用系统的用户总数。例如，一个已投运的 web 系统中，有 5000 名员工使用，但最多同时有 2500 人使用，那么业务并发用户数为 2500。

从后端服务器层面来看，并发用户数指的是在特定时间段内，Web 服务器处理浏览器请求所建立的 HTTP 连接数或生成的处理线程数。例如，在上述系统中，用户可能在同时进行浏览页面、填写订单、提交订单、查询订单等操作，而后端服务器实际的并发用户数是提交订单和查询订单这类实际操作的用户数。

1.2.2 吞吐量

单位时间内处理的并发数直接反映了软件系统的负载承受能力。吞吐量越高，系统能够处理的并发请求越多，性能表现也越好。假设有两种测试场景：

A场景：100 个并发用户，每个用户每秒发送 1 个请求。
B场景：1000 个并发用户，每个用户每 10 秒发送 1 个请求。

这两种场景的吞吐量相同，都是每秒 100 个请求。然而，由于 A 场景用户的思考时间短，系统需要更频繁地响应请求，因此 A 场景占用的系统资源比 B 场景更多，对系统的压力也更大。

1.2.3 响应时间

应用系统的响应时间是指从请求发出开始，到客户端接收到最后一个字节数据所消耗的总时间。对于 Web 系统来说，响应时间由两部分组成：前端展现时间和系统响应时间。前端展现时间是指页面的渲染时间，而系统响应时间则包括服务器处理、数据库操作以及通讯网络等环节的耗时。

在这里插入图片描述

并发用户、系统吞吐量、系统响应时间之间的关系如图所示：

在这里插入图片描述
当系统并发用户较少时，系统吞吐量低且响应时间较短，此时系统处于空闲区间。随着并发用户的增加，系统吞吐量开始呈线性增长，性能进入线性增长区间。

当吞吐量达到某个最大值时，系统性能达到饱和点（也称为拐点）。在拐点之后，用户请求无法被立即处理，响应时间逐渐延长，吞吐量逐步下降，系统性能进入过饱和区间。性能测试的主要目标之一就是确定系统性能的拐点，以评估系统的最大负载能力。

1.2.4 TPS 和 QPS

项目	描述	计算公式	示例
TPS	每秒处理事务数，表示系统在单位时间内能够处理的事务数量，用于衡量系统的整体处理能力。	TPS = 总事务数 / 总运行时间	在 1 分钟内处理了 1000 个事务，TPS = 16.7
QPS	每秒查询率，表示系统在单位时间内能够处理的查询请求数量。	若事务中只有一个查询接口，则 TPS = QPS	如果某场景只有查询接口，每秒 50 个查询请求，则 QPS = 50。

一个接口可以被视为一个事务，多个接口也可以组成一个事务，一个完整的业务流程也可以被定义为一个事务。事务通常代表系统中一个完整的功能操作。

1.2.5 资源利用率

资源利用率是通过监测系统资源的占用情况来分析可能存在的资源瓶颈。常见的监测对象包括服务器的 CPU、内存、磁盘和网络等关键资源。

1.3 性能测试的关注点

不同角色对性能测试的关注点各有侧重。从客户端发起请求到客户端接收响应的整个过程中，各阶段都可能出现性能问题，但开发人员和测试人员通常无需关注全流程的性能问题。通过明确不同角色的侧重点，可以更高效地开展性能测试。与软件系统性能相关的角色主要包括四类。

角色	关注点	示例
终端用户	关注用户进行业务操作时的主观响应时间，重点是从提交请求到收到响应的时间，包括系统响应时间和前端展现时间。	用户在提交登录请求后，关心页面多快能完成加载并显示结果。
系统运维人员	重点关注大量用户并发访问时对系统的影响以及在高负载下的系统健康状态，包括系统的最大并发用户数、响应时间的权衡取舍、系统容量、数据库调优、长期稳定性和可扩展性。	在两种方案中： A方案：100万并发用户，登录响应时间3秒 B方案：500万并发用户，登录响应时间8秒运维人员更倾向于选择B方案。
软件设计开发人员	专注于算法设计、架构设计、性能最佳实践、数据库相关优化以及软件性能的可测试性，确保系统性能高效、稳定且具备扩展能力。	在算法设计中，需保证高效且无内存泄漏；在架构设计中，确保系统容量和性能具备扩展能力。
性能测试人员	负责设计性能测试场景、开发和执行测试脚本、排查和定位性能缺陷，同时需要广泛的知识积累，如系统架构、存储架构、网络架构以及数据库调优、多线程问题等。	对数据库SQL语句执行计划进行调优，分析JVM垃圾回收问题，解决多线程常见性能问题。

1.4 性能测试分类

1.4.1 基准测试

基准测试又称单用户测试，主要用于监测系统在低压力下的运行状况并记录相关性能数据。在确定性能测试环境后，通常会选取业务模型中的关键业务进行基准测试，通过施加一定压力，获取系统在单用户运行情况下的性能指标。这些数据为后续的多用户并发测试和混合场景测试等提供了重要的参考依据。

在这里插入图片描述

1.4.2 并发测试

并发测试用于评估系统在特定操作同时发生时的性能表现。比如测试系统在多个用户同时登录时的响应能力，或某一功能被多个用户同时操作时的性能表现。通过并发测试，可以获得系统在多用户并发操作下的性能指标，并发现潜在问题，如内存泄漏、线程锁、资源争用等问题。

例如模拟多个用户同时访问某一条件数据或同时更新数据，可能会发现系统出现数据库访问错误或写入错误等问题。并发测试是性能测试的一个重要组成部分，但其对并发时间的精确性要求较高。通常需要借助专门的性能测试工具，通过多线程或多进程的方式来模拟多个虚拟用户的并发操作，从而全面评估系统在并发场景下的稳定性和性能表现。

1.4.3 负载测试

负载测试的重点在于测量系统处理不同负载的能力，这些负载通常通过增加并发用户或进程数量来模拟。在测试过程中，通过逐步增加并发访问负载，监测系统性能的变化，直到某项或多项性能指标接近或达到安全临界值，从而确定系统在满足该临界值条件下所能承受的最大负载。

简单来说，负载测试是通过逐步加压的方式确定系统的处理能力，类似于举重运动，通过不断增加重量来评估运动员在身体状态正常的情况下能够举起的最大重量。负载测试的结果能够帮助系统明确其峰值性能指标，为进一步优化和扩展提供数据支持。

在这里插入图片描述

1.4.4 压力测试

压力测试用于评估系统在高于预期负载、超过指定容量需求，或在资源不足的情况下的性能表现。它关注系统在超出预期负载或峰值负载时的处理能力，同时也评估系统在资源匮乏（如计算能力、带宽、内存等不足）情况下的稳定性和处理能力。

在压力测试中，通常通过逐步增加负载，直到系统某些资源达到饱和甚至失效，从而发现仅在高负载条件下才会暴露的缺陷，例如同步问题、内存泄漏等。同时，压力测试可以帮助识别系统的性能拐点，确定系统所能承受的最大压力，以及系统在峰值或超负载情况下的运行能力。压力测试主要应用于性能诊断、性能调优以及容量规划等场景，为系统优化提供重要依据。

1.4.5 压力测试和负载测试的区别

压力测试与负载测试有本质区别。负载测试是在满足性能指标要求的前提下，测试系统能够承受的最大负载；而压力测试则是评估系统在达到或超过性能极限时的表现。

例如，某软件系统要求响应时间不超过2秒。在负载测试中发现，当访问量达到1万时，系统的响应时间依然维持在2秒以内；但当访问量超过1万时，响应时间开始超出2秒。因此，系统在满足响应时间要求的情况下，最大可承受的访问量为1万。

而在压力测试中会继续增加系统的访问量，以观察系统在极限条件下的性能变化。例如，当访问量增加到2万时，系统的响应时间延长至5秒；当访问量增加到3万时，系统崩溃且无法响应。由此可以确定，系统的极限访问量为3万。压力测试通过分析这些极限数据，帮助识别系统的瓶颈和改进方向。

1.4.6 稳定性测试

稳定性测试是在负载测试的基础上，进行长时间的持续运行测试，以评估系统在高负载或特定条件下的稳定性。通常，长时间测试的周期为 3*24 小时或更长时间。稳定性测试的目的是验证系统能否在长期运行中保持性能稳定、无崩溃或异常情况。

二： JMeter

Apache JMeter 是由 Apache 组织基于 Java 开发的一款开源压力测试工具，主要用于对软件进行性能测试、负载测试和压力测试。其工作原理如下：

步骤	描述
配置测试计划	用户创建测试计划，包括线程组、取样器、监听器等组件，用于模拟用户的操作和请求。
模拟用户请求	通过线程组模拟并发用户行为，向目标系统发送请求，支持 HTTP、TCP 等多种协议。
监控和记录性能数据	实时收集系统的性能指标（如响应时间、吞吐量、错误率等），并记录测试过程中产生的数据。
分析测试结果	生成详细的测试报告，帮助分析系统的性能瓶颈、稳定性和负载能力，为系统优化提供数据支持。

在这里插入图片描述

2.1 使用 JMeter

使用 JMeter 之前先需要先安装 JMeter，接着点击 bin 目录下的 jmeter.bat 运行即可
在这里插入图片描述

除了能通过 jmeter.bat 启动，还能通过命令行方式进行启动：

添加 JMeter 系统环境变量

在这里插入图片描述

保存后打开命令行工具

在这里插入图片描述

2.2 JMeter 基础配置

在这里插入图片描述

2.3 JMeter 基本使用

启动 JMeter
在“Test Plan” 下添加 “线程组”

在这里插入图片描述

在 “线程组” 下添加 “HTTP” 取样器

在这里插入图片描述

填写 “HTTP请求” 的相关请求数据

在这里插入图片描述

在 “线程组” 下添加 “查看结果树” 监听器

在这里插入图片描述

点击 “启动” 按钮运行，查看接口测试结果

在这里插入图片描述

2.4 JMeter 元件作用域和执行顺序

在 JMeter 中，元件作用域和执行顺序是非常重要的概念。

项目	描述
作用域	JMeter 元件的作用域由测试计划树形结构中的元件父子关系确定，元件的作用域仅对其子节点生效。
执行顺序	取样器元件内的组件可以独立执行，不依赖其他元件，因此取样器不存在作用域问题。
默认规则	其他元件的作用域默认根据测试计划中的树形结构来决定，遵循父子关系的作用域原则。

2.5 重点组件

2.5.1 线程组

线程组是 JMeter 中用于控制测试执行线程数的组件，可以将每个线程理解为一个模拟的测试用户。线程组定义了测试中用户的数量及其行为，从而模拟真实场景下的并发访问。

在这里插入图片描述

配置项	描述
线程数	每个线程代表一个测试用户，用于设置发送的请求数量。
Ramp-up时间（秒）	设置线程启动的时间间隔，单位为秒，用于控制性能测试运行的时间节奏。
循环次数	配置指定次数：控制脚本循环执行的次数。配置循环永远：需要配合调度器使用，脚本会持续运行，直至达到指定的运行时间。
调度器配置	运行时间：设置脚本的总执行时间。延迟启动时间：设置脚本在启动前需要等待的时间。

2.5.2 HTTP 取样器

在这里插入图片描述

配置项	描述
协议	设置使用的协议类型，例如 HTTP 或 HTTPS。
主机名/IP	设置目标服务器的主机名或 IP 地址，用于发送请求。
端口	设置目标服务器的端口号：HTTP 协议默认端口号为 80，HTTPS 协议默认端口号为 443。
请求方法	设置 HTTP 请求的方式，例如 GET、POST 等。
路径（目录+参数）	设置目标资源的路径，可以包含目录结构和 URL 参数。
内容编码	设置请求内容的编码方式，默认使用 ISO 国际标准，但对中文支持不佳，推荐使用 UTF-8。
参数	参数可以直接拼接在路径中， POST 方法的参数需要放在消息体数据中，例如：{wd:test}。

2.5.3 查看结果树

在这里插入图片描述

取样器结果：统计请求相关的信息

Thread Name：线程组名称
Sample time:发送请求时间
load time：响应时间
Response code ：接⼝响应状态码

2.5.4 HTTP Cookie 管理器

在这里插入图片描述

HTTP Cookie 管理器的作用类似于 Web 浏览器，用于存储和发送 Cookie。当 HTTP 请求和响应中包含 Cookie 时，Cookie 管理器会自动存储这些 Cookie，并在后续对该特定网站的所有请求中使用它们。每个 JMeter 线程都有独立的 Cookie 存储区，因此在测试使用 Cookie 存储会话信息的网站时，每个 JMeter 线程都会维护自己的会话。这些 Cookie 不会显示在 Cookie 管理器的界面中，但可以通过“查看结果树监听器”查看。同时，缓存配置可以选择 standard（标准）或 compatibility（兼容）模式，也可以手动添加一些 Cookie。添加 HTTP Cookie 管理器后，Cookie 的存储和发送将自动完成。

在这里插入图片描述

2.5.5 HTTP 请求默认值

当接口的协议、IP 和端口号一致时，可以将这些公共配置抽取出来，存放在默认值中。这样其他接口就无需重复书写协议、IP 和端口号，简化配置，提高维护效率。

在这里插入图片描述

2.5.6 用户定义的变量

用户定义的变量可以通过线程组中的配置元件添加。这样，当需要在特定场景中使用参数化时，改动变量不会影响其他脚本。定义的变量可以在 HTTP 请求的取样器中通过 ${参数名} 的方式引用，适用于需要在多个脚本中统一管理和修改变量的场景，便于集中维护和提高效率。

在这里插入图片描述

2.5.7 CSV 数据文件设置

以登录接口为例，当执行登录接口的性能测试时，如果手动将用户名和密码固定为 username 和 password，这与实际使用场景不符，因为实际环境中不可能只有一个用户登录。为了模拟更真实的登录环境，需要提供更多的用户名和密码组合，动态实现登录操作，从而更贴近实际使用情况。

打开 CSV Data Set Config
CSV 数据文件设置

在这里插入图片描述

配置项	描述
文件名	填写 CSV 文件的路径，建议使用绝对路径以避免路径错误。
文件编码	设置文件的编码方式，推荐使用 UTF-8 以支持多种语言字符。
变量名称	定义从 CSV 文件中读取的数据对应的变量名称，多个变量时使用逗号分隔。
是否忽略首行	指定是否从 CSV 文件的第一行开始读取数据，如果第一行是标题，可以选择忽略。
分隔符	指定 CSV 文件中列与列之间的分隔符，需与实际文件中的分隔符一致。
遇到文件结束符再次循环	当设置为 True 时，在数据读取完后会从文件开头重新开始读取；当设置为 False 时，需要勾选“遇到文件结束符停止线程”选项，否则请求会报错。

编写 test.csv 文件

在这里插入图片描述

修改登录接口及其他涉及到 username 和 password 的参数配置后，登录接口在发起请求时会从 CSV 文件中依次读取配置好的 username 和 password 参数。读取顺序是从 CSV 文件的顶部开始，按行依次向下获取。

在这里插入图片描述

修改线程组中的线程数配置，以确保每次执行时从 CSV 文件中读取到的 username 和 password 都不相同，从而模拟不同用户的登录请求。

在这里插入图片描述

运行结果

在这里插入图片描述

2.5.8 JSON 提取器

JSON 提取器用于从接口响应中提取指定字段的值，并将其作为参数传递给其他接口的请求配置。

添加 JSON 提取器

在这里插入图片描述

操作符	描述	案例
$	表示根元素	$[‘store’]，选择根元素下的 store 节点
@	当前元素	@.price，选择当前元素的 price 属性
*	通配符，用于匹配所有节点	$[‘store’][‘*’]，选择 store 节点下的所有子节点
…	选择所有符合条件的节点	$…book，选择所有层级中的 book 节点
.<name>	指定的子元素	$[‘store’].book，选择 store 下的 book 子元素
[‘<name>’ (, ‘<name>’)]	子元素或子元素列表，用括号表示	$[‘store’][‘book’, ‘bicycle’]，选择 book 和 bicycle 子元素
[<number> (, <number>)]	数组索引或索引列表	$[‘store’].book[0, 2]，选择第 1 和第 3 本书
[start:end]	数组切片操作符，选择指定范围的数组元素	$[‘store’].book[1:3]，选择第 2 到第 3 本书
[?(<expression>)]	过滤器表达式，返回评估为布尔值的条件匹配的节点	$[‘store’].book[?(@.price < 10)]，选择价格小于 10 的书

添加 JSON 配置

在这里插入图片描述

配置 json 提取的参数

在这里插入图片描述

运行脚本后，会将所有查看博客内容接口中对应的 blogId 参数统一替换为 12。

在这里插入图片描述

2.5.9 JSON 断言

接口请求发送成功且响应码为 200，并不完全代表接口请求成功。更重要的是需要关注接口的响应数据是否符合预期，以确保其功能正常。

添加 JSON 断言，为指定的 HTTP 请求接口配置 JSON 数据验证逻辑，以确保响应数据符合预期。

在这里插入图片描述

添加 JSON 配置，使用与 JSON 提取器相同的语法进行设置。

在这里插入图片描述

配置项	描述
未选择 “Additionally assert value”	用于判断字段是否存在，无需添加断言值。
选择 “Additionally assert value”	必须添加 Expected Value（期望的断言值），用于验证字段值是否符合预期。
未选择 “Match as regular expression”	Expected Value 必须完整匹配字段值，缺少任何字符都会导致断言失败。
选择 “Match as regular expression”	Expected Value 可部分匹配字段值，仅需提供部分关键字即可断言成功（通过正则表达式匹配）。

2.5.10 同步定时器

同步定时器（集合点）用于实现并发效果，通过添加同步定时器，可以让多个线程在同一时间点同时执行操作，从而模拟并发场景。

在这里插入图片描述

JMeter 的同步定时器主要用于模拟多用户并发访问场景，确保多个线程能够在同一时间点执行操作，从而实现真正的并发效果。在性能测试中，由于线程在启动时可能存在时间间隔，导致无法达到预期的并发行为。同步定时器通过同步线程的执行时间，使它们在指定的集合点同时执行操作，模拟更接近真实的并发场景。此外，同步定时器还可以在多个线程之间设置延迟，直到所有线程达到指定数量后同时释放，从而瞬间产生高并发压力。

在性能测试过程中，同步定时器可以帮助真实模拟多个用户同时操作的情况，用于评估服务器的处理能力，提升测试的准确性和可靠性。然而需要注意的是，同步定时器虽然能确保请求在集合点同步发送，但由于网络延迟等不可控因素，无法保证请求能够同时到达服务器。因此，同步定时器只能较为接近地模拟并发场景，而非完全精准的并发行为。

在现实生活中，红绿灯就类似于一个集合点。有些人先到达，有些人后到达，但所有人都必须等到绿灯亮起后才能同时开始通过人行道。

在这里插入图片描述

2.5.11 事务控制器

JMeter 的事务控制器主要用于测量执行嵌套测试元素所花费的总时间，相当于模拟用户进行一系列操作的测试。在页面性能测试或 API 性能测试中，事务控制器是非常重要的工具，能够帮助测试人员更准确地评估系统性能，特别是在涉及多个接口或操作的复杂场景中。例如，在订单提交过程中，可能需要调用多个接口，其中一些接口还依赖于前一个接口的结果。通过使用事务控制器，可以将这些接口统一视为一个事务进行性能测试，从而获得更贴近真实场景的测试结果。

在这里插入图片描述

如果不添加事务控制器，每个接口会被视为一个独立的事务。添加事务控制器后，可以将多个接口统一归入一个事务控制器中，将其视为一个整体事务进行测试。

2.5.12 安装插件

在实际的企业压测场景中，我们通常采用逐步增加线程数的方式进行压力测试。为支持线程数的动态配置，需要安装额外的插件。可以通过插件管理工具下载并安装所需的插件来实现这一功能。

下载其他监听器插件

在这里插入图片描述

下载线程组插件

在这里插入图片描述

点击 Apply Changes and Restart JMeter 等待下载完成并重启 JMeter:

在这里插入图片描述

下载完成后再线程和监听器中可以看到新增的元件：

在这里插入图片描述

2.5.13 Stepping Thread Group

配置项	描述
This group will start	启动的线程数，与线程组中的线程数一致。
First, wait for	设置开始压测前的等待时间，单位为秒，通常默认为 0。
Then start	初始化启动的线程数，通常默认为 0。
Next, add	每次增加的线程数，用于逐步增加压测负载。
threads every	设置运行多长时间后再次启动线程，即每批线程启动完成后的持续时间。
using ramp-up	设置线程启动的持续时间。例如，设置为 5 秒，表示每次启动线程的过程需要持续 5 秒。
then hold load for	设置所有线程启动完成后，持续运行的时间，用于模拟稳定负载场景。
finally, stop/threads every	设置每隔多长时间释放多少个线程。例如，设置为每 1 秒释放 5 个线程，表示持续负载结束后逐步释放线程数。

在这里插入图片描述

2.6 常见监听器

2.6.1 聚合报告

聚合报告可以直观地展示性能测试过程中整体的关键数据变化和指标情况。

指标	说明
Samples	发起的 HTTP 请求调用数。
Average	平均响应时间，单位为毫秒。
Median	请求调用响应时间的中位值，即 50% 请求调用的响应时间，单位为毫秒。
90%Line	90% 请求调用的响应时间，单位为毫秒。
95%Line	95% 请求调用的响应时间，单位为毫秒。
99%Line	99% 请求调用的响应时间，单位为毫秒。
Min	请求调用的最小响应时间，单位为毫秒。
Max	请求调用的最大响应时间，单位为毫秒。
Error%	调用失败的请求占比，指因响应断言失败或请求调用出错导致的失败率。
Throughput	TPS/QPS，每秒处理的事务或请求数。
KB/sec	每秒网络传输的流量大小，单位为 KB，用于衡量网络的吞吐量。

在这里插入图片描述

2.6.2 Response Times Over Time

“Response Times Over Time” 监听器主要用于监测整个事务运行期间的响应时间。在测试过程中，它能够帮助测试人员实时观察和分析响应时间的平均值及整体变化趋势。通过该监听器，测试人员可以更直观地了解系统在不同时间点的响应性能，从而有效识别可能存在的性能问题或瓶颈。

在 “Response Times Over Time” 图形中，横坐标表示运行时间，纵坐标表示响应时间（单位：毫秒）。测试人员可以通过观察图形中的趋势线来评估响应时间的稳定性及波动情况。例如，如果响应时间在某个时间点出现明显增长，可能表明系统在该时间点发生了性能问题。

在这里插入图片描述

2.6.3 Transactions per Second（TPS）

JMeter 中的 Transactions per Second（TPS）监听器是分析系统吞吐量的重要工具。TPS（每秒事务数）表示客户端向服务器发送请求并接收响应的整个过程，反映了系统在单位时间内处理业务的最大能力。TPS 值越高，说明系统的处理能力越强。

使用 TPS 监听器时，横坐标通常表示运行时间，纵坐标表示 TPS 值。通过监听器生成的图表，可以直观地观察 TPS 值随时间的变化趋势。在图表中，红色通常表示成功的 TPS，绿色可能表示失败的 TPS。这种可视化的方式有助于测试人员快速识别系统性能的变化和潜在瓶颈。

在这里插入图片描述

2.7 测试报告

JMeter 测试报告是一份全面而详细的文档，提供了关于测试执行结果的关键信息，帮助用户全面评估系统性能并提出优化方案。可以通过指定命令生成性能测试报告，以便更高效地分析和改进系统性能。

Jmeter -n -t 脚本⽂件 -l ⽇志⽂件 -e -o ⽬录
-n ： ⽆图形化运⾏
-t ： 被运⾏的脚本
-l ： 将运⾏信息写⼊⽇志⽂件，后缀为jtl的⽇志⽂件
-e ： ⽣成测试报告
-o ： 指定报告输出⽬录

注意：日志文件和目录可以不存在，但如果已经存在，必须确保内容为空，否则可能会导致错误。

在这里插入图片描述

性能测试报告生成成功后，在 rizhi 文件夹下将出现以下内容：

在这里插入图片描述

一：性能测试

1.1 什么是性能测试

1.2 常见的性能指标

1.2.1 并发数

1.2.2 吞吐量

1.2.3 响应时间

1.2.4 TPS 和 QPS

1.2.5 资源利用率

1.3 性能测试的关注点

1.4 性能测试分类

1.4.1 基准测试

1.4.2 并发测试

1.4.3 负载测试

1.4.4 压力测试

1.4.5 压力测试和负载测试的区别

1.4.6 稳定性测试

二： JMeter

2.1 使用 JMeter

2.2 JMeter 基础配置

2.3 JMeter 基本使用

2.4 JMeter 元件作用域和执行顺序

2.5 重点组件

2.5.1 线程组

2.5.2 HTTP 取样器

2.5.3 查看结果树

2.5.4 HTTP Cookie 管理器

2.5.5 HTTP 请求默认值

2.5.6 用户定义的变量

2.5.7 CSV 数据文件设置

2.5.8 JSON 提取器

2.5.9 JSON 断言

2.5.10 同步定时器

2.5.11 事务控制器

2.5.12 安装插件

2.5.13 Stepping Thread Group

2.6 常见监听器

2.6.1 聚合报告

2.6.2 Response Times Over Time

2.6.3 Transactions per Second（TPS）

2.7 测试报告

相关文章：