第1章性能测试整体认知

一、第1章性能测试整体认知

1、shell

2、jvm调优，tomac调优

3、mysql：增删改查，监控，明白原理，

	语言：java，python：

4、分析调优工具：visualvm，yourkit、jps、jstat

5、LR，jmeter，fiddler

6、监控，瓶颈，

7、网络协议：http

开发语言：java，python
操作系统：linux：会操作（文件），监控，获取服务器
数据库：mysql：增删改查，监控数据库，明白监控返回的状态信息，
性能测试工具：loadrunner，jmeter
网络知识：对性能影响很大，网络宽带/数据/报文大小；http协议分层？
业务知识：

JMeter和LoadRunner对比

1、lr稳定，使用c写，jmeter跨平台，免费，开源，小巧，java写的；
2、jmeter没有进程方式，只有线程；
3、jmeter没有IP欺骗；
4、lr有不同带宽下的测试，jmeter没有；
5、分布式压测，jmeter需要将参数化文件传到压力机；

性能学习路线

loadrunner入门→jmeter→java基础→beanshell→linux→各种中间件等定位调优
jmeter是主流

性能测试目的：发现性能瓶颈

分类（测试范围）：

负载测试：通过逐步加压的方法，达到既定的性能阈值目标。如CPU使用率小于等于80%

负载测试（Load testing）：在一定的软件、硬件及网络环境下，通过运行一种或多种业务在不同虚拟用户数量情况下，测试服务器的性能指标是否在用户的要求范围内，用于确定系统所能承载的最大用户数、以及不同用户数下的系统响应时间及服务器的资源利用率。强调系统的稳定性。

压力测试：通过逐步加压的方法，达到系统某些资源达到饱和，甚至失效的状态，简单说就是什么条件能把系统压崩溃。

压力测试（Stress testing）：在一定的软件、硬件及网络环境下，通过模拟大量的虚拟用户向服务器产生负载，使服务器的资源处于极限状态下长时间连续运行，以测试服务器在高负载情况下是否能够稳定工作。

并发测试：在同一时间内，多个虚拟用户同时访问同一模块、同一功能，通常的测试方法是设置集合点。
容量测试：通常是指数据库层面，目标是获取数据库的最佳容量的能力。又称容量预估。具体测试方法为在一定的并发用户，不同基础数据量下，观察数据库的处理能力，即获取数据库的各项性能指标。
可靠性测试：又称稳定性测试或疲劳测试。是指系统在高压情况下，长时间的运行系统是否稳定。如CPU使用率80%以上，7*24小时运行，系统是否稳定。————内存泄漏
异常测试：又称失败测试，是指系统架构方面的测试。如在负载均衡架构中，要测试宕机、节点挂掉等情况系统的反映

1.性能测试: 收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。
负载测试：是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。
压力测试：是在一定的负荷条件下，长时间连续运行系统给系统性能造成的影响。
比喻：
性能测试,一个秘书对一个老板。
负载测试，一个秘书对一个部门。
压力测试。一个秘书对多个部门。
2.压力测试是测试系统的限制和故障恢复能力，它包括两种情况： 1）稳定性压力测试：在选定的压力值下，长时间持续运行。可以考察各项性能指标是否在指定范围内，有无内存泄漏、有无功能性故障等； 2）破坏性压力测试：在稳定性压力测试中可能会出现一些问题，如系统性能明显降低，但很难暴露出其真实的原因。通过破坏性不断加压的手段，往往能快速造成系统的崩溃或让问题明显的暴露出来；
负载测试的目标是测试在一定负载情况下系统性能（得到不同负载下相关性能指标）。
最简单来说： 负载测试是测试软件本身最大所能承受的性能测试；压力测试就是一种破坏性的性能测试；

1、工作流程

需求分析：熟悉了解项目，用户如何操作，那些是重点

分析的目的：
1、明确测试指标，TPS
2、明确测试场景，并发场景
新系统：同行业比较，业务预期，
老系统：对比以往用户使用行为以及用户量，

性能指标制定：吞吐量、TPS等定义，要有个目标，什么样的标准满足现阶段需求

脚本开发：工具

场景设置：和需求分析产生关联，设置场景要符合用户在应用程序上的使用流程，

监控部署：运行到服务器，数据库，要查看性能瓶颈

（循环以下这几步）

测试执行：有几个阶段，

1基础测试，少量用户-发现多并发下应用程序对多线程逻辑处理问题，

性能分析：基于监控部署，

性能调优：

测试报告

性能测试流程

压测任务具体包含：
0.前期准备
　　需求阶段就加入项目，可以深入了解业务、重要功能的需求和逻辑
1.性能需求分析（评审）
　　明确性能测试范围、目标，由于非专业性能测试人员也不知道怎么定目标，所以最好是引导产品、需求或者开发出目标，避免只有测试背锅；
　　基于接口或者场景（流程）的性能测试指标，一般是tps（每秒事务数，这里都是通过的事务）、art（平均响应时间）及并发数，加上服务器资料利用率的要求（cpu、内存、IO、网络等）。
2.熟悉系统架构，申请性能测试环境
　　用到的web服务器、应用服务器、缓存数据库服务器、数据库服务器、文件服务器等，画出系统架构图，理解其中的逻辑
3.制定性能测试方案
　　计划什么时候做什么事，需要的资源，技术策略（比如监控分析工具选择等等）、用例设计
4.搭建测试环境，准备测试数据
　　数据库的存量数据+增量数据，比如一个查询接口，都是并发100用户，对应的表数据量是1万和100万，压测结果是不一样的，这个数据量根据生产环境获取；数据最好是有标识、有规律的数据；
5.主流程稳定后，调试被测接口、开发压测脚本（也可以在功能测试环境进行）
　　参数化、关联、事务、检查点、思考时间等，造参数化测试数据。
6.预压测（基准测试）
　　少量并发（比如1个用户），看压测环境功能是否通；
　　估算并发过程中需要多少参数化数据的数据量
7.执行压测并监控服务器资源等
　　看测试指标是否满足需求，从请求开始，一步一步排查请求流经的节点，包括服务器资源（cpu、内存、磁盘io、网络）是否存在性能瓶颈、各种连接等是否存在性能瓶颈

常见的性能问题主要包括：
a.服务器问题
　　　　cpu：us&sy
　　　　内存：使用率及交换率
　　　　磁盘io：读写慢
           磁盘容量
　　b.网络带宽：看当前收、发速度，及占用的带宽，及有没有丢包，端口使用情况
　　c.load高：看线程信息；看是否fgc等
　　d.队列问题（负载高）：磁盘io队列（物理读高）；线程队列（线程阻塞，锁竞争）
      e.各种连接池问题：不足或者没释放（以及半释放）
      f.死锁问题：数据库死锁、线程死锁
　　g.慢sql问题：索引（未知，使用不当），慢sql（全表扫描，查询结果未分页显示，sql逻辑），长事务
h.缓存设置问题
J.业务不合理

8.分析定位
　　基于上一步的监控数据，对瓶颈进行分析、定位，全流程排查，模块隔离分析，日志分析
9.性能优化
10.性能回归
11.编写性能报告
　　测试结果，测试是否通过；发现、解决什么问题，系统性能提升了多少倍；如何调优的，改了什么东西，以便上线同事知道

从上面可以看到：
　　1、jmeter≠性能，jmeter只是一个主流客户端并发工具，当然，你也可以用loadrunner、locust、或者自己写并发代码，或者直接用，先学会并发工具的常用功能，然后系统架构中各个技术栈的监控、分析等等；
　　2、性能要求的知识面比较广，不仅需要知识积累，也需要实战经验积累；

性能测试方案

Y*H项目性能测试方案

常见系统应用分层架构

应用程序分块：

网页能打开应用程序，api层能控制业务逻辑，用mysql来存储
在性能前期准备阶段，怎么做？

1、首先能用工具或命令监控mysql，部署到服务器，对mysql状态进行监控，能实时反馈，能直观看到mysql处于什么状态。

2、监控API层，代码运行怎么样，处理速度情况，监控服务器运行的状态-服务器扛不住

3、web层：渲染过程-即先图片加载，后加载JS内容，否则会卡顿；先加载样式后加载脚本；图片大小-如何格式压缩不会失真，

性能测试指标定义

事务：从客户端发起的一个或多个请求（这些请求组成一个完整的操作），到客户端接收到从服务器返回的响应；

从客户端发起，服务端返回
事务：一般把被测的某个或者某几个请求一起定义为一个事务，是人为的测试定义
TPS：每秒系统能处理的事务数；

事务数并不一定等于请求数，
qps：https://www.cnblogs.com/uncleyong/p/11059556.html
请求响应时间：从客户端发起的一个请求开始，到客户端接收到从服务器返回的响应。整个过程所耗费的时间。
- 平均响应时间（art）：每个事务的处理时间，从发送请求到接收到响应
- 事务响应时间：事务可能是由一个或多个请求组成的，事务响应时间主要是针对用户的角度而言，如转账。
并发定义：没有严格意义的并发。并发总有先后，有时间差。所以并发讲的是一个时间范围内，比如1S内。

举例：

1、多用户在系统上进行同一操作，比如双十一时，大家都针对同一商品进行秒杀；

2、多用户在系统上进行不同操作，比如比如双十一时，大家都针对不同商品进行秒杀；或者是大家有进行其他不同的操作，如商品浏览。
- 并发用户数：同一单位时间内对系统发起请求的用户数量
吞吐量：一次性能测试过程中网络上传输的数据量的总和。可以估算，查看网络带宽
- 吞吐率：单位时间内网络上传输的数据量。
- 吞吐率=吞吐量/传输时间
点击率：每秒用户向服务器提交的请求数。

可以想象为每秒钟用户总共在页面上进行多少次点击动作，但是要注意的是一次鼠标单击的操作后，客户端有可能向服务器发送了多次请求。

每秒点击率（数）：每秒处理的请求数，而不是用户每秒发送的请求数
资源使用率：

对不同的系统资源的使用情况，如CPU、内存、io

参数化：
https://www.cnblogs.com/UncleYong/p/10702700.html
参数化的原因，并不是网上说的真实模拟不同用户，真实反应服务器性能，而是：
一、服务器不允许提交重复的值
1、数据库中要求唯一性（比如注册名不能一样，插入数据）
2、服务器不允许重复提交，（比如一个用户多点登录）
二、避免命中数据库查询数据

关联：
https://www.cnblogs.com/UncleYong/p/10702702.html

检查点：

迭代：每个人跑多少圈
循环：一次迭代里面，反复执行其中一段脚本，就是反复来回跑其中一段跑道
参数值：发请求时候用的数据
参数化：是一种策略，可以根据参数策略获取参数值，参考：
https://www.cnblogs.com/UncleYong/p/10702700.html

思考时间：模拟用户等待的时间
关联：下一个请求入参依赖上一个请求的某个返回值，参考：
https://www.cnblogs.com/UncleYong/p/10702702.html
检查点：判断请求是否成功，一般只有查询请求才加检查点
集合点：同一时刻去发起请求，主要应用场景是秒杀

负载：服务器的繁忙程度，如果一个8c的服务器，每次可以同时处理8个请求，如果请求量大，后面的请求就排队，排队的请求越多，服务器的负载就越高

场景：设置并发策略，模拟用户使用的场景
分析：场景运行完，生成各种维度的结果

性能测试：TPS和QPS的区别

各种ps，jps，tps，qps，rps，hps，你理解几个？
QPS：Queries Per Second，意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器（比如是读写分离的架构，就是读的服务器）在规定时间内所处理流量多少的衡量标准。

TPS：TransactionsPerSecond，意思是每秒事务数，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

1、tps，即每秒处理事务数，每个事务包括了如下3个过程：
　　a.用户请求服务器
　　b.服务器自己的内部处理（包含应用服务器、数据库服务器等）
　　c.服务器返回给用户
　　如果每秒能够完成N个这三个过程，tps就是N；

2、Qps基本类似于Tps，但是不同的是，如果是对一个页面请求一次，形成一个tps；但一次页面请求，可能产生多次对服务器的请求（页面上有很多html资源，比如图片等），服务器对这些请求，就可计入“Qps”之中；
例如：访问一个页面会请求服务器3次，一次放，产生一个“T”，产生3个“Q”

 但是，如今的项目基本上都是前后端分离的，性能也分为前端性能和后端性能，通常默认是后端性能，即服务端性能，也就是对服务端接口做压测

  如果是对一个接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么tps=qps，否则，tps≠qps

  如果是对多个接口（混合场景）压测，不加事务控制器，jmeter会统计每个接口的tps，而混合场景是要测试这个场景的tps，显然这样得不到混合场景的tps，所以，要加了事物控制器，结果才是整个场景的tps。

jmeter聚合报告中，Throughput是用来衡量吞吐量，通常由tps来表示。