性能综述：性能测试的概念到底是什么？

性能综述：性能测试的概念到底是什么？
性能测试概念
网上针对这三个名词的解释是这样的：
压力测试
压力测试是评估系统处于或超过预期负载时系统的运行情况。压力测试的关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。在压力级别逐渐增加时，系统性能应该按照预期缓慢下降，但是不应该崩溃。压力测试还可以发现系统崩溃的临界点，从而发现系统中的薄弱环节。
容量测试
确定系统可处理同时在线的最大用户数，使系统承受超额的数据容量来发现它是否能够正确处理。
极限测试
在过量用户下的负载测试。
我总结的概念：
性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。

这是我觉得唯一合理的概念定义，下面我就把这个概念详细解释一下。

性能测试需要有指标
应该有的指标是：时间指标、容量指标和资源利用率指标。

性能测试需要有模型

模型是什么？它是真实场景的抽象，可以告诉性能测试人员，业务模型是什么样子。比如说，我们有 100 种业务，但不是每个业务都需要有并发量，可能只有 50 个业务有，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例。

性能测试要有方案
方案规定的内容中有几个关键点，分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。基本上有这些内容就够了，这些内容具体的信息还需要精准。

性能测试中要有监控
这个部分的监控，要有分层、分段的能力，要有全局监控、定向监控的能力。关于这一点，我将在第三模块详细说明。
性能测试要有预定的条件
这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容。要是展开来说，在场景执行之前，这些条件应该是确定的。

性能测试中要有场景
可以说，“性能场景”这个词在性能测试中占据着举足轻重的地位，只是我们很多人都不理解“场景”应该如何定义。场景来源于英文的 scenario，对性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。
性能场景也要有分类，在我有限的工作经验中，性能场景从来都没有超出过这几个分类。
基准性能场景：这里要做的是单交易的容量，为混合容量做准备（不要跟我说上几个线程跑三五遍脚本叫基准测试，在我看来，那只是场景执行之前的预执行，用来确定有没有基本的脚本和场景设计问题，不能称之为一个分类）。
容量性能场景：这一环节必然是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多个，在概念部分就不细展开了，我会在后面的文章中详细说明。
稳定性性能场景：稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中，稳定性测试基本没和生产一致过。在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的心理安全感。
异常性能场景：要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。这个异常的定义是很宽泛的，在下一篇文章里，我们再细说。

思考题
为什么不推荐使用性能测试、负载测试、容量测试这样的词来概括性能执行策略呢？
@zzw 网友用博弈论的概念对这个问题做出解答，受到一些启发，个人理解是：性能测试、负载测试、容量测试这样的词因为之间的界限非常模糊，不好理解和运用到实际工作中，每个人对其的理解都不同，所以只能作为共有知识。而新定义的性能测试概念，定义相对明确，易运用到实际工作之中，可以作为共同知识。
为什么性能测试中要有监控和分析？
性能测试是一个过程，没有监控和分析就没有结果，也无法调优。