20天jmeter性能测试

接口性能测试.jpg

性能测试

*系统性能测试是为了保证产品发布后其性能能够满足用户的需求，下文结合具体案例介绍应用系统性能测试过程的六大步骤和测试内容。

一、什么是性能测试**

是不断的通过不同场景的系统表现去探究系统设计与资源消耗之间的平衡。

我们可以认为性能测试是：通过在测试环境下对系统或构件的性能进行探测，用以验证在生产环境下系统性能是否达到预估的性能，发现系统可能存在的性能瓶颈，进而改善优化并系统的性能，提高系统的可扩展性、稳定性。

从上面的描述可以看出，性能测试的主要工作包括：获得预估的性能需求、搭建测试环境、执行测试、分析测试结果。其中，最为重要两个工作是确定测试的目的、方案，并对结果进行分析。

二、性能测试的目的

(1)验证系统是否满足预期需求;
(2)验证系统在高压下的表现;
(3)验证系统是否能持续稳定的运行;
(4)探测系统的瓶颈和产生瓶颈的原因;
(5)探测系统设计与资源之间的最佳平衡，改善并优化系统的性能。

三、如何做性能测试

1. 负载测试：找到系统稳定时（或满足性能需求下）的最大吞吐量；（要有响应时间、成功率的限制，比如定义：99.9%的响应时间必需在1ms之内，平均响应时间在1ms以内，100%的请求成功）

2. 稳定性（通过浸泡测试soak test）：以系统稳定时的最大吞吐量（或满足性能需求时的最大吞吐量），长时间对系统进行测试，已检查系统是否稳定

3. 压力测试：找到系统极限值，系统瓶颈（系统崩溃临界值）（要求：响应时间可以变慢，但系统不能崩溃；）

   
   image.png

4. 并发有两个概念：
   多个用户同时进行相同操作，访问同一接口——单个业务接口并发；
   多个用户同时访问系统，但进行不同的操作，访问不同的接口——系统级并发

5. 测试流程：确定测试目的与需求——根据需求与场景，梳理测试要点——根据测试目的，制定测试方案——准备测试环境与数据——测试执行（脚本或工具）——统计测试结果——分析结果——测试报告
   PS：
   1 .测试执行时，执行多次，取平均结果更为准确。

6. 单机并发不够时，采用多机分布式并发；

7. 测试过程，一定要尽可能模拟实际应用场景；

四、性能测试关注的指标

测试人员关注（单次业务相关指标）：

• 并发用户
• 数响应时间：TP（百分比分布统计）
• 吞吐量：tps/qps
• 成功率
• 失败率

开发人员关注（系统层面指标）：

1. Tomcat、数据库等；
2. 容量：系统能承载的最大访问量是多少？系统最大的业务处理量是多少？

3. 稳定性：是否支持7*24小时（一周）的业务访问？
   运维人员关注：硬件资源消耗情况：CPU、内存、I/O读写速度、网络带宽等

   
   image.png
   image.png

五、性能结果分析

1.响应时间要和吞吐量TPS挂钩.

2. 响应时间吞吐量要和成功率挂钩

• 不难理解，如果请求可以并发10w，但是成功率只有40%，那也没什么用。
  性能测试的失败率的容忍应该是非常低的。对于一些关键系统，成功请求数必须在100%，一点都不能含糊
  3.CPU、内存等硬件资源占比持续超过90%，说明性能存在瓶颈
  4.带宽波动起伏很大，说明带宽受限

jemter操作性能测试

1.打开登录界面

2.注册跳转到登录页面

image.png

3.打开fiddler抓包:用正确的用户名登录,并且输入姓名查询

image.png image.png

导出添加到jmeter看前面几天的简书有详细说明.
4.填好信息,启动cookie,设置好断言跑一下观察!

image.png

5.关闭cookie跑一下 查询挂了

image.png
*这是为什么呢?为什么cookie把用户名和密码储存在本地中,我们查询的时候会调用登录的状态,是否登录.登录我们才能查询.这里cookie就其到了很好的作用,我们直接可以调用本地cookie存的ID.因此禁用了cookie管理器,查询就挂了.那么我们怎么做可以关闭登录和COOKIE还能跑通呢?
我们只需要在查询请求里面的http信息头管理器添加Set-Cookie后面的值A就行了.
添加:cookie=A如下步骤图

*首先我们要知道Set-Cookie的值
切换到登录接口,找到登录取样器结果里面cookie的值复制

image.png
*粘贴到查询接口http信管管理头,添加cookie 的值 等于复制的内容
image.png
6.我们禁用cookie管理器和登录接口 看跑得通不
image.png

对查询页面做性能测试

• 首先我们需要些什么?
  1.请求里面的参数 IP http 请求方法 编码格式 请求参数值
  2.请求里面添加http信息管理头 响应断言 和固定定时器
  

  image.png
  3.接下来全部从监听器添加 **
  1.聚合报告 **
  2.jp@gc - Active Threads Over Time(活跃线程组) **
  3.jp@gc - Transactions per Second(TPS)
  image.png

• 循环次数给50作为固定 线程组数 已从少到从多的方式记录

  
  image.png

用EXCEL 记录 请求数 线程数 循环次数 平均值 最小 最大 TPS

image.png

• 可以分析得出线程组40附近已经瓶颈,之后就要超负载了.怪我这条电脑渣渣!也就是说请求达到2250条时候,性能瓶颈之后将要超负荷.我们实时观看一下自己的CPU 内存 硬盘I/O
  带宽 等等

• 聚合报告

  
  image.png
• samples 请求数量
• average 平均响应时间
• median 中间值
• 90%Line 百分之90用户响应时间
• min 最小
• max 最大
• error 错误请求数量百分比
• throughput 吞吐量 每秒完成的请求数