性能测试的概念到底是什么？
网络上比较普遍的说法是负载测试，压力测试，并发测试，极限测试等，甚至一些书籍上都是这样的叫法，但是你仔细看呢，你又会发现这些说法都很相似，难以分辨。
其实我比较的认同的一种分法是：单业务基准测试，单业务负载测试，混合交易容量测试。最近也在慢慢的吸收，内化成自己的东西，这些概念在自己的脑子中会逐渐的清晰起来。
专栏的作者高楼给出了自己的定义：
性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。
性能测试需要有指标
指标的话，比较重要的有三个：时间指标、容量指标和资源利用率指标。
性能测试需要有模型
模型的话其实就是根据业务来的，那个业务的并发多，那个业务的并发少。
性能测试要有方案
方案规定的内容中有几个关键点，分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。
性能测试中要有监控
这个肯定是必不可少的部分，有很多的工具，以后会分享一下。
性能测试中要有场景
场景来源于英文的 scenario，对性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。这才是真正的场景全貌。
这里作者分了三类，摘抄如下：
基准性能场景：这里要做的是单交易的容量，为混合容量做准备（不要跟我说上几个线程跑三五遍脚本叫基准测试，在我看来，那只是场景执行之前的预执行，用来确定有没有基本的脚本和场景设计问题，不能称之为一个分类）。
容量性能场景：这一环节必然是最核心的性能执行部分。
稳定性性能场景：稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中，稳定性测试基本没和生产一致过。在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的心理安全感。
异常性能场景：要做异常性能场景，前提就是要有压力。
性能测试中要有分析调优
对性能项目分为如下几类。
新系统性能测试类：这样的项目一般都会要求测试出系统的最大容量，不然上线心里没底。
旧系统新版本性能测试类：这样的项目一般都是和旧版本对比，只要性能不下降就可以根据历史数据推算容量，对调优要求一般都不大。
新系统性能测试优化类：这类的系统不仅要测试出最大容量，还要求调优到最好。对性能团队的职责定位有如下几种。
性能验证：针对给定的指标，只做性能验证。第三方测试机构基本上都是这样做的。性能测试：针对给定的系统，做全面的性能测试，可以得到系统最大容量，但不涉及到调优。
性能测试 + 分析调优：针对给定的系统，做全面的性能测试，同时将系统调优到最优状态。
最后做一下总结：
最近的文章可能都会是总结，因为性能测试这块自己知道的实在是太少了，需要找大量的书籍与专栏来学习消化。
学着实践着越来越发现这块是一个无底洞，好像所有的问题都涉及到性能或者说跟性能有点关系。
【对自己的说的话】
有时候情绪会很低落，有时候又会很容易的兴奋，这样不好。要多传播正能量，做一个乐观的人，还是李笑来的那句话：“永远对未来的自己充满盲目的乐观”。