开源测试工具 流马测试平台 1.1 发布,除了新增 APP 测试还有更多更新

Chras · 2023年03月08日 · 最后由 xianghybb 回复于 2023年07月26日 · 9156 次阅读

前言

流马开源已有大半年,目前有多家公司或团队已经在内部落地使用了,不少用户都咨询作者何时上线 APP 测试。作者原计划去年底发布,中间因为私事耽搁,直到今天算是正式发布 1.1 版本,本次更新内容将在下面详细介绍。

正文

一、重要更新 - 设备管理和 APP 测试

之所以称之为设备管理而不是云真机,是因为云真机所需要提供的能力太多,而目前 1.1 版本的设备管理仅仅提供设备挂载、远程投屏、在线操作、控件元素以及用例调试,离云真机之能力相去千里。未来流马也不会在云真机能力上投入太多,一来本平台主要定位于提供更便捷易用的自动化测试能力,二来云真机方向已有太多优秀的开源或商业项目。

APP 测试的驱动主要基于 ATX 提供的 UIAutomator2 和 Facebook-wda 库,在此先感谢 ATX 组织的无私开源。之所以不选择 appium 这个更主流的框架,主要因为该项目过于沉重,不便于用户搭建环境,与流马轻量级架构相悖。另外一点是 ATX 的库更方便二开,为后续不断扩展新能力提供更多可能性。

同时,与 web 测试相同,采用低代码模式编写测试用例,让更多的人参与到自动化测试建设中来。此外,平台提供自定义操作组件的能力,无需二开平台就可以完成很多自定义的功能,让懂代码的人能做更多的事情。另外提一点,APP 用例支持与其他类型的用例在同一测试套件中顺序执行,结合 API 用例的便捷造数能力和数据回收能力,让 APP 测试用例设计更加方便。

图片演示

本次更新新增了除平台和引擎端的另一个项目,即设备挂载端,主要代码继承于 atx(源码文件中注有版权声明),在此基础上做了一些删减和增强,如安卓投屏替换为 scrcpy 等。设备挂载项目既可以用来服务器上搭建机群,也可以轻松本地 win/mac 启动,只需拥有 python 和 node 环境即可。

题外话,秉持着服务于中小企业做自动化测试的原则,搭建大型云真机机群的所需投入成本过高,反而去中心化的方式我认为更适合利用起来闲置手机,设备即插即用做测试,更为灵活。当然这些仅作为我的个人看法,欢迎一起探讨。

二、持续集成

本次迭代做了一些持续集成的功能,主要包括以下三点:

  1. 支持配置飞书/钉钉/企微的群聊机器人通知,同一项目下任意配置群聊,不同测试计划的执行结果支持发送到不同群聊。
  2. 支持 SMTP 协议的邮件发送服务,企业邮箱也好,163/qq 邮箱也可,只要开启 SMTP 服务即可使用。
  3. 支持 OpenAPI 调用执行测试计划以及获取相应测试结果,便于 CI/CD 集成。

三、其他增强和优化

1.1 版本拖更有几个月,在此期间做了很多增强和优化功能,例如:

  1. 接口用例支持自动生成接口字段校验的健壮性用例,主要针对字段的必填性、边界值、字段类型等属性进行校验,界面化操作生成,自动解析 json,无需编写复杂的配置。
  2. 接口管理支持 postman 和 swagger 接口的导入,让接口初始化更方便。
  3. 支持 docker 一键部署,让用户能够更快的搭建环境使用起来。
  4. 前后置脚本,自定义的系统函数均支持操作变量空间,让一些复杂的业务场景更灵活化。
  5. 测试计划的执行并发数支持配置化,更大程度上的利用执行资源。

当然还有很多优化功能和易用性的小点,这里不做赘述。其实很多小的功能点都来自用户建议,作者都在第一时间进行评估和落地,流马的架构可扩展性很强,欢迎更多的人参与进来,无论是提供建议还是提交代码。

最后

附上流马官网地址、演示平台地址以及源码地址,欢迎用户体验,如有部署或使用问题可查看官网手册,也可在官网社区提问交流。当然也欢迎大家加入微信群,一起交流技术问题。群聊二维码在官网最下方,定期更新。最后,希望大家能在 github 点点 Star 给予支持,感谢!

官网地址:流马官网
演示地址:演示平台
源码地址:GITHUB

共收到 13 条回复 时间 点赞

补上演示平台的账号密码:demo/123456

App 测试的啥文档都没么?

刚刚看了一下你的平台,如果做为练手的还可以,但是要做成产品的话,差的还太多。结合着真实的使用场景去优化一下,WebUI 和 AppUI 是很难用平台去写用例的,不建议往这方面去做,因为在真实的产品中根本无法使用。

Chras #10 · 2023年03月08日 Author
徐汪成 回复

文档还在补充,web 测试和 app 测试使用方法差不多

爱偷懒的QA 回复

首先呢,这个平台的定位是帮助中小企业快速实现自动化。当然我不知道您所在的公司是什么规模,测试基建做到什么程度,所以高屋建瓴般说出差太远的评价。
不过该平台只是作为 devops 其中的一环,甚至只是提供自动化测试的能力,只要能集成进去就可以。如果我把项目管理、需求管理、测试管理等等这些东西一股脑的都做进来,那必然将是一个很臃肿的系统,成本也必然随之升高,参考一些平台就知道了,好不好用用过的都知道。至于其他测试基建相关的能力和技术,在企业内部都有做过,只是那种更需要量身定制才能发挥作用。
个人认为自动化测试平台就应该是个小而美的工具平台,而不是搞臃肿不堪的一站式,至少目前我是没见到好用的,反而我这个平台在现有用户群体里口碑还算可以,当然我这个平台目前易用性和交互体验也还有很多提升空间,我也在慢慢完善。
或者说如果我对大佬的差太远理解有误,也欢迎大佬举例说出一两个地方让我学习学习?

还是走的 wda,不卡么?

爱偷懒的QA 回复

抛开技术不说,大哥你说话真的贼难听 你自己读一次

干饭狂人 回复

投屏确实不是那么流畅,不过我也不是做云真机服务的尚能接受。至于测试执行的话,目前还没接触过更好且更合适的底层驱动了,如果后续发现更优秀的技术也可以引入进来。

50how 回复

我没感觉哪儿难听,我也接受批评和质疑,但总要告诉我具体不行的地方,而不是光嘴说一句差得很,何况还不是第一次呢?

看着不赖

爱偷懒的QA 回复

可以说下具体的内容,交流下思想

ZYH 回复

根据我做了十多年的测试开发的经验来说,做过了不少尝试,也见过很多大公司类似的产品。只所以说不要做 WebUI 和 AppUI 的自动化的平台化功能,主要是这是要考虑一个投入产出比的问题。

这方面做的还算可以的,是淘宝的一个测试平台,名字就不说了,内部平台。他们成功的原因有如下几个前提:
1,被测试 App 和 Web 是组件化开发,组件是不变化,页面是组件的组合;
2,强大的图像识别服务,有一个团队专门提供这样的服务,识别的准确率较高;
3,以组件为单元进行开发和组织测试用例,而不是以元素。
如果你要测试的应用没有这样的前提,想做成平台化,后续维护起来就非常耗时。举个例子,如登录功能,你要测试的应用有多个地方可以登录,而登录操作的元素都不一样,那就要写多个公用的操作。平台化写用例,还不利于封装和公用,投入产出比较低,所以很多公司不会这么做的。
如果想做 UI 自动化做成平台,可以考虑平台关注以下功能:
1,测试资源的管理,如测试环境,手机设备,测试帐号等;
2,任务调度,灵活生成测试计划,定时执行任务等;
3,测试报告及结果分析,分析执行的结果,失败的原因,最近或是各个版本的执行情况及趋势等;
4,用例的编写和执行,还是交给具体的测试框架来完成,不要用平台来做。
个人经验,仅供讨论!!!

感觉很不错,大佬牛逼,就是指导文档好像打不开了😂

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册