性能测试概念 性能测试指标 性能测试分类 性能测试流程 性能测试吞吐量 TPS QPS

一、性能测试基础理论

1.1 为什么要做性能测试

• 业务需求

• 招聘需求

1.2 什么是性能测试

• 概念： 测试软件性能

  1. 后端服务成-响应时间
  2. 服务器硬件资源（CPU、内存、磁盘）
  3. 测试中间件应用服务器、系统架构、数据库
  

1.3 重要性：

说明：软件客流大/使用量 多的话，必须进行能测试；

1.4 性能测试目的：

• 评估当前系统的承载能力
• 寻找瓶颈、进行优化

1.5 性能与功能焦点：

• 功能：重点在于软件产品功能是否符合需求规格（焦点：功能的正向、逆向）
• 性能：重点在于软件产品业务场景是否能正确使用（时间、空间）

---

二、性能测试常用分类

• 负载测试
• 压力测试
• 并发测试
• 稳定性测试

提示：负载测试、压力测试、并发测试之前都会采用基准策略（单个用于跑场景，获取指标数据作为后续参考目标值）

2.1 负载测试

说明：逐步向服务器增加负载，观察性能发生变化，关注：在满足系统指标情况下，最多支持的负载量

负载：向服务器发送请求

2.2 压力测试

说明： 逐步向服务器增加负载，观察性能发生变化，关注：承受多少负载量情况下，系统处于 失效状态

2.3 并发测试

说明 : 多个用户同时访问统一个应用（同一个软件），观察系统性能指标是否满足需求

2.4 稳定性测试

说明： 给服务器增加一定的负载（如：CPU长时间保存在70%-90%的使用率），运行一段时间，观察系统是否稳定。

提示： 稳定性测试一般采用3个时间段：

1. 24小时
2. 3*24小时
3. 7*24小时

---

三、常用性能指标

指标： 经过某种运算，来表衡量某种性能统称

常用指标类型：

• 吞吐量
• 并发数
• 响应时间
• 点击数
• 资源利用率
• 错误率
• TPS
• QPS

---

1. 吞吐量：

说明：单位时间内服务器处理的请求数量；
重点：请求数/秒
扩展：
	业务角度：业务数/天
	网络角度：字节数/小时
	TPS/QPS归属于吞吐量，区别在于QPS/TPS衡量具体的业务性能指标

2. 并发数：

说明：多用户同时访问同一应用的数量
扩展：
	1. 并发数：同一时间向服务器发送请求的数量
	2. 在线用户数：系统目前在线用的用户数
	3. 注册用户数：总注册用户数

3. 响应时间：

说明：从客户端发送请求开始，到客户端接收到服务器响应数据为止，整个过程所消耗的时间为：响应时间
响应：
	1. 响应时间=T1+...+T7 [接口响应时间]
	2. 响应时间=T1+...T8[web项目]

4. 点击数：

说明：统计打开页面是服务器响应状态码数量
提示：
	1. 点击数并不是打开一个页面点击数就是1，或者点击一个按钮，就是一个点击数，而是统计打开页面数或操作页面是向服务器发送的请求数（包含：图片、JS、iframe...）
	2. 点击数只有web项目有，并且是web项目中很重要的一个主要；

5. 资源使用率:

说明：资源使用率指的服务器硬件资源
参考：
	1. CPU: 75%-85% 之间
	2. 内存：80%以内
	3. 磁盘：
			1. 磁盘空间剩余10%
			2. 磁盘读写时间比

6. 错误率：

说明：错误次数/总请求次数*100%
提示：
	1. 一个好的系统，错误率应该控制在千分之五以内
	2. 错误率应该是由超时引起

7. TPS：

说明：每秒事务数
事务：
	1. 代码角度：一行代码或一段代码的集合
	2. 业务角度：多个操作的集合
提示：TPS归属吞吐量

8. QPS：

说明：每秒查询数
提示：
	1. 主要衡量web项目，测试服务器每秒能不能出来指定的请求数；
	2. QPS归属吞吐量

---

四、性能测试流程

1. 需求分析
2. 测试计划
3. 编写测试用例（根据性能测试工具来定）
4. 编写脚本
5. 搭建场景
6. 执行场景
7. 性能调优
8. 测试报告

4.1 需求分析

说明：把客户实际的需求搞清楚
如：
	1. 20000人使用此系统，登录时间小于3秒； 需求：请求峰值（请求数/秒）
	2. 把软件所有功能进行并发测试； 需求：客户主要使用模块或功能（修改、配置、帮助...）

4.2 测试计划

1. 项目背景
2. 测试人员安排
3. 时间安排
4. 测试工具
5. 测试策略
6. 风险控制
7. 测试目标

4.3 测试用例

重点：
	1. 测试场景搭建策略（根据测试工具来定）
	2. 测试指标值
扩展：
	只要会性能测试工具，就能把用例正确实施出来，就是一条好的性能测试用例；

4.4 脚本编写

说明：根据场景策略，把脚本分开录制或分开编写；
注意：
	1. 注意代码冗余；
	2. 脚本的参数化等处理；

4.5 场景搭建

说明：根据用例场景策略，完整执行搭建出来即可；
注意：
	1. 执行机器必须能支持并发数
	2. 注意脚本依赖关系
	3. 场景内相关设置（集合点）

4.6 运行场景

注意：
	1. 执行机承载不了指定的虚拟用户数
	2. 没有预热
	3. 运行次数过少
	4. 场景没有正确搭建

4.7 系统调优

调优人员：（1. 开发人员 2. 网络管理员 3. 数据管理员 4.....）

调优原则：由易到难
	1. 硬件资源
	2. 网络
	3. 应用服务器、数据库配置
	4. 后台代码、数据库脚本
	5. 系统架构

4.8 性能报告

说明：无论使用哪款工具做性能测试，都会产出一份报告，在当前基础之上保留要的图标和数据，去掉不关注的数据
覆盖内容：
	1. 测试用例覆盖情况
	2. 用例执行过程中出现的问题及解决方法
	3. 性能瓶颈在哪，如何调优
	4. 总结经验教训

---

五、性能测试工具

5.1 工具：

1. Loadrunner
2. jmeter

1. Loadrunner:

• 缺点：

  • 收费
  • 体积庞大
  • 无法定制功能

• 优点：

  • 支持多协议
  • 报表分析能力
  • 支持ip欺骗

2. Jmeter:

• 缺点：

  • 不支持ip欺骗
  • 相比Loadrunner报表精度欠缺

• 优点：

  • 免费、开源
  • 小巧
  • 支持多协议
  • 功能强大 易上手

---