Totoro 框架在自动化测试中的重要地位
本帖最后由 草帽路飞UU 于 2022-9-23 16:34 编辑自动化测试框架 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 层也会有一定的初始化过程，通过JUnitrun起来的用例一旦业务封装或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（重启手机）策略。
· 针对偶现的既定的几种抽象异常类型，采用重新执行策略，有效提高成功率。
· 针对全场景的异常点，钉钉报警，及时发布补丁。
页:
[1]
