性能测试基础---测试分类

性能的概念

1. 系统的性能是一个很大的概念，覆盖面非 常广泛，对一个软件系统而言包括执行效率、 资源占用、稳定性、安全性、兼容性、可扩 展性、可靠性等等
2. 性能测试用来保证产品发布后系统的性能 满足用户需求。性能测试在软件质量保证中 起重要作用。

性能测试分类

阅读的非常多的文档资料，对于性能测试分类说法，各有不同，而且绝大部分解释的含糊不清。有说并发测试，稳定性测试，大数据测试算负载测试，也有说大数据测试，并发测试，稳定性测试算压力测试。

自己按照比较认可的方式，进行一个分类归纳。

性能测试不管分成啥子类，叫啥名字，反正就干一件事，【加压】，花式加压，不同的加压方式就对应不同的叫法。

先罗列一下，度娘，谷哥出来一堆性能测试名词：

基准测试，一般性能测试，负载测试，压力测试，并发测试，稳定性测试，持久测试，浸泡测试，大数据测试，容量测试，强度测试，

观摩根据N位大佬的之后个人理解方式：
以上众多测试分类名称其实很难被放在一起解释清楚，因为很多的操作实现模式是一样的。按照关注点的不同和加压方式的不同作为两个大的区分点。

序号	名称	含义
按照测试关注点（目的）不同来区分
1）	基准测试	查看系统应用的前后端性能是否符合产品性能需求，即是在性能需求明确的前提下，进行的性能测试，版本迭代，回归测试使用。也就是狭义阐述的性能测试解释 。又称一般性能测试。
2）	负载测试	逐步加压，应用系统运行【正常】，关注各项资源利用情况，测定系统饱和状态、确定阀值。压力测试也是通过高负载情况来体现的，所以负载测试更倾向解释成一个技术或者方法
3）	压力测试	逐步加压，应用系统运行【失效】，关注系统可以承受的最大压力值，可承受的最值的压力值。
按照加压方式不同来区分
4）	稳定性测试	应用系统，持续运行。又称持久测试，浸泡测试
5）	并发测试	应用系统，被多个用户单位同时访问
6）	大数据测试	应用系统，同时处理大量的数据业务

换种方式理解：

一个搬运工：

1）基准测试：一次搬运一块砖。

可能出现的实际情况：

2）稳定性测试：持续一天，一次搬运一块砖。看什么时候累到

3）并发测试：一次搬运多块砖。看到多少块砖就搬不动了

4）大数据测试：一次搬运一袋水泥。看是否搬的动和工作效率

结果：

5）负载测试：一次搬多块砖或多袋水泥（搬的动的前提下），持续工作（干的动的前提下）。看各项工作指标，压榨最大劳动力

6）压力测试：一次搬运多块砖或多袋水泥，直到搬不动，1，得出单次最大劳力。 2，搬运超过最大量级，给工人造成什么伤害，是否能否恢复正常工作 在高劳力的情况下，长时间工作，1，是否可行。2，不可行的点之后，是否有能力自己处理

忘了哪里捞来的图片

1）基准测试 （Performance Benchmark Test）：

a到b之间的系统性能，指以系统预期性能指标为前提，对系统不断增加压力，以验证系统能否达到预期性能

基准测试是每次对外发布产品版本前必须要完成的测试类型。
它会基于固定的环境和架构（固定的服务器、稳定的网络环境、固定的集群、固定的系统配置、固定的数据库等），通过执行固定的性能测试场景得到系统的性能测试报告，然后与上一版本发布时的基准测试结果进行对比，如果发现指标有“恶化”的趋势，就需要进一步排查问题

目的：

1. 获取系统性能基准作为参照物（性能问题发生后的测试很难了解系统性能基准）
2. 识别系统或环境的配置变更对性能带来的影响
3. 给系统优化前后的性能提升/下降提供参考标准
4. 观察系统的整体性能趋势与性能拐点，识别系统性能风险

典型的“恶化”趋势，主要表现在以下几个方面

同一事务的响应时间变慢了。比如，上一版本中，用户登录的响应时间是 2 s，
但是在最新的被测版本中这个响应时间变成了 4 s；

系统资源的占用率变高了。比如，上一版本中，平均 CPU 占用率是 15%，
但是在最新的被测版本中平均 CPU 占用率变成了 30%；

等等。。。。

基准自动化测试与一般性能测试的主要区别

1. 测试周期：基准自动化每天定时自动化执行，性能测试需要事件驱动执行。
2. 测试脚本：基准自动化的性能测试脚本仅仅包含所关注业务的HTTP请求，不做用户行为模拟；性能测试的测试脚本包含业务的上下文请求，并进行用户行为的模拟。
3. 测试策略：基准自动化策略固定，几乎不做修改；性能测试需要根据不断变化的性能需求进行修改。
4. 脚本维护：基准自动化的测试脚本仅在访问链接发生变更时维护，或者POST参数发生变更时维护，GET请求几乎不需要维护；性能测试脚本在每轮测试中一般都需要重新开发。
5. 结果用途：基准自动化结果数据用于系统性能变动的衡量指标；性能测试结果脚本可用于感知用户性能体验、预知系统性能风险。

2）负载测试：

b 点的系统性能，是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到极限，例如某种资源已经达到饱和状态等。
注：负载测试是通过逐步加压的方式来确定系统的处理能力，确定系统能够承受的各项阀值。
例如：逐步加压，得到（响应时间不超过3秒）（服务器平均CPU利用率低于80%）等指标的阀值
阀值：关注的某一具体数值（比如：登录小于3秒，用户数2000，业务成功率100%）

1. 持续稳定地增加系统的负载，测试系统性能的变化。直到性能指标达到阈值，找到系统瓶颈和性能拐点
2. 测试系统所能承受的最大负载量的测试
3. 找出内存管理错误，内存泄漏，缓冲区溢出等问题
4. 找到处理极限，为调优提供数据
5. 负载测试是通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。它是一种测试方法，可以被压力测试所采用。

eg：

1. 最多允许200个并发用户访问，测试最大响应时间，最大吞吐量
2. 21个小时内处理1000笔业务，测试最大并发
3. 响应时间不超过10s，测试最大负载
4. cpu利用率低于60%，测试最大并发

有说法是：
负载测试包含了并发，稳定和大数据

2.1）并发测试

1. 狭义上的并发：所有用户在同一时间点进行同样的操作，一般指同一类型的业务场景。例如：1000个用户同时登陆系统
2. 广义上的并发：多个用户与系统发送了交互，这些业务场景可以是相同的也可以是不同的，交叉请求和处理较多
3. 并发测试一般使用思考时间为零的虚拟用户脚本来发起具有“集合点”的测试
4. 并发测试，往往被当作功能测试的补充，主要用于发现诸如多线程、资源竞争、资源死锁之类的错误。要执行并发测试，需要加入“集合点”

2.2）稳定性测试

1. 又称可靠性测试，疲劳强度测试
2. a点到b点之间的系统性能，是指实测系统在接近生产环境的系统中，给系统加载一定于真实业务压力相仿的压力，使系统运行一段较长时间，以检测系统是否稳定，一般稳定性测试时间为N*12小时。
3. 通过对系统指标的监控，可以发现诸如内存泄漏，资源非法占用等问题
4. 破坏性压力测试：不断加压，直至系统崩溃。来得出系统的最大承受能力。通过破坏性不断加压的手段，能快速造成系统的崩溃或让问题明显的暴露出来

稳定性测试的场景设计和基准测试不同

一般是采用“阶梯增压”的方法，逐渐增加测试负载，在高负载情况下持续运行一段时间，然后再逐渐降低负载，这样就构成了一个梯级的测试场景。

稳定性测试通过的标志

1. 系统资源的所有监控指标稳定
2. 事务的响应时间不稳定
3. 事务的错误率不超过 1%

2.3）大数据测试

大数据量测试的两种类型：

1. 独立的数据量测试：针对某些系统存储，传输，统计，查询等业务进行大数据量测试
2. 综合数据量测试：和并发性能测试，疲劳性能测试相结合的综合测试方案

3）压力测试：

b 点到d之间的系统性能，是指超过安全负载的情况下，对系统不断施加压力，直到系统崩溃，确定系统的瓶颈或不能接收用户请求的性能点。

1. 测试系统的资源在达到饱和状态下，应用的处理会话能力
2. 持续稳定的增加系统负载，测试系统性能的变化，并最终确定在什么负载下系统性能处于失效状态
3. 它的目的是确保系统失败并正常恢复，目的是发现在什么条件下系统的性能变得不可接受，发现应用程序性能下降的拐点
4. 有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等
5. 关注大业务量情况下长时间运行系统性能的变化（例如是否反应变慢、是否会内存泄漏导致系统逐渐崩溃、是否能恢复）

目标

1. 测试在一定的负载下系统长时间运行的稳定性，但是这个负载不一定是应用系统本身造成的。比如我们经常利用脚本或工具事先吃掉服务器的一部分cpu、内存或带宽等，
2. 创造出一定的负载环境并测试被测应用系统在此环境下的事物处理能力，响应时间等等

注：

1，压力测试：

重点是在【失效】，就是逐步增加负载，使系统某些资源达到饱和甚至失效。例如：测试系统最多支持同时处理多少请求，超过该数数量系统就瘫痪了

2，负载测试：

重点是在【未失效】，也是逐步增加负载，确定在满足性能指标情况下，系统能承受的最大负载测试。例如：登录3秒内，最多支持多少用户同时登录；如超出此数量，可能需要5秒或更多时间才能登录成功之类的

虫师：https://www.cnblogs.com/fnng/archive/2012/06/09/2543274.html
飞天小子：https://www.cnblogs.com/Zfc-Cjk/p/11588062.html
小学生II：https://www.cnblogs.com/ceshi2016/p/9066105.html
51testing：http://www.51testing.com/html/53/15150753-3721088.html
优快云：https://blog.youkuaiyun.com/zhusongziye/article/details/80100688

Noga Cohen：https://www.blazemeter.com/blog/performance-testing-vs-load-testing-vs-stress-testing/