什么是性能测试？
性能测试就是通过特定的方式对被测系统按照一定测试策略施加压力，获取该系统的响应时间、TPS、吞吐量、资源利用率等指标，来检测系统上线后能否满足用户需求的过程。
负载测试与压力测试是最常用的两种性能测试策略。两者可以结合进行。
性能测试的目的
性能测试的目的是评估当前系统的性能，预测系统以后的性能，找到系统的瓶颈点，进行调优优化。
评估当前系统：检测系统性能，评估系统性能。类似体检，对系统的性能状况有一个了解。
寻找瓶颈优化性能：某业务操作响应时间比较长，上线一段时间后运行越来越慢，需要逐步分析并调优。
预测未来性能：用户数和业务量增加时能否及时应对？是增加服务器，还是数据库服务器？还是优化代码逻辑。
系统瓶颈
系统的性能与它所处的运行环境关系很大。如果把法拉利跑车放到一个乡村的山路上运行，它可能跑不过一辆拖拉机，因为法拉利底盘低，可能陷到坑中无法运行。同样的道理，同一个软件系统放到不同的环境下，表现出的性能也可能有天壤之别。
影响性能测试环境的环境因素是多方面的，如使用的浏览器、网络带宽、操作系统、Web服务器、应用服务器、硬件服务器、数据库等。测试的时候任何一个环节都可能会出问题，都可能会影响系统的性能。
软件的性能瓶颈可能不止一处，比如对交通系统来说，堵车是常见的性能问题，堵车的原因可能是很多种：
道路不够宽，拓宽道路
立交桥设计不合理而引起堵塞
红绿灯设计不合理
交通事故频发路段导致拥堵
测试找到一个的瓶颈点，解决之后，可能会发现其他的瓶颈点。
性能测试什么时候开展
性能测试开始的必要条件是软件系统已经处于一个比较稳定的状态，系统架构、主要代码、中间件等都不再有大的变化，否则会给性能测试带来很大的风险。
全新项目：功能稳定后；一般建议在产品的3轮完整功能测试后开始。
线上系统大的升级：大的升级功能稳定后
术语
并发
狭义：所有用户在同一时刻做同一操作，主要是为了验证程序或数据库对并发处理能力。
广义：多个用户对被测系统发起了多个请求，这些请求可以是同一种操作，也可以是不同操作，类似于混合场景的概念。
用户数
系统用户数：该系统的注册用户数，比如某论坛有10000个用户，这些用户可以是活跃的，也可能是僵尸的。
在线用户数：登录系统的用户，在线用户并不一定都会对服务器产生压力。
并发用户数：系统可以同时承载的正常使用系统功能的用户数量，即对服务器产生压力的用户数量。
网站系统用户数>网站在线用户数>网站并发用户数
集合点
阻塞线程，等待指定数量线程全部抵达该点位之后，再一次性释放所有线程同时发起请求，用来模拟真实瞬间并发，实现多人同一时刻点击接口。
100 个用户同时下单；不用集合点时线程先后错开执行；开启集合点后 100 线程凑齐瞬间一齐请求。
JMeter中可以通过同步定时器 Synchronizing Timer 来完成。
事务(Transactions)
用户一个或一系列的操作，代表一定的功能，所有性能测试其实最终都是围绕着事务展开的，事务代表用户的使用方法和结果，不同的操作组合成不同的事务。
比如在线考试，主要的操作流程有登录系统、进入考试页面、开始答题、保存答案和提交试卷，这整个过程可以看做一个事务。
比如淘宝，一个购物流程可以看做一个事务；一个支付接口可以看做一个事务。
思考时间(Think Time)：用户进行操作时每个请求之间的时间间隔。
场景1：为了更加真实的模拟用户的操作，引入了思考时间这个概念。如果想了解系统的最大承受能力或者极端情况下系统的性能表现，可以设置0思考时间。如果要预估系统的性能，应该最大可能的模拟真实的思考时间。
场景2：某论坛连续两次发帖时间间隔不能小于15秒钟。为了满足发帖的测试场景，需要增加上思考时间。
吞吐量(Throughput)
衡量系统在单位时间内能处理多少请求/事务数量。通常用于评估系统在负载下的处理能力。
吞吐量可以有不同的衡量方式，通常包括：
RPS：在单位时间内系统可以处理的请求数。
TPS：单位时间内系统能处理的事务的数量。
在性能测试中，吞吐量的高低通常反映了系统的处理能力和响应性能，吞吐量越高，说明系统能够处理的负载越大。
TPS(Transactions Per Second)每秒事务数
服务器在单位时间内可以处理的事务数量。
TPS大时，系统性能会比较好，但是不可能无限大。
如果环境没有发生大的变化，系统最大处理事务能力不会随着并发用户数的多少而改变。比如说小寨的地铁检票机，只有两台进站的机器，一次一台机器只能通过一个人，不论是10个人来，还是100 个人来。
QPS(Queries Per Second)每秒查询率
服务器一秒钟能够处理的接口请求次数。
RPS（Requests Per Second）每秒请求数
TPS与QPS的区别
TPS和QPS都是衡量系统处理能力的重要指标，一般和并发结合起来判断系统的处理能力；
TPS即每秒处理事务数，比如如下的三个过程构成一个事务，每秒能够处理3个这样的过程，TPS为3。
用户请求服务器
服务器自己的内部处理
服务器返回给用户
上面的一次事务，可能对服务器有多次请求，比如一次上面的事务过程有5个请求，那TPS为3时，QPS就是15。
RT Response Time：响应时间，指一个事务花费多长时间完成；
ART Average Response Time：平均响应时间，所有请求耗时均值，容易被长尾拉高
P50 中位数：一半用户的速度
P95 95 分位：95% 用户最大耗时，线上性能基准，保障绝大多数用户体验
P99 99 分位：99% 用户最大耗时，代表极端慢请求、长尾耗时
性能测试通用合格标准（互联网常规）
普通业务接口：P95 ≤ 300ms
首页、查询高频接口：P95 ≤100ms
支付、下单核心链路：严控 P99 ≤500ms
性能测试怎么确定并发用户数？
需求文档中有写性能指标，按需求文档中写的指标来
需求文档中没有写性能指标，系统已经上线使用，使用下页的公式来计算
需求文档中没有写性能指标，系统没有上线使用，通过负载测试，测试出实际能支持的并发用户数
并发用户计算公式
平均并发用户数计算公式：C = nL/T
C是平均的并发用户数；
n是平均每天访问用户数；
L是一天内用户从登录到退出的平均时间；
T指考察的时间段长度，也就是一天内多长时间有用户使用系统。
计算示例
假设某网上银行的服务，每天访问用户数量为1000万，一天内用户从登陆到退出的平均时间为5分钟， 每天早8点到晚12点均有用户访问，时长为16小时，也就是960分钟。
C=10000000*5/960=52083.33/m （即52083.33每分钟）
响应时间计算公式
响应时间：对请求作出响应所需要的时间。
网络传输时间：N1+N2+N3+N4
应用服务器处理时间：A1+A3
数据库服务器处理时间：A2
响应时间=N1+N2+N3+N4+A1+A3+A2
前端页面的解析展示时间一般不计算在响应时间之内，因为每个浏览器解析页面的方式不一样， 时间也不一样。
响应时间2-5-8原则
响应时间的2-5-8原则：
当用户能够在2秒以内得到响应时，会感觉系统的响应很快；
当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；
当用户在5-8秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；
而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个 Web站点，或者发起第二次请求。
2-5-8 原则是经典用户体感分层标准，用来评判页面/接口响应时间带给人的主观感受，也是压测 P95、P99 响应时 间的验收基准
现如今网速更快，用户容忍门槛进一步降低，衍生出 1-4-10 新标准：
0.1s：人眼无感知延迟
≤1s：流畅；
1-4s：可忍受；
＞4s：用户流失率大幅上涨
web系统常用的系统指标
并发用户数
每秒事务数TPS
响应时间
事务成功率
web系统常用的资源指标
CPU使用率
内存利用率
磁盘I/O
网络I/O
负载测试
Load Testing=Large amout of users
概念：在一定的软件、硬件和网络环境下，在不同用户数量情况下运行一种或多种业务，测试服务器的响应时间等各项指标是否在用户的要求范围内，用于确定系统所能承载的最大用户数、最佳用户数。
通俗：通过逐渐增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下， 系统能承受的的最大负载。负载测试是最常用的一种性能测试方法。
目的：不断加压，找出系统能承受的最大负载量。确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
测试系统在不同负载水平下的表现
验证系统是否满足业务性能要求
找出性能瓶颈
测试方法：从比较小的负载开始，逐渐增加用户的数量，直到应用程序响应时间超时。观察系 统的各项性能指标。需要测试多次，用户从少到多。
900是系统最佳用户数量；1000是系统最大用户数。
负载测试-通俗解释
测试对象：猪八戒人猪混合系统
负载测试：猪八戒背着高小姐走路，我们观察猪八戒的生理和心理指标是否存在异常，根据观察的数据判断“猪八戒人猪混合系统”的瓶颈所在。
如果猪八戒背着背着腰酸背疼腿抽筋，那么猪无能同志可能是缺钙了，需要补钙；
如果他背着背着头晕眼花四肢麻木，那么猪同志可能是脂肪肝、酒精肝三高患者，这就证明猪八戒需要减肥了。
如果猪八戒背着媳妇身轻如燕、健步如飞，那么继续加压，再做一次测试。观察他的各种反应，重复执行，直到找到他的瓶颈为止。
以上并没有具体的测试标准，我们可以给出测试标准，即指标：背着体重为45公斤的高小姐走上一段山路十八弯总长为10公里的羊肠小道，在此过程中猪八戒同志的平均时速不能低于8km/h，其心跳不能快于60次/秒
压力测试
Stress Testing=Too many users,too much data, too little time and too little room.
概念：在一定的软件、硬件和网络环境下，通过模拟大量用户向服务器产生负载，使服务器资源长时间处于极限状态下，以测试服务器在高负载情况下能否稳定工作。
通俗：模拟用户在同一时间段，对服务器发送大量的请求，以此来看服务器的性能指标。
压力测试是一种破坏性测试，不断增加业务量，让系统CPU使用率达到80%以上，内存使用率在80%以上。通过压力测试可以更快的发现内存泄漏问题，以及系统稳定性的问题。
并发测试
Concurrent Test
概念：并发测试是模拟多个用户同时对系统进行操作，来检测系统在并发情况下是否能正确处理事务、数据一致性和资源竞争问题。
目的：测试系统在并发用户访问时是否有：
死锁
数据冲突（比如两个用户同时修改同一个订单）
数据丢失
响应异常
基准测试
Benchmark Test，概念：一种测量和评估软件性能指标的活动。我们可以在某个时候通过基准测试建立一个已知的性能水平(称为基准线)，当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。
应用场景：
租车系统部署在笔记本，想确定硬件对性能的影响
4G4核的电脑上运行性能，记录一组的性能数据——基线
8G4核的电脑上运行性能，记录一组的性能数据
16G4核的电脑上运行性能，记录一组的性能数据
验证操作系统对性能的影响
windows10上运行性能，记录一组的性能数据——基线
window11上运行性能，记录一组的性能数据
window server上运行性能，记录一组的性能数据
租车之前没有测试过性能
V1R1版本上运行性能，记录一组的性能数据——基线
V1R2版本上运行性能，记录一组的性能数据
基准测试-通俗解释
测试对象：猪八戒人猪混合系统
压力测试：加大负载，极端负载下进行测试，如一次性背10个媳妇。找到全身最薄弱的部分,找到系统瓶颈。压力测试一定要测出问题，否则认为负载太小。
并发测试：主要测试一次能背几个媳妇。假如我们的目标是一次能背4个媳妇的话，看下此系统是否达标。
基准测试：如果猪八戒同志在背高小姐的时候没有服用任何的违禁药品，那么我们可以将此次的测试结果作为一个基点。然后让猪八戒同志喝点红牛或者使用兴奋剂，然后进行同样的负载测试，查看喝红牛对猪八戒背高小姐这个行为是否产生了利弊影响。当然我们也可以不让猪八戒同志背高小姐，而换成是让孙悟空同学背高小姐，观察这两次测试的测试结果，从而确定究 竟哪一种系统更能胜任“背高小姐”这个重任。
稳定性测试：让猪八戒背高小姐背上七七四十九天，观察猪同学的表现。如果系统设置是要背 49天，他只背了36天就受不了了。那就认为不达标，要继续优化。
可恢复性测试：让猪八戒背孙悟空走上半天，猪八戒已累得接近崩溃，然后再换成背高小姐， 看它是否能从疲劳中恢复。
稳定性测试
概念：Stability Test ，给系统一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。
目的：验证系统是否存在内存泄漏等问题。
有些软件的问题只有在运行一天或一个星期甚至更长的时间才会暴露。这种问题一般是程序占用资源却不能及时释放而引起的。比如，内存泄漏问题就是经过一段时间积累才会慢慢变得显著，在运行初期却很难检测出来；还有客户端和服务器在负载运行一段时间后，建立了大量的连接通路，却不能有效地复用或及时释放。
稳定性测试一般不用最大的并发来测试，最大并发用户量在一年的运行中极少出现或者根本就不会出现。 例如，淘宝的用户高峰是“双11”的营销，这个高峰一年可能也就出现一次，但是为了这次营销活动淘宝系统必须要能支撑这个最大并发用户量。在淘宝其余的运行时间内常见的负载压力可能是最高峰的 20%~40%的用户量，研发人员应该更加关心的是这个负载压力下系统是否稳定。就像用户买车一样，用户平时开车最常见的时速是60km/h、80km/h、100km/h，那么用户最关心的应该是这些时速下车的稳定性、油耗、噪声等方面的参数。
注意：一般进行7*24小时稳定性测试。场景的设计以模拟真实用户的实际操作为佳。
失效恢复测试
概念：失效恢复测试针对有冗余备份或者负载均衡的系统来说，检查如果系统内部发生故障， 系统对故障如何应付，保证系统可以正常启动，用户是否可以继续使用。
过失效恢复测试一般是对具有负载均衡的系统进行的，主要是为了测试当系统局部发生故障时， 是否会对全局产生大的影响，产生的影响是否在可以接受的范围内，以及用户能否继续使用系统。在实际应用过程中，可以模拟一台或几台负载均衡机器出现故障来进行失效恢复测试，但需要注意的是，不仅要关心失效后，用户是否可以正常访问或者恢复后系统是否可以正常工作， 也要关注失效后，系统还能支持多少并发用户，以及采用哪些备选方案来快速响应。
失效恢复测试重在关注系统出现问题后能否根据预先制定的策略恢复，且恢复后能否正常运行。 以跑马拉松为例，为了预防出现跑不动的情况，预先准备了一瓶红牛，当选手累得躺下后，拿出这瓶红牛一口气喝了，然后有力量了，恢复了原来的状态，站起来继续跑。
总结
负载测试（Load Testing）：测试系统在正常负载和预期负载下的性能
压力测试（Stress Testing）：超出系统承载极限，测试其崩溃点和恢复能力
稳定性测试 / 耐久测试（Stability/Soak Testing）：长时间运行系统，测试其稳定性和资源泄漏情况
基准测试（Benchmark Testing）：对系统关键操作做基准性能评估，常用于不同系统对比
性能测试流程
性能测试需求分析
必要性评估
性能测试需求分析
性能指标分析与定义
工具选型
性能测试需求评审
性能测试计划制定
性能测试设计
测试模型构建
测试场景设计
测试用例设计
性能测试环境搭建
业务环境搭建
监控服务器、数据库
性能测试脚本开发
测试数据构造
录制脚本
场景设置
性能测试执行以及结果收集
阶梯式加压
分析结果与性能调优
性能测试报告
性能测试需求分析
性能测试需求分析-必要性评估（要不要测）
性能测试从用户应用、系统架构设计、硬件配置等多个维度分析可能存在性能瓶颈的业务。
必要性评估
被测对象需要经过主管部门或监管部门的审查、认可，需要提供性能测试报告。
涉及财产、生命安全的系统。比如电商系统、金融业务系统、医疗健康评估，涉及用户等资金交易，生命安全类 的。
首次投产的大型系统，具有大量用户使用的核心业务。
与历史系统对比，系统核心数据库、业务逻辑、软硬件有大的升级。
业务量、用户量、节点增长30%以上，具体数值可以根据实际情况调整。业务节点增长一般是因为业务需求， 增加应用节点，比如银行拓展分行，分中心，分公司等。
系统架构发生重大变化。
生产环境严重缺陷修复后，需要开展性能测试活动，验证修改是否对生产环境产生不良影响。
什么情况不需要做性能测试？
小型的系统，用户量比较少
公司内部使用的系统，用户量比较少。
性能测试需求分析-性能需求分析（测什么）
从最终用户的角度，分析需要进行性能测试点，分析业务模型，提取性能测试业务。系统支持哪几类用户，每种用户有哪几种典型的场景。用户频繁使用，且存在大量用户使用的业务流程。特殊交易日、特殊业务场景、发生重大流程调整的业务流程。
比如某编程等级考试网站，典型的用户以及各类用户的使用场景：
用户-考生（考试）：
考试场景：登录系统->打开考卷->答题->保存试卷->提交试卷->退出登录
查询成绩场景：登录系统->查询考试成绩->退出登录
用户-监考老师（监考、改卷）：
登录系统->监考->退出登录
登录系统->改卷->退出登录
用户-官方运维（发布试题、给考生分配监考老师）
登录系统->发布试题->退出登录
登录系统->给考生分配监考老师->退出登录
从项目的角度，分析需要进行性能测试点：
性能测试后调整了架构的业务。
逻辑复杂，关键的业务。
可能消耗大量资源的业务。
与外部系统存在接口调用，有大量数据交互的业务。
性能测试需求分析-指标定义（测试的标准）
响应时间、并发用户、成功率、内存、CPU、磁盘IO、网络IO，各指标的性能标准是什么？
标准的定义
需求文档中有定义，以需求文档为准
参考历史版本的数据
参考同行竞品
业界的标准，互联网类的产品，响应时间在1s
不同的场景，性能标准是不同的
性能测试需求分析-工具选型（用什么测）
测试工具选型
JMeter开源工具，对测试工程师要求不高，提供了参数化、函数、关联等功能
LoadRunner商用工具，需要购买的。市场占有率比较高，与JMeter相比，LoadRunner有很强大的脚本开发功能，完善的函数库以及结果分析功能。对测试工程师要求比较高，资料比较多，便于学习。
Python-Locust开源工具，对测试人员的代码能力有一定的要求。
自研
性能测试需求分析-评审（测的全不全）
可测性
性能测试尽可能模拟真实的运行环境。性能测试环境与生产环境差异比较大时，性能测试的结果不 可信。如果无法搭建与生产环境相似的环境，则认为不具备性能的可测性。
一致性
本次测试的需求是否满足用户需求规格说明书明确列出的性能需求项。
以历史性能数据以及现今的运行数据为基础，规划未来业务发展的可能性，确保测试指标具有一定 的冗余度。
正确性
保证SE/BA、开发、测试、项目经理等角色，对关注的性能需求、性能指标的正确理解，从而减少 返工、重新设计的风险。
性能测试计划
测试计划包括但不限于
明确性能测试范围
性能测试环境
性能测试所需的资料规划以及筹备计划
性能测试人员安排、进度安排
性能测试入口标准（达到什么样的情况，开始启动性能测试）
功能测试：冒烟通过
性能测试：3轮全量测试已经完成，系统没有重大的功能性问题
性能测试出口标准（达到什么样的情况，停止测试）
性能测试风险管理
性能测试用例设计
测试用例主要用于指导脚本开发工程师如何 开发一个性能测试脚本，应该明确操作流程、 开发方式、脚本优化方式等内容。
基准测试、压力测试和负载测试，只是测试 目的不同，往往只需设计一个脚本。
性能测试脚本开发
构造测试数据
1.从CSV文件读取
2.从数据库读取
3.函数生成数据
录制脚本
1.使用badboy录制脚本
2.修改脚本
3.必要时添加定时器
4.增加断言
场景设置
1.按照不同的测试场景、测试类型进行设置
2.设置线程数，持续时间等
示例-租车系统性能指标以及用例
定义系统指标：响应时间小于3s，内存、CPU使用小于80%，失败率在2%以内。
单业务测试
场景：查询车辆的接口
基准测试：查询车辆的接口，单个用户执行耗时。
负载测试：查询车辆的接口，在自己的测试环境上，最佳并发多少？最大并发多少？
压力测试：查询车辆的接口，最佳并发下，能稳定运行多久？
综合业务测试
场景：租车系统，十来个页面，多用户并发访问这些页面
稳定性测试：该场景，并发100个用户，是否能稳定运行2小时。
性能测试环境搭建
性能测试环境搭建，尽量与生产环境/现网环境/用户使用的环境保持一致
硬件环境搭建，建立近似真实的环境，服务器、数据库以及中间件的真实。
业务环境搭建
预置数据，最好将生产环境的数据导入进去
部署监控软件
服务器监控
ServerAgent：服务端性能监控，部署到服务上并启动，可以收集服务器上的资源信息，CPU，内 存，磁盘，网络。
普罗米修斯，监控Linux系统、mysql数据库等。
性能测试环境搭建-ServerAgent监控系统资源
PerfMon是JMeter用来监控系统资源的一款插件，可以用来监控系统的CPU、内存、I/O等性能指标。
安装方式
https://jmeter-plugins.org/wiki/PluginsManager/下载JMeter插件管理包，放到\lib\ext路径下， 重新启动JMeter。
选项->Plugins Manager，打开插件管理器，选择PerfMon安装。
依赖的工具
PerfMon的使用需要ServerAgent服务的支持，https://jmeter-plugins.org/wiki/PerfMonAgent 下载ServerAgent-2.2.1.zip。
ServerAgent与JMeter通信，使用TCP协议，4444端口。
Windows下启动startAgent.bat。
Linux下启动startAgent.sh。
在需要监控的服务器上运行ServerAgent。
指标
CPU：各指标项，数值都是代表百分比
Memory：usedperc(默认)和freeperc两项的数值代表与总内存的百分比，其余指标项的数值都是指 内存大小
Disks I/O：各指标项中，queue(默认)的数值代表等待I/O队列长度，reads、writes分别代表每秒处 理的读/写次数，readbytes、writebytes顾名思义，代表每秒读/写的数据量，单位同样在Metric Unit区域配置，通常Mb会比较适合观察。
性能测试执行
性能测试执行-监听器
监听器(Listener)负责收集测试结果，支持将结果数据写入文件。同时也被告知了结果显示的方 式。常用的包括：
聚合报告
汇总报告
查看结果树（性能测试时一般不用）
jp@gc - Active Threads Over Time，线程数和时间的关系图
jp@gc - Response Times Over Time，响应时间和时间的关系图
jp@gc - Transactions per Second，TPS
jp@gc - PerfMon Metrics Collector，CPU、内存等信息
性能测试执行-普通线程组加压
线程数：设置发送请求的用户数，也就是并发数。
Ramp-Up时间：线程启动时间，单位是秒。也就是线程在多少时间内全部启动。如果是0，则同时启动。 假设配置线程数为20，Ramp-Up时间配置为5，则会每隔5/20=0.25s启动一个线程，1秒启动4个线程。
循环次数：请求的重复次数，如果选择"永远"，那么请求将一直继续；如果输入数字，那么重复指定的次 数。
性能测试执行-Stepping Thread Group
这个可以模拟递增式并发(可以递增，也还可以递减)，并可设置递增次数、递增启动延迟、递增时长、到 达目标递增数量保持时长等。
This Group will start 100 threads：这次的测试总共100个线程。
First , wait for 0 seconds：等待0s后开始起线程，也就是不等待直接起线程。
Then start 0 threads：从0个线程开始持续增加。
Next，add 10 threads every 30 seconds：每增加10个线程后会运行30s，再起余下的10个线程，再运行30s， 以此类推。
Using ramp-up 5 seconds：前面每起10个线程的时候花5s，与上面结合起来即5s内起10个线程，运行30s，然 后再5s内再起10个线程，再运行30s，以此类推。
Then hold load for 60 seconds. ：全部的线程起来后，运行60s 后开始停止。
Finally , stop 5 threads every 1 seconds：最后停止线程，5个线程停一次，等1s再停5个线程。
性能测试执行-命令行模式执行
性能测试时，一般不启动jemter界面，使用命令行模式来执行
对于那些非交互的测试，可以使用非 GUI 的模式运行 JMeter。参数：
-n 指定的 JMeter 运行在 non-GUI 模式下。
-t 包含测试计划的 JMX 文件的名称。
-l 记录测试结果的 JTL 文件名称。
-r 运行所有的在 jmeter.properties 中指定的远程主机。(或在命令行中提供的覆盖属性提供的远程 主机名。也可以同时提供防火墙或者代理服务器的信息。
-H 服务器名或 IP 地址。
-P 端口号。
-e 测试结束后生成测试报告
-o 测试报告的存放路径。是一个不存在的文件夹，如果存在则报错。
性能测试执行-命令行执行并生成报告
jmeter -n -t 脚本名称 -l result.jtl -e -o 运行结果保存位置
示例：jmeter -n -t C:\Users\Desktop\Jmeter.jmx -l d:\result\result.jtl -e -o d:\result
jmeter -help 查看更多命令信息
注意：要将JMeter安装路径加入环境变量，否则无法识别JMeter命令。
性能问题的特征
通常情况下，系统出现性能问题的表象特征有以下几种，一旦出现以下情况，基本可以判定系 统存在性能问题：
响应时间平稳但较长：测试一开始，响应时间就很长，即使减少线程数量，减少负载，场景快执行 结束，响应时间仍然很长。负载的增加与否响应时间都很长。
响应时间逐步变长：测试时，负载不变，但是运行时间越长，响应时间越长，直至出现很多错误。
数据积累导致错误：开始运行正常，数据量增加到一定规模，出现错误，无法消除，只能重启系统。
应用程序崩溃：特定场景或运行周期很长以后，突然发生错误，系统运行缓慢、挂死、重启等问题。
内存溢出：运行一段时间，内存耗尽，内存不足。
服务器压力不均衡：多台服务器，只有一台CPU超过60%，其他都在60%以下。
TPS波动较大：
并发数不断增加，TPS上不去，CPU使用率较低：
压测过程中TPS不断下降，CPU使用率不断降低：
性能调优
性能测试是一个严谨的推理过程，一切以数据说话，在没有明确证据证明系统存在性能问题时， 千万不可随意调整代码、配置、甚至是架构。因为一旦调整，就必须重新开展功能以及性能回归测试，而且可能影响现网业务。
性能调优后，需做功能及性能回归测试，确保调优活动正确完成，且未造成额外的影响。
解决一个性能瓶颈，往往又会出现另外的瓶颈或者其他问题，所以性能优化更加切实的目标是 做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。
性能测试曲线
性能测试曲线解读
性能测试曲线模型是一条随着测试时间不断变化的曲线，与服务器资源，用户数或其他的性能指标密切相关的曲线。
坐标轴横轴，从左到右表现了并发用户数（Number of Concurrent Users）的不断增长。
2个点
The Optimum Number of Concurrent Users最佳并发用户数
The Maximum Number of Concurrent Users最大并发用户数
3条曲线
Utilization(U)：表示资源的利用情况，包括硬件资源和软件资源。在第一区域稳定增长，在第二区 域小幅增长，在第三个区，呈直线，表示饱和。
Throughput(X)：吞吐量，每秒事务数。随着并发用户数的增加，在前两个区，并发用户数的增加，请求增加，吞吐量增加，中间的区域，处理达到顶点。
Response Time(R)：响应时间。随着并发用户数的增加，在前两个区，响应时间基本平稳，小幅递 增。在第三个区域，急剧递增。在第三个区的点为拐点。
3个区
Light Load：轻压力区，等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也 不需要等待。
Heavy Load：重压力区，也就是系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以 继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有 些用户无法忍受而放弃。
Bockle Load：超负荷区，当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长 的响应时间而放弃。
怎么找到系统的拐点？所谓性能测试拐点，就是指并发用户达到一定数量，平均响应时间递增，TPS不增反降，报错率递增。
阶梯式加压法
先设定一个预估值进行测试，观察系统的响应情况，然后增加一定的数量， 观察系统的变化，直到系统超出我们所预估的值。比如，在并发测试的时候， 我们先预估设置并发用户为2000，然后以200的速度递增，检查系统的响应 时间是否小与3秒，从而找出并发测试的系统拐点
二分逼近法
先预估两个值m和n
先用m来进行测试，如果测试不通过，以m/2 继续测试。
如果m通过测试了，就用n值来进行测试，如果n值测试不通过，我们可以确 定拐点在m与n之间，于是取（m+n）/2继续测试。
如果n值测试通过了，拐点比n大，找一个比n大的数字x继续测试。
当最大值与最小值在500内，认为找到拐点
地铁进站案例
某地铁站进站只有3个刷卡机。人少的情况下，每位乘客很快就可以刷卡进站，假设进站需要 1s。乘客耐心有限，如果等待超过30min，就会暴躁、唠叨，甚至选择放弃。
场景1：1名乘客进站时，该乘客在1s时间内完成进站，且只利用了一台刷卡机，剩余2台。
场景2：2名乘客进站时，2名乘客在1s的时间内完成进站，且利用了2台刷卡机，剩余1台。
场景3：3名乘客进站时，3名乘客在1s的时间内完成进站，且利用了3台刷卡机，资源得到充分利用。
场景4：随着上班高峰的到来，乘客也越来越多，6名乘客进站，A、B、C乘客进站时间为1s，而D、 E、F乘客进站的时间是2s（1s等待时间+1s进站时间），响应时间延长了。
场景5：10名乘客进站，有3名的“响应时间”为1s，有3名的“响应时间”为2s（等待1s+进站1s）， 还有3名的“响应时间”为3s（等待2s+进站1s），1名乘客的“响应时间”为4s（等待3s+进站1s）， 如果随着大量的人流涌入进站，可想而知就会达到乘客的忍耐极限。
场景6：如果地铁正好在火车站，比如西安北客站。每名乘客拿着大小不同的包，有的乘客拿的包太 大导致卡在刷卡机那堵塞，这样每名乘客的进站时间会又不一样。
解决办法
地铁进站的刷卡机有加宽的和正常宽度的两种类型，那么拿大包的乘客可以通过加宽的刷卡机快速进 站（增加带宽）。
多开几个刷卡机，增加进站的人流与速度（提升TPS）。
通过增加发车频率（加快应用/数据库的处理速度）
增加车厢数量（增加内存、增大吞吐量） ü 增加线路（增加服务的线程）
限流、分流等多种措施来解决问题。
