一)谈谈你对于性能测试的理解:
1)性能测试的概念+ 测试目的+与功能测试的区别+性能测试的指标
2)性能测试需要借助工具来进行测试,可以说说自己是用了哪些工具以及如何使用工具来进行性能测试
3)为了避免面试官在性能测试方面进行深究,主动说性能测试难就难在性能分析,需要具有多个方面的知识储备,说自己只会进行一些简单的性能测试;
二)loadrunner工具介绍:
要具体介绍三个组件,从个人使用上来说虽然VUG具备强大的录制功能,但是录制好的脚本达不到预期的测试目标,我们仍然会选择通过手动编写性能测试脚本的方式来进行增强代码
引出增强脚本的方式:事务,集合点
检查点(检查页面对应的展示是否符合预期)
参数化(模拟用户的输入)
来模拟大量用户的并发,来检测系统的性能
三)如何对自己的个人的项目来进行性能测试呢?
一)要进行性能测试方案的制定:
如何来确定哪些页面,哪些功能适合做性能测试?
主要是针对用户大量进行访问的界面还有一些主要的功能界面
二)性能测试设计和开发:主要是进行脚本的开发
哪些功能设计了一个事务
那些功能设置了检查点
那些功能设置了集合点
哪些功能设置了参数化
使用Controller进行创建场景,运行并且进行监控,点击率,虚拟用户,吞吐量,观察运行情况
三)使用analysis进行性能分析:
性能调优:避免全表查询
性能测试执行:
1)同时几千万人同时访问接口,看看页面访问时间,页面是否可正常展现
2)比如说对于这个登陆注册的接口,设计千万个注册登录的接口,看是否页面可以正确的展现,造成服务器负载压力过大;
1)我们的系统处理资源的能力是有限的,有一个最大的信息处理的一个量,一旦超过系统所能够处理的最大的信息量的时候,系统的性能就会发生极大的改变,这个点就叫做系统性能测试拐点,系统最大的负载和系统性能逐渐下降的一个临界点;
2)当我们在做压力测试的时候,负载测试,都希望能够找出性能测试的拐点,找到系统性能测试瓶颈,要研究一下系统的架构,看看是不是存在线程的同步问题,资源争抢问题,还有看看到底是哪一个组件功能,算法,阻碍了性能的提示,从而做出进一步的优化,在拐点处可以查看日志
一)常见的性能问题:
1)系统的内存泄漏或者是资源泄露,分配的内存无法回收或者是忘记回收内存从而导致不停的分配内存,耗尽了内存,从而导致系统运行越来越慢,最终导致系统崩溃
2)线程阻塞,线程死锁,导致系统程序无法继续向下执行
3)查询列表展示的速度越来越慢,刷新页面,软件各个功能的响应时间,页面加载时间和按钮反应时间,页面跳转时间
4)CPU的利用率达到了100%,最多只能占有70%,以及各种资源,内存资源,磁盘资源,网络资源,带宽资源,
5)弱电,弱网以及各个功能使用时候的耗电量
二)为什么要进行性能测试
1)进行基准的性能测试,获取到新系统性能的基准性能指标,比如说开发新功能不能影响到老功能的性能,所以我们需要先知道老功能的性能指标;
2)测试系统是否满足了系统的性能需求,就是是否达到了系统所进行期望的性能指标
2.1)看看系统是否可以进行预期的并发用户数量或者有一定盈余的能力(保证系统在任何情况进行稳定运行)
2.2)看看系统是否能够达到要求的性能指标
2.3)系统是否可以处理预期的事务数量
2.4)系统在预期和非预期的情况下,应用程序都是可以稳定的运行的
2.5)系统在任何情况下,用户都会有良好的体验
3)当系统出现性能问题的时候,可以找到系统的性能瓶颈,发现资源泄露等问题
4)进行性能测试的时候,可以帮助我们的系统规划硬件设备,哪一款软件在对应的硬件上使用比较好
5)可靠性:就是我们的系统是否能够长时间地承受高并发的这种情况,用户负载比较多
6)可扩展性:是否能够改成处理更多的用户请求
三)系统性能测试的流程:
1)先知道系统的性能需求:根据性能需求分析出系统性能指标的要求,要量化
2)根据性能需求分析出来的进行性能测试的类型,要确定性能场景,必须知道是进行压力测试还是并发测试,还是可靠性测试,因为不同的测试场景对时间和实际负载是不一样的
3)运行我们的性能测试场景,得出性能测试报告
4)根据性能测试报告找到系统性能测试的瓶颈
四)如何确定性能测试的需求来确定性能测试的指标
1)关键性能指标的分析
1)要支持2亿用户中的1%在线
1.1)所以同一时刻200万用户同时在线,所以说至少要支持200万用户的并发量
1.2)还要支持200亿用户的支持增删改查操作,响应时间低于1s
2)既然每天都支持2000万的次交易,时间在早上的8点到晚上的2点,所以说这个操作系统每秒钟支持的交易次数是(2000W/16*3600=309次/s)
3)高峰期:因为题干已经说了,高峰期系统的处理能力要求是平均值的三倍,所以会支持6000万次交易量,并且响应时间要在3s内,交易成功率(HTTP请求的成功率)不能低于99.9%
2)关键业务分析,分析可能会影响到系统整体性能的功能模块
1)关键业务就是用户频繁使用的业务,比如说淘宝打开首页,搜索商品比较多,用的比较少的功能比如说收藏商品
2)计算量比较大的业务,比如说支付功能,支付卷功能,后台的计算量是很大的
五)衡量软件性能的四个维度
1)软件开发人员
系统架构:架构设计是否合理?
数据库设计:数据库设计是否存在问题,数据查询太慢,索引设计不合理会影响性能
算法:核心算法效率是否高?占用内存之间和速度执行方面取一个综合的值
设计和代码:系统资源分配不合理的问题2)系统运维人员(操作系统、网络、服务器等等)
系统容量以及系统长期的稳定运行,服务器及各种资源分配是否合理,增加服务器
3)用户体验:越快越越好,响应时间快还有稳定提供有效的数据
4)测试人员:以上都要进行考虑
常见误区:
1)性能测试独立于功能测试:一般是在功能测试稳定之后再来进行性能测试,一个功能本身就不稳定,那么当有多个用户进行并发访问的时候肯定就玩完了
2)性能测试通常是在功能测试完成的中后期,等到功能测试稳定之后再来进行性能测试
六)性能测试指标:
系统用户数量:注册系统的用户数量不等于并发用户数
1)并发用户数:同一时刻向服务器发送请求的数量
业务层面并发数:同一时刻向服务器发送请求的用户数量
后端服务器层面并发数:同一时刻向后台服务器发送的HTTP请求的数量
2)系统的响应时间:
是指用户发出HTTP请求到前端页面渲染出所有数据展示到用户面前的时间
响应时间分为前端展示时间和系统响应时间两部分
响应时间=人的反应时间+网络传送时间(一来一回)+服务器处理时间(响应时间)+数据库响应时间+前端渲染页面的时间
2.1)前端展示时间指的是客户端收到服务器返回的数据后渲染前端页面,所耗费的时间。
2.2)系统的响应时间,分为web服务器,应用服务器,数据库服务器,等各种服务器之间通信和处理请求的时间3)系统平均响应时间:是指所有HTTP请求的一个平均响应时间
4)吞吐量:Throughput Second
系统在单位时间内处理的信息量,处理信息无非就是处理用户发送过来的HTTP请求,肯定是处理得越多越好,从网络的角度来说,可以用字节数/天数来进行衡量,直接体现出软件系统的性能承载能力
5)事务响应时间:服务器处理完成一个事务的所需要的平均时间(事务比如说转账操作)
发起支付操作:结算系统+会员系统+银行系统+支付宝系统,整体就构成了支付事务,只有所有的系统处理成功了,我们的支付操作才算完成,其中有一个失败了,你的支付操作也就失败了
6)平均每秒处理的事务数量:服务器平均每秒处理多少个事务,是衡量系统关键性能指标(TPS)(Transaction Per Second)
6.1)TPS是指每一秒系统能够处理的事务数量,它是衡量系统处理能力的重要指标
6.2)当我们的压力加大的时候,TPS曲线如果变化缓慢或者有平坦的趋势,那么很有可能是服务器出现瓶颈了,如果环境没有发生变化,对于同一个系统会存在一个最大事务处理能力,也并不会随着并发用户的删减而改变
咱们就拿地铁检票机来说,现在只有10台进站检票的机器,一台机器1s能进10个人
并发用户数是5,那么TPS是5
并发用户数是10,那么TPS是10
并发用户数是100,那么TPS还是10(人多了,就得排队),不是单纯的说并发用户数多了,TPS才会增长,在我们的TPS范围之内,随着用户请求增多,TPS才会增长,一旦到达我们的系统最大处理量的时候,TPS不变了
7)点击率:Hit Per Second
每一秒用户向WEB服务器发送的HTTP请求的个数,点击率越大,那么服务器的压力就越大
考时间(Think Time)
这里的点击并不是鼠标的一次点击,一次点击可能有多次HTTP请求
8)思考时间
人在第一次点击之后,看到了期望的响应结果之后,再进行下面的操作,就是一个操作和另一个操作,一个HTTP请求和另一个HTTP请求的间隔时间,是为了更加模拟用户的真是操作场景
9)资源利用率:系统在运行的时候所占用的资源的平均情况
不同系统资源的使用情况,CPU资源,内存资源,磁盘资源,网络资源,所占的CPU资源不能超过70%,所以可以通过任务资源管理器来查看各个进程的占用情况
10)软、硬件配置是否合适(容量规划/硬件选型)
七)性能测试方法介绍
一)代码级别的性能测试:
代码级别的性能测试是在单元测试阶段就对代码的时间性能和空间性能以及算法效率进行必要的测试和评估
二)基准测试:
对于一个全新的系统,需要了解这个系统的性能
就需要进行基准测试,需要获取系统的性能指标
1)作为以后性能测试的调优一个基准
2)比如说以后再次上线一个新产品的时候,就要在本次性能指标的标准上面增加10%或者更多,这样的目的就是为了让我们上线的产品,性能变得越快越好,不能拖慢老系统的性能吧
3)就是当以后系统的环境,参数发生变化之后,再进行一次相同标准下的测试,参考基准测试的结果可以看出变化对性能的影响
4)系统进行基准测试可以在较早的阶段发现问题
三)并发测试:
同一时刻向系统的服务器发送请求,看看在并发情况下系统性能的表现,看看是否会出现资源竞争竞争不合理,内存泄漏,死锁等性能问题
这里的并发测试指的是严格的并发测试,也就是所有用户在同一时刻向后端服务器发送请求
四)压力测试:
压力测试通常是指后端服务器的进行压力测试,不断的给服务器施加压力
1)也就是增加HTTP的请求数量,看看系统处理临界饱和状态下,一般是让系统的用户负载达到饱和长时间运行,服务器的各种性能指标(吞吐量,事务处理数量)是否在正常范围内,看系统是否会出现性能问题,是否可以稳定运行;
2)查看日志找到性能瓶颈
3)在不断地加压过程中,一旦系统出现拐点(从量变到质变),系统可能就会出现崩溃,揭露高负载下系统的问题,例如资源竞争、同步问题、内存泄漏等;然后逐渐较少压力,观察瘫痪的系统是否可以自愈
五)负载测试:
3.1)本质上说就是给系统定容定量,在系统上面不断增加负载,也就是用户数,观察系统能够承受的最大用户负载是多少,看看系统是否达到了需求所需要的性能指标
3.2)负载测试是在被测试系统上面不断增加压力,直到各项指标达到饱和,比如说响应时间超过了预定指标或者某种资源使用已经达到了饱和状态,从而找到系统的处理极限
负载测试和压力测试的区别:
1)负载测试和压力测试两者可以结合执行
2)负载测试,确定在各种工作下负载系统的性能,目标是检测系统负载逐渐增加的时候,系统的各项性能指标的变化情况
3)压力测试是通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能够提供的最大的服务级别的测试
六)配置测试:测试系统在不同的软硬件的配置下,系统性能的表现,找出适合系统运行的软硬件环境配置
临时内存存储空间,操作系统版本,浏览器版本,JVM版本,数据库,网络,不同的应用服务器,不同的电脑,不同的手机APP
七)可靠性测试:并发情况下,长时间运行系统,看看系统是否会出现性能问题
1)这里所说的并发情况是指系统实际并发数的60%-70%,而压力测试是超过系统的实际并发数的100% 110%,就是不断加压
2)性能问题指的是:线程死锁,资源泄露,CPU各项资源的利用率,响应时间
3)长时间运行系统,观看系统的性能指标是否稳定,有的系统在短时间运行的时候可能性能没有什么问题,指标可能达到要求,但是当运行时间变长,往往会暴露出一些问题
4)这个时候还是要看响应时间,TPS,吞吐量,点击率,资源利用率是否正常
8)大数据量测试:
8.1)独立的数据量测试:针对某些系统存储,传输,统计,查询等业务进行大数据量测试
8.2)和压力测试,负载测试,并发测试,可靠性测试相结合的综合测试方案
9)失效恢复性测试:
9.1)人为的让我们的服务器集群系统中的某些系统服务器发生崩溃,看看其他服务器集群是否能够稳定的运行,并且可以达到系统性能和功能的要求
9.2)这种测试方法用于检测如果系统局部发生故障,用户能否继续使用该系统,以及这种情况发生,用户将收到多大程度的影响
性能测试前期准备:
系统基础功能验证:
1)首先要确保当前需要进行测试的应用系统具备了进行性能测试的条件
2)确保当前进行性能测试的应用系统的版本已经稳定
3)必须保证性能测试之前至少进行了一轮系统功能覆盖性测试,况且性能测试的选取的业务功能是正常的
支持系统角色:
1)进行配置测试的时候,要进行网络带宽的一个准备,再进行模拟并发的时候,网管要协助测试工程师解决网络方面的问题
2)需要向数据库中插入大量的用户,直接让数据库工程师在数据库中进行大量用户的插入操作,这是我们在实现进行系统登陆功能的效果是一样的
3)专门的测试工程师
我们在做性能测试的时候,并不是对每一个功能都做性能测试,只是对常用的功能做性能测试,常用的功能的用户量比较多,服务器压力比较大,如果这个该功能在大量的用户访问下都没有问题,那么其他的功能也没有问题
常用的,关键性的业务,浏览功能,支付功能,添加购物车这些和新的功能
想要进行性能调优,就要找到性能瓶颈,然后再进行改进
性能测试分析与调优:
1)测试分析是需要测试分析人员具有相当程度的对软件性能,软件架构,以及各种性能测试指标的了解,还是要分析各种图标
2)这是为了可以让我们的系统性能达到一个更高的级别,或者满足我们的性能需求
3)通常是拐点分析的方法,关注性能表现上面的拐点,获得拐点附近的使用情况,定位系统的性能瓶颈