iPhone Duo 上市前，iOS App 還需要重新測試哪些地方？從模擬器到真機測試要花多少錢？

症狀：iPhone Duo 的正式規格與支援資訊尚未核實，直接照傳聞改測容易漏掉真正的發布風險。
最快解法：先用已確認的裝置、系統與 App 支援範圍縮小回歸清單，再以模擬器篩查、真機驗證硬體相關行為；費用則按實際設備、環境、週期與人力核算，不先猜金額。

這篇適合準備更新 iOS App、需要制定回歸測試清單的開發者與 QA。
也適合負責測試排程與預算的工程管理者，以及評估遠端 Mac 環境能否協助建置、除錯或自動化測試的團隊。

先界定 iPhone Duo 上市前的回歸範圍

截至本次資料核對，可用的官方資料不足以確認 iPhone Duo 的上市狀態、正式名稱、螢幕規格、系統相容性或特殊功能。因此，不要把未確認的外型、顯示方式或硬體能力寫成測試前提；先核對正式產品資料與你目前支援的裝置、系統版本，再判斷哪些項目會受影響。

回歸優先級可按三個維度判斷：使用者受影響程度、程式碼變更範圍，以及錯誤對發布的風險。登入、付款、資料同步等流程若近期有改動，通常應排在僅影響低流量頁面的視覺微調之前；若新裝置的規格尚未確認，先把相關項目列為待核實，不要據此宣稱已完成適配。

先建立一份範圍表：列出目前正式支援的裝置與系統版本、受影響功能、既有缺陷、需重新執行的案例，以及尚待確認的產品資訊。官方 UIKit 版面文件涵蓋安全區域與版面配置等概念；你可以據此檢查 App 是否依據可用版面空間配置內容，而不是假設新裝置必然採用某種螢幕尺寸或比例。UIKit 版面配置文件

提醒：媒體傳聞可以用來準備待測清單，不能當成裝置規格。只有在可靠來源確認相關能力後，才把它轉成正式驗收條件。

介面與版面要檢查哪些條件？

iPhone Duo 上市前，iOS App 的介面複測應從實際支援範圍出發，優先檢查版面伸縮、文字顯示、方向切換與操作可達性。沒有經核實的螢幕參數時，不要指定某個尺寸作為唯一驗收基準；改用專案已支援的顯示條件與設計稿，逐頁比較內容是否被遮住、擠壓或截斷。

請依序查看以下項目：

• 版面與安全區域：檢查導覽列、底部操作列、表單及浮動元素有沒有被系統介面遮住；確認約束、邊距與可用空間改變時，主要內容仍能閱讀與操作。
• 文字與內容：查看長標題、多語文字、錯誤訊息及動態內容是否截斷、重疊或推擠按鈕；不要只用短句和理想資料測試。
• 方向與顯示狀態：若 App 支援方向切換，驗證切換前後的欄位、捲動位置和未送出的輸入是否符合產品預期。若不支援，確認系統不會讓操作停留在錯誤狀態。
• 觸控與手勢：確認按鈕可觸及、相鄰操作不易誤觸，並測試滑動、返回和鍵盤出現後的版面變化。
• 彈窗與系統介面：檢查權限提示、分享、鍵盤及其他系統互動出現後，使用者能否完成原本流程並返回正確位置。

對照設計稿時，記錄裝置與系統資訊、操作步驟、畫面差異和判定結果。版面配置文件能提供 UIKit 相關規則，但不能替你證明新裝置的實際顯示條件；在規格未確認前，應把差異列作待驗證項目，而非預先判定通過。UIKit 版面文件中的配置說明

系統相容與核心流程的回歸優先級

系統相容性應以已確認的目標系統版本和 App 實際支援範圍為準。接著依功能清單、程式變更紀錄與既有測試案例，安排權限、通知、登入、付款、網路中斷、背景恢復及異常輸入等檢查。若 App 不使用某項能力，不必為了新裝置傳聞而加入無關測試；若使用者流程依賴該能力，才納入回歸。

特別留意權限的前後狀態：首次授權、拒絕、稍後在系統設定變更，以及 App 返回前景後的處理都要符合產品預期。通知授權文件說明了向使用者請求通知權限的流程；測試時應檢查授權結果如何影響 App，而不只確認提示是否出現。通知使用權限的官方說明

核心流程可依風險採用以下順序：

• 先跑近期改動且會阻斷主要服務的流程，例如登入、付款或資料提交。
• 再測試權限被拒、網路中斷、伺服器回應延遲及輸入格式錯誤等邊界情況。
• 最後確認 App 進入背景、重新啟動或恢復連線後，畫面狀態與資料沒有不一致。

這個排序不是固定的功能清單：若你的 App 不處理付款，就以真正影響使用者的核心流程替代；若新裝置能力尚未獲可靠來源確認，先標記為待核實，不能把它當作必測功能或已通過項目。

模擬器夠用嗎？真機要補哪些驗證？

模擬器適合在早期快速檢查版面、基礎流程和自動化回歸；真機則用來驗證實際觸控感受、硬體相關互動、效能表現與系統在實體裝置上的行為。兩者不是二選一：模擬器結果可用來縮小問題範圍，但不能直接替代真機驗收。

官方 Xcode 文件將在模擬裝置和實體裝置上執行 App 分開說明，正好反映兩種環境各有用途；測試計畫也可納入專案測試流程。Xcode 模擬與實體裝置執行說明；將測試加入 Xcode 專案

決策條件：

• 若問題只涉及一般版面、基本導覽或可自動化的邏輯回歸，先用模擬器篩查；若結果穩定，再把高風險流程抽到真機確認。
• 若功能依賴實體硬體、實際觸控，或錯誤可能造成付款、資料或發布風險，必須安排真機測試；模擬器通過不能作為唯一驗收依據。
• 若目標裝置或系統資訊仍未核實，先暫緩該裝置的最終驗收結論，改測已確認的支援範圍，並把待核實事項列入發布阻擋清單。

真機測試費用的估算邊界

從模擬器轉到真機測試，沒有可套用所有團隊的固定金額。實際成本取決於測試所需裝置如何取得、設備與環境是否可用、覆蓋多少功能與系統條件、測試持續多久、是否要並行，以及誰負責執行和分析結果。若沒有已確認的設備資源與服務報價，就不應把任何估算金額寫成實際費用。

預算前把下列資訊整理好，再向設備或環境提供方核實：

• 需要的實體裝置與系統條件，以及是否必須是特定待測機型。
• 真機測試案例、執行頻次、測試週期與需要同時使用的設備數量。
• 測試者、除錯、建置、維護自動化案例及整理缺陷的工時。
• 設備取得、運送或交付方式、可用時段，以及是否另有環境或服務費用。

遠端 Mac 環境、建置資源與 iPhone 真機是不同資源。遠端 Mac 可供符合條件的建置、除錯或自動化工作使用，但不能據此推定服務包含 iPhone 真機；設備是否提供、可用條件與費用都要分開確認。撰稿時沒有可引用的 Kvmjet 即時報價、租期或真機供應資料，因此本文不列金額，也不推定設備可用性。你可先查看現有基礎設施說明，再以實際服務頁面或書面確認資料完成預算。

最後更新：本次資料核對；產品上市狀態與規格未由本文可核實的官方資料確認。測試平台說明依據上述官方開發者文件，撰稿時不將傳聞當成產品事實。

把測試清單轉成發布計畫

安排回歸時，先在模擬器上跑高頻、可自動化且容易重現的案例，再依風險選出真機測試重點。每項結果都記錄裝置與系統資訊、測試案例、預期結果、實際結果及缺陷連結，避免只留下「已測」而無法重現的紀錄。

發布前逐項核對：

• 裝置名稱、規格與目標系統資訊已從可靠來源確認；未確認內容仍標示待驗證。
• 主要使用流程、權限與異常情境已有測試結果。
• 模擬器與真機各自負責的項目清楚，真機覆蓋範圍有風險依據。
• 設備、環境、測試週期、並行需求與人工投入已按真實資源核實。
• 遠端 Mac、建置環境與 iPhone 真機是否包含在同一服務內，已分別確認。

如果你目前依賴自有設備，可能受限於機型數量、設備被其他工作占用，以及維護測試環境的人力；若改用遠端 Mac，仍不能假設它附帶真機。對需要臨時建置、除錯或跑自動化的團隊，租用 Kvmjet Mac 環境可作為自備 Mac 之外的選項，但要先確認該服務實際支援的工作與資源範圍。整理好目標裝置、測試週期與清單後，可向 Kvmjet 查詢實際可用資源；若真機是否包含在內尚未確認，先取得答覆再編列預算。