真正的机器人AI移动端自动化测试 (ROBOT XT UEE Testing)

共 4848字，需浏览 10分钟

· 2021-04-06

阿里QA导读：“业务先赢”、“极致体验”一直是质量人的主旋律。今天小编带来已入选阿里巴巴内部《阿里集团21财年最值得读的前沿技术领域热文合集》，也是本年度唯一一篇质量领域入选“人工智能”板块的文章，跟大家一起分享交流，看看如何用「真正的」机器人测试来保障“业务先赢”和“极致体验”。

一.背景

随着移动互联网的蓬勃发展以及5G时代的到来，智能移动终端普及从智能手机拓展到 IoT，商业模式也逐步实现线上线下打通，产品设计时，多 App /多终端之间的交互也越来越多，例如消费者与商家互动、用户与主播互动等。随之而来的终端系统也拓展到了 Android、iOS、鸿蒙、Win Touch、RTOS 等等，多APP、多端矩阵也逐渐成为业务触达用户的常态。下图是一位测试人员在不同平台上模拟消费与商家沟通的一个场景。

UI自动化作为“业务先赢”的一种重要手段一直在不断演进，从泛终端与多端UI自动化视角看，行业内主要有以下或类似的解决方案：

从“极致体验”角度来看，加载时长评测占据半壁江山（还有普遍关注的内存/CPU性能、帧率/卡顿、Crash稳定性），行业内主要是以下或类似解决方案：

传统的方式存在一些缺陷：

1）人工点击录屏耗费人力；

2）基于埋点的方式能够反映技术优化结果，但很难作为用户真实场景体验的精确数据；

3）基于系统驱动的方式对待测设备有侵入，多个系统多套脚本，覆盖场景比较有限（如非Android/iOS的IoT设备），难以跨平台支持；

综上来看，在“业务先赢”、“极致体验”的道路上，依然存在需要解决的质量保障难题：1）从泛终端多端交互全流程的视角来看，目前功能自动化测试依然面临每个端（iOS/Android/PC）各自维护一套脚本或是“伪”一套脚本，成本高；

2）多APP矩阵间的交互场景以及同场景下的竞品分析日益增多，亟需支持多设备互动的自动化手段；

3）互联网市场厮杀日益激烈，产品形态多样性放缓，拥有极致用户体验的互联网产品才能赢得更多的市场与消费者，期望寻求一种立足“用户真实感受”、对被测系统无侵入、计量精确的解决方案。

4）在快速迭代/变更、复杂功能需求、AB测试的互联网产品背景下，完全依赖人工编写/维护自动化脚本已无法满足需求：系统变动自适应能力差；不能自行探索构建测试场景；传统的单点验证测试覆盖面小，很难在项目中快速应用和广泛推广。

二.我们的策略

为了应对以上难题，我们跳出了常规思维，尝试使用引入摄像头、机械臂、算法代替人眼、人手、人脑开展泛终端时代多端交互的UI自动化与用户体验评测，同时，我们提出了UEE自动化测试的概念。

1、什么是UEE自动化测试：

通过IoT（如机械手、摄像头）等外部设备模拟真实用户操作，实现以外部真实用户视角对AUT（APP Under Test）进行的端到端黑盒自动化测试。以“真实”模拟为核心目的，具体包括两部分：

1）用户交互体验评测：通过IoT（如摄像头、传感器）等外部设备采集并将真实用户感受数字化，来获取最接近真实用户体感的性能及用户体验指标；软件绿色联盟在2020年3月份也发布了《软件绿色联盟智能终端性能流畅评测标准V2.0》，并以机械臂+摄像头的方式作为加载耗时的评测标准，我们在2019年初就开始使用这种模式。

2）多设备端到端功能自动化：通过机械手实现同时多设备的跨终端的自动化操作执行；通过AI算法实现IoT设备的调度控制、场景理解、测试步骤执行、测试路径探索、体验指标计算、异常处理等能力。

通过机器人对系统进行黑盒测试，类似的做法在国外Axiz机器人也有尝试。

2、为什么要UEE设备端到端自动化测试

E：满足深度用户体验评测的诉求（Experience）

更高精度：随着深度用户体验提升的需求日益增加，端侧的性能和体验优化会精确到ms级别，因此需要找到进一步提升用户体验指标度量精度的方法。

多设备间交互测量：随着多端交互的场景越来越多。不光是APP之间，设备层面APP和PC乃至IoT之间交互的场景也不断出现，需要度量多APP多设备之间的交互性能及用户体验，需要度量多设备多系统间（从A手机到B手机，手机到PC/IoT 等）的交互式体验指标。

真实模拟：软件模拟点击和真实用户操作还是存在差异，要探索一种更模拟用户真实操作的方式。

E：对多设备端到端功能自动化测试的支持（End1 to End2）

业务客户端发版经常需要对Android/iOS/Pad甚至PC进行覆盖测试，同时APP之间的业务交互场景也逐渐增多，比如淘系的消费者-商家互通全流程，测试不仅仅只是单手淘、天猫或者千牛APP覆盖，还要能覆盖和串联起从消费者到商家的整个业务流程端到端自动化。此时，我们面临着新的挑战：

多机交互自动化：无法快速支持多手机 App 间、手机与PC/IoT之间交互的操作；

基于外部视角的对象识别：CV和AI算法的加持让UI自动化测试在对象识别上有了新的突破，但依然无法摆脱软件层API操作的局限，受所在操作系统限制，依旧存在部分特定场景下元素无法识别的问题（如系统内Push消息操作）；

一套跨终端设备的通用脚本：还不是真正意义上的多设备多平台一套脚本驱动，Android/iOS/PC/IoT受系统版本或环境影响，可能仍需要多套自动化脚本，维护成本高；

一个脚本一次执行覆盖多个设备和系统：由于不同操作系统有不同的自动化执行引擎，一个脚本一次执行无法同时对Android/iOS/PC/IoT 完成回归。

三.RXT(Robot-XT)迎接挑战，应运而生

基于UEE自动化的理念，我们尝试使用机器人的方式获取用户体验指标以及开展UI自动化测试，设计并研发了RXT。它基于IoT架构，从“用户真实感受”出发，零侵入被测系统获取用户体验指标（加载耗时、跳闪白分析），同时支持图/文驱动跨设备交互的UEE自动化用例批量执行。如下是演示效果：

下图是RXT的能力介绍：

1、深度用户体验指标

RXT立足“用户真实感受”获取用户体验指标，用机械臂手代替人手操作，用高速摄像头代替人眼记录操作过程，并具备体验指标算法(不需要目标对象的加载耗时分析、白屏分析)的大脑结构，RXT也可支持设备交互场景及竞品对比场景。

2、多端自动化

RXT在传统的单机操作之上引入一层新的“主控大脑”，接管、调度跨设备的时序操作，完美支持了多端多设备、多App间交互场景的自动化能力；RXT使用原生Python程式化(基于unittest)组织用例，用户可灵活控制/增加定制逻辑，并基于Python module理念抽离公共逻辑，降低用例维护成本，此外，用例可通过任务组织批量执行；RXT上层用例基于图文方式1套脚本驱动，底层执行引擎支持机械臂引擎和UIAutomator/WDA自动化引擎，其中机械臂方案做到与平台、设备无关，打通手机和PC(平板)间自动化的壁垒，满足各种场景的测试需要；“非预期”弹窗(突如其来的红包Poplayer、首次安装需要的各种权限、过渡动画广告等等)是自动化测试的灾难性问题，RXT-ESP提供了相关的识别和处理机制；RXT提供真机用例调试能力，用户无需准备任何本地环境即可运行、调试用例。

3、对象识别

多场景传感器融合下的对象识别，使用ROI截取、图像增强/去噪优化被测对象图片，坐标变换关联手机元素位置与机械臂操控位置，基于OCR获取目标图像文本信息，改进SURF/SIFT特征匹配算法提升图像识别准确率。

4、异常处理

RXT具备非预期弹窗的检测与处理能力，例如可以检测首页Poplayer红包弹窗、权限弹窗等，并且使用NLP对互动按钮(如"我知道了"，”允许“，”不再提醒“)进行语义理解、分类，然后加以处理。

5、用例生成

RXT能从分散杂乱的用户埋点数据中，通过清洗、聚合、去重构建手淘消息用户行为访问路径及Top N热点路径，从而转变成具备业务语义的用例，后者正在进行中。

四.项目实战

1、手淘消息场景用户体验升级项目

项目目标简介：手淘消息是世界上最大的商业沟通场景，该项目目标是大力提升手淘消息的加载体验、并进行跳、闪、白治理

策略&效果：下面是该项目优化前后，使用RXT观察到的用户使用前后版本打开消息业务的效果对比视频：

2、手淘消息多通道升级项目
项目目标简介：该项目涉及到底层链路新/老切换，与上层客户端业务进行对接，为降低质量风险，上线期间兼容了新/老链路方案，对应的测试回归场景涉及到手淘消费者(Android/iOS)、千牛商家(Android/iOS/PC)双端的新老链路交互，按笛卡尔乘积增长，共有48种，每种场景都基本对应同一套测试用例。

策略&效果：上层业务上存在大量重复Case回归，我们的策略是将简单、重复的用例交给RXT，人工投入更多的时间在复杂场景的用例设计和回归上。

3、大促态消费者-商家下单核心链路验收

项目目标简介：大促态下，消费者提交订单是核心链路。不仅需要保障手淘消费者(Android/iOS)提交订单成功，并且需要保障千牛商家侧（Android/iOS/PC）能够实时收到消费者提交的订单信息。

策略&效果：如下是实战效果(手淘-千牛移动端)：

五.总结及未来展望

本文主要介绍了UEE自动化测试理念，并在此基础上设计并研发了RXT以及相关的一些项目实践结果。我们还将在“业务先赢”、“极致体验”的道路上继续前行。未来我们将继续优化RXT产品，继续提升产品稳定性、智能化能力。同时也希望我们的能力可以更多对行业开放，让智能化测试服务行业，实现真正的测试智能。欢迎大家提供合作机会！！

六.附：