---

前言

性能测试‌

  围绕性能测试的实施方针和流程要点展开描述，旨在提供参考和指导。帮助项目团队，明确测试目标和任务，合理制定计划，予以实施，定位及优化系统瓶颈，验证性能指标是否满足实际业务需求，合理评估资源需求，从而保证系统的高可用性和高性能。

---

一、性能测试介绍

1. 简介

  简介：通常是按照测试方案，使用自动化的测试工具（Jmeter，Loadrunner），通过特定方式，模拟多种正常、峰值以及异常负载条件来实施压力，得到各项性能指标，来保证系统的性能需求。

  原理：基于协议，用工具模拟实际操作（发送多个请求），收集数据，生成报告。

  目的：

• 评估系统的能力；
• 识别系统的弱点（瓶颈）；
• 检查系统的隐藏问题；
• 保证系统的稳定性和可靠性；
• 在保证用户体验感的同时节省资源；

性能测试一般在系统功能测试的中后期进行，性能测试是依赖于系统功能测试的。

性能测试一般要有独立的测试环境，并且测试环境要进行用户数据初始化。

前期的网络测试能在局域网中进行，网络影响小。

2. 流程

1. 分析用户的性能需求，确定性能指标；
2. 制定性能测试方案，设计性能测试的场景；
3. 根据性能测试场景准备资源和工具；
4. 执行脚本，实施测试；
5. 收集性能测试指标数据，与需求进行比对，性能调优，回归测试，生成测试报告；
6. 上线运维后实施日常点检，如发现性能问题，持续优化改善。

3. 指标

1. 业务指标
   用户访问请求分布、分析既有业务常用业务比例。

2. 性能指标
   事务级别：分为接口级、业务级、用户级

• 接口级：系统内多个应用间的调用记作多个事务。
• 业务级：前端一次交互记作一个事务。对应一个或多个接口级事务。
• 用户级：前端一次连贯的业务，例如支付，包含多次前端交互，对应多个业务级事务。

指标类型：容量指标（TPS）与时间指标（响应时间）

• 容量指标测算：基于业务指标/历史数据/行业经验测算，极端情况暴力测算。

• 时间指标测算：258原则（时间管理原则，根据任务的紧急和重要性来分配时间），电商标准，行业参考。

• 响应时间：指的是从客户端发送请求开始到收到服务的响应且看到响应内容为止的时间段，响应时间=网络传输时间+服务器处理时间+浏览器解析呈现时间；

• 用户数：在线数：在软件上不一定操作，并发数：在软件上且在操作（特定时间或时段）；

• 资源利用率：常见资源有CPU、内存、磁盘、网络带宽；

• 吞吐量：处理数据总量；

• 吞吐率：单位时间内处理的数据量；

• 点击量：点击的数量；

• 点击率：单位时间内点击的次数；

3. 资源指标

• 内存：使用率不高于80%
• CPU：平均使用率不高于80
• 磁盘：从磁盘读取数据所需平均时间小于0.010秒；从磁盘写入数据所需平均时间小于0.012秒
• 网络：服务器带宽小于网络带宽的80%

软件的性能是否达标是依据用户的性能需求。

4. 测试方案

1. 测试范围

1.1 需要测试的特性
包含用户级事务场景和接口级事务场景。

1.2 不需要测试的特性
低频复杂查询接口可以只验证单次执行耗时。

1.3 日次批处理特性
存在前后依赖，需合理排期保障时间窗口（时长验证）。

1.4 (准)实时批处理
执行频率高、批量发送等。

2. 准则
   启动、暂停、结束准则。

3. 业务模型&指标

3.1 业务场景模型
合理规划单业务场景内占比、及汇总场景中各场景占比。

业务关键点识别
从业务流程需求文档和架构设计入手，识别常见业务关键点，梳理关键业务路径、业务热点数据、业务实时峰值、高负载批处理。

3.2 业务指标及性能指标
合理评估测算业务指标及性能指标，并描述性能指标测算依据。

4. 资源与工具准备

架构环境、技术栈、工具、监控设计等。

4.1 资源评估及调整

• 性能测试环境的应用/部署架构与生产环境一致，资源规格相同；
• 架构及基础设施进行评估调整；过程中按需调整。

4.2 监控工具

• 性能监测（如，华为云APM）
• 日志服务（如，华为云LTS）

4.3 测试数据

• 基础数据
• 脚本用业务数据
• 容量用业务数据

4.4 测试工具及脚本

• 性能测试机器
• JMeter脚本（基准脚本、场景脚本）

5. 场景设计

5.1 基准场景
目的：系统摸底，初步摸排系统大致容量；先通过单接口基准场景，为后续多接口复杂场景打基础；解决单接口性能问题；确认容量场景所需要的压力参数。
内容：业务级和接口级基准场景。
关键点：连续激增的压力策略；健康的最大TPS及响应时间。

5.2 容量场景
目的：验证真实的业务压力和比例下，系统能否支撑要求。
内容：用户级、通用混合、业务峰值混合、批处理容量场景。
关键点：连续激增的压力策略；业务模型的比例符合生产真实业务场景；动态参数的规则和数量级符合生产真实业务场景；铺底数据的数据量符合生产未来三年的数据量。

5.3 稳定场景
目的：验证在一个运维周期内，系统能否平稳运行并满足性能要求。

5.4 异常场景
目的：验证系统在各种异常情况下的表现是否符合预期，例如TPS合理下降，快速自愈等。

6. 测试计划
   执行/配合人员体制及计划日程。

5. 性能评估

1. TPS和响应时间
   通过指标数据和图形，判断瓶颈。

2. 递增策略
   合理递增线程才能把服务的真实能力验证出来，避免人为创造的瓶颈。

3. 性能衰减
   每线程的TPS开始变少，即可说明性能瓶颈已经出现了。

4. 响应时间拆分
   通过全链路监控、瀑布图等手段逐段分解耗时，或者绕过某个节点直接测试上游接口。

5. 构建决策树
   发现资源瓶颈后，通过定向监控，逐层向下分解，判断性能问题真因。

6. 场景对比
   直接调整测试对象应用资源（规格/实例数），观察性能是否发生变化。

6. 常见性能问题及解决对策

1.慢查询

• 优化SQL，保证查询时可以使用索引;
• 对于数据量大的表，进行分表;
• 引入缓存，减少查询数据库的次数。

2.程序复杂

• 优化代码，降低代码复杂度;
• 将大接口拆分成多个小接口。

3.测试数据准备不充分

• 通过数据迁移导入历史数据;
• 无法迁移导入的，自行创建或从预生产环境导入，补全测试数据。

附录1：容量指标（TPS）与时间指标（响应时间）
每秒事务数（TPS） = 1000（millisecond/second） ÷ 响应时间（millisecond/T）× 并发用户数

附录2：容量指标测算
1.基于业务指标测算
平均在线用户Avg. Session = 登录用户数Login Session × 会话平均长度Session Long ÷ 考察时间段长度Time。
最大在线用户数Max. Session = 平均在线用户 + 3 × (平均在线用户的平方根)。（假设用户会话的产生符合泊松分布）
并发度Concurrency = ∑(功能n的使用人数 × 平均使用次数) ÷ 平均在线用户Avg. Session。（秒级并发度一般为1%~5% 一般时间段取小点，使得平均使用次数=1）
每秒事务数Transaction Per Second = 最大在线用户数Max. Session × 每秒并发度Concurrency。

2.基于历史数据测算
以客户订单录入为例
按订单录入时间（格式化为分钟）对过去三年客户订单录入单数进行分组count，取最大值。
每分钟最大录入单数 × 80%÷ (60×20%) = 每秒事务数。

3.基于行业经验测算
中小企业TPS约为50~1千笔/秒
银行TPS值1千~5万笔/秒
淘宝TPS值为3万~30万笔/秒

4.极端情况暴力测算
低频业务
根据前面的算法，低频业务TPS或低于1。如果我们预期的事务响应时间低于1秒且有可能在常规业务峰值时发生，则应假设其有可能与高频业务的峰值在同一秒内发生，即容量场景下至少维持1TPS。

秒杀业务
根据以往活动运营经验，秒杀业务最高可达550个并发请求，如预期事务响应时间低于1秒，则秒杀活动路径上、秒杀开始前的最后一个接口最高要考虑达到550TPS。

附录3：时间指标测算

测算依据	具体内容
258原则	2秒以内‌：用户会感觉系统的响应非常快。‌2-5秒之间‌：用户会感觉系统的响应速度还可以。‌5-8秒以内‌：用户会感觉系统的响应速度较慢，但仍可接受。‌超过8秒‌：用户会感觉系统响应非常慢，可能会选择离开或发起第二次请求‌。
电商标准	0.1 秒是最理想的响应时间，因为 0.1 秒人是无感知的；1 秒是较好的的响应时间，会让人感觉到停顿，但是也是可接受的；4 秒是业务可以接受的上限，因为到了 4 秒的时候，客户流失率明显增加了；10 秒是完全不可接受的，因为已经导致企业的经济入不敷出了。
行业参考	参考同类头部产品的响应时间。头部产品往往具备了一定的社会影响力，会对用户关于响应速度的预期产生潜移默化的影响。

二、测试工具

1. Jmeter简介

Jmeter是基于Java语言开发的开源测试工具：轻量级测试工具（与LoadRunner比较）；
支持多种协议（web协议、webService、通过JDBC连接数据库、FTP等）。

1. 常用场景：

• 压力测试：常用于web系统，可以录制教本、参数化、断言、关联以及操作数据库
• 接口测试：http脚本（get，post），加cookie，加header、加权限认证以及上传文件等

2. Jmeter的特性优点：

• 免费的开源软件；
• 简单且直观的图形用户界面；
• Jmeter中负载和性能测试许多不同的服务器类型（HTTP、HTTPS，SOAP等）
• 独立于平台的工具；
• 拥有完整的Swing和轻量级组件支持；
• 拥有完整的多线程框架；
• 高度可拓展；
• 用于执行应用程序的自动化测试和功能测试。

3. Jmeter的组成部分：

• 负载发生器：用于产生负载（发送请求），多进程（线程）模拟用户行为；
• 用户运行器：脚本运行的引擎，附加在进程或线程之上的；
• 资源生成器：生成测试过程中服务器的资源数据（收集测试数据）；
• 报表生成器：根据测试中获取的数据生成报表，提供可视化的数据显示方式；

4. Jmeter常见概念：

• 测试计划：描述一个性能测试包含本次测试的所有相关功能；
• 线程组：一般一个线程组可看作一个虚拟用户组，其中每个线程为一个虚拟用户；
• 取样器：测试对象以及测试内容，是基于线程的，Jmeter支持多种取样（Jmeter支持多种协议）；
• 监听器：对测试结果进行处理和可视化展示的一系列组件，常见的有图形结果、查看结果树，聚合报告、表格结果等；
• 控制器：驱动处理一个测试，有逻辑控制器和取样控制器；
• 配置元件：用于提供对静态数据配置的支持；
• 定时器：用于在操作之间设置等待时间；
• QPS：每秒请求数（防止恶意刷取，增加项目负载）
• 断言：用于检查测试中得到的响应数据是否符合预期；
• 前置处理器：用于在实际请求发出之前对即将发出的请求进行特殊处理；
• 后置处理器：用于对Sampler发出请求后得到的服务器响应进行处理，一般用于提取响应中的特定数据。

2. Jmeter常见测试框架

测试计划：只要启动Jmeter就会默认生成一个测试计划，这个计划包含了本次测试的相关功能。

线程（用户）：

• 线程组：主线程组，核心，需要进行性能测试的内容（不可省略）；
• setup 线程组：初始化的内容（可省略），若存在则最先运行；
• teardown线程组：收尾的内容（可省略）；

线程属性：

• 线程数（用户数）
• Ramp-up: 虚拟用户启动时间，用户开始发请求的时间；
• 循环次数：具体的次数，或者永远（必须加调度器有持续时间，否则无法结束），当同时设置了次数并且添加调度器时间，以设置次数为准。

取样器：测试对象及测试内容，基于线程的，即要模拟的动作。常用http请求：协议、服务器IP、端口号、方法、url地址、编码方式

监听器：用来查看测试结果，图形化显示，常用的有查看结果树（同时查看请求和响应信息，绿色表示测试地址通常，不代表测试case成功，红色代表异常）、聚合报告（汇总请求发送情况）、图形结果（图形化展示）、表格形式展示（可以查看启动时间）。

Jmeter支持多个请求同时发送，支持多协议、多请求同时并发。

在聚合报告中，时间是以ms为单位的；

在汇总报告中，标准偏差体现稳定性的，表示离散程度，越小约好。

三、Jmeter录制脚本

1. 基本

1. http代理服务器设置（在Jmeter中完成）；

添加http代理服务器（脚本记录器），再添加线程组，将目标控制器选为如图所示，端口默认是8888：

2. 浏览器的设置；

在internet选项的连接中将局域网设置为如下：

在Jmeter的脚本记录器中启动，之后在浏览器中进行相关操作，就会录制：

2. 增强

tps：每秒事务处理量（每秒处理的消息数），表达系统处理能力的性能指标；

集合点：一般用来测试瞬间的并发能力；

思考时间：一般是用来模拟用户的真实行为（用户在页面的停留时间），让每个用户的操作有一定差异，有了思考时间会减少服务器堆积的情景时间；

事务通过控制器来体现。

在Jmeter中通过定时器来实现集合点和思考时间。

集合点使用同步定时器，能够实现真正的并发（先到的线程在集合点等后到的，等到期了就一起走），适用场景：秒杀、限购、抢票等。

注意：设置集合的模拟虚拟用户数不能大于线程数，否则会一直等待。

集合虚拟用户数小于线程组中的用户数，表示分批次集合，最后一批有可能不够集合的数目，必须要设置等待时间。

集合虚拟用户数等于线程组中的用户数，表示所有虚拟用户必须全部到达集合点，才一起开始下一个动作。如果模拟用户数量设置为0表示全部用户都参与集合。超时时间设置为0，当最后一批无法达到集合数量时将一直等待，等待到系统的最大值才释放。

对于思考时间常用的是固定计时器和高斯随机定时器；

固定计时器：固定停留（间隔），上下请求发出的时间间隔是固定的；

高斯随即定时器：随机停留（间隔)，每个虚拟在请求前都是按照随机事件间隔停留。

注意：在设置定时器时，固定偏移量和随机偏移量不要同时设置，否则以固定偏移量为准。

3. 脚本参数化

参数化的作用：让数据变得不一样，模拟每个线程（虚拟用户）的数据不一样，就进行参数化。

参数化实现的步骤：

1. 判断哪些参数需要实现参数化；
2. 设置参数：新建变量（定义名称），准备参数的值；
3. 用参数代替需要参数化的数据（替换形式：${xx})；

用户定义的变量：自定义变量，适用于ip或者欢迎词等只有一个参数值的数据，但是这个值可以变化；

配置原件 -> 用户定义的变量。

前置处理器中的用户参数：在请求发出之前，对请求的参数进行处理；

迭代：需要执行验证的操作再执行一次。

线程数表示使用的用户数；

特点：指定了用户和参数的关系，适用于数量比较少的参数化操作，用户和参数有特定关系。

配置原件中的CSV数据文件设置：必须先准备好参数文件是.csv文件格式或者.bat文件格式。

使用范围：大批量用户参数，并且参数值有一定规律（利用excel表格来准备参数文件）。

当设置的用户参数数量少于虚拟用户数时，就会循环重复使用参数。

将excel表格转换为dat格式时，先保存为txt文本格式，再保存为dat格式,并且在bat文件中键和值之间用拥吻逗号分隔。

Tools中的函数助手：使用其中的CSVRead函数。

前提：准备好csv参数文件，注意不要加列表名（参数标题）。

设置csv文件的读取列号从0开始。

作用域和执行顺序：

作用范围：处于不同的级别，受控范围和可控制的范围是不一样的，特别是定时器。
当一个定时器只应用于一个请求中，就将定时器作为请求的子节点加入；
当一个定时器同时应用于多个请求时，就将请求跟定时器放在同一个级别。

在Jmeter中，即使集合点放在请求子节点中仍可以实现同步。
在同一个作用域下，执行的顺序如下：
配置原件 -> 前置处理器 -> 定时器 -> 取样器 -> 后置处理器 -> 断言 -> 监听器

4. 断言

作用：用于就检查测试中得到的响应数据是否符合预期，用于保证性能测试过程中的数据交互与预期一致，主要用于做调试，在进行压力测试时，断言可以禁用。

目的：在request的返回层面加一层判断机制。

实现过程：

1. 在请求下添加断言（一个请求可以添加多个断言），请求不同，添加的断言不同；
2. 添加一个断言结果的监听器，通过断言结果可以看到是否通过断言，若通过，断言结果会打印一次请求的名称，一个请求的所有断言都通过了才算请求成功。

Jmeter中的断言和LoadRunner中的检查点是一致的。

常用断言：

响应断言：判断返回的内容是否满足预期；
作用对象：响应报文中的所有对象（响应代码、响应文本、url等等）

在响应断言下添加断言结果：

大小断言（size断言）：用来判断返回内容的大小；
作用对象：返回信息，响应报文，添加size断言，必须指定大小和长度

断言持续时间：判断服务器的响应时间是否达到预期；
作用对象：服务器；

BeanShell断言：与Java语言相结合的断言，用于验证脚本。

5. 关联

在测试过程中需要引用前面的数据，但是数据是经常发生变化的，那么要获取使用这些数据，就需要使用关联。

例如：第二个请求需要第一个请求返回数据的结果作为自己的输入数据，此时就需要使用关联将这两个数据对接起来。
具体实现步骤：在第一个请求之后添加后置处理器；
后置处理器的作用：在请求结束之后，处理响应结果的特定数据，提取需要的数据。

在关联的过程中，会通常使用到正则表达式提取器。

对于Jmeter的参数说明：
引用名称：下一个请求要引用的参数名称，比如填写name时，就需要用${name}进行引用；

正则表达式：
()：要提取的内容
.：匹配任意单个字符串
*: 匹配（之前的符号）0次或多次
+：匹配（+之前的符号）1次或多次
?：不要太贪婪，在找到第一个匹配项后停止。
.:匹配连续0个/多个字符
.+:匹配连续1个/多个字符
\ :转义，.表示匹配字符.本身

模板：表示取哪几个括号中的值
若模板为： 0 0 0，则为整个表达式匹配到的内容（这里为整个响应报文）
若模板为： 1 1 1，则对应正则表达式中的第一个()所匹配的内容
若模板为： 2 2 2，则对应正则表达式中的第二个()所匹配的内容

匹配数字：0代表随机取值，1代表全部取值，通常情况下使用0；

缺省值：如果参数没有取到值，就要给赋给默认值。

常用的正则表达式操作符：

后置处理器中的正则表达式：

6. JDBC请求

使用Jmeter通过jdbc请求来操作数据库。

准备工作：准备数据库环境（创建表、准备数据）

实现步骤：

1、添加jar包：

• 直接将jar包复制到jmeter的lib目录（mysql推荐使用）
• 通过Test Plan浏览加载（oracle推荐使用）

2、建立连接信息：在测试计划中，点击添加配置原件 -> JDBC Connection Configuration

3、添加JDBC请求：

四、分布式测试

使用场景：在使用Jmeter进行性能测试时，对于高频大并发的数据单台电脑可能难以支持就需要进行分布式压测，即对客户端的压力进行分摊，也叫负载均衡。

原理：

1. 在使用Jmeter进行测试时，选择其中一台作为主控调度机，其余作为执行机；
2. 执行时，主控机器会把每个脚本发送到每台执行机器上，执行机器拿到脚本就开始执行，执行机器不需要启动GUI界面；
3. 执行结束后，执行机器会把结果回传给主机，主机收集所有的执行机器的测试数据进行汇总；

主控机器：生成脚本，调试脚本，汇总数据。
执行机器：运行脚本，回传数据给主控数据。

具体实现步骤：

1、执行机器的设置：

1. 在执行机上安装JDK和Jmeter（执行机和主控机的版本必须保持一致）；
2. 添加环境变量；
3. 在启动bin目录下的：jmeter-server.bat;

易出现问题：提示无法启动，请按任意键/文件找不到。
解决方案：进入apache-jmeter-5.2\bin\jmeter.properties文件，将server.rmi.ssl.disable设置为true，重新启动jmeter-server.bat，查看命令行窗口显示则表示启动成功。

2、主控机器设置：

1. 准备测试脚本；
2. 修改属性配置文件：jmeter.properties 文件，修改IP和端口号，在文件中查找remote_hosts，原默认信息是127.0.0.1表示本机，修改host信息:执行机器IP:端口号,执行机器2号IP:端口号，默认端口号是1099，执行时，确保1099未被占用（端口号可以进行自定义）
3. 重新启动jmeter.bat;
4. 在jmeter中点击运行，再点击远程启动，即可开启分布式测试。

五、性能测试报告

大纲：目的、项目简介、测试过程、测试结果以及项目总结。

内容：概述、测试环境、测试目标（性能指标）、测试方法、测试数据分析、测试结论。

注意：在测试数据分析的过程中，必须按照不同的测试场景进行描述。

利用Jmeter生成html的测试报告：

方法一：

选择添加监听器中的聚合报告，将聚合报告输出到指定的csv文件，在jmeter的工具中选择Generate HTML report；

html报告展示：

方法二：在命令行窗口输入命令来实现：

操作命令：jmeter -n -t 脚本的绝对路径.jmx -l 测试报告的文件名称.csv -e -o html报告的目录路径。

注意：报告的目录文件必须为空目录，测试报告文件也不能有数据，必须是空文件或者是不存在的文件。

---

本文的引用仅限自我学习如有侵权，请联系作者删除。
参考知识
软件测试——性能测试

---