Day41 JMeter实战

系列文章目录

Day01 软件测试基础总结

Day02 测试用例知识点总结（上）

Day03 测试用例知识点总结（下）

Day04 禅道-从安装到卸载

Day05 MySql的基础使用

Day06 MySql知识点总结

Day07 MySql知识点再总结与多表查询

Day08 redis的基础知识

Day08 VMware的安装、Linux系统安装和Linux基础命令

Day09 Linux常用命令总结

Day10 Linux环境部署和项目构建

Day11 shell脚本基础知识

Day12 接口和协议

Day13 Postman的使用

Day13 Windows环境下的JDK安装与Tomcat的启动

Day14 jenkins部署

Day15 jenkins的简单使用

Day16 charles的基本使用

Day17 考试

Day18 考试

Day19 Fiddler的简单使用

Day20 Python基础

Day21 python 语句基础

Day22 Python数据类型（上）

Day23 Python数据类型（下）

Day24 Python函数

Day25 Python的文件操作和异常处理

Day26 Python面向对象

Day27 Python的部分算法

Day28 单元测试 unittest

Day29 单元测试 pytest

Day30 接口测试requests

Day31 Web端自动化基础

Day32 Web自动化进阶

Day33 PO模型

Day34 移动端测试（上）

Day35 移动端测试（下）

Day36 移动端自动化(上)

Day37 移动端自动化(下)

Day38 性能测试理论

Day39 JMeter的使用（上）

Day40 JMeter的使用（下）

Day41 JMeter实战

前言

一、项目的介绍和部署

1.轻商城项目介绍

项目背景：轻商城项目是一个现在流行的电商项目，我们需要综合评估该项目中各个关键接口的性能，并给出优化建议，以满足项目上线后的性能需求

2.框架

前台商城:购物车，订单，支付，优惠券等
后台管理系统:商品管理，会员管理，商场管理，推广管理等

3.项目技术架构

前端：VUE技术框架开发，支持微信小程序、手机移动端、web界面

后端：SpringBoot框架开发，MySQL做数据库

4.熟悉数据库设计

1：熟悉数据库设计结构，便于后期对数据库的性能监控，方便定位问题
2：构造性能测试

二、性能测试需求分析

1.获取需求

客户提出：

能够提出明确需求的一般是金融、银行、电信、医疗等企业，他们一般对系统性能要求高，并且对性能也非常了解

根据历史运营数据分析：

用户频繁使用的功能模块是哪些

每月每周每天的峰值业务量是多少

竞品分析：

对比同类型软件的性能指标结果

总结：

客户方给出(传统行业)

根据运营数据来计算(互联网行业)

根据竞品分析(新上线的无历史数据)

2.提取性能测试点

业务维度提取：

用户频繁使用的业务功能

非常关键的业务功能

特殊交易日或峰值交易的业务功能

核心业务发生重大调整的业务功能

技术维度提取：

资源占用非常高的业务功能

3.确定性能测试目标

以“轻商城”为例作为一个新开发的项目，性能测试目标包括：

确定核心业务功能的TTPS

对业务流程（多接口组合）进行压测

系统能在实际系统运行压力的情况下，稳定的运行24小时

三、性能测试计划及方案

测试计划的核心：

1.测试背景

2.测试目的

确定核心业务功能的TTPS

对业务流程（多接口组合）进行压测

系统能在实际系统运行压力的情况下，稳定的运行24小时

3.测试范围

4.测试策略

基准测试：先做基准测试，确定估算的标准

负载测试：分别模拟5、10、30、50、100个用户对系统进行负载测试，查看不同并发时系统软件各项指标是否符合需求

稳定性测试：用200用户对系统进行7*24小时的不间断稳定性测试

5.风险控制

6.交付清单

7.进度与分工

四、性能测试用例设计

根据测试点逐条进行细化

性能测试的数据，有明确的要求，需要达到一定的业务量

从接口维度上描述测试步骤

如果接口有关联，放在一个测试用例中

五、性能测试用例执行

1.编写测试脚本

按照用例去编写脚本信息

常用测试元件：

取样器--http请求

配置元件--用户定义变量

配置元件--http请求默认值

后置处理器--json提取器

断言--相应断言/json断言

监听器--聚合报告/察看结果树

2.建立测试环境

性能测试环境的特点：

独占性：

尽量保持性能测试环境与真实生产环境一致性

硬件环境

包括服务器环境，网络环境等

软件环境

版本一致：包括操作系统，数据库，被测应用程序，第三方软件等

配置一致：包括操作系统，数据库，被测应用程序，第三方软件等

使用场景一致：

基础业务数据一致

业务操作模式一致性：尽量模拟真实场景下用户的使用情况

构建性能测试数据

目的：压测环境中的数据量与生产环境中数据量一致

方法：为了快速创建大量数据，可以直接操作数据库进行添加

准备插入数据的SQL语句

循环执行SQL语句来插入数据

导包>>连接数据库>>创建游标>>执行SQL语句>>关闭游标>>关闭连接

import pymysql

# 建立连接
conn = pymysql.Connect(host='www.litemall360.com', port=3306, user='root', passwd='123456', database='lite-mall',
                       charset='utf8')
cursor = conn.cursor()  # 创建游标
sql11 = "INSERT INTO ’litemall‘.’litemall_address’(’id’, ’name’, ’user_id’,’province’, ’city’, ’county’, " \
        "’address_detail’, ’area_code’, ’postal_code’,’tel’, ’is_default’, ’add_time’, ’update_time’, ’deleted’) " \
        "VALUES ({}, {}, {},'北京市', '市辖区', '东城区', '123123', '110101', '', '13426388766', 0, '2022-09-14 18:20:06', " \
        "'2022-09-14 18:20:06', 0); "
start_id = 4
for i in range(3):
    start_id = start_id + i
    cursor.execute(sql11.format(start_id, start_id, start_id))
conn.commit()  # 提交
cursor.close()  # 关闭游标
conn.close()  # 关闭连接

3.性能测试监控

系统指标：响应时间、吞吐量、错误率、并发数

资源指标：cpu、内存、磁盘、网络

4.执行测试脚本

登录

进入首页

搜索商品

六、性能分析和调优

1.性能调优的步骤

确定问题：根据性能监控的数据和性能分析的结果，确定性能存在的问题

确定原因：确定了问题之后，对问题进行分析，找出问题产生的原因

给出解决的方案：确定调整目标和解决方案(改进服务器的参数配置/增加硬件资源配置，修改代码)

验证问题：按照给出的解决方案，重新进行测试

分析调优结果：分析出问题的性能指标是否有提升，关注其他指标是否下降

2.性能瓶颈分析

    在实际的性能测试中，会遇到各种问题，比如tps压不上去，导致这种现象的原因很多，作为测试人员应该配合开发人员进行分析尽快找出瓶颈的所在。

瓶颈存在的可能性：

服务器的资源
服务器资源分析CPU瓶颈CPU已压满（接近100%），通常其他指标的拐点出现的时刻是否与CPU压满的时刻基本一致内存瓶颈内存不足时，操作系统会使用虚拟内存，从虚拟内存读取数据，影响处理速度磁盘I/O瓶颈磁盘I/O成为瓶颈时，会出现磁盘I/O繁忙，导致交易执行时在I/O等待网络带宽如果传递的数据包过大，超过了带宽的传输能力，就会造成网络资源竞争，导致TPS上不去

压测机的资源
JMeter单机负载能力有限，如果需要模拟的用户请求超过其负载极限，也会导致TPS压不上去

数据库的资源
慢查询数据库的连接池设置太小数据库出现死锁

jvm--java程序运行的环境
JVM内存内存申请没有及时释放，造成内存泄漏

程序内部实现机制--开发人员编写的代码分析

1.服务器硬件指标

CPU,内存，磁盘，主板，显卡，机箱，电源，散热器等

CPU使用率=已使用的时间片/总时间片*100%

已使用的时间片=用户CPU+系统CPU

总时间片=用户CPU+系统CPU+空闲CPU

用户CPU：所有应用程序运行时消耗的CPU

系统CPU：操作系统运行消耗的CPU

测试关注点：

CPU过高时，需要确认是用户CPU高还是系统CPU高

如果是用户CPU高，需要进一步分析对应的应用程序的执行效率是否有问题

如果是系统CPU高，需要进一步观察其他的资源（内存、磁盘、网络等）是否存在问题

内存：

实际内存/物理内存，机器实际的内存空间，所有的程序运行都必须加载到内存中才能运行

虚拟内存：一种虚拟化技术。当内存空间不足时，从磁盘中读入数据，处理完成后写回磁盘，以此进行交换，保证在内存不足时，程序也能够运行

注意：

由于虚拟内存，实际上完成了数据在磁盘与内存之间的读写过程，磁盘的速度要远慢于内存，因此当使用虚拟内存时，就已经说明内存不足，可能存在问题

Linux查看内存的命令：

查看总量：top（查看内存使用百分比，检查是否超过80%）

查看虚拟内存的使用量：vmstat（查看swap的si和so是否为0，不为0说明内存可能不足）

测试关注点：

实际内存：查看内存使用的百分比，检查是否超过80%

虚拟内存：查看swap的si和so是否为0，如果不为0，说明内存不足

磁盘I/O瓶颈：影响性能是磁盘的读写速度（Input和Output），不是磁盘大小

查看磁盘的命令（两个1分别代表一秒一次）：iostat -x 1 1

测试关注点：

如果%until接近100%，说明磁盘长时间占用CPU在发送请求，说明磁盘传输速度不足，I/O系统已经满负荷，存在瓶颈

如果%iowait的值过高，说明磁盘io传输数据的任务很多，在等待，表示硬盘存在I/O瓶颈

网络瓶颈：影响性能的是网络的传输速度，与网络的总带宽进行对比，接近总带宽，说明网络存在的瓶颈

查看网络使用的命令：sar -n DEV 1 2

测试关注点：

实际统计的发送速率（rxKB/s）和接收速率（txKB/s），与网络的总带宽进行对比，查看使用的百分比（如果无限接近100%，说明存在网络性能瓶颈）

补充：

宽带：用户(业务)维度来描述网络速度的方式，比如：20M(兆)宽带，100M宽带，200M宽带速率单位：b(bit)/s
带宽：数据在网络中传输的速率，比如下载东西(迅雷),在技术中都是用带宽来描述速率的速率单位：B(byte)/s
区别：1B=8bit
实际情况：1000M的宽带---对应的带宽速率是1000/8=125M

2.数据库

慢查询

定义：指执行速度低于设置的阀值的SQL语句

作用：帮助定位查询速度较慢的SQL语句，方便更好的优化数据库系统的性能

查询语句：

show variables like 'slow_query%'; #慢查询日志开启状态（ON 开启/OFF 关闭）和位置

show variables like 'long_query_time'; #慢查询时长设置（超过时长的才会被记录单位秒）

set global slow_query_log='ON'; #开启慢查询日志

set global long_query_time=1; #设置慢查询时间标准，设置之后会在下次会话生效

数据库连接池

数据库连接池定义：事先建立连接，负责分配，管理和释放数据库连接，它允许应用程序重复使用一个现有的数据库连接，而不是再重新建立一个，节省了sql语句执行前后连接的和关闭的时间

使用过程：

当客户请求数据库连接时

首先查看连接池中是否有空闲连接，如果存在空闲连接，则将连接分配给客户使用

如果没有空闲连接，则查看当前所开的连接数是否已经达到最大连接数，如果没达到就重新创建一个连接给请求的客户

如果达到就按设定的最大连接数进行等待

如果超出最大等待时间，则抛出异常给客户

查询语句：

show VARIABLES like '%MAX_CONNECTIONS%'; #查看mysql最大连接数

show status like 'Threads_connected'; #查询当前数据库已建立连接数

测试关注点：

MYSQL官网给出了一个设置最大连接数的建议比例：Max_used_connections/max_connections*100%=85%，需要关注MYSQL的最大连接数和系统运行时数据库建立连接的比例

如果已使用连接数与最大连接数比例超过85%，需要增大最大连接数设置，否则会造成连接失败

如果使用连接数与最大连接数比例小于10%，那么显然设置的过大，会造成系统资源的浪费

数据库死锁

锁的定义：

当一个用户修改数据时，对该数据进行加锁操作，使其他用户不能进行修改；

只有当第一个用户修改完成之后，其他用户才能修改。

MySQL常见的两种锁：

表锁：效率低，但是安全性高(不会出现死锁)
行锁：效率高，但是安全性低(会出现死锁)

死锁的定义：

指两个或者两个以上的进程在执行过程中，因争夺资源而造成的一种相互等待的现象

若无外力作用，它们都将无法推进下去，此时称系统处于死锁状态或系统产生了死锁

表锁不会残生死锁

查询语句：

SHOW OPEN TABLES where in_use>=1; #查看当前正在使用的表(可能是锁定的表)
show PROCESSLIST; #查看执行长时间的线程，找到对应的sql
kill process_id; #如果锁死，先手动杀死死锁的连接

测试关注点（初步确定死锁）：

首先查询当前是否锁表如果表锁了，这个SQL可以查询出来但是这个SQL查出来的表，不一定是被锁住的。因为用查询，如果耗费时间很长，也会被查询出了来

查看执行时间最长的线程，找到对应SQL，找到表

如果需要先紧急解决问题，可以先动手杀死死锁的连接

3.java应用指标

jvm内存：java虚拟机在执行java程序的过程中所管理的不同的内存数据区域。可简单分为：堆内存和非堆内存
堆内存：存储动态的数据，主要存放用new关键字创建的对象，所有对象实例以及数组都放在堆上分配--给开发人员使用的(关注)
非堆内存：保存虚拟机自己的静态数据，存放加载的class类级别静态对象如类，方法等--给jvm自己使用的

jvm堆内存的管理机制（java垃圾回收机制）

年轻代存储”新生对象“，我们新创建的对象存储在年轻代中

当年轻代内存占满后，会触发Minor GC，清理年轻代内存空间

老年代存储长期存活的对象和大对象。年轻代中存储的对象，经过多次GC后仍然存活的对象会移动到老年代中进行存储

老年代空间沾满后，会触发Full GC是清理整个堆空间，包括年轻代和老年代

java常见的内存问题：

内存泄漏：

内存泄漏 memory leak，是指程序在申请内存后，无法完全释放已申请的内存空间

一次内存泄漏危害可以忽略，但内存泄漏堆积后果很严重，无论多少内存，迟早会被占光

内存溢出：

内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory

memory leak 最终会导致 out of memory

测试关注点：

堆内存使用量持续增长--可能是内存泄漏

Full GC比较慢，执行时会停止程序一些事务的处理。因此Full GC频率不能过高（低于10分钟）

如果Full GC之后，堆中仍然无法存储对象，就会出现内存溢出--程序出现crash（崩溃）

** jvm监控--使用本地jvisualvm远程监控服务器：**

添加应用程序启动参数，并启动服务 -Dcom.sun.management.jmxremote-Djava.rmi.server.hostname=ip地址-Dcom.sun.management.jmxremote.port=端口号-Dcom.sun.management.jmxremote.ssl=false-Dcom.sun.management.jmxremote.authenticate=false

进入本地jdk安装目录bin目录，找到jvisualvm.exe并启动

右键“远程”选择“添加远程主机”，并输入主机IP

右键主机选择“添加JMX连接”，并输入JMX端口

4.压测机

压测机影响性能测试结果的原因主要是：jmeter单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会导致TPS压不上去

压测机资源监控方法：

window测试机：自带的'任务管理器'
Linux测试机：perfmon组件或者top命令

解决方式：
采用分布式执行的方法(增加资源)来提高负载量，达到系统性能测试要求的TPS

总结（常见的性能问题主要的原因）：

服务器资源分析 cpu瓶颈用户cpu和系统cpu内存瓶颈实际内存和虚拟内存磁盘IO瓶颈磁盘input和output网络瓶颈网络上下行带宽

数据库瓶颈分析慢查询数据库连接池死锁

jvm瓶颈分析 jvm内存堆内存和内存回收

程序内部实现机制

压测机

七、性能测试报告总结

测试过程回顾----测试目的，测试范围，测试环境，测试使用的工具

测试问题记录及结果分析---性能测试过程中遇到的问题，分析过程和解决方案

测试结论

测试总结和教训

总结

    根据公司的需要分析提出性能测试点(主流程的接口)，接着（编写性能测试计划），编写测试用例，搭建压测环境(模拟线上的环境，服务器的配置，安装程序的版本)准备测试数据(通过python脚本执行)，通过测试工具jmeter进行压测，将serveragent在服务器上启动进行监听，在jmeter的监听器中使用perfmon进行监控，指定ip，端口，cpu/内存
     按照要求依次增加并发量，查看是否满足要求，找出对应的瓶颈(cpu使用过高，内存占用过高)我们公司规定cpu不能超过75%，内存不能超过80%，最后编写测试报告

标签：测试工具自动化测试

本文转载自: https://blog.csdn.net/lookout99/article/details/126946936
版权归原作者 lookout99 所有，如有侵权，请联系我们删除。