系统性能测试场景规划设计方案参考

系统性能测试场景规划设计一个性能测试案例的执行成本远高于功能测试，那么如何设计性能测试场景，以最少的案例拿出能够说明问题的结论，是所有关注性能问题的工程师的重要目标，同时也是一门工匠的艺术。1本文总结了社区线上交流活动“如何规划和设计高质量的系统性能测试场景”的 50余个问题，将之分门别类的汇总、归纳、浓缩，将 50余个方方面面的知识点在最短的篇幅中展现给大家。浓缩之后的章节如下：性能测试策略的设计性能测试场景的设计性能测试环境的设计性能测试工具的选取和设计2（一）性能测试策略的设计如何制定性能测试策略？性能测试策略需要考虑以下方面、业务测试范围哪些测，哪些不测。比如什么业务测、什么操作系统版本、中间件版本测。、制定优先级规则由于测试场景、测试案例是没办法穷举的，理论上测试是永远不可能结束的。并且，性能测试本身又牵涉出容量测试、扩展性测试、高可用测试、压力下的异常测试等等的测试延伸，因此在给定的时间条件下，必须制定性能测试的优先级规则， 根据优先级规则划定测试范围。 性能测试的进展受制于功能验证的完成、环境准备的完成、相关工具的开发、性能问题的定位和调优等，当性能测试的计划需要变更时，可以按照优先级规则重新选择测试范围。3、基本的测试方法例如：a）如何产生业务压力b）如何产生用户并发c）如何构造场景使应用系统的逻辑处理算法达到生产的计算量级d）如何制造外围环境对被测目标的响应34、测试环境设计设计测试环境的拓扑结构和资源配置，因为测试环境的拓扑、资源不一定和生产环境相同。需要想清楚为什么这么设计，也就是说在这样的环境下（可能是精简的环境）可以得出可信度高的性能测试结论。、概要测试计划、依赖条件、风险等等其中前4条基本决定了项目的工作量。更直接的说，前 2条决定了测试人员可以晚上几点回家。“测测看”是不是一个有效的测试方法？性能测试的成本是非常高的，“测测看”往往浪费严重。性能测试必须对测试场景有提前的规划，而这个规划的前提是对被测系统、产品有充分的了解。业务上面那些交易吞吐量大，从技术上讲哪些服务器、哪些模块容易出现性能瓶颈，甚至对操作系统、中间件、应用软件的参数都要提前规划好。不然测了很多案例，发现参数不合理，测试结论完全作废。当然，有时我们并不能很准确的设计每个参数，但至少要有一个计划，我对那个参数进行调参的测试，以期测出最优的性能表现。4然而，“测测看”有它的可取之处，因为真正的性能表现只有测试之后才会知道，笔者比较倾向的一种方式是，“提前规划场景，每个场景跑完之后分析结果，然后决定下一场跑不跑、跑什么、参数怎么设”。如何模拟和感知关联系统的压力？1）如何模拟核心系统的正常压力不确定你问的是哪一方面，就我的理解先回答一部分一个交易或者请求的链路可以很长，那么，可以从这条链路中任意一个节点，采用某种压力工具进行施加压力。比如：a）可以模拟 enduser 的页面操作，用 Loadrunner 、JMeter 等性能测试工具录制用户的页面操作，采用并发用户回放，模拟用户。b）可以模拟应用服务器直接给数据库服务器施加压力，采用性能测试工具，建立与数据库的连接，直接把批量的sql语句扔过去c）可以直接采用数据库录制回放，把生产上录制的数据库 sql在测试环境的数据库回放。发起压力的机器离核心系统越近，越容易控制2）如何感知在测试系统接入后对核心系统的压力影响5这个由监控来做。平常不测试的时候，核心系统有多少 TPS，多少CPU占用、内存占用，多少任务数，多少网络带宽占用、磁盘 IO、业务响应时间是多少。测试的时候，这些指标增加了多少，这个感知工作由监控来做。去掉前端系统，直接压测后端，和真实情况有差异吗？如果模拟的逼真，是没有任何差异的。那么问题来了，什么是模拟的不逼真？举例1）生产环境某系统每秒处理 100个事务，你如果采用性能测试工具， 1个用户每秒发 100个请求，可以模拟出系统每秒处理 100个事务。但是，假如生产环境中这 100个事务是由 100个用户发起的，那么此时就有些差异了。首先，网络通道的连接数可能不一样，用户登录次数可能不一样， session 的打开数量，数据库连接数，数据库启动的服务进程数等等都有可能不一样。举例2）生产环境中每分钟处理 60个业务，这 60个业务是匀速达到的。而你如果在性能测试的时候，在第一秒钟把 60笔业务都发出去了，后面 59秒闲着。那么这个模拟也是非常不逼真的。一场性能测试跑多长时间合适？很多人一跑性能场景就跑 1个小时以上，其实跑多久完全取决于系统特点。有些系统在大压力面前，几秒钟就可以调整到位，后面只要压力稳定，它的资源利用率、响应时间都是稳定的；对于这种系统，个人认为测10分钟足以。结果取下来，把前面几秒钟、后面几秒钟去掉，就可以采集数据了。6而对于数据库业务较复杂的场景， 可能头10分钟的性能表现和后 10分钟完全不一样。 这种情况下，测试多久、数据取哪一段、要不要先给系统预热然后再正式测试都是要具体分析的。白天执行性能测试还是晚上执行？很多企业选择在晚上做性能测试是因为环境只有 1套，白天有大量的功能测试人员趴在上，环境被改来改去，根本执行不了性能测试。只有晚上才空出来给性能测试那几个人用。然而，抛开环境共用的因素，从结果准确性的角度，我还是比较推荐在晚上测，因为，测试环境资源是公用的，即使性能和功能测试是分别的两套环境，业务上互不影响，但底层资源是互相影响的（网络资源、计算资源、存储资源）。从实际经验来说，晚上测出来的结果和白天的结果的确不太一样。再然而，我更推荐白天测。因为人是要睡觉的。有时候我们设置了定时任务，让测试晚上自动执行，但这样就不能及时获取性能结果并及时分析，不能及时调整下一场测试的内容。导致很多无效的测试。（二）性能测试场景的设计什么是性能测试模型？性能测试模型大概来说就是把哪些交易放到一起测试，各个交易的交易占比是多少。性能测试模型是从生产业务模型转化而来的，按照性能测试模型来设计测试场景，可以保证测试模拟更贴近生产实际的交易场景。一般都有这些模型：像正常交易日业务模型、峰值交易日业务模型、特殊交易日业务模型等。7银行核心业务系统的测试场景需要考虑哪些？银行类的系统，主要考虑联机交易和批量交易测试场景，联机交易场景：已上线的业务系统，需要先调研生产最近一段时间业务量分布情况，找出在什么时间点系统交易量出现峰值，然后在深入分析峰值时间点有哪些交易，交易的占比，峰值持续时间等，形成测试模型；未上线的系统，在没有明确的性能指标的情况或可参看的历史数据情况下，可做探索性测试，找出系统在什么时间、什么地点出现拐点和瓶颈，然后进行分析和调优。批量交易场景：主要考虑批次时间窗口要求，同时还要关注批次叠加联机交易的性能情况。测试用例如何设计比较合适？对于性能测试来说，主要是）测到点子上，即把最有可能出现瓶颈的地方测出来）在1)的前提下，尽量少侧缩小测试范围（只测某些业务、只测某个操作系统版本、只测某个中间件版本）。同一个场景下，减少案例个数。负载测试，能测 3场就不测5场。减少测试环境准备的成本，集中精力测试核心系统，或者由瓶颈的系统。其他系统都扔开。8基准->单交易负载->混合负载的弊端教科书式的方法、八股文式的思路，不能适应具体的测试，因为或许很多的测试场景是在浪费时间。笔者更倾向于根据系统的业务特点、技术特点选择少数几个性能案例执行。比如说，一共有 10个交易，但生产环境 98%的交易都是 A，那么单交易负载只测试 A，混合负载甚至可以不测。再比如说，10个交易中，仅有交易 B对数据库的增删改查压力较大，而其他交易交易没有太重的数据库访问，那么只测交易 B。新建系统没有任何过往数据的情况下如何建立性能测试模型？由于新业务项目可能没有明确的需求，也没有生产上的历史数据或者类似项目数据可以分析。新业务的性能测试可采用探索性测试。探索性测试的目的在于给出该系统的总体性能表现、系统将在何时何处出现性能瓶颈、并分析、定位问题，给出调优建议。简单来说，我不知道生产峰值 TPS是多少，但我要知道自己系统在某个条件下的最大承载能力是多少， 并且要分析出瓶颈在哪里，如果要扩容知道怎么扩。对于不同的测试对象（测试功能点或测试模块），需分为不同的维度进行测试，并说明选择这个分析维度的原因。测试的维度需要按照测试的优先级排列。测试维度举例：交易量的变化、用户并发数的变化、交易配比的变化、数据文件大小的变化、 软件参数配置的变化、 硬件参数配置的变化、 存量数据的变化等等。9每一类维度测试完成后，需选出最典型的值，在此基础上进行下一维度测试。这么做的目的是为了减少测试分支。举例说明：某系统中，某个模块的并发查询是性能关注点，可依据对查询影响较大的几个因素按优先级进行排序：不同的查询条件，不同的并发用户数、不同的存量数据。、不同的查询条件，开发程序内部的处理不同，性能表现也不同，作为第一个测试维度，需尽可能分析程序内在实现方式，划定测试范围，测试后挑选更加典型的查询条件，为后续测试尽量缩小查询条件的范围。、在维度一选定的典型查询条件基础上，选取不同的并发数进行测试。涵盖需求中要求的并发数。验证并发数是否满足需求， 预测并发数多大时会达到性能瓶颈。 并选择合适的并发数作为后续测试的并发参数。3、在维度一、维度二选定的参数基础上，进行不同存量数据的比对。设计哪些异常的测试场景？性能场景设计中，异常场景主要有：）系统的异常：在业务压力的情况下进行高可用切换（比如一个进程挂了、一台服务器挂了、一个站点挂了、一个光纤卡挂了、一台存储挂了），存储空间满了等等。）用户犯的错误：选取生产系统容易发生错误的业务，这类业务由于是错误的，所以应用的处理路径、消耗的资源和正常情况下是不一样的。10二八原则在很多情况下不适用我目前接触的生产环境， 没见过二八现象。因为现在的交易已经不太分时间段了， 白天晚上都有不少交易。以银行的业务 A为例，如果一天开门 8小时，其中峰值的小时吞吐量 乘以5可以得到全天业务量。以银行的业务 B为例，如果一天开门 24小时，其中峰值的小时吞吐量 乘以10可以得到全天业务量。如何计算性能场景里面的 vu、Pacing1）首先要指定 TPS的目标比如说咱们打算发到被测服务器的 TPS=100，即每秒要 100个请求。2）根据TPS计算用户数和间隔。如果设置10个虚拟用户，那么每个用户每秒发 10个请求。 那么每个用户每隔 100ms 要发出来一个请求（1000ms/10=100 ）。这100ms 包含了2个时间（1）发送请求的时间，（2）停顿时间，即上一次发送结束到这一次发送开始，中间的停顿。3）实测调整如果“发送请求的时间” 本身就要90ms（这个是需要实测出来的） ，那么你的停顿时间 应该是10ms，但10ms 计算机是不可能稳定控制的，因为进程调度、 CPU调度的原因。最后导致发出来的 TPS并不稳11定。因此第一次测试，可能设置的不合理，没关系，根据实测值，第二次测试就可以设置合理了。我们接着计算因为刚才的停顿时间 10ms 太短，咱们至少要有 30ms的停顿时间。那么一个请求整体时间就是90+30=120ms 。这个情况下，一个 vu（虚拟用户）一秒钟可以发出来多少笔请求呢？1000ms/120ms=8.33 笔。那么你要一秒发出来 100个请求，需要多少 vu呢？100/8.33=12 个vu。一台压力机放 12个vu能不能跑出来想要的结果呢？ 也不一定，因为这 12个vu可能把压力机给压垮了。如果一台压力机不够，可以多加几个压力，共同跑 12个vu。（三）性能测试环境的设计测试环境有限的情况下测出接近生产的性能表现企业里的测试环境大部分都不如生产环境。在测试环境有限的情况下，有什么好的策略可以在有限资源下测出接近生产的性能表现？1）将集群环境改为单台服务器，将有限的资源集中供应某一台服务器。这样，可以测试单台设备的最大吞吐量。如果集群环境中各个服务器之间没有资源共享、资源征用的话，单台设备的最大吞吐量 *设备数量 就是整个系统能够达到的最大吞吐量。当然，现实中没有这么理想，12往往存在网络共用、 存储共用，这就要深入分析这些共享因素对性能的影响了。 甚至有些集群还有锁机制，比如OracleRAC，IBMCF，这些有锁机制的集群不太适合单台的测试。2）去掉中间环节的服务器，直接压测核心系统。例如，一个客户请求过来之后，经过 F5、Web服务器、应用服务器、数据库这几个系统，而根据经验判断，前面几个系统都不是性能瓶颈。那么，可以把前面的系统摘掉，采用性能测试工具直接压测数据库服务器。再比如，业务系统的签名通过签名服务器来完成，但我们想知道签名服务器的最大吞吐量，那么，去掉业务系统，直接压测签名服务器。在生产环境下做性能测试是否可行？很多互联网公司和部分中小银行是采用生产环境做性能测试的，或是是共享了部分生产环境（例如网络、存储）做性能测试。他们的特点是，“没有办法只能选择生产环境做性能测试，并且出了问题也压力不大”。互联网应用由于系统庞大， 没有那么大的测试环境来使用， 并且，出了问题又能怎样， 反正是半夜测试的，一共也没几个用户受影响，受影响又有什么了不起，反正用户是免费用的，过一会儿就好了，对不住啦。一些中小银行也存在测试环境不足、出了问题也没几个人受影响的情况。13所以，在生产环境下做性能测试对于一些企业是可行的，但对于另一些则不行。比如，人民银行的测试，总不能真刀真枪的测吧，出了问题，所有银行业金融机构都受影响。银行系统出了故障和互联网公司的故障，民众的容忍度是不一样的。老旧的测试环境如何测试出合理的结果这个问题其实是两个问题）设备型号和生产一致，但资源配置少）设备老旧咱们分别来看1）设备型号和生产一致，但资源配置少1.1）将集群环境改为单台服务器，将有限的资源集中供应某一台服务器1.2）去掉中间环节的服务器，直接压测核心系统 ,或者直接压测你认为是瓶颈的系统。2）设备老旧设备也分为好多类型，他们采用的技术、协议也不一定相同。我们假设技术、协议是差不多的，只是型号老。对于CPU资源）可以对比测试设备和生产设备的 TPCC/tpmC 的值，有兴趣可以翻看我的文章/Article/16088714对于内存资源）速度上新老设备是有差异，但往往影响不到太大的量级对于存储资源）如果能力相差很大，这个没什么好办法。或者可以把内存当做磁盘， ramdisk。把存储的影响降到最低。局域网内如何模拟广域网环境？如何在测试环境模拟互联网公网环境，或者模拟有带宽限制（如 100M/s ）？有一种设备叫网络损伤仪，用来模拟带宽大小，延时是多少毫秒，丢包率等等。不过网络损伤仪也不是模拟的特别好，有时候网络损伤仪变成了网络瓶颈，并没有想象中那么完美。用内网还是外网测呢？问：测试环境是用内网还是外网呢？如果用内网，到时候如果是服务器端网络带宽问题是否无法发现，用外网测试的话如果是压力机网络带宽问题岂不是又要加带宽？答：如果贵司的业务是对外提供服务的，外网测比较真实，不仅仅是网络带宽问题是否能被发现，还可以发现因为网络延时导致的一些问题。带宽占用这个事，其实是可以算出来的，小压力的跑一会，用 TPS和服务器的网络带宽占用 就可以推算出来当生产压力达到 XX时，对应的服务器带宽占用。15广域网网络延时（比如 30ms），如果你的交易要好多个来回交互，可能就会出现性能问题，有些代码是有超时机制，超时就报错了。当然，如果单位的外网带宽固定，也不是说加就加，那就在局域网测吧。但如果单位有钱，可以买个网络损伤仪，模拟广域网的带宽延时。虚拟化环境中得出的测试结论是否可信 >只要虚拟化的参数设置得当，测试结论是可信的。比如说生产环境这个系统是 10个CPU，那么虚拟化环境也给足 10个CPU即可比如：设置 dedicatedCPU ，或者EC=VP=10。当然，还有网络、磁盘、内存等其他资源也同样要设置得当。虚拟化资源和物理资源有没有对应关系？内存一般都是物理的，实实在在的。也有的 hypervisor 把磁盘给 OS，让OS误以为是内存，但一般没这么搞的。CPU的话你要看你是什么虚拟化平台了，但都可以设置最低保障（标称计算能力）1)x86的CPU可以设置保障的 Hz值。x86平台在虚拟 CPU的分配和控制上的确不是很精细。162)Power 的CPU，可以设置 EC（entitledcapacity ），一个 EC约等于一个 core。但此时 VP的值要设置合理（如果过大，也会和实际情况偏差很大），可以设置 EC=VP 这样就和实际情况很接近了。或者，如果你对 CPU机制了解比较多的话，也可以去计算。任何虚拟化平台的 VP都是一个线程，一个线程最多占用一个逻辑 CPU（也就是一个 CPU超线程，或者一个 CPUSMT）。你可以把虚拟机 CPU跑的很饱和，这时，你就能算出来，占了多少逻辑 CPU，再根据 CPU型号，推算占了多少个 CPUcore.（四）性能测试工具的选取和设计有哪些好的性能测试工具可用？1）测试工具常用的有：Loadrunner ：需license，但不少人是试用性质。功能、易用性方便最优秀，是性能工具的标杆2）JMeter：无license，免费，是免费工具里面的标杆。易用性差一点。3）当然然还有很多其他工具，各有特色。还有些是专门测磁盘 IO、网络IO的小程序。用于模拟系统读写负载的测试工具？在做主机及存储系统等综合测试（含高可用、性能）时，常会碰到无法一开始就带应用测试，但又需要模拟真实应用的读写场景。有哪些比较简单又实用的测试工具，用于模拟系统的读写及计算负载？17磁盘IO的压测工具：例如orion、iometer ，dd命令、xdd、iorate，iozone，postmark不同的工具支持的操作系统平台有所差异，各具特色。有的工具可以模拟应用场景，比如orion是oracle出品，模拟Oracle数据库IO负载（采用与Oracle相同的IO软件栈）。即模拟oracle应用对文件或磁盘分区进行读写（可指定读写比例、iosize，顺序or随机）这里就需要提前知道自己的IO模型。如果不知道，可以采用自动模式，让orion自动的跑一遍，可以得出不同进程的并发读写下，最高的IOPS、MBPS，以及对应的响应时间。比对dd，仅仅是对文件进行读写，没有模拟应用、业务、场景的效果。postmark 可以实现文件读写、创建、删除这样的操作。适合小文件应用场景的测试。性能指标采集工具由于性能指标包含很多方面1）系统资源的指标（ CPU、内存、网络 IO、磁盘IO））服务指标（响应时间、吞吐量））业务指标（业务量、并发用户数、业务类型）因此没有一个现成的工具可以抓取所有指标， 原因是，一些指标是和业务、 应用关联，需要用户自己定制。比如某个业务的响应时间，需要从日志采集，那就需要自己定制日志采集和统计的工具。18当然，这些工具也可以集成在一起N台压力机没有跑出来 N倍的效果1）检查你发送压力的代码，有没有 lock。具体来说，举个例子，所有的交易要有全局唯一的交易编号。如果所有的压力机上的交易标号是由一台机器产生的，这台机器产生编号的速度就是整个压力机集群的瓶颈。2）检查是否有资源共用。比如所有压力机都是虚拟机，共用存储、 CPU等等。比如所有压力机去某个数据库读数据。这个可以看压力机的资源利用情况、响应时间就可以看出来）可能是被测系统已经到瓶颈了，压力机能力再强，请求也发不出去了。卫生管理制度1 总则1.1 为了加强公司的环境卫生管理，创造一个整洁、文明、温馨的购物、办公环境，根据《公共场所卫生管理条例》的要求，特制定本制度。1.2 集团公司的卫生管理部门设在企管部，并负责将集团公司的卫生区域详细划分到各部室，各分公司所辖区域卫生由分公司客服部负责划分，确保无遗漏。2 卫生标准2.1 室内卫生标准2.1.1 地面、墙面：无灰尘、无纸屑、无痰迹、无泡泡糖等粘合物、无积水，墙角无灰吊、无蜘蛛网。2.1.2 门、窗、玻璃、镜子、柱子、电梯、楼梯、灯具等，做到明亮、无灰尘、无污迹、无粘合物，特别是玻璃，要求两面明亮。2.1.3 柜台、货架：清洁干净，货架、柜台底层及周围无乱堆乱放现象、无灰尘、无粘合物，货架顶部、背部和底部干净，不存放杂物和私人物品。2.1