浅谈Jmeter性能测试流程

不管是Loadrunner还是jmeter进行性能测试，测试流程基本上都是一样的，限制以Jmeter为例分析测试流程：

一、性能测试需求分析

一般而言，被测对象的性能需求，会在用户需求规格说明说中给出，比如单位时间内的访问量达到多少、业务响应时间不超过多少、业务成功率不低于多少、硬件资源消耗应该在一个合理的范围内等，性能指标应以量化数据给出，对于一个规范的产品，产品团队会给出如下的性能要求：

如果产品团队并没有指明性能测试需求，或者只给出表述字面意义上的需求，如：系统的TPS需要到300以上，单笔交易时间不超过3秒，那么测试工程师如何提前量化的指标呢？

需要结合业务需求和系统本身特性进一步分解和提取显性和隐性的需求，可以从以下两个用户方法进行确定：

1、业务用户

• 用户频繁使用，且存在大量用户频繁使用的业务流程
• 交易占比高，日常占比在80%以上甚至更高的业务流程
• 特殊交易日或峰值交易占比80%以上甚至更高的业务流程
• 性能较差且做过调整的业务流程
• 特殊业务场景
• 核心业务发送较大流程调整的业务流程

以上为业务用户层面可能需要的性能需求点，实际项目中可能会向终端用户进行调研。

2、项目团队（业务系统）

• 曾经测试过性能后调整了架构设计的业务
• 逻辑复杂、关键的业务
• 可能消耗大量资源的业务
• 与外部系统存在接口调用，且有大量数据交互的业务
• 调用第三方业务组件，逻辑复杂业务

以上为项目开发角度可能需要的性能需求点，性能测试工程师需要与开发团队密切配合、深入了解被测对象。

3、案例分析

通过分析，我们以网上商城性能需求指标为例，得到下面数据：

二、测试用例设计及测试数据准备

1、测试用例设计

为了真实地反映被测对象可能存在的性能问题，需要尽可能地模拟被测对象可能发生瓶颈的业务场景，测试需求分析过程中已经确定了业务类型，在此需要设计如下性能测试场景：

2、测试数据准备

以本次测试为例，2小时内5万用户登录，意味着需要有50000个可用账户（尽量多准备一些，可以为60000），可以直接在数据库中添加，但要求对数据库结构相对熟悉；也可以使用Jmeter录制注册脚本，使用3个线程，循环2000次即可。

构造好测试数据后，需要对数据库进行备份，便于后期进行回归测试，可以使用NaviCat进行数据备份。

三、性能测试脚本开发

• 根据登录业务模型，利用BadBoy录制用户登录过程，生成Jmeter脚本
• 登录用户名进行参数化
• 设置定时器：参考测试用例输入信息5s、登录成功等待返回3s、退出成功等待返回
• 为登录成功页面设置断言，失败则提示信息，成功不提示
• 添加查看结果树、聚合报告等，实时查看脚本运行情况

四、场景设计及资源监控

1、场景设计

以登录业务为例子，本次测试的目的在于验证平台是否能支持100个用户的并发登录，无需考虑持续时间，根据对应的场景测试用例，设置线程组数据，脚本可以通用（如果有必要可以去掉思考时间、添加集合点等）。

相应的线程组可以改名为场景名称：用户登录业务并发负载。

2、Jmeter利用自带插件进行资源监控

• 解压JMeterPlugins-Extras-1.4.0.zip及JMeterPlugins-Standard-1.4.0.zip到Jmeter安装目录/lib/ext下
• 重启Jmeter，添加监听器：jp@gc - PerfMon Metrics Collector
• 下载ServerAgent-2.2.3.zip，并通过rz指令上传到服务器（Linux）指定目录下，执行unzip -o ServerAgent-2.2.3.zip解压该文件到当前目录
• 关闭服务器防火墙：systemctl stop firewalld.service
• 给启动文件设置执行权限：chmod u+x startService.sh
• 执行sh文件：./startService.sh
• Jmeter监听器jp@gc - PerfMon Metrics Collector下，添加监控的资源，如CPU、内存等
• 运行场景，即可监控服务器相应的资源

根据场景用例要求，业务量测试需要设置78个线程数，同时需设置执行的时间段（参考业务量指标：2小时完成5万笔交易或者是TPS），设置如下：

五、场景执行及结果分析

1、场景执行

场景执行前，需要对测试环境进行确认，保证所有环境，系统业务均能正常使用：

• 数据库恢复（避免脚本设计过程中对数据库中数据量的影响），记录商品、交易等相关数据
• 随机购买商品，为避免出现商品库存为零情况，将库存统一设置为1000
• 尽量单独部署服务器在Linux系统上，避免Jmeter对服务器性能的影响
• 执行前，启动相应的监控代理和apache和mysql服务

CMD下非GUI模式执行场景：

Jmeter -n -t 测试脚本Jmx文件 -l 日志文件名 -e -o HTML测试结果文件路径

2、场景结果分析

结合聚合报告，分析登录业务的每个请求的平均响应时间为：15s，是小于5s的，故该项指标测试不通过；在最大和最小响应时间差异较大时，我们可以采用90%事务响应时间作为标准。

Apdex（Application Performance Index）指标是一个国际通用的标准。是用户对应用性能满意度的量化数值，他提供了一个统一的测量和用户体验的方法， 吧最终用户的体验和应用性能统一度量，下图中0表示没有满意度，1表示所有用户均满意，是开发团队追求的目标。

六、性能调优及回归测试

测试结果分析完成以后，即可对进行性能问题的确定及优化，通常情况下性能问题表现如下几个方面：

1、响应时间问题：

• 响应时间平稳但较长，测试过程中响应时间就较长，即使减少线程数量（负载），也不会降低
• 响应时间逐步变长，测试过程中，负载不变，运行时间越长，响应时间越长，直至出现很多错误
• 响应时间随着负载的变化而变化，响应时间变长；负载减少，响应时间变短，资源利用率也下降
• 数据积累导致锁定，起初运行正常，但数据量积累到一定值，立刻出现错误，无法消除，只能重启系统

2、稳定性问题：

特定场景或运行很长时间以后，突然出现问题，系统运行缓慢，主要原因有如下：

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

 

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

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