[{"data":1,"prerenderedAt":50},["ShallowReactive",2],{"article-zh-upp-natural-language-iot-testing":3},{"article":4,"related":18,"prevArticle":40,"nextArticle":44,"availableLocales":48},{"id":5,"slug":6,"image":7,"date":8,"published":9,"created_at":10,"updated_at":11,"title":12,"excerpt":13,"content":14,"custom_css":15,"keywords":16,"meta_description":17,"og_image":15,"image_width":15,"image_height":15,"category":15},"c7b0ce42-ed7b-41f0-8262-8204890613a1","upp-natural-language-iot-testing","https://cdn.sqa.tw/blog_pictures/upp_cleanup.jpg","2026-02-01T04:30:00+00:00",true,"2026-01-22T04:39:15.889358+00:00","2026-02-03T13:33:23.295+00:00","當軟體測試碰到真實世界","當系統開始與真實世界互動，只驗證畫面與 API 已經不夠。\n本文介紹 Qaptly 為什麼開放 UPP（Unified Pilot Protocol），\n以及如何結合自然語言，讓 IoT 測試真正驗證「事情是否真的發生」。","\u003Cp>今天我們談談怎麼用Qaptly測試軟硬體整合的場景\u003C/p>\u003Cp>在多數軟體自動化測試工具裡，「測試」發生的地方很明確：\u003C/p>\u003Cp>在畫面裡、在 API 裡、在系統內部。\u003C/p>\u003Cp>\u003C/p>\u003Cp>只要這些地方都回傳正確結果，\u003C/p>\u003Cp>測試就被視為通過。\u003C/p>\u003Cp>\u003C/p>\u003Cp>但當系統開始和真實世界互動，事情就沒那麼單純了。\u003C/p>\u003Cp>\u003C/p>\u003Ch2>\u003Cstrong>一個很小、卻很常見的 IoT 問題\u003C/strong>\u003C/h2>\u003Cp>假設你有一個 IoT 裝置，可以透過 App 或 Web 介面控制。\u003C/p>\u003Cp>畫面上有一個按鈕：\u003Cstrong>「開燈」\u003C/strong>\u003C/p>\u003Cp>你點下去之後：\u003C/p>\u003Cul>\u003Cli>\u003Cp>UI 顯示「已開啟」\u003C/p>\u003C/li>\u003Cli>\u003Cp>API 回傳 success\u003C/p>\u003C/li>\u003Cli>\u003Cp>系統狀態顯示 ON\u003C/p>\u003C/li>\u003C/ul>\u003Cp>問題來了——  \u003Cstrong>燈，真的亮了嗎？\u003C/strong>\u003C/p>\u003Cp>這個問題，用人測很簡單。\u003C/p>\u003Cp>但對測試工具來說，卻很尷尬。\u003C/p>\u003Cp>\u003C/p>\u003Ch2>\u003Cstrong>傳統自動化測試，卡在這裡\u003C/strong>\u003C/h2>\u003Cp>對傳統工具來說，這個測試流程通常只能到這一步：\u003C/p>\u003Cul>\u003Cli>\u003Cp>點擊按鈕\u003C/p>\u003C/li>\u003Cli>\u003Cp>驗證畫面或 API 回傳\u003C/p>\u003C/li>\u003C/ul>\u003Cp>它能驗證的是：\u003C/p>\u003Cblockquote>\u003Cp>\u003Cstrong>「系統說自己做了什麼」\u003C/strong>\u003C/p>\u003C/blockquote>\u003Cp>但它沒辦法回答：\u003C/p>\u003Cblockquote>\u003Cp>\u003Cstrong>「現實世界真的發生了什麼」\u003C/strong>\u003C/p>\u003C/blockquote>\u003Cp>如果燈沒亮，但系統以為亮了，\u003C/p>\u003Cp>測試依然會顯示成功。\u003C/p>\u003Cp>\u003C/p>\u003Ch2>\u003Cstrong>Qaptly 一開始，其實已經能控制很多平台\u003C/strong>\u003C/h2>\u003Cp>在談 UPP 之前，有一個背景必須先說清楚。\u003C/p>\u003Cp>Qaptly 從一開始，就已經支援多種 Pilot：\u003C/p>\u003Cul>\u003Cli>\u003Cp>Browser\u003C/p>\u003C/li>\u003Cli>\u003Cp>Android\u003C/p>\u003C/li>\u003Cli>\u003Cp>iOS\u003C/p>\u003C/li>\u003Cli>\u003Cp>macOS\u003C/p>\u003C/li>\u003Cli>\u003Cp>Windows\u003C/p>\u003C/li>\u003C/ul>\u003Cp>也就是說，在「操作系統與畫面」這一層，Qaptly 本來就能完整自動化。\u003C/p>\u003Cp>\u003Cstrong>但問題不在這一層。\u003C/strong>\u003C/p>\u003Cp>\u003C/p>\u003Ch2>\u003Cstrong>問題在於：這種分類，碰不到真實世界\u003C/strong>\u003C/h2>\u003Cp>即使有再完整的平台 Pilot，還是會遇到同一個問題：\u003C/p>\u003Cblockquote>\u003Cp>\u003Cstrong>真實世界的狀態，不屬於任何一個作業系統。\u003C/strong>\u003C/p>\u003C/blockquote>\u003Cp>IoT 裝置是否真的執行指令、感測器是否真的回報數值、硬體是否真的進入某個狀態——\u003C/p>\u003Cp>這些事情，不能硬塞成：\u003C/p>\u003Cul>\u003Cli>\u003Cp>Android 的功能\u003C/p>\u003C/li>\u003Cli>\u003Cp>Browser 的行為\u003C/p>\u003C/li>\u003Cli>\u003Cp>或某個 UI 的結果\u003C/p>\u003C/li>\u003C/ul>\u003Cp>如果測試只能依附在「平台 Pilot」之下，\u003C/p>\u003Cp>那它天生就只能驗證一半。\u003C/p>\u003Cp>\u003C/p>\u003Ch2>\u003Cstrong>這就是 UPP 出現的原因\u003C/strong>\u003C/h2>\u003Cp>UPP（Unified Pilot Protocol）的出發點其實很單純。\u003C/p>\u003Cp>我們沒有試著把所有硬體邏輯塞進 Qaptly，而是承認一件事：\u003C/p>\u003Cblockquote>\u003Cp>\u003Cstrong>有些狀態，只能由「身處那個世界的角色」來確認。\u003C/strong>\u003C/p>\u003C/blockquote>\u003Cp>本來UPP只是給專案類型客戶使用，畢竟這種場景會需要高度客製化，\u003C/p>\u003Cp>透過 UPP，你可以建立一個代表 IoT 裝置或感測器的 Pilot：\u003C/p>\u003Cul>\u003Cli>\u003Cp>它知道裝置現在的真實狀態\u003C/p>\u003C/li>\u003Cli>\u003Cp>它能回報「燈有沒有真的亮」\u003C/p>\u003C/li>\u003Cli>\u003Cp>它不需要是某個作業系統的一部分\u003C/p>\u003C/li>\u003C/ul>\u003Cp>Qaptly 不需要知道硬體怎麼實作，它只需要讓真正的控制跟了解情況的Pilot去執行就好。\u003C/p>\u003Cp>\u003C/p>\u003Ch2>\u003Cstrong>自然語言，在這裡變得很重要\u003C/strong>\u003C/h2>\u003Cp>如果只是多一個硬體驗證機制，那 UPP 其實只會變成另一種工程整合。\u003C/p>\u003Cp>但 Qaptly 的核心，從來不只是「多接一個東西」。\u003C/p>\u003Cp>我們讓測試流程，\u003Cstrong>先用自然語言存在\u003C/strong>。\u003C/p>\u003Cp>例如：\u003C/p>\u003Cblockquote>\u003Cp>「當我在 App 中點擊『開燈』後，裝置應在 2 秒內亮起，並且感測器必須回報亮燈狀態。」\u003C/p>\u003C/blockquote>\u003Cp>這不是規格文件，\u003C/p>\u003Cp>也不是腳本，\u003C/p>\u003Cp>而是一個人本來就會這樣描述的流程。\u003C/p>\u003Cp>在這個流程裡：\u003C/p>\u003Cul>\u003Cli>\u003Cp>Qaptly 理解自然語言描述的條件\u003C/p>\u003C/li>\u003Cli>\u003Cp>Platform Pilot 負責操作 App 或 Web\u003C/p>\u003C/li>\u003Cli>\u003Cp>IoT Pilot 透過 UPP 回報實際硬體狀態\u003C/p>\u003C/li>\u003C/ul>\u003Cp>測試通不通過，\u003C/p>\u003Cp>不再只看畫面或 API，\u003C/p>\u003Cp>而是看「描述的事情，有沒有真的發生」。\u003C/p>\u003Cp>\u003C/p>\u003Ch2>\u003Cstrong>為什麼我們選擇把 UPP 開放出來\u003C/strong>\u003C/h2>\u003Cp>因為這種需求，不會只出現在某一個產品裡。\u003C/p>\u003Cp>只要系統開始碰到真實世界，就一定會遇到：\u003C/p>\u003Cul>\u003Cli>\u003Cp>平台控制做得到\u003C/p>\u003C/li>\u003Cli>\u003Cp>但狀態驗證做不到\u003C/p>\u003C/li>\u003C/ul>\u003Cp>UPP 不是為了展示能力，而是為了讓測試模型本身可以延伸。\u003C/p>\u003Cp>\u003C/p>\u003Cblockquote>\u003Cp>\u003Cstrong>Qaptly 負責理解人怎麼描述世界，Pilot 負責告訴我們世界是不是照那樣運作。\u003C/strong>\u003C/p>\u003C/blockquote>\u003Cp>我們選擇把 UPP 開放出來，而不是把它藏在系統裡。\u003C/p>",null,"UPP,  Qaptly, natural language testing, IoT testing, IoT automation testing, end-to-end IoT testing,軟硬體整合測試","Qaptly 透過自然語言測試與 UPP（Unified Pilot Protocol），\n解決 IoT 與真實世界整合測試中「系統狀態正確，但現實行為未發生」的關鍵落差。",[19,26,33],{"id":20,"slug":21,"title":22,"excerpt":23,"image":24,"date":25,"category":15},"deb70edd-ff7f-4b6e-b230-fa1c83dc0afa","qaptly-v0175-codex-support","Qaptly Desktop 開始支持 Codex","Qaptly Desktop 的 AI Assistant 從 v0.17.5 開始正式開放 Codex 支持。如果你本來就是 ChatGPT 訂閱用戶，現在可以直接讓 AI Assistant 使用 Codex，在日常測試設計與自動化調整上節省成本。","https://cdn.sqa.tw/blog_pictures/qaptly_support_codex.jpg","2026-05-16T13:01:00+00:00",{"id":27,"slug":28,"title":29,"excerpt":30,"image":31,"date":32,"category":15},"eebc38be-6eec-4e68-af7f-e5dd6c611a0f","ai-agent-workflow-critical-things","AI 協作進入 workflow 之後，那些最容易被低估、卻最關鍵的幾件事","過完年後，基本上都在幫幾間新創與大公司內部的開發部門導入 agentic development。這段時間看了不少團隊的做法，也有一些很直接的感受，想趁這個機會整理一下。","https://cdn.sqa.tw/articles/ai-workflow.jpg","2026-03-24T16:10:00+00:00",{"id":34,"slug":35,"title":36,"excerpt":37,"image":38,"date":39,"category":15},"1092dc59-4718-4902-809c-74cfdfc5fffd","from-tool-to-process-challenges","從單點工具到流程閉環的虛實與挑戰","探討2026年AI在軟體開發生命週期中的實踐，從單點工具普及化到流程閉環協作的轉變，以及QA自動化的真實與虛假繁榮。","https://cdn.sqa.tw/blog_pictures/from_tool_to_process.png","2026-03-02T03:06:00+00:00",{"slug":41,"title":42,"date":43},"error-code-as-software-quality-indicator","[SQA 的隱性指標] 結構化的Error Code","2025-12-21T05:16:00+00:00",{"slug":45,"title":46,"date":47},"pikmin-with-fake-gps","原來測試工具也可以拿來玩","2026-02-03T12:44:00+00:00",[49],"zh",1786461720561]