图 1 内部实现的压测平台
目前，我在公司的测试团队中担任 Leader，团队成员 11 人，以外包居多。外包同事在工作中遇到最多的问题是权限受限的问题。我们每次在完成 SIT（System Integration Testing，系统集成测试）后，都需要按照集团要求对所测系统的一些接口进行性能测试，并且将报告给到集团验收。
我们使用的性能测试工具是 JMeter。“Best practices state that you shouldn’t run a load test from the GUI mode at all.”——按照 JMeter 的最佳实践，我们准备了不少压力机供测试人员到上面执行命令（-n -t -l），下载 JTL 文件生成报告。
但是我们的外包同事居然没有压力机登录权限，这样我们只能一遍遍地上去帮助他们进行上传、执行和下载操作，并且发给他们结果。我们还需要负责调整脚本的项目结构，操心执行完后去取文件的时机。这样就导致我们的工作时间被严重碎片化，工作效率也被降低了。
如果我们向外包人员开放账号，也面临着新问题。操作的人太多，压力机里目录变得一片狼藉。简单来说就是一切有权限的目录，都会有各式的文件和文件夹，慢慢压力机磁盘也爆了，无人清理。
面对这样一个简单的问题，业界有很多的解决方案，我们也有自己的办法。
图 1 内部实现的压测平台
我们做了一个简单的 Web 程序，把一个个小项目的性能测试脚本文件夹打包上传，拷贝到做了分布式配置的压力机上。外包同事在 Web 页面点击便可执行，这时配置好的控制机就会执行一个事先准备好的 Shell 脚本去跑这些传上去的 JMX，每一条上传记录执行后都会有 JTL 的 ZIP 包下载链接。这样一来，上述的基础问题便解决了。磁盘的清理加个定时任务应该也不是难事，但我们还是遇到了新问题。
每更换一次虚拟用户数，就需要将脚本下载下来修改一次。调试时我们习惯将虚拟用户数和循环次数都设置成 1，这样操作很容易带入压测环境。这也带来了很多 “下载 - 修改 - 打包 - 上传” 的反复操作，真的令人抓狂的！我们需要让 Web 程序能够在线修改上传的 JMeter 脚本。
但是一波未平，一波又起。我们的性能测试除了出报告，也是需要配合开发调优，我们需要让开发看到实时变动。既然我们一直都在用 Non GUI 执行，就不必再使用 JMeter 的 GUI 去实时呈现了，这样不仅有性能损耗，也不太好和现有的 Web 程序相集成。
“Backend Listener+Grafana+InfluxDB” 很香吗？实践下来也不尽然。为每一次压测生成对应的 Grafana 展示模板并作为 URL 分享并不是一件容易的事。再看我们这个简单的性能脚本分发器，还缺乏项目组织、定时设置、日志查看等功能。如果持续投入时间去完善它，哪还有时间写代码呢？是时候找一个开源产品了。
选择开源产品的套路很多人都懂，比如开源许可协议、活跃度、开发语言等等。常年混迹于 GitHub，我们发现，GitHub 里开发框架和业务项目居多，优秀的国内开源测试平台却凤毛菱角。
2020 年 5 月之前，Java 系的看的下去的貌似只有 “LF”，阿里也有一款基于 AI 的用例膨胀的工具。国外的 Taurus 项目解决了我们根据场景修改 JMeter 脚本的痛点，但如何让它自身图形化、且变得易用又成为了一个新的课题。BlazeMeter 似乎是集大成者，但是我司网络访问真的好卡，而且开源版不直接在企业环境内部署。
我们希望能找到一款目前能解决我们大部分痛点，遇到新的痛点我们能在此基础上自行解决，发生问题我们能自行定位处理的开源测试平台。MeterSphere 开源持续测试平台正是我们所需要的。
从 2020 年 6 月 MeterSphere 发布的第一个版本，我们就开始试用，并阅读了其代码。MeterSphere 使用的是当下主流的开发框架（Vue.js+Spring Boot+Docker），建立在著名开源接口、性能测试工具 JMeter 之上，没有丝毫地 “藏私”，系统里的每一个组件都能找到源代码，包括它们使用到的 Dockerfile。
MeterSphere 项目的第一个版本发布后，我们完成了对它调研。GPL v2.0 开源许可协议赋予了这个开源项目充分的使用和修改自由，短时间内，这个项目在 Github 上的 Star 数量已经突破了 2500 个，项目团队也在持续展开规律性的迭代，每个月你都能收获一系列想要的功能。如果你是 Java 系，MeterSphere 项目采用的技术非常主流，代码也比较工整，你可以上手修改。
第一次搭建部署我们就遇到了问题，主要的原因是我们没有太多使用 Docker Compose 的经验。我们的风格是要完全掌控我们所使用工具的每一个细节，为此我们放弃了 MeterSphere 一键安装的部署方式，单独编译每个组件，并使用公司已有的中间件（Nginx、ZooKeeper、Kafka、MySQL）来部署 MeterSphere，并且把我们一直使用的 JMeter 做成 Docker 镜像供 MeterSphere 进行调度。
这样每个组件的日志，以及运行方式我们都能了如指掌，出现问题也能快速定位，以确保平台一直可用。遇到搞不定的问题，也能在微信交流群中提供更精准的信息请 MeterSphere 研发团队的同学帮忙解决。
图 2 MeterSphere 平台架构
在我们使用第一版 MeterSphere 之前，我们做了简单的改造，屏蔽了用例管理和 Bug 跟踪功能。这样做是考虑到上线了就会有人使用，屏蔽暂不使用功能是为了降低运维成本和解释成本。我们将执行时间从分钟改为了秒，也修改了一些 Bug（这些 Bug 在 MeterSphere 后续的版本中已经修复）。我们就这样愉快地开启了开源持续性能测试之旅，它完美解决了我之前所提到的种种问题。
伴随着 MeterSphere 项目的持续演进，我们基本上是 MeterSphere 每发布一个新版本都会进行升级。因为 MeterSphere 的接口测试功能几乎每个版本都在完善（从 Dubbo 到 TCP，再到 SQL），这对我们很有意义。我们的接口自动化测试用例都是以 JMeter 脚本的形式维护在 SVN 中，每次需要再次执行时都需要花费时间去调试。很多脚本都不知道是从何时开始就已经不可用，用这种维护方式做持续集成测试并不如人意，报告也需要额外处理。
MeterSphere 集中化、界面化、场景化接口测试用例的方式其实更为主流。而且 MeterSphere 一系列界面配置操作后内部其实还是一个个 JMeter 文件去跑接口测试（使用 JS 生成的 JMX），你从 JMeter 接口测试到 MeterSphere 接口测试的过渡从原理与机制上是顺滑的。而且在后面的版本，MeterSphere 还计划推出 JMeter 直接上传为 MeterSphere 接口测试用例的新功能。目前，MeterSphere 已经支持了 Postman 的迁移功能。总的来说，持续发展的项目更值得我们花时间去适应，也会引导我们走更为主流的技术道路。
MeterSphere 的每个版本都有惊喜，易用性也在不断加强。我总在期待却不知道如何建议，如果非要说点什么，那么我简单想到了以下两点：
我们还需要与 MeterSphere 开源持续测试平台不断磨合并深入使用。MeterSphere 项目成长得很快，我们还有很多东西没有来得及使用和学习，我们要加快脚步！
注：本文作者为某公司高级测试工程师李生。
