Jmeter性能测试的标准流程

性能测试必要性评估

● 常见关键评估项

监管单位要求性能报告

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

首次投产的大型系统

核心数据库、软硬件升级

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

● 单版本单业务评估权重

是否平台核心位置

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

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

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

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

性能测试需求分析

● 业务层面

用户大量使用的功能

日常占比80%以上的业务

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

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

● 项目层面

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

逻辑复杂、关键的业务

可能消耗大量资源的业务

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

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

● 性能测试需求评审

● 可测性

可搭建相对真实的环境

● 一致性

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

● 正确性

性能测试用例设计

● 测试模型建模

● 场景用例设计

● 分类

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

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

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

综合业务压力测试

综合业务负载测试

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

● 线程数计算

● 场景用例

随机购买并发量基准测试场景用例

● 脚本用例设计

随机购买商品脚本用例

测试数据构造

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

录制脚本导出为jmx

● Jmeter迭代生成账号

${username}变量要导入CSV

测试脚本开发

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

● Jmeter配置

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

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

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

● Fiddler的使用

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

添加->Sample->HTTP请求

场景设计与实现

● 并发线程数与调度器配置

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

● 监听结果

用例执行

● 环境

注意客户端性能

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

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

● 记录服务器配置

测试服务端配置：

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

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

● 测试客户端配置：

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

● 运行任务

结果分析

● 响应时间

用户登录响应时间目标指标≤5秒，结合jmeter执行结果后的聚合报告分析

● 业务成功率（看断言）

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

● 并发数数据

● CPU与内存数据

● 数据库情况

● 结果统计

性能调优

● 性能问题表现特征

响应时间平稳但较长

响应时间逐步变长

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

数据积累导致锁定

稳定性差

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

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

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

 

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取