目录
- 一、思维差异
- 1、功能测试、自动化测试
- 2、性能测试
- 二、性能的概念
- 1、100个人同时对登录接口进行登录，性能中的avgRT应该在多少，是可以被接受的？
- 2、性能
- 3、事务
- 三、性能测试
- 1、用工具来模拟多个人的方式很多
- 2、性能指标
- 3、性能测试是为了找什么？
一、思维差异
1、功能测试、自动化测试
- 输出：找bug，预期结果与实际结果进行比较。
- 隐藏的前提：都是模拟1个用户的操作。
2、性能测试
1）不是模拟1个人，模拟多个人同时调接口向服务器发起请求。
2）关注多个人操作时，它的响应时间。
十个人百个人同时做登陆的事情的时候，能不能快速得响应，其中80个人失败了，只有20个人成功。
为什么80个人失败，20个人成功？100个人同时做登陆的事情，只要有一个人能登陆成功，那都不是功能的问题，而是服务器的性能问题。
服务器处理不过来，有的人不能被它处理就返回的是报错，有的人能被它处理，就返回的是正常。
这一批的人，这个总数量里有百分之多少的成功，百分之多少的失败，返回回来需要多长时间，最快的人需要多长时间，最慢的人需要多长时间，这是需要关注的点。
服务器在同时处理100个请求的时候，它消耗了多少资源，cpu的利用率有多高，内存的使用率有多高，这些资源的消耗是我们关注的点。
不会关注单独的某些人是成功或失败的。
3）接口服务器性能测试中，一定是多个人同时操作，才是性能测试。
二、性能的概念
1、100个人同时对登录接口进行登录，性能中的avgRT应该在多少，是可以被接受的？
1）可接受的范围：1.5s。比这个时间越少，说明反应的越快，性能越好。
2）1.5s的来源是：APDEX用户满意度指数。它规定500毫秒以内，我们认为性能很好，500毫秒-1.5s，我们是可以接受的。1.5s以后是不能接受的。
2-5s，3-5s，8s这样的说法是什么呢，这是针对于页面的性能测试。
访问一个页面的时候，需要域名解析，页面里面有很多资源，比如图片、js，页面还要通过接口返回一些数据。
页面上是个表格，要把数据放到表格里面去，就要把数据拆开填充到表格不同的行和列中。浏览器解析js进行渲染。
客户端需要通过js进行解析，渲染一下，拆分数据放到不同的位置。所以它也需要前端展示的时间。
页面有非常多的图片、js、数据、接口。返回回来整体比一个接口的时间要长。用户端的性能测试的时候，是有个3、5、8s的说法，5s的时间是能接受的。
现在测试的是数据通过接口调用服务器的这种，更趋向于底层来分析服务器的性能。所以这个响应时间能接受的范围是1.5s。
2、性能
事务和物品的某些特性的一个不同角度的展示。
3、事务
一个页面有多个接口，一个业务也有多个接口。就会出现多个接口合并成一个事务。
这个事务的响应时间也会定在1.5s以内，当然要看事务的数量的多少。 页面有10-50个接口，还把响应时间定在1.5s，只能说明你的标准比较高。
如果是2-3个接口，你把响应时间定在1.5s，这是很正常的。这个是要根据企业的实际情况来确定的。
1）事务的概念：
是从发起，到网络传输，收到响应。这样一个完整的过程才是一个事务。
一个请求行为一定只调用一个接口吗？并不一定只调用一个接口。所以，一个事务可能是多个接口。
但是也有可能一个事务：一个请求行为只调用了一个接口。所以，一个事务是一个接口。
jmeter：
1）默认情况下，1个接口请求一次，认为是一个1个事务Transation。
2）也可以是通过事务控制器，挂载多个接口请求，合并成为1个事务。
例如：我在网站上进行登陆，登陆这件事只调用这一个接口吗？肯定不止调用一个接口，但是核心接口就是只有一个登陆。
它可能调用了校验你的用户名，校验你的密码，获取用户信息等这些接口。
这是个页面用户的一个行为。用户在界面上点击登陆，后面实际调用了一个校验用户信息，进行登陆，获取用户信息这三个接口。
模拟的时候只模拟了一个登陆接口，其它的两个接口没有模拟。就会感觉少了点什么东西。
真实模拟用户的在界面上的登陆行为，使用事务控制器把相关的接口合并都放在这个事务控制器下面。
这个时候才能真实得模拟出用户在界面上的登陆行为，得出的性能的响应时间才是更加接近用户真实情况的一个响应时间。
单独调用一个登陆接口得到的响应时间，只是这个接口的响应时间的值，不等于用户真实在界面上的登陆行为。
三、性能测试
通过工具，模拟多用户发起请求，获取性能指标值。
1、用工具来模拟多个人的方式很多：
1）线程: 线程（比如是人的一只手）是使用进程的资源，来干活。jmeter、lr（默认也是用的线程）。
线程是依附在进程上的，干活的时候要有进程，没有进程也就没有线程的。
可以是只有一个进程，但是我在下面有个100个线程，都是可以的，都是使用进程的资源。
2）进程： 我们的一个程序运行起来，这个程序需要占用一定的资源。它是个资源拥有者，资源消耗会比较大。LR。
一段代码、一个软件或者一个工具等要能运行起来，就需要提供给它资源。那么这个程序（比如：人）就是个进程，一个运行的程序是拥有自己独特的资源的。
当然，进程它自己也能干活。比如不用手和脚，让你走路，你也能走，但是很麻烦。
不能说进程由线程组成。 一个程序运行起来，它肯定会有一个以及以上的进程。进程里可以没有线程，但是一般至少会有一个线程。
比如进程只给线程128兆的内存资源，不管你启动多少个线程，它都只在这128兆的内存资源里面使用，绝对不会超出你给的资源来使用。一超出就会出现内存溢出的问题了。
3）进程 线程： ngrinder。
启动一个进程，给它虚拟出一百个人，只给它128兆，虚拟不出来一千个人。
但是如果开2个进程，每个进程我开启128兆的，那虚拟出100个人，开了2个进程，就模拟出200个线程出来了。
4）协程： （模拟一只手的5个手指）python locust。
协程的资源是依附于线程的资源，线程的资源又来自进程。所以它是线程的子集，是来干活的。
2、性能指标
1）平均响应时间: avgRT 90%在这个时间点之下。
2）最大响应时间可以看，但是这个一般没有价值。
性能测试里，100个人来发起请求，以一次为准吗？
100个人，每个人都请求20次，每个人都请求30次，40次，在请求的次数中，总会有些人的某次值可能大些小些，偶然性的这种波动把最大响应时间的值拉得很高。
3）TPS：服务器每秒处理的事务数。
衡量服务器处理能力的最主要的指标。
本来我的处理能力能够达到一千，每秒你给我一千个事务，我都能处理完，一千是我能处理事务的最大值。
你现在给我的事务没有一千，每秒钟只给我发了300个请求，你一发过来我马上给你处理掉给你返回回去。这个时候每秒钟能处理的事务数就变成了300。吞吐量也会变成了300。
我的最大能力达到一千，你给我800也能处理完。现在你每秒钟给我发了1200个事务，我最大能力能够处理一千个事务，还剩200个事务处理不了，处理不了，我就放在那边。
但是我处理完的这一千个事务，我还是会通过网络传输出来。现在这一秒钟你给我传了1200个，下一秒钟你还给我传递1200个。
这样每秒钟累积200个事务，我处理不了，就放在那边，但是我的tps值是不会上升，我的网络吞吐量也不会上升的。
积累了一段时间，发现tps值会有个相对比较平均的过程，是一条线。
积累下来的事务占用cpu的空间，资源占用的比较多。tps会出现下降，出现tps下降就说明资源已经不够用了。
4）吞吐量： 网络中每秒能传输的事务数。
服务器处理了多少事务，网络就传输了多少。所以服务器的处理能力就在吞吐量上展示出来。
- 1、没有网络瓶颈：tps数值 = 吞吐量数值
- 2、如果网络有瓶颈: tps数值 != 吞吐量数值
如果网络有瓶颈，服务器处理事务的能力（tps数值）就不能够得到很好的展示。
如果网络有瓶颈，真实的tps数值测试不出来的，所以就不知道。
5）吞吐率：每秒钟能通过多少kb数据。
6）服务器资源利用率：
cpu、内存、io的利用率。
io：1.磁盘的读写和2.通过网络的这种方式进行数据的换入换出。（io的利用率主要体现在这2个上面） 当然还有内存里面的数据的换入换出。
这个换入换出就不再局限于磁盘这一个方向了。我通过网络来访问一个数据，数据通过网络来进行上传下载，这就是进出系统。
7）并发用户数：
- 同一时间发起请求的用户数。
- 集合点（这个是狭义并发才会有的）：集合多个人在同一时间发起相同请求。
- 广义并发：同一时间发起请求(请求是相同的、不相同都可以)。
- 狭义并发：同一时间发起相同请求。
8）集合点可以用来做秒杀的这种场景的测试。
本来100个并发用户数同时做了一些请求。接下来做了个集合点，等待到20个人来齐了后，就让这20个人一起去做登陆。
用了集合点的这种情况下，强制把发起请求的频率拉低了，实际上这种情况不能获得服务器真实的性能指标。这个集合点，用的比较少。
3、性能测试是为了找什么？
1）100并发用户数同时向服务器发起请求调用一个登陆的接口，1秒钟发起多少次请求？
（请求的频率）不知道的，所以1秒钟的总请求数量是不知道的。请求的频率是不知道的，所以tps值是不知道的。
和响应时间有关。在同一时间点第一个人发起了请求，给到服务器，服务器处理完毕后就有一个结果给到它。整个过程只有100毫秒就能收到响应。
接下来的900毫秒里面还会继续发起请求。这一秒钟，一百个人总共发起请求的次数是多少是不知道的。
2）请求的频率（1秒钟发起多少次请求？）
100个人，1秒钟内平均的请求频率是7次，这100个人就会在1秒里总共发起700次请求。没有网络瓶颈的情况下，tps值可能是700。
0.8次的由来是： 我虽然发起了请求，在这1秒钟里有100请求。但是有些没处理完毕，需要超过1秒钟，服务器才能处理完毕。
这种情况下，它的频率才会出现零点几，小于1的情况。比如是0.8。
如果并发用户数是100，我的请求频率是一秒钟里面只能请求0.8次。比如是0.8，100个人x0.8，总请求数是80，tps值是80。
3）请求的频率和tps的关系
服务器的处理能力越强，响应时间越短，请求的频率越高。
处理得越快，每次处理的时间消耗得越少，那发起的请求数就越多，请求的频率就更高，总请求量就越多，tps的处理能力就能更加得展示出来。
并发用户数和tps之间是存在着一个请求的频率在中间的。这个值是个未知数，需要通过性能测试才能出得来。
注意：说一百个人发起请求，tps就是100，这是完全错误的。不能认为100个人1秒钟每人只能发起一次请求。
自己的代码写得很好，那么进行处理的时候，响应时间就要短一些，那么这个请求频率就要高一些。这个请求频率的高低能反映出你们的代码写得好与坏。
用户发起请求的频率是不一样的，从而得到tps值来衡量服务器、软件、硬件加软件的综合的这样一个性能。
4）企业关注的是啥？
有的企业关注的是并发用户数，有的企业是关注tps。
更趋向于tps，因为tps是服务器处理能力，要调优的是服务器。调优了服务器，并发用户数也会相应得提升。
比如你们的企业是做一个网站的，关注的是同时支持多少个人在线，同时多少人的请求。
如果是做接口第三方提供的，提供一些接口出来给第三方来使用。这个接口的tps值要是多少，人家才能使用我们的接口，这个时候就是关注tps。
