MeterSphere 使用 MeterSphere 让你的测试工作持续高效

编者注：本文为 CSDN 博主 weixin_41974278 的原创文章。

原文链接：文章源自玩技e族-https://www.playezu.com/180904.html

https://blog.csdn.net/weixin_41974278/article/details/124174009文章源自玩技e族-https://www.playezu.com/180904.html

自我介绍一下，我是某医疗行业公司的测试团队 Leader，带领着一个 5 人测试团队。这个团队主要负责公司产品的测试工作，包括 App 测试、黑盒测试等，还会配合研发部门进行部分白盒测试。文章源自玩技e族-https://www.playezu.com/180904.html

由于产品迭代周期较短，导致平时上线前测试任务繁重，忙于工作后也没有什么时间静下心来好好思考。碰巧这次疫情被强制在家隔离，工作任务顿时少了很多，正好趁着这段时间静下心来好好回顾一下工作上所遇到的问题，也算 “因祸得福” 吧。文章源自玩技e族-https://www.playezu.com/180904.html

我们团队都是工作三年以上的准资深测试工程师，平时都会用 Postman、JMeter 进行接口、性能测试，自认为我们测试部门的工作效率还是不错的。我们研发部门的同学也不乏技术大牛，代码能力很强，研发效率也是很高的。从内部资源的视角来看，功能研发、功能测试、性能测试、需求评审等每个环节的效率都很高。但从业务视角来看呢？那就是另外一回事了。文章源自玩技e族-https://www.playezu.com/180904.html

在测试工作中面临的实际问题文章源自玩技e族-https://www.playezu.com/180904.html

首先，我们面临的问题是效率集中在局部，且难以持续。文章源自玩技e族-https://www.playezu.com/180904.html

站在用户的视角上看，用户都是希望能尽快实现他们的要求或者需求，解决他们最迫切需要解决的问题。但是当我们切换到这一视角时，尽管我们内部认为局部效率不错，但用户的感知是不一样的。也就是说，局部效率不一定带来高效的产品交付。文章源自玩技e族-https://www.playezu.com/180904.html

我们作为一个组织，是不是能够把各个局部的效率转化为高效的交付？其中部门间的协作、研发质量、测试质量、是否需要返工，都会导致 “局部效率不等于高效交付”。当然，以前为了解决高效交付的问题，通常会在上线前，或者做项目时临时成立项目交付团队，工位也靠得很近，以此来解决交流的问题。这样确实达成了一时的高效，但这种高效是不可持续的。文章源自玩技e族-https://www.playezu.com/180904.html

第二，我们所拥有的测试 “资产” 是零散且陈旧的。文章源自玩技e族-https://www.playezu.com/180904.html

站在我们测试团队的角度而言，我们维护的测试用例在将来是可以重用的，并且在重用的时候不会产生质量问题。我们习惯叫这些东西为 “测试资产”。

既然称作为资产，那么我们肯定希望它们是能够产生正向利息的。但在现实中，它们对我们来说往往不是资产，而是负债。我们花了很长的时间去维护，但却没有很好地持续累积资产。我们团队的测试用例都四散在各地，有的在 TAPD 上，有的自己用 Excel 去维护，经常懒得上传同步。这都是阻碍我进行持续高效测试的因素。

基于以上这两个问题，我开始使用 MeterSphere 一站式开源持续测试平台。之前和他们产品团队线上交流过，但一直没有好好用起来，这几天试用下来发现比较贴切我的需求，故写下这篇文章供大家共勉及参考。

使用 MeterSphere 的实际过程

MeterSphere 开源持续测试平台（metersphere.io）主要涵盖了测试跟踪、接口测试、UI 测试、性能测试、 团队协作等功能。因为兼容了 JMeter 作为底层平台，所以在使用上没有任何技术隔阂。话不多说，给大家讲一下我是如何使用的吧。

安装 MeterSphere 的过程我就不赘述了，官网上都有，如果不清楚的可以参考 MeterSphere 在线安装文档（
https://metersphere.io/docs/installation/online_installation/4 核 8GB 的 Linux 机器一键安装即可，特别方便。）。找一台

安装完成后，输入初始用户名密码 admin/metersphere，就可以正常登录了，登录界面如下图所示：

从上方导航框中可以看到，MeterSphere 主要分为以下工作模块：

我的工作台：属于企业版功能，开源版本是没有的，申请企业版试用入口为：
https://metersphere.io/enterprise.html。

测试跟踪：包含测试用例创建与管理、用例评审、测试计划跟踪与缺陷管理。这个模块可以让用户创建/导入功能用例，包含评审功能。这样就可以打通测试、研发、产品经理及项目经理的部门墙，让多方人员共同参与，在前期就可以杜绝不合理的需求。评审完的用例可以整理成一个测试计划进行执行，测试计划包含功能用例、接口和性能测试用例。测试计划也可以通过定时执行及 Jenkins 触发的方式执行，也可以在测试中建立 Bug 与用例的对应关系，这样就很好地把当前的测试资产给串联起来了。

接口测试：这个模块最让我惊喜的就是建立起了 API 与 Case 的关系，大大缓解了我们测试资产堆积的窘境。把所有的测试用例资产以 API 与 Case 的关系进行层级关联，点击 API 之后，自然就可以看到所对应的 Case。另外，这个模块还包括接口测试及场景化测试的执行，做到了管理及执行一体化。

性能测试：MeterSphere 底座用的是 JMeter，用户可将接口测试一键转化成性能测试，当然你上传自己的 JMX 及 CSV 文件也可以创建性能测试，并且可以自动生成报告。

报表统计：展现项目用例趋势及用例状态统计。

项目设置：展现当前项目中的信息及所用到的文件，从而方便调用。

系统设置：包含用户及工作空间管理，也可以配置消息与钉钉、企业微信打通，还支持配置外部需求，对接 Bug 平台，例如 TAPD、JIRA、禅道等。

■ 创建功能用例

进入 “测试跟踪” 模块，进入 “功能用例” 可以导入及创建测试用例。根据提示填写基本信息、步骤详情，也可以编辑与其他功能用例的依赖关系，关联与其他接口、性能测试的对应关系，还可以上传附件等。

■ 用例评审

之后就进入功能评审阶段了。这个也是我很喜欢的一个功能，让研发、测试甚至甲方爸爸都可以共同参与到项目评审阶段。每个人都可以留下评论，在评审阶段就消除了不合理的需求，减少了后续返工的可能。这样就能有效解决我前面提到的 “局部高效不等于业务高效” 的问题。

用例评审完成后，评审通过的用例就可以认为这个用例是可以执行的了。接下来就可以进行测试计划了。这个流程是比较契合整理逻辑的。

另外，“接口测试” 模块展现了 API 与 Case 的层级关系，这个功能真的帮了我的大忙。

我拿/userlogin 这样的一个接口给大家解释一下。显而易见，这是个用户登录的 POST 方式的接口，我们输入{username:$username,Password:$Password}的 data 组测试，测试通过之后 API 层级的就结束了。

但熟悉测试的小伙伴肯定知道，更大的工作量在于后续的不同情况的 Case 级别测试。就比如还是拿刚刚的/userlogin 接口举例，我们使用正确的用户名、密码测试成功后测试就结束了吗？显然没有，我们还要尝试错误的用户名密码登录，是否能正常返回错误信息，空密码登录是否会提示 “Please enter password”。如果只允许密钥登录的时候，输入正确的密码登录是否会生效等。

可以说就简简单单的一个用户登录 API，就会衍生出几十种方法，久而久之这种 Case 的堆积就会耗费很多人力去管理。你说不管理吧，以后要用到难道还要重新写吗？你说管理吧，高昂的管理成本谁去承受呢？

MeterSphere 就很好地解决了这个问题。它把 API 与 Case 变成了父子层级的关系，首先我们通过 Swagger UI 导入 MeterSphere 的 API，找到/userlogin 接口，可以看到 API 与 Case 两个维度。

点击进去之后我们创建两个 Case，分别表示 “输入正确的用户名密码，是否正常显示登录成功” 以及 “错误的用户名密码是否正常显示登录失败”。可以看到正确的用户名密码，Case 是执行成功的，输入错误的用户名密码，预期返回错误的 Reponse Code，也是显示执行通过的。

■ 正确的用密 Case

■ 错误的用密 Case

也可设置断言规则，指定此 Case 预期输出的 Response Code 值就是 500，这样即使执行失败，但在 Case 执行层面也是判定为成功的。

■ /userlogin 对应的 Case

这样我们从以前的 API 和 Case 并行的层级变成了如今 API 和 Case 一对多的关系，简便了我们对用例的管理，增强了复用性。并且，MeterSphere 平台化的特点让我们所有用户的测试资产都可以统一、持久化地保留，达到我前面所说的 “测试持续高效” 的理念。

MeterSphere 也支持接口用例的场景化编排。当经过了 API 和 Case 两层的测试之后的接口，即可认为连通性没问题，并且可以在不同极限情况下都能返回预期值。我们就可以去测试接口之间的联调及传参的场景了。

另外，比较让我惊喜的就是 MeterSphere 的接口测试可以一键转换为性能测试。这样就不用再每次从 Postman 测试完之后，把脚本、接口信息等再复制一份到性能测试工具中，不用再考虑两个工具之间脚本函数兼容性的问题了，大大减少了学习成本及上手难度。

■ 接口测试转化为性能测试

■ 自动生成 JMX 文件

总结

本次试用下来，我认为 MeterSphere 是一个很适合中大规模团队的测试平台工具。它可以很好地将测试资产进行层级管理，涵盖了性能测试、接口测试、功能测试的基础测试能力及用例管理。并且，基于 MeterSphere 本身平台化的能力，可以将用户数据用工作空间、项目维度进行分类，保证了数据的共享和隔离。

不过，MeterSphere 项目目前开箱即用的协议不多，只支持常见的 HTTP、TCP、Dubbo 及 SQL 形式，性能报告也比较简单，没有包含 JMeter 的高级配置图表。期待未来 MeterSphere 的产品团队能在这些地方进行优化。