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