作者:Larry

如果您是开发人员,QA工程师或DevOps,则知道需要进行不同类型的性能测试,以确保每个代码更改或添加的功能(a)不会破坏系统,并且(b)可以工作。

但是,您应该执行哪种类型的性能测试,负载测试和其他类型的测试之间有什么区别,哪种测试适合于哪种情况?在此博客文章中,我们将介绍这些问题的答案以及更多内容。

什么是性能测试?

性能测试是检查系统行为和性能的测试的总称。性能测试检查软件和基础架构的响应能力,稳定性,可伸缩性,可靠性,速度和资源使用情况。不同类型的性能测试将为您提供不同的数据,我们将进一步详细介绍。

在进行性能测试之前,确定系统的业务目标很重要,这样您就可以根据客户的需求判断系统的性能是否令人满意。

运行性能测试后,您可以分析不同的KPI,例如虚拟用户数,每秒命中数,每秒错误,响应时间,延迟和每秒字节数(吞吐量)以及它们之间的相关性。通过报告,您可以确定瓶颈,错误和错误,并确定需要执行的操作。

什么时候应该使用性能测试?

当您要检查网站性能和应用程序性能以及服务器,数据库,网络等时。如果使用瀑布方法,则至少每次发布一个版本时。如果您向左移动并变得敏捷,则应该不断进行测试。

这是CA BlazeMeter上的性能测试报告的示例。这是一个很好的测试,因为用户数量的增长不会影响响应时间,错误率持续较低,每秒的点击数随用户数量的增加而增加,但保持稳定。

CA BlazeMeter的性能测试报告

什么是负载测试?

负载测试是一种测试,用于检查在一定时期内大量并发虚拟用户在执行事务的系统如何运行。换句话说,系统如何处理重负载。有几种类型的开源负载测试工具,其中JMeter是最受欢迎的工具

什么时候应该使用负载测试?

当您要确定系统可以处理多少个用户时。您可以确定不同的用户方案,让您专注于系统的不同部分,例如网站或应用程序上的结帐网页,以进行Web负载测试。您还可以确定负载的行为方式,例如地理位置用户来自何处,或者负载如何在系统中构建和维持。基本上,负载测试是您始终应该做的事情,以确保系统始终处于正常状态。这就是为什么应该使用JenkinsTaurus之类的工具将其集成到您的持续集成周期中的原因。

这就是JMeter中的负载测试的样子。此测试分析每30秒增加100个用户,直到达到1,000个用户。整个步进过程需要300秒。在达到1,000个线程之后,所有线程将继续运行并将服务器连接5分钟。

用火焰计进行压力测试

什么是压力测试?

压力测试是通过在极端负载下进行测试来检查系统上限的测试。该测试检查系统在高负载下的行为,以及恢复正常使用后如何恢复,即吞吐量和响应时间之类的KPI是否与以前相同?除了对KPI进行负载测试外,压力测试还检查内存泄漏,速度慢,安全性问题和数据损坏。

压力测试可以通过负载测试工具进行,方法是定义一个具有大量并发虚拟用户的测试用例。如果压力测试包括虚拟用户数量的突然增加,则称为“峰值测试”。如果您长时间进行压力测试以通过缓慢的上升来检查系统随时间推移的可持续性,则称为“浸泡测试”

什么时候应该使用压力测试?

网站压力测试和应用程序压力测试对于重大事件(例如黑色星期五),要求很高的流行音乐会或选举的门票销售之前的重要活动很重要。但是我们建议您不时进行压力测试,以便了解系统的耐用性。这样可确保您始终为意外的流量高峰做好准备,并为您提供更多的时间和资源来解决瓶颈。

在此示例中,我们描述如何使用“Ultimate Thread Group”工具来获取流量高峰。我们假设被测系统在测试开始后的3:00分钟处处于通信中。通过Ultimate Thread Group,我们使用初始delay属性定义了在固定时间窗口中运行的其他线程(请参见下图)

火焰计的性能测试

使用不同类型的性能测试可确保您始终了解所遇到的问题,并可以计划如何解决这些问题。因此,不要放弃任何类型的测试。

对比

下表列出来了三种测试的区别:

Performance Testing Load testing Stress testing
Domain Superset of load and stress testing A subset of performance testing. A subset of performance testing.
Scope Very wide scope. Includes – Load Testing, Stress Testing, capacity testing, volume testing, endurance testing, spike testing, scalability testing and reliability testing, etc. Narrower scope as compared to performance testing. Includes volume testing and endurance testing. Narrower scope as compared to performance testing. Includes soak testing and spike testing.
Major goal To set the benchmark and standards for the application. To identify the upper limit of the system, set SLA of the app and see how the system handles heavy load volumes. To identify how the system behaves under intense loads and how it recovers from failure. Basically, to prepare your app for the unexpected traffic spike.
Load Limit Both – below and above the threshold of a break. Till the threshold of break Above the threshold of break
Attributes studied Resource usage, reliability, scalability, resource usage, response time, throughput, speed, etc. peak performance, server throughput, response time under various load levels (below the threshold of break), adequacy of H/W environment, the number of user app can handle, load balancing requirements, etc. Stability beyond bandwidth capacity, response time (above the threshold of break),etc.
Issues identified through this testing type All performance bugs including runtime bloat, the scope for optimization, issues related to speed, latency, throughput, etc. Basically – anything related to performance! Load balancing problems, bandwidth issues, system capacity issues, poor response time, throughput issues, etc. Security loopholes with overload, data corruption issues at overload situation, slowness, memory leaks, etc.

计算机生成了可选文字:
性能试
图4.3性能测试曲线
压力试
豕鲮资源

计算机生成了可选文字:
响应时间
系
臼堂运行区间
最体负虱点
系0娃运行貞
芸点
#发用户
图4.4
并发用户访问响应时间曲线

性能测试里的QPS和TPS是什么

QPS:Queries Per Second意思是“每秒查询率”,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

TPS:是TransactionsPerSecond的缩写,也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数,

个人理解如下:

1、Tps即每秒处理事务数,包括了

1)用户请求服务器

2)服务器自己的内部处理

3)服务器返回给用户

这三个过程,每秒能够完成N个这三个过程,Tps也就是3;

2、Qps基本类似于Tps,但是不同的是,对于一个页面的一次访问,形成一个Tps;但一次页面请求,可能产生多次对服务器的请求,服务器对这些请求,就可计入“Qps”之中。

例如:访问一个页面会请求服务器3次,一次放,产生一个“T”,产生3个“Q”

希望大家通过这篇文章对性能测试有个初步的了解。

By larryonaws

10多年大型企业软件研发管理经验,曾就职于爱立信、汤森路透、甲骨文、亚马逊AWS等公司。丰富的企业软件项目管理、架构设计、开发测试、交付运维、客户成功、大客户销售等职业经历。 有多年管理PeopleSoft/Fusion SaaS ERP套件研发工作的经历,对大型ERP软件有深刻的理解和丰富的经验。 AWS解决方案专业架构师,致力于推动AWS创新技术赋能企业软件的云转型。

发表评论

邮箱地址不会被公开。 必填项已用*标注