如何规划和设计有效的系统性能测试场景？

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

本文根据社区线上交流活动内容，进行汇总、概括、浓缩，将50余个方方面面的知识点在最短的篇幅中展示给你们。包括以下内容：

1.性能测试策略的设计

2.性能测试场景的设计

3.性能测试环境的设计

4.性能测试工具的选取和设计

1、性能测试策略的设计

（一）如何制定性能测试策略？
性能测试策略须要考虑如下方面

一、业务测试范围

哪些测，哪些不测。好比什么业务测、什么操做系统版本、中间件版本测。

二、制定优先级规则

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

三、基本的测试方法

例如：

a）如何产生业务压力

b）如何产生用户并发

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

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

四、测试环境设计

设计测试环境的拓扑结构和资源配置，由于测试环境的拓扑、资源不必定和生产环境相同。

须要想清楚为何这么设计，也就是说在这样的环境下（多是精简的环境）能够得出可信度高的性能测试结论。

五、概要测试计划

六、依赖条件

七、风险

等等

其中前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套，白天有大量的功能测试人员趴在上，环境被改来改去，根本执行不了性能测试。只有晚上才空出来给性能测试那几我的用。

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

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

2、性能测试场景的设计

（一）是性能测试模型？
性能测试模型大概来讲就是把哪些交易放到一块儿测试，各个交易的交易占比是多少。性能测试模型是从生产业务模型转化而来的，按照性能测试模型来设计测试场景，能够保证测试模拟更贴近生产实际的交易场景。通常都有这些模型：像正常交易日业务模型、峰值交易日业务模型、特殊交易日业务模型等。

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

（三）测试用例如何设计比较合适？
对于性能测试来讲，主要是

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

2）在1)的前提下，尽可能少侧

缩小测试范围（只测某些业务、只测某个操做系统版本、只测某个中间件版本）。

同一个场景下，减小案例个数。负载测试，能测3场 就不测5场。
减小测试环境准备的成本，集中精力测试核心系统，或者由瓶颈的系统。其余系统都扔开。

（四）基准->单交易负载->混合负载的弊端
教科书式的方法、八股文式的思路，不能适应具体的测试，由于或许不少的测试场景是在浪费时间。笔者更倾向于根据系统的业务特色、技术特色选择少数几个性能案例执行。

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

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

（五）新建系统没有任何过往数据的状况下如何创建性能测试模型？
因为新业务项目可能没有明确的需求，也没有生产上的历史数据或者相似项目数据能够分析。新业务的性能测试可采用探索性测试。探索性测试的目的在于给出该系统的整体性能表现、系统将在什么时候何处出现性能瓶颈、并分析、定位问题，给出调优建议。

简单来讲，我不知道生产峰值TPS是多少，但我要知道本身系统在某个条件下的最大承载能力是多少，而且要分析出瓶颈在哪里，若是要扩容知道怎么扩。

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

举例说明：

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

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

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

三、在维度1、维度二选定的参数基础上，进行不一样存量数据的比对。

（六）设计哪些异常的测试场景？
性能场景设计中，异常场景主要有：

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。

3、性能测试环境的设计

（一）测试环境有限的状况下测出接近生产的性能表现
企业里的测试环境大部分都不如生产环境。在测试环境有限的状况下，有什么好的策略能够在有限资源下测出接近生产的性能表现？

1） 将集群环境改成单台服务器，将有限的资源集中供应某一台服务器。

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

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

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

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

（二）在生产环境下作性能测试是否可行？
不少互联网公司和部分中小银行是采用生产环境作性能测试的，或是是共享了部分生产环境（例如网络、存储）作性能测试。

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

互联网应用因为系统庞大，没有那么大的测试环境来使用，而且，出了问题又能怎样，反正是半夜测试的，一共也没几个用户受影响，受影响又有什么了不得，反正用户是免费用的，过一下子就行了，对不住啦。

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

因此，在生产环境下作性能测试对于一些企业是可行的，但对于另外一些则不行。好比，人民银行的测试，总不能真刀真枪的测吧，出了问题，全部银行业金融机构都受影响。银行系统出了故障和互联网公司的故障，民众的容忍度是不同的。

（三）老旧的测试环境如何测试出合理的结果
这个问题实际上是两个问题

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

2）设备老旧

我们分别来看

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

1.1） 将集群环境改成单台服务器，将有限的资源集中供应某一台服务器

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

2）设备老旧

设备也分为好多类型，他们采用的技术、协议也不必定相同。咱们假设技术、协议是差很少的，只是型号老。

对于CPU资源）能够对比测试设备和生产设备的TPCC/tpmC的值，有兴趣能够翻看个人文章http://www.aixchina.net/Artic...

对于内存资源）速度上新老设备是有差别，但每每影响不到太大的量级

对于存储资源）若是能力相差很大，这个没什么好办法。或者能够把内存当作磁盘，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.

4、性能测试工具的选取和设计

（一）有哪些好的性能测试工具可用？
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）多是被测系统已经到瓶颈了，压力机能力再强，请求也发不出去了。