第4章 被测应用与场景选择:确定回归范围与典型操作序列
适用场景
本章流程适用于以下场景:
- AOSP Framework 帧率优化验证:代码提交后需要确认帧率抖动是否回归。
- 版本周期回归测试:每轮测试前需明确被测应用和操作场景。
- 三方应用兼容性测试:针对高频使用的第三方应用进行帧率稳定性判断。
- 系统 UI/Launcher 回归:桌面、通知栏、多任务切换等核心系统组件。
前置条件
- 已确认被测设备系统版本、ROM 构建号。
- 已安装或部署待测应用(Launcher / SystemUI / 三方应用)。
- 已获取上一基线版本的帧率抖动数据(如 JankCount、FrameTime 均值)。
- 测试环境温度、电量、后台进程已归一化。
- 回归范围决策文档或负责人已指定。
操作步骤
| 步骤 | 操作内容 | 责任角色 |
| 1 | 根据变更影响范围列出待回归的应用类别(Launcher / 系统UI / 三方应用) | 测试工程师 + 开发 |
| 2 | 从每个类别中选取 1~3 个代表性应用(如 Launcher 选 Pixel Launcher, 系统UI 选 Settings, 三方应用选微信/抖音/Chrome) | 测试工程师 |
| 3 | 定义每个应用的典型操作序列(滑动/转屏/列表滚动),可参考下表 | 测试工程师 |
| 4 | 编写操作序列脚本或录制手势 | 测试工程师(自动化) |
| 5 | 在测试设备上预先验证操作序列可复现 | 测试工程师 |
| 6 | 将回归范围清单和操作序列定义纳入测试计划 | 测试负责人 |
典型操作序列定义示例
| 应用类别 | 应用实例 | 操作序列 | 时长 |
| Launcher | Pixel Launcher | 主屏左右跨页滑动 → 呼出抽屉 → 快速上下滚动应用列表 → 返回桌面 | 15s |
| 系统UI | Settings | 进设置 → 快速上下滚动 → 点击子菜单 → 返回 → 横向旋转屏幕 → 继续滚动 | 20s |
| 三方应用 | 抖音 | 打开抖音 → 连续上划切换 10 个视频 → 横屏播放 → 旋转回竖屏 → 进入评论列表滚动 | 25s |
| 三方应用 | Chrome | 打开 Chrome → 加载新闻页 → 快速上下滚动 → 切换标签页 → 横屏后继续滚动 | 20s |
输入输出物
| 类型 | 名称 | 说明 |
| 输入 | 变更影响分析报告 | 说明哪些模块被修改(SurfaceFlinger / Choreographer / GPU 调度等) |
| 输入 | 基线帧率数据 | 上一稳定版本的 Jank 数、FrameTime P90/P99 |
| 输出 | 回归范围清单 | 格式:应用名 | 版本 | 操作序列描述 | 预期帧率阈值 |
| 输出 | 操作序列定义文档 | 详细步骤、手势参数(速度/距离)、屏幕方向变化点 |
责任边界
- 测试工程师:主导应用选择和操作序列设计,执行预验证,记录异常。
- 开发工程师:确认变更影响范围,提供针对性的重点应用建议。
- 测试负责人:审核回归范围是否覆盖关键风险,批准输出物。
- PM:当回归范围超出时间预算时,参与优先级决策。
记录材料
需保留以下记录:
- 回归范围审批记录(邮件或 Jira ticket)
- 操作序列定义文档(包含每个手势的起始/结束坐标、速度、方向角度)
- 预验证通过的截图/日志(证明操作序列可触发帧率抖动)
记录模板示例(部分):
应用:抖音
版本:28.6.0.123
操作序列步骤:
1. 从首页推荐流启动
2. 向上滑动 5 次,每次间隔 0.5s,滑动距离 250px
3. 点击视频右下角全屏按钮
4. 旋转设备至横屏(旋转时间 < 0.3s)
5. 保持横屏 3s 后旋转回竖屏
6. 快速进入评论列表,上下滚动 3 次
异常处理
| 异常类型 | 处理措施 |
| 应用无法安装或启动闪退 | 更换同类别替代应用,并记录异常原因 |
| 操作序列无法精确复现(如手势偏移) | 使用 UI Automator / MonkeyRunner 重新录制,并调整容忍度 |
| 横竖屏切换无响应 | 检查设备传感器状态,重启 adb 并重试 |
| 三方应用版本更新导致 UI 元素变化 | 锁定应用版本 APK,或更新坐标/控件 ID |
验收标准
- 回归范围清单至少包含 1 个 Launcher、1 个系统 UI、2 个三方应用(或按项目要求调整)。
- 每个应用至少包含 滑动 + 转屏 + 列表滚动 三类操作中的两类。
- 所有操作序列已通过预验证,能在被测设备上连续执行 5 次无中断。
- 输出物已上传至测试管理平台(TestRail / Jira / Git)。