2.压测过程

1.区分定义

性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试

负载测试：确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。

压力测试：评估系统处于或者超过预期负载情况下，系统的运行情况，关注点是在过载情况下找到处理问题慢的边界及处于崩溃的临界点在哪儿。

2.制定目标：性能测试目标

即性能指标，至少包含三方面：时间、容量、资源利用率

ps:容量，可简单理解为tps(单位时间内能支持的用户请求数)

3.建立模型：性能测试模型

性能模型，也就是性能运行的业务抽象，一个业务流程中到底有多少业务会有并发需求，这些并发需求的运行占比如何，总量100%的业务流程中各项业务占比分布同比抽象出来的就是业务模型。

ps:如何抽象? ---基于大量的真实用户、真实业务数据
---这个问题可以回答，如何设置线程数，线程数是基于大量的真实用户数据、运行占比、高峰峰值等，计算出的比例；
如果是一个新业务，没有真实数据可参考，那只能通过阶段加线程数，测试出一个性能指标数据；
以cms为例，线程数的范围是50-200；

4.制定策略：测试策略

性能测试策略应该包含性能方案和性能监控。方案中就包含了刚才说到的测试方法、过程、范围、环境、数据、入口及出口准则等描述。
而性能监控则描述的是，软件及硬件的各项指标数据的监控、分段、全局及定向监控的能力。

重点： 如何将时间分段？ 发现问题是如何定向监控？
---首先清楚业务在后台的流程，如缓存、数据库等，通过改代码、模拟等来分段定位问题，这个需要积累，至少我要自己先写下前后端吧==

5.描述条件：预置条件

性能测试的预置条件 应该有对环境的描述、数据构造的描述，还应该包含我们对某个监控指标达到某个数值位置后所设计的预调整操作。

Ps:记录硬件、软件环境，然后调整有哪些？ 1.扩容等硬件支持 2.代码改进 3.思考别的手段

6.设计用例：测试用例

也就是我们常说的性能测试场景。它应该是在既定的环境中（也包含动态扩展后的环境）、数据、执行策略和监控下，所完成测试后的各个性能指标参数的变化，并判断结果是否符合预期。

ps1: 测试结果分析是很重要一环 关注 时间 容量 资源利用率等前后的变化、走向，得出自己的判断
ps2:如果把性能场景着重在数据和脚本准备上，相当于你就把测试重点放在了测试步骤上，而忽略了测试结果

7.测试执行

除了执行测试脚本，收集数据之外，还应该包含我们对现场对指标结果不正常的判断和调整，达到更准确测试结果的过程。

8.测试结果

除了分析通过不通过、并给出分析过程，我们还应该给出的结果是调优前后的时间、容量和资源利用率的对比图。

9.了解：性能变化图

image.png

10.明确：性能测试的业务指标和技术指标

image.png

image.png

11.思考：性能场景的分类

1、基准性能场景
单交易容量测试，就是说把每一个业务都压到最大TPS，得到一个基准数据，为后续对比提供依据。（我们现在正在做的）
2、容量性能场景
混合交易容量测试，这应该是把我们所有的业务根据一定的比例加到一个场景中，在数据，软硬件环境、监控等配合下，不断调优以期达到目标的测试过程。
3、稳定性性能场景
稳定性的核心是长时间运行，是指的在很长世间的高强度压力下能扛多久。（很少有这种测试。）
4、异常性能场景
这里需要非常注意关于异常的定义，这个异常通常就是宕各种架构上的组件，例如应用实例、主机、网络、缓存等等各种。（运维发起的演练有点类似，但是忽略了一点：较强压力场景下的各种“宕”。平时的调整策略在各种宕的时候没有问题，那么在较强压力下呢？资源能否更好的调节？有没有保证业务不崩溃的策略？……）

image.png

image.png

image.png