网上一搜性能测试，就会出现很多诸如性能测试、负载测试、压力测试、强度测试等一堆专有名词的解释。
但实际上我们不需要区分这么多。
那什么是性能测试？
性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。
这个定义，其实也就是一个完整的性能测试流程了。
为什么要弄清楚？因为这些概念要抹平沟通的误解，让不同层级，不同角色的人，可以在同样的知识背景下沟通，也可以让做事情的人有清晰的逻辑思路。
一、性能测试需要有指标
指标这个东东通常在很多公司并没有明确的定义。可能老板随口一句“把系统压挂”，下面人就得开始张罗了。但是这个“把系统压挂”其实就是一种指标。
通常来说，有三种指标：时间指标、容量指标和资源利用率指标，具体这里先不展开。
二、性能测试需要有模型
模型，可以理解为场景。
比如说，要对一个返回广告的接口进行性能测试。那么用户进入首页之后，可能有50%的人会点击banner位广告，30%的人会点击中部位的广告，最后20%的人会点击侧边框广告。
那么，你基于这样的一个模型，在施加压力的时候就需要控制好比例。这些业务数据，通常来说是有渠道可以获得的。
三、性能测试要有方案
需要确定性能测试方案，以便指导后续的工作。
通常来说，内容如下：
·测试环境
· 测试数据
· 测试模型
· 性能指标
· 压力策略
· 准入准出
· 进度风险
其中每一项内容的细化程度，要具体参考项目需要。
四、性能测试中要有监控
关于监控：
· 分层、分段
· 全局监控、定向监控
具体这里先不展开。
五、性能测试要有预定的条件
在测试场景执行之前，通常要确定如下的条件：
· 软、硬件环境
· 测试数据
· 测试执行策略
· 压力补偿
六、性能测试中要有场景
场景：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。
性能场景也要有分类，通常逃不出如下四大类：
1.基准性能场景
这里要做的是单交易的容量，为混合容量做准备。
2.容量性能场景
是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多个。
3.稳定性性能场景
最核心的元素是时间，而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的“拍脑袋”。
4.异常性能场景
要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。
那需要哪些异常？这也是要明确定义出来的。比如有宕主机、宕应用、宕网卡、宕容器、宕缓存、宕队列、宕流量控制、宕熔断等等。
总之，实际的场景中需要模拟什么异常，不是拍脑袋决定的，而是根据系统的业务架构和部署架构分析来的，不是看到有什么都宕一下。
另外，关于场景下对应的测试用例，不仅要描述测试脚本和测试数据，而且要描述需要哪些实时的判断和动态的分析，否则会影响性能结果。
七、性能测试中要有分析调优
相信有很多跟我一样的测试工程师，在进行性能测试的时候，其实也仅仅做的是性能验证，很少有进行分析调优，因为很难（o(╥﹏╥)o）。
但是，分析调优才是一个更能体现性能测试价值的重要元素。
八、性能测试肯定要有结果报告
结果报告是性能测试活动的价值内容体现，自然要展示领导关心的内容，比如调优前后的TPS、响应时间以及资源对比。相比较而言，用了多少人，花了多少时间可以往后放一放。
九、总结
一图流。
