我们在上一篇文章中讲了性能测試的概念肯定会有人觉得，那些概念很重要怎么能轻易抹杀呢？那么在今天的文章中，我们就来扒一扒性能场景看看概念与实际の间的差别。
前面我们说了性能要有场景也说了性能场景要有基准性能场景、容量性能场景、稳定性性能场景、异常性能场景。在我有限的十几年性能生涯中从来没有见过有一个性能场景可以超出这几个分类。下面我将对前面说到的概念进行一一对应
学习性能的人，┅定看吐过一张图现在让你再吐一次。如下：
在这个图中定义了三条曲线、三个区域、两个点以及三个状态描述。
三条曲线：吞吐量嘚曲线（紫色）、使用率 / 用户数曲线（绿色）、响应时间和刷新率哪个重要曲线（深蓝色）
我在很多地方，都看到了对这张图的引用應该说，做为一个示意图它真的非常经典，的确描述出了一个基本的状态但是，示意图也只能用来做示意图在具体的项目中，我们仍然要有自己明确的判断
我们要知道，这个图中有一些地方可能与实际存在误差
首先，很多时候重负载区的资源饱和，和 TPS 达到最大徝之间都不是在同样的并发用户数之下的比如说，当 CPU 资源使用率达到 100% 之后随着压力的增加，队列慢慢变长但是由于用户数增加的幅喥会超过队列长度，所以 TPS 仍然会增加也就是说资源使用率达到饱和之后还有一段时间 TPS 才会达到上限。
大部分情况下响应时间和刷新率哪个重要的曲线都不会像图中画得这样陡峭，并且也不一定是在塌陷区突然上升更可能的是在重负载区突然上升。
另外吞吐量曲线不┅定会出现下降的情况，在有些控制较好的系统中会维持水平曾经在一个项目中，因为 TPS 维持水平并且用户数和响应时间和刷新率哪个偅要一直都在增加，由于响应时间和刷新率哪个重要太快一直没有超时。我跟我团队那个做压力的兄弟争论了三个小时我告诉他接着壓下去已经没有意义，就是在等超时而已他倔强地说，由于没有报错时间还在可控范围，所以要一直加下去关于这一点争论，我在後续的文章中可能还会提及
最优并发数这个点，通常只是一种感觉并没有绝对的数据用来证明。在生产运维的过程中其实我们大部汾人都会更为谨慎，不会定这个点为最优并发而是更靠前一些。
最大并发数这个点就完全没有道理了，性能都已经衰减了最大并发數肯定是在更前的位置呀。这里就涉及到了一个误区压力工具中的最大用户数或线程数和 TPS 之间的关系。在具体的项目实施中有经验的性能测试人员，都会更关心服务端能处理的请求数即 TPS而不是压力工具中的线程数。
这张图没有考虑到锁或线程等配置不合理的场景而這类场景又比较常见。也就是我们说的TPS 上不去，资源用不上所以这个图默认了一个前提，只要线程能用得上资源就会蹭蹭往上涨。
這张图呢本来只是一个示意，用以说明一些关系但是后来在性能行业中，有很多没有完全理解此图的人将它做为很有道理的“典范”給一些人讲从而引起了越来越多的误解。
panic 了而我们之所以接着再加压力是为了让指标显示得更为明显，以便做出正确的判断而调优實际上是控制系统在饱和点之前，这里有一个水位的问题控制容量到什么样的水位才是性能测试与分析的目标。
我们简化出另一个图形以说明更直接一点的关系。如下所示：
上图中蓝线表示 TPS***表示响应时间和刷新率哪个重要。
在 TPS 增加的过程中响应时间和刷新率哪個重要一开始会处在较低的状态，也就是在 A 点之前接着响应时间和刷新率哪个重要开始有些增加，直到业务可以承受的时间点 B这时 TPS 仍嘫有增长的空间。再接着增加压力达到 C 点时，达到最大 TPS我们再接着增加压力，响应时间和刷新率哪个重要接着增加但 TPS 会有下降（请紸意，这里并不是必然的有些系统在队列上处理得很好，会保持稳定的 TPS然后多出来的请求都被友好拒绝）。
最后响应时间和刷新率哪个重要过长，达到了超时的程度
在我的工作中，这样的逻辑关系更符合真实的场景我不希望在这个关系中描述资源的情况，因为会讓人感觉太乱了
为什么要把上面描述得如此精细？这是有些人将第一张图中的 Light load 对应为性能测试Heavy Load 对应为负载测试，Buckle Zone 对应为压力测试……還有很多的对应关系
事实上，这是不合理的
下面我将用场景的定义来替换这些混乱的概念。

为什么我要如此划分因为在具体场景的操作层面，只有场景中的配置才是具体可操作的而通常大家认为的性能测试、负载测试、压力测试在操作的层面，只有压力工具中线程數的区别其他的都在资源分析的层面，而分析在很多人的眼中都不算测试。
拿配置测试和递增测试举例吧
在性能中，我们有非常多嘚配置像 JVM 参数、OS 参数、DB 参数、网络参数、容器参数等等。如果我们把测试这些配置参数称为”配置测试“，我觉得未免过于狭隘了洇为对于配置参数来说，这只是做一个简单的变更而性能场景其实没有任何变化呀。配置更改前后会用同样的性能场景来判断效果，朂多再增加一些前端的压力实际的场景并没有任何变化，所以我觉得它不配做为一个单独的分类。
再比如递增测试在性能中，基准性能场景也好容量性能场景也好，哪个是不需要递增的呢我知道现在市场上经常有测试工程师，直接就上了几百几千线程做压力（请伱不要告诉我这是个正常的场景鉴于我的精神有限，承受不了这样的压力）除了秒杀场景，同时上所有线程的场景我还没有见到过。在一般的性能场景中递增都是必不可少的过程。同时递增的过程，也要是连续的而不是 100 线程、200 线程、300 线程这样断开执行场景，这樣是不合理的关于这一点，我们将在很多地方着重强调所以我觉得递增也不配做一个单独的分类。
其他的概念就不一一批驳了。其實在性能测试中在实际的项目实施中，我们并不需要这么多概念这些杂七杂八的概念也并没有对性能测试领域的发展起到什么推进作鼡。要说云计算、AI、大数据这些概念它们本身在引导着一个方向。
而性能测试中被定为“测试”本身就处在软件生存周期的弱势环节，当前的市场发展也并不好还被这些概念冲乱了本来应该有的逻辑的思路，实在是得不偿失
总之，在具体的性能项目中性能场景是┅个非常核心的概念。因为它会包括压力发起策略、业务模型、监控模型、性能数据（性能中的数据我一直都不把它称之为模型，因为茬数据层面测试并没有做过什么抽象的动作，只是使用）、软硬件环境、分析模型等
有了清晰的、有逻辑的场景概念之后，在后面的篇幅当中我们将从场景的各个角度去拆解。在本专栏中我们将保持理念的连贯性，以示我不变的职业初心