Push Notification 測試：你以為推了，用戶不一定收到

Push Notification 測試：你以為推了，用戶不一定收到 「推播已送出」和「用戶收到推播」是兩件完全不同的事。從後端觸發到用戶看到橫幅，中間至少經過五個可能失效的環節——而你的測試環境幾乎模擬不了任何一個。這篇文章聊的就是這個落差。 目錄 1. 那個九成送達率的推播活動 2. 推播為什麼這麼難測 3. 推播測試要覆蓋的層次 4. Deep Link + 推播的組合 5. 結尾 那個九成送達率的推播活動 我們的 App 有一次推播活動：週一早上提醒用戶「本週目標還差 X 棵樹」，個人化內容。 活動後看數據：推播送出去了，但只有 62% 的用戶「看到」推播（App 有打開）。 我們以為是用戶沒有興趣，後來發現：有一批 iOS 用戶的推播根本沒有出現，因為他們在裝置設定裡關掉了「橫幅通知」，但保留了「App 圖示的角標」。我們的推播沒有更新角標，只發了橫幅，這群用戶完全不知道有推播。 還有一批 Android 用戶：推播送出去了，但被廠商的省電機制攔截了，App 不在白名單裡，後台被殺掉，推播顯示延遲了 3–4 小時。 這些問題在測試環境完全重現不了。 推播為什麼這麼難測 推播路徑長 你的後端 → Apple Push Notification Service (APNs) / Firebase Cloud Messaging (FCM) → 用戶裝置 → 系統通知層 → 用戶看到 這條路徑上每個環節都可能出問題：後端 payload 格式錯、APNs 連線問題、裝置通知權限設定、廠商省電機制。你在後端看到「推播已送出」，不代表用戶收到了。 測試環境和 Production 行為不同 開發用的裝置通常： 推播權限是開的 App 在白名單，不被省電機制殺死 穩定的網路 真實用戶的裝置： 可能關掉部分通知類型（只留角標，關掉橫幅） 部分 Android 廠商（小米、OPPO、華為）有積極的後台管理 網路狀況不穩 無法測試 APNs / FCM 的穩定性 APNs 和 FCM 偶爾有 latency 或失敗，這是你控制不了的外部依賴，只能監控送達率。Firebase 官方數據顯示，全球 FCM 平均送達率在理想條件下可達 95% 以上，但部分 Android 製造商（小米、OPPO、華為）的積極省電機制，會讓特定市場的實際到達率顯著低於這個數字。 推播測試要覆蓋的層次 Layer 1：Payload 格式驗證 推播的 payload 格式符合 APNs/FCM 的規範嗎？ 驗證： title 和 body 有沒有超過字元限制（iOS title 上限約 65 字元，body 約 240） 超過限制的字串有沒有被截斷處理，不是直接截掉 deep link 的 URL 格式正確 個人化內容（「差 X 棵樹」）的數字計算邏輯正確 Layer 2：通知權限的邊界狀態 | 裝置通知設定 | 預期行為 | | | | | 全部開啟 | 橫幅 + 聲音 + 角標 | | 只開角標，關橫幅 | 只更新角標，沒有橫幅 | | 全部關閉 | App 角標應更新（if 有角標邏輯），但無橫幅 | | 通知群組設定 | 群組折疊的行為 | 測試方法：在 iOS 設定裡調整各種通知選項，從後端觸發推播，確認各種設定下的行為符合預期。 Layer 3：App 狀態 × 推播行為 | App 狀態 | 預期行為 | | | | | Foreground | 通常不顯示橫幅（由 App 自行處理），或自訂 in app 通知 | | Background | 系統通知橫幅出現 | | Cold Start（點擊後） | Deep link 正確處理（見 deep link 文章）| Layer 4：送達率監控 不是測試，是上線後的持續觀察： FCM/APNs 的 delivery report 有沒有異常（大量 invalid token、大量失敗） A/B 測不同推播文案的打開率 推播時段對打開率的影響 推播組合 推播 + Deep link 的組合是最多 bug 的地方（在 deep link 文章裡也提到），這裡補充幾個推播特有的情境： 通知中心裡積壓的舊推播 用戶幾天沒開 App，通知中心有 10 條推播。用戶點了第三條（幾天前的），deep link 的目標資源可能已經不存在了（活動結束、好友刪帳）。 推播被合併 iOS 的通知會被合併（grouping）。如果你的 App 一天發了 5 條推播，iOS 可能會把它們顯示為一個群組。點擊群組展開，再點擊某一條的行為要測。 結尾 推播測試的難點不是技術，是覆蓋範圍的廣度：payload 格式、通知權限設定、App 狀態、deep link 處理、送達率監控——每個層次都有可能出問題，而且大部分問題只在真實裝置和真實用戶條件下才會出現。 從 Layer 1 開始，確保 payload 格式正確、深連結有效、各種通知設定下的行為符合預期。Layer 4 的送達率監控是長期需要做的事，讓你知道推播在真實世界的表現，而不是只知道「後端說送出去了」。 參考資料 Apple Push Notification service (APNs) — Apple Developer Firebase Cloud Messaging — Google Handling Notifications in iOS — Apple Developer Android Notification Best Practices — Android Developers Ministry of Testing — Mobile Testing Approaches