魅族终端自动化测试探索之路

业界的办法不适用
业界提供的云测服务更多 聚焦在应用方面，而魅族的自 动化测试是从应用到固件全覆 盖的。而且定制化需求高，机 型信息需要保密等原因。
怎么做到的
测试框架 平台开发
Android源码 研究
结合业务 平台化 产品化
经验
Java、Python
JavaScript、 C++
技术 Android
实践 1－规范脚本 & 整合报告
整合并上传结果 & 展示报告 拉取脚本 & 选择模块执行 & 异常监控 LINT扫描 &编译打包 & case 信息入库 Review & 版本控制/merge/abandon 规范Ant & Gradle打包资源
代码
GERRIT
JENKINS 守护 APP
W守护EABPP
魅族终端自动化测试探索之路
摘要
MEIZU Android自动化测试系统通过对测试框架的反思扩展和对测试流程的提炼优化，用平台打破 了固件、设备（手机／测试仪器）、测试脚本、测试报告 等各项资源间的隔离，构建了一个完整、易扩展、 可配置的自动化测试体系。
在方便自动化测试的同时，也为其他非测试人员提供了一个了解项目质量概况的捷径，为自动化测试 在整个部门的普及与规范节约了大量的成本。
魅族终端自动化测试
案例特点
一套完整的自动化测试系统，MEIZU全机型自动化测试覆盖。
UiAutomation、Instrumentation、Monkey稳定性测试、OTA升级、RECOVERY互刷、单元测试自动 调度、固件基础性能、安全扫描和专项测试。
WIFI / USB / 串口等方式调度任务。
案例ROI分析
案例启示
１、整合&强化测试框架，提高覆盖率 ２、提供易用配置，增强脚本对不同设备、不同系统、不同应用版本和不同测
试任务类型适配，增强脚本的健壮性 ３、“自动化”自动化 ４、开放调度接口，提供调度支援（固件研发流程CI接入） 5、技术落地，解决用户痛点 6、先定个小目标，肯定能实现
谢谢
云测平台（ATS）打通了与终端的通讯、提供了报告的收集与整合、测试代码的质量管控，以及提 供了内部众测的问题反馈渠道和项目管理等功能。
成果
Monkey 安全
UI
pm
ATS
众测 专项
OTA
Recovery
单元测试
引入案例来源
引入案例来源
业界有没有解决的方法
业界有很多出色的云测 平台，但是魅族需要的是适 合手机厂商、适合自身业务 和测试流程的整套测试系统。
不同RECOVERY 互刷升级
实践3－任务化
升级测试
实践3-任务化
安全测试 ……
扫描Activity/Service组件暴露
扫描ContentProvider/ BroadCastReceiver组件暴露
云测平台ATS自动安全复测
Text in here
构造Intent检查组件安全性
同步安全信息至缺陷平台
专项测试（非仪器）
实践3-任务化
实践小结
从调度层次增加任务类型概念 依据不同的任务类型在守护APP端执行不同的逻辑 生成各个任务类型报告上传服务端展示
专项测试主要采用动态代理技术 hook关键API／仪器调度 统计各数据项并生成图表
实践4-项目管理
独立应用进度管理 试用、反馈、绩效 机型项目进度管理
无须人工干预的自动化（任务／调度计划）
平台调度
统一汇总测试资源
抽象设备池
通过模块配置适配不同机型 不同类型固件
模块配置
实践 2－配置化 & 自动化
仓库
Flyme5 Flyme6
Flyme5
模块B 模块C
模块A
联通版 公开版 电信版
实践 2－配置化 & 自动化
实践 2－配置化 & 自动化
通过模块化、配置化 提高脚本的健壮性和兼容性 模块引入“仓库”概念，对应一个模块集 抽象设备池，集中资源（物理式集中／局域网集中）
实践3-任务化
稳定性测试
基本性能监控
应用稳定性 固件稳定性
Monkey
指定时长 指定机器 种子执行
CRASH ANR MEIZU重启 FLYME 重启 NORESPONSE
实践3-任务化
稳定性测试
实践3-任务化
稳定性测试
实践3-任务化
开机时间 开机内存
……
监控应用启动时间
固件的大小趋势
性能测试
那些年踩过的坑
•配置化 •自动化
• 不同机型需要多份代码或大量逻辑判断，维护成本高 • 需要人工升级固件，然后才能进行自动化测试 • 需要人工启动守护APP，选择模块进行自动化测试 • 需要人工确认失败用例
那些年踩过的坑
任务化
• 测试任务类型多，脚本类型多样，调度复杂 • 固件迭代快，编译周期不固定，需要及时自动执行
GERRIT进行代码审核、Jenkins 统一构建、Case信息入库 要求脚本结束有效清理资源（账户、设置、黑白名单等） 由守护APP调用脚本 ( 脱离USB执行 ) 脚本通过注解提供操作步骤、期望等信息 对操作过程GIF录制／截图
监控CRASH、ANR、无响应等异常，并收集运行时Log
实践 2－配置化 & 自动化
监控Native/Persistent/ System/Cached/Foreground 等分类内存的新增/减少
监控开机启动线程数
实践3-任务化
性能测试
实践3-任务化
检查整包/增量固件 质量
固件升级历史测试 结果对比
升级
校验
升级测试
图表
升降 交叉
校验升级前后基带 /recovery/kernel是 否正确，评估升级 时间
先定个小目标
实践一
•规范脚本 •整合报告
实践二
• 配置化 • 自动化
实践三
实践三
• 任务化
实践四
• 项目管理
实践 1－规范脚本 & 整合报告
报告对接缺陷管理平台 守护APP监控运行时异常 跟业务确定字段、格式 Gerrit，Jenkins 注解
对接缺陷平台 异常捕获，合入报告 规范报告 审核、构建 规范脚本
守护APP添加推送功能，做任务分发、固件升级、用例执行… WEB端从一个单纯的报告展示改造为任务中心，推送任务 自动错例重跑
实践3-任务化
调度仪器设备／APP 探针 Drozer改造／漏洞case化 串口开发 固件层面 Monkey改造
专项测试任务 安全测试任务 升级测试任务 性能测试任务 稳定性测试任务
VCC管理功能 内部众测功能 终端管理功能
实践4-项目管理
实践小结
用平台方式解决项目管理过程复杂，信息滞后不同步的问题 测试执行可以自动化，测试管理也可以自动化
帮助各VCC负责人，测试项目经理和PMO团队简化工作流程 减少沟通成本，提高工作效率
目标实现了
• 合理分配资源，保证设备池高效利用 • 减少和降低自动化的使用限制，提高自动化效率和覆盖率 • 魅族测试部团队500+,日常使用案例提供服务人数280+
实践 1－规范脚本 & 整合报告
自动化脚本 1.步骤 2.期望
守护APP
1.调用脚本 2.GIF／截图 3.CRASH 4.ANR 5.无响应 6. MEIZU重启 7.2.页面显示 3.缺陷对接
实践 1－规范脚本 & 整合报告
测试报告
实践 1－规范脚本 & 整合报告
服务
培训 技术支持
优化
那些年踩过的坑
•脚本质量 •测试报告
• 测试场景未恢复，影响其他脚本 • 容错性差，不稳定，执行效果差 • 造了太多轮子（各自实现了一系列通用操作） • 部分前置条件需要手工构造 • 依赖USB连接 • 原始的测试log简陋，缺少操作步骤、预期结果 • 没有捕获CRASH、ANR、无响应等异常
Text in here
实践3－任务化
安全测试
实践3－任务化
UI卡顿
• onCreate • onStart • onResume • Layout • Handler
WebView
• Navigation timing • Resource timing • JS errors
• 网络请求 • 内存泄露 • 电量