性能测试-jmeter实战2

课程：B站大学
记录软件测试-性能测试学习历程、掌握前端性能测试、后端性能测试、服务端性能测试的你才是一个专业的软件测试工程师

性能测试的流程

如下：
🟡 1. 分析现状（Analyze the existing environment）
目的：了解系统架构、部署环境、业务流程等背景信息。

例如：识别测试系统的服务器组成、应用架构、网络拓扑等。

🟠 2. 获取当前性能指标（Gather performance characteristics of the current system）
目的：了解系统在当前负载下的性能情况，为后续测试做基准。

包括：CPU 使用率、内存使用、响应时间、TPS、吞吐量等。

🔴 3. 定义用户场景（Define usage model and load distribution）
目的：基于用户行为定义测试场景和负载模型。

示例：并发用户数、操作路径（如登录-浏览-下单）等。

🟣 4. 定义性能验收标准（Define the performance acceptance criteria）
目的：确定性能测试是否通过的标准。

包括：响应时间不超过 2s，错误率 <1%，并发用户数支持 5000 等。

🟣 5. 测试计划/脚本（Develop the test assets, test plan, test scripts and scenarios）
目的：编写测试脚本、制定测试计划。

工具：JMeter、LoadRunner、Locust 等。

🔵 6. 准备压力环境（Configure the load generation environment）
目的：搭建并配置性能测试执行环境。

包括：压测机配置、网络带宽检查、工具安装等。

🔵 7. 执行压测（Execute planned tests）
目的：按照计划开始执行性能测试。

注意：压测时控制变量，分阶段增加并发负载。

🔵 8. 监控（Monitor web servers, application servers and database server’s performance counters）
目的：实时监控服务器的运行状态。

包括：系统监控（如 Zabbix、Prometheus）和日志监控。

🟢 9. 搜集分析（Correlate and analyze the results）
目的：分析性能数据，找出瓶颈点。

技巧：使用图表查看 TPS 曲线、响应时间波动、错误分布等。

🟤 10. 测试报告（Generate reports）
目的：整理压测数据和分析结果，撰写性能测试报告。

包括：测试结论、问题定位、改进建议等。

⚫ 11. 改进建议（Provide performance improvement recommendations）
目的：提出系统优化建议，如 SQL 优化、缓存机制、增加资源等。

⚫ 12. 持续测试（Retest as needed）
目的：修改优化后重新测试，验证性能改进效果。

特点：是一个持续循环优化的过程。

性能测试方法

一、并发模式（虚拟用户模式）

定义：通过模拟“并发用户数”来发起请求，从业务角度模拟用户行为。

理解方式：可等价理解为“同时在线的用户数”。

适用场景：当你希望从客户端用户的角度，验证系统在高并发场景下是否还能稳定运行，适合 Web、App 等交互式系统。

举例：模拟 1000 个用户同时登录、浏览、下单，观察系统响应时间和错误率。

二、RPS 模式（吞吐量模式）

RPS（Requests Per Second）：每秒请求数，反映服务端单位时间内的处理能力。

测试方式：从服务器端角度出发，直接设定请求速率（如每秒 1000 次请求），验证系统的吞吐能力。

适用场景：适用于接口、服务类测试，特别是微服务系统，可避开并发转 RPS 的繁琐过程。

优势：比并发更“直接”和“稳定”，尤其适合接口压测、限流测试等场景。

总结：两种性能方法：一种测试同时在线数，一种测试高频请求

性能测试计划

1、如何制定性能测试计划？根据实际场景制定性能测试计划

2、测试数据集

3、搭建性能测试环境

此处环境部署阶段，需要掌握运维相关技能知识，比如搭建一个专属小集群，并且该集群和生产环境尽量保持一致，性能测试不能"只测不调"，需要一边测试一遍调试，找到性能瓶颈。

4、性能指标预期

Jmeter性能

Jmeter工具常见的插件

• PerfMon Metrics Collector

• 安装在 JMeter 和被测服务器上
  实时收集 CPU 使用率、内存变化、磁盘 IO 等信息

• Custom Thread Groups

• 更精细控制压测场景，如阶梯式加压、定时并发等

• Throughput Shaping Timer

• 更精准控制 RPS 模式下的请求速率

发压时间线

第一步很重要：记录机器各个方面的参数，作为原始数据，以此作为性能调试测试时依据
一般分为：CPU、内存、磁盘、网络
第二步：起压，逐步调节并发量，观察一段时间内的各个机器参数的变化
第三步：大多数公式都会用nginx做负载均衡以及日志记录各种数据
故我们可以选择常用的命令查看详细的数据：

常用命令解读：

以下是图片中Linux运维命令的详细解读，按编号对应说明其作用和原理：

​​1. 查看Nginx每秒请求数​​
tail -f access.log | awk '{print $4}' | uniq -c
​​作用​​：实时统计Nginx每秒处理的请求数量。
​​解析​​：
tail -f：实时追踪日志文件新增内容。
awk '{print $4}'：提取日志中时间戳字段（假设第4列为时间）。
uniq -c：合并相邻重复行并计数，显示每秒请求频次。
​​2. 查看某接口每秒请求数​​
tail -f access.log | grep p_getorderstatus | awk '{print $4}' | uniq -c
​​作用​​：实时监控特定接口（如p_getorderstatus）的每秒请求量。
​​解析​​：
grep：筛选包含接口名的日志行。
其余部分同命令1，统计时间戳频次。
​​3. 查看CPU空闲状态​​
xmstat 1
​​注意​​：应为vmstat 1（可能是笔误）。
​​作用​​：每秒输出一次CPU使用情况，包括空闲率（id列）。
​​关键列​​：id表示CPU空闲百分比，值越高说明负载越低。
​​4. 查看内存​​
free -m
​​作用​​：以MB为单位显示内存使用情况。
​​输出字段​​：
total：总内存。
used/free：已用/剩余内存。
buff/cache：缓存和缓冲区占用。
​​5. 检查Nginx错误请求​​
tail -f access.log | cut -d' ' -f 10 | grep -v 200
​​作用​​：实时过滤非200状态码的请求（错误请求）。
​​解析​​：
cut -d' ' -f 10：提取日志中HTTP状态码字段（假设第10列）。
grep -v 200：排除状态码为200的行，显示异常请求。
​​6. 查看进程​​
top        # 动态查看进程资源占用
ps aux|grep xxx  # 筛选特定进程
​​作用​​：
top：实时进程监控（CPU、内存排序）。
ps aux|grep：精确查找含xxx关键词的进程。
​​7. 统计某接口总访问量​​
cat access.log.xxxx|grep p_getorderstatus |wc -l
​​作用​​：统计历史日志中某接口的调用总次数。
​​解析​​：
grep：筛选接口名相关日志。
wc -l：计数行数（即请求次数）。
​​8. 杀进程的三种方式​​
kill 1234                 # 终止指定PID的进程
pkill nginx               # 按进程名批量终止
kill `pgrep -f xxxx`      # 终止匹配自定义特征的进程
​​区别​​：
kill：需精确PID。
pkill：按名称模糊匹配。
pgrep -f：支持完整命令行匹配（如参数）。
​​9. 检查TIME_WAIT连接数​​
ss -s                  # 统计各状态连接数（推荐）
netstat -tn|grep TIME_WAIT|wc -l  # 传统计数方式
​​作用​​：检测TCP连接中TIME_WAIT状态的数量（可能影响端口复用）。
​​推荐​​：ss -s更高效，直接显示汇总信息。

测试结果

测试报告

以上就是接到一个性能测试任务，从0到1的流程

性能测试场景

常见的性能常见主要有：

• 能力验证
• 容量规划
• 问题追查风险发现
  

性能测试概念

并发:并发是指虚拟并发用户数，从业务角度，也可以理解为同时在线的用户数，并行技术上提升压力的方式：

TPS::系统每秒处理交易数，单位是笔/秒
QPS:系统每秒处理查询次数，单位是次/秒，对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS,一般情况下用户TPS来衡量业务流程，用QPS来衡量接口查询次数

并发数=QPS*平均响应时间
平均响应时间、QPS可以从jmeter中获取

性能测试概念

目前都是一些做性能测试实战需要知道的知识点，方便后面我们进行性能测试

实践是检验真理的唯一标准