MeterSphere案例分享丨基于JMeter的性能测试方案演进之路

699次阅读

目前，我在公司的测试团队中担任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文件生成报告。

但是我们的外包同事居然没有压力机登录权限，这样我们只能一遍遍地上去帮助他们进行上传、执行和下载操作，并且发给他们结果。我们还需要负责调整脚本的项目结构，操心执行完后去取文件的时机。这样就导致我们的工作时间被严重碎片化，工作效率也被降低了。

如果我们向外包人员开放账号，也面临着新问题。操作的人太多，压力机里目录变得一片狼藉。简单来说就是一切有权限的目录，都会有各式的文件和文件夹，慢慢压力机磁盘也爆了，无人清理。

MeterSphere能够帮助我们做什么？

面对这样一个简单的问题，业界有很多的解决方案，我们也有自己的办法。

图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的使用感受

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的迁移功能。总的来说，持续发展的项目更值得我们花时间去适应，也会引导我们走更为主流的技术道路。