那台顾客日常使用的手机，如何让全绿的发布检查失效

模拟器全部通过，只能证明代码在受控环境里能跑，不能证明它在顾客手中的真机上可靠。发布前必须用有代表性的实体设备走完注册、登录、支付、拍摄、通知和弱网恢复等关键路径，否则一个设备差异就可能让上线停在周五晚上。

1970年4月，阿波罗13号飞往月球途中，服务舱氧气罐发生爆炸。任务团队面对的已经不是训练中那套预定登月流程，而是一艘受损的飞船、不断消耗的电力和逐渐升高的二氧化碳浓度。

休斯敦任务控制中心必须让登月舱的圆形净化罐适配指令舱的方形接口。飞行主管吉恩·克兰兹带领地面团队，根据宇航员手边实际拥有的材料设计临时转接装置，再把步骤传给太空中的吉姆·洛弗尔、杰克·斯威格特和弗莱德·海斯。这个过程记录在NASA的阿波罗13号任务资料中。方案交付前，没有人能靠“理论上应该可行”保证三名宇航员安全返航。

手机应用当然没有这样的风险级别，但问题的结构相同：模型描述环境，实物决定结果。

周五下午，所有检查都是绿色

把几类常见移动端事故压缩成一个典型场景：一位创业者准备在周五提交发布候选版本。自动化测试通过，模拟器里的注册、订阅和内容上传都正常，团队已经写好发布说明，推广排期也已确定。

最后，有人把安装包放到一台顾客日常使用的手机上。

首次启动后，系统弹出权限请求。用户拒绝，再从设置页重新授权。应用返回前台时，上传按钮一直转圈。强制关闭并重新打开后，草稿还在，上传状态却丢了。模拟器里稳定的网络、干净的存储空间和固定的权限状态，没有覆盖这条路径。

团队继续测试。切换移动网络和无线网络后，请求没有恢复；锁屏几分钟再回来，登录状态过期；系统字体调大后，确认按钮被挤到屏幕外。原本准备发布的版本，现在至少有一条核心任务无法可靠完成。

这不是“真机更严格”的抽象问题。真实手机带着用户积累多年的设置、缓存、权限选择、电量限制、旧数据和不稳定连接。模拟器往往从一个整洁、可重复的起点开始，顾客不会。

模拟器证明代码能运行，真机证明产品能使用

模拟器适合快速开发。它启动快，状态容易重置，也方便并行检查多个系统版本。许多界面错误、崩溃和逻辑问题，本来就应该先在这里被发现。

它无法完整复制实体设备的传感器、摄像头行为、生物识别、通知交付、后台调度、存储压力、温度变化和厂商定制。即使系统版本相同，两台手机也可能因为芯片、屏幕比例、历史数据或省电设置表现不同。

因此，真机测试不该变成发布前随手点几下。先列出产品最不能失败的任务，再让每个任务经历真实状态变化：

1. 从全新安装开始，也从旧版本升级开始。
2. 分别允许、拒绝和稍后修改权限。
3. 在提交过程中切换网络、锁屏、返回桌面。
4. 使用较大的系统字体、较低电量和接近满载的存储空间。
5. 失败后重新打开应用，确认数据、进度和提示是否仍然可信。

测试范围不用追求覆盖市场上每一种手机。优先选择真实用户占比较高的系统版本、关键硬件差异，以及最容易影响收入或留存的路径。设备矩阵可以小，但每台设备都要回答一个明确问题。

Google Cloud近期推出了一个托管平台的公开预览，可通过流式访问和并行测试API按需使用实体设备与模拟器。这类服务降低了团队接触真机的门槛，却没有替团队决定该测什么。设备数量增加以后，测试设计仍是瓶颈。

发布证据应该来自顾客会走的路径

“在我的手机上没问题”与“模拟器里没问题”同样缺乏信息。更有用的发布记录应写清设备类别、系统版本、安装方式、权限状态、网络变化、执行步骤和结果。失败时，还要保留日志、截图或录屏，并确认修复后重新走过原路径。

如果多人轮流接手发布，测试记录还要区分已验证、未覆盖和已知失效的部分。它与运维交接面对的是同一个问题：下一位接手的人必须知道系统哪里可靠、哪里仍然失明。[这篇关于交班判断的文章](/blog/zh-CN/6-10-cf2a7d46/)讨论了这种证据边界。

阿波罗13号地面团队没有把计划中的飞船当作现实中的飞船。他们根据宇航员当时真正拥有的接口和材料解决问题。移动团队也需要同样朴素的纪律：在发布决定前，把软件放进用户真正携带的设备、真实会改变的状态和确实可能中断的流程里。

周五发现问题令人失望。周一由顾客替你发现，代价通常更高。