自动化测试框架 Totoro 是由蚂蚁金服终端工程技术部实验平台技术组自主研发的一套自动化测试框架，支持  Android 、 iOS 、 HTML5 、 小程序 、 Weex 、 Cube  等移动端自动化测试场景。

创新互联公司是一家集网站建设,大余企业网站建设,大余品牌网站建设,网站定制,大余网站建设报价,网络营销,网络优化,大余网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

为了确保蚂蚁金服移动测试平台在集群环境下能够稳定、高效运行自动化任务，并灵活快速支持多场景域内业务，Totoro 经历了从 0 到 1，从 1 到 2，并逐步演进到目前支撑阿里域内 10+ BU 日常自动化测试及结合移动开发平台 mPaaS 对外输出，成为集团内使用面最广、性能最为稳定的自动化测试框架之一。

本文将围绕 Totoro 一路踩坑、迭代完善成熟的过程，从沉淀总结的一些方法论和解决方案展开分享：

• Totoro C/S 架构模型设计
• 全链路稳定性构建
• 安卓 App 全自动智能安装
• 全场景的异常弹窗治理
• Totoro 重要里程碑及未来规划

Totoro C/S架构模型设计

蚂蚁金服移动测试平台最开始引用了 Appium 开源解决方案，但由于其部署复杂、接口不稳定、设备掉线、多层服务链路、社区维护不够迅速等种种问题，综合评估业内类似框架都有共性的痛点，因此我们决定重新设计一套适合云测集群环境、满足域内不同业务需求快速迭代更新的解决方案。

基于已有的痛点，我们认为 Totoro 从设计上需要满足“调用链路尽可能短”、“项目结构尽可能简单透明”等特点，从而确保测试链路上的不稳定因素尽可能少。同时，综合考虑异常情况下，我们需要能够快速定位问题，并具备一定的自修复能力。结合业内多个框架普遍采用三层或多层的设计，Totoro 最终被设计成了 C/S 模型的两层架构。

两层架构的设计理念实际上为 Totoro 带来很多优点，比如：

1. 服务统一集成到了手机端，缩减了 PC 端的繁杂调用 ：只要 Client 端与手机链接，就可以开始自动化流程，避免了中间服务的命令中转及服务本身资源管理；
2. 真正的 C/S 架构模型 ：无论在自动化的调用速度还是链路的稳定性上都有了质的提升，此外简单的架构模型确保了近些年框架快速迭代的可行性。

全链路稳定性构建

面对蚂蚁云测集群自动化严格的要求，稳定性的问题依然浮出水面，成为 Totoro 不得不解决的一道难题。

在自动化任务的任何链路节点都有可能发生异常，所以稳定性实际上覆盖多个层面，比如：

• 框架本身 API 功能稳定性；
• 宿主服务稳定性；
• 设备链接在线稳定性；
• 设备网络稳定性；
• 硬件 Hub 稳定性。

接下来我们从以上 5 个方面阐述在整个调用链路上我们都做了那些努力。

1. 程序异常全面治理

Totoro 框架在前期开发中，日常维护需要投入极大精力，每日要面临框架自身缺陷引起的异常和各种业务自身的异常问题。同时，各类异常问题要求人工筛选，从而推动框架自身及业务方去解决。由此带来的结果是，大部分云测任务因为这类代码问题而引起终止，导致测试开发不够稳定。

为了改善任务异常带来的不稳定因素，杜绝框架自身 SDK 问题，并且业务异常能够做到智能分类，我们首先做了一次全类型异常堆栈的上报统计。根据后台统计数据可以大概分为“业务层逻辑异常”和“SDK 层异常”，针对发现问题，我们集中投入专项研发精力，修复框架逻辑不合理引起的异常，杜绝 SDK 自身问题；针对海量业务异常，我们做了一层抽象归类，将业务异常逻辑归类为明文提示并给予一定推动建议，并且添加检测点状态校验；针对某些偶现异常，重脚步层做一次重试提示用例结果成功率。

在程序异常治理过程中，我们发现业务用例大多都需要在程序各个运行阶段封装一些业务逻辑，然而 SDK 层也会有一定的初始化过程，通过 JUnit run 起来的用例一旦业务封装或SDK层接口调用实际不对，就有可能引起程序不稳定现象。因此，Totoro 框架更加现有的业务需求现状，及日常已发现的问题，自身定制了一套规范的 Totoro 用例生命周期，业务用例可以在钩子方法中封装各个节点的逻辑。

2. 手机宿主服务稳定性保障

Totoro 框架在手机中的核心服务（TotoroUiautomator/TotoroWDA）在用例执行过程中，会发现链接失败、服务不可用等情况，这种不稳定因素更多是系统限制造成的，能做的就是在恰当时候重启服务，保障整个自动化流程正常进行。

• API 接口级别异常分析，过滤服务异常情况，触发重启。并且能够保留或恢复用例现场。
• Agent daemon 进程服务轮训监控，动态启动异常服务（针对 TotoroWDA）。
• 端口转发失效的假性异常分析，通过网络探测，触发假重启逻辑。

3. 手机稳定链接策略

手机掉线问题是自动化任务流程中必须面对的问题，Totoro 联合蚂蚁云测平台采用了一套软硬件全链路的设备在线保障服务。

Ⅰ. 软件链路上的掉线恢复能力

软件链路上的能力是指集成在 Totoro Client 端的一套设备恢复方案，嵌入在底层通信接口处，一旦发现设备掉线，可以通过远程网络服务，发送消息到手机中的核心服务，通过设备 owner 权限重启手机 ADB，如果依旧失败将进行 PC 端链路的 usbreset。

正常情况下，三次重启内手机 ADB 几乎都能恢复。个别情况恢复失败的，会有现场详细信息上报，且会触发 changedevices 策略更换手机重新执行测试任务，保障流程正常。如果根据历史上报数据统计，分析老旧设备处于经常掉线的不稳定状态，会采取降级措施，调换到对链接要求低的设备池中（如 monkey 池）或下线操作。

Ⅱ. 硬件链路上的设备链接护航能力

在硬件链路的稳定性构建中，大多云测平台选择购买质量较好的 USB Hub。然而蚂蚁云测平台目前要面临每日 7k+ 级别的自动化任务和 mPaaS 金融云级别的用例稳定性挑战，经过实验，市面上再好的设备也无法达到的所有工程需要的质量标准，并且缺少智能控制模块。因此蚂蚁终端工程技术部实验平台组自研了一套 SmartHub，具备独立稳定的供电模块，每个端口可远程程序自动控制（电压/电源/重置等）。目前为止 SmartHub 已经全面量产并投入使用，效果图如下：

4. 设备网络稳定性

设置网络服务的稳定提供，我们主要做了以下几方面尝试：

• 用例失败检测点的网络探测快照，快速定位用例失败现场是否有网络问题；
• SLM 云终端服务管理手机网络，能够自动链接指定网络，并具备网络异常后重置链接能力；
• 云测平台集群环境升级机柜，隔离网络，保障网络热点稳定性。（终端实验室的集群服务将以规范化的屏蔽机柜为单位，提供稳定的移动自动化服务）。

5. 多维度策略 提升用例成功率

在真实的用例构建环境中，需要有很多细节策略点保障整个服务的稳定运行，这里主要罗列几条主要的方案：

• 针对顽固偶现的不稳定因素，采取 DeviceChange（更换设备）策略。
• 针对手机内存、资源等系统限制，会采用 DeviceReboot（重启手机）策略。
• 针对偶现的既定的几种抽象异常类型，采用重新执行策略，有效提高成功率。
• 针对全场景的异常点，钉钉报警，及时发布补丁。

安卓App全自动智能安装

蚂蚁云测自动化执行集群环境中，应用全自动智能安装是最常见场景之一，然而 Android ROM 的碎片化和各个厂商的定制化，导致在安装过程中需要适配各种各样的弹窗；甚至部分厂商需要登录态且要求输入账号密码，导致在数以千计的机型集群环境中全自动智能安装应用成了一个挑战。如下图部分安装弹窗场景：

1. 技术选型

Totoro 框架的自动化服务能力是基于 Uiautomator2 深度定制的，因此整个服务会以 APK 形式安装在手机端。要做到一套完整的全自动安装方案，就必须抛弃在 Totoro 服务 APK 里实现。

最终，我们采用了可以独立在手机中免安装直接运行的 Uiautomator1 方案进行实现，作为独立的安装弹窗处理专项进行迭代更新。

针对国内机型及云测机房全线机型，安装弹窗专项项目，前期以全覆盖的方式抽象弹窗点击规律，dump 页面控件信息，查找关键字，做了机型纬度的适配，并且在每个任务有安全失败报警机制，研发人员能够快速兼容问题机型，及 UI 变更。

最终实现了一套可以处理大部分 ROM 安装弹窗场景的持续迭代的智能安装弹窗处理方案。

2. 智能盲点

由于整个弹窗处理依赖与 dump 控件信息逻辑，某些厂商（华为、vivo、oppo 等）为了防止黑产及其他安全考量，部分安装链路上的弹窗页面会禁止 dump 功能，导致我们获取不到页面信息，而无法判断应该点击的页面坐标信息。

针对该场景，我们对机房的手机做了大量的安装调研，发现弹窗的 button 出现的位置区域和意义是有一定规律的，有些需要服务重启才能 dump 控件信息，有些是按照版本及机型呈现规律的 UI 样式，有些需要特殊的手机 Action 才能获取相应事件。我们将这些规律进一步抽象分类，做了一套智能盲点逻辑，针对无法 dump 到的场景具备拓展兼容的能力。

3. 算法辅助实践

智能盲点在个别规律没有考虑周全的场景下仍然会出现失败的情况，那么，如何构建一套自适应的能力呢？

因此，我们在思考是否可以结合 AI 能力来智能分析页面信息，由算法结果提供具体的点击路径方案，从而快速兼容遗留场景。

目前结合 OCR 服务，Totoro 具备智能分析界面信息，精准获取点击目标坐标，完成弹窗处理的能力。后续将结合深度算法实践，采用安装场景模型数据，让算法直接给出操作建议，完成整个场景的自适应兼容方法。

4. 云测效果视频

目前自动化安装组件经过多纬度的场景兼容，已具备一定自适应能力，能够完成日常自动化安装任务，目前已处于极低成本的维护状态。除了应用在日常自动化任务中，该功能也嵌入了云测平台的远程租用功能，以下是安装效果：

全场景的弹窗治理

移动自动化测试过程中的各种手机弹窗是影响用例稳定性执行的重要因素之一，面对各种类型及场景的弹窗，Totoro 框架中自研了一套全场景的弹窗治理方案：

1. 深度改造安卓 Watcher 接口

异常弹窗的处理中，安卓框架中给出了  UiDevice.registerWatcher  接口方案。但是我们实际使用中发现，这个接口回调不是稳定的，更加官方解释,当自动化过程中查找一个控件失败时候才会触发回调。

为了能够构建多场景的监听机制，必须要有一套页面监听的稳定回调接口。经过翻看UiWatcher相关源码发现，可以通过 hook，主动触发  runWatchers()  。而我们需要做的，还需要在页面弹窗变化时，稳定触发该接口。

安卓 Accessibility 服务可以通过注册，监听弹窗或者页面甚至一个细微的控件变化，为了性能均衡，只需注册弹窗变化回调事件即可。这样一套稳定的弹窗监听回调机制就构建好了。

2. 多维度注册监听

有了保障  registerWatcher  接口的回调稳定性的机制，那个我们就可以依赖这个接口去监听页面UI的变化，做到稳定处理页面弹窗。结合业务需求及日常用例场景，Totoro 框架中可以针对以下纬度来监听页面变化，做到几乎全场景的弹窗治理。

• 注册关键字文案监听
• 注册内容模糊匹配，精准点击目标控件
• 注册 desc 文案
• 注册资源 ID
• 注册目标控件，触发一个 Action

3. 机器学习图像检测方案

然后面对无法 dump 到控件信息的非 Native 页面（H5 /小程序），就需要结合机器学习的方式，采用算法能力去分析页面 UI 结构，去处理页面中可能的异常弹窗。

Totoro 算法同学自研了一套控件 dump 算法能力，脱离平台及页面渲染方式，可以将 App 截图通过算法生产页面原始控件图，满足非 native 场景的弹窗处理。

目前机器学习的分析能力仍然在快速迭代中，除了应用在弹窗页面分析处理外，还应用在页面异常类型检测（包括加载失败、控件截断黑白屏等），已成功落地小程序日常准入和支付宝钱包日常兼容性等重要业务线中，后续会推广到更多的业务中去，让 AI 赋能不是一句空话。

重要里程碑与规划

Totoro自动化测试框架从立项到现在已经走过近三个年头，目前仍然处于快速迭代时期。最近一年，项目自身稳定性质量有了质的提升，在与蚂蚁云测平台共同努力下，越来越多的域内 BU 选择蚂蚁云测和 Totoro 作为移动自动化云测方案。

规划

为更好的支撑域内及 mPaaS 移动自动化测试测试技术，高效输出 Totoro 实验 SDK ，我们还有很多事情可以完善。

未来，我们将从以下几个场景发力，朝着 规范化 、 可扩展 、 多语言平台 、 插件化方向 继续努力发展。

• 继续降低用例维护成本；
• 完善多端脚本语言支持；
• 标准化文档、项目配置等构建；
• 加强 AI 赋能，继续深挖落地场景；
• 构建开发者社区，拥抱开发者，支持域内更多的业务线，较大价值化项目的业务价值。

分享题目：干货分享：Totoro在自动化测试领域的深耕与收获-创新互联
网站网址：http://kswjz.com/article/cejgep.html