【软件测试】--性能测试Jmeter

最新推荐文章于 2025-05-02 15:00:00 发布

Mr Maria

最新推荐文章于 2025-05-02 15:00:00 发布

阅读量742

点赞数 6

分类专栏： # 测试文章标签： jmeter

本文链接：https://blog.youkuaiyun.com/qq_63051355/article/details/140776002

版权

1. 性能测试概述

1.1 性能测试基础

1.1.1 什么是性能测试

概念：测试软件的性能

后端处理性能–响应时间

服务器硬件资源（CPU、内存、磁盘）

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

中间件：提供系统软件和应用软件之间连接的软件。简称：应用服务器，如：Tomcat、Apache…

1.1.2 性能测试目的

评估当前系统能力–发布时

寻找性能瓶颈，优化性能–线上出问题，定位问题时使用

预估是否满足未来性能要求–为将来做准备

1.1.3性能测试与功能测试

焦点
- 功能测试：验证软件系统操作功能是否符合产品功能需求规格，主要焦点在功能（正向、逆向）
- 性能测试：验证软件系统是否满足业务需求场景，主要焦点是业务场景的满足（时间、空间）
  
  注：
  
  时间：软件的响应时间
  
  空间：服务器的磁盘使用率，CPU使用率、内存空闲率…
关系：
- 功能测试和性能测试是相辅相成的，对于一款优秀的软件产品来讲，他们是不可减少的2个重要测试环境

1.2 性能测试分类

基准测试

基准测试策略：无论选取之前的任何一种测试方式，都需要先进行基准测试，作为后续测试结果的对比

基准测试的概念

狭义上讲：就是单用户测试。测试环境确定后，对业务模型中的重要业务做单独的测试，获取单用户运行时的各项性能指标

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

基准测试的用途
- 基准测试不会单独存在
- 为多用户并发测试和综合场景测试等提供参考依据
- 为系统/环境配置、系统优化前后的性能提升/下降提供参考指标

负载测试

压力测试

并发测试

稳定性测试

1.2.1 负载测试

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

1.2.2 压力测试

通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统处于失效状态

1.2.3 并发测试

通过模拟用户并发访问，测试多用户同时访问同一应用、模块或数据，观察系统是否存在问题

1.2.4 稳定性测试

给系统加载一定的业务压力的情况下，运行一段时间（24h，3X24h，7X24h）检查系统是否稳定

1.3 性能测试指标

吞吐量

并发数

响应时间

点击数

资源利用率

错误率

TPS

QPS

1.3.1 吞吐量

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

通常情况下，吞吐量用“请求数/秒”或者“页面数/秒”来衡量

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

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

每秒事务数（TPS）和每秒查询数（QPS）归属吞吐量，区别在于TPS\QPS描述服务器具体性能处理能力

1.3.2并发数

并发测试的用户数

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

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

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

1.3.3 响应时间

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

组成：响应时间=服务器处理时间+网络传输时间

响应时间分为前端展示时间和系统响应时间两部分。
前端展示时间指的是客户端收到服务器返回的数据后渲染前端页面，所耗费的时间。
系统的响应时间，分为web服务器，应用服务器，数据库服务器，等各种服务器之间通信和处理请求的时间。

前端展示时间（用户响应时间）：服务器发起请求到收到响应这段时间
N1+A1+N2+A2+N3+A3+N4
**系统响应时间（请求响应时间)：**服务器收到请求到发出响应这段时间
A1+N2+A2+N3+A3
影响一个软件响应时间的因素：网络带宽、数据库性能、服务器处理性能、软件算法逻辑

1.3.4 点击数

点击数是衡量web服务器处理能力的一个重要指标

注：

点击数不是通常以为的访问一个页面就是一次点击数，点击数是该页面包含的元素（如：图片、链接、框架等）向web服务器发出的请求数数量
通常我们也用每秒点击次数（Hits per Second）指标来衡量Web服务器的处理能力
只有web服务器才有此指标

1.3.5 资源利用率

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

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

建议CPU不高于80%（+—5）
内存不高于80%
磁盘不高于90%
网络不超过80%

1.3.6 错误率

错误率指系统在负载情况下，失败交易的概率。错误率=（失败交易数/交易总数）*100%

提示：

不同系统对错误率要求不同，但一般不超过（成功率为6到8个9）
稳定性较好的系统，其错误率应该由超时引起，即为超时率

1.3.7 TPS

Transaction Per Second，每秒事务数（单位时间内系统处理的客户端请求的事务次数）

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

事务：业务站在代码角度的统称，可以理解为一段或多段代码

提示：TPS归属吞吐量

1.3.8 QPS

Query Per Second，每秒查询数（衡量web服务器处理能力的重要指标）

1.4 性能测试流程

性能测试需求分析
性能测试计划
性能测试用例
测试脚本编写/录制
搭建场景
运行脚本
系统性能调优
性能测试报告总结

功能测试流程

需求评审

测试计划（测试什么时候开始与结束，谁来测、怎么测）

测试设计（编写测试用例、开发测试工具、用例评审）

执行用例

缺陷管理

测试报告

1.4.1 性能测试需求分析

明确被测系统
- 熟悉被测系统的业务功能
- 熟悉被测系统的技术架构
明确测试内容
- 从业务角度明确测试内容
  - 确定关键业务。即：用户使用频率较高的业务功能
- 从技术角度明确测试内容
  - 如：通常逻辑复杂度较高的业务也是CPU密集运算较大的地方，考量服务器CPU在预定性能指标下是否达标
  - 如：通常数据量较大的业务很占用系统内存，考量服务器CPU在预定性能指标下是否达标
明确测试策略
- 负载测试
- 压力测试
- 稳定性测试
- 并发测试
明确测试指标