您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 性能测试 > 正文

如何规划和设计有效的系统性能测试场景 | 内含50多个知识点

发表于:2018-07-19 作者:杨建旭 来源:软件测试培训

一个性能测试案例的执行成本远高于功能测试,那么如何设计性能测试场景,以最少的案例拿出能够说明问题的结论,是所有关注性能问题的工程师的重要目标,同时也是一门工匠的艺术。

笔者总结了社区线上交流活动“如何规划和设计高质量的系统性能测试场景”的50余个问题,将之分门别类的汇总、归纳、浓缩,将50余个方方面面的知识点在最短的篇幅中展现给大家。浓缩之后的章节如下:

1.性能测试策略的设计
2.性能测试场景的设计
3.性能测试环境的设计
4.性能测试工具的选取和设计

(一)性能测试策略的设计
 
如何制定性能测试策略?
性能测试策略需要考虑以下方面

1、业务测试范围

哪些测,哪些不测。比如什么业务测、什么操作系统版本、中间件版本测。

2、制定优先级规则

由于测试场景、测试案例是没办法穷举的,理论上测试是永远不可能结束的。并且,性能测试本身又牵涉出容量测试、扩展性测试、高可用测试、压力下的异常测试等等的测试延伸,因此在给定的时间条件下,必须制定性能测试的优先级规则,根据优先级规则划定测试范围。性能测试的进展受制于功能验证的完成、环境准备的完成、相关工具的开发、性能问题的定位和调优等,当性能测试的计划需要变更时,可以按照优先级规则重新选择测试范围。

3、基本的测试方法

例如:

a)如何产生业务压力

b)如何产生用户并发

c)如何构造场景使应用系统的逻辑处理算法达到生产的计算量级

d)如何制造外围环境对被测目标的响应

4、测试环境设计

设计测试环境的拓扑结构和资源配置,因为测试环境的拓扑、资源不一定和生产环境相同。

需要想清楚为什么这么设计,也就是说在这样的环境下(可能是精简的环境)可以得出可信度高的性能测试结论。

5、概要测试计划

6、依赖条件

7、风险

等等

其中前4条基本决定了项目的工作量。更直接的说,前2条决定了测试人员可以晚上几点回家。

“测测看”是不是一个有效的测试方法?



性能测试的成本是非常高的,“测测看”往往浪费严重。性能测试必须对测试场景有提前的规划,而这个规划的前提是对被测系统、产品有充分的了解。业务上面那些交易吞吐量大,从技术上讲哪些服务器、哪些模块容易出现性能瓶颈,甚至对操作系统、中间件、应用软件的参数都要提前规划好。不然测了很多案例,发现参数不合理,测试结论完全作废。当然,有时我们并不能很准确的设计每个参数,但至少要有一个计划,我对那个参数进行调参的测试,以期测出最优的性能表现。

然而,“测测看”有它的可取之处,因为真正的性能表现只有测试之后才会知道,笔者比较倾向的一种方式是,“提前规划场景,每个场景跑完之后分析结果,然后决定下一场跑不跑、跑什么、参数怎么设”。

如何模拟和感知关联系统的压力?



1)如何模拟核心系统的正常压力

不确定你问的是哪一方面,就我的理解先回答一部分

一个交易或者请求的链路可以很长,那么,可以从这条链路中任意一个节点,采用某种压力工具进行施加压力。比如:

a)可以模拟end user的页面操作,用Loadrunner、JMeter等性能测试工具录制用户的页面操作,采用并发用户回放,模拟用户。

b)可以模拟应用服务器直接给数据库服务器施加压力,采用性能测试工具,建立与数据库的连接,直接把批量的sql语句扔过去

c)可以直接采用数据库录制回放,把生产上录制的数据库sql在测试环境的数据库回放。

发起压力的机器离核心系统越近,越容易控制

2)如何感知在测试系统接入后对核心系统的压力影响

这个由监控来做。平常不测试的时候,核心系统有多少TPS,多少CPU占用、内存占用,多少任务数,多少网络带宽占用、磁盘IO、业务响应时间是多少。测试的时候,这些指标增加了多少,这个感知工作由监控来做。

去掉前端系统,直接压测后端,和真实情况有差异吗?



如果模拟的逼真,是没有任何差异的。那么问题来了,什么是模拟的不逼真?

举例1)生产环境某系统每秒处理100个事务,你如果采用性能测试工具,1个用户每秒发100个请求,可以模拟出系统每秒处理100个事务。但是,假如生产环境中这100个事务是由100个用户发起的,那么此时就有些差异了。首先,网络通道的连接数可能不一样,用户登录次数可能不一样,session的打开数量,数据库连接数,数据库启动的服务进程数等等都有可能不一样。

举例2)生产环境中每分钟处理60个业务,这60个业务是匀速达到的。而你如果在性能测试的时候,在第一秒钟把60笔业务都发出去了,后面59秒闲着。那么这个模拟也是非常不逼真的。

一场性能测试跑多长时间合适?



很多人一跑性能场景就跑1个小时以上,其实跑多久完全取决于系统特点。有些系统在大压力面前,几秒钟就可以调整到位,后面只要压力稳定,它的资源利用率、响应时间都是稳定的;对于这种系统,个人认为测10分钟足以。结果取下来,把前面几秒钟、后面几秒钟去掉,就可以采集数据了。

而对于数据库业务较复杂的场景,可能头10分钟的性能表现和后10分钟完全不一样。这种情况下,测试多久、数据取哪一段、要不要先给系统预热然后再正式测试都是要具体分析的。

白天执行性能测试还是晚上执行?




很多企业选择在晚上做性能测试是因为环境只有1套,白天有大量的功能测试人员趴在上,环境被改来改去,根本执行不了性能测试。只有晚上才空出来给性能测试那几个人用。

然而,抛开环境共用的因素,从结果准确性的角度,我还是比较推荐在晚上测,因为,测试环境资源是公用的,即使性能和功能测试是分别的两套环境,业务上互不影响,但底层资源是互相影响的(网络资源、计算资源、存储资源)。从实际经验来说,晚上测出来的结果和白天的结果的确不太一样。

再然而,我更推荐白天测。因为人是要睡觉的。有时候我们设置了定时任务,让测试晚上自动执行,但这样就不能及时获取性能结果并及时分析,不能及时调整下一场测试的内容。导致很多无效的测试。

(二)性能测试场景的设计

什么是性能测试模型?



 

性能测试模型大概来说就是把哪些交易放到一起测试,各个交易的交易占比是多少。性能测试模型是从生产业务模型转化而来的,按照性能测试模型来设计测试场景,可以保证测试模拟更贴近生产实际的交易场景。一般都有这些模型:像正常交易日业务模型、峰值交易日业务模型、特殊交易日业务模型等。

银行核心业务系统的测试场景需要考虑哪些?



银行类的系统,主要考虑联机交易和批量交易测试场景,联机交易场景:已上线的业务系统,需要先调研生产最近一段时间业务量分布情况,找出在什么时间点系统交易量出现峰值,然后在深入分析峰值时间点有哪些交易,交易的占比,峰值持续时间等,形成测试模型;未上线的系统,在没有明确的性能指标的情况或可参看的历史数据情况下,可做探索性测试,找出系统在什么时间、什么地点出现拐点和瓶颈,然后进行分析和调优。批量交易场景:主要考虑批次时间窗口要求,同时还要关注批次叠加联机交易的性能情况。

测试用例如何设计比较合适?




对于性能测试来说,主要是

1)测到点子上,即把最有可能出现瓶颈的地方测出来

2)在1)的前提下,尽量少侧

缩小测试范围(只测某些业务、只测某个操作系统版本、只测某个中间件版本)。

同一个场景下,减少案例个数。负载测试,能测3场 就不测5场。

减少测试环境准备的成本,集中精力测试核心系统,或者由瓶颈的系统。其他系统都扔开。

基准->单交易负载->混合负载的弊端



教科书式的方法、八股文式的思路,不能适应具体的测试,因为或许很多的测试场景是在浪费时间。笔者更倾向于根据系统的业务特点、技术特点选择少数几个性能案例执行。

比如说,一共有10个交易,但生产环境98%的交易都是A,那么单交易负载只测试A,混合负载甚至可以不测。

再比如说,10个交易中,仅有交易B对数据库的增删改查压力较大,而其他交易交易没有太重的数据库访问,那么只测交易B。

新建系统没有任何过往数据的情况下如何建立性能测试模型?



由于新业务项目可能没有明确的需求,也没有生产上的历史数据或者类似项目数据可以分析。新业务的性能测试可采用探索性测试。探索性测试的目的在于给出该系统的总体性能表现、系统将在何时何处出现性能瓶颈、并分析、定位问题,给出调优建议。

简单来说,我不知道生产峰值TPS是多少,但我要知道自己系统在某个条件下的最大承载能力是多少,并且要分析出瓶颈在哪里,如果要扩容知道怎么扩。

对于不同的测试对象(测试功能点或测试模块),需分为不同的维度进行测试,并说明选择这个分析维度的原因。测试的维度需要按照测试的优先级排列。测试维度举例:交易量的变化、用户并发数的变化、交易配比的变化、数据文件大小的变化、软件参数配置的变化、硬件参数配置的变化、存量数据的变化等等。每一类维度测试完成后,需选出最典型的值,在此基础上进行下一维度测试。这么做的目的是为了减少测试分支。

举例说明:

某系统中,某个模块的并发查询是性能关注点,可依据对查询影响较大的几个因素按优先级进行排序:不同的查询条件,不同的并发用户数、不同的存量数据。

1、不同的查询条件,开发程序内部的处理不同,性能表现也不同,作为第一个测试维度,需尽可能分析程序内在实现方式,划定测试范围,测试后挑选更加典型的查询条件,为后续测试尽量缩小查询条件的范围。

2、在维度一选定的典型查询条件基础上,选取不同的并发数进行测试。涵盖需求中要求的并发数。验证并发数是否满足需求,预测并发数多大时会达到性能瓶颈。并选择合适的并发数作为后续测试的并发参数。

3、在维度一、维度二选定的参数基础上,进行不同存量数据的比对。

设计哪些异常的测试场景?



性能场景设计中,异常场景主要有:

1)系统的异常:在业务压力的情况下进行高可用切换(比如一个进程挂了、一台服务器挂了、一个站点挂了、一个光纤卡挂了、一台存储挂了),存储空间满了等等。

2)用户犯的错误:选取生产系统容易发生错误的业务,这类业务由于是错误的,所以应用的处理路径、消耗的资源 和正常情况下是不一样的。

二八原则在很多情况下不适用



我目前接触的生产环境,没见过二八现象。因为现在的交易已经不太分时间段了,白天晚上都有不少交易。以银行的业务A为例,如果一天开门8小时,其中峰值的小时吞吐量 乘以5可以得到全天业务量。以银行的业务B为例,如果一天开门24小时,其中峰值的小时吞吐量 乘以10可以得到全天业务量。

如何计算性能场景里面的vu、Pacing



1)首先要指定TPS的目标

比如说咱们打算发到被测服务器的TPS=100,即每秒要100个请求。

2)根据TPS计算用户数和间隔。

如果设置10个虚拟用户,那么每个用户每秒发10个请求。 那么每个用户每隔100ms要发出来一个请求(1000ms/10=100)。

这100ms包含了2个时间(1)发送请求的时间,(2)停顿时间,即上一次发送结束到这一次发送开始,中间的停顿。

3)实测调整

如果“发送请求的时间” 本身就要90ms(这个是需要实测出来的),那么你的停顿时间 应该是10ms,但10ms计算机是不可能稳定控制的,因为进程调度、CPU调度的原因。最后导致发出来的TPS并不稳定。因此第一次测试,可能设置的不合理,没关系,根据实测值,第二次测试就可以设置合理了。我们接着计算

因为刚才的停顿时间10ms太短,咱们至少要有30ms的停顿时间。那么一个请求整体时间就是90+30=120ms。

这个情况下,一个vu(虚拟用户)一秒钟可以发出来多少笔请求呢?

1000ms/120ms= 8.33笔。那么你要一秒发出来100个请求,需要多少vu呢?100/8.33=12个vu。 一台压力机放12个vu能不能跑出来想要的结果呢? 也不一定,因为这12个vu可能把压力机给压垮了。如果一台压力机不够,可以多加几个压力,共同跑12个vu。

(三)性能测试环境的设计

测试环境有限的情况下测出接近生产的性能表现






企业里的测试环境大部分都不如生产环境。在测试环境有限的情况下,有什么好的策略可以在有限资源下测出接近生产的性能表现?

1) 将集群环境改为单台服务器,将有限的资源集中供应某一台服务器。

这样,可以测试单台设备的最大吞吐量。如果集群环境中各个服务器之间没有资源共享、资源征用的话,单台设备的最大吞吐量 * 设备数量 就是整个系统能够达到的最大吞吐量。当然,现实中没有这么理想,往往存在网络共用、存储共用,这就要深入分析这些共享因素对性能的影响了。甚至有些集群还有锁机制,比如OracleRAC,IBMCF,这些有锁机制的集群不太适合单台的测试。

2) 去掉中间环节的服务器,直接压测核心系统。

例如,一个客户请求过来之后,经过F5、Web服务器、应用服务器、数据库这几个系统,而根据经验判断,前面几个系统都不是性能瓶颈。那么,可以把前面的系统摘掉,采用性能测试工具直接压测数据库服务器。

再比如,业务系统的签名通过签名服务器来完成,但我们想知道签名服务器的最大吞吐量,那么,去掉业务系统,直接压测签名服务器。

在生产环境下做性能测试是否可行?



很多互联网公司和部分中小银行是采用生产环境做性能测试的,或是是共享了部分生产环境(例如网络、存储)做性能测试。

他们的特点是,“没有办法只能选择生产环境做性能测试,并且出了问题也压力不大”。

互联网应用由于系统庞大,没有那么大的测试环境来使用,并且,出了问题又能怎样,反正是半夜测试的,一共也没几个用户受影响,受影响又有什么了不起,反正用户是免费用的,过一会儿就好了,对不住啦。

一些中小银行也存在测试环境不足、出了问题也没几个人受影响的情况。

所以,在生产环境下做性能测试对于一些企业是可行的,但对于另一些则不行。比如,人民银行的测试,总不能真刀真枪的测吧,出了问题,所有银行业金融机构都受影响。银行系统出了故障和互联网公司的故障,民众的容忍度是不一样的。

老旧的测试环境如何测试出合理的结果



这个问题其实是两个问题

1)设备型号和生产一致,但资源配置少

2)设备老旧

咱们分别来看

1)设备型号和生产一致,但资源配置少

1.1) 将集群环境改为单台服务器,将有限的资源集中供应某一台服务器

1.2) 去掉中间环节的服务器,直接压测核心系统,或者直接压测你认为是瓶颈的系统。

2)设备老旧

设备也分为好多类型,他们采用的技术、协议也不一定相同。我们假设技术、协议是差不多的,只是型号老。

对于CPU资源)可以对比测试设备和生产设备的TPCC/tpmC的值

对于内存资源)速度上新老设备是有差异,但往往影响不到太大的量级

对于存储资源)如果能力相差很大,这个没什么好办法。或者可以把内存当做磁盘,ramdisk。把存储的影响降到最低。

局域网内如何模拟广域网环境?



如何在测试环境模拟互联网公网环境,或者模拟有带宽限制(如100M/s)?

有一种设备叫网络损伤仪,用来模拟带宽大小,延时是多少毫秒,丢包率等等。

不过网络损伤仪也不是模拟的特别好,有时候网络损伤仪变成了网络瓶颈,并没有想象中那么完美。

用内网还是外网测呢?



问:测试环境是用内网还是外网呢?如果用内网,到时候如果是服务器端网络带宽问题是否无法发现,用外网测试的话如果是压力机网络带宽问题岂不是又要加带宽?

答:如果贵司的业务是对外提供服务的,外网测比较真实,不仅仅是网络带宽问题是否能被发现,还可以发现因为网络延时导致的一些问题。

带宽占用这个事,其实是可以算出来的,小压力的跑一会,用TPS和服务器的网络带宽占用 就可以推算出来当生产压力达到XX时,对应的服务器带宽占用。

广域网网络延时(比如30ms),如果你的交易要好多个来回交互,可能就会出现性能问题,有些代码是有超时机制,超时就报错了。

当然,如果单位的外网带宽固定,也不是说加就加,那就在局域网测吧。但如果单位有钱,可以买个网络损伤仪,模拟广域网的带宽延时。

虚拟化环境中得出的测试结论是否可信


 

只要虚拟化的参数设置得当,测试结论是可信的。

比如说生产环境这个系统是10个CPU,那么虚拟化环境也给足10个CPU即可

比如:设置dedicated CPU,或者EC=VP=10。

当然,还有网络、磁盘、内存等其他资源也同样要设置得当。

虚拟化资源和物理资源有没有对应关系?



内存一般都是物理的,实实在在的。也有的hypervisor把磁盘给OS,让OS误以为是内存,但一般没这么搞的。

CPU的话你要看你是什么虚拟化平台了,但都可以设置最低保障(标称计算能力)

1)x86的CPU 可以设置保障的Hz值。x86平台在虚拟CPU的分配和控制上的确不是很精细。

2)Power的CPU,可以设置EC(entitled capacity),一个EC约等于一个core。但此时VP的值要设置合理(如果过大,也会和实际情况偏差很大),可以设置EC=VP 这样就和实际情况很接近了。

或者,如果你对CPU机制了解比较多的话,也可以去计算。任何虚拟化平台的VP 都是一个线程,一个线程最多占用一个逻辑CPU(也就是一个CPU超线程,或者一个CPU SMT)。你可以把虚拟机CPU跑的很饱和,这时,你就能算出来,占了多少逻辑CPU,再根据CPU型号,推算占了多少个CPU core.

(四)性能测试工具的选取和设计

 

有哪些好的性能测试工具可用?

1) 测试工具常用的有:

Loadrunner:需license,但不少人是试用性质。功能、易用性方便最优秀,是性能工具的标杆

2) JMeter:无license,免费,是免费工具里面的标杆。易用性差一点。

3) 当然然还有很多其他工具,各有特色。还有些是专门测磁盘IO、网络IO的小程序。

用于模拟系统读写负载的测试工具?



在做主机及存储系统等综合测试(含高可用、性能)时,常会碰到无法一开始就带应用测试,但又需要模拟真实应用的读写场景。有哪些比较简单又实用的测试工具,用于模拟系统的读写及计算负载?

磁盘IO的压测工具:

例如orion、iometer,dd命令、xdd、iorate,iozone,postmark

不同的工具支持的操作系统平台有所差异,各具特色。

有的工具可以模拟应用场景,比如orion是oracle出品,模拟Oracle数据库IO负载(采用与Oracle相同的IO软件栈)。即模拟oracle应用对文件或磁盘分区进行读写(可指定读写比例、io size,顺序or随机)这里就需要提前知道自己的IO模型。如果不知道,可以采用自动模式,让orion自动的跑一遍,可以得出不同进程的并发读写下,最高的IOPS、MBPS,以及对应的响应时间。

比对dd,仅仅是对文件进行读写,没有模拟应用、业务、场景的效果。

postmark可以实现文件读写、创建、删除这样的操作。适合小文件应用场景的测试。

性能指标采集工具



由于性能指标包含很多方面

1)系统资源的指标(CPU、内存、网络IO、磁盘IO)

2)服务指标(响应时间、吞吐量)

3)业务指标(业务量、并发用户数、业务类型)

因此没有一个现成的工具可以抓取所有指标,原因是,一些指标是和业务、应用关联,需要用户自己定制。比如某个业务的响应时间,需要从日志采集,那就需要自己定制日志采集和统计的工具。

当然,这些工具也可以集成在一起

N台压力机没有跑出来N倍的效果

1)检查你发送压力的代码,有没有lock。具体来说,举个例子,所有的交易要有全局唯一的交易编号。如果所有的压力机上的交易标号是由一台机器产生的,这台机器产生编号的速度就是整个压力机集群的瓶颈。

2)检查是否有资源共用。比如所有压力机都是虚拟机,共用存储、CPU等等。比如所有压力机去某个数据库读数据。这个可以看压力机的资源利用情况、响应时间就可以看出来

3)可能是被测系统已经到瓶颈了,压力机能力再强,请求也发不出去了。