性能测试基础及练习
1、性能测试的理解
性能测试：多用户高并发访问服务器来测试服务器的性能
可以从多个角度理解性能测试：响应时间，失败率
2、性能测试的分类
负载测试：强调开展性能测试的一种方法，一种手段，使用增加或者减小压力的形式来开展性能测试，找出最大容量，即最高的用户并发数（例如测试一个网站，先采取100个用户量，如果没问题，再往上加用户量），初级性能测试基本上都在测这个东西
压力测试：压力测试是在负载测试开展完成之后，测试服务器超过最大容量的性能情况（就比如我们已经知道这个服务器的最大容量是500，我们就去测1000,1500容量的时候，因为我们不知道一个网站在秒杀或者抢券的时候有多少用户量，需要去做这样的测试——瞬时并发），去测试服务器崩溃的情况，压到崩溃为止
强度测试（疲劳测试）：长时间运行性能测试，执行标准：3*24h*最大容量的80%
并发测试：偏重于使用性能测试的手段来测功能，例如测订单超发：抢超出了库存的订单却成功
。。。。
这些概念了解即可，负载测试最重要
3、性能测试指标：（三个）
在testplan下右键--->添加--->监听器--->聚合报告
3.1、响应时间（单位毫秒）
- 平均响应时间（Average）：统计所有请求的平均值（聚合报告中的Average，一般都是参考的这个值，响应时间越小越好）
怎样通过平均响应时间来判断测试的结果是否通过？平均响应时间业内有258原则：x<2s，明显快；2s<x<5s，比较快，明显卡顿；5s<x<8s，明显慢，指的一等；x>8s，特别卡。在工作中，如果没有明确需求，就使用258原则判断，即average<8秒即可判断通过
- 90%line（包分之90的请求在这个时间点完成，即统计大部分人的响应时间）
3.2、事务失败率（Error%）
事务的失败率可以理解为请求的错误率，越小越好，判断标准：x<5%
在jmeter中，事务=一个或者多个请求，是统计性能测试指标的最小单元，jmeter会自动把每个请求都当成一个事务来
3.3、tps
tps：即每秒事务数（服务器每秒返回的请求数），它直接反映了服务器的性能状况，数值越大越好（在负载测试中用不到这个指标，但是在性能调优的时候，它是直接观察的参数）
例如：tps指标：服务器A：100/s；服务器B：200/s。则服务器B的性能好（服务器A每秒返回100个请求数，服务器B每秒返回200，个请求数）
3.4、服务器的CPU使用率
服务器的CPU使用率：即服务器的繁忙程度，数值越小越好，对于服务器的CPU使用率有个监控原则，不要持续100%，数值在85%-90%之间，如果持续100就没有办法接收别的请求，就会卡顿，甚至会有失败率
CPU：电脑中央处理器，计算机的大脑，任何软件想要运行，都要被cpu执行，CPU有一个指标叫CPU使用率：CPU的繁忙程度
4、如何判断性能测试是否通过
如何判断单次请求通过：平均响应时间、事务失败率、CPU使用率同时满足算通过，有任何一个不满足都不通过
面试题：如何判断性能测试是否通过？从平均响应时间、事务失败率、CPU使用率这三个指标来判断，这三个指标能综合的反应服务器的性能，平均响应时间反映的是用户请求的快慢，事务失败率是从用户的成功率来进行考量的，服务器的CPU使用率是从服务器的繁忙程度来考虑的。
5、如何来做性能测试——负载测试
负载测试是在找最大容量，肯定会运行多次（负载测试其实就是多次判断单次请求是否能通过），so找最大容量：不断去增加压力，直到不通过，例如100 >pass；200>pass；300>pass；400> failed，则最大容量就是300（当然如果时间充足的情况下，可以更精确）
5.1、负载测试测试步骤
1.需求分析，知道测试的目的，熟悉被测系统（要理解系统业务，从技术层面讲，要知道软硬件结构，即这个系统是由哪些东西组成的，例如软件redis，nginx，gunicorn等，硬件：单机还是集群）
2.设计场景（测试用例）：从场景角度来看，明确要执行的case以及场景的每个步骤；从策略上，即我们需要知道采用什么方法来测——一般都是负载测试
3.编写脚本，用jmeter或者loadrunner，前面学习的什么关联啊乱七八糟的就是在编写脚本
4.执行测试（要在终端执行），jmeter必须要配置好环境变量才能在终端执行（即能终端打开jmeter环境变量就配置好了）
5.指标监控
- tps/响应时间/失败率——jmeter或者lr会搜集
- CPU使用率
有以下两种方式可以去查看CPU使用率：
①需要我们去连接上Linux，使用top命令
②还可以使用工具：zabbix（一款运维工具）
6.分析&报告：就是在Excel表格中将多次运行结果的值记录下来，找出最大容量（最高用户并发数），如下图所示：
5.2、以测试测谈网完成留言评论的业务流程的最大容量为例：
5.2.1.需求分析
首先明确，这是在测试业务流程，里边会涉及到多个接口，此处涉及到12个接口，整个业务流程包括了：登录-跳转到首页-浏览文章详情-评论文章
5.5.2.设计场景：在不用登录的情况下，可以正常的浏览首页以及点进去具体的文章，从业务流程上分为了四步，第一步，登录，第二步，刷新首页，第三步，点进去具体的文章，第四步，留言评论文章；从接口层面，登录调用了一个接口，刷新首页调用了六个接口，点进具体的文章调用了三个接口，评论调用了两个接口，并且，有的接口是需要保在登录的前提下，例如浏览文章详情部分功能和评论全部功能，都需要保持在登录的前提下。
刷新首页需要的接口数：
文章详情需要的接口数：
注意：在做负载测试的时候，如果有多个接口，我们一定是通过抓包查看具体的参数，请求数据之类的，不能只看接口文档上的数据，接口文档只是一个辅助
5.2.3.编写脚本
①添加一个线程组，取名用户浏览文章
②分别添加http请求（填数据，添加请求头，运行一下，断言：每个http请求下都应该添加断言，但是可以共用嘛，就把他拉到当前线程组下边，请求头也是一样的道理）
这里有个坑，路径那块，一定不能有空格，不然就会报404错误
还可以添加一个总的事务，把小的两个事务给检测到
按照顺序应该考虑是否需要关联和做参数化了：由于登录后返回的token值后边的接口会调用到，此处需要做关联，步骤：设置后置正则表达式
引用token值，这一步可以直接设置在最前方的头文件里即可
接下来就是参数化：添加CSV数据文件，注意变量名和数据文件的值要一一对应，之后再引用变量${变量名}
注意：什么时候需要关联，什么时候需要参数化：前面返回值需要作为参数传给后面接口，则说明需要做关联；每个用户（线程）都需要单独的数据，则说明需要参数化
③设置并发：分清应该做瞬时并发还是平均并发（具体需求具体分析，一般涉及到秒杀、抢券之类的才会是瞬时并发）
基准测试（冒烟），一般用户量设置为100为起点，此处设置为10为起点，循环数设置为100
5.2.4.执行测试
打开命令行，输入cd /d 脚本文件位置（到文件夹即可，不用选定脚本）——dir（Windows下边的ls）：可以查看脚本文件名
之后在命令行中输入：jmeter -n -t [jmx file] -l [results file] -e -o [Path to web report folder]，后面的 -l [results file] -e -o [Path to web report folder]可以省略不写，不写就没有对应的每次运行的报告
例如：jmeter -n -t 脚本名 -l 10-100-01.jtl -e -o ./10-100-01
10-100-01.jtl：文件名随便起，后缀是.jtl文件，此处为了方便查看起名规则为：10个线程，循环100次的第1次运行
./10-100-01：运行完成之后对应的测试报告存放目录，自己定的
刚跑起来的样子：
跑完之后的样子：
5.2.5.指标分析：
查看跑完之后的图，上边会有tps，平均响应时间，事务失败率等指标，在zabbix上监测服务器CPU占用率
5.2.6.分析&报告
将以上数据整理成Excel表格，分析得出最大容量
