Jmeter性能测试的标准流程

1、性能测试必要性评估

 

常见关键评估项

监管单位要求性能报告

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

首次投产的大型系统

核心数据库、软硬件升级

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

单版本单业务评估权重

是否平台核心位置

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

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

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

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

---

2. 性能测试需求分析

业务层面

用户大量使用的功能

日常占比80%以上的业务

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

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

项目层面

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

逻辑复杂、关键的业务

可能消耗大量资源的业务

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

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

性能测试需求评审

可测性

可搭建相对真实的环境

一致性

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

正确性

---

3.性能测试用例设计

测试模型建模

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

打开首页

输入用户名、密码登陆

退出系统

场景用例设计

分类

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

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

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

综合业务压力测试

综合业务负载测试

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

线程数计算

场景用例

脚本用例设计

4.测试数据构造

脚本开发创建用户注册脚本

录制脚本导出为jmx

Jmeter迭代生成账号

${username}变量要导入CSV

5. 测试脚本开发

脚本开发录制登陆与购买脚本

Jmeter配置

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

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

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

Fiddler的使用

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

添加->Sample->HTTP请求

6.场景设计与实现

并发线程数与调度器配置

如果是脚本开发录制的脚本，循环设置在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.性能调优

性能问题表现特征

响应时间平稳但较长

响应时间逐步变长

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

数据积累导致锁定

稳定性差

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

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

我之前一个人，到处找学习资料，吃尽了苦头，还遇到不少坑，所以我把我整理的学习资料都归类整理好。环境对于一个人的成长很重要，我们一起加油，互相鼓励，从此不再孤单，所以小编决定，不能再低调了，毕竟实力不允许啊！如果有小伙伴想提升自己，未雨绸缪，为自己的未来提前规划，关注我，2021最新的软件测试电子版书籍、视频、还可以找我一起交流技术。更多软件测试资源分享微信公众号：【程序员阿沐】软件测试技术交流群：810119819

逆水行舟，不进则退！共勉！软件测试与你同行！点赞是最大的支持！