关于jmeter性能测试的一些笔记

1.性能测试必要性评估

常见关键评估项

监管单位要求性能报告

涉及财产、生命安全的系统

首次投产的大型系统

核心数据库、软硬件升级

用户量、业务量增长30%以上

单版本单业务评估权重

是否平台核心位置

是否存在部署方式调整或优化

是否增加了性能风险较高的调整

是否存在客户要求必须测试的业务流程

是否涉及多个功能缺陷的修复且流程发生较大变化

2. 性能测试需求分析

业务层面

用户大量使用的功能

日常占比80%以上的业务

特殊交易日或峰值80%的业务

核心业务发生流程重大调整的业务

项目层面

曾经测试过性能调整了架构的业务

逻辑复杂、关键的业务

可能消耗大量资源的业务

与外部系统存在接口调用、大量交互的业务

调用第三方业务组件且逻辑复杂的业务

性能测试需求评审

可测性

可搭建相对真实的环境

一致性

用户需求、生产需求（真实性）、运营需求（规划未来发展要求）

正确性

3.性能测试用例设计

测试模型建模

举例：登陆业务操作流程（思维导图）

打开首页

输入用户名、密码登陆

退出系统

场景用例设计

分类

单业务基准测试：是否满足系统设计和用户期望的性能指标

单业务压力测试：最大负载下，持续服务的时长

单业务负载测试：系统能够承受的最大负载

综合业务压力测试

综合业务负载测试

综合业务稳定性：核心业务基准负载下长时间运行系统稳定服务的能力

线程数计算

场景用例

 

 

脚本用例设计

 

 

4.测试数据构造

BadBoy创建用户注册脚本

录制脚本导出为jmx

Jmeter迭代生成账号

${username}变量要导入CSV

 

 

 

 

5. 测试脚本开发

BadBoy录制登陆与购买脚本

Jmeter配置

添加->定时器->固定定时器：设置间隔时间

添加->断言->响应断言：检查登陆成功

 

 

添加->监听器->查看结果树/聚合报告

Fiddler的使用

若BadBoy未录制到商品添加到购物的请求，需要用Fiddler抓包手动添加

 

 

添加->Sample->HTTP请求

 

 

6.场景设计与实现

并发线程数与调度器配置

 

 

如果是Badboy录制的脚本，循环设置在Step1设置 永远

监听结果

 

 

资源监听器gc-perfMon Metrice Collector

下载：

地址https://jmeter-plugins.org/downloads/all/，下载plugins-manager.jar                   

把给文件放到apache-jmeter/lib/ext目录下

增加插件：

选择，重启

 

 

添加监听器：

重启后可以 添加-监听器-@gc-perfMon Metrice Collector

增加CPU、内存等指标后保存

 

 

7. 用例执行

环境

注意客户端性能

注意服务器最好能够独占测试

注意时间的选择，测试环境/生产环境最好是少人使用的时候

记录服务器配置

测试服务端配置：

应用服务器-机型-台数-CPU-内存-IP

数据库服务器-机型-台数-CPU-内存-IP

测试客户端配置：

客户端-机型-台数-CPU-内存-IP

运行任务

8.结果分析

响应时间

 

 

Apdex

 

 

业务成功率（看断言）

测试脚本中设置了断言，判断用户登录后是否出现“登录成功”字样，并设定“断言结果”查看器，通过查看断言结果，全部通过表示业务成功率100%

 

 

并发数

CPU与内存

 

 

数据库

 

 

结果统计

 

 

9.性能调优

性能问题表现特征

响应时间平稳但较长

响应时间逐步变长

响应时间随着负载变化而变化

数据积累导致锁定

稳定性差

响应时间长，系统越来越慢，出现业务错误，通常原因

物理内存资源不足；内存泄露；资源争用；外部系统交互；业务失败频繁重启，无终止状态；中间件配置不合理，数据库连接设置不合理；进程/线程设计错误