性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件下执行性能场景，分析判断性能瓶颈并且调优，最终得出性能结果来评估系统的性能指标是否满足既定值。
针对这个性能测试概念的解读，如下：
性能测试需要有指标：
但是这些指标还可以再进行细分.......
性能测试需要有模型：
模型是什么？它是真实场景的抽象。比如说，我们有100种业务，但不是每个业务都需要有并发量，可能只有50个业务有，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例。
其实就是我们需要挑选出来需要并发的业务，还要区分这些业务各自的并发是多少，有不同的并发比例。这些数据最好都是从生产环境获取。
性能测试要有方案：
一个方案中包含着：测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险这些关键点。
性能测试中要有监控：
这个部分的监控，要有分层、分段的能力，要有全局监控、定向监控的能力
性能测试要有预定的条件：
这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容，在场景执行之前，这些条件应该是确定的。
性能测试中要有场景：
对性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。这才是真正的场景全貌。
性能场景也要有分类
性能测试中要有分析调优：
就要不要进行调优做了如下划分
对性能团队的职责定位有如下几种。
当只能做性能验证的团队遇到旧系统新版本性能测试类和新系统性能测试优化类项目，那就会很吃力，这样的团队只能做新系统性能测试类项目。
当做性能测试的团队，遇到需要新系统性能测试优化类项目，照样很吃力。这样的团队能做前两种项目。
只有第三个团队才能做第三种项目。
性能测试肯定要有结果报告：
性能结果如何来定义呢？有了前面监控的定义，有了场景执行的过程，产生的数据就要整理到结果报告中了。
这个文档工作也是很重要的，是体现性能团队是否专业的一个重要方面。并不是整理一个Word，美化一下格式就可以了。
测试报告是需要汇报或者归档的。
总结：
在性能测试的概念中，性能指标、性能模型、性能场景、性能监控、性能实施、性能报告，这些既是概念中的关键词，也可以说是性能测试的方法和流程。
首先，性能要有场景，性能场景要有基准性能场景、容量性能场景、稳定性性能场景、异常性能场景
然后来看一张图，分析这张图：
在这个图中，定义了三条曲线、三个区域、两个点以及三个状态描述。
另外，吞吐量曲线不一定会出现下降的情况，在有些控制较好的系统中会维持水平。
有经验的性能测试人员，都会更关心服务端能处理的请求数即TPS，而不是压力工具中的线程数
这张图没有考虑到锁或线程等配置不合理的场景，而这类场景又比较常见。也就是我们说的，TPS上不去，资源用不上。所以这个图默认了一个前提，只要线程能用得上，资源就会蹭蹭往上涨。
用场景的定义来替换这些混乱的概念
通常大家认为的性能测试、负载测试、压力测试在操作的层面，只有压力工具中线程数的区别
在性能中，我们有非常多的配置，像JVM参数、OS参数、DB参数、网络参数、容器参数等等
在一般的性能场景中，递增都是必不可少的过程。同时，递增的过程，也要是连续的，而不是100线程、200线程、300线程这样断开执行场景，这样是不合理的。
总之，在具体的性能项目中，性能场景是一个非常核心的概念。因为它会包括压力发起策略、业务模型、监控模型、性能数据（性能中的数据，我一直都不把它称之为模型，因为在数据层面，测试并没有做过什么抽象的动作，只是使用）、软硬件环境、分析模型等
3.怎么理解TPS、QPS、RT、吞吐量这些性能指标？
通常我们都从两个层面定义性能场景的需求指标：业务指标和技术指标。
这两个层面需要有映射关系，技术指标不能脱离业务指标。
这张示意图以便你理解业务指标和性能指标之间的关系
这个示意显然不够详细，但也能说明关系了。所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程。这样一来，技术指标就不会是一块飞地。同时，在回答了技术指标是否满足的同时，也能回答是否可以满足业务指标。
有了这样的关联关系，下面我们看一下性能测试行业常用的性能指标表示法。
QPS一开始是用来描述MySQL中SQL每秒执行数QueryPerSecond，所有的SQL都被称为Query
QPS和TPS到底是什么关系呢？
RPS指的是每秒请求数。这个概念字面意思倒是容易理解，但是有个容易误解的地方就是，它指的到底是哪个层面的Request？如果说HTTPRequest，那么和HitsPerSecond又有什么关系呢？
HPS，这也是个在字面意思上容易理解的概念。只是Hit是什么？有人将它和HTTPRequest等价，有人将它和用户点击次数等价。
通常情况下，我们会根据场景的目的来定义TPS的粒度。如果是接口层性能测试，T可以直接定义为接口级；如果业务级性能测试，T可以直接定义为每个业务步骤和完整的业务流。
用一个示意图来说明一下。
如果我们要单独测试接口1、2、3，那T就是接口级的；如果我们要从用户的角度来下一个订单，那1、2、3应该在一个T中，这就是业务级的了
当然，这时我们还要分析系统是如何设计的。通常情况下，积分我们都会异步，而库存不能异步哇。所以这个业务，你可以看成只有1、2两个接口，但是在做这样的业务级压力时，3接口也是必须要监控分析的。
所以，性能中TPS中T的定义取决于场景的目标和T的作用。一般我们都会这样来定事务。
接口级脚本：
——事务start（接口1）
接口1脚本
——事务end（接口1）
——事务start（接口2）
接口2脚本
——事务end（接口2）
——事务start（接口3）
接口3脚本
——事务end（接口3）
业务级接口层脚本（就是用接口拼接出一个完整的业务流）：
——事务start（业务A）
接口1脚本-接口2（同步调用）
接口1脚本-接口3（异步调用）
——事务end（业务A）
用户级脚本
点击0-接口1脚本-接口2（同步调用）
点击0-接口1脚本-接口3（异步调用）
你要创建什么级别的事务，完全取决于测试的目的是什么，在性能测试过程中，TPS之所以重要，是因为它可以反应出一个系统的处理能力。
首先是QPS，如果它描述的是数据库中的QueryPerSecond，从上面的示意图中来看，其实描述的是服务后面接的数据库中SQL的每秒执行条数。如果描述的是前端的每秒查询数，那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体的性能是不够全面的。所以不建议用QPS来描述系统整体的性能，以免产生误解。
RPS（Requestpersecond），每秒请求数。看似简单的理解，但是对于请求数来说，要看是在哪个层面看到的请求，因为请求这个词，实在是太泛了。
HPS（HitsPerSecond），每秒点击数。Hit一般在性能测试中，都用来描述HTTPRequest。当它描述HTTPRequest时，如果RPS也在描述HTTPRequest，那这两个概念就完全一样了。
所有服务的进出口上都做记录，然后计算结果就行了。在做网关、总线这样的系统时，基本上都会考虑这个功能。而现在，随着技术的发展，链路监控工具和一些Metrics的使用，让这个需求变得简单了不少。比如说这样的展示：
为什么要性能测试团队来主导协调其他团队的人一起来分析瓶颈点
（重点）压力工具中的线程数和用户数与TPS
但是做性能的都会知道，并发线程数在没有模拟真实用户操作的情况下，和真实的用户操作差别非常远。
现在很多人都没有明白压力工具中的线程数和用户以及TPS之间是怎样的关系。同样，我们先画一个示意图来说明一下。
这里先说明一个前提，上面的一个框中有四个箭头，每个都代表着相同的事务。
在说这个图之前，我们要先说明“并发”这个概念是靠什么数据来承载的。
在上面的内容中，我们说了好多的指标，但并发是需要具体的指标来承载的。你可以说，我的并发是1000TPS，或者1000RPS，或者1000HPS，这都随便你去定义。但是在一个具体的项目中，当你说到并发1000这样没有单位的词时，一定要让大家都能理解这是什么。
在上面这张示意图中，其实压力工具是4个并发线程，由于每个线程都可以在一秒内完成4个事务，所以总的TPS是16。这非常容易理解吧。而在大部分非技术人的脑子里，这样的场景就是并发数是4，而不是16。
那么用户数怎么来定义呢？涉及到用户就会比较麻烦一点。因为用户有了业务含义，所以有些人认为一个系统如果有1万个用户在线，那就应该测试1万的并发线程，这种逻辑实在是不技术。通常，我们会对在线的用户做并发度的分析，在很多业务中，并发度都会低于5%，甚至低于1%。
通过这样简单的计算逻辑，我们就可以看出来用户数、线程数和TPS之间的关系了。
所以，在性能分析中，我一直在强调着一个词：趋势！
业务模型应该如何得到呢？这里有两种方式是比较合理的：
总结:
性能测试策略、性能测试场景、性能测试指标，这些关键的概念在性能测试中深深地影响着很多人。我们简化它的逻辑，只需要记住几个关键字就可以，其他的都不必使用。
4.JMeter和LoadRunner：要知道工具仅仅只是工具
JMeter、LoadRunner的基本功能基本就做了两件事情，做脚本和发压力
在性能场景学习期这个阶段，你关心的将不再是工具的使用操作，而是如何做一个合理的性能测试。你可以学会调整业务比例，并设计到压力工具中；你可以学会参数化数据的提取逻辑；你可以学会场景中要观察哪些数据。按照这个思路，再做几个项目，就会慢慢摸着一些门道。
学会使用工具了，也有了场景设计的经验，通过监控工具也拿到了一堆大大小小的数据。可是，数据也太多了，还在不断的变化。我又怎么判断性能瓶颈在哪里呢？
我们应该知道我们针对一个性能压测结果，我需要看什么数据，我想要看什么数据，而不是“把数据都给我看看”。
公司性能团队成长的三个阶段阶段
性能团队初建
性能团队初成熟
到了这个阶段，团队已经可以应付版本的更迭带来的性能工作压力，团队合作良好，稍有余力，开始考虑团队价值所在，在公司的组织结构中应该承担什么样的职责。在产品的流水线上终于可以占有一席之地了。这样很好，只是从实际的技术细节上来说，仍然没有摆脱第一阶段中琐碎的工作，没有把性能的价值体现出来，只是一个报告提供机器。这时就需要考虑平台上是不是可以加个SLA来限制一下？在各个流程的关卡上，是不是可以做些性能标准？是不是该考虑下准入准出规则了？是的，这时一个团队开始慢慢走向成熟，站住脚之后要开始争取尊重了。
性能团队已成熟
直观上说，主要体现在一下几个方面。
1.通过你的测试和分析优化之后，性能提升了多少？
一个成熟的团队应该回答的是：提升了10倍，我们调优了什么。这样的回答有理有据，底气十足。
2.通过你的测试和分析优化之后，节省了多少成本？
这个问题就没有那么好回答了，因为你要知道整体的容量规划，线上的真实运营性能。如果之前的版本用了200台机器，而通过我们的测试分析优化之后，只用到了100台机器，那成本就很明显了。
对个人以及团队来说，工具应该如何选择
比较常见的工具做下比对
所以在压测工具中同时收集监控计数器，就是不符合真实场景的。这样压测平台就有出现的必要了，我们可以看到出现了五花八门的压测平台，也会有后端监控数据的曲线，乍看起来，就两个字：全面！可是，同样也没有告诉你瓶颈在哪里。
压测工具也好，压测平台也好，都没有一个工具可以直接告诉你瓶颈在哪里，能告诉你的只是数据是什么。分析只有靠自己，在这个过程中，我们也会用到很多的分析剖析工具，用这些工具的人也都会知道，工具也只提供数据，不会告诉你瓶颈点在哪里。
如果选择合适自己的工具？
所以我们用工具，一定要知道几点：
对企业，举例来说：
如果是一个需要支持万级、亿级TPS的电商网站，本身就是云基础架构，那么可能最简单的就是直接买这家的云压测工具就好了。这样做的优点是不用再买机器做压力了。压力发起，主要就是靠压力机的量堆出来大并发
但缺点也很明显，一是不能长期使用，长期用，费用就高了。二是数据也只能自己保存比对，如果测试和版本跨度大，还是要自己比对，无法自动比对。最后一个缺点就是压力机不受控了。
所以如果有这样需求的企业，也基本上可以自己开发一套云压测工具了，从使用周期和长远的成本上来看，自已开发，都是最划算的。
如果是一个需要支持每秒100TPS的企业内部业务系统，就完全没必要买什么云服务了，自己找一台4C8G的机器，可能就压得够了。
5.你知道并发用户数应该怎么算吗？
在不同的测试目标中设置不同的事务，也就是TPS中的T要根据实际的业务产生变化。那么问题又来了，TPS和并发数是什么关系呢？在并发中谁来承载”并发“这个概念呢？
我们先说一下所谓的“绝对并发”和“相对并发”这两个概念。
什么是并发？
我们假设上图中的这些小人是严格按照这个逻辑到达系统的，那显然，系统的绝对并发用户数是4。如果描述1秒内的并发用户数，那就是16。是不是显而易见？但是，在实际的系统中，用户通常是这样分配的：
也就是说，这些用户会分布在系统中不同的服务、网络等对象中。这时候”绝对并发“这个概念就难描述了，你说的是哪部分的绝对并发呢？
所以“绝对并发”这个概念，不管是用来描述硬件细化的层面，还是用来描述业务逻辑的层面，都是没什么意义的。
我们只要描述并发就好了，不用有“相对”和“绝对”的概念，这样可以简化沟通，也不会出错。
那么如何来描述上面的并发用户数呢？在这里我建议用TPS来承载“并发”这个概念。并发数是16TPS，就是1秒内整个系统处理了16个事务。这样描述就够了，别纠结。
在线用户数、并发用户数怎么计算
在线用户数和并发用户数应该如何算呢？下面我们接着来看示意图：
如上图所示，总共有32个用户进入了系统，但是绿色的用户并没有任何动作，那么显然，在线用户数是32个，并发用户数是16个，这时的并发度就是50%。
但在一个系统中，通常都是下面这个样子的。
为了能hold住更多的用户，我们通常都会把一些数据放到Redis这样的缓存服务器中。所以在线用户数怎么算呢，如果仅从上面这种简单的图来看的话，其实就是缓存服务器能有多大，能hold住多少用户需要的数据。
最多再加上在超时路上的用户数。如下所示：
所以我们要是想知道在线的最大的用户数是多少，对于一个设计逻辑清晰的系统来说，不用测试就可以知道，直接拿缓存的内存来算就可以了。
假设一个用户进入系统之后，需要用10k内存来维护一个用户的信息，那么10G的内存就能hold住1,048,576个用户的数据，这就是最大在线用户数了。在实际的项目中，我们还会将超时放在一起来考虑。
但并发用户数不同，他们需要在系统中执行某个动作。我们要测试的重中之重，就是统计这些正在执行动作的并发用户数。
当我们统计生产环境中的在线用户数时，并发用户数也是要同时统计的。这里会涉及到一个概念：并发度。
要想计算并发用户和在线用户数之间的关系，都需要有并发度。
那么该如何计算或者估算并发度呢？
1.统计某时段的当前在线用户数；2.统计同一时段的操作某个功能的用户数；3.把所有功能操作的用户数都统计出来；4.将统计出来的用户数除以在线用户数就知道并发度了。
服务端线程的工作情况图在哪看？
java的可以用jvisuamvm之类的工具看
做性能的人都知道，我们有时会接到一个需求，那就是一定要测试出来系统最大在线用户数是多少。这个需求怎么做呢？
那就是压力工具中的线程或用户数到底是不是用来描述性能表现的？我们通过一个示意图来说明：
通过这个图，我们可以看到一个简单的计算逻辑：
而我们通常说的“并发”这个词，依赖TPS来承载的时候，指的都是Server端的处理能力，并不是压力工具上的并发线程数。在上面的例子中，我们说的并发就是指服务器上100TPS的处理能力，而不是指5个压力机的并发线程数。
上面说了这么多，我们现在来看一个实例。
这个例子很简单，就是：
JMeter（1个线程）-Nginx-Tomcat-MySQL
通过上面的逻辑，我们先来看看JMeter的处理情况：
summary+5922in00:00:30=197.4/sAvg:4Min:0Max:26Err:0(0.00%)Active:1Started:1Finished:0summary=35463in00:03:05=192.0/sAvg:5Min:0Max:147Err:0(0.00%)summary+5922in00:00:30=197.5/sAvg:4Min:0Max:24Err:0(0.00%)Active:1Started:1Finished:0summary=41385in00:03:35=192.8/sAvg:5Min:0Max:147Err:0(0.00%)summary+5808in00:00:30=193.6/sAvg:5Min:0Max:25Err:0(0.00%)Active:1Started:1Finished:0summary=47193in00:04:05=192.9/sAvg:5Min:0Max:147Err:0(0.00%)
那么对于服务端呢，我们来看看服务端线程的工作情况。
可以看到在服务端，我开了5个线程，但是服务端并没有一直干活，只有一个在干活的，其他的都处于空闲状态。这是一种很合理的状态。但是你需要注意的是，这种合理的状态并不一定是对的性能状态。
下面我们换一下场景，在压力机上启动10个线程。结果如下：
再回来看看服务端的线程：
同样是5个线程，现在就忙了很多。
如果要有公式的话，这个计算公式将非常简单：
下面公司代表个人理解：
理论TPS计算：
TPS=在线用户数*并发度
实际TPS计算：
但是通常服务端都是有业务逻辑的，既然有业务逻辑，显然不会比压力机快。应该说，服务端需要更多的线程来处理压力机线程发过来的请求。所以我们用几台压力机就可以压几十台服务端的性能了。