作为一款一站式的开源持续测试平台，MeterSphere（https://github.com/metersphere）遵循GPL v3开源许可协议，涵盖测试跟踪、接口测试、UI测试和性能测试等功能，全面兼容JMeter、Selenium等主流开源标准，有效助力开发和测试团队充分利用云的弹性进行高度可扩展的自动化测试，加速高质量的软件交付。目前，MeterSphere开源持续测试平台项目在软件托管平台GitHub上的Star数量已经超过9,900个，累计安装部署次数超过175,000次。
MeterSphere一站式开源持续测试平台除了离线部署的开源版和企业版外，还有Cloud版本（也就是在线的SaaS版本）。本文根据《MeterSphere开源版、企业版和Cloud版选型攻略》直播内容整理而成，呈现MeterSphere各版本的基本情况和主要差异，为广大测试行业用户提供MeterSphere开源版、企业版和Cloud版的选型策略参考。
一、MeterSphere版本概览
1. 什么是MeterSphere？
MeterSphere是一款一站式的开源持续测试平台，遵循GPL v3开源许可协议，涵盖测试管理、接口测试、UI测试和性能测试等功能，全面兼容JMeter、Selenium等主流开源标准，有效助力开发和测试团队充分利用云弹性进行高度可扩展的自动化测试，加速高质量的软件交付。
2. MeterSphere v2.10 LTS版本
2023年5月25日，MeterSphere一站式开源持续测试平台发布v2.10 LTS版本。这是继2022年5月发布v1.20 LTS版本后，MeterSphere开源项目发布的第三个LTS（Long Term Support）版本。MeterSphere开源项目组将对MeterSphere v2.10 LTS版本用户提供长期支持，每两周发布小版本，持续进行问题修复更新并针对部分功能进行优化。
MeterSphere v2.10 LTS版本在测试能力、用户体验、系统架构、系统安全四大方面进行了关键性的升级与优化，为用户带来全面升级的使用体验。
3. 什么是MeterSphere企业版？
MeterSphere企业版由X-Pack功能增强包和原厂企业级支持服务构成。
■ X-Pack功能增强包
系统管理层面，用户可以自定义系统的Logo以及主题配色等；
功能用例相关方面，平台提供了多版本管理以及不同版本之间进行用例对比的功能，以及公共用例库的功能；
接口测试方面，平台主要是通过插件的方式来支持更多的接口测试协议，然后提供了“误报库”进行误报管理的功能，以及接口与Case之间变化的联动。当接口发生变化时，可以把该接口下的用例进行对应的更新；
测试执行层面，平台提供了自定义消息通知模板的功能，用户可以内置一些变量来构造自己的消息通知格式以及模板。平台可以支持使用Kubernetes集群来提供测试资源，比如用户去跑一个接口测试或UI测试、性能测试的时候，都可以把这些任务执行在指定的Kubernetes集群中；
性能测试方面，平台针对大规模的性能测试进行了多方面的优化；
系统集成方面，用户可以通过各种各样的标准协议去跟单点登录系统进行对接，包括CAS、OIDC等这些常见的协议都是支持的。另外，就是可以跟Jira、TAPD、禅道等平台进行缺陷的双向同步，如果用户已经用了这些平台来管理缺陷，只需进行一些简单的配置就可以把已有的缺陷同步到MeterSphere平台的缺陷管理模块之上。
此外，UI测试功能也包含在X-Pack功能增强包当中。MeterSphere官网展示了平台的功能列表，如果对此感兴趣可以的用户进行详细的阅读了解：https://metersphere.io/features.html。
■ 原厂企业级支持服务
除了X-Pack增强包中的功能增强之外，MeterSphere企业版还有对应的服务增强。其中，测试专家服务主要针对性能测试，包括对测试需求进行分析、对压测模型进行设计、对压测环境进行搭建和管理，以及后续测试结果的分析和优化。另外，针对MeterSphere平台的安装部署、使用、数据迁移等具体操作，MeterSphere企业版也提供了专业服务解决用户使用过程中会遇到的各种各样问题。
4. 什么是MeterSphere专业测试云？
MeterSphere专业测试云，即MeterSphere Cloud版，在功能上与MeterSphere企业版是一致的，都是在MeterSphere开源版功能的基础上增加了X-Pack增强包中的增强功能。但是因为MeterSphere Cloud版是SaaS模式，用户无需部署并维护MeterSphere的环境，直接访问Cloud版的官网(metersphere.com)，直接注册购买账号即可开始使用。与MeterSphere企业版类似，MeterSphere Cloud版同样提供了更加专业、更加细致的技术支持服务。
我们看到，在功能层面，MeterSphere Cloud版和MeterSphere企业版是一样的，但是在产品的背后，比如部署架构层面，MeterSphere Cloud项目组针对Cloud应用场景进行了很多额外的处理和优化。整体上，MeterSphere Cloud项目组希望能够充分利用公有云还有Kubernetes的一些技术优势给大家提供一个安全、稳定、可靠并且可以规模化扩展，同时成本又相对可控的MeterSphere版本。
■ MeterSphere Cloud部署架构
MeterSphere Cloud环境目前都是运行在公有云上的，在最底层使用了比较多的公有云托管服务，比如托管的MySQL、Kafka、Redis等。这些托管服务的稳定性比较有保障，像扩/缩容、被测恢复都可以直接使用，不需要额外去处理。
▲ 图1 MeterSphere Cloud部署架构
如图1所示，托管的MySQL、Kafka、Redis等应用负载都运行在Kubernetes集群中。Kubernetes Worker节点大体上可以分成两类，一类是包年/包月或者竞价实例的固定节点，通过提前购买云服务器，然后将其添加到Kubernetes集群中作为一个Worker节点来使用。
另外，还有一种就是超级节点或者虚拟节点，这种类型的节点只是一个虚拟的逻辑概念，不需要提前额外购买服务器，它会根据运行在虚拟节点上的容器的维度来进行计费。在MeterSphere Cloud的使用场景里，这种类型的节点很适合去跑像性能测试以及UI自动化的测试。当有需要的时候去启动一个容器，跑完之后它就会被回收掉，不会再计费。
在这些Worker节点之上，MeterSphere Cloud的工作负载大概又分成两类。图1的左侧是一些公共的管理服务，包括大家访问metersphere.com看到的门户网站，还有大家注册登录之后进入到了“个人中心”页面。在“个人中心”页面中，用户可以去管理MeterSphere的订阅、管理成员及工单等这些通用功能。
图1的右侧，就是整个MeterSphere完整的应用，整体也是通过Kubernetes的方式跑起来的。这里进行了一个设计，就是“个人中心”页面和门户背后，可以去关联绑定多个MeterSphere环境。
这样一来，虽然在一个MeterSphere环境的Kubernetes集群里，每一个组件都可以去横向的扩容。但是它能够支持的用户规模毕竟还是有限的，所以在这种情况下，比如说当用户规模在进一步增长的时候，可以通过增加新的MeterSphere环境来扩展整个MeterSphere Cloud环境的规模。
有的用户对MeterSphere的环境要求特别高，希望有一套单独的环境来使用，也可以通过这样的方式单独部署一个MeterSphere环境，然后添加到“个人中心”页面，将这一部分用户的路由跳转到单独部署的MeterSphere环境之上。
■ 性能测试执行时的资源调度
前面提到在整个MeterSphere环境Kubernetes集群的Worker节点使用到了“超级节点”或者“虚拟节点”的概念，这种类型的节点特别适合用来运行性能测试还有UI自动化测试，具体的使用方法如下。
▲ 图2 性能测试执行时的资源调度
大家都知道跑性能测试其实是比较耗费资源的，使用MeterSphere去跑性能测试的时候，Cloud版本都是使用Kubernetes集群来跑性能测试，MeterSphere就会调用Kubernetes的接口去创建出对应的性能测试的Job。在这背后，可能是一个或者多个JMeter的Pod来执行的脚本。
具体有多少个Pod取决于并发数有多少。比方说，一个配置设定每一个Pod承载500个并发的测试，那么跑1,000并发的时候，就需要两个Pod。在这些Pod运行起来之后，它会把结果传输到指定的Kafka Topic当中。MeterSphere就从这个Kafka对列中获取到性能测试的报告并且进行处理，并展示到性能测试报告的页面上。
在这一过程中，如果是私有化部署的方式，用户什么时候跑性能测试、跑多少规模的性能测试，都是一定程度上可以提前预知或者提前规划的。但是在Cloud模式下，无法预知有多少用户在什么时候会跑多少个并发数的性能测试，这样对MeterSphere整体的资源调度就有一个比较高的要求。比方说，当有很多个用户总共需要去跑1,000个性能测试的时候，那么产品端就至少需要去启动1,000个JMeter的容器，来运行这个性能测试。
■ 基于云平台能力的动态调度
那么，要运行这么多容器平台需要多少个Kubernetes节点呢？一种比较容易解决这个问题的方法是，通过“节点池 弹性伸缩”的方式。根据一个节点池的CPU、内存、网络流量以及Pod数量等监控指标，来动态地伸缩Kubernetes的Worker节点数量。当用户有更多的性能测试需要去跑的时候，就创建出更多的Kubernetes节点出来。当没有那么多性能测试要跑的时候，就缩减这个节点的数量。
▲ 图3 基于云平台能力的动态调度
但这种方式存在两个比较明显的问题：
① 伸缩指标的配置与调试比较繁琐。比方说如果根据CPU内存来配置的话，可能不一定能很好地触发伸缩策略；
② 扩缩容存在一定的滞后性。因为通过这种方式的话，在公有云上创建节点需要时间，节点的初始化需要时间，节点加入到Kubernetes里也需要时间，加入到Kubernetes之后，在该节点上把JMeter的容器跑起来也需要时间。整个时间会拉得比较长，有可能造成的情况就是用户运行一个性能测试，需要等待一段比较长的时间，可能得几分钟才能真正的把这个性能测试任务给跑起来。
这对用户来说体验不够友好，MeterSphere Cloud版本没有采用这种方案，而是使用到了“超级节点”或者叫“虚拟节点”来调度性能测试的Job。
“超级节点”就不需要事先去创建出对应的云服务器，并且把它加到Kubernetes集群里了。只需要在创建这个性能测试任务的时候，给它打上特定的节点选择标签，公有云就会自动地把这个节点调度到其背后的一个资源池上。具体调度在什么地方，对MeterSphere Cloud产品端是透明的。这些性能测试任务会启动在对应的“虚拟节点”上。在启动它时，只会在该性能测试任务运行期间对产品端进行计费，整体费用可控，响应时间也比较快。
这种方式比起刚才提到的弹性伸缩方式，有几个比较明显的优点：
① 配置很简单，用户只需要在创建任务的时候，添加一个额外的Node Selector标签，就可以完成这个任务；
② 底层调度是由云厂商完成的，可靠性和响应速度都有比较好的保障；
③ 从用户/产品研发方面来讲，这个方案的成本更优，因为只有在Pod运行的时候才会对产品端进行计费，不需要准备大量的闲置节点在整个MeterSphere环境中。
■ MeterSphere UI自动化执行过程
UI测试方面其实跟性能测试比较类似，它可能没有性能测试那么耗资源，但当用户去跑一个性能测试与跑一个UI测试的时候，都需要一个单独的浏览器来执行UI测试。所以，相比于接口测试其实也是比较消耗资源的。
UI测试的执行方式可能跟性能测试也比较接近，当用户去执行一个UI测试的时候，MeterSphere会把UI的脚本包装成一个JMeter的脚本。在JMeter的脚本里，就会指定一个Selenium Grid来提供各种各样不同的浏览器节点，比如Chrome或者Firefox。在执行的过程中，也是通过JMeter把这个结果发送到Kafka当中以及MeterSphere平台等，再从Kafka中取到结果来进行解析。
与性能测试类似，产品端不知道什么时候会有多少用户运行多少个UI自动化测试，那就不能很确切地来评估整个Selenium Grid的规模，需要准备多少个浏览器节点在这个Grid当中。
▲ 图4 MeterSphere UI自动化执行过程
所以，最好的情况就是整个Selenium Grid是可以动态扩展的。当用户有新的UI测试任务时，它的浏览器节点就多一些。没有那么多新的测试任务的时候，它的浏览器节点就少一些。
MeterSphere Cloud项目组所采用的方案整体上可以分成两个环节：
■ 浏览器节点的动态扩缩容
▲ 图5 浏览器节点的动态扩容
① 如图5所示，上层的Selenium Grid扩缩容环节，产品端使用了一个名为“KEDA”的第三方组件，它是来做Kubernetes集群中应用的弹性扩缩容的。KEDA的弹性扩缩容可以很方便地使用到一些业务指标。具体到产品端的场景，KEDA可以根据Selenium Grid中处于等待队列的会话数量来进行弹性的扩缩容。比方说，在Selenium Grid等待队列中有一个会话，需要一个Chrome浏览器去执行，KEDA就会监控到这个信息，去创建出一个新的Chrome节点出来。这个会话就可以调度到新的Chrome节点上，完成UI自动化测试。
② 在下层的资源层面，也是用到了刚才提到的“超级节点”或者“虚拟节点”概念，通过KEDA新创建出来的浏览器节点，也会被调度到指定的“超级节点”上。相应的也是在浏览器存在，在UI自动化测试执行的这段时间可能会进行费用的计算，除此之外就没有额外的资源消耗了。
二、MeterSphere各版本之间的差异
1. 开源版、企业版及Cloud版对比
基于前面的介绍，相信大家应该对MeterSphere的开源版、企业版和Cloud版有了基本的了解。接下来，我们从三个版本的部署方式、软件价格、功能、技术支持、服务以及成本构成这五个方面，再跟大家来进一步对比一下三个版本之间的差异性。
▲ 图6 MeterSphere开源版、企业版和Cloud版对比
首先，从部署方式上来看，MeterSphere的开源版和企业版都是采用私有化部署的方式，需要用户自己准备服务器资源，需要用户自行下载MeterSphere安装包，执行MeterSphere安装脚本实现部署安装。MeterSphere的Cloud版采用云端托管的模式，也就是SaaS的模式，大家直接在MeterSphere Cloud的网站上注册账号，就可以开始使用到MeterSphere平台的全部功能。
软件价格层面，开源版是免费的，大家直接在MeterSphere官网上下载安装包或者运行一键安装脚本，就可以完成开源版的部署操作，开始使用开源版提供的所有功能。MeterSphere企业版和Cloud版采用的是按人按年订阅的模式，用户所在团队有多少人需要去使用MeterSphere，支付每人每年订阅的费用。
功能层面，开源版提供了测试跟踪、接口测试、性能测试几大核心功能模块，大家如果有UI测试的相关需求，就需要使用MeterSphere企业版。MeterSphere的企业版和Cloud版就是在开源版的核心功能之上，增加了前面提到的X-Pack功能增强包中的相关功能。
技术支持及服务方面，前文介绍到了MeterSphere企业版以及Cloud版有更专业、更细致、更及时、更全面的技术支持服务。那么MeterSphere的开源版也不是说没有技术支持服务，是相比较而言是比较有限、粗放的技术支持服务。大家可以通过MeterSphere的GitHub仓库、用户交流群、论坛等，来给MeterSphere项目组反馈问题、提出需求。MeterSphere项目组也会尽可能地提供比较及时、比较专业的帮助。但是因为在社区交流群等场景下提问的用户可能比较多，大家的问题可能会被很快刷走，问题的解决有时会有滞后。
最后是成本构成方面，刚才提到了MeterSphere开源版是免费的，大家不需要为这个软件付费。但是这也不意味着用户使用MeterSphere开源版就是没有成本的，比如刚才提到了开源版是要私有化部署的，大家在私有化部署的过程中，就需要去准备服务器资源。部署完成后使用的过程中，也会碰到各种各样的运营上的问题。比方说网络异常、CPU内存或者某个资源遇到瓶颈、存储占满需要去备份以及需要恢复等。所以说，MeterSphere开源版的成本构成主要是用户自己的服务器资源成本，以及后期使用过程中的运维成本。
MeterSphere企业版因为同样是私有化部署的模式，所以它的成本构成首先是也会包含服务器资源的成本以及运维成本，除此之外还要加上MeterSphere企业版的软件订阅成本。
MeterSphere Cloud版的成本构成就很简单，只需要有一个软件订阅的成本。大家注册之后在MeterSphere Cloud版的网站完成付费之后，就可以正常的使用MeterSphere了，并不需要关注其背后的服务器资源、运维操作等问题。
因此，MeterSphere Cloud版反而是成本最低的一个选择，这可能和大家的直觉有些不太匹配。举个具体的例子，根据MeterSphere官方的服务器配置（8核16GB），甚至更低一点的配置，用户自己在公有云上去买这一规格的服务器，大概需要4,000到6,000元每年。而这个价格就可以供十个人的团队去使用MeterSphere Cloud版一年的时间了。所以说如果不是出于监管、网络或者数据敏感性等方面对私有化部署的强要求，MeterSphere Cloud版对大部分用户来而言是更好的选择。
2. MeterSphere Cloud版本的优势
MeterSphere Cloud版的优势具体体现在几个方面：
首先，大家不需要去关心部署的问题，直接注册就可以使用，可以更快地使用MeterSphere并将平台的功能应用到测试流程当中；第二，相比于MeterSphere开源版，MeterSphere Cloud版的功能会更加全面，因为它包含了X-Pack功能增强包中的功能，同时有更好的技术支持，大家使用起来的话也会更加省心，不用担心执行测试时服务器资源够不够用，会不会出现故障等问题。
MeterSphere Cloud版整体来讲是成本最优的选择，无论是跟MeterSphere企业版相比来，还是跟MeterSphere开源版相比，当用户把服务器资源的成本以及运维成本都考虑进去的时候，MeterSphere Cloud的实际成本都是最低的。
三、我适合使用什么版本的MeterSphere?
以下是为大家总结的MeterSphere不同版本的选型策略。如果您的团队决定要使用MeterSphere，可以参考图7进行实际选型。
▲ 图7 MeterSphere版本选型思路示意
1. 我适合使用什么版本的MeterSphere?
第一个要考虑的问题就是有没有专门的运维团队。虽然MeterSphere已经把安装这个环节给大家进行了一个比较好的封装，提供了在线安装包、离线安装包，提供了Kubernetes的环境中使用的Helm Chart ，基本上大家都可以很快速地完成 MeterSphere的安装部署。
但是在部署完成后，随着用户使用的时间越来越长、使用的规模越来越大，MeterSphere的后续运维就需要考虑各种各样的问题。比如存储空间可能会不够；CPU内存去跑大批量的性能测试时资源是否足够；以及各种各样的中间件、数据库、Kafka的性能是不是存在瓶颈，是不是能够支撑大规模使用等。
所以，如果大家没有专门的运维团队来保障MeterSphere的稳定使用，建议直接考虑使用MeterSphere Cloud版。作为用户直接使用MeterSphere，不需要关心其背后复杂的运维问题。
2. 是否需要X-Pack功能增强包？
如果有专门的运维团队可以保障整个MeterSphere环境的稳定，接下来就需要考虑功能层面的问题了，即是否需要X-Pack功能增强包中所提供的功能。比方说，用户的业务系统如果需要开展UI测试，那就需要使用到X-Pack功能增强包。是否需要与单点登录系统进行对接？是否需要对MeterSphere平台的主题色、Logo进行定制？如果有这些需求就需要考虑MeterSphere企业版。
3. 是否需要进一步的技术支持服务？
如果用户对MeterSphere的增强功能没有需求，是不是就可以直接使用开源版了呢？这里还有一个问题需要大家去考虑：是不是需要MeterSphere官方提供的专业技术支持服务？比如当用户对于某个功能的使用场景及使用方式可能不是特别明确，MeterSphere官方就可以提供专门的上手服务，可以帮助大家更快地把MeterSphere的这些功能应用到实际测试工作当中。还有前文提到的针对性能测试的专家服务等。
如果大家对这方面的服务也没有需求，大家可以接受在GitHub或者通过技术交流群、论坛等方式来获取支持的话，或者说大家可以自己服务自己，就可以考虑使用MeterSphere开源版。
4. 是否需要私有化部署？
如果大家对私有化部署没有特别强烈的诉求的话，不妨直接考虑MeterSphere Cloud版。如果大家需要私有化部署，可以考虑MeterSphere企业版。
那么什么情况下会需要私有化部署呢？一般来说如果用户身处强监管的行业，或者说用户的被测系统是纯内网的环境，互联网上根本访问不到，也没有办法跟MeterSphere Cloud环境的网络进行打通，那么用户就要考虑使用MeterSphere企业版。或者说，用户特别在意数据安全相关的问题，担心使用SaaS服务后用例会被其他人看到。如果有这样的担心， 虽然说这种情况出现的可能性很小，但如果大家实在有这种担心也要考虑私有化部署，选择使用MeterSphere企业版。
