一、压测流程

可参照上篇压测对抗流程

二、压测需求

需要明确需要压测的环境

需要压测的接口，其中包含接口的入参

需要明确接口的预计qps

需要明确线上机器配置

三、压测准备

3.1、服务端开发准备：

1.根据需要测试的接口，决定需要部署哪些相关依赖服务；

2.测试接口对应的服务、接口；

3.相关配置；

4.相关数据库；

5.需要的机器整理，其中包含机器的配置，需要几台机器。

3.2、前端开发准备：

1.测试的接口和服务应用；

2.域名；

3.需要准备的机器；

4.根据需要测试的接口，决定要部署哪些相关依赖。

3.3、测试准备：

1.准备压测的测试方案和测试计划；

2.通过接口确认压测的场景，其中包含每一个接口需要测试的场景，预计接口需要的压测线程。通过测试场景确认测试方案；

3.根据测试计划准备测试脚本；

4.根据每一个接口的情况准备对应的测试场景；

5.根据测试场景准备需要的测试数据。其中会包含登录账号相关，接口返回有数据相关等。建议可以将线上的数据库直接copy一份到压测环境中；

6.测试申请施压机器的权限；

7.施压机上准备压测需要跑的工具。

四、压测方案和计划

4.1、编写压测方案和计划

1.压测方案和计划的模板查看；

2.在测试方案中将信息进行整合和处理，其中包含需要测试的接口，每一个流程对应的时间节点；

3.测试方案和测试计划确定后需要跟对应的人员（包含服务端开发、前端开发、测试人员、前端运维、服务端运维等）进行评审，确认最终的流程的时间节点；

4.根据测试计划中的时间输出对应的结果。其中包含服务券和前端代码部署、机器申请和部署、测试的测试脚本输出。

4.2、测试编写测试脚本

1.确认测试接口是否依赖于登录，是否需要登录信息；

2.确认需要测试的接口属于atop接口还是http接口；

3.确认需要编写哪些脚本；

4.调试测试脚本；

5.自动化脚本或者jmeter脚本编写，可查看jmeter使用。

4.3、测试验证测试脚本

1.在日常环境对测试脚本进行验证，确定脚本能够正常跑；

2.对测试接口需要的准备数据进行整理；

3.对测试接口需要的断言进行准备。

4.4、施压机上对压测环境的验证

1.将测试脚本中对应的域名和数据等换成压测环境的数据；

2.在压测环境中对环境和脚本进行验证；

3.与开发调试压测环境中的问题，并调试脚本问题。

4.5、在压测环境中进行模拟压测

1.使用一个接口进行模拟压测，确认需要收集的图标信息、结果是否满足预期；

2.确认施压机和压测机器是否正常，是否需要更换；

3.确认需要采集数据的采集；

4.确认断言方式是否ok。

五、压测开始

5.1、正式压测：

1.开始正式压测，将各路人马（开发、运维、DBA等人进行封闭压测）；

2.针对压测的接口进行决定接口压测的顺序；

3.压测中需要逐渐增加线程数量；

4.在压测过程中观察实时的qps和报错相关，并通知开发进行查询对应的接口响应时间；

5.根据接口的链路分别通知对应的人员进行查看压测过程中其接收时间、响应时间等。

5.2、当次压测结果分析：

1.当次接口压测结束后，对结果进行分析，确认压测后的qps、报错率、10%、50%、90%用户的响应时间；

2.开发寻找对应浪费的时间，当场进行优化后，可以针对此接口在进行压测，以便找到性能瓶颈问题；

3.压测结果最终是需要找到最大的qps和开始出现报错的并发数；

4.当前线程数对应的线程数，如没有达到对应的qps要求，可根据qps进行决定增加多少线程数。若线程数增加后，qps没有提高，大致已经找到qps的极限。

5.3、稳定性测试：

1.找到比较稳定的qps对应的线程数，进行稳定性测试；

2.稳定性测试与压测的区别在于持续的时间；

3.可通过稳定性测试进行观察持续性调用接口时系统的表现；

4.后续可根据稳定性测试和压测的qps进行计算出对应的每日能够承受的日活量。

六、压测后测试报告整理

1.测试报告整理

a.对此次压测进行整理测试报告；

b.测试报告中需要记录压测对应的时间节点、此次压测对应的qps、此次压测中的错误率；

c.此次压测10%、50%、90%用户的响应时间；

d.压测过程中出现的毛刺时间节点；

e.压测过程中曲线不正常对应的原因；

f.此报告需要开发、测试同步进行整理；

g.测试记录压测数据和图标；

h.开发记录对应系统的cpu使用率、负载、数据库负载等信息；

i.测试报告模板。

作者：weixin_45879397

原文链接：https://blog.csdn.net/weixin_45879397/article/details/123011905