SoloPi SoloPi:支付宝开源的 Android 专项测试工具

烧碱 · July 11, 2019 · Last by 大荔秦川牛 replied at July 18, 2019 · Last modified by admin 陈恒捷 · 3523 hits

1. 前言

近年来,随着移动互联网的蓬勃发展,移动测试技术也取得了长足的进步,从早期基于测试脚本的单机自动化,到录制回放、图像识别、云测平台等测试技术贴合实际业务需求深度应用和创新,测试效率从而一次又一次被提升。

1.1 移动测试 1.0 时代

移动测试 1.0 时代,也可以称之为探索期。由于厌倦了日复一日的手工操作,如何提升测试效率成为了移动测试领域最重要的课题,在此期间,除了 Monkey、UiAutomator、Instruments 等官方提供的工具,业界还涌现了一批优秀的开源自动化测试工具/框架,在自动化驱动能力的基础之上,不仅可以实现基本功能的验证,还可以结合性能采集方案、遍历算法等实现各类专项测试的自动化。在这个阶段,自动化测试的常见形态是在单机或本地少数几台 PC 上部署测试环境,再利用 Jenkins 等工具实现持续集成。

1.2 移动测试 2.0 时代

伴随着测试技术的持续发展、又得益于 STF 的开源,业界开始出现了云测平台的概念,将真机设备、任务管理、自动化框架以及专项测试方案打包在平台中作为服务提供出去,给用户带来了一站式的测试体验。另一方面,远程调试、设备调度等技术的引入极大的提升了设备的利用率,测试人员不再需要为缺少测试设备或测试任务排队耗时而担心。对于云测平台用户而言,在此阶段常见的测试形态是:在本地 PC 上开发测试脚本,再上传至云测平台执行,最后可在平台中查看测试报告,测试流程简单且清晰。

1.3 移动测试 2.0+

在保留了上述“云测”的玩法之外,移动测试 2.0+ 时代下的测试技术提供的往往不再是某一个独立的小工具,更多的是带来一套完整的解决方案,例如为用户提供一套定制化的 IDE 环境,结合录制回放、图像识别等技术,用户可能只需要做一些简单的框选、拖拽就能完成测试脚本的开发。另一方面,由于办公环境、硬件条件等因素的限制,越来越多的测试人员希望可以在移动端上直接发起测试,做到移动测试“移动测”。当然,无论是云端、IDE 端、还是移动端,都应该做到能力互通,即“多端多通”,这样才能让测试方案更加灵活、适用于更多场景。

2. 无线驱动的 Android 专项测试方案:Soloπ

“多端多通”的概念比较广,仅凭一篇文章可能无法阐述清楚,所以下面将会重点介绍为了迎接“移动 2.0+”时代,我们在移动端上实现的一套无线化、非侵入、免 Root 的 Android 专项测试方案 Soloπ。直接操控手机,即可实现自动化的功能、性能、兼容性、以及稳定性测试等工作。

2.1 整体架构

这套方案中,底层依赖主要是“无线 ADB、系统辅助功能、Chrome 调试以及图像识别技术”,后文将会介绍它们具体的应用场景。同时,在底层依赖的基础上,我们封装了一套核心能力,由“控件定位、事件驱动、性能采集以及依赖注入”组成,并在服务层实现了录制、回放、数据处理等公共服务能力。在架构的最顶端,结合界面交互逻辑包装出了各个功能的入口。

2.2 无线 ADB 方案

大家都知道,对于 Android 自动化,ADB shell 的执行能力是一切的基础。

在 PC 上,通过 Android SDK 提供的ADB client 与同样运行于 PC 中的 ADB server 通信,再由 ADB server 通过 USB 与位于设备中的 Adbd 通信。要实现一套无线化的方案,必须要摆脱对 USB 线的依赖。好在 Android 系统还提供了一种基于 Socket 的 ADB 连接模式,既然是这样,那么只需要按照 ADB 通信协议在端上与本机的 5555 端口进行通信即可获得 ADB shell 的执行能力。

目前已经有一些实现 ADB 通信协议的 Java 开源项目,如 AdbLib ,他们封装了一套 ADB 的调试通信服务,能够替代 PC 上 ADB Server 的角色。我们在Soloπ应用中集成了 AdbLib 开源库,包装成一套 ADB 命令执行工具,为 Soloπ 后续各种专项测试能力的实现奠定了坚实的基础。下面将开始为大家介绍 Soloπ 的几大核心功能。

2.3 录制回放

录制回放功能基于 AccessibilityService、ChromeDevToolsProtocol、图像识别三种模式实现精确查找,可以在设备本地实现回放,也可以转换为 Appium/Macaca 等框架的脚本,对接云测平台。另外,为了降低用例维护的成本,我们在端上还提供了用例编辑、流程控制的功能。

2.3.1 实现方案

在录制过程中,Soloπ 会对用户的操作进行拦截,识别用户操作的位置,高亮当前操作的控件,记录用户当前要做的操作类型,在每一步操作后,将操作类型及目标控件的各种信息都记录下来。这里的控件信息包括控件的 ID、文字等基本信息,以及相对布局、截图信息等。

在回放时,Soloπ 会逐条解析之前录制的数据,通过智能查找算法,综合各种属性,定位目标控件,找到控件后,就会执行相应的操作,如点击、滑动等。在所有步骤执行后,会展示本次回放的结果,包括日志、截图等信息,作为本次回放的总结。

2.3.2 控件查找能力

对于传统的 Native 应用,通过 UiAutomator dump 获取的属性就足以实现自动化了。然而,随着移动端动态化能力的稳步发展,越来越多的应用采用了 “Native + H5/小程序” 这种混合开发的方案。再考虑到近年来手游行业的飞速发展,手机游戏自动化测试的需求也越来越多。为了尽可能的适配各种场景,Soloπ 提供了三种查找模式:

第一种方案不必多说,核心就是基于 AccessbilityService 生成当前控件视图树,并记录下id、文字等属性,适用于 Native 场景
第二种方案基于 Chrome 的调试协议,通过注入js可以获得页面布局以及各元素属性,控件的定位思路与辅助功能这一套方案是一致的。适用于 H5/小程序场景。
第三种方案是图像匹配方案,Soloπ 在端上实现了一套图像比对能力,结合了模板匹配、特征匹配等算法,并做了一定的适配和调优。适用于游戏自动化的场景。此外,在 Soloπ 目前的方案中,图像匹配能力还会作为前两种定位方式的兜底方案,进一步的提升控件查找的准确率。

2.3.3 回放能力

通过 Soloπ 录制的用例会以 JSON 的形式存储起来,用例不仅可以向上述视频演示的一样在设备本地直接回放,还可以通过 Soloπ 的解析器将用例转换为 Appium、Macaca 等目前主流自动化测试框架的脚本,轻松打通云测平台。另外,得益于文本抓取和图像识别能力,Soloπ 还实现了在 Android 端录制一遍用例,生成的脚本能够同时在 Android、iOS 双端回放的能力。

2.3.4 更多功能

Soloπ 还提供了用例步骤的插入、删除、修改等用例编辑功能,可以有效降低用例的维护成本。另外,Soloπ 还引入了循环、条件等流程控制能力,若对用例进行合理编排,可轻松实现需要重复操作的工具脚本或是需要暴力回放的稳定性测试脚本。

录制回放更多的能力还包括结合数据 Mock 解决用例回放不稳定的能力、打通性能测试的能力等等。

2.4 一机多控

在各类专项测试中,兼容性测试是最为耗时费力的一项,测试人员需要关注各种系统版本、各大手机厂商,各种类型的屏幕等等,想要通过纯人工测试来保证兼容性测试的质量成本是非常高的。

Soloπ 在录制回放能力的基础上实现了一套兼容性测试的解决方案。在录制回放的场景中,我们先是在一台设备上记录了用户的操作,然后再在任意一台设备上实现操作的回放。如果把场景扩展到多台设备上,就可以实现通过一台设备操控多台设备,我们把这套功能称为“一机多控”。具体说来就是主机与从机建立 Socket 连接,然后在主机上将用户的操作实时发送到各个从机,在从机上完成操作的回放。

一机多控的环境搭建比较灵活,手边的手机在安装 Soloπ 后,通过简单的建联操作即可完成部署。一机多控适配了目前市面上主流机型和 ROM,并封装了一些提升测试效率的快捷功能,如应用安装、数据清理、设备信息查看等等。

2.5 性能测试

提到专项测试,不得不提性能测试。近年来,手机应用成为了人们日常生活中不可或缺的一部分,这也对应用的使用体验提出了更高的要求。 为了给用户带来“丝般顺滑”的体验,仅仅实现功能是不够的,而性能测试,就是打造优质应用不可或缺的一个环节。 然而,性能测试的开展并不是很容易,一方面,性能测试具有一定的门槛,很多时候需要开发脚本去实现,还要去处理各类兼容性问题。另一方面,大多数性能测试方案获取到的都是一些基本指标,难以发现深层次的问题。针对上述问题,Soloπ 实现了一套性能测试工具。包含常规性能指标获取、响应耗时计算以及移动 Lighthouse 三方面功能。

2.5.1 常规性能指标获取

Soloπ 支持 CPU、内存、fps、流量等常规指标的实时获取,同时支持将性能数据记录下来,存储到本地并通过报表形式展示。Soloπ 还提供了数据上传的功能,可以将数据发送给服务端做进一步的处理。整套性能工具支持手动触发和广播触发,可以和自动化测试轻松打通。

2.5.2 响应耗时计算

除了常规性能指标的获取,Soloπ 还提供了响应耗时计算的功能。大家都知道,计算响应耗时的一种常用方法就是基于代码埋点或是系统日志(比如 activityDisplayed Time),但是这种方法计算得到的结果对于异步加载较多的界面来说会与用户实际的观感有比较大的偏差。

Soloπ 基于录屏分帧能力实现了一套计算接近用户体验的响应时间的方案。具体的说,在开启录屏后,Soloπ 会基于 ADB shell 的 get event 命令监听屏幕的点击事件,将其作为计算响应耗时的起点,当录屏结束后,Soloπ 会从后向前倒序对视频进行对比,查找出界面趋于稳定的时间点,并作为计算的终点,二者相减就是响应耗时。

2.5.3 移动 Lighthouse

H5/小程序等技术在移动应用中的占比越来越高,如何测试这类应用的性能成为了一个新的课题。接触过前端性能的同学都知道,Lighthouse 是前端性能测试的利器,但是它无法在手机上直接应用。而 Soloπ 所做的,就是基于 CDP 协议,在客户端中实现了一套 Lighthouse 性能测试工具,它可以获取 H5/小程序页面的启动性能、资源流耗、请求质量、JS 质量、JSAPI 调用情况与页面信息,并内置了 30 余条前端开发最佳实践,旨在发现细粒度的性能问题。

具体的实现方案,就是将 Soloπ 与待测应用建立基于 CDP 协议建立 Websocket 通信,监听页面发起请求、接收数据、开始加载等事件的回调、并收集报错、Trace 等数据。再按照启动性能、资源流耗、请求质量、JS 质量、 JSAPI 调用情况与页面信息 6 大维度进行数据的分类和整理,随后通过内置的规则对采集到的结果进行判断,最终生成报表并在界面中展示。

3. 更多

作为一套完整的专项测试方案,除了前面提到的录制回放、一机多控、性能测试外,Soloπ 还提供了数据 Mock,性能加压、网络模拟、智能 Monkey 等功能。目前 Soloπ 的部分源码已开源(项目地址:https://github.com/soloPi/SoloPi),欢迎大家加入到项目中,与我们一同开发出更好用的测试工具!

联系我们

共收到 32 条回复 时间 点赞

开源项目越来越多了,特别是一机多控,在兼容性测试里很实用。

比较好奇,一机多控,对于分辨率不同的机器,目前可以适配吗?

陈恒捷 回复

一机多控是基于控件信息,而不是坐标来查找。如果控件的一些结构、内容信息不变,就算位置出现变化,比如主控机是4K屏,从机是720P,也是能够找到的。

一机多控是空间识别, 我这里前端是unity的,貌似识别不了。还有其他办法吗

那么流弊必须fork&star。。。。。

手机用 root 吗?

zzt 回复

除了控件识别还有图像识别,能根据图像特征来查找控件

这种基于控件的操作方式,在游戏应用中要用特定的方法去接入么,比如airtest里面的poco

一机多控试了试。。。有种说不上来的感觉
感觉考虑的很周到,功能也完善。
但操作起来不顺畅,一步接着一步的操作感觉噶住了

https://github.com/alipay/SoloPi 我安装的solopi.apk怎么没有编辑用例的功能呢 是还没有开源吗?

功能很强大

我这一机多控并不是很灵,好几台设备,都是只能启动和退出。
而且,有一个问题,有可能每个设备启动app的界面是不一样的,比如,有的有弹窗有的没有,这种问题如何避免?

怎么看起楼主的头像就想起 我投简历过

Zyanbo 回复

不需要

回复

可以看看帮助文档,比如有统一处理弹窗的全局操作。

三年前实现了这样一套系统,有云端的server做中转,录制回放这块功能一致,录制和回放之间的主要矛盾是如何解决out of sync 的问题,即如果不同步了如何还能让它同步回来,这块我们有一些机制。另外,如何把录制过程做到用户透明,是个挑战。做到端上的体验还是不错的。支持一下。

启动时间这样测是不是不准确?【自动记录点击起始点,自动识别屏幕变化结束点】进入了结束页面还要等待加载,会受网络影响。而且页面如果存在动态的也会不准

工具和 手机厂商的朋友聊过没有;据我的了解 ,中兴、华为、酷派,之类的手机厂商 早在 7年前,有了无线(wifi、3G)记录手机bug平台;当然了 他们自己的手机,不存root不root的问题;我的问题是 如果有有手机厂商的朋友 可以解答一下Soloπ 就会更好,市场的手机 以前是4.5个月,一款手机,现在是2个月一款手机 (这里的手机是说 功能和体验有加大幅度优化,不是单纯的复用,另启一个名字),现有的行情 各大手机厂商都在收紧关于root、和用户体验UI设计,着这块有没有针对这个工具的计划,还是就是怕就是怕 这个工具只是 一些人的爬升职位的附属品,昙花一现

RK-7 回复

的确,起点没问题,但结束点现有的各种自动化方案都很难算准。
可以体验一下soloπ的录屏分帧,结束点靠人工手动确认(不用担心点的时机不准,因为算法会倒查视频中最早接近这一帧画面的时间点),虽然没办法全自动化,但理论上最接近高速摄像机的结果且省去了繁琐操作。
当然业界也有其他方案比如通过模型训练找结束时间点,准确度可能打折扣。

真是牛啊,请问这个目前可以完全down load下来免费试用吗?

通过 Soloπ 的解析器将用例转换为 Appium、Macaca 等目前主流自动化测试框架的脚本

用例导入其他设备,以及转换,在文档里似乎没看到有提到,试着尝试把导出的json用例导入到/storage/emulated/0/solopi/import路径下也没生效

最后一句话扎心了

得了吧,开源给你用就不错了,又没收你钱还得给你做保姆吗

对于solopi,我的疑问有几点:

  1. 识别控件的兼容性怎样?
    native控件定位采用的是UIAutomator1或者2来识别,兼容性是很差的,尤其对h5页面特别差,而基于chrome dev tools protols可以弥补,因为它其实本质是类似webui的测试,是js取控件的,所以会比较准,但要使用这个技术,要么这个webview是x5内核(手动开启调试),要么就是自己应用开启debug调试模式,才能去做。至于基于图像来识别,看了相关的视频,感觉还不错,我之前在testin做过一段时间,简单的还是比较好识别的,但图像不具备特色就比较难识别,并且在不同手机上,图片颜色可能都不太一样,对上百台设备乃至上千台设备,识别控件的准确度会怎样?不知道有没有实际测试过验证过。图像识别在我看来只是一个补充。

  2. 一机多控稳定性怎样?
    看着是通过socket连不同的手机,有主从之分,这个socket会不会被系统干掉导致连接断开

  3. 能否支持持续集成?
    这个很重要,有没有一个方式提测让设备随时能够执行任务,能否配合Jenkins做定时任务呢?

虽然有很多疑问,但我还是觉得solopi是一个很不错的工具,在无线自动化上的探索已经做的很好了(虽然我不认为无线自动化是一种很好的方式)

寻觅 回复

导入到 /sdcard/solopi/import 之后还需要在Soloπ设置中执行导入用例

希望有收益的

cmlanche 回复
  1. native控件不是走UIAutomator1或2进行查找的,有自己的一套控件查找算法,多维度定位控件,具体算法已经开源。h5的话目前有一些积累,可以关注下后续的进展。至于图像模式的话,还是有一些打磨空间的。
  2. 一机多控在一个比较好的网络环境下稳定性还是可以的。
  3. 持续集成这个点确实比较重要,从机的模式其实可以兼容Jenkins的玩法,就是让电脑作为主机,基础能力是支持的。
Cathor 回复

查找算法是算法,但native控件的话,你只能基于UIAutomator,你们或许用了辅助功能,利用accessbilityService来做,但兼容性跟UIAutomator是一样的,UIAutomator背后的原理也是它。非侵入式的控件定位,绕不过accessbilityService,那就绕不过兼容性

28Floor has been deleted
cmlanche 回复

对纯Native的页面来说,我们测过市面上的top机型,其兼容性还是可以的。如果说accessibilityService获取到的控件信息存在问题,那可以通过其他模式进行补充。

看起来非常成体系,一步步搭建解决终端测试的瓶颈。

移动 Lighthouse,这个功能还没开源吗?

看起来很牛逼,点很多,但是我有点担心最后效果,这玩意说白了还是基于目前自动化的套路整合起来的。uiautomator控件识别,图像算法匹配,h5页面light house等工具。

先mark下

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up