Q：MeterSphere 和 JMeter 的主要区别是什么？

根据 51Testing软件测试网的调查报告，2009 年时仅 6% 的受访者采纳 JMeter 工具。但是到 2019年，62% 的受访者采纳 JMeter 作为性能测试工具，已经成为目前最主流的性能测试工具。 除了性能测试以外，也有很大部分用户在使用 JMeter 进行接口测试。既然有了 JMeter，为什么还需要 MeterSphere？我们将从规模扩展性、测试报告、测试管理和多人协作这四个方面详细分析 JMeter 存在的问题，及 MeterSphere 带来的变化。

  1. 规模扩展性
    • JMeter 存在的问题
      • 并发数超过单节点承载能力时，多节点环境配置、维护复杂
      • 默认配置下无法并行运行多个测试，需要更改配置启动额外进程
      • 难以支持云环境下测试资源的弹性伸缩需求
    • MeterSphere 带来的改变
      • 压测执行节点支持一键安装
      • 多个项目、多个测试可并行使用同一个测试资源池（最大并发数允许情况下），提高资源利用率
      • 对接云平台 API 根据并发数自动启动、释放压测执行节点
  2. 测试报告
    • JMeter 存在的问题
      • 测试报告需要在测试执行完成后单独生成，实时报告需要通过第三方方案实现
      • 测试报告不能很方便地进行共享
      • 没有多次测试结果之间进行比较的功能支持
    • MeterSphere 带来的改变
      • 近乎实时的性能测试报告展示
      • 团队共享的测试报告，方便团队成员进行协作分析
      • 历史测试报告随时查看，多次测试结果可以快速比较
  3. 测试管理
    • JMeter 存在的问题
      • 如何存放这些脚本可以让整个团队很方便地使用和修改
      • 针对不同产品、项目的脚本如何进行区分
      • 如何控制不同成员对不同测试脚本的访问权限
      • 同一个测试脚本的更新修改如何进行追踪回溯
    • MeterSphere 带来的改变
      • B/S 架构的测试平台，测试脚本统一存放在数据库，团队成员可以很方便的进行共享和协作
      • 多租户、多项目的管理模型可以很好的将测试资源进行分隔
      • 灵活的角色配置，根据需求为团队成员分配不同权限
      • 针对测试脚本的修改、执行可以提供完善的记录跟踪
      • 天然支持测试脚本与测试用例的关联， 用户在进行手工测试及接口/性能测试时体验更加一致，测试报告更加完整
  4. 多用户协作
    • JMeter 存在的问题
      • C/S 架构的测试工具，所有需要使用的人都需要在本地进行安装
      • 没有内置的租户、用户管理能力，测试脚本、测试报告不能很方便地进行共享
    • MeterSphere 带来的改变
      • B/S 架构的测试平台，只需一个现代浏览器加可以使用到平台提供的所有功能
      • 灵活的多租户、多项目管理模型，租户间测试用例、测试脚本和报告可以有效隔离，租户内方便共享协作

Q：是否支持/如何支持分布式的性能测试？

MeterSphere 通过在测试资源池中添加多个测试执行节点的方式来支持分布式的性能测试。在我们向一个测试资源池中添加节点时，除了节点的 IP、端口信息外，还需要根据该节点的机器规格，配置该节点可以支持的最大并发数。当我们在执行性能测试的过程中选择了某个测试资源池时，MeterSphere 会将本次性能测试定义的并发用户数，按照所选测试资源池的节点支持的最大并发数进行按比例拆分，在测试开始执行后，每个测试执行节点会将测试结果、测试日志等信息输送到执行的 Kafka 队列中，MeterSphere 中的 data-streaming 组件会从 Kafka 中收集这些信息并进行汇总处理。

例如当我们在系统中存在一个如下配置的测试资源池，并选择该测试资源池执行一个 10000 并发用户的性能测试时，node1 及 node2 将各分配 4000 个并发用户，node3 将分配 2000 个并发用户。

测试资源池

Q：重启安装服务器后，如何启动 MeterSphere 相关组件？

MeterSphere 在安装过程中没有配置 docker 及其相关容器的自启动。当用户重新启动部署服务器之后，需要手动启动 docker 服务及 MeterSphere 相关容器。

  1. service docker start
  2. msctl start
  3. msctl status

Q：如何向测试资源池中添加节点？

首先需要在要添加的节点上部署 MeterSphere 的 node-controller 组件，安装方式参考本文档「在线安装」或「离线安装」章节内容，在执行安装脚本前，修改 install.conf 文件中的 MS_MODE 字段的值为 node-controller 后执行安装脚本。

安装完成通过查看组件状态是否正常

  1. msctl status

当组件状态正常后，使用管理员账号登录 MeterSphere，在「系统设置」-「系统」-「测试资源池」页面添加或编辑已有测试资源池，在弹出的页面中增加一个节点，IP 地址为要添加的测试执行节点的 IP，端口默认为 8082，最大并发数根据测试执行节点的机器规格进行配置。

节点添加完成点击确定后系统将对节点状态进行检查，若测试资源池为可用状态则说明该测试资源池及其中的节点可以正常使用。若提示校验不通过，请登录测试执行节点通过如下命令查看组件日志。

  1. docker logs ms-node-controller

Q：执行性能测试时提示“Kafka 不可用，请检查配置“如何解决？

系统在执行性能测试之前，会先检查安装系统时配置的 Kafka 地址是否可用。当提示该信息时，表明 MeterSphere 无法正常连接到 Kafka，可以通过以下方式进行排查定位。

排查思路

Kafka 不可用排查

检查 Kafka 是否正常运行

如果在安装时使用的外部的 Kafka，请联系相关人员进行排查，检查 Kafka 服务是否正常；如果安装时使用 MeterSphere 默认配置进行安装，使用了自带的 Kafka 服务，请通过如下命令进行排查。

  1. # 检查各组件的运行状态
  2. msctl status
  3. # 若 Kafka 容器不处于 `healthy` 状态，查看 Kafka 日志进行进一步排查
  4. docker logs kafka

检查 MeterSphere 到 Kafka 服务的网络连接

若 Kafka 服务状态正常，请通过如下命令检查 ms-server 容器是否能正常连接到 Kafka 服务

  1. # 检查 ms-server 是否能正常访问 Kafka 服务
  2. [root@meter-prototype ~]# docker exec ms-server nc -zv ${kafka 服务 IP} ${kafka 服务端口}
  3. kafka (172.23.0.5:19092) open

如果在安装时使用的外部的 Kafka，请联系相关人员进行排查，检查 MeterSphere 部署服务器到 Kafka 服务之间的网络连接是否正常，是否有防火墙、安全组等安全策略的影响；如果安装时使用 MeterSphere 默认配置进行安装，使用了自带的 Kafka 服务，请检查 MeterSphere 部署服务器上的防火墙配置，是否放通了 Kafka 的服务端口（默认 19092），也可以选择直接禁用防火墙后，重启 docker 服务和 MeterSphere 组件进行重试。

  1. # 以 CentOS 7 操作系统为例，禁用防火墙及重启服务命令
  2. systemctl stop firewalld
  3. systemctl restart docker
  4. msctl start

若检查发现网络连接状态正常，在执行性能测试时仍旧提示该错误，请联系我们的团队进行进一步定位。

Q：开源版和企业版的区别是什么？

和同属飞致云旗下的 JumpServer 开源堡垒机一样，MeterSphere 的核心功能全部开源，坚持按月发布新版本，永久免费使用。

相比 MeterSphere 开源版，MeterSphere 企业版提供面向企业级应用场景的 X-Pack 增强包，以及高等级的原厂企业级支持服务，有效助力企业快速构建并运营自己的持续测试平台，加速高质量软件的交付。其中，X-Pack 增强包括一些企业级客户所需的附加功能，比如自定义 Logo和主题、配额管理、单点登录支持等。X-Pack 增强包的具体功能会随新版发布持续增加。