不懂性能测试，被面试官挂了...

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

图片来自 Pexels

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

本文将为大家详细介绍性能测试主要类型、性能测试流程规划以及面对项目如何开展性能测试策略，如何设计不同场景下的性能测试用例，助你从此远离性能测试的盲区。

性能测试类型

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

负载测试

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

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

• 在应用程序出现异常情况前，该应用程序所能容纳的最大负载量是多少?
• 在系统变慢或出现崩溃之前，数据库所能处理的数据量有多少?
• 是否有任何与网络相关的问题需要解决?

压力测试

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

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

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

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

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

• 系统在崩溃前能承受的最大负载是多少?
• 在实施压力测试过程中，系统是如何崩溃的?系统能否在崩溃后自行恢复?
• 被测系统/应用程序在处理异常负载时，有哪几种中断方式?

容量测试

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

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

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

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

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

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

• 应用程序能够支持未来的负载吗?
• 环境是否能够承受即将增加的负载?
• 要使环境具备足够的能力，需要哪些额外的资源?

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

可靠性/可恢复测试

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

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

性能测试流程

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

究其原因不外乎两点：

• 几乎无实战经验
• 缺乏对性能测试的整体认知

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

性能需求收集&分析

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

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

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

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

性能测试工具选择

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

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

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

性能测试计划&设计

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

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

性能测试用例研发

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

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

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

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

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

性能测试建模

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

性能测试执行

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

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

性能测试结果分析

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

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

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

• 分析并记录测试失败的原因。
• 与前一次测试执行相比，应用程序的性能是否有变化。
• 为了执行性能测试用例，从应用程序构建到测试环境都做过哪些设置更改。
• 对每个性能场景执行的测试用例，及时进行性能测试结果分析，避免最终呈现完整性能测试报告时，出现任何数据指标的遗漏。
• 在总结中需要说明每场测试的目的、对应的虚拟用户数、测试持续时间、响应时间、吞吐量、不同负载情况下性能指标对比图、测试过程中出现的错误，以及后续改进的建议。

完整报告

完整的性能测试报告以简洁为主，不需要任何推导，开发团队需要更多关于分析、比较结果的信息，以及如何获得结果的细节。

性能测试计划/策略编写 Demo

现在我们以一款实时消息传递应用程序为例，编写性能测试策略。

由于用户对于不同产品的性能需求不尽一致，这里仅以 Demo 呈现性能测试策略编写的完整过程，大家在工作中可适当对 Demo 模板进行裁剪，以满足自己当前项目所需。

关于 XXX 在线聊天应用程序：假设这是当前客户公司内部使用的聊天工作平台，这个聊天应用程序基于 XMPP 协议支持发送和接收即时消息。

此外该平台功能进行了一些增强，如远程 PC 控制、PC 诊断、修复工具、在线聊天等。

对于这个应用程序，我们假设项目团队已经决定使用 JMeter 进行性能测试，使用 JIRA 进行缺陷跟踪。

性能测试策略文档的第一页应该包含文档的标题和公司的版权;第二页应该包含文档控制，包括文档版本历史、审阅者和审批者列表和贡献者列表;第三页应包含目录，其中涉及以下主题：

①简介

本文档目的旨在说明如何在 XXX 聊天应用程序上，基于当前及未来状态进行性能测试。

XXX 聊天应用程序是一个用于内部远程支持的工作平台，具有在线聊天、客户识别、远程 PC 控制、PC 诊断和修复工具等功能。

性能测试主要目的如下：

• 确保当前聊天应用程序的任何更新符合规范的服务级别协议。
• 确保应用程序的性能、可用性和稳定性不会因为新功能的添加而受到影响。
• 在持续增加负载的情况下，事务响应时间保持在可接受的范围内。
• 在不断增加负载的情况下，JVM 始终显示稳定的内存使用情况。

下图清晰展示了性能测试/优化过程：

注：如在企业内，这里还可以附上被测应用系统的架构设计图。

②性能测试工作范畴

XXX 聊天应用程序性能测试工作范畴如下(In Scope)：

• 通过对系统详细调研，获取关键事务处理节点，构建负载分配。
• 确定性能测试的关键场景。
• 使用前一个版本的结果作为未来版本的基线。
• 确认其他用于分布式压测的代理机性能测试环境，以及使用的性能测试工具。
• 使用 JMeter 模拟各种峰值负载，并为负载场景准备性能测试脚本。
• 为服务器设置性能指标监控，以便在测试执行阶段识别性能瓶颈。
• 发布性能测试结果。
• 与项目干系人协作沟通，确定可行的调优方案，针对已识别的性能问题给出解决方案。
• 为该产品将来版本确定性能需求基线。

以下任务不在此次性能测试工作范畴中(Out of Scope)：

• 功能测试，UAT，系统测试和安全测试;对任何第三方接口进行性能测试/监视。
• 性能调优;(大多数时候调优是由不同的团队完成的，如果团队中有性能工程师来调优系统，可以将其这部分工作添加到 In Scope 中)。
• 安全/渗透测试/白盒测试。
• 性能测试的数据生成。
• 非功能测试(例如，故障转移、灾难恢复、备份、可用性)，而不是性能测试。
• 第三方应用程序性能测试和调优。
• 从性能团队的角度来看，应用程序代码更改，优化供应商支持的产品/服务器配置等都超出范围。
• 基础设施支持/构建部署/环境准备/数据库恢复/网络支持等。

③性能测试方案

XXX 聊天应用程序的性能测试将使用 JMeter 来进行，结合自定义编写的 XMPP 插件，这些插件通过 Smack 库实现 XMPP 连接。

这些库用来创建连接、实现用户登录并向 XMPP 服务器发送聊天消息。将这些库打包进成一个 Jar 文件，然后部署到 JMeter 中，并根据测试场景进行设计。

JMeter 工作台即 JMeter 服务器，安装在本地机器上，JMeter 工作台通过负载生成器产生所需的负载，向聊天服务器所在系统发出请求，与此同时 JMeter 工作台负责监视聊天服务器所在系统的行为。

根据性能测试需求分析，通过 JMeter 创建测试脚本和测试场景，针对不同场景设计虚拟用户数及虚拟用户活动状态，尽可能模拟真实场景。

将每个测试场景分解并从以下几个方面进行检测：

基线测试：1 个虚拟用户数+多个迭代运行每个场景，以确定应用程序性能是否满足业务服务水平。

基本负载测试：为了满足负载测试下的业务基准，性能测试团队将执行一个基本负载测试，该测试将有助于识别随着负载增加而出现的任何系统性能问题，并为下一级别的性能测试创建基线。

峰值负载/可伸缩性测试：性能测试团队针对不断增加虚拟用户数进行多次测试，以满足预期负载，同时检测应用程序性能，建立性能曲线，确定当前应用程序部署是否能够支持峰值用户负载下的服务水平协议。

这有助于对单个 Java 虚拟机(JVM)进行调优，以及对所需 JVM 总数和处理器的容量规划。

通过将虚拟用户数的值增加到峰值容量的 50%，75%，100% 和 125% 来进行峰值负载测试。

持久性测试/稳定性测试：性能测试团队基于不同时长(8 小时/16 小时/24 小时)持续运行指定的测试，以识别随着时间推移所产生的内存泄漏及其他性能问题，同时检验整体系统的稳定性。

在持久性测试期间，性能测试团队需要监视关键性能指标，例如事务响应时间，CPU，I/O，内存等系统资源使用情况是否稳定。

假定性能测试环境是生产环境的一个副本，测试将在增量负载下运行，以确定应用程序在那种负载情况下未达到性能要求，或出现异常行为。

④性能测试场景

注：企业中所有的测试场景可以集中编写在 Excel 文档里，这里仅以一个测试场景为例。

【场景 1】：验证代理和客户间的并发会话数。

【测试方案】：下表列出了不同性能测试方案及其对应的测试目标。

【性能指标设定】

客户端关注指标：

系统&网络性能指标：

【性能测试阶段活动及对应输出】

如下图：

⑤测试数据来源

这里假定所有性能环境数据是生产环境数据的副本，所需的测试数据将由项目团队统一提供。

⑥测试入口&出口准则

测试入口&出口准则如上图：

• 访问环境中所有应用程序
• 环境准备就绪
• 性能测试数据准备就绪

⑦缺陷管理

缺陷管理如下：

• 本项目将使用 JIRA 缺陷管理模块对缺陷进行记录和跟踪直至关闭。
• 在测试执行阶段发现的缺陷将被记录在 JIRA 中，这些缺陷将由开发团队根据以下严重性级别进行修复。
• 缺陷审查会议将提上每日工作日程，参与者包括测试、开发、质量分析师和业务团队。
• 随着项目发布上线日期推进，修复缺陷的标准将变得更加严格，因此在每日缺陷评审会议上，需要发布缺陷修复标准的指导策略。

缺陷严重级别定义，如下图：

⑧测试工具&技术

⑨测试执行停滞及恢复准则

⑩可交付成果物

性能测试交付成果包括:

• 性能测试策略
• 性能需求文档
• 性能测试场景文档
• 性能测试脚本
• 性能测试结果

⑪角色&职责

下图表格中列出不同角色及其对应的职责：

⑫潜在风险及缓解计划

下图表格中列出潜在风险及缓解计划：

⑬性能测试约定规则

性能测试约定规则如下：

• 性能测试环境是真实产品环境的复制(即硬件、软件、接口、集成层等与真实产品保持一致性)。
• 性能脚本将根据使用率高的关键业务流程来设计。
• 在性能测试开始之前，必须解决所有基础设施问题，此后所做的任何系统配置更改都将导致无效的测试结果。
• 性能测试执行前提：必须确保应用程序是稳定的，可以在性能测试环境中使用。
• 硬件和软件资源(如用户产生负载的工具、控制器/代理机器)准备就绪。
• 性能测试范围的任何变更都必须经由变更控制流程， 同时性能测试团队将对变更引起的时间/资源影响做出评估。
• 启用应用程序跟踪日志。

到此我们就完成了聊天应用程序性能测试计划的编写，在真实企业项目中，大家可以基于实际情况对文档内容自行裁剪。

总结

不难发现要成功完成一个性能测试项目，我们需要确保性能测试计划阶段各方面的准确性。

即计划、基于测试需求分析的用例开发、场景设计、测试执行和结果分析，这些关键点都必须按照正确的方式进行，加上合理的风险预估及缓解策略。

希望通过本篇分享，能够丰富你在性能测试领域的认知及实践，同时学会如何编写一份带有详细示例的性能测试计划文档，为后续性能测试活动的开展奠定良好的基础。

作者：罗小罗

简介：英国 TOP10 计算机专业，计算机科学与技术硕士，先后就职于汇丰，JPMorgan，HP，交行，阿里等国内外知名企业。涉及项目领域主要有：互联网金融，电商，教育，医疗等。现任就职于某世界 500 强公司，担任测试开发团队负责人，带领团队构建并持续优化自动化测试框架，研发自动化测试辅助类工具;擅长领域：单元/接口/性能/安全/自动化测试/CD/CI/DevOps;个人持续研究领域：自动化测试模型/数据分析/算法/机器学习等。

编辑：陶家龙

征稿：有投稿、寻求报道意向技术人请联络 [email protected]

【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】