九里云(深圳)科技有限公司是一家近百人的创业型公司,主营业务是为融资提供担保服务。因为金融业务本身的特性,对业务敏感功能要求进行充分测试,并针对业务敏感场景进行防重复测试、接口并发测试以及每个版本正式发布之前的回归测试,以确保系统数据的准确性以及服务的稳定性。

目前九里云测试团队规模在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. 在对应的模块下,添加测试用例:

小结-LMLPHP

3. 创建测试计划。

小结-LMLPHP

4. 给测试计划关联测试用例。

小结-LMLPHP

5. Jenkins配置自动化执行Job。

6. Jenkins配置执行策略。

【执行时间】:每天凌晨3:50左右执行;Master分支如有更新,接口和性能测试都执行;

【执行环境】:默认为测试环境;

【执行结果通知】:如Job构建失败,以邮件的方式通知并附带测试报告,测试报告将直接展示在邮件内容中;以钉钉的形式通知测试组成员并附带测试报告链接;

【执行结果通知对象】:测试组成员及对应开发负责人。

下图是我们公司质量团队内部整理并执行的MeterSphere使用流程和规范的内容概要。如果您感兴趣,可以到以下地址详细查看:

网盘地址:

https://pan.baidu.com/s/1kGuX7E2z9F9iQxqH6nU9Aw

密码: 1ltb

小结-LMLPHP

小结

最后总结一下整个MeterSphere使用体验。在使用的过程中,切身感受到MeterSphere项目团队对于版本更新速度还是很快的,缺陷修复也很及时,希望继续保持~

作为创业型公司的质量团队,MeterSphere一站式开源持续测试平台给我们团队带来了自研工具的感觉,希望能够和 MeterSphere一起成长,持续不断地提高测试质量和效率。

编者注:本文作者为九里云(深圳)科技有限公司质量团队李sir,文章转载自知乎。

05-21 18:16