直播回顾丨MeterSphere一站式开源持续测试平台的初心与方向

编者注：以下内容根据MeterSphere研发经理王振在6月17日“FIT2CLOUD飞致云在线讲堂”的直播内容整理而成，其中演讲内容进行了部分节选，并对在线问答环节进行了整理。

本次直播我会和大家分享一下FIT2CLOUD飞致云最新开发的一站式开源持续测试平台——MeterSphere。

说到FIT2CLOUD，可能有朋友了解过我们的公司和之前的产品，包括多云管理平台、JumpServer开源堡垒机和KubeOperator开源容器平台。那么，我们为什么会在测试领域做MeterSphere这样一款产品呢？以及MeterSphere会有哪些具体功能？能解决什么的问题？今天来跟大家分享一下。

一、MeterSphere为何而来？

FIT2CLOUD飞致云的产品定位是“为企业提供多云时代更好地构建、运行、管理、保护其IT基础设施和应用的关键工具”。在“运行”、“管理”和“保护”这三方面，我们已经有了对应的产品，也给我们的用户带来了比较好的价值，但是在“构建”领域，也就是面向研发、测试的环节，我们还缺少一款产品提供支持。

同时我们也发现，测试人员的需求其实是没有很好被满足的。现在市面上，尤其是在国内，也缺少一款相对成熟、受众广泛的开源测试平台。为什么会出现这样的情况呢？借用同行的一句话，可能是“因为测试不够性感吧”！

最后也出于我们自身的需求，我们需要有这样的一个平台给公司其他产品的测试任务提供支持。

基于以上几方面的原因，MeterSphere应运而生。

我们对MeterSphere的产品定位是一个“一站式的开源持续测试平台”。它主要涵盖测试跟踪、接口测试、性能测试、团队协作等功能，同时兼容JMeter等主流的开源标准，可以有效地助力开发和测试团队充分利用云的弹性，进行高度可扩展的自动化测试。

在刚才的这段介绍里面，其实有三个关键词：一站式、开源、持续测试。下面我们一个个来解读一下。

首先是“一站式”。我们和很多测试人员聊的时候发现，其实在测试领域的每个环节、每一部分，很多公司、团队都有对应的工具、方法提供支持，但是一个很普遍的现象是——各个环节之间都是互相割裂、互相独立的。我的测试用例管理工具里面的某个用例和某个测试人员写的测试脚本之间没有什么联系，测试脚本跑完之后需要手动把测试结果更新到用例管理工具上去。

另一种情况是，我写好接口测试的脚本不能直接拿来用作性能测试，还需要换一个工具重新来一次。

面对这样现象，我们希望MeterSphere能够涵盖到软件测试工作中，从测试用例管理、测试任务跟踪到测试执行、测试报告分析的不同阶段，同时可以帮助测试人员完成从手工的功能测试到自动化接口测试、从接口测试到性能测试的无缝过渡衔接。

虽然我们目前发布的MeterSphere v1.0版本离真正的“一站式”还有一些距离，像材料里灰色部分的移动端测试、UI测试、安全测试等功能都还没有包含，但是我们会在后面的迭代中不断朝着“一站式”的目标持续前进。

再来看看“开源”。开源就是开放源代码，相信大家有着切身的体会，开源应用、开源软件正在切切实实地改变着我们的这个世界。

我简单列了一下我们的团队和我个人平常会用到的开源项目，从底层的操作系统到最上层的具体应用和工具一应俱全，这里列出来仅仅是整个开源世界的冰山一角，大家也可以去整理一下经常用到的软件和工具里有多少是开源的。

像我们的JumpServer开源堡垒机和KubeOperator开源容器平台一样，MeterSphere这款产品也会以开源项目的形式运作，大家可以从官网或者直接在GitHub上搜索，就可以找到MeterSphere的代码仓库。

另外，我们目前在接口测试、性能测试这一块完全兼容JMeter格式，后续的话也会和其他优秀的开源测试工具、测试引擎，比如Selenium、Robot Framework等来进行对接，不断完善我们自身的功能。

最后是“持续测试”。持续测试不是孤立的事情，需要融入到我们整个DevOps体系。DevOps也是这几年很火的概念，很多公司都在积极探索，进行DevOps转型，不同的人可能会对DevOps有不同的概念和认识。

在我看来，DevOps最核心的特点就像经典的八字图一样，就是不断地重复、循环，也就是持续化。它包含了各个环节的持续化，从最开始的持续计划、持续开发到持续集成、持续测试，然后再到上线之后持续部署、持续监控等。

从快速交互应用的角度来看，可能持续集成是整个DevOps流水线的核心。但是从DevOps的核心目的——又快又好地交付应用的角度来看，“持续集成+持续测试”才应该是整个DevOps的核心所在。

Gartner的一份报告也印证了这样的观点。Gartner预测，到2020年50%的企业会通过采纳开源框架和开源工具来落地持续测试。

提到持续测试，可能有人会问，持续测试和自动化测试有什么区别？自动化测试我们可能听到的更多一些，持续测试是在自动化测试的基础上进行一些扩展和延伸，不仅包括自动化测试的过程，更包括从测试左移到测试右移所覆盖的全部环节。

测试左移的话，就像我们做一些单元测试、组件测试、代码覆盖率测试一样；测试右移就是我们需要在应用上线之后，不断地对它进行生产环境的监控，在生产环境上做一些简单而不影响业务的测试等。

具体到MeterSphere，我们会提供完善的Jenkins插件，帮助用户实现持续测试的目标，把测试环节纳入到整个DevOps流水线当中。目前MeterSphere主要还是在测试左移这个方向的功能，后续我们会推出实现测试右移的相关功能，来达到整体持续测试的效果。

“一站式”、“开源”、“持续测试”这三个关键词基本概括了我们对MeterSphere这个产品的整体定位，接下来看一下为了实现这样的定位，MeterSphere相比于传统的测试工具或者测试平台所具有的优势和特色。

二、MeterSphere的优势与架构

MeterSphere的优势体现在以下四个方面：

第一，全生命周期的支持。这部分就是刚才针对“一站式”的解读，MeterSphere所提供的功能能够覆盖测试计划、测试执行、测试分析的不同阶段；

第二，自动化和扩展性。现在是云和容器的时代，如果在之前我们要做一个大规模的性能测试，去部署和维护大量的测试执行节点，可能需要我们投入很大的精力来做。基于MeterSphere，可以通过和云平台、容器平台的接口进行对接，自动管理测试资源池，可以充分利用云的弹性实现超大规模的性能测试；

第三，持续测试。MeterSphere能够与持续集成工具无缝集成，支撑企业实现测试左移；

第四，团队协作。MeterSphere提供了一个比较灵活的多租户管理模型，基于这样的多租户体系，MeterSphere既可以支持小到几人的测试团队，也可以支持大到数百人的测试中心。

接下来我们来看一下MeterSphere的整体架构。MeterSphere主要由紫色的四个部分组成，灰色的部分是一些通用的开源中间件。紫色的部分中的Frontend 和Backend 构成来我们应用的一个主体，在应用主体中我们采用了前后端分离的架构，分为前端和后端。

前端主要是基于VueJS和ElementUI来做的，后端是基于Java SpringBoot这个框架来做的。应用主体里包含应用的大部分功能，比如刚才提到大部分功能都是在这部分里提供的。

DataStreaming组件和NodeController组件主要是支撑我们完成大规模分布式的性能测试。

首先看一下NodeController组件，这个组件我们可以装在一台安装了Docker的Linux机器上，主体应用会在做性能测试的时候，把这个性能测试任务下发到NodeController，可以把它理解为压测的执行节点。NodeController收到这个性能测试任务之后，会通过控制Linux机器上容器引擎的方式来启动一个JMeter的容器运行性能测试脚本，从而完成性能测试。

同时在这个JMeter脚本里，我们增加了一些配置，在测试执行时会实时地把性能测试压测结果传输到Kafka队列中。这个结果到了Kafka队列之后，后边就是DataStreaming组件的工作。这个组件会不断从Kafka队列中收集性能测试结果和测试产生的日志，进行一些相关处理之后，会再把它持久化存储到数据库里。存储到数据库之后，在前端页面上就可以看到整个性能测试压测的报告了。

三、MeterSphere的管理模型和四大功能

接下来看看MeterSphere的管理模型。刚才提到MeterSphere的一大优势就是团队协作能力，我们整个背后管理模型是一个两级租户体系。这个租户体系在FIT2CLOUD的其他产品里得到了比较好的验证，有了很丰富的落地实践经验。

在这里，我们划分了组织和工作空间两级租户。在工作空间租户中，不同的团队还可以创建维护自己的项目，所有的测试跟踪、接口测试等都在项目的范围内提供。

测试跟踪中首先是测试用例的管理。基于你的用例可以针对不同版本、不同迭代发起测试计划。还有一个比较好的特点，就是我们这里的测试用例可以和接口测试、性能测试、UI功能测试等进行关联，这也就是刚才说的“一站式”的体现。

现在，大家一定迫不及待地想要了解MeterSphere究竟提供了哪些具体的功能，以及可以用它做什么？在MeterSphere v1.0版本中，我们提供了四大功能：即测试跟踪、接口测试、性能测试、团队协作。

首先是测试跟踪。MeterSphere提供了远超TestLink的使用体验。TestLink大家可能都有了解，它的整个技术栈、UI等都是比较老旧的，用起来体验并不是特别好。在MeterSphere的测试跟踪功能模块里，用户可以针对每个独立项目，以树状的形式管理所有的用例。用例的管理方式既可以通过浏览器在线编辑的方式来维护，也可以通过Excel导入的方式，快速导入已有的用例。

同时用例都维护好之后，可以针对这个项目的不同迭代、不同版本来发起若干个测试计划。发起测试计划的时候，可以从项目里的所有用例中选择若干的用例分配给不同的执行人进行测试。

执行人被分配测试之后，通过MeterSphere可以在线记录整个测试的过程和结果。整个测试用例、计划都执行完之后，系统会给出一个完整的测试报告，这就是测试跟踪模块的主要功能。

第二是接口测试。在接口测试功能模块中，MeterSphere提供了类似主流Postman工具的使用体验。大家应该都用过Postman这个工具，整体上它的功能还是比较完善和好用的。但是对于一个团队使用来说，一个很大的问题是它的免费版本不支持团队协作，如果要支持团队协作，需要用到企业版。

MeterSphere具备天然的团队协作能力，在MeterSphere的接口测试功能模块里，大家也可以像使用Postman那样，在浏览器里在线编辑接口测试的请求详情。除了基本的请求详情之外，我们也提供了很常用的参数化测试、变量提取等较为高级的功能。

同样，用户在MeterSphere平台上执行测试后，可以马上查看到一个完整的测试报告。这个测试报告里包含了测试概览情况，同时也包含了每个测试具体的请求和相应的内容，方便大家去做一些异常的判断和问题的定位。

第三是性能测试。MeterSphere的性能测试和接口测试都是完全兼容JMeter的。如果你之前使用JMeter，可以把已有的JMeter脚本直接上传到MeterSphere的平台上，非常方便地发起性能测试。同时，在接口测试功能调测好之后，还可以基于MeterSphere把接口测试一键转化成性能测试，然后再加上一些压力配置相关的参数，就可以发起性能测试了。

MeterSphere也提供了浏览器插件，这个浏览器插件开启录制之后，会把你在浏览器页面中所有的网络请求都记录下来，当然会筛选掉一些静态文件的请求。记录下来之后，你可以把它保存为一个JMeter脚本。有了这个脚本之后，你就可以把它扔到MeterSphere平台上做接口测试、性能测试，整个插件用起来还是很方便的。

和接口测试一样，整个性能测试跑完之后，可以在线看到整个测试执行的报告情况。报告呈现的内容也是很完整的，既有概览的信息，也可以看到请求的统计，还有出现错误异常的情况，以及背后JMeter完整的日志，都可以在报告中进行查看。

第四是团队协作。这部分前面基本上介绍了，主要包含多租户的支持和测试资源管理。

很多管理员可能对多租户的支持感兴趣。它可以很好地组织租户，既可以做到不同租户之间很好的隔离，包括资源的隔离、权限的隔离，又可以做到同一个租户中的成员比较方便的协作。

测试资源管理，包括我们做性能测试时对整个测试资源池的管理。MeterSphere还提供了默认的测试报告模板，你也可以基于这个模板创建自己的测试报告模板，同时可以做一些和第三方系统对接的工作，以及比较常见的系统配置任务。

四、MeterSphere的研发计划

MeterSphere会保持每个月一个功能版本的节奏来持续迭代。除了在完善改进已有功能的同时，我们也会不断的增加新功能，不断探索在测试领域中技术创新的更多可能性。

MeterSphere v1.1的版本预计将在2020年7月底发布。这一版本的功能规划大概包含以下几方面：

第一，浏览器插件功能的改进和增强，主要包括浏览器插件录制后脚本的在线编辑能力。现在插件功能比较简单，只能保存下来，保存成JMX文件之后再去编辑，后面我们会增加在插件界面上的直接编辑能力；

第二，插件录制的脚本可以直接扔到MeterSphere平台上做接口测试；

第三，针对性能测试报告的优化。有使用过MeterSphere的用户可能发现，现在的报告功能只能在测试执行完成后才能看到报告内容。在下一个版本中，我们会增加报告动态展示的能力，在测试执行过程中可以实时查看到整个被测系统响应的情况；

第四，我们会在v1.1的版本中提供达到持续测定目的的Jenkins插件，通过这个插件可以在Jenkins上触发MeterSphere的测试任务；

第五，v1.1版本会推出在线体验环境，便于大家更快速、更便捷地体验到MeterSphere平台最新版本的功能。

预计在2020年8月发布的v1.2版本中，MeterSphere将主要对接口测试做一些功能上的增强和优化。在接口测试中，会支持前后置的脚本，同时可以支持等待时间的设置，可以加一些CSV类型的参数。插件方面我们也会做功能的增强，现在导出的是JMX JMeter脚本的格式，后面我们可以导出成更为通用的HAR格式。

另外，在v1.2版本中，MeterSphere还计划增加和前后置系统的对接集成能力，包括对比较主流的需求管理系统的集成，以及缺陷管理系统的集成对接。

刚才提到了对接云平台，从而动态地来管理测试资源池，MeterSphere计划在v1.3版本时推出相关的功能。而在更长远的版本规划中，比如之前提到其他形式的测试，包括UI功能测试、移动端测试、Mock服务等，我们也会在后续的版本中不断地增加相关的功能。

五、在线互动问答

问题1：MeterSphere和JMeter有什么区别？

回答：这个问题很好，后面我们会专门写一些相关的文章来说明这个事情。这里先简单说一下：

第一，和Postman类似，JMeter这样的客户端工具更多的是面向个人的，团队协作能力相对欠缺。比如我使用JMeter，写好一个JMeter脚本之后，可能需要把这个脚本存起来，再发给其他同事。MeterSphere因为有天然的团队协作能力，大家都可以在同样的平台和界面管理维护你的脚本；

第二，JMeter去做分布式、多节点的性能测试时，会有自己的一些问题和局限。比如说它所有的节点都要求在同一个子网内，当然你也可以有其他规避这个问题的方式，但是相应地你也需要额外地投入和精力做这个事情；

第三，JMeter整个分布式的机制也有比较大的局限。MeterSphere可以比较好、比较方便地进行分布式的性能测试，可以很方便地把你的压测执行节点以一个资源池的形式统一地管理起来。

问题2：MeterSphere手工测试用例是如何转为自动化测试关联的？测试用例是如何与需求、版本关联的？是否支持用例在不同计划轮次的随意编排、评审和指定执行人？

回答：刚才提到MeterSphere有一个浏览器插件，可以通过浏览器插件让我们在做手工的功能测试时把浏览器插件的录制功能打开，然后在做功能测试的同时，这个插件会把我们在测试过程中发送的网络请求录制下来。

测试完成后，我们就可以把录制的脚本保存下来，再进行一些参数化、断言等相关的修改，可以得到一个接口自动化测试的脚本。你可以把它扔到MeterSphere平台上来执行，因为它是一个标准的JMeter格式。你如果比较喜欢用JMeter的话，也可以直接把它扔到JMeter上运行。

另外这个问题涉及研发规划的v1.2版本，MeterSphere将会和前置的需求管理工具，比如说Jira，以及后置的缺陷管理工具，来进行集成和对接。

问题3：MeterSphere是否会划分商业和开源版本，还是纯开源？

回答：这个问题也是大家比较关心的问题，这里统一回答一下。MeterSphere的开源策略将和FIT2CLOUD飞致云其他产品的开源策略保持一致。它会在保持核心功能开源的基础上，增加一些企业版的扩展功能，也就是说我们未来会推出MeterSphere企业版。

当然大家可以放心的使用MeterSphere的开源版本，我们会保证它的核心功能是开源的。你如果不用企业版只用开源版的话，也可以用得很爽。这方面大家可以和JumpServer开源堡垒机的用户了解印证。

问题4：接口有规划支持Dubbo吗？

回答：目前还没有这样的规划，但是我们会很欢迎大家在GitHub和MeterSphere项目交流群里给我们提出需求，如果大部分人都有这方面的需求，我们会考虑把它加到后面版本的规划当中。

问题5：介绍中提到能够与持续集成工具无缝集成，具体是如何与企业现有的CI/CD系统集成的？

回答：在MeterSphere v1.1版本规划里提到的，我们会提供一个Jenkins插件。这个插件大概功能就是——首先会和MeterSphere平台有一个认证，认证完成后可以在你所选的项目里选择一些测试用例、接口测试、性能测试脚本做一个触发执行，执行完成后我们的插件会返回给Jenkins结果。

这个插件可能有几种使用方式，你可以用Freestyle的方式，把它作为一个单独的任务，然后跟其他的任务关联起来。我们也会支持Pipeline的方式，你可以直接把这一个环节加到你的整个Pipeline里面。

问题6：是否支持与gitlab-ci集成呢？

回答：目前我们考虑的更多是和Jenkins集成。和刚才那个问题一样，如果您这边有比较强的需求，我们会看这个需求是不是比较普遍，也会考虑把它加入到我们后续的版本规划当中。

问题7：遇到高并发场景的话，有分布式吗？

回答：在MeterSphere的产品架构包含了NodeController的组件，这个组件可以脱离主体应用独立安装。我们会有一个测试资源池的概念，在这个测试资源池里面，你可以添加很多个这样的NodeController，或者叫压测执行节点。当你去做性能测试、压测的时候，你选择了对应的资源池，我们会把整个并发数按照一定的规则拆分到每个压测执行节点上进行执行，最后再把结果进行统一汇总。

问题8：性能测试除了支持上传JMeter脚本外，是否支持在线编写和修改脚本？

回答：目前MeterSphere提供的测试针对Web应用更多一点，在线的编辑和修改脚本的形式虽然不能在性能测试中直接做这个事情，但是我们提供的对应功能可以把一个接口测试转换成性能测试的脚本。也就是说，如果你有在线编辑修改的需求，你可以在接口测试那边编辑修改你的接口测试，在没有压力的情况下，测试通过了之后，再把这个接口测试转化成一个性能测试。

当然JMeter除了测Web应用、HTTP请求以外，它通过插件的形式还能做很多事情。MeterSphere目前的规划还是会以Web形式为主，因为JMeter功能蛮强大的，我们如果把它的所有功能都挪到我们的Web页面上也不是特别现实。

问题9：接口测试和性能测试的参数有可能不一样，这种情况怎么把接口测试直接生成性能测试脚本呢？

回答：这个问题可能一方面是MeterSphere平台会提供相关的功能，另一方面可能也需要把这个脚本做一个比较好的参数化处理。相当于在做接口测试的时候，已经把可能会变的参数剥离出来，把它搞成一个外部的参数。当我把它转换成性能测试的时候，其实可以重新给性能测试的参数赋值。

另一方面，未来我们也会去做一个类似环境管理的功能。在环境管理中，针对不同的环境，你可能会维护不同的变量，以及不同变量的不同值。可能用类似的功能，同时也会有全局或者局部的变量。基于这样的形式，你在做接口测试、性能测试的时候，就可以给到某一个参数不同的值。

问题10：建议规划中能考虑测试数据管理、生成、Mock的能力。

回答：这个我们其实也考虑过，测试数据管理、生成可能会麻烦一些，现在想的还不是特别清楚。如果大家有什么好的解决思路、好的方法，十分欢迎和我们联系，大家一起交流一下，共同把MeterSphere做得更好用。

Mock的话，刚才在规划里也提到了，目前在v1.x的版本中，更多的是把现有的能力不断地完善优化。未来的v2.0版本会增加这样的能力，比如Mock服务，以及UI功能测试等。

问题11：请问如何快速部署出测试集群？

回答：不知道这里的“测试集群”指的是什么？是不是我们做压测的时候，分布式的压力执行节点。如果是的话，可能有几种方式。目前来讲，MeterSphere提供的安装包中，通过安装包可以不安装其他的组件和应用，只安装我们的压测执行节点需要的组件。通过这样的方式，你可以按需部署自己的压测执行节点。

另外像v1.3版本中所规划的，我们后续会考虑和云平台的接口做一个对接。这样的话，你只要把云平台的认证信息、机器创建所需的相关配置参数填写到MeterSphere平台上，后续做性能测试的时候，MeterSphere平台可以自动地把整个测试集群、压测执行节点创建出来。测试结束之后，也可以把它自动销毁掉，你就不需要手动管理这样的测试资源了。

问题12：可以上传locust脚本压测吗？

回答：目前还不太可以。因为目前MeterSphere的接口测试、性能测试背后都是通过JMeter来完成的。在后续的版本里面，我们也考虑把整个平台做进一步的抽象。这样的话，MeterSphere平台既可以使用JMeter来作为测试引擎，也可以使用其他的主流工具作为测试引擎，同时也会提供一些比较好的扩展能力。用户可以在MeterSphere扩展机制的基础上，去扩展自己已有的引擎里没有的东西，这个可能是更长远的规划。

感谢大家的提问，非常感谢大家关注MeterSphere项目。如果大家还想要了解更多的信息或者跟我们保持沟通交流，大家可以访问MeterSphere的官方网站或者加入MeterSphere的微信交流群。

我们也提供了一个一键安装脚本，大家如果有自己的机器，可以通过这个脚本快速部署一套自己的环境，亲自体验一下刚才介绍到的所有功能。

再次感谢大家的关注，希望大家能够和我们分享您的想法和建议，大家一起打造一款符合我们心中期望的开源持续测试平台。谢谢大家！