有了 JMeter，为什么还需要 MeterSphere？
希望以下内容能够给你带来帮助。
1. MeterSphere和JMeter之间的关系
提起JMeter，相信大部分的测试人员应该很熟悉。JMeter因其小巧轻量、开源，加上支持多种协议的接口和性能测试，在测试领域有着广泛的运用。一方面测试人员会将其安装在个人的PC上，满足日常测试工作的需要；另外一方面很多企业会基于JMeter建设企业自动化测试能力。
MeterSphere是基于JMeter之上构建和研发的一站式的开源持续测试平台，从下面MeterSphere组件架构图也可以看出，MeterSphere 采用了JMeter 容器作为测试引擎。另外MeterSphere在JMeter的测试能力和平台架构上进行了增强和延伸，在测试能力上MeterSphere除了支持接口测试和性能测试外，还拓展了测试跟踪管理、WEB UI 自动化测试、测试团队协同管理等功能；在架构上MeterSphere可以充分利用云弹性进行高度可扩展的自动化测试。
2.MeterSphere和JMeter之间的区别
从上述MeterSphere和JMeter的关系说明中也不难看出，JMeter在产品设计上定位为工具，而MeterSphere在产品设计上定位为平台，这个也导致了两者在研发理念、管理能力、部署架构三个方面有着本质的差别。
在研发理念上：JMeter解决的是用户的使用。侧重于测试功能的设计，同时在会从部署简单、架构轻量等方面考虑，方便测试人员能够进行简单部署和使用；而MeterSphere则是侧重于系统平台的研发设计，在具备测试功能之外，充分考虑了多用户情况下的易用性、多测试团队的管理、大规模自动化回归等各个方面需求。
在管理能力上：JMeter遵从功能实现的角度出发，工具的使用规范、建设标准等依赖个人用户和企业制定一些规章制度进行约束。而MeterSphere，除了功能的实现的同时，也注重人员权限的管理、流程上的规范上、项目数据的隔离等方面。比如MeterSphere支持“基于角色的访问控制”（RBAC）的人员权限管理模型。
在部署架构上：JMeter往往以独立部署在个人用户PC上为主。而MeterSphere平台满足多人员、多团队的同时使用，支持高可用、集群分布式等部署架构，而且能随着企业用户的逐渐增多支持部署架构的横向扩展。
3.MeterSphere相对JMeter能力上的增强
虽然MeterSphere底层的执行引擎采用了JMeter，但是从两者区别来看，MeterSphere一方面补充JMeter本身在测试管理方面的不足，另外一方面对JMeter上测试能力上进行了增强：
3.1 团队协作管理增强
JMeter 的不足：
- 采用C/S 架构部署，使用的人需要在本地进行安装；
- 无法针对不同团队、产品、项目的测试脚本进行管理和区分；
- 无法控制不同成员对不同测试用例的访问、修改、运行等权限；
MeterSphere 的增强：
- B/S 架构的测试平台，只需浏览器就能使用平台提供的功能，无需使用人进行部署；
- 支持团队和项目维度的管理模型，当多个部门多个项目多个测试团队使用时，则可以为各个部门创建工作空间进行部门级分权分域，之后为各个部门下的项目创建项目进行进一步项目级分权分域进行管理；
- 支持RBAC的角色权限管理方式，支持用户自定义不同的角色，设置不同的用户权限，可细化到部门管理员、项目管理、项目测试人员、只读人员等等。并且支持操作审计日志，轻松应对多产品、多项目的管理测试。
3.2 测试管理方面的增强
JMeter 的不足：
- 编写好的测试脚本独立管理，其他项目或者其他测试用例需要无法引用，造成脚本编写的冗余和维护难；
- 测试脚本进行了修改后，无法进行追踪回溯和版本对比；
- 测试依赖的文件，自定义代码等管理较为分散，管理和维护很不便利。
MeterSphere 的增强：
- 支持测试用例的复制引用，可以提炼公共测试用例供其他测试用例和项目进行引用；
- 针对测试脚本的修改提供双维度记录和跟踪，支持脚本修改历史查询和定位和脚本的历史版本管理和比对；
- 内置统一测试文件管理中心、代码片段库，将测试依赖的文档和代码进行统一管理，大大降低了文件和测试代码维护的复杂性。
3.3 接口自动化能力加强
JMeter 的不足：
- 接口管理和接口测试割裂，一旦接口发生变化，无法快速更新涉及变更接口的测试用例；
- 无法快速模拟接口自动化测试所依赖的的上下游接口；
- 无法将同一套的接口自动化脚本运行至不同环境，并且使用不同的参数变量；
- 无法方便快捷的方式将接口自动化测试接入现有DevOps流水线中。
MeterSphere 的增强：
- 提供了从接口定义到单接口用例的统一管理能力，支持的导入源有Postman、Swagger、HAR和JMeter等接口；还提供了按照实际业务场景编排接口自动化能力；
- 提供了Mock服务，可以根据用户输入的请求参数，自动生成模拟数据并返回。同时，MeterSphere Mock还可以根据设置的请求触发条件进行过滤，返回期望的数据；
- 在项目维度将环境相关的变量进行抽象，并按照Dev、QA、SIT等进行组织，测试用例通过选择运行环境即可在不同的测试环境中进行执行。
- 提供标准的RESTful API接口和Jenkins插件，无论是广泛使用的Jenkins、GitLab这类开源CI工具，还是诸如Azure DevOps和云效的商业DevOps平台，亦或其他各类研发管理平台的流水线均可以调用MeterSphere的自动化测试用例、测试场景和测试计划；
更详细的接口能力说明详见连《产品解读丨MeterSphere接口自动化测试的应用场景和实践》：产品解读丨MeterSphere接口自动化测试的应用场景和实践 - 技术博客 – FIT2CLOUD 飞致云
3.4 大规模扩展性增强
JMeter 的不足：
- 单节点JMeter并发数承载能力有限，多节点环境配置、维护复杂；
- JMeter无法并行运行多个测试，需要更改配置启动额外进程；
- 不支持大规模测试下的测试资源弹性伸缩。
MeterSphere 的增强：
- 压测执行节点支持一键安装，支持百万级虚拟用户的测试；
- 多个项目、多个测试（接口、性能、UI）可并行使用同一个测试资源池；
- 对接Kubernetes API 根据并发数自动启动、释放压测执行任务。
更详细的压测能力说明详见《MeterSphere在开源压测工具JMeter上的分布式优化和实践》：MeterSphere在开源压测工具JMeter上的分布式优化和实践 - 技术博客 – FIT2CLOUD 飞致云
3.5 测试报告分析增强
JMeter 的不足：
- 在测试执行完成后单独生成，无实时报告；
- 测试报告不能很方便地进行共享；
- 报告可读性较差，美观性较差；
- 没有多次测试结果之间进行比较的功能支持。
MeterSphere 的增强：
- 近乎实时的性能测试报告展示；
- 团队共享的测试报告，方便团队成员进行协作分析；
- 丰富的报告图表和展示，美观大方；
- 历史测试报告随时查看，多次测试结果可以快速比较。
4.MeterSphere核心能力总结
MeterSphere平台能够将多种测试能力整合，屏蔽测试工具带来的差异化，将功能测试、接口测试、性能测试、UI测试等以服务的方式提供给最终的测试人员和团队。
从核心能力来看，MeterSphere平台功能设计上对企业管理需求和用户具体的功能需求进行了综合评估，取得了一个很好的平衡。具体来说主要包括以下几个方面：
- 统一的用户/租户体系：MeterSphere测试平台提供了多种的测试能力，这些能力最终提供给不同的用户进行使用。MeterSphere提供一个统一的逻辑用户/租户体系，并且可以和企业现有的组织管理架构进行映射和规划。
- 完整的权限管理体系：测试平台的使用者不仅仅是测试人员，同时也有开发人员、运维人员等。MeterSphere测试平台提供权限管理体系，实现人员、角色和功能权限的解耦，从而可以让企业非常方便地建立出一套符合自己企业内部实际情况的测试权限管理管理体系，不同的角色人员在测试平台中依据其职责边界开展工作。
- 完备的API访问接口：大部分企业建设的DevOps平台或者CICD工具链，都已经提供相关的API访问接口。MeterSphere作为一个测试平台，它必然要和其上层或者同级服务进行数据交互和联动。如前所述，MeterSphere测试平台通过API开放与外围系统形成交互。
- 测试工具兼容能力：企业测试经过了很长时间的累计，在不同的工具商累积的大量的测试用户或者测试数据，MeterSphere提供用户一键导入现有测试工具的数据至平台中，比如PostMan接口用例、JMeter接口测试、Swagger接口等脚本、Selenium IDE 自动化脚本，最终实现统一的管理。
- 灵活的协议插件体系：一方面MeterSphere将测试协议的支持与平台进行解耦，通过协议插件的方式，灵活的支持用户通过自定义开发协议插件方式MeterSphere平台中开展其特需协议的自动化测试和性能测试。另外一方面MeterSphere支持以平台插件的方式，灵活、全面且深入地对接TAPD、JIRA、禅道等市面上已有的成熟系统，目前MeterSphere已经支持了包含Webscoket、MQTT、JIRA、TAPD等在内的几十种插件。
- 大规模横向扩展能力：不同的企业测试团队人员从几人至几十、几百人都有。MeterSphere支持采用传统虚拟机和Kubernetes集群等分布式测试资源池。通过资源池的方式支持测试机的动态扩容，所有的测试任务，无论接口测试、性能测试还是UI自动化测试都可以采用资源池的方式调度与运行。可以同时满足几人到几百人团队的高频测试需求。
感谢，学习到了。
不客气，我们互相学习~ 