企業 Mac CI 一開 Xcode 並行測試，長尾常在模擬器與系統服務搶資源：CoreSimulator、快取與 xcresult 寫入會同時頂高 CPU、記憶體與磁碟 I/O。把 Test Plan 切成可預測佔用的片，比單純拉高 -parallel-testing-worker-number 更穩。資源池見 企業 Mac CI 資源池選型；快取與水位見 自託管 Runner 並行 CI 與磁碟 FAQ。
一、爭搶從哪裡來：並行測試不是「多開幾個執行緒」而已
多個 UI 測試工作階段會重疊啟動模擬器，RAM 之外還有大量小檔寫入。xcodebuild test 與打包 Job 同機時，磁碟佇列一深就出現「超時但 CPU 不忙」的假性空閒。先把瓶頸歸成記憶體壓力、I/O 水位、裝置配對三類，再談並行度。
二、Test Plan 切分：用「邊界」取代「勇氣」
實務用三條邊界降噪：測試類型拆 UI／Unit；Runtime 拆 iOS 版本或裝置；模組 拆 target。Test Plan 把每包測試的 RAM 與周邊權限變成可排程單元。全量仍跑同一方案時，把長時佔用模擬器的套件丟夜間批次，白天留快路徑。
三、高記憶體節點 vs 拉高 worker 數：怎麼對照
高記憶體節點壓低 swap 與壓縮記憶體抖動，適合同時開機數可控、單次峰值高的專案。拉高 worker 等於堆更多模擬器實例；SSD 或快取跟不上時，失敗會從 OOM 換成 I/O 逾時。判準：記憶體壓力常黃紅先加 RAM；磁碟佇列與 simctl 錯誤升溫先降並行或拆機，別再加 worker。
四、磁碟水位：比「剩幾 GB」更重要的指標
水位別只看剩餘 GB：把可用空間比例與寫入延遲一起看。DerivedData、模擬器資料、Artifacts、xcresult 幾輪夜間批次就堆高。清理放 Job 的 always()，報告訂 TTL；快取與持久碟分工寫進 Runbook。
- 每個並行工作階段使用獨立
-derivedDataPath與結果輸出目錄。 - 水位觸發時先降並行，再評估擴容 SSD 或分流到專用測試節點。
五、對比 FAQ（精簡）
- UI 與 Unit 能同一個 worker 池混跑嗎？可以，但建議分 Test Plan，避免 UI 峰值拖垮短測試。
- 模擬器版本要與 Xcode 鎖死嗎？是，Runtime 漂移會讓並行測試更難重現。
- 先加記憶體還是先加機？記憶體壓力主導時加 RAM；I/O 與服務競爭主導時分流節點。
在 Mac mini 上把測試池跑順
測試池常長時間併行、無人值守。macOS 與 Xcode 讓模擬器與簽章邊界一致；Mac mini 的 Apple Silicon 記憶體頻寬利於多模擬器，待機約 4W 適合 7×24。Gatekeeper、SIP、FileVault 疊出安全邊界。
Runbook 定稿後要驗節點，可打開 Macstripe 首頁對照區域。Mac mini M4 仍是 2026 年擴測試池的高性價比起點；並行度交給監控，不靠感覺。若你準備把測試搬到獨享節點，現在就讓延遲下降——前往首頁了解更多。
