性能测试概念
性能测试又成为性能策略或性能方法，平时看到的性能测试、负载测试、压力测试、强度测试等等都可以统称为性能测试
比如，压力测试是超过预期负载时系统的运行情况
容量测试是使系统承受超额的数据容量来发现它是否能够正常处理
---
当然其他的一些还有极限测试也是相关的概念，但是都只是在描述性能的不同侧面
性能测试合理定义
性能测试针对系统的性能指标，建立性能测试模型，指定性能测试方案，制定监控策略，在场景条件下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估西雅图的性能指标是否满足既定值
以下也可以分为整个性能测试步骤的解释也可以作为开展性能测试的思路
性能测试需要有模型
什么是性能测试模型？它即是真实场景的业务模型，比如一个电商系统，登录、购买下单、支付都可以算是业务模型
基本性能测试模型选择是根据实际业务场景来去选择，比如业务峰值，业务重要性，实际线上数据统计中实际哪个业务并发多，整体业务比重，这些都可以算作模型的一部分，根据一系列的分析结果来得到一个可用的结果（可进行性能测试的对象）
性能测试需要有方案
性能测试方案中必须有几个关键点，分别是测试环境，测试数据，测试模型，性能指标，压力策略，准入准出和进度风险。
这些整体构成一个测试方案
性能测试需要有监控
性能测试监控中，需要有分层、分段的能力，要有全局监控、定向监控的能力
性能测试需要有预定的条件
这里的条件指的是是软硬件环境、测试数据、测试执行策略、压力补偿内容等等，这些条件需要在场景执行之前，这些条件应该是要确定的
有些场景会根据动态的压力变化再进行动态扩展，也是有确定的策略的，比如说，我们判断 CPU 使用率达到 80% 或 I/O 响应时间达到 10ms 时，就做动态扩展。这些也是预定的条件。
所以性能测试工程师需要弄懂所做的一些工作，对软硬件资源、测试数据和测试执行策略都需要弄清楚，才能有效的完成性能测试
性能测试需要有场景
可以说，“性能场景”这个词在性能测试中占据着举足轻重的地位，只是我们很多人都不理解“场景”应该如何定义。场景来源于英文的 scenario，对性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。
性能测试场景大致分类：
1.基准性能场景：单交易的容量，为混合容量做准备
2.容量性能场景：根据业务复杂度不同，这部分场景会设计出很多个
3.稳定性性能场景：稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中，稳定性测试基本没和生产一致过。在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的心理安全感。
4.异常性能场景：要做异常性能场景，前提就是要有压力。在压力流量下，模拟异常。
性能测试场景也可以成为测试中的测试用例。
性能测试需要有分析调优
性能测试到底是定位性能问题、性能验证还是需要有后续调优能力，这里众说纷纭，
对于是否需要调优，可以做以下划分：
1.新系统性能测试：这种项目必须要测试出系统的容量峰值，不然上线没底
2.旧系统版本性能测试：与原本性能做比较，只要性能不下降即可，调优要求不大
3.新系统性能优化：不仅需要测出最大容量峰值，也需要进行调优
至于调优策略，后续文章再说明
性能测试需要有结果报告
如果是内部项目，一个表格或者邮件就可以了，但是专业度是不够的
我们要知道，大部分老板或者上司关心的是测试的结果，而不是用了多少人，花了多少时间这些没有意义的数字。我们更应该在报告中写上调优前后的 TPS、响应时间以及资源对比图。
性能测试的概念图
ps：本文仅供学习参考记录使用。