压测--完善个人测试体系重要的一环

本文主要是介绍压测--完善个人测试体系重要的一环，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、压测是个啥？为啥要压测？

二、压测方案设计

1、压力场景

2、压测方案设计关注点

3、涉及到的知识点：

三、压测执行

四、压测报告关注点

一、压测是个啥？为啥要压测？

压测属于性能测试的一种：

性能测试的选择和需求有关，选择的场景不同，使用的性能测试方案均是不同的，性能是随着业务的发展，不断新的要求，不同的阶段，性能测试的频率不一样。

看到过网上有个馒头的例子：

一口气吃十个馒头，并发，压力（并发）测试，一口吃15个，20个，吃不下，一口吃18，能吃；

馒头一个一个吃，负载测试；（压死骆驼的最后一根稻草）

已知吃15个馒头，绕操场跑，如果没问题，就是稳定性很好。

压测目的：

压测的目的是为了观察当前系统的负载能力，考察系统高负载的稳定性。

给出系统当前的性能状况
定位系统性能瓶颈或潜在性能瓶颈

题外话：压测经常和负载测试让人分不清楚，从一篇博客看到一句说的很明白的话：

负载测试就是不断增加压力，进行测试。压力测试就是最大负载下的测试。

负载测试是通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。负载测试是一种测试方法，可以为性能测试、压力测试所采用，负载测试的加载方式也有很多种，可以根据测试需要来选择。

性能测试是为获取或验证系统性能指标而进行测试，多数情况下，性能测试会在不同负载情况下进行。
压力测试通常是在高负载情况下来对系统的稳定性进行测试，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。

二、压测方案设计

1、压力场景

压测包括两种场景：

一种是单场景只压一个接口的；第二种是混合场景，多个有关联的接口。

2、压测方案设计关注点

1、调研下游接口和基础组件的负载能力，查看调用次数，确定人员和接口是否可以承受；
2、梳理下游接口的时候，整理出具体调的服务和次数；
3、确认是否有缓存，预估每个服务的QPS;
4、设计方案时候，预估风险；
5、压测前测试时需要通过链路验证，确定是否漏掉部分服务；
6、数据量大的时候，考虑压测是否对线上真实数据有影响，比如写数据库，用影子缓存，如果只是读，可以考虑直接用线上数据；
7、在压测中考虑是否回放，具体和缓存的失效时间也都有关；
8、报警需要把无关的mock掉，否则干扰定位问题；

3、涉及到的知识点：

1.TP指标&QPS（TPS）

TP指标: TP50：指在一个时间段内（如5分钟），统计该方法每次调用所消耗的时间，并将这些时间按从小到大的顺序进行排序，取第50%的那个值作为TP50 值；配置此监控指标对应的报警阀值后，需要保证在这个时间段内该方法所有调用的消耗时间至少有50%的值要小于此阀值，否则系统将会报警。

需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。

TP90，TP99，TP999与TP50值计算方式一致，它们分别代表着对方法的不同性能要求，TP50相对较低，TP90则比较高，TP99，TP999则对方法性能要求很高

这里面包含了两个概念一个是TP指标，一个是QPS。

QPS（TPS）：每秒钟request/事务的数量。比如一秒内只有一个请求，那么qps=1;如果每秒50，那么qps=50;

2. 吞吐量(Throughput)
吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
　　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。

3. 并发用户数
　　并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。