编者注：本文为CSDN博主weixin_41974278的原创文章。
原文链接：
https://blog.csdn.net/weixin_41974278/article/details/124174009
自我介绍一下，我是某医疗行业公司的测试团队Leader，带领着一个5人测试团队。这个团队主要负责公司产品的测试工作，包括App测试、黑盒测试等，还会配合研发部门进行部分白盒测试。
由于产品迭代周期较短，导致平时上线前测试任务繁重，忙于工作后也没有什么时间静下心来好好思考。碰巧这次疫情被强制在家隔离，工作任务顿时少了很多，正好趁着这段时间静下心来好好回顾一下工作上所遇到的问题，也算“因祸得福”吧。
我们团队都是工作三年以上的准资深测试工程师，平时都会用Postman、JMeter进行接口、性能测试，自认为我们测试部门的工作效率还是不错的。我们研发部门的同学也不乏技术大牛，代码能力很强，研发效率也是很高的。从内部资源的视角来看，功能研发、功能测试、性能测试、需求评审等每个环节的效率都很高。但从业务视角来看呢？那就是另外一回事了。
在测试工作中面临的实际问题
首先，我们面临的问题是效率集中在局部，且难以持续。
站在用户的视角上看，用户都是希望能尽快实现他们的要求或者需求，解决他们最迫切需要解决的问题。但是当我们切换到这一视角时，尽管我们内部认为局部效率不错，但用户的感知是不一样的。也就是说，局部效率不一定带来高效的产品交付。
我们作为一个组织，是不是能够把各个局部的效率转化为高效的交付？其中部门间的协作、研发质量、测试质量、是否需要返工，都会导致“局部效率不等于高效交付”。当然，以前为了解决高效交付的问题，通常会在上线前，或者做项目时临时成立项目交付团队，工位也靠得很近，以此来解决交流的问题。这样确实达成了一时的高效，但这种高效是不可持续的。
第二，我们所拥有的测试“资产”是零散且陈旧的。
站在我们测试团队的角度而言，我们维护的测试用例在将来是可以重用的，并且在重用的时候不会产生质量问题。我们习惯叫这些东西为“测试资产”。
既然称作为资产，那么我们肯定希望它们是能够产生正向利息的。但在现实中，它们对我们来说往往不是资产，而是负债。我们花了很长的时间去维护，但却没有很好地持续累积资产。我们团队的测试用例都四散在各地，有的在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的产品团队能在这些地方进行优化。