App 推送时区测试：三层时间与边界用例

推送延迟要先分清服务端调度、推送服务状态、设备接收和屏幕展示。用户反馈的“没收到”可能发生在其中任一环节。

先统一测试设备与服务端的时钟，再分别记录调度触发、服务端收到的推送状态、设备实际接收和通知展示时间。设备时区与网络出口是不同变量，应分开测试。系统推送和用户点击后加载页面也可能走不同网络路径；只有实际配置走代理的请求才使用该出口。本文聚焦自有 App 的验证。

分别记录调度、接收与展示

这几个时间点由不同环节产生，记录时应使用同一通知 ID，并区分服务端日志与设备侧观测。

调度触发时间

查看计划触发时间与任务实际执行时间，并记录使用的时区。固定偏移可能来自本地时间与 UTC 转换不一致，不应先归因为地区网络。

设备接收时间

推送服务受理或投递状态不等于设备已经收到。优先记录设备侧通知日志；无法观察设备接收时，标为未知。通知类型、优先级、平台规则和系统状态都可能影响结果，应结合通知 ID 和统一时钟分析。

屏幕展示时间

检查通知实际出现的时间、顺序和分组。系统策略可能造成延迟或摘要展示；先记录现象，再按产品预期、平台规则和同类设备结果判断是否异常。字段缺失、落地错误、延迟、丢失或重复都应有记录。

分别比较计划触发、实际执行、服务端状态、设备接收和展示。差异能帮助定位环节，但单一时间差不能直接证明根因。

测试跨日与夏令时边界

覆盖 UTC 跨日、跨月与跨年边界。夏令时测试使用 IANA 时区而非固定偏移量，例如 Europe/Berlin 的春季跳时与秋季重复时段。测试前先明确不存在或重复的本地时间应跳过、顺延还是执行多次，并记录计划与实际执行时间。

尽量在同一批次执行对照，并记录每条用例的计划与实际触发时间。

分开测试设备时区与网络出口

测试时先固定出口，只改设备时区，观察展示时间和日期文案；再固定时区，只改变出口，检查地区化页面或接口响应。不要把出口变化直接当作推送投递差异的原因。

检查点击后的落地页面

点击行为应与推送投递分开验证。记录冷启动、已登录和链接过期等场景下的落地页面、耗时与回退结果，并注明当时的设备时区和实际网络路径。

冷启动时记录首屏耗时和目标页面是否保留；已登录时检查页面状态；链接过期时检查提示与回退页面。

实际测试可用一行记录计划时刻与 IANA 时区、对应 UTC、调度和设备侧证据、点击结果。春季跳时和秋季重复时段分别建用例；设备接收无法观测时写“未知”，未实际执行时不要填写通过或失败。

推送服务到设备的链路与 App 请求可能不同，应根据实际配置分别观察。代理出口可用于测试配置走该出口的地区化请求；目标地区测试机或云主机也可提供对照。