性能测试基本测试概念
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
.
一、性能测试的目的
1、评估当前系统
2、寻找瓶颈
3、预测未来性能
二、性能测试的前提:
接口稳定/接口确定
三、性能术语与指标详解:
1.并发:(1)一种为所有用户在同一时刻做同一操作,主要是为了验证程序或数据库对并发处理能力
(2)另一种为多个用户对被测系统发起了多个请求,这些请求可以是同一种操作,也可以是不同操作,类似于混合场景的概念
2. 响应时间:响应时间反应完成某个业务所需的时间
响应时间= 网络传输时间(请求)+服务器处理(一层或多层)时间+网络传输时间(响应时间)+页面前端解析渲染时间
3.每秒通过事务数(TPS):指每秒通过的事务数,是直接反映系统性能的指标,该值大时,系统性能比较好,当然每个系统都有他的上限,不可能无限大
将他以平均事务响应时间进行对比,可以分析事务数量对以响应时间的影响
4.事务:用户一个或一系列的操作,代表一定的功能,在程序上变现为一段代码区块,所有性能测试其实最终都是围绕着事务展开的,事务代表用户的使用方法和结果,不同的操作组合成不同的事务,不同的事务又能组合成不同的场景(LR 必须至少有一个事务,LR监控事务)
(事务不能超过接口的上限)
事务 Transactions
5.事务请求时间:从这个事务发起到最终处理完毕的所有时间。
一个事物包括一个或多个事务,每个任务包含一个或多个请求。
6.每秒点击数:每秒点击数代表用户每秒向外部服务器提交的http请求,但这里需要注意是提交一个登陆请求对于后端服务器来说,也许是多个请求,所以点击一次不代表就是一个请求。
7.吞吐量/吞吐率(I/O)(Input/Output)(反应服务器处理能力)
吞吐量:指单位时间内系统处理的请求数量
吞吐率:一般指用户在给定的一秒内从服务器获取的数据量,简而言之就是服务器返回的数据量
8.思考时间:指用户进行操作时每个请求或操作之间的间隔时间,是为了更加真实的模拟用户的操作场景。
9.资源利用率(服务器)
CPU:一般分为系统CPU和用户CPU
15
/ 1
.
:是处理系统本身占用的资源系统CPU :是处理程序所占用的资源用户CPU处理的任务,也就是CPUCPU正在处理和等待Load Average:指一段时间内使用队列的长度的统计信息CPU将各种信息收集起来存他就像大脑的记忆区域,运行速度慢):缓存(比CPU 放,数据从内存中读取要比硬盘上读取速度快,内存会有泄露和溢出现象。队列:可以理解成地铁进站的排队现象,队列长,说明处理能力可能达到了
极限或者遇到的阻塞交换频率和磁盘队列长度(硬盘):与磁盘的交互,重点关注I/O网络的流量,看是否存在网络带宽的瓶颈:重点关注网络四、性能测试分类这样以后当系统:可以在制定的标准下通过测试建立一个性能基
准,1.基准测试即可看出变化对性能的的环境参数发生变化后,在进行一次相同标准下的测试,影响。系统进行基准测试可以在较早的阶段发现性能问题。
可以理解为很多的用户按照预定的场景并发请求某个业务或功能时并发测试:2. 是否出现并发问题。并发测试的算法:服务器/web响应时间*因数=PV/PV Time*1)并发数页面连接次数*HTTP(数量。PV解释:PV:即页面浏览量,一个用户可能创造十几个甚至更多的他是目前判断网站访问流量最常用的计算方法,也是反映网站受欢迎程度的重要指标。秒的统计时间,换算成秒,一天就是86400PV Time:是PV
10 ,图片等,一般为,CSS页面连接次数包括外部的JS 1秒或更少响应时间一般为HTTP因数一般为5
(2) C=nL/T (段念【软件性能测试过程详解与案例剖析】)
解释:C是平均的并发用户数
n是平均每天访问用户数
L是一天内用户从登录到退出的平均时间(操作时间)
T是考察时间长度
C'≈C+3*√c
解释:C' 是最大并发数
3.负载测试:可以理解为确定所要测试的业务或系统的负载范围,然后对其进行测试,他的主要目的验证业务或者系统在给定负载条件下的处理能力。此外,还要关注响应时间、每秒通过事务数和其他相关指标。
负载测试是为了发现性能问题。而性能测试是为了获取性能指标。
4.压力测试:可以理解为没有预期的性能指标,不断加压,看系统什么时候崩溃,以此来确定系统的瓶颈不能接受的性能拐点,以获取系统的最佳并发数,最大并15
/ 2
.
发数
压力测试也可以看作负载测试的一种,即高负载下的负载测试。负载测试与压力测试的概念并非完全独立,在实际应用中一般二者都是相互结合,相互补充的。
5.稳定性测试(小公司不测):需要长时间运行,在这段时间内观察系统的出错
几率、性能变化趋势等。进而大大减少系统上线后的崩溃的现象。
一般都会进行所谓的7*24小时的稳定性测试
1)一般稳定性测试需要在系统成型后进行,并且没有严重的BUG存在 2)场景的设计以模拟真实用户的实际操作为最佳。
6.失效恢复测试(小公司不测):重在关注系统出现问题后能否根据预先制定的策略回恢复,且恢复后能否正常运行。
失效恢复测试一般是对其具有负载均衡的系统进行的,主要是为了测试当前系统发生故障时,是否会对全局产生大的影响,产生的影响在是否可以接受的范围内,以及用户能否继续使用系统。
在实际应用过程中,可以模拟一台或者几台负载均衡出现故障来进行失效恢复测试,但需要注意的是,不仅要关心失效后,用户是否可以正常访问或者恢复后系统是否可以正常工作,也要关注失效后,系统还能支持多少并发用户,以及采用那些备选方案来响应。
7.现网性能测试(小公司不测):就是实际网络,实际环境中进行测试,完全和真实用户一样,当然这样的测试有一定的风险,需要注意以下几点:(1)时间段的选择,非高峰时间段,选择都为半夜或者凌晨来进行
(2)垃圾数据处理。测试数据后期一定要清理,为了清理方便、前期数据的设计要有规律可循
(3)网络限制,压力机需要和被测试服务器部署在同一个网段机房内,这样可以避免网络限制,最后远程收集数据即可。
*如果没有特殊情况,尽量不要进行现网的性能测试,风险比较大,如果非要进行,一定要事先充分评估风险以及应对的解决方案。
LR的三大模块
Virtual user Generator LR8(虚拟用户生成器)
Create/Edit Scripts LR11
创建/编辑脚本
LR进行操作的第一步,制造基本性能脚本
性能测试前的准备
Controller(控制器)
Run Load Tests
15
/ 3
.
运行负载测试
在脚本写完的基础下,对其设置不同的场景,进行测试
性能测试执行
Analysis(分析)