一套能产出可复现工单的真机 QA 流程

QA 和研发之间的落差通常不是投入的问题，而是：测试看到了 bug，开发收到的是关于它的一句话。

下面讲的都是怎么在设备还在测试同事手上的时候，把这个落差补上。

一份好 bug 报告的局限

即使是认真写的报告 —— 步骤、预期、实际、一张截图 —— 也几乎丢掉了当时设备上的一切。故障前后的日志。前两秒 App 在干什么。内存是不是在爬。iOS 是哪个构建号、磁盘满不满、手机烫不烫。

复现不了的开发只能把这些一条条猜出来，靠一周的评论往返。

在发生的当下就抓

设备就在手边，抓四样东西：

1. 故障前后的日志

不是整场会话。清空 → 复现 → 停止 → 保存。一份从十分钟前开始的日志，和没有日志差不多，因为没人会读。过滤到被测 App，并在工单里注明用的是哪个过滤条件。

2. 性能采集（如果是性能问题）

卡顿、卡死或崩溃前后各十秒。这就是“有点慢”和“转场期间 CPU 冲到 90% 持续 400 毫秒”之间的差别。

3. 定时截图

任何视觉上的、间歇性的问题，500 毫秒一张的连拍能抓到手动截图永远抓不到的东西。开着，复现，停。

4. 设备状态

iOS 构建号、机型、剩余存储、电池健康、已装描述文件、地区语言、辅助功能设置。原样贴进工单。这一段解决“无法复现”的次数比任何其他部分都多。

模板

保持短到大家真的会填。

概述：
步骤：
预期 / 实际：

设备：      iPhone 12，iOS 17.4.1
存储：      剩余 4.2 GB
电池：      84%，612 次循环
版本：      2.8.0 (412)
描述文件：  无异常
语言：      zh-CN，动态字体默认

附件：      过滤后的日志（过滤条件：[Feed]）
            性能采集（卡顿前后各 10 秒）
            连拍截图（500 毫秒）

六行设备状态加三个附件。比一张截图费事，比一周来回省事得多。

提单之前值得做的两件事

换一台设备试试。 如果两台都复现，写清楚 —— 这砍掉了整整一个排查分支。如果不复现，你已经拿到了这张工单里最有价值的事实，而答案就在设备状态那一段里。

看一眼崩溃列表。 如果 App 是直接消失而不是表现异常，设备上会有一份崩溃报告。附上它。有 dSYM 撑着的报告，能把两天的排查变成五分钟的。

面对别人的设备

当手机属于客户而不是团队时，上面所有内容依然适用，外加一条：取最少的。

• 日志和性能采集通常没问题。
• 截图里可能有他的数据。附之前先看一眼。
• App 沙盒或设备备份装的是他的全部生活。必须获得明确许可，只导能回答问题的最小范围，工单关闭就删。

这里的失效模式不是恶意，而是：为了排查导出了一份，查完了，然后忘了那个文件夹的存在。

会发生什么变化

坚持这么做的团队，最后会拿到开发当天就能动手的工单，以及一批采集记录 —— 这让同一个 bug 第二次出现时的定位速度远快于第一次。代价是每份报告多花大约四分钟，而那正是 bug 就在眼前、信息唾手可得的时刻。