性能测试

¶性能测试怎么测试

性能测试其实就是通过自动化工具模拟多种正常、峰值以及异常负载来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，二者可结合使用。

性能指标主要有平均响应时间、90%响应时间、吞吐量、吞吐率，每秒事务数，以及服务器的资源使用率(CPU占比，mem内存占比等)等。当并发用户数超过300时，为了让测试数据更准确，可以考虑分布式压测，通过jmeter客户端控制几台jmeter服务器进行测试。

性能测试要先调试好脚本，主要考虑对脚本的数据参数化和添加断言。因为有些接口需要对业务逻辑或参数格式进行校验，为了能让所有线程数跑起来，需要将数据参数化。

数据参数化有这几种做法：

1、可以将一些固定值改成随机函数;

2、利用JDBC从数据库读取数据并关联变量；

3、Excal数据参数化，

4、动态关联参数化，断言是为了判断用例是否

执行成功，并验证服务器的响应错误率。响应断言常用json断言，xml断言用的最少，

性能测试的目的是为了检验系统能否满足客户的性能需求，若性能需求无法满足时，则

要考虑对系统进行性能调优，一般用排除法：

1、首先考虑网络方面问题：使用ping命令查看与目标服务器的连接是否正常、传输速度的快慢。通过提升服务器的带宽，看响应时间是否相应降低。

2、考虑数据库的问题，可以单独去压测数据库，查看数据库的最大连接数和SQL语句的执行时间，索引命中率和sleep等待时间等

3、考虑 Apache/Nginx等中间件的问题，查看中间件设置的最大连接数是否合理，如果设置的连接数太小，会话数超过设定的最大连接数时会导致等待时间变长，出现响应超时情况

4、考虑服务器的硬件配置，如内存、CPU、磁盘读写速度等，可以用top命令来监控，也可以使用nmom工具来监控，nmom会把监控的数据形成表格形式，方便我们查看。

5、最后考虑开发代码写的好不好，处理时间长不长的问题。

举例：在我之前的公司，我们主要是会考虑用户操作使用比较频繁的模块，比如借贷，充值，投资模块，我们一般会通过增加并发数来压测，观察CPU、mem、磁盘读写、吞吐量和每秒事务数等性能指标，以前我老大要求我并发100个用户，我用 jmeter把线程数设为100，永久循环，持续时间半个小时，设置启动延退55，在Linux启用mmom工具监控服务器。

当我运行脚本的时候我看聚合报告90%的平均响应时间达到了6s，吞吐量也比较小，用top命令监控资源发现CPU差不多到了100%。于是我用 Navicat工具通过SQL命令show full processlist取当前运行的SQL语句，发现有许多语句用的是左关联，在查看了这条SQL语句的执行计划发现没有用索引，再查看了索引的命中率，命中率倒是还行看了下nmom生成的报告，发现CPU一直是处于爆满状态，其中主要是mysql的占比很大，这个时候我基本上判断数据库的问题。

于是我就照着前面的步骤再次压测，同样还是用nmom工具去监控CPU，mem网络等状态，这次我是主要在 Navicat上用命令去抓取SQL语句，还是一样有很多语句都是左关联，并发现很多空连接(sleep)，我就用 show global variable like"wait_time"命令查看了设置的休眠时间(等待时间)发现时间很长28800s，然后我就把这个休眠时间改成了20s，因为SQL语句使用了很多左连接，我就用 show variables like"tables_size"查看了临时表的空间大小、发现临时表只有16m，我将空间改成了1G再去压测了下，发现CPU只是降了10%左右，nmom报告上还是显示mysql占的CPU很大，然后运行的时候，用top命令监控，发现有的时候有很多mysq进程同时运行(因为没有设置连接池)，我就用命令查看了下mysql的最大连接数，因为SQL语句的执行速度还是挺快的，所以就把mysql的连接数调小到50，再去跑了一遍发现CPU降到了40%左右，并且其他的性能指标也都还不错。最后把聚合报告的数据以及nmom的数据整理成性能报告给老大，其实做接口性能主要就是用排除法个一个去排除，发现性能问题就要先解决了性能问题再压测，不然其他的问题也有可能是这个性能问题导致的所以接口性能基本上就是观察，各个性能指标都在范围之内就差不多了。

¶性能测试流程是怎么样的

例外一种问法：简单介绍下你们公司的性能测试流程是怎么样的?

我们那个项目的性能做得不多，公司要求也不严格。

对于流程这块，首先就要对整个系统进行详细的分析，确定基本的测试范围，看下系统的哪些业务是需要做性能测试的，还有就是做那方面的性能测试，对于我们那个项目，当时就做了几个业务做了些简单的井发压测(稳定性)这块，像登录的，搜索查询，下单，还有就是购物车里面的几个接口都有做过，然后就是对各个业务场景进行详细的场景分析与设计，确定每个业务场景的并发数，是否需要设置集合点啊，压测时间是多长，还有各个业务场景的性能指标等等，场景设计这块基本上都是老大跟产品哪个一起弄的，我参与的不是太多。

上面把个场景设置好了之后，提交给我们，我们就是根据老大设置好的那些场景编写了基本的性能测试用例，其实做性能测试，我觉得前期最关键的还是业务场景一定要设计好，后期我们主要的任务就是准备各自任务需要用到的一些测试数据，搭建好测试环境，还有就是测试脚本设计与开发，执行，并生出测试报告，对于测试结果我们一般会简单的做个分析，如果没有什么问题，基本后期就写一个性能测试报告。流程大概就是这样的。

¶你们性能观察哪些指标，大概指标范围是怎么样的。

对于指标这块，业务方面的指标主要有：并发数，90%用户的平均响应时间

错误率，吞吐量/吞吐率这些，例外还需要关注服务器资源的使用情况，像：CPU的使用率、内存的占有率，磁盘IO，网络。

我们那个项目当时只针对，登录，搜索查询，下订单，购物车相关接口，支付等业务做了些简单的并发，压测这块，指标大概是这样的：

单基准业务并发测试登录，注册，查询1s以内，下订单，购物车相关接口，支付2s以内，混合业务性能：5s以内

响应时间：登录，注册业务<2s之内查询，下订单，购物车，支付业务<3s

充值，提现，查看充值日志，查看提现日志业务查询标的，<3s

投标，申请借款<5s

错误率：0

吞吐量/吞吐率：200左右请求/sec

CPU：80%以内

内存：80%以内

I/O： %util<=80%，%nowait<=20%

%util: 磁盘一秒中有百分之多少的时间用于I/O操作，

% nowait：磁盘等待处理时间占比

带宽：<=系统带宽的30%，无丢包，无延迟，无阻塞

¶这个测试的环境配置，如转速度

租用的服务器，一台数据库服务器，一台后端服务器

8核16G网络带宽1000M，2.5GHZ磁盘15000pm转数

¶性能测试计划有哪些内容

写过，主要是时间进度安排与工作安排，主要是环境，测试任务，测试需求，测试方法与策略，测试环境准备，测试通过的标准。

比如说原来我们一个项目性能测试时做了5天，那我们计划是，测试策略与用例编写一天，测试准备需要1天，测试执行2天，报告总结1天。

¶有没有写过性能测试报告，具体包括哪些内容

性能测试报告，需要每次 Jmeter压测完成的html报告的数据跟nmon工具监控的数据，整理出一份性能测试报告，性能测试报告，主要包含：

1，测试资源(环境，测试数据，表里面需要多少数据，测试工具)

2，测试设计(测试业务，测试类型，测试时间，并发用户数)

3，测试分析(每一个场景都需要分析)

4，测试结论(能不能上线，不上线的原因)

5，优化和建议

6，测试通过的标准，平均响应时间<5s，资源利用率<75%，事务失败率<5%

¶什么是内存泄漏，什么是内存溢出？

内存泄漏：

是指程序在申请内存后，无法释放已申请的内存空间，导致系统无法及时回收内存并且分配给其他进程使用。通常少次数的内存无法及时回收并不会到程序造成什么影响，但是如果在内存本身就比较少获取多次导致内存无法正常回收时，就会导致内存不够用，最终导致内存溢出。

内存溢出：OOM

指程序申请内存时，没有足够的内存供申请者使用1M实际要占用2M内存，

就说分配的内存不够，导致内存溢出

给了你一块存储int类型数据的存储空间，但是你却存储long类型的数据
长期出现内存泄漏，导致系统内存越用越少，最终导致内存不够用，导致系统崩溃，出现OOM

¶吞吐量，吞吐率

吞吐量：KB

指在一次性能测试过程中网络上传输的数据量的总和(单位应该KB)也可以这样说，

在单次业务中，客户端与服务器端进行的数据交互总量；对交互式应用来说，吞吐量指标反映服务器承受的压力。

并不是吞吐量越高越高，一个服务器的性能，要从多个方面去考虑：

90%用户的平均响应时间、错误率、吞吐量/吞吐量、CPU、内存、磁盘I/O、网络的占用情况，

还有服务器的配置。

吞吐率：

吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量，它是衡量网络性能的重要指标。

12s 800M数

800 * 1024 / 12 = 66666 KB/sec

通常情况下，吞吐率用“字节数秒”来衡量，当然，也可以用“请求数/秒”来衡量;

¶吞吐量与吞吐率跟负载有什么关系

吞吐量/率和负载之间的关系:

1、上升阶段：吞吐量随着负载的增加而增加，吞吐量和负载成正比;

2、平稳阶段：吞吐量随着负载的增加而保持稳定，无太大变化或波动;

3、下降阶段：吞吐量随着负载的增加而下降，吞吐量和负载成反比;

总结：吞吐量/率干不过负载!!！

¶当你服务器满了之后，你们吞吐量和响应时间怎么变化的

吞吐量会所有下降，响应时间会变长

¶你们的TPS的指标是什么估算的

假设一个系统的业务有登录、浏览帖子、发送新帖、回复帖子，访问高峰是上午10点，日访问高峰PV约5208(含登录1300、浏览2706、发帖526、回帖676)，系统响应时间要求小于3秒，试计算此系统的TPS以及并发数。

如果分析业务量的数据是以PV来统计的，我们需要把PV转化为TPS。

PV的统计一般可以通过监控埋点或者统计访问日志统计得出。

说到PV还有个特殊的情况，叫 PeakY，指一天中PV数达到的高峰PV值。

通过一些监控系统，也可以直观看到统计数据。

实际上一个PV即一次对服务器的客户请求，可能还包含了很多资源请求，比如图片、样式JS信息、文字等。而浏览器具有资源缓存功能，下次访问同样资源将不会再从远程服务器上下载，这大大加快了响应速度。如果我们使用代理服务器访问外网资源时，多数代理服务器也会缓存这些静态数据。也就是说浏览器与服务器之间的动态数据的Size会小于静态数据。

所以浏览器是否缓存了静态数据对性能测试影响明显。我们在做性能测试时，其中就有许多用户可能是新用户，在他们的浏览器上还没有缓存这些静态数据，为了更准确的模拟用户请求，我们有必要不缓存这些静态内容.所以性能测试中是否缓存访问的静态资源要根据业务情况而定。

本例中，我们把一个请求放在一个事务中来统计服务器的响应时间。这么说，一个PV即是一个事务(每秒的PV量并不直接等同于TPS，因为一次客户请求可能包含了很多资源请求。如果我们不关心页面刷新时请求资源的耗时，此时我们就把每秒PV数等同于TPS)，比如一个功能页面(浏览帖子)每秒会有10个PV，那么此功能的TPS即为10。

估算TPS：

业务量一般要取系统业务高峰的值，才能代表系统的实际处理能力，系统在10点的访问高峰PV约5208，那么这个时段的TPS = 5208/3600 ≈ 1.45吗?

答案是否定的，因为在一小时内的吞吐量未必是平均的。

如果我们采集到的业务量数据能够细分到每分钟，TPS就越准确。如果不能，可以按照二八原则。即80%的业务在20%的时间内完成，TPS=(520880%)/(360020%)≈5.8

估算并发数：

1、由TPS进行估算 2、由在线活动用户数估算 3、根据经验估算

方法1：由TPS进行估算

因为TPS=事务数/时间，假设所有的事务都来自不同的用户，那么并发数=事务数=TPS * 时间。

具体如下：

Vu(业务名称)=TPS(业务名称)*( Runtime+ ThinkTime)

其中，Vu(业务名称)表示此业务的虚拟用户数，即并发数。 RunTime是测试程序/脚本运行一次所消耗的时间，包括事务时间+非事务时间。 ThinkTime是模拟用户思考或者填写表单消耗的时间。

下面是发帖动作的测试脚本伪代码(T、TT、AT表示时间，单位为秒，AT一般都是非常小的，包含在事务时间中，可以忽略).Runtime=T1+…+T7; ThinkTime=TT1+TT2。

Enter login page (进入登录页面)Tl=0.2

ThinkTime (思考时间)TT1=3

Declare login trans action (声明登录事务)T2=3

Commat formm (提交登录表单)

Assertlogin (检资登录是否成功)AT1

Enter default page(进入登录成功后的默认页)T3=0.2

Sender topic

Enter topic list (进入论坛列表)T4=0.2

Enter new page for topic (选入新帖编辑页面)T5=0.2

ThinkTime (思考时间)TT2=3

Declare newTopic transaction (声明新帖事务)T6=3

Commit fom (提交新帖)

Assert commit (查发帖是否成功)AT2

Enter topic list (提交新帖后进入论坛列表)T7=0.2

业内一般把 Think Time设为3秒。测试需求中要求响应时间小于3秒，我们就以3秒为阀值

可得 Vu=TPS (RunTime + ThinkTime)=5.8*(T1+TT1+T2+T3+T4+T5+TT2+T6+T7)≈76

如果只计算事务时间，Vu=TPS*(T2+T3)=34.8≈35

可以看到两者之间的Vu数量相差巨大。由于一次迭代的时间会大于事务的响应时间，如果在估算时不把非事务消耗的时间加入进去，计算出来的12个并发用户在测试执行时很有可能无法达到TPS=5.8的目标。

由于我们计算Vu时，使用的是系统TPS(登录、浏览、发帖、回帖合计)，其中又以发帖业务消耗时间最长，所以计算出来的76个并发数实际上是系统业务的总并发数，需要按比例分配到各个业务。

业务名称	高峰业务量	TPS	并发数	响应时间	事务成功率
登录	1300	1.44	20	<3秒	>99%
浏览	2706	3.0	40	<3秒	>99%
发帖	526	0.58	7	<3秒	>99%
回帖	676	0.75	10	<3秒	>99%
合计	5208	5.8	77	-	-

方法2：在线活动用户数估算

在线用户数的预估可以采取20%的系统用户数.例如某个系统的系统用户数有1000，则同时在线用户数据有可能达到200，或者预估200做参考。

在线用户数和并发用户数又存在着关系，即：平均并发用户数为C=NLTL为在线时长，T为考核时长例如考核时长为1天，即8小时，但是用户平均在线时长为2小时，则c=n*2/8

n为登录系统的用户数，L为登录的时常。例如一个系统有400个用户登录，然后每个用户登录大概停留2小时，则以一天8小时考核，算平均并发用户则为C=400*2/8

答：我们系统的TPS当时是根据PV值来计算的，就是通过查看系统访问日志来获取每个业务功能每天高峰期的PV值(也就是每天高峰期的时间段，有多少服务器的客户请求)，

当时的PV值大概在5000多

然后按照二八原则，即80%的业务在20%的时间内完成，TPS=(P80%)/(时间20%)≈5.6。算出来大概在5.6。

[具体的指标都是SE跟测试主管他们经过分析出来给到我们的。他们开会的时候大概跟我们说过估算方式，差不多是这样的……]

¶每人说一个项目接口，你设置多少并发

首先涉及到并发用户数可以从以下几个方面去做数据判断

1.系统用户数(注册用户数量)

2.在线用户数(平均每天大概有多少个用户要访问该系统，可以从系统日志从获得)

3.并发用户数(高峰期的时候的在线用户数量)

三者之间的关系

在线用户数的预估可以采取20%的系统用户数。例如某个系统在系统用户数有1000，则同时在线用户数据有可能达到200，或者预估200做参考
在线用户数和并发用户数又存在着关系。即：平均并发用户数为C=NUTL为在线时长，

T为考核时长例如考核时长为1天，即8小时，但是用户平均在线时长为2小时，则c=n2/8

n为登录系统的用户数，L为登录的时常，例如一个系统有400个用户登录，然后每个用户登录大概停留2小时，则以一天8小时考核，算平均并发用户则为c=400*2/8

答：就拿登录接口来讲吧

我们的并发数是根据注册用户数量及每天在线用户数综合来估算的，我们系统当时注册用户数量大概是在70多万的样子，不过这里其实有一些僵尸用户，真正的用户大概在60%的样子，也就是差不多，46万多一点，通过查看系统访问日志，高峰期的时候每天在线数,用户数量大概差不多在52000多点吧，按52000估算，每个用户停留时间大概在20分钟左右，大概平均每天同时在线用户数量在2145多。其中登录业务的占比大概在10%的样子，同时在登录的大概80%的比例计算，登录接口大概设置的并发数在172多的样子，查询业务的占比大概在30%，查询接口大概设置的井发数在510的样子，下单业务大概占比在20%，下单接口的井发数设定在345的样子。

[具体的指标都是SE跟测试主管他们经过分析出来给到我们的。他们开会的时候大概跟我们说过估算方式，差不多是这样的…]

¶你们吞吐量是多少，响应时间是多少，你设置了多少并发

查询：吞吐量大概在36/sec响应时间<3s，设置的并发数500个并发数。

下单：吞吐量大根在25.6/sec响应时间<3s，设置的并发数350个并发。

¶做井发你们一般cpu和内存是多少

cpu大概在60%多点，内存大概占比在65%的样子。

¶有没有做过稳定性测试

部分接口有做过稳定性测试。具体怎么做的?

稳定性测试主要就是看某个业务在高并发情况下是否能持续稳定运行嘛，当时大部分的核心业务都有做过稳定性的，这个需是把并发数设置为峰值，然后循环次数设置为永远，例外要开启调度器，调度器中的持续时间设定为3600秒，让它持续压测1个小时。看下接口的各项性能指标的变化，是否在预期的指标范围之内。

¶5000个人抢购，只能50个人能抢到，你怎么设计并发数的

并发数，按群内最大人数计算，利用二八原则，5000 * 80%=4000，并发

¶微信群里面发送红包，5000个人群，只能3000个人能抢到，你怎么设计并发数的峰值

并发数，按群内最大人数计算，利用二八原则，5000 * 80%=4000，并发数的峰值为4000

¶20并发40次循环怎么做？

线程数设置20个，循环次数40

¶我想从200慢慢加载到300，到400怎么做

这个需要用到自定义线程组，自定义线程组最大的好处就在于做压测的时候，可以设置一些复杂的业务场景，具体设置的话，就是…

¶需要插入500条数据，你怎么插入

1、使用存储过程来实现

2、可以通过 JMeter来实现，调用注册接口，线程数设置为500，账号，密码可以通过 JMeter中的随机函数 randomString()，random()函数结合计数器来实现。

¶响应超时，你是怎么定位的

这里一般我会采用排查发，首先考虑软件优化问题，之后考虑硬件问题，思路大概是这样的

1、首先考虑中间件(tomcat，Apache的连接数的问题)，可以尝试增加连接数，看是否变化。

2、例外还有就是数据库的连接数问可题，也可以尝试增加，看是否有变化。

3、要不就是看数据库的访问效率问题，这里要考虑数据库的操作是否添加索引，如果没有添加索引，可以让开发优化下数据库的访问速度，添加索引，或者优化sql语句。

4、再一个就可以尝试考虑后台代码的架构设计是否合理，代码算法是否足够优化。

5、如果以上问题都不能解决，那么只能考虑增加服务器的CPU内存，或者增加网络带宽，看响应时间是否可以得到优化。

大概的思路差不多就是这样的吧。

¶压测返回数据报错，你怎么去定位的

1、如果是所有请求的数据报错，那肯定是脚本问题，认真检查脚本参数。

2、如果只是部分请求报错，那估计是性能可题了。

¶你理解的性能调优是什么

响应时间过长(排除法) -用户体验不好

网络情况(提升带宽)
服务器资源情况
中间件类型
中间件的连接数
代码质量问题
数据库类型mysql–Redis
数据库连接数
sql语句执行时间（show full PROCESSLIST 查看哪些sql语句运行比慢）
1. 看表是否建立索引
2. 运行sql语句是否需要sq优化
索引命中率

低于0.1%比较好，低于0.01%分配比校多，适当减少缓存空间大小

show GLOBAL STATUS like "key——read%"

Key_reads=568

Key_read_requests=1329114

Key_cache_miss_rate=key_reads/key_read_requests=0.000427=0.04%

show VARIABLES like "key_buffer_size" #查看缓存空间大小

set GLOBAL key_buffer_size=8000000 #设置缓存空间大小

10，sleep过多

show GLOBAL VARIABLES like "wait timeout%"

show GLOBAL VARIABLES like "interactive timeout%"

set GLOBAL interactive_timeout= 30

set GLOBAL wait_timeout=30

临时表空间大小

性能排优一些方面：

排除法
很多问题，都是同一个问题导致，需要一个个去排除优化，解决

资源使用率不足：(系统薄弱的位置)

用户量较少
网络问题
中间件连接数不够
代码质量问题
数据库问题

资源使用率过高：(系统会崩溃)

用户量比较大
中间件连接数太大
代码质量问题
数据库问题

¶如果要做万并发，你怎么做

那我们就需要考虑分布式压测，那需要准备几台测试机，

master机器要设置。。。。

slave机要设置。。。。。

也可以租用云测平台进行测试

¶如果用户并发要慢慢加载，你怎么设置的

设置并发数的时候，我们会设置启动时间，比如说设置50个并发用户数就是50个线程组，

启动时间会设置成10秒，让用户慢慢启动起来

¶并发用户数跟响应时间与吞吐的关系

并发用户数越多，响应时间越长
并发用户数越多，吞吐量会一直，增加，增加到一个临界点(系统瓶颈后)，不再增加，有少许的回落