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

MeterSphere 小助手 · 2020年11月24日 · 最后由 MeterSphere 小助手 回复于 2020年12月02日 · 233 次阅读

目前,我在公司的测试团队中担任 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 项目成长得很快,我们还有很多东西没有来得及使用和学习,我们要加快脚步!

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

共收到 4 条回复 时间 点赞

智慧科技不是解散了吗?

仅楼主可见
仅楼主可见

https://github.com/metersphere/metersphere
在 GitHub 仓库最下方有交流群二维码

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册