今天我們談談怎麼用Qaptly測試軟硬體整合的場景
在多數軟體自動化測試工具裡，「測試」發生的地方很明確：
在畫面裡、在 API 裡、在系統內部。
只要這些地方都回傳正確結果，
測試就被視為通過。
但當系統開始和真實世界互動，事情就沒那麼單純了。
一個很小、卻很常見的 IoT 問題
假設你有一個 IoT 裝置，可以透過 App 或 Web 介面控制。
畫面上有一個按鈕：「開燈」
你點下去之後：
UI 顯示「已開啟」
API 回傳 success
系統狀態顯示 ON
問題來了—— 燈，真的亮了嗎？
這個問題，用人測很簡單。
但對測試工具來說，卻很尷尬。
傳統自動化測試，卡在這裡
對傳統工具來說，這個測試流程通常只能到這一步：
點擊按鈕
驗證畫面或 API 回傳
它能驗證的是：
「系統說自己做了什麼」
但它沒辦法回答：
「現實世界真的發生了什麼」
如果燈沒亮，但系統以為亮了，
測試依然會顯示成功。
Qaptly 一開始，其實已經能控制很多平台
在談 UPP 之前，有一個背景必須先說清楚。
Qaptly 從一開始，就已經支援多種 Pilot：
Browser
Android
iOS
macOS
Windows
也就是說，在「操作系統與畫面」這一層，Qaptly 本來就能完整自動化。
但問題不在這一層。
問題在於：這種分類，碰不到真實世界
即使有再完整的平台 Pilot，還是會遇到同一個問題：
真實世界的狀態，不屬於任何一個作業系統。
IoT 裝置是否真的執行指令、感測器是否真的回報數值、硬體是否真的進入某個狀態——
這些事情，不能硬塞成：
Android 的功能
Browser 的行為
或某個 UI 的結果
如果測試只能依附在「平台 Pilot」之下，
那它天生就只能驗證一半。
這就是 UPP 出現的原因
UPP（Unified Pilot Protocol）的出發點其實很單純。
我們沒有試著把所有硬體邏輯塞進 Qaptly，而是承認一件事：
有些狀態，只能由「身處那個世界的角色」來確認。
本來UPP只是給專案類型客戶使用，畢竟這種場景會需要高度客製化，
透過 UPP，你可以建立一個代表 IoT 裝置或感測器的 Pilot：
它知道裝置現在的真實狀態
它能回報「燈有沒有真的亮」
它不需要是某個作業系統的一部分
Qaptly 不需要知道硬體怎麼實作，它只需要讓真正的控制跟了解情況的Pilot去執行就好。
自然語言，在這裡變得很重要
如果只是多一個硬體驗證機制，那 UPP 其實只會變成另一種工程整合。
但 Qaptly 的核心，從來不只是「多接一個東西」。
我們讓測試流程，先用自然語言存在。
例如：
「當我在 App 中點擊『開燈』後，裝置應在 2 秒內亮起，並且感測器必須回報亮燈狀態。」
這不是規格文件，
也不是腳本，
而是一個人本來就會這樣描述的流程。
在這個流程裡：
Qaptly 理解自然語言描述的條件
Platform Pilot 負責操作 App 或 Web
IoT Pilot 透過 UPP 回報實際硬體狀態
測試通不通過，
不再只看畫面或 API，
而是看「描述的事情，有沒有真的發生」。
為什麼我們選擇把 UPP 開放出來
因為這種需求，不會只出現在某一個產品裡。
只要系統開始碰到真實世界，就一定會遇到：
平台控制做得到
但狀態驗證做不到
UPP 不是為了展示能力，而是為了讓測試模型本身可以延伸。
Qaptly 負責理解人怎麼描述世界，Pilot 負責告訴我們世界是不是照那樣運作。
我們選擇把 UPP 開放出來，而不是把它藏在系統裡。