目录
[负载测试(load testing)](#负载测试(load testing))
[压力测试(Stress Testing)](#压力测试(Stress Testing))
[可扩展性测试(](#可扩展性测试()
[尖峰测试(Spike Testing)](#尖峰测试(Spike Testing))
[耐久性测试(Endurance Testing)](#耐久性测试(Endurance Testing))
[并发测试(Concurrency Testing)](#并发测试(Concurrency Testing))
[容量测试(Capacity Testing)](#容量测试(Capacity Testing))
性能测试的类型
性能测试：确定软件产品性能的测试。
负载测试(load testing)
负载测试的重点是系统处理由并发用户或进程的可控数量产生的事务请求所导致的不断增加的预期实际负载的能力。
负载测试用于评估组件或系统在不同负载下的行为，通常在预期的低使用率、典型使用率和峰值使用率之间进行。
负载测试几乎总是基于一些真实的组织条件。负载测试是所有性能测试的组成部分，因为它是其他性能测试类型的基础。负载测试的基础（运行和最终负载曲线）通常被称为volumetrics，并根据以下问题确定：
-
Who
谁是用户？是否有不同的用户组访问该负载测试的组件或系统？这些用户可能是执行不同任务或拥有不同访问权限的不同用户组。
-
What
用户正在执行哪些业务流程？
以在线零售网站为例。业务流程代表了用户想要执行的一些端到端的操作（例如，购买一本关于性能测试的书）。这个端到端的流程可以被分解成一系列可重用的任务（登录、搜索书籍、添加到购物篮、购买和注销），这些任务可以代表系统中的服务或组件。每个可重复使用的任务都可以分解成用户将要执行的一系列步骤（打开浏览器，浏览零售商网站，输入用户名和密码，点击登录按钮）。
这些业务流程中的每一个都代表了负载的定义，或负载的一部分，将在环境中执行代码来创建实际的负载。性能测试的部分技巧在于观察 "是什么"，并了解该业务流程如何在被测系统中运行。例如性能测试计划需要创建80个独立的报告来测试ERP系统的商业智能报告。但是，当从后端服务器、数据库和服务进行测试时，发现80个脚本可以减少到7个，每个报告都可以通过输入数据进行管理（从而节省了性能工程师大量的工作）。
- Where
用户在哪里？用户是集中访问系统（如企业办公室）还是分散访问系统（如用户在家工作）？使用地理定位将负载重定向到不同的服务器、服务、组件或业务流程。
- When
负载测试在一天中的什么时间进行？
压力测试(Stress Testing)
压力测试的重点是系统或组件处理峰值负载的能力，这些负载达到或超过了其预期或指定工作负载的极限。压力测试也用于评估系统处理资源可用性降低的能力，如可访问的计算能力、可用带宽和内存。
压力测试是一种有用的类型，因为它有助于识别：被测系统的最大容量,组件或系统的哪个部分首先失效
压力测试需要注意的一点是，它可以无限期地进行下去。一旦确定并报告了最大容量，就存在替代方案：
压力测试可以从负载定义的角度（用户执行与时间行为相关的业务流程），简单地告知利益相关者最大容量。可能不需要采取进一步的措施--我们知道当负载达到X时，系统将变得不稳定。
压力测试通知开发人员和/或管理员，如果负载达到最大容量（资源利用率），哪个组件将失效。因此，如果负载达到X，出现故障的部件就是Y。
然后，可以采取进一步措施修复最初出现故障的组件，从而可能提高最大容量。如果时间和资金允许，测试可以继续到新的故障点，因为总有另一个组件会在负载下发生故障。
可扩展性测试(
scalability testing)
可扩展性测试的重点是系统满足未来效率要求的能力，这些效率要求可能超出目前的要求。这些测试的目的是确定系统的增长能力（例如，更多的用户、更大的数据存储量），而不违反当前指定的性能要求或失败。一旦知道了可扩展性的极限，就可以设置阈值，并在生产中进行监控，以便对可能出现的问题发出警告。此外，还可通过适当数量的硬件调整生产环境。
可扩展性:组件或系统可根据容量变化进行调整的程度。
可扩展性测试
确定软件产品可扩展性的测试。
-可扩展性测试
一个常见的问题是："系统是可扩展的吗？
请记住，答案总是肯定的！我们总是可以增加系统、服务或组件的负载，并提高处理负载的能力。
之前我们问过："负载对系统/服务/代码在时间行为、资源利用率和容量方面的可扩展性有多大影响？
通过可扩展性测试，我们现在回答了一个不同的问题。与其问 "系统/服务是否具有可扩展性？"，不如问 "系统/服务的可扩展性如何？
"系统/服务的可扩展性如何？
可扩展性测试一般有两种类型--水平和垂直
横向可扩展性是在系统中增加更多相同规格的机器/设备/虚拟机，而纵向可扩展性则是将现有的机器/设备/虚拟机替换成更大、功能更强的机器，或为虚拟机/设备分配更多的CPU和/或内存。这两种方法各有利弊。
在这两种情况下，通常首先收集时间行为、资源利用率和单台服务器的容量。然后可以决定是测量横向可扩展性（添加额外的服务器/虚拟机/虚拟机）还是纵向可扩展性（增加单台服务器的资源），以提高系统/服务处理更高容量负载的整体能力。
需要始终明确的是，可扩展性总是有上限的。系统或服务可能具有可扩展性，但将必要的硬件/软件许可/基础设施扩展到所需水平的成本可能过于昂贵。系统或服务可能变得不稳定，或者增加容量对整体性能没有任何好处。
尖峰测试(Spike Testing)
尖峰测试主要是测试系统对突如其来的峰值负载做出正确响应并在其后恢复到稳定状态的能力。
尖峰测试: 测试确定系统从突发的峰值负载中恢复到稳定状态的能力。
尖峰负载测试已成为一种流行的测试方法，用于考察负载在短时间内超过规定峰值时系统的性能。这些峰值可能是
单个事件
耐久性测试(Endurance Testing)
耐久性测试的重点是系统在特定时间段内的稳定性。此类测试验证是否存在资源容量问题（如内存泄漏、数据库连接、线程池），这些问题最终可能会降低性能和/或导致断点故障。
耐久性测试:在系统运行环境下，确定系统在相当长的一段时间内承受重大负载的稳定性的测试。
耐久性测试也称为浸泡测试。负载测试和耐久性测试的区别主要在于测试执行的时间长短。两者在设计上具有相似的负载曲线。不同之处在于，负载测试可能只执行一小时；而耐久性测试通常会执行数小时、数天，甚至在极端情况下执行数周。耐久性测试的挑战在于获得足够的测试数据来长时间执行测试，并有足够的存储空间来捕获测试结果。耐久性测试变得更加重要，因为许多组织每周7天、每天24小时在线，这意味着几乎没有时间停机或 "重启服务器"。
并发测试(Concurrency Testing)
并发测试的重点是特定操作同时发生时（如大量用户同时登录）的影响。众所周知，并发问题很难发现和重现，特别是当问题发生在测试几乎无法控制的环境中，如生产环境。
并发性: 组件或系统同时执行多个独立的线程。
并发的概念是性能测试的基石。即使单个用户或事务产生负载，该负载也可能不足以真正锻炼被测系统。通过并发性，性能工程师可以定义有多少业务流程、任务甚至步骤同时发生。
一般可考虑三种并发类型。例如，如果被测系统是一个在线零售网站，许多用户可能同时在网站上执行一系列功能。在组件层面，测试登录组件时可能需要同时进行多次登录尝试。细分如下
- 应用程序并发性
可能有许多用户使用网站执行不同的业务流程（搜索、购买、检查订单状态、创建用户帐户等）。
- 业务流程并发
较少数量的用户可能同时执行一个业务流程（搜索网站）。
- 事务并发
用户子集同时执行一个业务流程（搜索），所有用户同时点击搜索按钮。-
也可能出现意外情况，这些情况更多属于故障转移和灾难恢复的范畴，但仍需要进行性能测试。并发测试可能会在高峰负载时同时运行批处理，或在繁忙时开始计划备份。
容量测试(Capacity Testing)
容量测试确定给定系统将支持多少用户和/或事务，并仍然满足既定的性能目标。这些目标也可能与事务产生的数据量有关。
容量:组件或系统参数的最大限制满足要求的程度。
容量测试类似于其他已经确定的测试类型（压力和尖峰测试）。容量测试和压力测试的区别在于，压力测试延伸到预定的故障点（例如，吞吐量或资源利用率的限制，或超过处理时间）。容量测试仍可能超出峰值负载，但其目的是实现性能测试目标（例如，系统将支持多少用户），而不是确定故障原因。容量测试的重点是达到规定的性能水平，而不是试图导致故障（压力）或 "看看会发生什么"（峰值）。通常情况下，容量测试的负载/性能增长与组织需求有关。例如，组织可能有一个全球增长率，定义为每年4%的新客户增长。容量测试可以帮助回答系统支持这种逐年增长的能力问题。
资料获取方法
【留言777】
各位想获取源码等教程资料的朋友请 点赞 + 评论 + 收藏 ，三连！
三连之后我会在评论区挨个私信发给你们~