本機與 CI 對同一個跨框架測試呈現不同結果，讓你不確定該改測試還是改設定。
四種模式中，漸進遷移先以 complete 評估：它保留跨框架問題原有嚴重級別；舊 Test Plan 可能仍是 limited，strict 適合要阻止特定呼叫的團隊。不要把 none 當作讓 CI 變綠的常規修復方式。
維護 XCTest 存量測試、準備增量引入 Swift Testing 的開發者，可用本文選擇遷移期間的互操作模式。
負責 Xcode Test Plan 和 CI 的工程師，可據此核對本機與遠端測試的設定。
制定測試規範的技術負責人，可用這些指標區分相容遷移、嚴格治理與臨時排障。
最後更新於 2026 年 10 月 7 日；模式行為與設定入口核對自 Apple 的 Xcode 27 發布說明、Swift Testing 遷移文件及 WWDC26 遷移示範。
01 互操作範圍：同一測試套件可以混用框架
可以。Swift Testing 與 XCTest 能在同一個測試套件中共存；互操作設定決定的是跨框架測試問題如何處理，並不代表要一次替換整套測試框架。Apple 的測試概覽與XCTest 框架說明分別界定兩套工具的測試用途；遷移時應先看實際呼叫邊界，而非只看測試檔案用了哪一種語法。
例如，Swift Testing 測試中呼叫 XCTest 的斷言 API，就會形成跨框架情境。你要觀察的是這個呼叫產生的問題是否被記錄、嚴重級別是否符合預期，以及測試執行是否仍能回報結果。這比單純確認兩種框架都能編譯更能反映遷移風險。
| 評估指標 | limited |
complete |
strict |
none |
|---|---|---|---|---|
| 跨框架處理範圍 | 有限度處理，保留相容性 | 完整處理跨框架問題 | 對指定的跨框架呼叫採嚴格限制 | 關閉互操作處理 |
| 問題嚴重級別 | 依既有行為處理 | 保留問題原有嚴重級別 | 適用於要阻止特定呼叫的政策 | 可能不再呈現可供判斷的問題 |
| 適合情境 | 舊測試計畫或尚未完成遷移 | 漸進遷移的評估起點 | 已有明確禁止規則 | 有明確排障目的時短暫檢查 |
| 主要風險 | 可能未符合新團隊的可見性要求 | 仍須確認結果符合團隊驗收標準 | 限制過嚴會阻斷仍需保留的舊呼叫 | 掩蓋跨框架問題 |
Apple 的遷移文件和 Issue.record 嚴重級別文件可協助你核對問題如何呈現。不要把 complete 理解成「自動修復斷言」；它保留的是問題原有嚴重級別，測試本身是否合理仍要由你驗證。
02 問題可見性：按治理需求選模式
如果你要在不中斷舊測試的前提下觀察遷移影響，先用 complete 跑一組最小跨框架測試，再比較報告中的問題數量與嚴重級別。這個基準能幫你判斷後續該保留相容行為、建立禁止規則，還是回頭修改測試。
limited：適合先維持既有測試計畫的相容處理；但不能只因測試通過，就假定問題都已充分呈現。complete：適合增量導入時評估跨框架問題；預期保留問題原有嚴重級別，便於與團隊既有規則比對。strict：適合已決定阻止特定跨框架呼叫的團隊。先確認被限制的呼叫確實不應留在程式碼中，再納入持續整合檢查。none：只在你有明確排障目的時暫時使用。若以它作為固定設定，可能讓有價值的跨框架問題失去可見性。
若
none讓 CI 轉綠，先確認測試問題是否只是停止呈現；不要把「沒有看到問題」當成「問題已解決」。
03 舊 Test Plan：Xcode 升級不代表設定同步更新
舊 Xcode Test Plan 升級後仍可能是 limited。Xcode 版本不能單獨代表專案當前採用的互操作模式；較早建立的計畫可能保留原設定，因此先在實際使用的 Test Plan 中檢查，再決定是否統一調整。Apple 的測試計畫組織與設定說明可用來核對計畫層級的設定位置。
| 檢查對象 | 可能造成的差異 | 你要留下的證據 |
|---|---|---|
| 新建 Test Plan | 使用建立時適用的預設行為 | 計畫設定畫面與測試結果 |
| 舊 Test Plan | 可能沿用既有的 limited 設定 |
升級前後的設定紀錄 |
| 同專案多個 Test Plan | 不同計畫可能採用不同互操作模式 | 每個計畫的名稱、設定與執行結果 |
所以，遇到「Xcode 已升級但還是 limited」，先確認執行中的 scheme 指向哪一個 Test Plan，再逐一檢視計畫設定。不要只在一份計畫上改值，就推定其他 scheme 或 CI 工作也已套用。
04 Swift Package 與 Xcode 專案：分開檢查預設行為
Swift Package 和 Xcode Test Plan 的設定入口並不相同，也不能假定它們會自動採用相同預設。Swift 工具鏈版本及 swift-tools-version 都可能影響你實際遇到的行為；Apple 的遷移文件與 Xcode 發布說明應作為核對依據。若文件沒有明確涵蓋你的組合，就把它記為待驗證，不要外推成所有專案通用的結論。
| 專案類型 | 優先檢查的位置 | 常見驗收盲點 |
|---|---|---|
| Swift Package | Package 設定、工具鏈及套件的 swift-tools-version |
命令列使用的工具鏈與本機 Xcode 不一致 |
| Xcode 專案 | 實際執行的 Test Plan 與 scheme | 舊計畫保留設定，其他計畫未同步 |
| 兩種方式並用 | 相同測試樣例的命令列與 Xcode 結果 | 只核對其中一個執行入口 |
實際操作時，先選同一個會呼叫 XCTest 斷言的 Swift Testing 測試，分別從 Xcode 與命令列執行。記下兩邊的工具鏈、Test Plan（如適用）、互操作模式及問題嚴重級別。Apple 的命令列執行與結果解讀說明可協助你確認命令列測試的執行及結果檢視方式。若輸出不同，先查執行設定，不要急著改斷言程式碼。
05 CI 可觀察性：用同一樣例完成驗收
遠端 Mac CI 要驗收的是設定一致性，不是只看工作是否成功結束。你需要把本機 Xcode、命令列與 CI 的執行入口分開記錄；若遠端節點使用不同工具鏈或執行計畫，即使測試程式碼相同，也不能直接把結果差異歸因於框架。
按以下順序操作，並把結果放入變更紀錄：
- 選定測試樣例：保留一個 Swift Testing 測試呼叫 XCTest 斷言的最小案例，確定它能涵蓋團隊關注的跨框架情境。
- 記錄本機設定：記下 Xcode 與 Swift 工具鏈版本、實際執行的 scheme 和 Test Plan，以及互操作模式。
- 核對套件設定：若專案含 Swift Package，確認
swift-tools-version與命令列使用的工具鏈，避免把不同執行環境當成相同前提。 - 執行命令列測試：用與 CI 相同的入口執行樣例，保留輸出與測試結果，不只記錄結束狀態。
- 比對遠端 CI：確認 CI 實際選到的 scheme、計畫與工具鏈，再把問題是否出現、嚴重級別及舊測試能否繼續執行逐項對照。
- 依證據決定遷移策略：若問題可見性與團隊政策一致，才統一模式；若差異尚未查明，先保留設定並修正環境差異，不要用
none掩蓋它。
驗收勾選清單
- [ ] 本機、命令列與 CI 都執行同一個跨框架測試樣例。
- [ ] 每個入口使用的 Test Plan、工具鏈與互操作模式均已記錄。
- [ ] 跨框架問題是否被記錄，以及其嚴重級別，符合團隊預期。
- [ ] 原有 XCTest 測試仍能執行；若有失敗，已能重現並定位原因。
- [ ] 若採用
strict，被限制的呼叫與團隊規範相符。 - [ ] 若曾暫用
none排障，已恢復正式設定並重新執行驗收。
如果你目前缺少能執行 Xcode 測試的 Mac 環境，可先評估遠端 Mac 開發與測試環境是否符合專案需要；若只在特定遷移或驗收期間需要，先查看租賃方案與週期。相較於長期維護一台專用主機，遠端測試環境也要考慮網路連線、節點設定一致性與實體裝置驗證等限制；若你需要長期固定負載或直接連接實體設備，自購 Mac 可能更合適。先確認現有 Test Plan，再用同一樣例比對本機與 CI；確定需要可執行 Xcode 的 Mac 時，再按實際測試週期選擇CALMVPS 遠端 Mac 方案。