Menu Close

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

目前,我在公司的测试团队中担任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的迁移功能。总的来说,持续发展的项目更值得我们花时间去适应,也会引导我们走更为主流的技术道路。

期待与建议

MeterSphere的每个版本都有惊喜,易用性也在不断加强。我总在期待却不知道如何建议,如果非要说点什么,那么我简单想到了以下两点:

■ 报告与图表不如BlazeMeter精细、丰富;

■ 日志类的文件存到了MySQL中,不适合查询。下载是需要先读mysql,文件大时非常卡,感觉Elastic Search和InfluxDB更合适一些。

我们还需要与MeterSphere开源持续测试平台不断磨合并深入使用。MeterSphere项目成长得很快,我们还有很多东西没有来得及使用和学习,我们要加快脚步!

编者注:本文作者为高级测试工程师李生。

Posted in 持续测试, 案例