前面两篇笔记介绍了如何快速上手压测项目以及压测前准备测试环境和测试数据的一些方法。
这篇文章,我想分享下关于压测平台功能设计和技术实现方案的一些技术笔记内容,内容主要来源于两方面:
- 18年我所在性能团队使用的压测平台技术实现细节;
- 20年后我带稳定性团队时我们开发的全链路压测平台的功能设计和技术方案;
为什么需要压测平台?
从实际工作场景出发,如果只有一两个人做性能测试工作,那其实没必要开发专门的压测平台,原因如下:
- 成本问题:开发压测平台,前期需要投入至少1-2个专门的人力,且需要长期维护;
- 效率问题:人数少,基本相当于压测任务并不太多,脚本管理数据管理这些可以通过本地上传到服务器,服务器只需要按照业务域和压测节点,建立对应的文件目录,然后有个crontab的定时任务来清理即可;
- 协作问题:人数少其实不太需要平台来解决规范和流程问题,协作的事情几句话口头就可以沟通解决;
对于压测平台,或者说各种测试平台,其实很多同学有个误区就是:平台各种高大上牛逼,但往往忽略了开发和维护以及学习使用平台本身的成本。
测试平台的目的是:通过平台提供标准化操作,将不同个体差异通过流程化的方式约束起来,减少重复造轮子和轮子之间差异导致的排查和解决问题的成本,进一步提高人效。
毕竟工作最终是结果导向的,如果没有更高效的解决问题,那平台最终会成为沉没成本。
假设现在你想拥有一个压测平台,那我个人觉得最起码需要满足如下几

文章讨论了压测平台的需求背景,指出在多业务线、快速迭代和大规模团队中,压测平台能提高效率和标准化。平台应具备易用性、数据持久化、低维护成本、协同支持和扩展功能。文中提到了用例管理、压测执行、实时监控等功能模块,并分享了mock和日志采样等技术实现方案。
最低0.47元/天 解锁文章
2万+

被折叠的 条评论
为什么被折叠?



