Menu Close

MeterSphere用户访谈录:微洱科技

用户访谈

MeterSphere × 微洱科技

编者注:本次用户访谈的受访嘉宾为微洱科技测试工程师邱佳桂,花名大牙。

微洱科技成立于2016年,是国内致力于让机器理解人类语言的人工智能高科技企业。微洱科技基于人工智能、区块链、大数据等前沿技术,专注于企业智能化(AI)应用解决方案的研发与实现,目前已成功开发出小微全域智能机器人等核心产品,为企业智能化转型提供技术、产品和解决方案支持。

从大数据、算法、开发等核心业务团队,到小微机器人、小程序、插件等面向顾客的各种软件产品,以及公司内部的各种OA系统,都离不开测试团队的持续投入。随着系统的日益庞大,提升整体的研发效率和稳定性,是我们一直在思考和探索的方向。

测试团队的痛点

微洱科技的测试团队从公司成立之初就一直存在,目前有超过25人的规模。经历了这么多年的扩展,团队已经构建了相对完整的研发、测试、压测流程。但是在实际的流程落地中,我们还是面临了非常多的痛点,比如:

  • 测试用例零散杂乱,复用率低,往往是一个迭代一套用例,较少维护原有用例;
  • 测试进度不够直观,依赖测试同学书写项目日报,测试同学自己评估项目研发进度,报告测试风险可能出现不及时的情况;
  • 手动测试占据了大部分的测试时间,较少时间去进行接口测试和性能测试。而且在手动测试的时候,可能出现漏测,或者缺少性能测试,导致在线上环境出现性能问题,例如慢SQL、机器资源飙升等风险事件;
  • 性能压测时,大家使用PTS也好,JMeter也好,JMX文件的复用率也很低,大多是测试同学各自书写。特别使用JMeter时,更是缺少可靠稳定的可视化场景管理。使用PTS时,长期的费用是一笔不小的支出;
  • 测试经理无法直观地了解测试同学做了哪些测试工作,是否做过性能测试、接口测试等,只能依赖口头描述;
  • 线上出现问题时,复盘定位问题时,测试同学难以拿出有力证据证实是否确实覆盖到该问题。

从上面的这些痛点可以看出,其中很大一部分是与整合测试团队管理及自动化测试相关。除了团队自身能力和人员建设外,一款合适的测试工具也是解决以上痛点的重要一环。

我们期望的测试平台

我们一直在寻找一款适合我们的测试工具,它需要符合以下特征:

  • 平台集成度高,可以开箱即用。最好是开源的,且有成熟可靠的社区和团队,我们自身可以二次开发,也可以大家一起维护服务;
  • 测试模块不仅仅只有测试用例,还应该有性能测试,支持分布式施压,最好是JMeter,这样原有的JMX文件可以上传和管理;
  • 测试的资源以及目前的测试进度等可以直观地展示,方便测试经理进行统计和管理。

我们的团队一开始考虑的是自研测试平台,但是开发周期会比较长,也不能立即使用测试平台。2020年10月,一个偶然的机会看到了MeterSphere v1.3版本,考虑到我司也是一直在使用JumpServer堡垒机,对于FIT2CLOUD飞致云和社区一直非常信赖,再加上MeterSphere测试平台的每月迭代,我们决定借用FIT2CLOUD飞致云和开源社区的力量推动自身测试团队的测试能力。

我们使用MeterSphere的情况

目前我们对于MeterSphere开源持续测试平台的使用处于边开发、边试用推广的状态。总结下来包含以下几个方面:

■ 项目质量

我们的研发流程工具是Teambition,但是Teambition的统计数据页面做得不是很符合我们团队的要求。为此我们构思了项目质量统计页面,根据不同的业务线来调用Teambition接口,实现研发任务的统计和维护,生成项目质量周报。

图1 基于MeterSphere平台构建项目质量统计页面

■ 静态代码质量

不单单是研发任务,我们的测试团队还特别看重开发团队的代码质量,因此兼容Sonar也成了我们必须要做的任务。但是在兼容Sonar的时候,我们发现了一个问题。因为我们的构建部署平台是自研的,从部署平台回调MeterSphere取Sonar扫描数据的时候,会有较大概率出现时间差,再加上我们的Sonar是社区版本,因此扫描数据和MeterSphere平台查询数据可能会出现不准确的情况。最后的解决方案是部署平台通过回调直接返回Sonar扫描数据,MeterSphere不再主动查询Sonar。

图2 基于MeterSphere平台监控静态代码质量

 接口自动化

在使用MeterSphere之前,我们已经有了自己的接口自动化方案,也就是Python的接口自动化。作为独立的Python服务,为了最大限度地兼容,我们二次开发了接口自动化统计页面,实现了接口自动化服务和测试平台的兼容。

图3 基于MeterSphere平台进行接口自动化统计

 性能测试

JMeter压测模块:MeterSphere的性能测试也是我们很看重的一个模块。因为我们对于压测的需求特别大,更迫切地需要可视化的压测模块来帮助我们。在MeterSphere平台上,通过导入已有的JMeter脚本和CSV文件,既实现了既有资源的复用,又达到了对压测脚本统一管理的效果。同时,MeterSphere还可以方便地管理压测节点,水平扩大压测节点。

图4 基于MeterSphere平台进行性能测试

Locust压测模块:在原有的JMeter压测模块上,我们加入自身的Locust(主从模式)模块,页面化管理了自身的压测场景,压测报告通过Grafana来实现。

图5 基于MeterSphere整合Locust模式压测场景

■ 测试小工具

因为自身业务特点原因,我们的测试同学们在日常工作中常常需要用到一些小工具。比如分库分表规则查询工具、Redis的Key记录规则等。因此我们也基于MeterSphere开发了属于自身的测试小工具。

图6 分库分表规则查询工具
图7 测试日报工具

MeterSphere 带来的收益

过去的几个月中,我们团队其实一直处于二次开发的进度中,目前也依然处于推广和迁移测试资产的进度之中。但在这短暂的时间内,MeterSphere平台依然给我们发挥了相当大的作用。总结来说包含以下几个方面:

  • 最明显和最直接的作用是目前有了质量大盘,通过质量大盘我们可以一目了然地看到研发任务、开发代码质量、接口自动化的各自统计视图;
  • 其次是一直在培养和迁移大家使用MeterSphere的习惯。在试用MeterSphere的时候,我们能够较为方便地管理和测试用例,测试经理可以方便地统筹和管理测试同学的测试任务;
  • 最后,我们逐渐将原有零散的用例向MeterSphere平台进行迁移,充分利用其管理能力和复用能力。当用例积累到一定规模后,可以快速展开冒烟和回归测试。
Posted in 案例