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

前面两篇笔记介绍了如何快速上手压测项目以及压测前准备测试环境和测试数据的一些方法。

这篇文章，我想分享下关于压测平台功能设计和技术实现方案的一些技术笔记内容，内容主要来源于两方面：

• 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、造数工具、三方库兼容等；

看完了上面的条件和功能模块要求，那么一个基本的压测平台，要具备哪些具体的功能呢？请看下图：

PS：此图仅供参考，并不代表要完全有这些功能，根据自己的具体情况设定。

压测平台技术实现方案

接下来聊聊压测平台部分功能的技术实现方案。

压测平台的技术架构其实关键字搜索已经很多了，这里我也不想多费笔墨，在其他人的基础上微创新。

我想分享一些具体功能模块的技术实现方案，供大家参考。

mock功能

日志采样功能

PS：该功能是基于jmeter为压测工具实现的，仅供参考。

如上就是我关于压测平台的一些工作实践笔记和个人思考。

下篇文章，我会聊聊关于质量度量的新看法，敬请期待。