fastlane scan 能呼叫 iOS 專案的測試流程，但測試仍須在具備相應 Apple 工具鏈的 Mac 環境執行。本文按遠端節點準備、首次設定、試跑、結果留存與 CI 驗收整理操作步驟，並說明模擬器測試和真機驗證的界線。
fastlane scan 能呼叫 iOS 專案的測試流程，但測試仍須在具備相應 Apple 工具鏈的 Mac 環境執行。本文按遠端節點準備、首次設定、試跑、結果留存與 CI 驗收整理操作步驟，並說明模擬器測試和真機驗證的界線。
症狀：遠端 Mac 上的測試命令已啟動，卻不確定測試是否真的執行；最快解法：先核對 Xcode、scheme 與遠端可用的模擬器，再用最小測試確認結果產物。
fastlane scan 可以呼叫 iOS 專案的測試流程，但不能取代 Mac 執行環境，也不能把模擬器通過視為真機驗收完成；適用條件是遠端 Mac 已備妥專案所需的 Apple 工具鏈。
這篇適合負責 iOS 自動化測試、需要確認遠端執行結果是否可重現的開發者；也適合維護 Mac 構建節點、要讓失敗日誌與測試結果可供複核的 CI 工程師。
如果你是沒有長期 Mac 節點的獨立開發者或小團隊，文中也會提供試跑後判斷是否接入正式流水線的依據。
fastlane scan 的工作是調用測試流程，實際建置與測試仍依賴遠端 Mac 上可用的 Xcode 環境。fastlane 的 iOS 測試說明將 scan 與測試執行流程連結；Apple 的 Xcode 命令列工具參考則說明命令列工具與 Xcode 工具鏈的關係。
因此，不要只比較本機和遠端的 lane 命令文字是否相同。應先留下遠端節點的基線紀錄，至少包含：
.xcodeproj 還是 .xcworkspace，以及該路徑在遠端工作目錄中是否存在。若使用專案級 Ruby 或 fastlane 管理方式，沿用專案已有的設定與鎖定檔，不要為了讓遠端「先跑起來」而臨時改用不同依賴組合。版本是否相容，應以專案配置、fastlane 文件與目標 Mac 的實際執行結果判斷，不以未驗證的通用版本建議代替。
先在 Fastfile 建立可重複呼叫的 lane，將專案路徑、scheme、測試計畫及目的地寫清楚。以下範例中的值均為佔位符，請換成專案設定和遠端實際可用的模擬器：
lane :test_remote do
scan(
project: "<專案路徑>.xcodeproj",
scheme: "<測試 Scheme>",
testplan: "<測試計畫>",
devices: ["<遠端可用的 Simulator 名稱>"],
output_directory: "<測試輸出目錄>"
)
end
若專案使用 workspace，應按專案實際結構選擇對應輸入，不要同時填入不適用的專案資訊。scan 與 run_tests 的參數和行為可能隨 fastlane 文件及專案環境而異；調整前應核對官方 run_tests 參數文件與專案本身的設定。
| 執行方式 | 適合用途 | 主要優點 | 需要留意 |
|---|---|---|---|
scan 寫入 Fastfile lane |
團隊重複執行、接入 CI | 專案可保存共用入口與設定，較容易檢視變更 | lane 的輸入與輸出路徑必須對應遠端工作目錄 |
fastlane run_tests |
手動確認 action 或短暫排查 | 可直接呼叫測試 action，適合檢查參數與執行回應 | 若參數分散在終端命令，需另行確保 CI 使用一致設定 |
| 直接呼叫 Xcode 命令列測試 | 核對 fastlane 以外的執行層 | 可協助辨別問題是否來自測試工具入口 | 命令與產物設定應依 Xcode 文件及專案需求管理 |
這不是哪種方式「一定比較快」的性能排名，而是維護方式的取捨：若團隊要重複執行並留存設定，lane 通常更容易審查；若是在定位 action 參數，直接執行 fastlane run_tests 可作為對照。fastlane 的 CI 整合文件也將 fastlane 命令放在 CI 工作流程中使用，但實際環境變數、工作目錄及結果保存仍須由團隊設定。
若測試依賴不同的測試集合或執行配置，請確認 scheme 及測試計畫選擇正確。Apple 的測試計畫文件說明測試計畫如何組織測試；這有助於避免把「跑了某個 scheme」誤認為「跑了所有預期測試」。
首次試跑不要直接把完整 CI 工作流搬到遠端。先挑選能驗證建置與測試入口的最小任務，再逐步加入專案實際需要的測試範圍。每次執行都記錄提交版本、遠端使用的 Xcode、lane 參數、終端輸出和 Xcode 測試結果。
| 試跑階段 | 要核對的事情 | 留下的證據 | 未通過時的下一步 |
|---|---|---|---|
| 專案載入 | 工作區、scheme、測試目標是否可讀取 | 命令輸出與專案設定 | 先修正路徑或 scheme，不急著改 fastlane |
| 建置與模擬器啟動 | 目標裝置是否存在，測試是否進入執行 | 建置日誌與模擬器目的地 | 對照遠端裝置清單及所選 Xcode |
| 最小測試 | 測試案例是否真的開始並產生結果 | 測試日誌與 Xcode 結果 | 區分依賴、建置、啟動與斷言失敗 |
| 完整測試套件 | 測試範圍與團隊預期是否一致 | 完整測試結果與失敗紀錄 | 檢查測試計畫及輸出是否涵蓋預期內容 |
失敗時先按執行階段分類，而不是把所有錯誤都歸因於 fastlane。依賴解析失敗，先看專案鎖定檔與工作目錄；建置失敗，對照 Xcode 輸出與專案設定；Simulator 啟動失敗，確認目標名稱是否真的存在於遠端；進入測試後才出現的錯誤，則需檢視測試斷言與測試資料。
若終端只顯示命令已啟動，不能據此判定測試完成。Apple 的測試執行與結果解讀文件可用來理解 Xcode 測試結果；應確認結果中有實際執行的測試資訊，再將其與 lane 的結束狀態一併核對。
CI 的驗收不應只看成功時是否產生測試報告。請明確設定測試輸出目錄，並檢查流水線在測試失敗時是否仍會收集日誌與結果檔。若使用 Xcode 測試結果包，應依團隊採用的 Xcode 與 fastlane 設定確認產物位置、檔名及收集方式；Apple 文件指出測試執行會產生可供檢視的測試結果，具體保存及上傳仍由流水線負責。
落地時可按以下次序操作：
這些步驟不假設任何特定節點已自動替團隊上傳或保存結果。若流水線沒有設定失敗時的產物收集，測試工具產生結果也不代表團隊日後一定能取回。
遠端 Mac 測試前要檢查什麼？
先檢查專案路徑、scheme、測試目標、選用的 Xcode、專案級 Ruby 與 fastlane 管理方式，再確認遠端實際可用的 Simulator 名稱。若這些資訊尚未固定，先保存基線並跑最小測試，避免把環境差異誤判成測試程式問題。
fastlane scan 找不到 iOS Simulator 時先核對什麼？
先檢查遠端目前選用的 Xcode 是否提供所需 Simulator runtime，再核對遠端裝置清單與 lane 內的目標名稱。不要直接複製本機的目的地設定；遠端實際清單才是選擇目標的依據。
CI 測試失敗後怎麼保留結果？
檢查流水線是否在失敗路徑仍執行日誌與測試結果收集，並從 CI 產物區實際下載一次。結果包可供檢視測試狀態，但其上傳、存取及保留方式須按團隊流水線配置。
模擬器通過是否等同真機驗收？
不等同。模擬器測試確認的是指定模擬環境中的執行情況；若專案需要驗證實體裝置上的行為，仍須另安排真機測試。Apple 對模擬器與實體裝置執行 App 的說明也將兩種執行目標區分開來。
完成試跑後，用同一提交確認遠端 Mac 是否能重現本機預期的測試範圍、回報失敗原因並提供可取回的結果。若其中任何一項無法複核，先補齊工具鏈紀錄或產物收集，再接入正式 CI；若專案需要實體裝置行為覆蓋，就把真機測試列為獨立驗收，而不是用 Simulator 結果代替。
| 驗收結果 | 建議安排 | 判斷依據 |
|---|---|---|
| lane 可重複執行，結果及失敗日誌可取回 | 接入正式 CI | 團隊能對照提交、執行設定與測試產物 |
| 測試可啟動，但目標或結果路徑仍依賴人工確認 | 繼續試跑 | 先穩定遠端設定及失敗時的收集流程 |
| 專案要求驗證真機專屬行為 | 增加實體裝置驗收 | 模擬器通過不能證明真機覆蓋已完成 |
| 專案工具鏈或結果留存需求不適合目前節點 | 調整節點或測試安排 | 先找出差距，再比較其他執行方式 |
對沒有長期可用 Mac 的團隊，遠端 Mac 可以讓測試在具備 macOS 工具鏈的節點執行，但仍需自行管理專案依賴、CI 工作目錄及結果取回。相較於購買並維護自有 Mac，按需租用可避免先承擔硬體購置、閒置期間及設備維護的負擔；相較於只使用 Linux 執行環境，則可直接處理需要 Xcode 的測試工作。不過，若團隊需要長期固定負載、實體連接測試設備，或必須掌握本地硬體，就應先比較自購設備等方案，不必為短期測試需求硬改架構。
建議先用一個真實測試 scheme 在遠端 Mac 完成試跑，確認 Xcode 選擇、Simulator 目標與結果下載都符合團隊流程，再查看 VNCMac 遠端 Mac 租用方案是否適合你的工具鏈與節點使用方式。若目前只是在驗證流程，從遠端 Mac 服務資訊了解可用方式即可；在專案相容性尚未驗證前，不必先承諾長期配置。