性能测试_Day_02（集合点、性能指标、性能测试流程）

性能测试理论

集合点

集合点是为了增加【瞬间并发压力】的一种【机制】，在脚本中增加一个标记，【所有虚拟用户】执行到标记处会进行【等待】，等所有用户都到达后，再同时继续执行下一步操作。

优点：对服务器来说，会产生一种瞬间高并发
缺点：对服务器来说，平均压力会降低

什么时候需要加集合点呢？

根据业务来选择，如果业务场景是瞬间高并发类型的，如抢购、秒杀等，需要加集合点；

其他的场景都不需要加，一般加了集合点后，就不使用TPS来衡量系统性能
集合点功能要慎重选择，因为加了集合点后，系统的平均压力会降低

性能监控指标

操作系统级别监控

CPU使用率、内存使用率、网络IO（input/output）、磁盘（read/write/util）

中间件监控

连接数、长短连接、使用内存

应用层监控

线程状态、JVM参数、GC频率、锁

数据库监控

连接数、锁、缓存、内存、SQL效率

性能测试流程

1. 需求调研
2. 测试计划
3. 环境搭建
4. 数据准备
5. 测试脚本
6. 压测执行
7. 调优回归
8. 测试报告

性能测试流程-需求调研

1. 项目背景
2. 测试范围 (合理性)
3. 业务逻辑 & 数据流向 (登录)
4. 系统架构 (b/cs)
5. 配置信息 (软硬)
6. 测试数据量（量级要一致） (字典)
7. 外部依赖
8. 系统使用场景，业务比例
9. 日常业务量
10. 预期指标
11. 上线时间

性能测试流程-测试计划

1. 项目描述
2. 业务模型及性能指标

平均TPS = 小时交易量/3600秒*服务时段8小时

TPS = 1W订单 * 80% / (8小时运行时间 * 3600 * 20%)

3. 测试环境说明
4. 测试资源
5. 测试方法以及场景设计原则
6. 基准测试（比如1个用户数的TPS）
7. 单交易负载测试(单个业务，用于排查定位的标准）
8. 混合场景测试（登录，查询，下单等）
9. 高可用性测试(服务重启、降pod数)
10. 异常场景测试（有点像容灾测试）
11. 稳定性测试（混合和稳定，并发用户不一样）
12. 其他特殊场景
13. 测试进度安排及测试准则

性能测试流程-环境搭建

1. 测试机器硬件配置尽量和线上一致
2. 系统版本与线上一致
3. 测试环境部署线上最小单元模块
4. 应用、中间件、数据库配置要与线上一致
5. 其他特殊配置

性能测试流程-数据构造

1. 业务接口

• 适合数据表关系复杂
• 优点：数据完整性比较好

2. 存储过程

• 适合表数量少，简单
• 优点：速度最快

3. 脚本导入

• 适合数据逻辑复杂
• 自由度比较高

4. 数据量级

• 测试数据
• 基础数据

性能测试流程-脚本编写

1. 选择协议
2. 选择工具
3. 参数化
4. 关联
5. 检查点
6. 事务判断

性能测试流程-压测执行

1. 分布式执行
2. 监控
   – Linux
   – JVM
   – 数据库
3. 收集测试结果
4. 数据分析
5. 瓶颈定位

性能测试流程-调优回归

1. 性能调优需要整个团队完成
2. 反复尝试
3. 回归验证
4. 监控工具
5. 全链路排查
6. 日志分析
7. 模块隔离

性能测试流程-测试报告

1. 概述
2. 测试环境
3. 结果与分析
4. 调优说明
5. 项目时间表
6. 结论
7. 建议

性能测试工具

Loadrunner（功能强大、重量级、商业软件）
Jmeter（小巧灵活、轻量级、开源）
Ngrinder（ 开源压测平台）
locust（Python开源框架）

现状和趋势

性能测试自动化、平台化
测试工具多样性、开源、二次开发
在高并发下验证功能正确性
线上线下相结合，线上发现问题，线下调优