性能测试1——如何设计性能测试用例
性能测试简介
性能测试包括的范围非常广泛, 简单来说可以分为后台性能测试(Linux服务器,mysql服务器,文件服务器等等), 客户端性能测试(WEB前端,移动端等)。
一般企业的性能测试指的是狭义的后台性能测试,性能测试整个流程如下:
**1. 性能测试需求与调研
- 设计性能测试方案,并出具文档
- 审核方案,确定后准备性能测试数据,测试环境
- 按照测试方案执行性能测试
- 出具性能测试报告**
性能测试目的
测试系统相关性能能否满足业务需求。通常分一下两种情况:
1)新项目上线
2)老项目优化
如果是老项目,可考虑是否存有历史测试方案,如果有参考或许可以省事很多。
性能测试对象
测试对象可归结为“业务功能”。测试前,需要了解我们测试的业务功能有哪些,比如“购买商品”、“寄送快递”等。
有没有必要测试?
通常,可从以下几个方面考虑:
- 是否为核心功能,是否要求严格的质量
- 是否常用、高频使用的功能
- 是否为可能占用系统较多资源的功能
- 使用人数多还是少
- 在线人数多还是少
拆分对象
从业务上分,实现这个完整的功能包含哪些流程、环节
举例:购买商品
登录——搜索商品——提交订单——支付订单——退出
指标分析
分析性能需求指标是否合理
有必要测试这个需求,考虑需求指标是否合理?有没有数据支撑?
通常,支撑数据可从以下几方面考虑:
1)采样时间段内系统使用人数
2)采样时间段内系统在线人数
2)采样时间段内系统(页面)访问量
2)采样时间段内请求数
…
常用分析思路
1) 2/8法则
80% 的业务量在20%的时间里完成,业务量泛指访问量,请求数,数据量等。(也可能是1/9或其他更严格的算法)
2)正态分布
3)按比例倍增
4)响应时间2-5-8原则
一般,用户在2秒内得到响应时会感觉系统的响应很快;2-5秒内得到响应会感觉系统的响应速度还可以;5-8秒内会觉得很慢,但还是可以接受;超过8秒就会抓狂,或者认为系统已经失去响应。(这个也要根据实际情况判断,有些情况时间长点也是可以接受的,例如12306)
性能测试需要测试具备的能力:
1.常规性能测试工具的使用(Jmeter,Zabbix,Postman,jvisualvm,Monyog 等等)
2.对性能测试的各层进行测试的能力(一般指的是: OS层,应用层,DB层)
3. 设计合理的测试方案的能力(熟悉性能基准指标验证, 逐步加压原则, 混合压测稳定性验证等方法)
4. Linux等后台系统独立搭建后台测试环境的能力
性能测试方案设计的方法和思路:需求决定方案,所以首先要获取性能需求
需求一:用户数量信息
1)调查系统当前和未来使用的用户数量
系统用户数 = 本系统目前注册的用户数,注册用户数并不代表他会每天并且无时无刻的使用着。
在线用户数 = 同时在线对系统进行操作的用户数量(相当于混合场景)
并发用户数 = 同时在线并且同时操作同一个功能(单场景添加集合点)
估算未来一到五年使用此用户的数量,可以根据一些日志数据估算出来的。
2)调查系统当前和未来的每日、月活跃用户数
当前活跃用户数,即某天大概有多少用户使用本系统:那么这部分数据一说来也就是当前真正对系统构成压力的数量。
需求二:业务数据量
1)调查当前和未来背景数据量
从100条数据中查10条也许很快,但是未来数据量变成100w那你懂得…
2)调查当前和未来业务每天使用的总笔数
每个用户每天可能下多少笔单,平均需要多少次来执行这个操作?那么根据用户数,我们就可以确定每天下单的笔数。如50人,平均每人每天下10次,每次下100笔,那么总笔数就是5010100=50000笔。注意此数据根据TPS换算后,我们可以换算出系统的业务总处理量是否能达到这个数据,这也是一个很重要的指标。
3)调查当前和未来高峰时业务的总笔数
即上面所描述的特殊情况,这也是必须要考虑,并且要拿到的数据。
需求三:调查场景业务
1)系统关键、核心的业务
从系统亮点出发,以主要的业务逻辑点为第一核心:这些功能对系统或公司来说往往具有举足轻重的地位,无论怎样都必须要优先执行满足这以功能的性能测试。
2)高访问量的功能,经常承受压力的功能点
系统中表现在系统关键、核心业务前面必须要经过的地方:比如对于百度搜索来说,其核心业务是搜索功能,但是首先要面对的其高访问量对是搜索输入框加载的首页,百度首页加载即高访问量的请求。
3)业务复杂度高
往往说来业务逻辑复杂度的都具备1、2点的要素,可能其功能使用的人数较少但是对系统有很严重影响:这些功能由于其业务逻辑具有的复杂度,往往出错的可能性也比较高,所以这些功能也是必须要进行测试的。
需求四:与性能指标相关的调查
1、调查每秒事务数(TPS)
这是衡量系统处理能力的一个重要指标,同时这个指标在一定程序也关系到业务数量是否能够及时完成,所以需要获得。
估算方式一:BS类可以参考以下指标估算:Vuser*TRequest/RPS=TPS(注意1Requset的含义为Resource=0的请求)。Resource=0的含义其实就是保证此次请求能够真正到达服务器,去掉那些本地可以缓存的东西。
估算方式二:CS类可以参考每小时的业务数/3600s,这是没办法的办法。
估算方式三:API类往往要求是Vuser*1API=TPS,由于公司的API都是提供给机构用户的,所以API要求往往比较高,所以需要保证其远算得非常快。
注:BS:浏览器-服务器架构;CS:客户端-服务器架构;Vuser:虚拟用户数;TRequest:事务中的请求数;RPS:平均响应时间。
2、调查90%(或95%)响应时间
只看平均时间是不太科学的,对于我们的系统来说需要保证绝大多数的用户其响应时间都是非常快的,所以我们从90%或95%用户响应时间为指标的标准。
如果拿不到,那么我们仍可以估算:
估算方式一.BS类,按通用的标准2一5一8的标准来进行。不同业务,不同客户类型要求不同,但对于我们的产品来说绝大多数是不能超过5s
估算方式二:CS类,根据处理的数据量其时间不同,但一般说来是不能超过15s的。
估算方式三:API类,从行业的角度来说,一般要求是毫秒级(<500ms)
3、平均响应时间和TPS的波动率
这是对响应时间的补充,要求其系统响应时间应尽量稳定,TPS的波动率受测试方法和思考、间隔时间的影响。可参考以下的计算方式:
T=(TPS标准差/TPS平均值)*100%一般说来小于10%
T= (RPS标准差/RPS平均值)*100%一般说来小于10%
----小知识:测试的分类-------------------
第一类前端性能测试(客户端)
B/S:HttpWatch、FireBug、YSlow、JS内存泄漏、大数据量下的功能测试、浏览器长时间运行的稳定性测试等。
C/S:内存泄漏、CPU使用、显卡使用等:
网络性能测试:利用工具分析网络传输以及延时等,为宽带拓展做铺垫。
第二类服务器端性能测试
性能测试,是指以性能预期目标为前提,对系统不断施加压力,验证系统在资源可接受范围内,是否能达到性能预期。(即:系统是否满足预定的性能目标?)
负载测试,是指对系统不断地增加压力或增加一定压力下的持续时间,直到系统的某项或多项性能指标达到临界值,例如某种资源已经达到饱和状态等:(即,最大并发数是多少?在什么时候,响应时间不可接受”系统的服务器资源瓶颈是什么?)
稳定性测试,是指被测试系统在特定硬件、软件、网络环境条件下,给系统加载一定业务压力,使系统运行一段较长时间,以此检测系统是否稳定,一般稳定性测试时间为n*12小时。(即系统在一般压力条件下,是否可以提供连接不断的优质服务?系统在长时间最大压力条件下,是否崩溃?)
**4、测试前环境的检查收集**
环境检查包括服务器的架构以及部署方案,服务器的配置、中间件的参数配置,以及需求、功能测试报告、API调用方式等。
服务器的配置需要收集生产环境与实测试环境的服务器的配置。主要收集:
CPU:型号、核心、速度、核数、倍频、总线速度,己耗费平均CPU
内存:总物理内存、所在磁盘的虚拟内存、可用物理内存
磁盘:转速(如是旧有电脑,在执行前最好磁盘碎片整理一下)
网卡:一般是100Mb,专用网络可能在1000MB以上。
业务
跟据客户实际使用情况,划分业务比例:
某个功能在一段时间内的使用频率:每天使用此功能大概有多少次?在多长时间内会操作此功能?
如设计脚本用例为:登录>进入单表查询(70%)>通过目录导航(80%)>检索>下载(80%),根据功能的重要性,这个用例应该首先要测试单场景,并且并发数也可能比其它的功能大一些,所以需要设置集合点。
其它业务相对于使用得少一些的则可以将其与上面的用例组合成混合场景:其它场景也可以继续细分。
思考时间
观察、推测用户操作这一个过程的时间
以一个正常用户使用系统业务的角色,录制脚本随机产生,随后根据实际情况调整其值:在运行场景的时候,以50%至120%的比例随机使用思考时间
**5.持续时间**
用户操作此功能的时间段,采用二八定理,取80%的场景时间:
注意用户操作此功能时间段,如果是业务类软件,中午的时间要去掉:
**6.加载和退出方式**
一般采用缓慢登录的方式,以便观察当用户数降低时其服务器的资源情况。但登录和退出功能除外,更多的登录和退出是集中在一个时间段。
下图展示了如何将整个系统,按照用户操作业务的比例来构成一个整体的认识,通过功能的比例,我们很容易就可以得出其性能测试需求覆盖哪些功能
监控方法
由于监控采集记数器也会消耗资源,所以初次测试的时候应尽量把适合的记数器加上,而当判断某个资源出现情况时需要添加更详细的记数器,:
建议初次测试的时候监控值
CPU:ProcessorTime和PrivilegedTime和ProcessorQueueLength
Memory:AvailableMbytes和PageFaults/Sec
PhysicalDisk:DiskTime和Avg.DiskQueueLength
监控所有服务器,另外也需要监控压力机的资源。