反馈与崩溃
测试不是「把包发出去就完事」，真正的价值在于把反馈收回来并形成修复闭环。本章教你如何收集、解读和处理测试反馈与崩溃。
测试员如何反馈
测试员在安装的构建中，可以通过两种方式反馈：
- TestFlight App 内反馈：在 TestFlight App 中打开应用详情，点击反馈入口（或摇一摇触发），描述问题并附上截图。
- 崩溃自动上报：App 发生崩溃后，崩溃信息会随 TestFlight 自动上报到 App Store Connect 的崩溃报告。
给测试员发测试说明时，务必明确「在哪里反馈」。很多用户不知道 TestFlight 自带反馈入口，会跑去 App Store 打分，反而造成差评。
在 App Store Connect 查看反馈
- 反馈列表：TestFlight → 对应 App → 底部「反馈 / Feedback」区域，可查看测试员提交的文字反馈、截图与设备信息。
- 崩溃报告：进入「XCrashes / Crashes」页面，可按版本、设备、操作系统筛选，查看崩溃堆栈。
崩溃报告怎么看
崩溃报告是定位稳定性问题的最重要素材。阅读时关注：
| 信息 | 说明 |
|---|---|
| 崩溃堆栈 | 崩溃发生的函数调用链，定位到具体代码位置 |
| 崩溃类型 | 如 SIGABRT / EXC_BAD_ACCESS / 内存问题等 |
| 影响版本 | 崩溃集中在哪个版本，判断是否为回归 |
| 设备/系统 | 是否只出现在特定机型或系统版本 |
| 崩溃次数与用户 | 判断影响面，决定修复优先级 |
判断优先级的口诀：「高频 × 大影响」优先修。同一个崩溃影响了大量用户，即使堆栈看着简单也要优先处理；低频且仅在旧系统的崩溃可以排后。
形成修复闭环
一个标准的测试反馈闭环：
- 收集：测试员反馈 / 崩溃报告统一汇聚。
- 归类：按模块（登录、支付、首页…）和严重度（崩溃 / 功能不可用 / 体验问题）分类。
- 定位：结合崩溃堆栈、日志、复现步骤定位根因。
- 修复：开发修复并补充回归用例。
- 验证：上传新构建，让相关测试员重点回归。
- 记录：沉淀到发布说明 / 版本更新说明中。
提审前的稳定性门禁
正式提交 App Store 审核前，建议用以下标准判断是否「够稳」：
- 无已知的 P0 崩溃（影响核心路径）。
- 核心流程（注册、登录、支付、主功能）在真机上验证通过。
- 主要机型与系统版本覆盖冒烟测试。
- 已知问题已有规避方案或明确告知审核员。
- 崩溃报告中高频问题已定位并修复。
常见问题
- 崩溃报告看不到怎么办？ 确保 App 在 Xcode 中开启了
BITCODE/符号化（dSYM 上传），并在 App Store Connect 中开启崩溃报告；模拟器崩溃不会上报。 - 测试员反馈很散，怎么管理？ 可以建立简单的反馈模板（设备 / 系统 / 复现步骤 / 期望行为），减少无效信息。
- 外测用户反馈与内测反馈分开吗？ 同一页面会聚合所有测试员反馈，可按测试组或构建筛选。
好的测试流程是「提审前把问题暴露在测试期」。TestFlight 的反馈与崩溃能力，就是帮你把线上事故转化为提审前的修复清单。