希望大家指出我的不足之处。
希望能帮我点上一颗 star，多谢多谢。

github：[https://github.com/zyanycall/stressTestPlatform]

背景

云压测平台在测试领域并不是陌生的名词，简单来说就是在网页/移动端执行压测操作，同时压力机是部署在云端。
如压力节点机在云南，那就是云南产生压力，在北京，那就是北京产生压力。
现阶段云压测平台挺多的，我了解到的就有收费的如阿里云的 PTS、XMeter，还有一些开源的，如 nGrinder、云集微店的 TITAN。

云压测平台要解决什么问题

1. 压测任务和业务的关系：隶属层级。
2. 压测任务和测试人员的关系：权限管理。
3. 摒弃繁琐的手工操作，提高效率，完全线上操作。
4. 实时查看结果：集成监控平台。
5. 历史压测数据留存：在线测试报告。
6. 统一压测工具，统一压测标准。

云压测平台为什么要自己实现

收费的就不提了。
开源的各种压测工具，总会面临各种问题：

1. 脚本语言写的压测内核，创造压力的性能就不够。
2. 冷门的压测软件，测试结果难以服众。
3. 软件用的人少，容易出问题和出了问题不好解决。
4. 热数据图形监控都不好。
5. 系统较庞大，占用资源较多。
6. 是否便于推广，真正减轻工作量。

同时，平台实现之后还有好处：

1. 和其他测试工具/平台做集成对接。
2. 和其他部门的工具/平台做对接。
3. 全链路性能测试的起点，公司性能保障的开端。

实现语言及内核

开发语言

其实平台本身使用什么语言开发都可以，但是由于压力内核选择使用了 Jmeter，为了要调用 Jmeter 的 API，平台也选择使用 Java 开发。

Jmeter 的优缺点

优点不详述了，最重要的还是顶级项目开源，社区活跃，Java 语言性能好和跨平台。

说下缺点，我目前发现的有：

1. 代码还是庞大冗余，但这一定程度上保证了软件稳定性。
2. 至少测试报告的核心开发，水平一般（我有实锤，要反驳的别在这吵）。
3. Jmeter 的 API 设计的一般，调用时较麻烦。
4. 分布式压测架构存在中心节点瓶颈，总压力上不去。
5. 用大文件生成测试报告，时间较长。

所以国内已经有余力的公司（阿里）是在改造 Jmeter，就是取其精华去其糟粕了。

Jmeter 压测启动的方式

• 脚本执行

平台根据前端的操作，自动拼接出一行可执行的命令，然后在指定服务器上执行这段脚本。
相当于是手工敲的命令平台帮着拼接和回车执行了。
即便是前端来生成测试脚本，也可以先保存成 jmx 文件，再脚本执行。
特点是平台和 Jmeter_Home 完全分离，带来的：

1. 平台代码可以不用 Java 写了，什么语言写都可以，仅仅是拼装命令。
2. 毕竟是脚本执行，Jmeter 随意切换版本。
3. 平台和 Jmeter 可以不部署在同一台服务器上，即不是相同的进程内了。
4. Jmeter 挂掉不影响平台运行。

• 程序内引用 Jmeter 的 API 来压测执行

平台代码直接调用 Jmeter 的 API。
相对脚本执行的实现：

1. 平台代码需要使用 Java 来写，毕竟要引入 Jmeter 的 jar 包了。
2. 同样支持各种版本的 Jmeter，但是不灵活。
3. 同平台在一个进程内产生压力，Jmeter 如果挂了，平台也危险，因为可以线程产生压力。

对比脚本执行的好处：

1. 脚本执行得到的返回仅仅是窗口返回数据，太单薄且不稳定。
2. 可以定制 Jmeter 功能，比如自实现压测监控数据。

• 补充

1. Jmeter 成名已久，程序还是很稳定的，至少 master 主节点我没遇到因为压测导致的崩溃。同时基于 JDK 的线程启停都很顺畅。
2. 网上之前有声音说 Jmeter 2 系列版本性能更优，我认为是有一定依据的，至少代码量没现在这么臃肿，不过我自测的情况是，4 版本和 2.13 版本的压测性能差不多。
3. 由于 Jmeter 3 版本才开始支持测试报告生成，所以我默认使用 Jmeter 4 版本的 API。
4. Jmeter 的 API 随着版本更新有变化。

我的平台两种方式都支持，当然推荐是引用 Jmeter 的 API 方式启动，可配置。

从需求看实现

核心需求

• 网页/移动端可以启动压测和停止压测。

最最基本的要求了。

• 压测数据可以在线实时监控。

如果没有在线实时监控，那和 Jmeter 自身的脚本压测甚至和 AB 等工具，就没啥区别了。

• 可能生成测试报告，最好在线查看，最少也要导出查看。

Jmeter 3 开始支持测试报告，这也是选择 Jmeter 的原因之一。

• 支持分布式压测

即云压测的基础。

• 权限管理

权限管理是平台面向全公司/全网的基础。

• 业务层级展示

压测需要和具体业务有关系，这个关系在平台上要可以设置。

• 压测热数据实时监控要可控

图形监控的功能要非常丰富，比如放大缩小等。

• 删除，下载等操作

删除是让系统文件空间可控。下载是移动办公的基础。

• 分布式节点管理

分布式压测的衍生需求，有了分布式节点管理，能大大减轻手工操作。同时各种提示非常人性化。

抛弃的需求 1：在线生成测试脚本

这曾经是我比较纠结的地方。

1. 测试脚本要适应各种场景，各种协议，至少 HTTP(S)，TCP 协议要有。
2. 各种协议就要有不同的输入页面。
3. 需要前端输入压测指标数据，如步长，虚拟用户数等等。
4. 断言的实现。
5. 前端录制脚本。

还有很多很多。
阿里的 PTS 是让在平台上写脚本代码实现最核心的功能包括断言，然后页面录入压测指标数据。
这样做如果遇到复杂的性能测试要求，问题很大：

1. 调试困难，不解释了，在线调试代码，尤其移动端，画面太美。
2. 参数化，测试数据关联要怎么破，尤其测试的请求特别多的情况。
3. 高昂的学习成本，这么复杂的脚本代码我还搞什么工具推广，工具面对的是小白怎么办。

所以我的选择很简单，上传 Jmeter 的脚本，同时上传参数化文件。
好处不说了，详细的后续会介绍。

抛弃的需求 2：在线监控服务器指标

简单来说，就是平台可以实时监控到服务器的网卡，CPU，内存，磁盘，甚至日志等等。
我放弃的原因：

1. 自研不如直接用开源。
2. 运维和阿里云都有监控，功能重复。
3. 自研性价比不高。

其实这个话题很大，比如监控到什么程度才算合格，能否做到智能化监控与测试报告的连接，服务器指标数据和服务器日志的结合展示分析等等。
在没想好怎么做之前，我的选择是抛弃这部分需求，做不好不如不做。

结尾

平台我一直在深度使用，挺好用。
平台代码当前也比较稳定。

平台创造压力的能力和 Jmeter 的内核相同，无论是单机还是分布式，同样的支持 Grafana+InfluxDB。

后续我会慢慢介绍这个平台，当然也可以直接看我的代码，我自认为代码注释，结构等，还是很清晰的。

压测引擎链接：

基于 Jmeter 的轻量级云压测平台的原理与实现 (二)：压测引擎