网上一搜性能测试，就会出现很多诸如性能测试、负载测试、压力测试、强度测试等一堆专有名词的解释。

　　但实际上我们不需要区分这么多。

　　那什么是性能测试？

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

　　这个定义，其实也就是一个完整的性能测试流程了。

　　为什么要弄清楚？因为这些概念要抹平沟通的误解，让不同层级，不同角色的人，可以在同样的知识背景下沟通，也可以让做事情的人有清晰的逻辑思路。

　　一、性能测试需要有指标

　　指标这个东东通常在很多公司并没有明确的定义。可能老板随口一句“把系统压挂”，下面人就得开始张罗了。但是这个“把系统压挂”其实就是一种指标。

　　通常来说，有三种指标：时间指标、容量指标和资源利用率指标，具体这里先不展开。

　　二、性能测试需要有模型

　　模型，可以理解为场景。

　　比如说，要对一个返回广告的接口进行性能测试。那么用户进入首页之后，可能有50%的人会点击banner位广告，30%的人会点击中部位的广告，最后20%的人会点击侧边框广告。

　　那么，你基于这样的一个模型，在施加压力的时候就需要控制好比例。这些业务数据，通常来说是有渠道可以获得的。

　　三、性能测试要有方案

　　需要确定性能测试方案，以便指导后续的工作。

　　通常来说，内容如下：

　　·测试环境

　　· 测试数据

　　· 测试模型

　　· 性能指标

　　· 压力策略

　　· 准入准出

　　· 进度风险

　　其中每一项内容的细化程度，要具体参考项目需要。

　　四、性能测试中要有监控

　　关于监控：

　　· 分层、分段

　　· 全局监控、定向监控

　　具体这里先不展开。

　　五、性能测试要有预定的条件

　　在测试场景执行之前，通常要确定如下的条件：

　　· 软、硬件环境

　　· 测试数据

　　· 测试执行策略

　　· 压力补偿

　　六、性能测试中要有场景

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

　　性能场景也要有分类，通常逃不出如下四大类：

　　1.基准性能场景

　　这里要做的是单交易的容量，为混合容量做准备。

　　2.容量性能场景

　　是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多个。

　　3.稳定性性能场景

　　最核心的元素是时间，而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的“拍脑袋”。

　　4.异常性能场景

　　要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。

　　那需要哪些异常？这也是要明确定义出来的。比如有宕主机、宕应用、宕网卡、宕容器、宕缓存、宕队列、宕流量控制、宕熔断等等。

　　总之，实际的场景中需要模拟什么异常，不是拍脑袋决定的，而是根据系统的业务架构和部署架构分析来的，不是看到有什么都宕一下。

　　另外，关于场景下对应的测试用例，不仅要描述测试脚本和测试数据，而且要描述需要哪些实时的判断和动态的分析，否则会影响性能结果。

　　七、性能测试中要有分析调优

　　相信有很多跟我一样的测试工程师，在进行性能测试的时候，其实也仅仅做的是性能验证，很少有进行分析调优，因为很难（o(╥﹏╥)o）。

　　但是，分析调优才是一个更能体现性能测试价值的重要元素。

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

　　结果报告是性能测试活动的价值内容体现，自然要展示领导关心的内容，比如调优前后的TPS、响应时间以及资源对比。相比较而言，用了多少人，花了多少时间可以往后放一放。

　　九、总结

　　一图流。

作者：把苹果咬哭    

来源：http://www.51testing.com/html/70/n-4997370.html