目录
为什么需要压测平台？
从实际工作场景出发，如果只有一两个人做性能测试工作，那其实没必要开发专门的压测平台，原因如下：
- 成本问题：开发压测平台，前期需要投入至少1-2个专门的人力，且需要长期维护；
- 效率问题：人数少，基本相当于压测任务并不太多，脚本管理数据管理这些可以通过本地上传到服务器，服务器只需要按照业务域和压测节点，建立对应的文件目录，然后有个crontab的定时任务来清理即可；
- 协作问题：人数少其实不太需要平台来解决规范和流程问题，协作的事情几句话口头就可以沟通解决；
对于压测平台，或者说各种测试平台，其实很多同学有个误区就是：平台各种高大上牛逼，但往往忽略了开发和维护以及学习使用平台本身的成本。
测试平台的目的是：通过平台提供标准化操作，将不同个体差异通过流程化的方式约束起来，减少重复造轮子和轮子之间差异导致的排查和解决问题的成本，进一步提高人效。
毕竟工作最终是结果导向的，如果没有更高效的解决问题，那平台最终会成为沉没成本。
假设现在你想拥有一个压测平台，那我个人觉得最起码需要满足如下几个条件：
- 业务线多，版本迭代快（需求驱动）；
- 测试团队个体间的技术差异比较大（技术驱动）；
- 性能需求较多，线上稳定性问题频发（问题驱动）；
- 技术团队达到一定规模，做压测的人比较多（效率驱动）；
压测平台功能设计思路
聊完了关于压测平台是否必须以及要解决的问题，这部分聊聊一个可用的压测平台要满足哪些条件。
- 简单易用：平台学习和使用成本低，操作简单快捷；
- 数据持久化：测试脚本&测试数据&测试结果持久化，便于追溯历史记录；
- 维护成本低：满足开箱即用，和外部系统可以交互，出问题也有高效的技术支持；
- 支持多人协同：可以满足不同团队的人使用，快速开展压测工作且不会交叉影响；
- 便于配置管理：对压测集群、压测组件和一些配置项的管理便捷高效，不用手敲太多命令；
- 完善的施压支持：支持一定的高并发能力，压测集群可扩展，支持多协议和基本的自定义扩展能力；
看完上述条件，我们对压测平台的功能模块，就有了比较明确的要求。
- 用例管理：一个压测项目可以创建多个压测任务，任务=用例，用例包含压测脚本、压测数据和插件；
- 压测执行：支持手动和定时执行压测，可以配置运行参数、可以选择多个压测节点、支持同时运行多个压测任务；
- 实时监控：压测过程中实时展示TPS、RT、请求数、错误率等核心指标，并支持按时间段选择和计算；
- 压测结果：压测结束后整个任务的压测结果可以进行详细的展示，比如TPS、ART、90/95/99RT、成功/失败请求数、错误日志等；
- 配置管理：比如压测节点参数变更、绑定host、插件上传更新等；
- 扩展功能：比如支持mock、openAPI、造数工具、三方库兼容等；
看完了上面的条件和功能模块要求，那么一个基本的压测平台，要具备哪些具体的功能呢？请看下图：
PS：此图仅供参考，并不代表要完全有这些功能，根据自己的具体情况设定。
压测平台技术实现方案
接下来聊聊压测平台部分功能的技术实现方案。
压测平台的技术架构其实关键字搜索已经很多了，这里我也不想多费笔墨，在其他人的基础上微创新。
我想分享一些具体功能模块的技术实现方案，供大家参考。
mock功能
日志采样功能
PS：该功能是基于jmeter为压测工具实现的，仅供参考。
总结
感谢每一个认真阅读我文章的人！！！
我个人整理了我这几年软件测试生涯整理的一些技术资料，包含：电子书，简历模块，各种工作模板，面试宝典，自学项目等。欢迎大家点击下方链接免费领取，千万不要错过哦。
