性能测试场景设计深度解析

1、性能测试场景设计深度解析作者：张允庆，现就职于易宝付有限公司，任职级性能测试程师，有多年的系统性能测试设计与优化经验，经历过上百个项的性能优化，对性能测试有着较为深的研究。2008年底获得北京学理学学学位，前进对外经济贸易学在职研究班进深造，专业向是数据分析及应。对性能测试相关话题感兴趣的读者可以和作者进交流，电邮箱地址：。责编：陈秋歌，寻求报道或者投稿请发邮件chenqg#，或加微信：Rachel_qg。了解更多前沿技术资讯，获取深度技术章推荐，请关注。说在前提到性能测试，家想到的就是使具对应进加压，看看应能承受多少并发，TPS（Transactions Per Second）是多少，交易响

2、应时间是否在接收的范围内。不错，这些都是家最关的应的性能指标，也是每个性能测试项输出的结果。然，要实现这样的效果却并不是件简单的事情，因为性能测试是个分复杂的系统程，对测试员的能平提出了更的要求，需要性能测试员具备常全的知识与技能，能够定位应的性能瓶颈，并提出适当的优化案。通常，要对个应进性能测试需要经历需求调研、环境准备、脚本开发、数据预埋、场景设计、场景执、应监控分析、瓶颈定位、瓶颈修复、回归测试、结果整理、输出报告等多个环节。今天我们先谈谈性能测试中的场景设计。性能测试的场景设计性能测试的场景如何定义？我们可以理解为功能测试中的例，即性能测试的场景就是性能测试的例。性能测试的场景是为了要

3、实现特定的测试标对应执的压测活动。性能测试场景的设计与执是整个性能测试活动的核与灵魂，没有完整的场景设计就法达到我们的测试的，没有合理的场景设计就不会发现系统的性能缺陷。我们所开发的测试脚本，所预埋的测试数据都是为了实现特定场景所准备的。个性能测试场景包含诸多要素，图1中列出了些必备的要素，其中测试模型作为测试场景的基础与输。图1 性能测试场景的组成要素下对每个要素做个简单的说明。测试模型与测试指标在进场景设计之前我们应该先确定了本次性能测试的测试指标与测试模型。测试指标和测试模型是进场景设计的前提和基础，是场景的输。根据被测系统的类型不同，可能测试指标的类型略有不同。对于在线Web类的应，测

4、试指标般包括在线户数、最优并发户数、最并发户数、交易平均响应时间、标TPS等等。对于接调类的应测试指标般包括标TPS、平均响应时间等。测试模型就是被测试系统的各交易在线运时承受的交易数量（或请求数量）的例不是并发户的例。为什么不是并发户的例呢？因为实际的户的操作具有不确定性，使测试具很难模拟真实户的为。另外，在进运营数据分析时很难获取户的操作为，应的交易记录却很容易通过查询的式获取。应实际承受的压是户的实际操作请求，在线户如果没有进实际操作那么他最多将消耗个连接线程，应CPU并不会有什么资源消耗。100个户平均每个花费10秒下个订单和10个户每1秒钟下个订单对应带来的压是样的。所以，在场景中能

5、最少的并发户来模拟真实的请求是最经济的选择式。那么，测试模型到底该如何确定呢？通过需求调研获得。下介绍的两点是我们常的调研式：对于还未上线运营的新系统，我们般会让应的产品经理或负责给出个预估的例；但是这个预估需要我们进评估，不是随意的。对于个以提供下单交易为主的应，通常下单交易是占整个模型的较例，如果需求提出的模型是查询例较，那么我们就有理由怀疑该模型的合理性。对于这种情况，我们建议选择个常见的典型的模型来配合需求模型进场景设计。对于已上线运营的应，我们般会分析实际的交易数据来确定交易例，这样会更加精准。例如个应对户提供下单、查询、退款三个交易，我们通过DBA在线查询某的交易数据总量为2000

6、00笔，其中交易下单160000笔、查询38000笔，退款2000笔，由此我们算出各交易的例是80%、19%、1%，那么这个例就是我们的测试模型。被测交易或使的脚本测试脚本是测试场景的基础，脚本包括对应的测试数据，例如登录所需要的户名与密码、下单交易可能需要的银卡号等等。考虑到性能测试是多户并发的测试，所以需要提前准备相应的测试数据，例如个场景要对个含登录操作的交易进压测，那么我们在场景设计时就要考虑可的户名与密码数量；如，要对退款交易做测试，那么就需要提前准备好可以退款的数据，这就需要提前做好数据预埋准备。般情况下，为了便我们统计TPS，建议个脚本只包含个完整的交易，不要把多个交易放到个脚本

7、中。因为，不同的交易其响应时间会不同，响应时间较长的交易会成为“瓶颈”。另外，我们设计测试场景时需要考虑不同交易的占，如果多个交易存在同个脚本，场景的设计就法实现。上提到的“被测交易”是我们压测的对象，也是应的。当然，并不是被测应的每个交易都需要进压测，这要视具体情况定。如果被测应提供的交易常多，我们可以考虑只选取占较的交易进压测，占较低的交易可以忽略。并发户数量或并发线程数量并发户和并发线程其实是同个概念，只是在不同的性能测试具中其叫法不同已。在下中我们统称“并发户”。当然，这些户是虚拟户，是压测试具使进程或线程来模拟真实户请求的种式。并发户是每个场景提供不同压的直接来源，场景不同其需要的并

8、发户数量可能会不同。那么是什么因素决定个场景要并发户的多少呢？主要是被测交易的响应时间和场景的标TPS。交易响应时间的快慢是决定并发户数量的主要因素，例如个应的某个交易响应时间是50ms，如果要实现100TPS的标，那么只需5个并发户即可达到（标TPS*交易平均响应时间=并发户量）。如果响应时间是100ms，那么实现同样的TPS需要的并发户就会多倍。加压策略加压策略就是并发户以什么样的“步调”开始对应发起请求。常的并发策略有同时加载、指定间隔时间的加载，梯度加载等式。加压策略的不同主要是模拟产环境不同的情况，下分别做简单介绍。同时加载式是指所有并发户在场景启动时同时发起交易请求不包含任何等待，

9、这样会对被测应带来突然的压，于考察应在突然加压下的表现是否符合预期。般有户突增的业务特点的应会设计这样的场景，例如，某些抢购系统、铁路售票系统的按时放票功能等。当然，对于那些并发户较少的场景也可以采这种户加载式。对于有些应如果同时加载量的并发户可能会出现异常或超时，导致部分并发户失败。指定间隔时间的加载式是我们最常的，这是为了模拟产的实际情况，般产系统接收户请求都是逐渐增加的，到当交易的峰时段达到最。在场景设计时，根据并发户的多少可以设置适当的增加频率，般是“多长时间增加多少户”。例如，每秒钟增加个户、每两秒增加5个户等等。梯度加压策略也是我们常的种户加载式，但是这种式严格来说应该是种梯度加压

10、场景。该场景般是预先设置个并发户的梯度，每个梯度执分钟，这样就可以通过个场景的执基本上找到应的最TPS。在下场景类型中，我们会详细介绍这种场景。运时间每个类型的场景其执时间是不同的。表1为家提供个参考值。运时间是不包含户的加载时间和退出时间的，即全部户都在执的这段时间。表1 各种典型场景运时间设置延时式延时是上笔请求完成到下笔请求发起之间的时间间隔。延时在场景中的作就是为了精准控制TPS，或者降低当前并发户数量下的压。精准控制TPS的的就是考察应在特定压下是否存在性能问题。在某些性能测试具中提供了三种延时设置式：第种是上次请求完成后即发起下次请求，也就是延时为0。第种是上次请求完成后间隔指定的

11、时间后再发起下次请求。第三种是在指定时间内完成次请求，即区间型的延时，这要求我们设置的这个时间要于交易的响应时间，也就是说要保证交易响应时间在我设置的这个时间的区间内，否则就不能实现精准控制TPS的标。在这个区间内，交易响应时间论如何变化，只要不突破我的这个最区间，那么TPS就是平稳的。在实际的场景设置中，为了实现精准的TPS控制标，我们选第三种设置式。通过不断地尝试与调整，最终能够达到标TPS。户终式和户加载式对应，户终式是场景执完成后的户退出式。般使的是“同时退出”和“每隔多少时间退出个户”这种式。这我们重点介绍下“同时退出”这种式。应在持续段时间的压后如果突然压全部释放了，那么这时的应在

12、理想情况下应该是怎样的？CPU资源应该从繁忙即变为空闲，络传输也幅降低，磁盘IO降为0等等。不然，那就是有某种问题的存在了。这时候就需要分析导致资源不能释放的原因。各种资源的监控式资源的监控式也是我们场景设计时必须考虑的个必要因素，在场景设计时就应该确定每个场景的资源监控策略。这些策略包括监控的对象、使的监控具或法、监控数据采集频率等。监控对象般是测试环境中所有操作系统资源使（CPU、内存、磁盘IO、络吞吐等）、数据库（TOP SQL、数据库锁等待与死锁、缓冲区命中率等）、JVM的运情况（堆内存垃圾回收、线程状态、数据库连接池使情况等）等。监控数据采集频率也会因场景执的时间长度不同进适当调整，

13、例如混合容量场景如果执30分钟，那么采集频率可以为每5秒钟采集次，共采集360次。但是，考虑到监控要提前启动，所以采集次数可以适当增加些，这样可以确保整个监控区间于场景执区间，也就同时监控到了资源使在压发起前后的变化情况。对于执时间较长的场景，我们就要适当调整采集间隔和采集次数，例如对于个执12时的稳定性场景，我们可以每50秒采集次，共采集1000次。常见的场景类型单交易基准般使个户或个线程，延时设置为0，对个交易持续运10分钟以上。该场景的主要的是获取单个交易在压的情况下的基准响应时间及环境资源使情况，作为其他场景的参考依据。单交易负载单交易负载的场景是为了找到单个交易的最优TPS，检测单交

14、易在并发情况下是否存在性能瓶颈。这个最优是以什么为衡量标准呢？通常以应或数据库等系统的CPU使率不于70%为标准。为什么是70%？不能更了吗？通常在产上运的应，如果CPU使率长期处于平那是常严重的问题，应的节点随时都可能挂掉。对于产环境各种资源的使情况，通常运维部门都会有实时的监控，般当摸个节点的CPU使率超过50%时就会触发报警，如果长时间处于负载状态，那么说明应节点可资源不，就应该考虑进节点扩充了。当然，也并不是什么情况下都需要找到单交易的最优TPS，这要分情况来对待。对于被测应提供的交易较少的话，可以通过不断测试找到每个交易的最优TPS。但是，有的应提供的交易较多，这时如果每个交易的最优

15、TPS都要找到，那就会需要较多的时间来进测试。单交易负载的场景具体该如何设计与执呢？如果你想找出每个交易的最优TPS，可以从5个并发户开始，执分钟后再增加5个户，直到应CPU使率超过70%为。场景的延时设置为0，场景执前需开启相关监控。该场景于获取单交易在并发情况下的响应时间与TPS，发现交易本是否存在并发问题，应是否会出现错误和异常，响应时间相对单交易基准是否有明显的提，资源使率是否在合理的承受范围之内等等。如果应存在性能缺陷该场景即可发现。当然，如果你不想测试出每个交易的最优TPS，那么单独对每个交易做次5个并发的负载测试即可。多交易混合负载多交易混合负载的的是为了找到应的最优TPS，即应

16、CPU资源消耗在70%左右时的TPS（此时需确保数据库等其他被调资源不成为瓶颈）。按照测试模型中的交易例及标TPS，对每个交易分配不同的并发户数量，设置不同的延时，同时进加压，通过多个场景的不断尝试最终测试出应能够达到的最优TPS。这个场景较复杂，般需要经过多次的测试与调整才能到达测试模型的例要求。经过单交易负载测试之后我们已经获取了每个交易的平均响应时间，那么由此值我们便可以设置我们的混合负载场景。假设，我们应的测试指标TPS为100，单交易负载测试获取的各交易响应时间如下：下单0.4秒，查询0.2秒，退款0.5秒，那么要达到100TPS的压，该如何设置场景？计算每个交易的TPS下单TPS=

17、100*80%=80，查询TPS=100*19%=19，退款TPS=100*1%=1确定每个交易的并发户标TPS、响应时间、并发户之间有这样个关系：标TPS=并发户/响应时间如果个交易响应时间是0.2秒，那个户时的TPS就是1/0.2=5。在咱们这个实例中每个交易的并发户计算如下：下单交易并发户数量=80*0.4=32查询交易并发户数量=19*0.2=3.8退款交易并发户数量=1*0.5=0.5家看到了，这出现了整数的情况，怎么办？对于这种情况我们要进整数化处理。即我们般取于并最接近当前数的整数，3.8我们按4，0.5我们按1。整数化后对应的响应时间也应该发变化，否则就法实现标TPS。整数化再

18、次计算实际的响应时间：查询交易调整后的响应时间=4/19=0.21退款交易调整后的响应时间=1/1=1于是场景设置如下，下单交易并发户32个延时设置为0秒，查询交易并发户4个延时设置0.01秒，退款交易并发户1个延时设置0.5秒，场景运时间10分钟以上。但是这个场景运结果可能并不会完全符合我们的预期，因为并发户相单交易负载场景已经增加了很多，交易的响应时间很可能会出现明显的延长。如下单交易的实际响应时间可能会延长到0.6秒，那么实际的TPS将明显下降。如果出现这种情况该如何处理呢？我们推荐使区间型延时设置，将这个“区间时间”设置的实际交易响应时间些，根据这个时间再计算对应的并发户量。另外，建议

19、家建个excel的表格，于计算延时和并发户的值，效果见下表2。表2 场景设置具表表2中的列“延时设置”的值是使公式动计算出来的，公式为“=并发户单元格编号/（标TPS单元格编号*交易占单元格编号）”。建这个表之后我们只需动修改两个列的值就可以便地计算出每个场景下的每个交易的延时，这两个列就是“平均响应时间”和“并发户数”。平均响应时间随着并发户的增加必然会相应地增长，所以在表2中每个场景的平均响应时间数据都是上个场景的执结果。这样我们每执完成个场景，然后就把响应时间的数据填写到下个场景中，然后再修改并发户数量，并确保延时设置于平均响应时间即可，如果在测试执过程中出现平均响应时间于延时设置时间时

20、需要停场景重新计算。综上所述，多交易混合负载场景并不是个场景，是系列混合场景的集合。还以上例来说，标100TPS时我们分析监控结果发现系统各项资源利率都不是太，这说明应还能够承受更的压。这就需要我们继续加压进测试。我们可能的场景是150TPS、200TPS等等。那么如何确定我们的压梯度呢？这就要看系统资源到底使了多少，如果100TPS时发现系统各项资源使率在50%左右，我们就可以估计应的最优TPS应该能够达到150，那么我们下个场景就是要按150TPS的标压去发压，相关的并发户和延时根据上表进调整即可。如果不能实现150TPS的压，那么我们就要减少标TPS再进发压，直到测试获取到应的最优TPS

21、。多交易混合容量容量的意思就是应能够达到的最TPS。该场景是和多交易混合负载场景相关联的，即通过多交易混合负载找出应承受的最优TPS后继续对应进加压，直到找到应的最TPS。混合容量场景的并发户与延时调节式和混合负载样，在这就不再赘述了。并发该类场景的的是考察系统在并发的情况下是否存在问题，是否有报错，是否有户失败等。并发般要设置个延时，于到达最优并发时的TPS。那么，并发时的户到底设置多少，这个延时要设置多久，依据是什么呢？般我们设置的并发户数量是最优并发的510倍，延时要通过计算得到。这还是举例说明，有个应，测试得到的最TPS为200，对应的并发户为20，那么我们可以设置两个并发场景，即10

22、0并发户和200并发户。100并发时的延时设置为100/200TPS=0.5秒，200并发时的延时设置为200/200TPS=1秒，这个延时为区间型的延时。通常，在进并发测试时获得的TPS结果要最TPS低很多，因为在并发时系统很有可能出现某些资源不够，线程很可能会出现严重的阻塞等等。如何考量并发测试获得的测试结果是否符合预期，或者说并发测试通过的标准是什么？这个也没有固定的标准可循，通常我们认为只要符合如下两的要求即可认为测试通过。最并发户量是否能达到最TPS时的5倍；测试结果的TPS是否达到测试指标的要求；需要说明的是这的并发和应的最优并发与最并发并不是回事，者并不相同。稳定性给应个恒定的压

23、，使场景运较长的时间，于测试应在长时间运下的表现，TPS是否有较波动、是否有错误和异常、是否存在内存溢出等。根据业务类型不同般会运不同的时长，对于5*8这样的应稳定性运8时即可，7*24这样的应最好能够运12时以上。恒定的压怎么选取？通常有两种式。第种，选择应最优压的80%最为标压，这种式较适合应的最优TPS不是很的应，如200以下；第种，如果应的TPS较，那么我们需要换种式，否则就会产较多的测试数据。例如个应的最优TPS为1000笔/秒，如果我们取其80%的压800笔/秒，那么加压12时的数据量为3456万！这时，我们使200TPS的恒定压运12时即可。扩展性考察应的扩展能。未扩展的情况下基

24、本是个系统使个单独的机器节点，也就是应的单点情况。扩展性就是，再对应进个节点的扩展，测试扩展情况下的TPS。般双节点的总TPS达到单节点的1.8倍即认为系统具有良好的扩展性。压测时我们选取混合容量场景中获取到应最TPS时的场景做为压测场景，并使不同的压机分别对两个节点进加压，考察测试结果能够达到多少TPS。可靠性或异常测试这种情况下般是将压做为背景，对应所依赖的环境进模拟故障，考察应的表现是否符合预期。例如，在定压背景下，模拟络的闪断，待络恢复后应TPS是否能够及时恢复。背景压我们般选取混合负载测试获取最优TPS时的场景即可。影响性影响性测试也是性能测试过程中经常遇到类场景。这种场景般是针对提

25、供实时功能的应所设计的。例如，有批处理或异步处理的应。严格来说，这不应该算是个单独场景类型，应该是种特定的测试类型。对于这类的测试我们般分两步来执，先是在未启具有影响性的功能时测试出应的最优和最TPS；其次，启动具有影响性的功能，再按第步的场景（场景的设置均不变）进测试，对者的TPS差别，这个差别就是我们要考察的影响性。挡板延时对如果压测环境使了挡板，可以通过挡板来设置不同的延时进对测试。如延时设置为0.5秒，1秒，甚2秒。根据不同的延时设置，增加相应的并发户数量，调整场景的各项设置，考察应是否能够达到最TPS,是否出现并发户失败或应异常等。对于挡板延时，般的作是模拟被调的系统的延迟，考察被测应在不同的延时情况下的性能表现。现在的应系统很少有是完全独的了，或多或少地都需要调别的系统来实现某些操作或业务。例如，对于个付系统，起码需要调银通道、银