移动端自动化：Android 自动截图、录屏与证据留存方案怎么设计才有排障价值
移动端自动化里，最让人头疼的不是 case 失败，而是 失败了却没有现场。
你大概率见过这种情况：
- 报告里写着
AssertionError - 日志里能看到一点异常，但看不出页面当时长什么样
- 截图只有一张，而且已经是恢复动作之后的页面
- 录屏倒是开了，但几十分钟一个大文件，根本没人愿意看
最后排查只能回到老路上：测试同学重新手工复现，研发远程盯着手机看，问题定位效率极低。
所以这一篇我想讲的不是“ADB 怎么截图录屏”，而是一个更实用的问题：
Android 自动截图、录屏和证据留存方案，到底怎么设计，才能在真实测试里真正有排障价值。
一、证据留存要解决的核心问题，不是“有没有文件”，而是“能不能还原现场”
已经做了截图或录屏，但实际效果依然很差。原因通常不是工具不支持，而是方案设计只停在“失败后保存一下文件”。
这会直接带来几个问题：
- 证据触发太晚，真正的异常页面已经消失
- 文件命名混乱，查不到对应的设备和 case
- 截图、录屏、日志彼此脱节，无法拼成完整证据链
- 录屏成本过高，最后要么不开，要么开了也没人用
所以证据留存的真正目标，不应该只是“把附件存下来”，而应该是：
- 能定位到哪台设备、哪个 case、哪一步失败
- 能看到失败瞬间前后发生了什么
- 能把截图、录屏、日志、设备状态串起来
- 能支撑人工复盘，也能支撑自动分析
只有满足这几件事，证据才不是装饰品。
二、截图和录屏不是互相替代关系，而是两种不同层级的证据
这个场景里最核心的问题是：到底应该优先截图还是录屏。结论可以先写清楚：
- 截图适合保留“瞬时现场”
- 录屏适合还原“动态过程”
它们不是二选一，而是解决不同问题。
1. 截图最适合捕捉异常瞬间
比如：
- 页面白屏
- 弹窗遮挡
- 元素没显示
- 登录失败提示
- 崩溃对话框
这类问题最需要的是“当时看到的是什么”。
截图的优点是轻、快、成本低，非常适合默认启用。
2. 录屏更适合还原过程问题
比如：
- 某一步点击后页面长时间没反应
- 动画过渡异常
- 间歇性卡顿
- 偶发点击错位
- 前后台切换导致页面状态丢失
这类问题只看一张图通常不够，因为关键不只是“结果长什么样”，而是“过程怎么演变成这个结果”。
3. 证据方案不能把全部希望压在录屏上
为了省事，干脆所有 case 全程录屏，看起来很完整，但后果通常是：
- 文件极大
- 设备性能受影响
- 存储空间被迅速吃满
- 报告里挂着一堆视频，但没人会逐个看
所以录屏更适合作为增强型证据，而不是默认无脑全开。
三、截图能力怎么做，关键不在命令，而在触发时机
最常见的截图命令是：
1 | adb -s <serial> exec-out screencap -p > screen.png |
命令本身并不复杂，真正决定价值的是“什么时候截”。
更推荐的截图策略通常有三层。
1. 关键步骤前后截图
适用场景：
- 登录
- 提交表单
- 支付确认
- 页面跳转
- 前后台切换
这样做的价值是，你不仅知道失败了，还能知道失败前页面状态是否已经异常。
2. 异常瞬间立即截图
这一步非常关键。
只要脚本检测到下面这些信号，就应该尽量第一时间截图：
- 断言失败
- 启动失败
- 页面超时
- crash 信号
- 关键控件不存在
因为很多失败现场只存在几秒，后续恢复动作、系统弹框变化、页面自动跳转都会把现场覆盖掉。
3. 恢复前后各留一张图
这是 忽略的点。
如果失败后脚本直接执行“回桌面”“重启应用”“清数据”，那恢复前的现场往往就没了。
所以通常要求：
- 恢复动作前先截图
- 恢复动作完成后再截图
这样才能区分“原始故障现场”和“恢复结果”。
四、录屏能力怎么做，关键不在能不能录，而在录多长、何时录、录完怎么回收
最常见的录屏命令是：
1 | adb -s <serial> shell screenrecord /sdcard/fail.mp4 |
看上去很简单，但它在真实项目里有几个明显问题：
- 长时间录制容易拉高设备负载
- 文件很大
- 有的设备会在长录制时出现不稳定
- 录制文件如果不及时清理，会直接影响后续执行
所以录屏能力不能只理解成“开和关”，而要理解成一套策略。
1. 不建议默认全程录制所有 case
除非你执行规模很小，否则全量全程录制通常不可持续。
更合理的方式是：
- 只对关键用例录屏
- 失败后触发短录屏
- 在高风险步骤前后录制局部窗口
2. 录屏时长要受控
很多问题的关键窗口其实只有几十秒。
如果每次都录十几分钟，绝大多数内容都是无效背景。
所以更倾向把录屏设计成：
- 单次时长上限
- 到时间自动停止
- 失败后自动拉回并归档
3. 录屏产物必须有回收和清理策略
这是非常现实的问题。
如果 /sdcard/ 里的视频文件不清掉，设备执行几轮之后就可能出现：
- 安装失败
- 截图失败
- 日志写入异常
- 设备明显变慢
很多所谓“自动化越来越不稳定”，最后根因不是用例逻辑，而是证据文件残留把设备拖脏了。
五、真正有价值的不是截图或录屏本身，而是“完整证据链”
截图、录屏如果孤立存在，价值其实有限。
真正有效的是把它们和别的证据拼起来。
更推荐的证据链至少包含下面几类内容：
- 失败前后截图
- 关键窗口录屏
- 对应时间段的
logcat - 当前前台 Activity
- 目标应用进程状态
- 设备基础信息
- 用例步骤时间点
这样你拿到一个失败 case 时，就不只是得到“一个视频文件”，而是得到一套完整上下文：
- 哪一步失败
- 失败当时页面什么样
- 失败前后日志怎么变化
- 系统有没有弹窗或回收行为
- 恢复动作有没有成功
这才是真正能支撑排障的证据方案。
六、证据文件怎么命名和归档，直接决定后期排查效率
前期也会存截图和视频，但后面还是找不到。这通常不是因为没存，而是因为命名和目录结构根本不适合排查。
更推荐的组织方式是按下面几个维度归档：
- 执行批次
- 设备序列号
- case 标识
- 步骤标识
- 时间戳
比如一个更可用的目录结构可以是：
1 | outputs/ |
这个结构的价值非常直接：
- 一眼能看出证据属于谁
- 不容易多设备串文件
- 便于自动上传报告或长期归档
如果文件名只是 1.png、fail.mp4、log.txt 这种，规模一大就不可维护。
七、在项目里踩过的几个典型证据留存坑
坑 1：只在 case 最后失败时截图，现场早就变了
现象：
- 报告里有截图
- 但截图里显示的是首页、桌面，甚至是恢复后的页面
根因很简单：
- 截图触发太晚
- 失败后自动恢复动作先执行了
- 截图不是在第一异常点触发的
修复思路：
- 让关键异常一出现就立即截图
- 恢复前强制留证
- 恢复后再补一张“恢复结果图”
坑 2：录屏开了，但根本没人看
现象：
- 每个任务都有视频
- 但视频文件过大、时长过长
- 报告里挂了视频链接，排查时依然没人点开
这类问题本质不是“录屏没用”，而是录屏粒度不对。
修复思路：
- 控制录屏时长
- 只录关键窗口
- 在报告中给出失败发生的大致时间点
如果让排查者从 15 分钟视频里自己找问题，录屏价值会被大幅抵消。
坑 3：截图、日志、录屏的时间轴对不上
现象：
- 日志显示 20:31:05 崩溃
- 截图时间却是 20:31:20
- 视频文件看起来也不是同一轮执行
这种问题最麻烦，因为你无法确定到底哪份证据可信。
根因通常是：
- 设备时间和执行机时间没校准
- 文件命名不带统一时间
- 证据生成顺序不一致
修复思路：
- 执行开始时统一记录基准时间
- 证据文件名带精确时间和步骤号
- 报告里统一引用同一时间轴
坑 4：证据采集本身拖垮了执行稳定性
这个坑很隐蔽。
把“多留一点证据总没错”当成默认策略，实际会反过来影响执行结果。
典型表现包括：
- 频繁截图拖慢脚本
- 全程录屏影响设备性能
- 原始日志、视频、图片太多导致 I/O 压力大
- 多设备并发时采证进程互相争资源
所以证据能力不能只追求完整，还要控制成本。
八、更推荐的证据留存触发策略
如果要在稳定性和排障价值之间找平衡，更推荐下面这套策略。
1. 默认轻量化采证
默认开启：
- 关键步骤截图
- 失败即时截图
- 基础日志采集
这样成本低，适合大多数回归任务。
2. 失败增强采证
一旦出现失败信号，再触发：
- 当前窗口录屏
- 额外日志快照
- 设备上下文导出
- 恢复前后截图
这样能把资源集中在真正有问题的 case 上。
3. 高价值场景专项采证
对于下面这些场景，可以单独加重采证：
- 间歇性问题
- 动画或手势相关问题
- 前后台切换问题
- 启动性能和稳定性问题
这类问题本来就更依赖动态过程，还原成本高，更值得加强证据。
九、排查一个移动端失败 case 时，这些证据可以怎么用
实际排查时，通常不会先看整份日志，而是按下面顺序走：
1. 先看失败步骤前后的截图
目的是快速判断：
- 页面是不是走偏了
- 有没有弹窗挡住
- 页面有没有明显渲染异常
2. 再看对应窗口的短录屏
目的是确认：
- 失败是瞬时问题还是过程问题
- 点击、跳转、加载过程中发生了什么
3. 再对照同一时间段日志
目的是确认：
- 应用有没有 crash
- 是否是接口超时
- 是否有系统限制、权限拒绝、Activity 异常
4. 最后看设备上下文和恢复结果
目的是判断：
- 是业务缺陷
- 是环境问题
- 还是设备已经脏掉，不适合继续调度
这样排查的效率会比“先看全量日志、再随便点个视频”高很多。
结语
移动端自动化里的截图、录屏和证据留存，价值从来不在“有没有采”，而在于它能不能帮你还原故障现场。
真正有排障价值的证据方案，至少应该满足几件事：
- 截图时机准确，能保住第一现场
- 录屏策略受控，不把系统拖垮
- 文件归档清晰，能快速定位到设备、case、步骤
- 证据和日志、设备状态、恢复动作能对齐
- 既能服务人工排查，也能服务后续自动分析
如果只是随手留一张图、挂一个大视频，那它最多只是“有附件”；
如果能把触发、关联、归档、成本控制都设计好，它才会变成移动端测试体系里真正有价值的排障资产。