文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

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

2024-12-11 17:42

关注

[[335942]]

图片来自 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 诊断和修复工具等功能。

性能测试主要目的如下:

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

 

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

②性能测试工作范畴

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

以下任务不在此次性能测试工作范畴中(Out of 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】:验证代理和客户间的并发会话数。

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

 

【性能指标设定】

客户端关注指标:

系统&网络性能指标:

 

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

如下图:

 

⑤测试数据来源

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

⑥测试入口&出口准则

 

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

⑦缺陷管理

缺陷管理如下:

缺陷严重级别定义,如下图:

 

⑧测试工具&技术

 

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

 

⑩可交付成果物

性能测试交付成果包括:

⑪角色&职责

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

 

⑫潜在风险及缓解计划

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

 

⑬性能测试约定规则

性能测试约定规则如下:

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

总结

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

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

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

作者:罗小罗

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

编辑:陶家龙

征稿:有投稿、寻求报道意向技术人请联络 editor@51cto.com

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

来源:51CTO技术栈内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯