九里云（深圳）科技有限公司是一家近百人的创业型公司，主营业务是为融资提供担保服务。因为金融业务本身的特性，对业务敏感功能要求进行充分测试，并针对业务敏感场景进行防重复测试、接口并发测试以及每个版本正式发布之前的回归测试，以确保系统数据的准确性以及服务的稳定性。
目前九里云测试团队规模在10人左右，测试内容以Web服务端为主。测试完成后还需要经过UAT、联调、部署上线等流程。
使用JMeter作为自动化接口工具的缺陷
为了提升测试质量和效率，接口的自动化测试成了必然选项。我司曾引入JMeter来作为自动化接口实现工具，并采用主流的“Jenkins+Ant+Git+JMeter”搭建自动化测试框架。在一定程度上，这样做确实提升了测试的效率，但是随着后续深入地使用，一些天然的缺陷也逐渐暴露出来，主要表现为以下几点：
1. 多人协作难
测试团队中不同岗位角色可能由多人负责，这就涉及到多人协作，例如：JMeter测试脚本是由整个测试团队共同编辑和维护，这就涉及到JMeter脚本的版本管理和协同的问题。为了解决这个问题，引入了版本管理工具Git，但由于工作习惯的问题，实际落地效果并不好，团队成员还是习惯在本地去编辑维护自己的个人脚本，并带来版本覆盖、流程过重等其他问题。
2. 测试执行关联难
JMeter作为测试执行工具，在测试协议支持、编辑、调试等方面的能力是完整的，但它无法同需求、用例等进行关联绑定。因为JMeter本身就是一个测试执行工具，缺少用例、测试跟踪、用户管理等统一能力。从质量团队的角度来说，我们肯定希望将JMeter的每个脚本同对应的需求，以及用例绑定起来进行管理，自动在测试报告中进行展现，而实际却难以做到。
3. 使用规范难
JMeter已经有各种丰富的开源插件，导致工具本身比较灵活，还另外需要配套的规范让整个团队统一风格。
由于上述原因，虽然我们团队已经初步实现了接口的自动化测试，在测试效率方面有所提升，但是存在的一些原有框架内无法解决的问题，导致落地后的整体与我们的期望还有一定差距。
2020年12月，在同事的介绍下开始了解MeterSphere这款软件，看完整个官方文档后，对它产生了极大的兴趣，它几乎涵盖了我们测试团队对测试工具软件的绝大部分要求。下面我分享MeterSphere在我们团队中落地的实践经验。
持续测试思想的引入
如果让我对测试工具来进行分类，可能会有两类；一类是Easy-Mock、Postman、JMeter；另外一类是Jenkins、Git。它们的最大区别就是有些工具会引入一些思想和方法。比如Jenkins所提倡的持续集成、持续交付、持续部署思想，Git带来的版本管理和多人协同的方法；而作为对比，Postman、JMeter等就是单纯执行工具了。通过工具引入的一些思想和方法，不仅会指导我们如何正确使用工具，还有利于优化整个工作模式。
而对于MeterSphere这款工具来说，它更偏向于Jenkins、Gitlab那种类型，它不仅带来了一整套测试执行工具，还引入了持续测试的理念，并且给出了非常具体的持续测试成熟度模型维度标准，这对我们团队后续工作开展带来了指导性方向。
一站式的测试平台
对于质量团队来说，测试工具的建设很大程度上决定了整个项目的测试效率和整体质量。对于测试平台来说，常见的有两种建设方式，一种是引入一些常见的测试工具，比如JMeter、Postman、禅道等；另一种是组建专门测试开发团队，针对公司当前的研发模式，设计和编写适配的研发平台及测试工具。两种方式各有优劣，在这里就不细说对应的优缺点了。
而对于MeterSphere来说，这个平台集成了从测试计划到测试执行、测试报告的不同阶段功能，并且其产品规划中，会将该平台打造成一个一站式的测试平台，并支持自己编写工具集成到平台中，真正实现一站式，并且还是开源免费的。这对于一个创业型公司的质量团队来说真的太棒了。目前我们团队通过MeterSphere平台使用到的功能有：
■ 系统设置
■ 测试跟踪
■ 接口测试
■ 性能测试
■ 接口自动化
■ 集成Jenkins、钉钉等
MeterSphere使用流程和规范
我们基于此平台，编写了一套适配我们公司实际情况的使用规范和流程。首先是用户、组织和工作空间的使用，在MeterSphere平台中，组织和工作空间是个逻辑上的架构划分，可以灵活适配不同的组织架构。我们根据团队的组成以及实际测试的习惯对用户、组织、工作空间指定了如下命名规范：
■ 【测试人员】ID和姓名均设置为自己的名字全拼，角色分配为管理员；
■ 【非测试人员】ID和姓名均设置为自己的名字全拼，角色分配为只读用户；
■ 【组织】只新建一个组织，并以公司名为组织名称，组织添加测试组人员；
■ 【工作空间】工作空间命名为“质量支撑组”，工作空间添加测试组人员；
■ 【项目】根据需求创建项目，命名方式为“需求名称项目”；另外增加一个项目名称为“自动化接口项目”；
■ 【自动化接口项目】所有通过的测试即接口需要放置于该项目下，用于自动化接口测试。
对于接口和性能自动化测试规范，我们质量团队也指定了对应的流程和执行策略：
1. 将已经测试通过的接口测试或者性能测试，根据需求的测试维度创建一级模块。
2. 在对应的模块下，添加测试用例：
3. 创建测试计划。
4. 给测试计划关联测试用例。
5. Jenkins配置自动化执行Job。
6. Jenkins配置执行策略。
【执行时间】：每天凌晨3:50左右执行；Master分支如有更新，接口和性能测试都执行；
【执行环境】：默认为测试环境；
【执行结果通知】：如Job构建失败，以邮件的方式通知并附带测试报告，测试报告将直接展示在邮件内容中；以钉钉的形式通知测试组成员并附带测试报告链接；
【执行结果通知对象】：测试组成员及对应开发负责人。
下图是我们公司质量团队内部整理并执行的MeterSphere使用流程和规范的内容概要。如果您感兴趣，可以到以下地址详细查看：
网盘地址：
https://pan.baidu.com/s/1kGuX7E2z9F9iQxqH6nU9Aw
密码: 1ltb
小结
最后总结一下整个MeterSphere使用体验。在使用的过程中，切身感受到MeterSphere项目团队对于版本更新速度还是很快的，缺陷修复也很及时，希望继续保持~
作为创业型公司的质量团队，MeterSphere一站式开源持续测试平台给我们团队带来了自研工具的感觉，希望能够和 MeterSphere一起成长，持续不断地提高测试质量和效率。
编者注：本文作者为九里云（深圳）科技有限公司质量团队李sir，文章转载自知乎。