性能测试技术笔记(三)：如何设计一个压测平台

• 18年我所在性能团队使用的压测平台技术实现细节；
• 20年后我带稳定性团队时我们开发的全链路压测平台的功能设计和技术方案；

为什么需要压测平台？

• 成本问题：开发压测平台，前期需要投入至少1-2个专门的人力，且需要长期维护；
• 效率问题：人数少，基本相当于压测任务并不太多，脚本管理数据管理这些可以通过本地上传到服务器，服务器只需要按照业务域和压测节点，建立对应的文件目录，然后有个crontab的定时任务来清理即可；
• 协作问题：人数少其实不太需要平台来解决规范和流程问题，协作的事情几句话口头就可以沟通解决；

1. 业务线多，版本迭代快（需求驱动）；
2. 测试团队个体间的技术差异比较大（技术驱动）；
3. 性能需求较多，线上稳定性问题频发（问题驱动）；
4. 技术团队达到一定规模，做压测的人比较多（效率驱动）；

压测平台功能设计思路

1. 简单易用：平台学习和使用成本低，操作简单快捷；
2. 数据持久化：测试脚本&测试数据&测试结果持久化，便于追溯历史记录；
3. 维护成本低：满足开箱即用，和外部系统可以交互，出问题也有高效的技术支持；
4. 支持多人协同：可以满足不同团队的人使用，快速开展压测工作且不会交叉影响；
5. 便于配置管理：对压测集群、压测组件和一些配置项的管理便捷高效，不用手敲太多命令；
6. 完善的施压支持：支持一定的高并发能力，压测集群可扩展，支持多协议和基本的自定义扩展能力；

1. 用例管理：一个压测项目可以创建多个压测任务，任务=用例，用例包含压测脚本、压测数据和插件；
2. 压测执行：支持手动和定时执行压测，可以配置运行参数、可以选择多个压测节点、支持同时运行多个压测任务；
3. 实时监控：压测过程中实时展示TPS、RT、请求数、错误率等核心指标，并支持按时间段选择和计算；
4. 压测结果：压测结束后整个任务的压测结果可以进行详细的展示，比如TPS、ART、90/95/99RT、成功/失败请求数、错误日志等；
5. 配置管理：比如压测节点参数变更、绑定host、插件上传更新等；
6. 扩展功能：比如支持mock、openAPI、造数工具、三方库兼容等；

压测平台技术实现方案

mock功能

日志采样功能