压测对抗流程

本文主要是介绍压测对抗流程，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

​1. 目的

为规范云端部门压测对抗演练过程，保障压测过程顺利、高效进行，故整理云端部门《压测对抗流程规范》，为部门的压测对抗演练活动的组织和执行提供参考。

2. 适用范围

云端部门内部所有压测或对抗活动。

3. 角色职责

●测试方：是指在压测过程中承担“压测方”角色的一方。主要负责在压测过程中模拟线上场景，对被压测对象施加压力。一般为测试工程师担任。

●业务方：是指在压测过程中承担“被压测方”角色的一方。一般为业务团队的开发工程师担任。

4. 压测对抗流程

​

4.1 准备阶段

4.1.1 确定压测对抗目标

1、来源

压测对抗目标来源有两种：

●部门压测需求

● 业务内部需要

2、压测对抗的主要目标

压测对抗的主要目标是得出压测对象的基线值、稳定性等性能情况。参考指标如下：

1) 并发或压力：用户数、并发数、数据量；

2) 性能指标：QPS、响应时间等；

3) 稳定性指标：降级、限流熔断；

4) 资源耗费情况：CPU、内存、硬盘、带宽等。

3、确定压测对象和具体目标

开发工程师根据压测对抗目标，与测试工程师一起分析、确定压测对象和具体的压测目标。

4.1.2 制定压测对抗方案与计划

由测试工程师根据确定的压测对象和目标，与开发工程师共同讨论和确定压测对抗方案与计划安排。

压测对抗方案与计划包括以下内容：

1、压测对象与目标

2、测试环境介绍

包括硬件环境、软件环境、网络环境等。

硬件环境需说明采用的机器配置参数、个数；软件环境需说明使用的软件版本等内容。

3、测试场景

明确压测对抗场景。包括场景介绍、场景详情、压测结果预测。其中，场景详情中，要包括测试时间、场景指标（如QPS、长连接等）。必要时，说明不同场景的机器配置（若有不同）、配置等场景指标参数。

选择压测对抗场景时，要尽可能还原实际业务场景，拟合线上数据曲线，提供可靠数据参考。业务场景介绍，尽可能提供接口及接口调用的时序关系图表。

压测对抗场景一般包括正常场景和异常场景两种，并提供相应场景的预测说明。

4、测试计划

包括压测对抗全过程各步骤、负责人以及计划时间安排等。

方案与计划确定后，测试工程师组织评审或确认。评审通过后，测试工程师将文档提交部门（过程改进）进行归档。

4.1.3 测试环境与数据、用例准备

压测对抗方案与计划确定后，测试工程师和开发工程师开始测试环境与测试数据的准备工作。

1、测试环境准备

开发工程师负责测试环境准备。包括机器、网络、应用配置，以及测试环境运行的基础数据准备。

●测试环境尽可能模拟线上运行环境。如功能、硬件配置、所安装的软件版本保持一致，充分考虑当次测试涉及的链路与各种可能场景。

●测试环境尽可能独立。避免测试环境被占用，影响测试进度及测试结果，比如设备连网后，如果其他开发或测试也在共用。

测试环境准备完成后，由测试工程师对测试环境进行验证。确保测试环境能够达到预期压测需求。

●软件状态是否稳定；

●被测功能点是否正常、稳定，且不再进行大的调整；

●软件部署方式、硬件配置是否与线上环境一致；

●测试环境是否独立。

2、压测数据和用例准备

测试工程师负责压测数据和压测用例的准备。本活动可以与测试环境验证并行进行。准备压测对抗使用的数据，包括系统用户数据、业务数据等。

1）数据真实性：尽可能准备与真实业务执行相一致的初始数据；不得使用真实客户或用户信息及数据作为测试数据。

2）数据规模：尽可能与线上环境一致。

3、压测用例准备

由测试工程师编写测试用例，根据需要编写或录制测试脚本，并进行调试。

4.1.4 模拟压测

测试环境、压测数据与用例准备完成后，测试工程师根据压测对抗计划组织模拟压测对抗，预演压测场景，以尽早发现本次压测对抗过程可能会出现的问题及其他意外情况，保证正式压测能够顺利进行。

考虑压测成本，模拟压测阶段可以采用最低单元机器配置进行模拟。

4.2压测对抗执行阶段

4.2.1 正式压测准备

正式压测开始前，根据压测对抗方案，进行正式压测机器扩容和环境调试，以保障正式压测环境达到预期压测对抗需求。

4.2.2 执行压测场景

执行压测对抗时，要暂停与本次压测对抗内容无关的系统及服务，保障压测环境单独运行。

4.2.3 压测过程记录与结果分析

1、压测对抗过程记录

压测对抗过程中，测试工程师和开发工程师均要及时记录各场景信息及对抗过程性能指标数据。

场景信息包括实际压测对抗时间、连接数、QPS等场景指标信息。压测对抗过程性能指标包括：

1）主机硬件指标：如CPU使用率、内存利用率、磁盘I/O、网络带宽等；

2）服务器指标：CPU和内存利用率、磁盘空间、IOPS、当前总连接数、网络流量等；

3）业务系统事务指标：并发用户数、响应时间、错误率、吞吐量等。

2、压测对抗结果分析

根据压测对抗过程记录与指标情况，分析压测对抗结果与预期的符合程度。若压测对抗结果与预期产生偏差，则需重点分析产生偏差的原因。必要时，进入性能调优阶段。

若压测对抗结果符合预期，或达到准出条件，则可以继续执行下一对抗场景。

4.2.4 性能调优

若对抗结果与预期产生的偏差，可以及时进行性能调优，则可以在压测过程中进行调优后，重新进行该场景的压测对抗，直至达到预期压测对抗目标。

1、开发工程师进行性能问题的定位，并进行程序修改；

2、必要时，开发工程师可协调运维工程师、数据库工程师和中间件系统工程师调整系统参数。

其中，调优过程中，需要注意：

1、测试工程师人员要与开发工程师一起参与性能优化与问题定位；

2、性能调优不影响原有功能；

3、开发工程师负责人确认当前系统的指标满足需求，作为性能基线备案。

若偏差原因一时难以定位，或调优措施在压测对抗过程中较难及时落实，则可以进行充分记录，继续执行下一对抗场景。具体问题在本次压测对抗结束进一步排查或解决。

4.2.5 压测对抗准出

所有计划场景执行完毕后，则可以结束本次压测，进入压测收尾阶段。

若存在个别场景无法按照原计划进行压测，则需说明场景未压测原因。

4.3压测对抗收尾阶段

正式压测对抗活动结束后，测试工程师和开发工程师分别整理“压测方”和“被压测方”的测试结果，并对测试过程指标和结果进行充分描述和分析。

在开始整理前，双方需就整理描述的各场景、时间、指标、现象（及其发生的时间）及结论达成一致，以免造成测试分析内容不一致。

最后由测试工程师汇总、统一测试过程与结果分析内容，输出《压测对抗报告》，提交部门过程改进归档。

​

这篇关于压测对抗流程的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！