一  真正性能测试的真正含义和工作内容

刚开始，以为做性能测试，就是做些脚本、参数化、关联，压起来之后，再扔出一个结果。

但实际上不止这些内容，还要加上性能分析，关注调优之后响应时间有多大的提升，TPS 有多大的提高，资源有多少的节省

我们努力的方向是完整的工程，既要有前期的测试，还要有中间的分析，以及最后的调优，而不仅仅是做做脚本。如果你想把性能测试做好，就不要局限自己的技术范围和认知范围。无论是系统、数据库、代码、中间件、存储、网络，你遇到什么问题，都要试着去分析下该如何判断，并考虑如何在后续的过程中进行调优。

二  性能测试的概念

性能测试针对 1）系统的性能指标，2）建立性能测试模型，3）制定性能测试方案，4）制定监控策略，5）在场景条件之下执行性能场景，6）分析判断性能瓶颈并调优，7）最终得出性能结果来，8）评估系统的性能指标是否满足既定值。

性能测试概念

1. 性能测试需要有指标

有人说，我们在做项目的时候，就没有指标，老板只说一句，系统压死为止。听起来很儿戏，但这样的场景不在少数。在我看来，把系统压死也算是一种指标。至于你用什么手段把系统“压死”，那就是实现的问题了

时间指标：响应时间

容量指标：最大用户数

资源利用率指标：系统CPU，内存

2. 性能测试需要有模型

模型是什么？它是真实场景的抽象，可以告诉性能测试人员，业务模型是什么样子。比如说，我们有100 种业务，但不是每个业务都需要有并发量，可能只有 50 个业务有，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例。这种做法需要的数据通常都是从生产环境中的数据中统计来的，很多在线上不敢直接压测的企业都是这样做的。

3. 性能测试要有方案

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

4. 性能测试要有预定的条件

这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容。要是展开来说，在场景执行之前，这些条件应该是确定的。有人说，我们压力中也会动态扩展。没问题，但是动态扩展的条件或者判断条件，也是有确定的策略的，比如说，我们判断CPU 使用率达到 80% 或 I/O 响应时间达到 10ms 时，就做动态扩展。这些也是预定的条件。

5. 性能测试中要有场景

基准性能场景：这里要做的是单交易的容量，为混合容量做准备（不要跟我说上几个线程跑三五遍脚本叫基准测试，在我看来，那只是场景执行之前的预执行，用来确定有没有基本的脚本和场景设计问题，不能称之为一个分类）。

容量性能场景：这一环节必然是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多个。

稳定性性能场景：稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中，稳定性测试基本没和生产一致过。在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的心理安全感。

异常性能场景：要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。这个异常的定义是很宽泛的。

6. 性能测试中要有分析调优

新系统性能测试类：这样的项目一般都会要求测试出系统的最大容量，不然上线心里没底。

旧系统新版本性能测试类：这样的项目一般都是和旧版本对比，只要性能不下降就可以根据历史数据推算容量，对调优要求一般都不大。

新系统性能测试优化类：这类的系统不仅要测试出最大容量，还要求调优到最好。