性能测试的基础概念原理

简介: 介绍关于性能测试基础概念,核心指标:并发用户数(VU)、吞吐量(QPS/TPS)、响应时间(RT),以及在性能测试过程一些注意事项。

image.png

0. 什么是性能测试?

系统的性能是一个很大的概念,覆盖面非常广泛,软件系统的性能包括执行效率、资源占用、系统稳定性、安全性、兼容性、可靠性、可扩展性等。

性能测试是为描述测试对象与性能相关的特征并对其进行评价而实施和执行的一类测试。性能测试主要通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

通常把负载测试、压力测试、容量测试等统称为性能测试。

负载测试

负载测试是通过逐步增加系统负载,测试系统性能的变化,并最终确定在满足系统性能指标的前提下,系统所能够承受的最大负载量的测试。

简而言之,负载测试是通过逐步加压的方式来确定系统的处理能力和能够承受的各项阈值。例如,通过逐步加压得到“响应时间不超过10秒”、“服务器平均CPU利用率低于85%”等指标的阈值。

压力测试

压力测试是通过逐步增加系统负载,测试系统性能的变化,并最终确定在什么负载条件下系统性能处于失效状态来获得系统能提供的最大服务级别的测试。压力测试是逐步增加负载,使系统某些资源达到饱和甚至失效。

配置测试

配置测试主要是通过对被测试软件的软硬件配置的测试,找到系统各项资源的最优分配原则。配置测试能充分利用有限的软硬件资源,发挥系统的最佳处理能力,同时可以将其与其他性能测试类型联合应用,从而为系统调优提供重要依据。

并发测试

并发测试是测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题,所以几乎所有的性能测试都会涉及一些并发测试。因为并发测试对时间的要求比较苛刻,通常并发用户的模拟都是借助于工具,采用多线程或多进程方式来模拟多个虚拟用户的并发性操作。

容量测试

容量测试是在一定的软、硬件条件下,在数据库中构造不同数量级的记录数量,通过运行一种或多种业务场景,在一定虚拟用户数量的情况下,获取不同数量级别的性能指标,从而得到数据库能够处理的最大会话能力、最大容量等。系统可处理同时在线的最大用户数,通常和数据库有关。

可靠性测试

可靠性测试是通过给系统加载一定的业务压力(如CPU资源的使用率在70%~90%时)的情况下,运行一段时间,检查系统是否稳定。因为运行时间较长,所以通常可以测试出系统是否有内存泄露等问题。

在实际的性能测试过程中,也许用户经常会碰到要求7 × 24小时稳定运行的系统性能测试需求,对于这种稳定性要求较高的系统,可靠性测试尤为重要,但通常一次可靠性测试不可能执行1年时间,因此在多数情况下,可靠性测试是执行一段时间,如24小时、3 × 24小时或7 × 24小时来模拟长时间运行,通过长时间运行的相关监控和结果来判断能否满足需求,平均故障间隔时间(MTBF)是衡量可靠性的一项重要指标。

失败测试

对于有冗余备份和负载均衡的系统,通过失败测试来检验如果系统局部发生故障,用户能否继续使用系统,用户受到多大的影响,如几台机器做均衡负载,一台或几台机器垮掉后系统能够承受的压力。

1. 什么是并发?

从用户业务的角度,并发分为狭义和广义两类。

狭义并发即所有的用户在同一时刻做同一件事情或操作,这种操作一般针对同一类型的业务,或者所有用户进行完全一样的操作,目的是测试数据库和程序对并发操作的处理。比如,所有用户同一时刻做并发登录,同一时刻做表单提交。

广义并发即多个用户对系统发出了请求或者进行了操作,但是这些请求或操作可以是不同的,但对整个系统而言,仍然是有很多用户在同时进行操作。比如,在同一时刻有的用户在登录,有的用户在提交表单。

狭义并发强调对系统的请求操作是完全相同的,多适用于负载测试、压力测试;广义并发不限制对系统的请求操作,多适用于混合场景、稳定性测试。

从服务器的角度来看并发

前面的两种解释都是从用户业务的角度来解释并发的,因为我们平时所做的性能测试也是从用户端对业务层的操作来进行并发测试的。

如果考虑整个系统运行过程中服务器所承受的压力是这样的:在该系统的运行过程中,把整个运行过程划分为离散的时间点,在每个点上都有一个“同时向服务端发送请求的客户数”,这个就是所谓的服务器所承受的最大并发访问数。

2. 什么是并发用户数?与在线用户数和注册用户数的区别是?

并发用户数是指现实系统中同时操作业务的用户数,在性能测试工具中一般称为虚拟用户 (Virutal User)数。并发用户数跟注册用户数、在线用户数有很大差别:

  • 并发用户数:一定会对服务器产生压力的用户数量。
  • 在线用户数:只是“挂”在系统上对服务器不产生压力的用户数量。
  • 注册用户数:一般指的是数据库中存在的用户数量。

假设一个网站有20万注册用户,那20万就是这个网站的“注册用户数”。网站有一个在线统计功能,从统计数据中可以看到,同时登录网站的人数的最高记录是2万,就是有2万人同时用浏览器打开着这个网站,2万就是“在线用户数”

那么系统的并发用户数是多少呢?2万只表示系统最高峰时有这么多用户登录了网站,并不表示实际服务器的承受压力。因为服务器承受压力还与具体的用户访问模式相关,在这2万用户中考察某一个时间点用户发出请求数,可以会大大缩水。那么,该系统的服务端承受的最大并发访问数是多少呢?这个取决于业务并发用户数和业务场景,一般可以通过服务器日志的分析得到。

3. 什么是TPS、QPS?

TPS(Transaction Per Second):每秒事务数,即每秒系统能够处理的交易或事务的数量,它是衡量系统处理能力的重要指标。

QPS(Queries Per Second):每秒请求数,即每秒系统能够处理的请求数,它也是衡量系统处理能力的重要指标。

4. 并发用户数、响应时间和TPS之间的关系是?

事务是靠虚拟用户(并发用户)产生的,假如1个虚拟用户在1秒内完成1笔事务,那么TPS就是1,要想达到1000TPS至少需要1000个虚拟用户;如果某笔业务响应时间是1毫秒,那么1个虚拟用户在1秒内能完成1000笔事务,TPS就是1000。

因此1个虚拟用户可以产生1000TPS,1000个虚拟用户也可以产生1000TPS,主要看响应时间的快慢。

由此我们可以得出一个公式:TPS=虚拟用户数(并发用户数)/响应时间

BUT,该公式看似成立,但仅适用于单机单接口压测场景,因为在混合负载的情况下用户不仅只发送一个请求

5. 如何选择并发用户及施压策略?

对于已上线的系统,可以选取高峰时刻在一定时间内使用系统的人数,这些人数可以认为是在线用户数,并发用户数取其10%就可以了。例如在1小时内使用系统的用户数为10000,那么取10%作为并发用户数基本就够了。

对于新系统,没有历史数据作参考,只能通过业务部门进行评估。

性能测试需要一套标准化流程及测试策略,并发用户数只是指标考虑的一个。在进行压测时一般会按照梯度施压的方式增加用户数,以此观察系统在不同压力下的各种反应。而不是在没有预估的情况下,一次加压大量用户,这样会导致系统失败率高响应时间长,最终得到的测试结果也没有太大意义。

一般情况下,大型系统(业务量大、机器多)做性能测试 5000 个并发用户就够了,中小型系统做性能测试 1000 个并发用户就足够了。

6. 如何获取TPS?

对于已上线系统,可以通过高峰时刻,在5或10分钟内获取系统每笔交易的业务量和总业务量,然后按照单位时间内完成的笔数计算出TPS, 即业务笔数 /单位时间(5x60或10x60)。

对于新系统,因没有历史数据可供参考,只能通过业务发展趋势来预判各项指标,或者可以采用二八原则对TPS进行预估,即指80%的业务量在20%的时间里完成。

可以得出的公式:TSP=(90%x业务量x80%)/(20%x时间)

该公式比较适合一些互联网系统,比如秒杀、抢购等营销活动场景。

7. 如何评价系统性能?

在做性能测试的时候,很多人都用并发用户数来衡量系统的性能,觉得系统能支撑的并发用户数越多,系统的性能就越好。

其实,针对服务器端的性能,应该以TPS为主来衡量系统的性能,并发用户数为辅来衡量系统的性能。如果必须要用并发用户数来衡量的话,需要一个前提,那就是交易在多长时间内完成。因为在系统负载不高的情况下,将交易响应时间加到脚本中,并发用户数基本可以增加一倍,因此用并发用户数来衡量系统的性能没太大的意义

8. 测试脚本中事务选择的原则是什么?

测试脚本中事务选择的基本原则是:根据您的实际需求来设计。以一个网站为例:

如果您的压测目的是为了测试系统某个页面的对外服务能力,则可以用其页面的访问url作为一个事务。

如果您的压测目的是为了测试某个功能的服务能力,比如一个页面里某个url的服务能力(例如页面里有一个url需要访问数据库,想测试数据库的访问能力),则可以只压测这个url。

如果您的压测目的是为了测试某个业务场景或流程,比如从用户登录到浏览商品再到下单,这种较为复杂的业务流程,则需要对脚本中事务进行组合编排,包括一些参数的传递。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
2月前
|
监控 Java 测试技术
精准化测试原理简介
该文探讨了软件测试中的精准化测试问题,通过找不同游戏引出测试覆盖的挑战。文章指出,全面的测试覆盖并不现实,自动化测试虽有帮助但并非银弹,且面临成本和覆盖率局限。接着,文章提出需要“最强大脑”来快速识别代码差异、影响范围及测试覆盖率。为此,它介绍了通过语法分析器和字节码来定位代码差异,利用ASM进行调用链分析,并借助Jacoco进行覆盖率统计。此外,文章强调了增量覆盖率统计和调用链在接口测试中的重要性,同时提醒高覆盖率不代表高质量,测试策略应结合业务逻辑和代码审查。
27 2
|
3月前
|
Java 测试技术 Maven
JAVA单元测试概念与实战
单元测试是软件开发中的一个测试方法,用于验证软件代码中最小的、独立的单元是否按照预期工作。在Java中,这通常指的是单个的方法或者一个类的个别功能。单元测试的目的是隔离代码的每个部分,并确保各个部分是正确的。
57 4
|
4月前
|
jenkins 测试技术 持续交付
软件测试:基础概念
软件测试:基础概念
54 0
|
5月前
|
测试技术 UED
软件测试/测试开发|软件测试基础概念
软件测试/测试开发|软件测试基础概念
32 0
|
5月前
|
JavaScript Java 测试技术
『App自动化测试之Appium基础篇』| 从定义、原理、环境搭建、安装问题排查等深入了解Appium
『App自动化测试之Appium基础篇』| 从定义、原理、环境搭建、安装问题排查等深入了解Appium
816 0
|
5天前
|
前端开发 测试技术
前端自动化测试中的快照测试原理
快照测试用于前端自动化测试,通过比较当前应用状态与预存预期快照来检测UI变化。流程包括设置测试环境、捕获屏幕快照、保存预期快照、比较快照及处理差异。当快照比较出现差异时,测试工程师审查判断是否为预期变化或错误,确保应用一致性。这种方法在重构、样式更改和跨浏览器测试时提供有效回归测试,减少手动验证工作。
|
15天前
|
测试技术 开发者
【专栏】测试驱动开发(TDD)和行为驱动开发(BDD)的核心概念与实践
【4月更文挑战第27天】本文探讨了测试驱动开发(TDD)和行为驱动开发(BDD)的核心概念与实践。TDD强调先写测试用例,通过测试推动设计,确保代码质量与可维护性。BDD侧重软件行为和业务价值,提倡使用通用语言描述行为,减少沟通障碍。选择TDD或BDD取决于项目复杂性、团队技能和业务需求。理解两者差异有助于团队做出合适的选择,发挥测试的最大价值。
|
1月前
|
敏捷开发 编解码 测试技术
【测试】1. 概念 + 基础篇
【测试】1. 概念 + 基础篇
41 1
|
2月前
|
测试技术 Android开发
快速上手App自动化测试利器,Toast原理解析及操作实例
`Toast`是Android中的轻量级通知,短暂显示在屏幕任意位置,1-2秒后自动消失,不获取焦点且不可点击。Appium通过uiautomator2在控件树中处理Toast。在测试中,可设置隐式等待,利用XPath或Accessibility ID定位Toast元素进行检测和验证。示例代码展示了如何初始化driver,点击触发Toast,以及如何定位并读取Toast文本。
28 3