使用者在戶外有衛星訊號，App 卻停在登入或提交畫面，團隊該先查哪裡？
最快做法：先把 T-Satellite 視為受裝置、覆蓋與網路條件限制的補充連線，測完核心任務在延遲、中斷及應用支援限制下的降級方式，再決定能否對外承諾。
適合負責網路請求與離線體驗的行動開發者，用來設計弱網驗收。
為戶外或偏遠地區開發工具的產品團隊，可據此確認核心流程是否可用。
準備說明衛星連線支援範圍的技術負責人，可用時間線核對證據和回退機制。
最後更新於 2026 年 10 月 1 日；資料核實自營運商官方裝置與應用支援清單及服務覆蓋與限制說明。支援裝置、應用名單和可用地區可能變動，發布前應重新查核官方頁面。
測試前：先界定可宣稱的支援範圍
測試計畫開始前，先記錄查核日期、服務地區、相容裝置與系統版本，並保存當時的官方清單或頁面截圖。官方公告提到 T-Satellite 支援訊息及部分衛星最佳化應用；官方支援頁另列出適用範圍與限制，兩者都不能解讀成所有 App 或所有網路協定均可使用。官方公告是服務背景，不應取代發布前的即時支援清單。
某個衛星最佳化應用可以連線，是否代表其他 App 也可用？
不能。應用列入支援清單，只能作為該應用及其指定功能的依據；不能因此推定任意登入流程、即時資料串流、檔案上傳或自訂通訊協定也能正常運作。測試紀錄應把「服務有覆蓋」和「特定應用或功能獲支援」分開記載。
| 查核項目 | 要保存的證據 | 未確認時的處理 |
|---|---|---|
| 服務覆蓋 | 官方覆蓋頁面、查核日期、測試地點 | 不對該地點宣稱可用 |
| 裝置相容性 | 官方支援清單中的裝置與系統條件 | 以實際相容裝置測試，不外推至其他機型 |
| 應用支援 | 清單列出的應用或功能、頁面版本 | 僅標示已核對的功能，不承諾整個 App 可用 |
| 服務限制 | 官方對速度、功能及連線狀況的說明 | 在產品提示中保留限制，不寫成一般行動網路體驗 |
注意：有衛星覆蓋不等於測試現場當下必定連線成功。遮蔽、位置、裝置條件和服務限制都可能影響結果；官方說明應作為範圍界線，現場測試則用來回答產品流程是否可接受。服務說明
測試中：用核心任務找出請求失敗點
不要只測首頁能否載入。先選出失敗後會影響使用者安全、現場作業或資料正確性的核心任務，再將流程拆成登入、讀取、提交及狀態回報。每個步驟都要寫明前置條件、預期結果、失敗後顯示內容，以及資料能否在連線恢復後補送。
衛星網路下，請求逾時應如何處理？
逾時不是「使用者沒有送出」，也不是「伺服器一定沒有收到」。介面要明確區分處理中、結果未知和已確認完成，並提供安全的查詢或重試方式。Apple 平台的 timeoutIntervalForRequest 文件列出預設值為 60 秒，但這是平台設定資料，並非 T-Satellite 的延遲保證；團隊應依任務類型調整逾時策略，不能把預設值直接當成衛星連線的驗收標準。平台逾時參數說明
| 流程階段 | 要測的情況 | 可接受的產品行為 |
|---|---|---|
| 登入 | 驗證請求逾時、重新開啟 App | 顯示登入狀態未知或要求確認，不誤報登入成功 |
| 讀取 | 請求中斷、重新連線後重取 | 顯示資料時間或載入狀態，避免把舊快取標成最新 |
| 提交 | 伺服器已收到但回覆未返回 | 可查詢結果或安全重試，不能因重送而重複建立紀錄 |
| 狀態回報 | 使用者切換 App，連線其後恢復 | 恢復後更新狀態，明確呈現尚未同步的資料 |
HTTP 規範將 408 定義為請求逾時回應；這能協助測試伺服器回覆，但用戶端也可能只看到連線逾時、無回應或中斷，不能只靠單一狀態碼判斷結果。對可能重複送出的操作，應檢查伺服器端冪等設計、請求識別碼及結果查詢流程；HTTP 對安全與冪等方法的定義可作為設計參照，但建立資料的 POST 請求不能僅因重試而假設安全。HTTP 語意與狀態碼規範
測試中：覆蓋中斷、重送與狀態復原
測試應刻意製造「請求已送出、回應未收到」這類模糊狀態，而不只是關閉網路後確認畫面出現錯誤。至少驗證連線突然消失、等待逾時、使用者離開畫面、恢復後重試，以及快取與伺服器資料不同步等路徑。每次紀錄裝置、系統版本、地點、服務條件、App 版本和重現步驟，避免把一次成功寫成普遍效能結論。
如何確認中斷後真的恢復，而非只恢復網路圖示？
先記下中斷前的資料狀態，再恢復連線並檢查伺服器端結果、用戶端畫面及本機佇列是否一致。尤其是簽到、派工、付款或庫存異動，必須確認重試不會建立重複紀錄；若操作結果仍未知，介面應引導使用者查詢，而不是鼓勵連續點擊提交。
Android 網路狀態文件說明如何監聽網路變化，但網路狀態回呼只能表示系統觀察到的連線變化，不能代替對特定服務端點的請求驗證。網路狀態監測文件因此可用於觸發復原檢查，實際是否可完成登入或同步，仍須以核心任務結果判定。
建議依下列清單逐項留下測試紀錄：
- [ ] 確認測試裝置、系統版本、App 版本及官方支援狀態。
- [ ] 記錄測試地點、查核日期及當時可確認的服務條件。
- [ ] 完整操作一次登入、讀取、提交和狀態回報流程。
- [ ] 在請求送出前、送出後及等待回覆時分別中斷連線。
- [ ] 恢復連線後檢查資料一致性、快取更新與待同步佇列。
- [ ] 重試有副作用的操作，確認不會造成重複提交。
- [ ] 記錄使用者切換 App 或返回畫面後的狀態與提示。
- [ ] 將成功、失敗及結果未知分開分類，不以單次成功作為支援承諾。
發布前：把功能降級寫進產品行為
將功能分成可離線使用、連線恢復後可同步，以及必須即時連線才能完成三類。離線可用的功能要說清資料是否可能過期；待同步操作需呈現佇列狀態；無法離線完成的流程則提供安全退出或稍後重試方法。支援文字應逐項對照官方當前清單，不要用「衛星網路可用」概括成整個產品都能工作。
提醒：沒有收到錯誤訊息，不代表伺服器已完成操作；在結果無法確認時，介面應顯示待確認狀態，並提供查詢或人工處理路徑，而非顯示成功。
發布驗收還要檢查提示文字是否把「沒有覆蓋」、「目前無法連線」與「此功能不受支援」混為一談。三者代表不同原因，後續處置也不同：前者需等待合適地點或服務條件，暫時中斷可稍後重試，而功能支援範圍則應以官方清單及實際驗證為準。
上線後：用可重現證據維護相容說明
上線後將回報按裝置、系統版本、App 版本、地點、操作流程和問題類型分類，並記錄發生時間及可重現步驟。官方新增支援裝置、應用或地區時，先判斷哪些核心流程受影響，再安排回歸測試；不要因單一使用者回報就直接擴大相容承諾。若支援清單變更，更新產品說明與客服處理方式時，也要保留舊版查核紀錄，方便釐清問題發生時的服務範圍。
如果團隊尚未建立弱網驗收流程，可先參考本站的支援與操作說明入口，並將衛星支援範圍與實際測試條件分開記錄。若測試缺少 macOS 建置資源，短期租用 Vuncloud Mac 可作為環境選項，但它不能取代具備衛星服務的實體裝置，也不能模擬現場覆蓋與無線連線條件；現有本機 Mac 或其他建置方式若已足夠，就沒有為衛星驗收額外租用的必要。
因此，團隊可先依清單在實際支援裝置上驗收，再把衛星連線定位為有限條件下的補充通道。上線前仍應重新核對官方支援頁，並把弱網下的失敗、復原與離線行為明確寫進產品承諾。