【性能测试】性能测试的概念到底是什么

一、传统意义上的性能测试名词解释

压力测试：

压力测试是评估系统处于或超过预期负载时系统的运行情况。压力测试的关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。在压力级别逐渐增加时，系统性能应该按照预期缓慢下降，但是不应该崩溃。压力测试还可以发现系统崩溃的临界点，从而发现系统中的薄弱环节。

容量测试：

确定系统可处理同时在线的最大用户数，使系统承受超额的数据容量来发现它是否能够正确处理。　　

极限测试：

在过量用户下的负载测试。

 

二、性能测试合理定义：

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

　　

总结一下性能测试的概念：

1、性能测试需求指标

有人说，我们在做项目的时候，就没有指标，老板只说一句，系统压死为止。听起来很儿戏，但这样的场景不在少数。在我看来，把系统压死也算是一种指标。至于你用什么手段把系统“压死”，那就是实现的问题了。
你可以采用很多种手段，告诉老板，这系统还没压就死了！ 这也是你的贡献。而对“有指标”这个定义来说，理论上合理的，并且应该有的指标是：时间指标、容量指标和资源利用率指标。　　

假设公司是从0开始做性能测试

• 第一阶段：做好性能测试，得到性能指标值（通常第一次做性能测试也叫单基准测试）
• 第二阶段：假设性能比之前差，哪些性能指标值不满足预期值，就需要分析是哪里有问题

版本迭代，进行第二次做性能测试，重新跑一遍之前的性能脚本

• 又会得到一些性能指标值，对比上个版本的性能指标值，看是否有优化（性能变化）
• 假设这个时候120个人同时下单是正常的，150个人才有异常，那么接口已经有优化了

 

2、性能测试需要有模型

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

　　我们需要选择择适合自己系统业务逻辑的方式，用最低的成本、最快的时间来做事情。

3、性能测试要有方案

方案规定的内容中有几个关键点，分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。基本上有这些内容就够了，这些内容具体的信息还需要精准。
你可能会说，怎么没有测试计划？我的建议是，用项目管理工具单独画测试计划，比如用 Project 或 OmniPlan 之类的工具。这是因为在方案中，写测试计划，基本上只能写一个里程碑，再细化一点，就是在里面再加几个大阶段的条目。
但是用项目管理工具做计划就不同了，它不仅可以细分条目，还能跟踪各个工作的动态进度，可以设置前后依赖关系，填入资源和成本以便计算项目偏差。　

4、性能测试中要有监控

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

5、性能测试中要有场景

性能场景也要有分类，在我有限的工作经验中，性能场景从来都没有超出过这几个分类

 

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

2、容量性能场景：这一环节必然是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多个，在概念部分就不细展开了，我会在后面的文章中详细说明。

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

4、异常性能场景：要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。这个异常的定义是很宽泛的，在下一篇文章里，我们再细说。

　　

6、性能测试中分析调优，以及测试结果报告

 在性能测试工程师中，可以做瓶颈判断、性能分析、优化的人并不多，所以很多其他职位上的人对性能测试的定位也就是性能验证，并不包括调优的部分。于是有很多性能项目都定义在一两周之内。这类项目基本上也就是个性能验证，并不能称之为完整的性能项目。而加入了调优部分之后，性能项目就会变得复杂。对于大部分团队来说，分析瓶颈都可能需要很长时间，这里会涉及到相关性分析、趋势分析、证据链查找等等手段。

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

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

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

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

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

1）性能验证：针对给定的指标，只做性能验证。第三方测试机构基本上都是这样做的。

2）性能测试：针对给定的系统，做全面的性能测试，可以得到系统最大容量，但不涉及到调优。

3）性能测试 + 分析调优：针对给定的系统，做全面的性能测试，同时将系统调优到最优状态

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

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