产出可复现工单的真机 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 就在眼前、信息最容易获取的时候。