性能测试（Performance Testing）包括如下方法：
验收性能测试（Acceptance Performance Testing）
负载测试（ Load Testing）
压力测试（Stress Testing）
配置测试（Configuration Testing）
并发测试（Concurrency Testing）
可靠性测试（Reliability Testing）
失败恢复测试（Failover Testing）
2.1.1.验收性能测试
验收性能测试（Acceptance Performance Testing）方法通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。这是一种最常见的测试方法，通俗地说，这种测试方法就要在特定的运行条件下验证系统的能力状况。
验收性能测试方法具有以下特点：
（1）这种方法的主要目的是验证系统是否具有系统宣称具有的能力
（2）这种方法需要事先了解被测试系统的典型场景，并且具有确定的性能目标
验收性能测试方法需要首先了解被测系统的典型场景，所谓的典型场景，是指具有代表性的用户业务操作，一个典型场景包括操作序列和并发用户数量条件。其次，这种方法需要有确定的性能目标，性能目标描述方式一般为：“要求系统在100个并发用户的条件下进行A业务操作，响应时间不超过5秒”
（3）这种方法要求在已确定的环境下进行
2.1.2.负载测试
负载测试（Load Testing）方法在被测系统上不断增加压力，直到性能指标（如：响应时间）超过预定指标或者某种资源使用已经达到饱和状态。
负载测试方法可以找到系统的处理极限，为系统调优提供数据，有时也被称为可置性测试（Scalability Testing），该方法有如下特点：
（1）这种性能测试方法的主要目的是找到系统处理能力的极限。
负载测试检测方法通过“检测-加压-性能指标超过预期”的手段，找到系统处理能力的极限。一般性能要求会有业务描述例如：‘在给定条件下最多允许120个并发用户访问’或者是‘在给定的条件下最多能够在1小时以内处理2100笔业务’，一般要求‘响应时间不超过10秒’，‘服务器平均CPU65%’等等
（2）这种性能测试方法需要在给定的测试环境进行，通常也需要考虑被测系统的业务压力量和典型场景，使得测试结果具有业务上的意义
（3）这种性能测试方法一般用来了解系统的性能容量，或事配合性能调优来使用。
2.1.3.压力测试
压力测试方法测试系统在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理会话能力，以及系统是否会出现错误。
压力测试方法具有一下特点：
（1）这种性能测试方法的主要目的是检查系统处于压力状况下时的性能表现。
（2）这种性能测试一般通过模拟负载等方法，使得系统的资源使用达到较高水平。
注意⚠️：压力测试内容（在CPU使用率达到75%以上，内存使用率达到70%以上）：JVM的可用内存、数据库连接数、数据库服务器CPU利用率等都可以作为压力的依据。
（3）这种性能测试一般用于测试系统的稳定性
2.1.4.配置测试
配置测试方法通过对北侧系统软硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。
（1）配置测试性能测试方法主要目的是了解各种不同因素对系统性能影响的程度，从而判断最值得进行的调优操作。
（2）这种性能测试方法一般在对系统性能这状况有初步了解后进行。
（3）这种性能测试方法一般用于性能调优和规划能力
2.1.5.并发测试
并发测试方法通过模拟用户的并发访问，测试多用户并发访问同一个应用，同一个模块或者数据记录时是否存在思索或者其他性能问题。
并发测试具有以下特点：
（1）这种性能测试方法主要目的是发现系统中可能隐藏的并发访问时的问题。
（2）这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。
（3）这种性能测试方法可以在开发的各个阶段使用，需要相关的测试工具的配合和支持。
2.1.6可靠性测试
可靠性测试方法通过给系统加载一定的业务压力(例如资源在70%～90%的使用率)，让应用持续运行一段时间，测试系统在这种条件下能否稳定运行。
可靠性测试方法具有以下特点：
（1）这种性能测试方法的主要目的是验证系用是否长期稳定的运行。
（2）这种性能测试方法需要在压力下持续一段时间的运行。（一般大型项目需要在峰值压力下，进行2-3天的稳定性测试即可）
（3）测试过程中需要关注系统的运行情况。
2.1.7失效恢复测试
失效恢复测试方法针对有冗余备份和负载均衡的系统设定的。这种测试方法可以检验如果系统局部发生故障，用户是否能够继续使用系统，以及如果情况发生，用户受到多大程度的影响。
失效恢复方法具有以下特点：
（1）这种性能测试方法主要目的是验证在局部故障情况下，系统能否继续使用。
（2）这种性能测试方法还需要指出，当问题发生时‘能支持多少用户访问’的结论和‘采用何种应急措施’的方案
（3）一般来说，只有对系统持续运行有明确要求的系统才需要进行这种类型的测试。
2.2性能测试应用领域分析
性能测试的应用领域划分为5个不同领域：
能力验证
规划能力
性能调优
缺陷发现
性能基准比较
2.2.1能力验证
能力验证领域的特点与性能测试的特点非常接近：
（1）要求在已确定的环境下运行。
只有在一个确定的运行环境下，软件性能的承诺和规划才是有意义的。
（2）需要根据典型场景设计测试方案和用例。
能力验证需要了解被测系统的典型场景，并根据典型场景设计测试方案和用例。一个典型场景包括操作序号和并发用户数量条件。在设计用例时，需要确定相应的性能目标。
能力验证一般采用性能测试方法，一般包括性能测试、可靠性测试、压力测试和失效恢复测试方法。
2.2.2规划能力
规划能力应用领域与能力验证应用领域有些不同，能力验证应用领域关心的是“在给定条件下，系统能否具有预期的能力表现”，而规划能力应用领域关心的是“应该如何使系统具有我们要求的性能能力”或是“在某种可能发生的条件下，系统具有如何的性能能力”。规划性能应用领域内的问题常常会被描述为：“某系统能否支持未来一段时间的用户增长”或是“应该如何调整系统配置，使系统能够满足增长的用户数的需要”
规划能力的特点：
（1）它是一种探索性的测试
（2）它可用于了解系统的性能以及获得拓展性能的方法。
用于规划能力领域的问题，常用的测试方法包括负载测试、配置测试和压力测试方法。
2.2.3性能调优
性能调优的标准过程示意图：
一个标准的性能调优过程的描述如下：
1）确定基准环境，基准负载和基准性能指标。
注意⚠️：实际的性能调优过程中常见的错误包括以下几种：
（1）没有保证每次执行时的数据库具有相同的数据环境。
（2）对于某些建立在J2EE或dotNet应用服务器上的应用，在应用服务器需要重启时，没有在测试之前首先进行一段时间“预热”。
2）调整系统运行环境和实现方法，执行测试。
这是性能调优的核心步骤。性能调优的目的是通过调整，提高应用系统的性能表现，对于一个应用系统来说，这种调整包括一下3个方面。
1⃣️硬件环境的调整：主要是对系统运行的硬件环境进行调整，包括改变系统运行的服务、主机设备环境（改用具有更高性能的机器，或者调整某些服务的物理内存总量，CPU数量等）、调整网络环境（更换快速的网络设备，或是采用更高带宽的组网技术）等。
2⃣️系统设置的调整：主要是对系统运行的基础平台设置进行调整，例如，根据根据应用需要调整UNIX系用的核心参数，调整数据库的内存迟大小，调整应用服务使用的内存大小，或是采用更高版本的JVM环境等。
3⃣️应用服务级别的调整：主要是对应用实现本身进行调整，包括选用新的架构、采用新的数据访问方式或修改业务逻辑实现方式等。
注意⚠️：实际生产环境上的部署完成的系统，调优的重点可能会放在硬件环境和系统设置上，以达到投入/产出比；但对于开发中的的应用，通过硬件环境和系统设置仍达不到用户要求已部署系统，还需要再应用级别上进行调整。
3）记录测试结果，进行分析
性能调优使用主要测试方法包括配置测试、负载测试、压力测试和失效恢复测试。
前端性能测试在使用上类似于性能调优的步骤，具体如下：
（1）通过前端性能统计数据或工具发现前端性能的问题
（2）根据问题进行前端性能的调整（通过修改前端实现方式，页面代码达成）
（3）验证前端性能是否达到预期的要求。
2.2.4缺陷发现
缺陷发现性能测试应用领域的主要目的是通过性能测试的手段来发现系统中存在的缺陷。为了解决“应用在测试环境下非常正常，但是一旦交付给用护，就出现大量莫名其妙的错误”的一类错误。
如果测试环境正常，生产环境出现应用挂死，多人访问时速度时快时慢，多人访问时应用崩溃几率增大等问题，则基本上市由于并发时的线程锁，资源竞争或内存问题引起的。
该应用领域主要目的是发现缺陷，并没有可以参照的性能指标或是需要达到的性能目标。因此需要采用并发测试的方法。还需要关注压力及失效恢复过程中出现的问题，则可以采用压力测试和失效恢复测试方法。
2.2.5性能基准比较
性能基准比较通常应用在敏捷开发过程中。敏捷软件开发采用“递增”的开发方式，由于很难在一开始就为每个迭代定于明确的性能需求，因此，在每个迭代中对应用进行性能检查，以保证应用的性能不会随着迭代的不断发生而变化是非常好的实践。
在实际操作中，可以将性能测试形成固定的脚本，并在固定的环境上对模块执行相应的性能测试，测试结果通过工具直接写入数据库并通过图形展现工具将其展现成折线图，其中可以直观的反映模块每个迭代中性能表现的变化，甚至可以做为验收条件的一部分。
另一方面，在敏捷软件开发过程中，用于设立性能基准比较的不仅仅是模块，还可以在单元测试中为给懂的函数设置性能基准比较。
