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

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

笔者总结了社区线上交流活动“如何规划和设计高质量的系统性能测试场景”的50余个问题，将之分门别类的汇总、归纳、浓缩，将50余个方方面面的知识点在最短的篇幅中展现给大家。浓缩之后的章节如下：文章源自玩技e族-https://www.playezu.com/191461.html

1、业务测试范围文章源自玩技e族-https://www.playezu.com/191461.html

哪些测，哪些不测。比如什么业务测、什么操作系统版本、中间件版本测。文章源自玩技e族-https://www.playezu.com/191461.html

2、制定优先级规则文章源自玩技e族-https://www.playezu.com/191461.html

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

3、基本的测试方法文章源自玩技e族-https://www.playezu.com/191461.html

例如：文章源自玩技e族-https://www.playezu.com/191461.html

a）如何产生业务压力文章源自玩技e族-https://www.playezu.com/191461.html

b）如何产生用户并发文章源自玩技e族-https://www.playezu.com/191461.html

c）如何构造场景使应用系统的逻辑处理算法达到生产的计算量级文章源自玩技e族-https://www.playezu.com/191461.html

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）可能是被测系统已经到瓶颈了，压力机能力再强，请求也发不出去了。