2026年獨佔遠端 Mac CI：Xcode 測試計畫與並行測試在自託管 Runner 上的資源爭用——xcresult 聚合、Simulator 並行度與 SSH 無頭 flaky 復現的可復現決策矩陣 + FAQ
獨佔一台遠端 Mac 跑自託管 Runner 時，「開啟並行測試」並不免費：同一時刻的多個 Simulator、xcodebuild 子行程與 DerivedData IO 會互相搶 CPU、記憶體與磁碟頻寬；xcresult 若分散在多目錄，報告聚合與失敗歸因也會變難。本文用三張決策視角——結果包聚合、並行度上限、SSH 無頭 flaky 復現——把 Runbook 寫成可執行表。若你正在做「算力池＋多台獨佔節點」規劃，可先對照
遠端 Mac mini 開發者資源池與 Xcode 編譯叢集；
需要把命令列工具鏈版本釘死到可復現描述，可並行閱讀
Nix-darwin 遠端 iOS 命令列工具鏈實踐。
1. 爭用從哪來：Test Plan × 並行 × 獨佔節點
在單租戶獨佔前提下，爭用仍會發生：同一台實體機上的多個測試目的地（不同 destination、不同 OS 組合）會各自拉起 CoreSimulator 行程、掛載映像、寫日誌與截圖；xcodebuild test 的編譯階段又與單元測試的 JIT／行程派生疊加。自託管 Runner 若再疊「同一使用者多個 Job」或「持久 ~/Library 狀態」，表現為排隊時間變長、隨機逾時，或僅 CI 復現的 flaky。
- 測試計畫（Test Plan／Scheme）：決定跑哪些 target、環境變數與設定；並行開啟後，計畫內的拆分粒度會放大為「並發 Simulator 數量」。
- 並行測試開關：提高吞吐，但把瓶頸從「單次測試慢」挪到「整機資源與 Simulator 啟動風暴」。
- xcresult：每次完整測試執行產生結果包；多階段流水線若多次呼叫
xcodebuild，需要明確「哪一個是權威失敗源」。
2. xcresult 聚合：可復現決策矩陣
目標：在報告平台（或 PR 留言）裡呈現單一結論，同時保留分 destination 的細節。下列策略依「流水線複雜度 × 是否需要歷史趨勢」選型。
| 情境 | 建議做法 | 注意點 |
|---|---|---|
單次 xcodebuild test，多 destination 串在同一 invocation |
預設單個 .xcresult；以 Xcode／xcresulttool 檢視各 destination 結果樹 |
失敗時先確認是「編譯失敗」還是「某一 Simulator 失敗」，避免被彙總狀態誤導。 |
| CI 分多步（例如先編譯再測、或依模組拆分多次 test） | 每步獨立 -resultBundlePath，上傳前以指令稿合併或產生摘要 JSON |
合併工具鏈版本須與產生包一致；合併失敗時退化為「分步 artifact＋頂層索引頁」。 |
| 僅需通過／失敗與測試計數給 Slack／GitHub | xcresulttool get test-results summary 或匯出 JUnit |
JUnit 遺失部分診斷附件時，保留原始 xcresult 作深度排查。 |
| 長期趨勢、flake 率 | 將 summary 寫入時序庫／資料倉儲；xcresult 按需保留 N 天 |
磁碟：大包與錄影會暴漲；在獨佔節點上設滾動清理與最小保留策略。 |
3. Simulator 並行度：什麼時候該關小並發
-parallel-testing-enabled 與 -maximum-concurrent-test-simulator-destinations（及等價環境／scheme 設定）是「旋鈕」，不是越大越好。下面依症狀選型。
| 現象 | 優先動作 | 原理簡述 |
|---|---|---|
整體變慢、Simulator 啟動排隊 |
降低並發 destination 數；序列化不同 iOS 版本組合 | 記憶體與映像 IO 飽和時，並行度↑只會拉長尾延遲。 |
偶發 DTXProxyChannel／通訊逾時類錯誤 |
先固定為單 destination 復現；再開並發 | 多 Simulator 下測試宿主與 UI 測試通道更易受系統負載影響。 |
| 僅 CI 失敗，本機 Xcode 正常 | 對齊 Xcode 版本、命令列 xcode-select、同一使用者下跑 |
SSH 無頭工作階段與 GUI 登入工作階段在部分權限／鑰匙圈上行為不同（參見團隊其他 CI 安全文章）。 |
| 磁碟飆滿 | 限制並行＋定期清理 Simulator 資料與舊 xcresult |
錄影、當機日誌與多模擬器資料目錄疊加很快。 |
4. SSH 無頭 flaky：可復現清單
目標：把「只在 Runner 上偶發」變成可重複實驗，而不是反覆重跑 main。建議固定順序如下（寫進 Runbook）：
- 鎖定身分：與 CI 相同使用者、相同
HOME、相同xcode-select -p輸出。 - 最小化變數：單 destination、關閉並行、固定 Scheme／Test Plan 與隨機種子（若測試支援）。
- 採集對照：同一提交在「SSH 單次跑」與「Runner 指令稿跑」各保留一份
xcresult與系統日誌片段（log show或統一日誌篩選）。 - 負載對照：在獨佔機上以
caffeinate／人工加壓（僅限測試）驗證是否與電源管理、睡眠或節流相關。 - 結論門檻：連續 N 次同結果再改產品程式碼；否則先調 CI 並行度或資源配額。
5. FAQ
Q1：並行測試開得越大，總時間一定越短嗎？
不一定。當 CPU／記憶體或磁碟成為瓶頸時，並發過高會拉長尾延遲並放大 flaky。應以「單並發 baseline → 階梯加壓 → 記錄總時長與失敗率」實證選點。
Q2：多個 xcresult 能否只靠複製目錄合併？
不建議當作正式流程。合併需工具鏈支援的匯出／摘要步驟；否則在報告系統裡用「索引頁＋分 artifact」更可靠。
Q3：獨佔 Mac 還需要限制並行嗎？
需要。獨佔消除的是「租戶間」爭搶，不消除「同機多 Simulator」與「編譯 IO」的內捲；仍要依機型記憶體與 SSD 健康度設上限。
在獨佔遠端 Mac mini 上，測試流水線更穩
本文討論的測試計畫、並行度與 xcresult 紀律，本質依賴可預期的硬體與單一管理員邊界。Apple Silicon Mac mini 在持續 xcodebuild、多 Simulator 與磁碟寫入混合負載下仍能保持較好能效比，適合長期作為自託管 Runner；macOS 原生支援 Unix 工具鏈、SSH 與自動化指令稿，排錯路徑比異構虛擬化更短。安全上，Gatekeeper、SIP 與 FileVault 便於為 CI 專用帳戶做最小權限；總持有成本上，小體積、低待機功耗與靜音運行對 7×24 節點更友善。
若你希望把上述決策矩陣落到真實獨佔節點上，Mac mini M4 仍是 2026 年高性價比的起點——從首頁瞭解方案，把 Runbook 與並行度基線一起固化即可。