后端性能测试的类型

这篇具有很好参考价值的文章主要介绍了后端性能测试的类型。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

性能测试的类型

性能测试:确定软件产品性能的测试。

后端性能测试的类型

负载测试(load testing)

负载测试的重点是系统处理由并发用户或进程的可控数量产生的事务请求所导致的不断增加的预期实际负载的能力。

负载测试用于评估组件或系统在不同负载下的行为,通常在预期的低使用率、典型使用率和峰值使用率之间进行。

负载测试几乎总是基于一些真实的组织条件。负载测试是所有性能测试的组成部分,因为它是其他性能测试类型的基础。负载测试的基础(运行和最终负载曲线)通常被称为volumetrics,并根据以下问题确定:

  • Who
    谁是用户?是否有不同的用户组访问该负载测试的组件或系统?这些用户可能是执行不同任务或拥有不同访问权限的不同用户组。

  • What

用户正在执行哪些业务流程?

后端性能测试的类型

以在线零售网站为例。业务流程代表了用户想要执行的一些端到端的操作(例如,购买一本关于性能测试的书)。这个端到端的流程可以被分解成一系列可重用的任务(登录、搜索书籍、添加到购物篮、购买和注销),这些任务可以代表系统中的服务或组件。每个可重复使用的任务都可以分解成用户将要执行的一系列步骤(打开浏览器,浏览零售商网站,输入用户名和密码,点击登录按钮)。

这些业务流程中的每一个都代表了负载的定义,或负载的一部分,将在环境中执行代码来创建实际的负载。性能测试的部分技巧在于观察 "是什么",并了解该业务流程如何在被测系统中运行。例如性能测试计划需要创建80个独立的报告来测试ERP系统的商业智能报告。但是,当从后端服务器、数据库和服务进行测试时,发现80个脚本可以减少到7个,每个报告都可以通过输入数据进行管理(从而节省了性能工程师大量的工作)。

  • Where

用户在哪里?用户是集中访问系统(如企业办公室)还是分散访问系统(如用户在家工作)?使用地理定位将负载重定向到不同的服务器、服务、组件或业务流程。

  • When

负载测试在一天中的什么时间进行?

参考资料

  • 软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞,谢谢!
  • 本文涉及的python测试开发库 谢谢点赞! https://github.com/china-testing/python_cn_resouce
  • python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md

后端性能测试的类型

压力测试(Stress Testing)

后端性能测试的类型

压力测试的重点是系统或组件处理峰值负载的能力,这些负载达到或超过了其预期或指定工作负载的极限。压力测试也用于评估系统处理资源可用性降低的能力,如可访问的计算能力、可用带宽和内存。

压力测试是一种有用的类型,因为它有助于识别:被测系统的最大容量,组件或系统的哪个部分首先失效

压力测试需要注意的一点是,它可以无限期地进行下去。一旦确定并报告了最大容量,就存在替代方案:
压力测试可以从负载定义的角度(用户执行与时间行为相关的业务流程),简单地告知利益相关者最大容量。可能不需要采取进一步的措施--我们知道当负载达到X时,系统将变得不稳定。

压力测试通知开发人员和/或管理员,如果负载达到最大容量(资源利用率),哪个组件将失效。因此,如果负载达到X,出现故障的部件就是Y。

然后,可以采取进一步措施修复最初出现故障的组件,从而可能提高最大容量。如果时间和资金允许,测试可以继续到新的故障点,因为总有另一个组件会在负载下发生故障。

可扩展性测试(

scalability testing)

后端性能测试的类型

可扩展性测试的重点是系统满足未来效率要求的能力,这些效率要求可能超出目前的要求。这些测试的目的是确定系统的增长能力(例如,更多的用户、更大的数据存储量),而不违反当前指定的性能要求或失败。一旦知道了可扩展性的极限,就可以设置阈值,并在生产中进行监控,以便对可能出现的问题发出警告。此外,还可通过适当数量的硬件调整生产环境。

可扩展性:组件或系统可根据容量变化进行调整的程度。

可扩展性测试
确定软件产品可扩展性的测试。

-可扩展性测试

一个常见的问题是:"系统是可扩展的吗?

请记住,答案总是肯定的!我们总是可以增加系统、服务或组件的负载,并提高处理负载的能力。

之前我们问过:"负载对系统/服务/代码在时间行为、资源利用率和容量方面的可扩展性有多大影响?

通过可扩展性测试,我们现在回答了一个不同的问题。与其问 "系统/服务是否具有可扩展性?",不如问 "系统/服务的可扩展性如何?

"系统/服务的可扩展性如何?

可扩展性测试一般有两种类型--水平和垂直

横向可扩展性是在系统中增加更多相同规格的机器/设备/虚拟机,而纵向可扩展性则是将现有的机器/设备/虚拟机替换成更大、功能更强的机器,或为虚拟机/设备分配更多的CPU和/或内存。这两种方法各有利弊。

在这两种情况下,通常首先收集时间行为、资源利用率和单台服务器的容量。然后可以决定是测量横向可扩展性(添加额外的服务器/虚拟机/虚拟机)还是纵向可扩展性(增加单台服务器的资源),以提高系统/服务处理更高容量负载的整体能力。

需要始终明确的是,可扩展性总是有上限的。系统或服务可能具有可扩展性,但将必要的硬件/软件许可/基础设施扩展到所需水平的成本可能过于昂贵。系统或服务可能变得不稳定,或者增加容量对整体性能没有任何好处。

尖峰测试(Spike Testing)

后端性能测试的类型

尖峰测试主要是测试系统对突如其来的峰值负载做出正确响应并在其后恢复到稳定状态的能力。

尖峰测试: 测试确定系统从突发的峰值负载中恢复到稳定状态的能力。

尖峰负载测试已成为一种流行的测试方法,用于考察负载在短时间内超过规定峰值时系统的性能。这些峰值可能是
单个事件

耐久性测试(Endurance Testing)

耐久性测试的重点是系统在特定时间段内的稳定性。此类测试验证是否存在资源容量问题(如内存泄漏、数据库连接、线程池),这些问题最终可能会降低性能和/或导致断点故障。

耐久性测试:在系统运行环境下,确定系统在相当长的一段时间内承受重大负载的稳定性的测试。

耐久性测试也称为浸泡测试。负载测试和耐久性测试的区别主要在于测试执行的时间长短。两者在设计上具有相似的负载曲线。不同之处在于,负载测试可能只执行一小时;而耐久性测试通常会执行数小时、数天,甚至在极端情况下执行数周。耐久性测试的挑战在于获得足够的测试数据来长时间执行测试,并有足够的存储空间来捕获测试结果。耐久性测试变得更加重要,因为许多组织每周7天、每天24小时在线,这意味着几乎没有时间停机或 "重启服务器"。

并发测试(Concurrency Testing)

并发测试的重点是特定操作同时发生时(如大量用户同时登录)的影响。众所周知,并发问题很难发现和重现,特别是当问题发生在测试几乎无法控制的环境中,如生产环境。

并发性: 组件或系统同时执行多个独立的线程。

并发的概念是性能测试的基石。即使单个用户或事务产生负载,该负载也可能不足以真正锻炼被测系统。通过并发性,性能工程师可以定义有多少业务流程、任务甚至步骤同时发生。

一般可考虑三种并发类型。例如,如果被测系统是一个在线零售网站,许多用户可能同时在网站上执行一系列功能。在组件层面,测试登录组件时可能需要同时进行多次登录尝试。细分如下

  • 应用程序并发性

可能有许多用户使用网站执行不同的业务流程(搜索、购买、检查订单状态、创建用户帐户等)。

  • 业务流程并发

较少数量的用户可能同时执行一个业务流程(搜索网站)。

  • 事务并发

用户子集同时执行一个业务流程(搜索),所有用户同时点击搜索按钮。-

也可能出现意外情况,这些情况更多属于故障转移和灾难恢复的范畴,但仍需要进行性能测试。并发测试可能会在高峰负载时同时运行批处理,或在繁忙时开始计划备份。

容量测试(Capacity Testing)

容量测试确定给定系统将支持多少用户和/或事务,并仍然满足既定的性能目标。这些目标也可能与事务产生的数据量有关。

容量:组件或系统参数的最大限制满足要求的程度。

容量测试类似于其他已经确定的测试类型(压力和尖峰测试)。容量测试和压力测试的区别在于,压力测试延伸到预定的故障点(例如,吞吐量或资源利用率的限制,或超过处理时间)。容量测试仍可能超出峰值负载,但其目的是实现性能测试目标(例如,系统将支持多少用户),而不是确定故障原因。容量测试的重点是达到规定的性能水平,而不是试图导致故障(压力)或 "看看会发生什么"(峰值)。通常情况下,容量测试的负载/性能增长与组织需求有关。例如,组织可能有一个全球增长率,定义为每年4%的新客户增长。容量测试可以帮助回答系统支持这种逐年增长的能力问题。文章来源地址https://www.toymoban.com/news/detail-550364.html

到了这里,关于后端性能测试的类型的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 确定Oracle SQL语句性能瓶颈

    9.1. 分析Cost方法 9.1.1. 方法说明 SQL调优(SQL TUNING),就是在SQL语句执行计划中,发现浪费大量系统资源的节点,然后,想办法降低该节点对系统资源的消耗,以使其不再浪费系统资源。那么,SQL语句执行计划中,衡量系统资源的标准是什么呢?Oracle优化器结合各种统计数据

    2024年02月03日
    浏览(34)
  • Gpt微信小程序搭建的前后端流程 - 前端小程序部分-2.确定交互所需的后端API(二)

    Gpt微信小程序搭建的前后端流程 - 前端小程序部分-2.确定交互所需的后端API(二) 参考微信小程序- 小柠AI智能聊天 ,可自行先体验。 根据上一节的小程序静态页面设计,需要从后端获取数据的主要4个点: 登录流程; 获取今日已提问次数; 获取聊天记录; 发起聊天和响应。

    2024年02月13日
    浏览(32)
  • 确定Mac\Linux系统的架构类型是 x86-64(amd64),还是 arm64 架构

    我们在下载软件或镜像时会有很多版本,那需要根据我们的系统架构选择正确的软件或镜像版本。 要确定你的系统使用的是 x86-64(amd64) 还是 arm64 架构,可以使用以下方法之一: 使用 uname 命令: 打开终端,并运行以下命令: 在MAC中: 如果输出结果是 x86_64 ,则表示你的系

    2024年02月08日
    浏览(33)
  • 【SQL开发实战技巧】系列(十八):数据仓库中时间类型操作(进阶)INTERVAL、EXTRACT以及如何确定一年是否为闰年及周的计算

    【SQL开发实战技巧】系列(一):关于SQL不得不说的那些事 【SQL开发实战技巧】系列(二):简单单表查询 【SQL开发实战技巧】系列(三):SQL排序的那些事 【SQL开发实战技巧】系列(四):从执行计划讨论UNION ALL与空字符串UNION与OR的使用注意事项 【SQL开发实战技巧】系列

    2024年02月01日
    浏览(36)
  • 前端传输数组类型到后端(附代码)

    通过问题Bug指引代码实战,结合实战问题,相应查漏补缺 前端传输数组给后端的时候,出现如下问题: 前端log请求如下: 且请求后端你的时候出现了服务器500error: 如果不使用 JSON 格式传输数据,而是使用普通的数组,可以考虑通过 POST 请求的 body 直接传输数组的形式 前端

    2024年04月17日
    浏览(28)
  • 前端和后端交互数据类型转换

    页面是男/女 后端pojo类以及数据库中是Integer 0/1  怎么样很方便地转化? ----枚举转化-- 在web开发中有时会使用枚举作为参数,而前端在调接口时就会出现传错或者传空导致后端拿不到枚举类型。在这里就使用反序列化@JsonDeserialize 这里是对枚举进行反序列化,所以首先编写一个

    2024年03月26日
    浏览(42)
  • 【架构】后端服务架构高性能设计方法

    “N 高 N 可”,高性能、高并发、高可用、高可靠、可扩展、可维护、可用性等是后台开发耳熟能详的词了,它们中有些词在大部分情况下表达相近意思。本序列文章旨在探讨和总结后台架构设计中常用的技术和方法,并归纳成一套方法论。 本文主要探讨和总结服务架构设计

    2024年02月11日
    浏览(40)
  • 后端Long类型传到前端精度丢失的问题

    问题出现:后端的Java Bean的id属性是用的Long类型对应数据库主键使用bigint类型,当使用JSON方式传递该数据给前端时,前端接收到的数据末尾会变成0。(发生的精度丢失问题) 问题原因:Java中的long能表示的范围比js中number大,也就意味着部分数值在js中存不下(变成不准确的值

    2024年02月16日
    浏览(37)
  • 后端long类型数据在前端产生精度损失

    后端我们常常会用Long类型的数据作为ID,例如用雪花算法生成唯一ID java中long类型的取值范围 (-9,223,372,036,854,775,808)(9,223,372,036,854,775,807)。有19位数字 JavaScript的Number类型是浮点数类型,它可以表示的整数范围是从(-9,007,199,254,740,992)到2^53(9,007,199,254,740,992)只有16位数

    2024年02月16日
    浏览(33)
  • 后端传long类型数据到前端精度丢失问题

    在 Spring Boot 中,将 long 类型传输到前端时,会发现该类型的值可能会出现精度丢失的问题。 这是因为在 JavaScript 中,数字类型默认会被转换为双精度浮点数,而双精度浮点数的精度有限,只能精确表示 2 的 53 次方以内(即 Number.MAX_SAFE_INTEGER,约为 9 x 10^15)的整数。对于超过

    2024年02月15日
    浏览(29)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包