性能：到底什么是性能测试

概念

我们经常看到的性能测试概念，有人或称之为性能策略，或称之为性能方法，或称之为性能场景分类，大概可以看到性能测试、负载测试、压力测试、强度测试等一堆专有名词的解释。但是这些东西（压力测试、容量测试、负载测试等等），在实际的项目实施过程中，都不具备全局的指导价值。你应该在性能领域中抛弃这些看似非常有道理实则毫无价值的概念。

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

性能测试需要有指标

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

• 时间指标：响应时间
• 容量指标：最大用户数
• 资源利用率指标：系统CPU，内存

性能测试需要有模型

模型是什么？

它是真实场景的抽象，可以告诉性能测试人员，业务模型是什么样子。

比如说，我们有100 种业务，但不是每个业务都需要有并发量，可能只有 50 个业务有，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例

这种做法需要的数据通常都是从生产环境中的数据中统计来的，很多在线上不敢直接压测的企业都是这样做的。

性能测试要有方案

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

测试计划请用单独的项目管理工具比如project、omniplan画。

性能测试中要有监控

这个部分的监控，要有分层、分段的能力，要有全局监控，定向监控的能力

性能测试中要有预定的条件

这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容。要是展开来说，在场景执行之前，这些条件应该是确定的。

有人说，我们压力中也会动态扩展。没问题，但是动态扩展的条件或者判断条件，也是有确定的策略的，比如说，我们判断CPU 使用率达到 80% 或 I/O 响应时间达到 10ms 时，就做动态扩展。这些也是预定的条件。

性能测试要有场景

场景指的是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。

场景分为如下几类：

• 基准性能场景
• 容量性能场景：最核心的性能执行部分
• 稳定性性能场景：在稳定性测试中，最核心的元素是时间
• 异常性能场景：要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常

很多性能测试工程师，都把场景叫成了测试用例。如果只是叫法不同，我觉得倒是可以接受，关键是内容也出现了很大的偏差，这个偏差就是，把用例限定在了描述测试脚本和测试数据上，并没有描述需要实时的判断和动态的分析。这就严重影响了下一个概念：性能结果。

性能测试中要有分析调优

对于系统要不要调优，必须综合来看

对性能项目分为如下几类。

• 新系统性能测试类：这样的项目一般都会要求测试出系统的最大容量，不然上线心里没底
• 旧系统新版本性能测试类：这样的项目一般都是和旧版本对比，只要性能不下降就可以根据历史数据推算容量，对调优要求一般都不大。
• 新系统性能测试优化类：这类的系统不仅要测试出最大容量，还要求调优到最好。

对性能团队的职责定位有如下几种。

• 性能验证：针对给定的指标，只做性能验证。第三方测试机构基本上都是这样做的。
• 性能测试：针对给定的系统，做全面的性能测试，可以得到系统最大容量，但不涉及到调优。
• 性能测试+分析调优：针对给定的系统，做全面的性能测试，同时将系统调优到最优状态。

性能测试肯定要有结果报告

性能结果如何来定义呢？有了前面监控的定义，有了场景执行的过程，产生的数据就要整理到结果报告中了。这个文档工作也是很重要的，是体现性能团队是否专业的一个重要方面。并不是整理一个Word，美化一下格式就可以了。测试报告是需要汇报或者归档的。

如果是内部项目，测试报告可能就是一个表格，发个邮件就完整了，另外归档也是必须的。而对一些有甲乙方的项目，就需要汇报了。

那么，如何汇报呢？

• 我们要知道，大部分老板或者上司关心的是测试的结果，而不是用了多少人，花了多少时间这些没有意义的数字。
• 我们更应该在报告中写上调优前后的TPS、响应时间以及资源对比图。

有了上面的的解析，相信你对性能测试的定义有了明确的感觉了。这个定义其实就是描述了性能测试中要做的事情。

当然，也许会有人跳出来说，你这个说得太重了，不够敏捷。现在不都用DevOps了吗？还要按这个流程来走一遍吗？

显然有这种说法的人，没有理解我要说的主旨。以上的内容是针对一个完整的项目，或系统或公司的系统演进。对于一些半路就跟着版本和新需求一轮轮迭代做下去的人的处境会不同，因为这样的人只看到了当前的部分，而不是整个过程。

并且这个过程也是不断在迭代演进的。

不管是敏捷开发过程还是DevOps，你可以一条条去仔细分析下项目中的各个环节

总结

• 不要再使用像性能测试、负载测试、容量测试这样的词来概括性能执行策略，这是对实施过程没有任何指导价值的。

• 在性能测试的概念中，性能指标、性能模型、性能场景、性能监控、性能实施、性能报告，这些既是概念中的关键词，也可以说是性能测试的方法和流程。

• 而这些概念我们在实际的工作中，都是非常重要的。因为它们要抹平沟通的误解。让不同层级，不同角色的人，可以在同样的知识背景下沟通，也可以让做事情的人有清晰的逻辑思路，同时对同行间的交流，也有正向的促进作用。