性能测试理论2
1、性能测试模型（步骤）
1.1测试前期准备
（1）梳理测试场景（如测试产品的登录、产品列表、API执行等）；
（2）制定测试目标，该目标由测试主导初定，然后和相关人员（开发、架构师、产品、其他测试）达成一致后方可敲定；
（3）设备准备，如服务器等。
1.2测试工具引入
（1）loadrunner：由HP（惠普公司）开发，包含LR、QTP、QC等产品，现已逐渐被淘汰，很少使用了；
（2）jmeter：java语言，一般公司会进行二次开发，形成自己的测试平台；
（3）locust（蝗虫）：payth语言，基于协程的；
（4）自己开发工具。
1.3性能测试计划
（1）人力；
（2）做什么；
（3）什么时候开始、什么时候结束；
（4）使用什么技术。
1.4测试设计与开发
（1）工具/代码如何写；
（2）具体的脚本。
1.5测试执行与管理
根据配置的场景执行。
1.6数据收集
（1）数据库资源：主要收集IOPS；
（2）linux：主要收集CPU和memory；
（3）nginx：主要收集连接数；
（4）响应时间（response time)和吞吐量(throughput)等资源。
1.7测试分析
2、性能测试的方法
2.1验收负载测试
在QA的环境模拟生产运行的业务压力和使用场景组合，测试系统的性能是否满足生产环境的性能诉求。
2.2负载测试
在被测系统上持续不断的增加压力，直到性能指标(响应时间等)超过预定指标或者某种资源(CPU&内存)使用已达到饱和状态。核心是找到系统的处理极限，为系统调优提供数据，从而达到了解系
统性能的容量。
2.3压力测试
该方法是指系统在一定饱和状态下，具体如CPU，内存等饱和使用的情况下，系统能够处理的会话能力，以及系统是否会出现错误，比如TimeOut，OOM，OverStackExpection（堆栈异常）。
压力测试的特点：
*OOM：内存溢出，查看日志文件，发现在日志文件中会存在java.lang.OutOfMemoryError的错误提示。
（1）检查系统在处于压力情况下时应用的性能表现；
（2）等价于负载测试，使系统的资源处于一个瓶颈的状态（建议CPU和内存在75%以上）；
（3）这种方式一般用于测试系统的稳定性。
2.4配置测试
被测环境软硬件环境参数的调整，达到最优的分配原则。
2.5并发测试
模拟用户的并发访问，测试多用户并发访问同一个应用时是否存在死锁或者其他的问题，并发测试的特点是：
（1）发现系统中可能隐藏的并发访问的问题；
（2）关注系统可能存在的并发问题，如内存泄露，线程锁，资源争用情况；
（3）使用的测试工具如profiler等。
2.6可靠性测试
给系统加载一定的业务压力，让应用持续运行一段时间，测试系统在这种条件下是否能稳定运行。
2.7故障演练
故障演练就是故意的让系统出现一些故障，用来考验相关人员合作处理问题的能力。
2.8容灾恢复测试
故意对程序的数据等做一些破坏，看程序如何自行恢复。
3、jmeter性能测试实战
3.1jmeter执行原理
3.1.1JMeter执行原理
JMerer通过线程组来驱动多个(也可以理解为LR工具里面的虚拟用户)运行测试脚本对目标服务器发起⼤量的网络请求，在每个客户端上可以运行多个线程组，也就是说一个测试计划里面可以包含
N个线程组。线程组里的线程数就是指虚拟用户。
3.2场景设置
在JMeter的测试工具中，依据业务的形态来设置它的目录结果，但是设置性能测试的场景，主要是在线程组中来进行设置。JMeter的线程组可以理解为是建立了⼀个线程池，在执行的过程中处理
线程组里面的各个业务逻辑，线程组的信息具体如下：
取样器错误后要执行的动作：
（1）继续：如果有⼀个请求错误，其他的请求会继续，不会因为有⼀个请求错误的导致其他请求终止；
（2） 启动下⼀个进程循环：如果请求出现问题，同⼀脚本中的其他请求就都不再执行，直接执行下⼀个进程的信息；如风暴平台，当个人主页的测试用例数断言错误，则会跳过添加产品，继续
执行下一次循环：
（3）停止线程 ：停止线程指的是如果请求失败，就停止当前线程执行，不再继续执行。如果线程数很多，那么导致的结果是停止的线程就会很多，处于真正运行的线程会很少，最后导致服务器
的负载不够，⼀般不建议勾选该项选项；
（4） 停止测试：如果请求失败，那么停止所有线程执行，也就是说停止整个测试；
（5） 立即停止测试： 如果请求失败，立即停止整个测试场景的执行；
3.3线程属性
3.3.1线程数
⼀个线程可以理解为对应模拟⼀个用户，所以线程数越多，那么也就认为可以模拟的⽤户数越多。
3.3.2Ramp-Up时间(秒)
该属性指的是所有线程从启动到开始运⾏的时间间隔，单位是秒，也就是说所有线程在多⻓时间内开始执行，如线程数设置50，设置的时间为5秒，则计算的公式为:每秒执行线程数=线数/Ramp-
Up； 具体如：如设置的线程数为50，Ramp-up的时间为10，那么也就是说开启执行后，每秒会启动5个线程，如图：
如果Ramp-Up设置为0，那么开始执行后，50个线程会⽴刻启动，如图：
如果如果Ramp-Up设置为1，那么开始执行后，每秒启动50个线程，如图：
3.3.3循环次数
循环次数可以理解为，请求的重复次数。如果选择“永远”，那么请求将⼀直进⾏，不建议这样操作。
3.3.4调度器
所谓调度器可以理解为设置何时开始运⾏。
3.3.5延迟创建线程直到需要
如50个线程数，Ramp-Up时间是10秒，执行后线程是全部就绪的，那么就是每隔1秒启动5个线程数。
3.3.6持续时间
测试计划持续多长时间。
3.3.7启动延迟
从当前时间延迟多长时间开始运行测试，也就是说点击执行后，仅仅是做初始化的场景，不会执行测试，等待延迟到达后开始运行测试，执行的时间为持续时间设置的时间。
场景：每秒发送15个请求，同时发送45个请求，总的请求数150个。
*一般最优情况下，持续时间大于10秒就可以。
3.4监听器
3.4.1聚合报告
聚合报告是以表格的形式来显示取样器的结果信息，如果不同的取样器拥有相同的名字，那么在聚合报告会显示在 一行里面，那么⼀般来说，聚合报告都是根据取样器来显示每个取样器的执行结
果信息。聚合报告添加方式如下：
如：100个请求，每秒执行2个请求，同时并发20个请求，则启动延迟为10秒，如下：
结果如下：
聚合报告表格含义：
Label:取样器名称；
Samples:取样器运行次数；
Average:单个请求的平均响应时间；
Median:50%请求的响应时间；
90%Line:90%请求响应时间；
95%Line:95%请求响应时间；
99%Line:99%请求的响应时间；
Min:请求的最小响应时间；
Max:请求的最⼤响应时间；
Error%:事务错误率；
Throughput:吞吐率，也就是TPS KB/sec:每秒数据包流量；
Received KB/sec:每秒从服务器端接收到的数据量；
SentKB/sec:每秒从客户端发送的请求的数量。
3.4.2响应时间图
响应时间趋势图反馈的是请求的时间趋势图，添加方式如下：
