性能测试流程（流程概念全）_性能测试 csdn-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_35283902/article/details/137977719

本文详细阐述了IT项目中的需求分析，包括性能需求采集、系统架构设计、业务流程理解、并发用户计算以及性能测试的各个环节，如JMeter在性能测试中的应用，TPS和并发用户数的计算，以及测试模型、场景设计和风险评估等内容。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

需求分析

需求采集
1. 性能需求采集的内容
  1. 系统架构
    1. websever负责反向代理，青苔处理请求
    2. tomcat负载动态处理
    3. musql做双机热准备
    - 逻辑架构
  2. 采集业务并量化业务
    1. 系统的主要业务流程
  3. 了解业务扩展趋势
    1. 系统的业务扩产预估，一段时间的用户增长量，如：系统业务增长率有30%，系统在3年内不进行分库分表处理
  4. 了解系统是否有归档机制
    1. 在3年内不进行数据归档，在测试时需要3年的存量数据
  5. 采集业务的发生时段
  6. 采集在线用户数、活动用户数、业务分布
  7. 系统是否与第三方关联关系
  8. 采集业务性能指标
  9. 采集系统硬件指标
    1. cpu使用率小于70%，过大导致服务不稳定
    2. 内存使用率小于70%，过大导致服务不稳定
    3. disk time小于70%，过大io等待时间编程，服务水平降低
    4. 网络带宽小于70%，过大导致网络阻塞，网络延时变长，响应时间变长
需求分析
1. 圈定测试范围
  1. 确定高频次的业务
  2. 确定性能影响最大的业务
  3. 确定此功能的可验证性
2. 明确性能指标
  1. 吞吐量（PV、TPS）
    1. 日PV是2万，3年30%的增长。日PV=2*（1+30%）≈3.38万
  2. 响应时间：要求3s内
  3. 成功率：90%
  4. 稳定波动正常范围
  5. 其他各项硬件等性能指标（参考采集系统硬件指标）
3. 分析业务量
  1. 测试数据的多少对测试结果会有影响，所以测试时我们需要以日PV=2*（1+30%）≈3.38万的数据量的基础上进行测试，可以提前把问题暴露出来
4. 计算TPS（TPS:每秒平均事务数即吞吐量）
  1. 计算TPS需要把PV转化成TPS
  2. TPS、要取系统业务高峰期的值，高峰期的TPS才能代表系统的实际处理能力
  3. 采用8/2原则如：系统10点的pv为5208 TPS=5208*80%/(3600*20%)≈5.8
5. 分析系统协议
  1. 向开发团队咨询，了解程序的交媾与协议
  2. 截包分析
并发数计算
1. 常用的并发数计算方式
  1. 由TPS来估算并发用户数
  2. 有在线用户数来估算并发用户数
  3. 根据经验来估算并发用户数
2. TPS（每秒事务数）是衡量系统每秒可以处理的事务数的一个指标。要从TPS计算并发用户数，我们需要了解两个额外的参数：
  1. 平均事务响应时间 (Average Transaction Response Time, ART): 即用户发起一个事务，到事务被完全处理完毕，所需的平均时间，通常以秒为单位。
  2. 用户思考时间 (Think Time, TT): 用户在发起连续两个事务之间的平均等待/思考时间。
  3. 这两个参数对于理解用户的行为模式至关重要。用户并不会连续不断地发送请求；他们会在两个请求之间有一个思考期或等待期。有了这些信息，我们可以使用以下公式估算并发用户数：
    1. 并发用户数 = TPS × (ART + TT)
  4. 举例说明：
    
    假设一个应用程序的TPS约等于5.8，即每秒可以处理大约5.8个事务。平均事务响应时间为2秒，用户思考时间为8秒。那么并发用户数可以按照上面的公式计算：
    
    并发用户数 = 5.8 × (2 + 8) = 5.8 × 10 = 58
    
    这意味着在这个例子中，系统可以支持大约58个并发用户在正常操作下保持大约5.8 TPS的性能。
    
    请注意，这个计算假设所有用户都是均匀分布，且每个用户都会按照平均事务响应时间和用户思考时间进行操作。实际情况中，用户行为可能会有很大差异，这个计算只能提供一个大致的估算。实际的并发用户数可能会因为网络延迟、用户行为模式的不同以及服务器处理能力的波动而有所不同。因此，通常需要更详细的性能测试来准确评估系统能够支持的并发用户数。

测试模型

业务模型：业务流程，业务系统在某个时间段内运行的业务种类及其业务占比，即哪些业务在在哪个时间段在运行，业务量是多少
测试模型：从业务波形中分析整理出来的进行测试的业务，通常是高额业务，高资源占用业务，这些业务具有可测性、可验证性。测试模型作为性能测试场景的依据，通常会惩戒业务模型大多数业务功能。
性能测试场景：参照用户使用习惯设计负载场景，比如哪些业务的测试脚本一起运行；哪些业务有先后顺序，运行多少并发用户等

测试计划

系统概述

简述系统使命、系统功能，清楚系统是做什么

测试环境

系统生产环境、系统测试环境、测试执行环境（测试负载机）

需求分析

系统性能需求，确认性能测试需求范围

测试策略

用什么手段来测试，如：采用jmeter模拟用户大并发操作，第三方不支持，采用挡板程序等

测试场景

如何组合业务场景进行性能测试

测试准备

测试前的的环境准备、数据准备

时间计划

相对合理估算测试资源及耗时，从而合理安排测试工作。一般是功能测试2.5倍

测试组织架构

测试相关干系人，明确不同干系人的职责。如：性能测试工程师通常做执行工作，文档记录员帮助整理交付文档

交付清单

性能测试计划、性能测试报告、性能测试脚本等交付物

系统风险

对测试过程中可能设计的风险，确定风险应对策略

环境搭建

性能测试环境搭建

参考_分布式环境搭建1

jemeter性能测试CICD——jenkins创建步骤(windows)

性能监控环境搭建

JMeter + Grafana + influxdb 性能监控平台搭建

脚本开发

数据准备

主数据准备
1. 并发用户账户，及对应的系统权限
2. 用户账户尽量越多越好
数据制作方法
1. 可以使用工具
2. 使用sql或者存储过程

场景设计

场景设计
1. 基准测试
  1. 主要用来验证测试环境，验证脚本正确性，得到系统的性能基准，为后续的测试执行提供参考。基准测试采用但业务场景、单用户的方式来执行脚本
2. 配置测试
  1. 帮助分析系统相关的性能配置，确保系统配置适合当前性能需求，一般场景为混合场景
3. 负载测试场景
  1. 负载测试的目的是帮助我们找出性能问题与风险，对系统进行定容量定量，分析系统性能变化趋势；为系统优化、性能调整提供数据支撑。
  2. 负载场景分为单场景与混合场景：单场景有利于分析系统性能问题，混合场景更贴近于用户实际使用习惯
4. 稳定性测试
  1. 验证当前软硬件环境下长时间运行一定的负载，确定系统在满足性能指标的前提下是否运行稳定，执行时采用混合场景

参考性能环境搭建_1 参考性能场景设计

场景实现
1. 只运行一个线程组实现基准测试场景
  1. 优势：参数化容易
  2. 劣势：脚本顺序执行，互相之间有影响；脚本复杂度高
2. 运行多个线程组实现配置测试场景
  1. 优势：多个线程互不干扰，独立设置，简单明了，易于维护
  2. 劣势：多个线程分开设置，参数化分开，登陆账户会有冲突
3. 负载场景设计
  1. 只运行一个线程组为例来设置负载场景

测试监控

测试执行

测试准入条件:
1. 检查网络环境
  1. 环境独立，不会对生产系统、外部系统等使用造成影响
  2. 环境可靠，不会对生产系统、外部系统等而影响测试结果
2. 检查测试数据
  1. 确保基础数据完整，能够支持性能测试脚本对业务功能的覆盖。
  2. 确保基础数据量，能够支撑性能测试脚本的参数化需求
  3. 确保存量数据，能顾对结果事假有意义的影响
3. 检查监控设备
  1. 监控工具是否准备完毕可用
4. 脚本检查
  1. 确认脚本能够模拟业务场景
  2. 确认甲苯无性能风险不影响测试结果
基准测试
配置测试
1. 测试场景
  1. JVM配置：jvm优化
  2. tomcat线程池配置：确定一个较合理的tomcat配置（负载均衡配置看这里）
  3. 数据库连接池配置：确定一个合理的连接池配置
  4. MySQL数据库的一些配置

参考1_数据库配置参考2_慢sql定位与优化参考3_读写分离、分表分区

测试执行、分析优化及调优
1. JVM配置测试
2. tomcat线程池配置测试
3. 数据库连接池配置测试
4. MySQL数据库优化配置
负载测试
1. 测试场景：单场景测试执行、分析及调优
稳定性测试
1. 测试场景：稳定性测试的目的是为了验证在当前软硬件环境下，长时间运行一定的负载，确定系统在瞒住性能指标的前提下是否运行稳定
  1. 稳定性测试的负载一般是1.5倍到2倍之间
2. 测试执行与分析
  1. 稳定性测试结果与测试指标的对比