在雲端 Mac 上驗證 iOS 觸覺回饋：先測事件，再上實機

雲端 Mac 上的 iOS 建置通過了，模擬器裡的確認按鈕也能點擊，團隊仍不能因此宣告觸覺回饋驗收完成。模擬器可以檢查程式碼是否準備了正確的事件，卻無法讓測試者感受到那一下震動。應將兩者列為不同的檢查項目：前者交給自動化，後者留給支援觸覺回饋的實機。

先定義回饋要傳達什麼

以「儲存完成」為例，回饋應在儲存成功之後觸發一次，而不是在使用者剛按下按鈕時觸發。儲存失敗時，畫面需要顯示錯誤，但不應播放成功回饋。撰寫測試前，先將觸發條件、事件類型與觸發次數列為契約。

不要用觸覺回饋取代文字或畫面狀態。使用者可能關閉系統觸覺回饋，也可能使用不支援所選觸覺功能的裝置。儲存結果始終應有可見的確認；觸覺回饋只是額外提供一項感知線索。

自動化測試證明「要求了哪種回饋」，實機驗收回答「回饋是否合適」。兩者無法互相取代。

將事件規格與播放程式碼分開

如果事件參數散落在按鈕的回呼函式中，測試就只能透過點擊介面，間接推測發生了什麼事。先建立產生事件的函式，再讓播放層使用它。如此一來，測試便能直接檢查事件數量、類型與相對時間，不必依賴硬體是否震動。

在雲端 Mac 上執行事件檢查

以下範例用一個短暫事件表示「儲存完成」。參數只是範例起點，並非適用於所有產品的建議強度；最終數值仍須透過實機體驗確認。

import CoreHaptics

func confirmationEvents() -> [CHHapticEvent] {
    let event = CHHapticEvent(
        eventType: .hapticTransient,
        parameters: [
            CHHapticEventParameter(parameterID: .hapticIntensity, value: 0.65),
            CHHapticEventParameter(parameterID: .hapticSharpness, value: 0.35)
        ],
        relativeTime: 0
    )
    return [event]
}

在專案的測試目標中，可以先檢查不依賴播放裝置的契約。測試程式碼與應用程式碼應引用同一個 confirmationEvents()，不要在測試中另建一份事件，否則兩份參數可能各自產生偏差。

import XCTest
import CoreHaptics
@testable import YourApp

final class ConfirmationHapticsTests: XCTestCase {
    func testConfirmationIsOneImmediateEvent() {
        let events = confirmationEvents()
        XCTAssertEqual(events.count, 1)
        XCTAssertEqual(events[0].relativeTime, 0)
        XCTAssertEqual(events[0].eventType, .hapticTransient)
    }
}

將 YourApp 換成實際模組名稱後，在雲端 Mac 上透過專案現有的共用測試入口執行該測試目標。這裡檢查的是事件定義，不要求模擬器產生真實震動。如果業務需求日後決定將一次回饋改成兩段節奏，應先修改契約與測試，再討論實機上的感受。

播放失敗不能改變業務結果

播放層應先檢查 CHHapticEngine.capabilitiesForHardware().supportsHaptics，再建立引擎與播放器。引擎啟動、模式建立或播放都可能失敗；發生錯誤時，只應將其記錄為應用程式內部可診斷的回饋失敗，不應把已經成功的儲存操作改判為失敗。引擎中斷後，也不要假設原本的播放器始終可用；應依照應用程式生命週期重新準備播放狀態。

測試呼叫時機，不測模擬器的觸感

為播放動作加上一層可替換的介面。在儲存流程測試中注入會記錄呼叫次數的實作：成功後斷言呼叫一次，失敗後斷言零次；若業務邏輯攔截了重複點擊，也不應額外播放。另針對不具備觸覺回饋能力的分支進行測試，確認畫面結果沒有變化。這些檢查比「模擬器有沒有震動」更穩定，也更貼近程式碼真正能保證的行為。

將體驗驗收留給實機

實機檢查至少應涵蓋儲存成功、失敗、快速連續操作，以及從背景返回後的第一次操作。觀察觸覺回饋與完成狀態是否同時出現；連續點擊時，回饋是否密集到難以分辨；系統音訊中斷或應用程式切換到背景後，下一次回饋是否仍能正常發出請求。每次調整參數只改一項，並記錄測試裝置、系統版本與觀察結果，避免將主觀感受的差異誤認為程式碼回歸。

雲端 Mac 可以完成編譯、模擬器測試與事件契約檢查。實際觸感仍須由團隊在支援觸覺回饋的裝置上確認；遠端桌面上看到的按鈕動畫，不是觸覺回饋驗收的證據。

提交前核對驗證邊界

合併前確認四件事：事件產生函式由正式程式碼與測試共同使用；儲存失敗不會觸發成功回饋；不支援觸覺回饋或播放異常時，畫面仍有明確的可見結果；實機紀錄包含觸發時機與連續操作的觀察。如果某項實機體驗意見促使參數調整，也要同步更新事件測試中的預期值，並重新執行自動化檢查。

如此分工後，雲端 Mac 上的測試負責守住可重複驗證的事實，實機檢查則負責把關模擬器無法回答的體驗問題。

常見問題