xcodebuild 的測試結果要怎麼存到指定位置？

在測試命令加入 -resultBundlePath，並把路徑指向專用的 .xcresult 位置。路徑應能區分工作流程執行、工作與重試，不要放在會被清理的來源目錄；平行測試也要各用不同路徑，避免結果互相覆蓋。

遠端 Mac CI 有產生 xcresult，為什麼工作流程產物裡找不到？

先確認測試步驟確實執行，再檢查上傳步驟是否因前一步失敗而被跳過。接著比對實際結果包路徑與上傳範圍；結果包是目錄時，若只選到內部檔案或不相符的萬用字元，可能沒有把整個結果包交給產物步驟。

GitHub Actions 的 xcresult 產物要在哪裡下載和開啟？

從工作流程執行記錄的產物區下載對應項目，確認下載後仍保有 .xcresult 結果包，再於 macOS 使用 Xcode 或 xcresulttool 檢查。若下載的是壓縮檔，先解壓縮到可讀寫位置；只確認產物名稱出現，不能證明內容可讀。

測試失敗時要怎樣避免 Xcode 結果包被丟掉？

把結果上傳設為測試失敗後仍會執行的步驟，並確認測試命令結束前已寫出結果包。取消工作流程、節點中斷或結果尚未完整寫入是另一類情況，應另行驗收；若沒有符合上傳範圍的檔案，應讓工作流程明確報錯，而非靜默略過。

遠端 Mac CI 的 xcresult 怎麼匯出？2026 指南

本文協助遠端 Mac CI 維護者設定可追蹤的 xcresult 路徑，並避免測試失敗時遺失結果包。你會看到產物策略比較、上傳與下載檢查步驟，以及供 CI、測試和平台負責人使用的決策條件。

本週建議：先在 xcodebuild test 指定獨立的 .xcresult 路徑，再把整個結果包設為工作流程產物；測試失敗時也要執行上傳，最後實際下載並開啟驗證。這適用於你需要在遠端 Mac CI 執行 Xcode 測試，並在工作結束後取回診斷資料的情況。

CI 維護者：確保測試結果離開遠端 Mac 後仍可追蹤、取回。
測試工程師：從結果包檢查失敗細節、測試日誌或專案需要的覆蓋率。
發布與平台負責人：為產物訂定可追溯的命名、留存與存取界線。

遠端 Mac CI 的 xcresult 匯出，先確認結果由測試生成

xcresult 不是一般建置日誌，也不能直接當成歸檔發布檔。你要先確認工作流程真的執行了測試，再判斷測試結果包是否生成；Apple 說明 xcodebuild 執行測試會產生包含測試結果等資訊的結果包，xcresulttool 則提供檢查入口。Apple 的 Xcode 測試結果說明也列出如何在 Xcode 中檢視及解讀結果。

Apple 在 Xcode 11 的發布說明中介紹了測試結果包。這項版本資訊有助於釐清概念來源，但你仍應按目前使用的 Xcode 版本核對命令參數與可用檢查方式。Xcode 11 發布說明

先用這個對照判斷輸出策略。評級是依可追溯性、覆寫風險及故障診斷需要所做的工程判斷，不代表平台效能測試。

輸出策略	可追溯性	覆寫風險	適合情況
專用結果目錄，按執行與工作命名	高	低	長期維護 CI、需要比較重跑結果
固定路徑放在來源目錄內	低	高	僅適合短暫本機驗證，不建議作為交付路徑
多個平行工作共用同一路徑	低	高	應改為每個工作各自指定結果包位置

也要分清三種不同交付物：建置日誌通常提供命令輸出；.xcresult 用於檢視測試結果及相關診斷資料；歸檔產物則服務於後續簽署或發布流程。Apple 的命令列工具參考可用來核對 xcodebuild 與 xcresulttool 的命令介面。不要因為 CI 顯示「建置完成」，就假定工作流程已產生可供測試人員使用的結果包。

建置工程師：為每個測試工作指定獨立路徑

指定結果包路徑的作用，是讓你知道某一個測試工作把結果寫到哪裡，並讓上傳步驟可以選取同一個位置。Apple 的命令列工具文件列出 -resultBundlePath 這項參數；實際可用的選項仍以你正在使用的 Xcode 文件為準。xcodebuild 命令列工具參考

RESULT_ROOT="/path/outside-repo/results"
RUN_KEY="replace-with-run-job-attempt"
RESULT_PATH="$RESULT_ROOT/$RUN_KEY.xcresult"

mkdir -p "$RESULT_ROOT"
xcodebuild test \
  -scheme "$SCHEME" \
  -destination "$DESTINATION" \
  -resultBundlePath "$RESULT_PATH"

執行前，將 RESULT_ROOT、RUN_KEY、SCHEME 與 DESTINATION 換成你的 CI 實際值。把結果目錄放在不會被來源清理流程刪除的位置，並以執行識別、工作名稱及重試識別組成唯一名稱；不要讓新測試沿用已存在的結果包路徑。若測試會平行執行，應分配彼此獨立的目錄，而不是只靠工作流程結束後再重新命名。

工作流程維護者：測試失敗後仍要執行上傳

GitHub Actions 的工作流程產物可用來保存及下載建置或測試輸出；官方文件也說明上傳步驟可依路徑選取檔案、目錄及符合條件的項目。保存工作流程資料的官方說明明確區分產物與快取用途：你要取回測試結果時，應建立工作流程產物，而不是把快取當成留存機制。

工作流程順序至少要包含測試、結果包上傳和失敗診斷；最關鍵的是，上傳不能只在測試成功後才執行。GitHub 的狀態檢查運算式文件說明了步驟執行條件；依你的取消與失敗處理政策，為上傳步驟設定能在測試失敗後繼續執行的條件。若使用 !cancelled() 這類條件，也要在目標工作流程中測試失敗及取消時的實際行為。

設定時特別檢查以下情況：

上傳範圍指向結果包所在的目錄，而不是僅指向其中某個檔案。
路徑與測試命令使用的 RESULT_PATH 一致，沒有引用另一個工作或舊工作目錄。
找不到預期檔案時讓步驟明確失敗，避免工作流程表面成功、實際沒有產物。
如果使用多個路徑或萬用字元，先檢查實際選取範圍。GitHub 說明不同路徑的共同根目錄會影響產物內的目錄結構；工作流程產物概念文件可供核對相關行為。

測試工程師：下載後確認結果包可讀

工作流程頁面顯示有產物，不等於結果包內容完整或可讀。從該次執行記錄下載對應產物後，先確認解壓縮結果中有完整的 .xcresult，再於 macOS 使用 Xcode 開啟，或以 xcresulttool 檢查摘要及測試項目。Apple 的測試結果解讀指南說明如何透過 Xcode 檢視結果；命令列檢查方式則應對照所用版本的工具文件。

你可以先執行摘要檢查，再依專案的診斷需求查看測試清單：

xcrun xcresulttool get test-results summary --path "$RESULT_PATH"
xcrun xcresulttool get test-results tests --path "$RESULT_PATH"

檢查的重點不是命令能否執行而已，而是結果是否足以支援下一步判斷：測試摘要能否識別失敗工作、失敗資訊是否指出測試項目與錯誤、專案要求的覆蓋率或附件是否確實存在。若結果包能開啟但欠缺必要內容，回頭檢查測試方案及收集設定；若無法開啟，先確認下載與解壓縮後的目錄完整性。

CI 維護者：用決策條件定位遺失的結果

遇到「有測試失敗但沒有結果包」時，依證據走分支，不要先假設是上傳平台故障：

若測試步驟沒有執行，回查工作流程條件、工作路由與測試命令；沒有測試執行證據，就不能假設已生成測試結果包。
若測試已執行，但指定位置沒有 .xcresult，檢查 -resultBundlePath 的實際值、路徑是否可寫，以及平行工作是否覆用了同一位置。
若結果包存在，但產物未出現，回查上傳條件、路徑選取範圍及上傳錯誤；若選取萬用字元沒有匹配整個結果包，改成指向實際目錄。
若產物已下載但無法檢查，先確認交付內容包含完整結果包，再於 macOS 使用 Xcode 或 xcresulttool 驗證；不要只憑產物名稱推定它可讀。
若產物已不可取得，先核對平台的留存設定與工作流程執行記錄，再按團隊政策調整期限及存取權限；不要把尚未核實的平台預設值寫進維運文件。

GitHub 提供從工作流程執行下載產物的操作說明，下載後仍需由你確認檔案範圍及內容完整性。下載工作流程產物指南適合用來核對介面操作；命令列或自動化下載方式則應配合團隊採用的工作流程確認。

測試工程師常見問題

測試命令非零結束時，結果包一定會寫完嗎？

不一定。測試失敗與結果包是否完整，是兩件要分開驗證的事；上傳步驟只在命令結束後選取檔案。你應分別檢查測試結束時的檔案、上傳步驟的執行狀態，以及下載後能否開啟。節點中斷或工作流程取消也要另行驗收，不能只用一般測試失敗代替。

上傳目錄和上傳多個檔案有什麼差別？

.xcresult 應作為完整結果包交付，因此先確認上傳設定會選到結果包本身及其內容。多個路徑或萬用字元可能改變產物中的目錄層級；若測試人員下載後找不到預期位置，就要對照上傳路徑、共同根目錄和實際產物結構，而非假定下載操作遺失了檔案。

結果包裡的測試日誌、附件要不要開放給所有人？

不宜預設公開。結果包可能包含專案內部的測試細節、環境資訊或附件；由平台負責人依除錯、稽核及發布需求設定存取範圍。產物名稱可使用工作流程執行、提交識別及工作名稱，避免把敏感資料直接寫進名稱，也不要在公開討論區散布完整結果包。

平台負責人：命名、留存與權限要可稽核

命名應讓接手的人不打開內容也能辨識是哪次工作流程、哪個提交及哪個測試工作產生的結果；不同重試也要能區分。提交識別可用團隊慣用的短識別方式，但不要只用可重複的固定名稱，否則重跑可能覆蓋先前證據。

留存期限依專案的除錯週期、發布稽核要求與儲存政策訂定，並在團隊文件中寫明由誰調整、在哪裡確認。存取權限則依產物內容設定：若測試附件涉及內部資料，就不要把下載連結視為公開檔案。GitHub 的產物文件說明產物用於在工作流程中保存與取回資料；具體留存和權限行為請以你的平台設定及官方文件為準，不應引用未核實的預設天數。若你在遠端 Mac 的連線、權限或環境交付上需要協助，可參考VPSMAC 技術支援說明，並將 CI 執行識別與已確認的錯誤階段一併整理，方便釐清問題邊界。

發布負責人：成功與失敗工作都要完成端到端驗收

部署前至少走完兩種驗收情境：先讓測試成功，確認結果包生成、上傳、下載及開啟；再讓測試按預期失敗，確認上傳仍執行，並能從下載結果辨識失敗資訊。驗收紀錄應附上工作流程執行識別、結果包路徑及檢查結果，避免只保存一張顯示工作失敗的截圖。

如果成功工作有產物、失敗工作沒有，優先檢查上傳步驟是否被前一步的失敗狀態略過；如果兩者都沒有，先回查測試是否執行及路徑是否匹配；如果可以下載但不能開啟，就檢查選取範圍與交付完整性。這種按證據區分問題來源的方式，能避免把生成、上傳、下載和讀取故障混成同一類問題。

若你目前靠 Linux CI 承擔 Xcode 測試，限制是無法直接執行 macOS 工具鏈；若共用本地 Mac，睡眠、重啟或有人佔用可能中斷排程；若購置專用硬體，則要承擔前期支出及持續維護。對需要按階段補足測試能力、又希望在真實 macOS 環境驗收結果的團隊，租用 VPSMAC 遠端 Mac 可作為較靈活的執行選項；你可先查看 VPSMAC 方案與租用資訊，再依建置頻率與維護責任決定。若工作長期高負載或必須直接連接特定實體設備，自購 Mac 可能更合適。