性能测试综述

性能测试旨在检查应用程序或软件在特定负载下工作时的响应性和稳定性，从而检测应用程序/软件在响应速度、可扩展性和稳定性方面是否达到预期的要求。

 

简而言之，性能测试目标就是为了识别并消除应用程序中的性能瓶颈。

 

性能测试类型

性能测试主要有[负载测试]，[压力测试]，[容量测试]和[可靠性/可恢复性测试]这四大主要类型，下面将对这四大主流性能测试类别逐一展开介绍：

负载测试

负载测试用于测试应用程序在正常和峰值情况下的性能。在负载测试中，我们对应用程序性能好坏的判定依据主要源于该应用程序对用户请求的响应情况，以及它在不同负载变化下（可接受的程度内）一致响应的能力来检测的。

负载测试中的核心关注点：

在应用程序出现异常情况前，该应用程序所能容纳的最大负载量是多少？

在系统变慢或出现崩溃之前，数据库所能处理的数据量有多少？

是否有任何与网络相关的问题需要解决？

压力测试

压力测试旨在寻找破坏系统的方法。该测试同时还能为我们找到系统可以承受的最大负载范围。

通常，压力测试采用增量方法，通过逐步增加负载来观察系统各项性能指标的变化情况。

首先，我们可以从应用程序已经测试过的负载开始（例如当前用户数 100 个）；然后慢慢地增加更多的负载来给系统增加压力（例如从 100 个用户数逐步增加到 10000）。

当我们发现服务器没有响应请求的那个点开始，这个点就被认为是断点（在一些性能测试报告图表中，往往也视为性能拐点）。

在压力测试过程中，我们需要关注的问题有：

系统在崩溃前能承受的最大负载是多少？

在实施压力测试过程中，系统是如何崩溃的？系统能否在崩溃后自行恢复？

被测系统/应用程序在处理异常负载时，有哪几种中断方式？

容量测试

容量测试是为了验证应用程序的性能不受应用程序正在处理的数据量的影响。为了执行容量测试，需要向数据库中输入大量数据。

此类测试可以视为增量式测试或稳定性测试。在增量式测试中，数据量是逐渐增加的。

通常，随着应用程序的使用，数据库容量会随数据而增长，例如一个新建立的教育网站，最初只有少量的数据需要存储，但在 5-10 年后，该网站数据库中的数据存储就已有相当规模了。

因此针对数据量逐步递增至规模庞大的情况下，对应用程序进行容量测试很有必要。

此外容量测试还有另一层含义：应用程序是否能够在正常及峰值负载条件下满足当前正在处理的业务量需求？

这通常是为了系统将来可能面临的情况而进行的可预见性测试，需要纳入考察的核心点有：

应用程序能够支持未来的负载吗？

环境是否能够承受即将增加的负载？

要使环境具备足够的能力，需要哪些额外的资源？

为了确保 Web 应用程序将支持在给定的用户和/或事务数，且满足性能要求，我们在测试过程中需要考虑修改处理器容量、网络带宽、内存使用情况、磁盘容量等资源，从而满足目标。对网上银行实施容量测试就是一个典型案例。

可靠性/可恢复测试

可靠性测试或恢复测试用于验证应用程序在出现故障或异常行为后，是否能够恢复到正常状态，以及恢复阶段需要经过多长时间。

例如在某线交易站点出现故障，致使用户不能在一天的某个点（高峰时间）买卖股票，但在一两个小时后用户能够进行在线股票交易，我们就可以说该应用程序是可靠的，即有能力从异常行为中自行恢复。

性能测试流程

大部分测试工程师们在面对功能测试进展规划时游刃有余，而当被问起如何开展性能测试时，往往陷入沉默。

究其原因不外乎两点：

几乎无实战经验

缺乏对性能测试的整体认知

下面将为大家系统性地介绍性能测试规范化流程：

性能需求收集&分析

性能需求的收集与分析至关重要，这直接影响到后续的性能测试活动是否能有效开展。

对于有性能测试需求的项目，企业内部通常都会有专职的性能测试工程师，或者性能测试团队（即便人数不多，亦或是临时组建）。

性能测试工程师直接或间接参与客户方针对系统/应用程序的性能需求调研会议，以识别和收集应用系统实现技术和业务方面的需求。

这包括获取有关应用程序的架构、技术和使用的数据库、目标用户、功能、应用程序使用情况、性能测试需求、硬件和软件需求等方面的信息。

性能测试工具选择

一旦确认了性能测试需求，接下来就到了性能测试工具选取的环节，如果之前没有类似的经验，企业也没有硬性规定必须使用的工具，那么在这个节点上，我们可以将可用工具逐一罗列。

分别从工具的成本、应用程序使用的协议、用于构建应用程序的技术、我们为测试而模拟的用户数量等等对可用工具列表进行筛选，选取一款合适当前项目情况的性能测试工具。

选定测试工具后，我们需要为关键业务创建脚本，并在 10-15 个虚拟用户中执行，这就是所谓的（POC—— Proof Of Concept，这是在有限范畴内，对用户实时活动的一种演示）。

性能测试计划&设计

根据第一个阶段收集的寻求信息，我们需要对性能测试进行整体计划和设计。测试计划旨在明确性能测试该如何进行，即性能测试环境、工作负载场景的设计、相关硬件配置等等。

这个阶段的输入是测试需求分析，输出是测试策略文档（包含了整个性能测试计划，设计），关于测试策略文档，在下文中将会以实例呈现。

性能测试用例研发

基于 POC 的测试用例研发：根据上述测试计划中确定的测试范畴及核心业务功能，开始着手设计编写性能测试用例；这些初始的测试用例通常是在 POC 期间基于所选的性能测试工具来记录被测试业务的步骤。

基于 POC 的测试用例评审：性能测试用例的评审最好能将客户代表纳入以获得他们的认可，确保被测业务每个步骤的准确性。

测试用例优化：基于 POC 的测试用例一旦通过评审，我们就可以逐步优化测试用例，例如参数化，等待，集合点等的设置。

环境同步：在创建优化性能测试用例脚本的同时，需要设置测试环境(软件和硬件)，从而确保性能测试脚本在特定环境下执行（尽可能模拟真实的线上环境）。

真实用户 VS 虚拟用户：如果性能测试在真实的客户环境下执行，性能团队还需要考虑如何避免实时用户及虚拟用户同时在线的情况，一般而言这类情况可以选择避开实时用户大量在线且活跃度相当高的情况。

性能测试建模

为测试执行创建性能负载场景模型， 该阶段主要目的是验证给定的性能指标(来自性能需求)在测试期间是否达到。

性能测试执行

在指定的场景下执行性能测试脚本，性能测试场景是根据上述负载模型设计的，测试执行通过虚拟用户数递增模式进行。

例如，如果用户的最大数量是 100，那么场景首先会运行 10、25、50 个用户，以此类推，最终会运行 100 个用户。

性能测试结果分析

测试结果是性能测试人员最重要的交付内容，也是可以证明 ROI（投资回报率）以及性能测试工作真正体现价值的地方。

由于性能测试通常需要进行多次执行才能得出正确的结论，无论通过工具自动生成还是自己汇总测试结果。

有效的性能测试结果分析需要注意这几点：

分析并记录测试失败的原因。

与前一次测试执行相比，应用程序的性能是否有变化。

为了执行性能测试用例，从应用程序构建到测试环境都做过哪些设置更改。

对每个性能场景执行的测试用例，及时进行性能测试结果分析，避免最终呈现完整性能测试报告时，出现任何数据指标的遗漏。

在总结中需要说明每场测试的目的、对应的虚拟用户数、测试持续时间、响应时间、吞吐量、不同负载情况下性能指标对比图、测试过程中出现的错误，以及后续改进的建

 

from ：https://new.qq.com/rain/a/20200731A0QQAQ00