一个性能测试案例的执行成本远高于功能测试，那么如何设计性能测试场景，以最少的案例拿出能够说明问题的结论，是所有关注性能问题的工程师的重要目标，同时也是一门工匠的艺术。
笔者总结了社区线上交流活动“如何规划和设计高质量的系统性能测试场景”的50余个问题，将之分门别类的汇总、归纳、浓缩，将50余个方方面面的知识点在最短的篇幅中展现给大家。浓缩之后的章节如下：
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）可能是被测系统已经到瓶颈了，压力机能力再强，请求也发不出去了。
