AppIntentsTesting 適合放在 UI Testing Target，以真實 App 進程驗證 Intent、Entity、Query 與系統整合，而不是以 Mock 取代完整鏈路。本文按測試場景整理最小基線、資料隔離、Spotlight 驗證、簽名與遠端 Mac 持續執行的部署方法，並說明 Beta 階段何時應保留人工測試。
AppIntentsTesting 適合放在 UI Testing Target，以真實 App 進程驗證 Intent、Entity、Query 與系統整合，而不是以 Mock 取代完整鏈路。本文按測試場景整理最小基線、資料隔離、Spotlight 驗證、簽名與遠端 Mac 持續執行的部署方法，並說明 Beta 階段何時應保留人工測試。
症狀 → 最快解法
Apple 在 2026 年 8 月 24 日的公開發布記錄中列出 Xcode 27 beta 6 與 iOS 27 beta 7；若 App Intents 只靠 Shortcuts 手動確認，Entity Query 的回歸很可能要到使用者回報才會曝光。Apple 發布記錄
最快解法：把關鍵 App Intents 放進 UI Testing Target，以真實 App 進程驗證 Intent、Entity、Query 和系統整合；需要每次提交後重跑時，再部署到工具鏈固定、可無人值守的遠端 Mac。Beta 階段先守住關鍵鏈路，不要立即取消 Siri、Shortcuts 與 Spotlight 的人工驗收。
已經接入 App Intents，卻擔心 Siri、Shortcuts 或 Spotlight 功能在改版後靜默失效的獨立開發者，適合從本文開始建立最小回歸集。
需要在每次提交後檢查 Intent 與 Entity Query 的小型團隊，可以把測試任務與正式發版分開。沒有常駐 Apple silicon Mac、但要持續執行 iOS 整合測試的 Windows 或 Linux 開發者，也能據此評估遠端 Mac 是否符合條件。
截至 2026-09-01，Apple 已公開 App Intents Testing Beta 文件與 WWDC26 範例；Xcode 27 與 iOS 27 仍屬 Beta，框架 API、工具鏈要求和測試結果不能視為正式版長期承諾。App Intents Testing 官方文件 WWDC26 AppIntentsTesting 示範
AppIntentsTesting 的價值，不是把普通單元測試換一個名稱，而是由獨立測試進程觸發真實 App Intents 鏈路。測試要能碰到被測 App 的 Intent 實作、Entity 查詢、參數解析，以及系統整合邏輯，這也是它不應被簡化成 Mock 回傳值的原因。Apple 測試 App Intents 程式碼指南
配置時先核對三項關係：
com.example.sampleapp，不要把真實專案 ID 寫進公開腳本。第一個基線應選擇沒有外部帳號、遠端 API 或雲端資料庫依賴的 Intent，例如以固定輸入回傳確定結果。這樣失敗時可以分成三類：測試沒有發現入口、參數轉換失敗、Intent 本身執行失敗；若一開始就混入網路服務，錯誤會失去邊界。
App Intents 的 Entity 不是只要能在 App 內顯示就算完成。測試資料應固定建立，並在測試結束後清理，避免使用開發者帳號裡剛好存在的內容。這一點直接影響結果是否可重現，也能避免上一輪測試留下的同名資料造成錯誤匹配。
建議將 Entity Query 拆成三個檢查面：
接著建立兩個互相銜接的 Intent：第一個產生或選取測試 Entity，第二個接收它並完成後續操作。測試重點不是只看兩個 Intent 各自成功，而是確認前一個結果能以正確型別傳給下一個；這裡最容易捕捉到參數轉換、識別碼映射與可選值處理的回歸。
| 驗證場景 | 應固定的輸入 | 失敗時優先檢查 | 通過標準 |
|---|---|---|---|
| 字串查詢 | 脫敏的固定名稱 | Query 過濾與排序 | 返回預期 Entity，無相似誤配 |
| 識別碼解析 | 測試建立的穩定 ID | ID 儲存與資料清理 | 重啟後仍解析到同一筆資料 |
| 連續 Intent | 前一個 Intent 的結果 | 型別、參數與 Optional | 下一個 Intent 收到正確 Entity |
| 返回欄位 | 固定標題與顯示值 | Entity 屬性映射 | Shortcuts 選項與 App 內容一致 |
提醒： 測試資料、帳號、檔案路徑與專案識別都應使用佔位符。若測試必須登入，請將登入會話視為環境依賴並在節點重啟後明確驗證，不要把個人 Apple ID 或密鑰放入 Repository。
Entity 能被 App 內查詢，不代表 Spotlight 一定已建立索引。測試已知 Entity 時，應把結果分成三種故障：索引尚未生成、索引資料已過期、Query 或 Entity 邏輯本身錯誤。Core Spotlight 與 App Entities 的接入方式應以 Apple 的官方文件為準，而不是只依賴模擬器畫面上的一次成功結果。讓 App Entities 出現在 Spotlight Core Spotlight 官方說明
頁面驗證可以使用測試專用 Intent 導航到確定頁面，再檢查 View Annotation 是否暴露正確 Entity。這種方式適合確認「目前頁面所代表的資料」和系統可見 Entity 是否一致，但不應把它誤認為完整的 Spotlight 搜尋體驗。
實際驗收時，保留一條已知 Entity 的索引查詢，再加入索引重建或資料更新後的檢查。測試應記錄索引建立前後的狀態，而不是用未定義的等待時間判斷成功；本文不提供未經本站實測的耗時或穩定性承諾。
可以在 Debug 建置中加入不可發現的測試專用 Intent，用來初始化固定資料、導向指定頁面，以及執行測試後清理。它不應出現在產品的公開 Intent 清單，也不應在 Release 產物中保留可呼叫入口。
每個測試都要自包含，原因有三個：
因此，初始化、執行、驗證、清理應是同一測試的完整邊界。測試賬號、樣例資料、路徑和 Bundle ID 以環境變數或安全儲存提供，測試報告則只保留必要的脫敏內容。
遠端 Mac 不是把一台開著螢幕的 Mac 放到機房就完成部署。持續整合至少要將 AppIntentsTesting 與普通單元測試、XCUITest、自動化發版任務分開路由，因為它們的失敗含義不同：
| 任務類型 | 主要回答的問題 | 失敗通常指向 | 是否可取代人工驗證 |
|---|---|---|---|
| 普通單元測試 | 純邏輯是否正確 | Swift 邏輯、模型或轉換 | 否 |
| XCUITest | App 介面流程是否可操作 | UI 狀態、頁面與互動 | 否 |
| AppIntentsTesting | Intent、Entity 與系統鏈路是否接通 | Target、簽名、Query 或執行鏈路 | 否 |
| Siri / Shortcuts 人工測試 | 使用者實際操作是否自然 | 語音、編排與權限體驗 | 不能被自動化完全取代 |
| Spotlight 驗證 | Entity 是否能被系統索引找到 | 索引狀態、資料新鮮度或查詢 | 需保留最終體驗測試 |
落地時可依序執行以下步驟：
若節點要長時間執行，應先完成 遠端 Mac 方案與可用環境選擇 的硬體與連線評估，再決定是否把測試工作獨立路由。這比把正式上架和 Beta 測試塞進同一個未隔離的工作目錄更容易回退。
我們建議用以下五項結果作為最小驗收集，而不是以「整套測試都綠燈」作為模糊標準：
評分時，我們會把「功能覆蓋」和「環境可恢復」分開看：
| 評估項目 | 本地試用 | 每次提交檢查 | 常駐遠端測試節點 |
|---|---|---|---|
| 基礎 Intent 與 Entity | 2/5 | 4/5 | 5/5 |
| 連續 Intent 與資料清理 | 1/5 | 4/5 | 5/5 |
| Spotlight 與頁面注解 | 1/5 | 3/5 | 5/5 |
| 無人值守與重啟恢復 | 1/5 | 3/5 | 5/5 |
| 適合的專案狀態 | 初次接入 | 已有 CI | 依賴長期回歸 |
這是部署成熟度評分，不是 Apple 對框架的官方評分。若 App 尚未深度採用 App Intents，先在本機完成基線即可；若每次提交都可能改動 Entity 或 Query，應加入 CI；若團隊需要持續驗證、又沒有可長時間保留狀態的 Apple silicon Mac，才值得部署專用遠端 Mac。
Apple 目前公開的是 Beta 文件與示例，因此正式採用前要保留回退路徑，並在 Xcode 27 RC 或正式版發布後重新核對 API、系統要求、簽名流程和測試結果。不要因 Beta 階段的一次通過，就移除 Siri、Shortcuts 和 Spotlight 的人工驗證。
因為測試目標是透過獨立進程接觸實際 App Intents 和系統整合，而非只測試一個純函式。UI Testing Target 能承載被測 App 邊界、Bundle Identifier 與簽名關係；普通單元測試仍然重要，但只能負責可隔離的查詢與轉換邏輯，不能單獨證明整條鏈路可用。
可以，條件是遠端 Mac 能固定 Xcode、SDK 和模擬器執行環境，並在重啟後恢復測試所需狀態。CI 任務應保存 xcresult、主控台記錄與環境資訊，同時把 AppIntentsTesting 與單元測試、XCUITest、正式簽名發版分開；否則一次簽名失敗可能被誤判為 Intent 回歸。
先以可重建、可清理的固定 Entity 驗證字串查詢、識別碼解析和返回欄位，再以兩個連續 Intent 檢查結果能否傳遞。測試資料不能取自個人帳號現有內容，否則同名資料、殘留狀態和並行任務都可能製造只有 CI 才出現的錯誤。
將被測 App、測試 Target 和相關產品的 Team 設定納入啟動檢查，使用可受控的團隊簽名身份，不要依賴遠端桌面上的個人登入會話。節點重啟後要重新確認憑證、Provisioning Profile、Bundle ID 和測試入口；簽名身份的同步方式應遵循 Apple 官方文件，而不是把私密檔案提交到 Repository。
不能。它適合攔截 Intent 執行、Entity Query、參數傳遞及部分系統整合回歸，但不能完整模擬自然語音、Shortcuts 編排和使用者在 Spotlight 中尋找功能的體驗。Beta 階段應採用「自動化守住回歸、人工確認最終體驗」的雙層驗收方式。
若目前方案是只在開發者本機手動開啟 Shortcuts、依賴個人帳號資料、把正式發版和 Beta 測試共用一個狀態，缺點是回歸不可追蹤、失敗難以重現，而且 Mac 關機或登入狀態改變後便無法持續執行。若改用臨時雲端環境，還可能遇到工具鏈版本漂移、模擬器狀態不固定，以及無法保留完整 xcresult 的問題。
完成最小測試鏈路後，建議先用本文的驗收項目套入自己的 App Intents 測試集，連續執行並做一次重啟復測。若手邊沒有能長時間保留 Xcode 27 測試環境的 Apple silicon Mac，再評估向 VNCMac 了解遠端 Mac 租用方式，把它作為專用測試節點；但若需求是長期滿載編譯、需要實體 USB 裝置，或必須完全控制硬體，購買並自行維護 Mac 仍可能更合適。