如何在沒有實體硬體的情況下測試 POS 系統

沒有硬體時你能測什麼

比大家以為的多得多。你可以驗證商品查詢、加入購物車的行為、數量變更、折扣規則、顧客歸屬、焦點回復、錯誤處理，以及許多收銀員會碰到的邊界情況，全程不用碰真實掃描器。

關鍵是把工作流程邏輯和硬體驗證分開。如果問題在於 POS 如何回應輸入、狀態變化或查詢結果，以軟體為基礎的測試通常就足以找到它。如果問題在於掃描器、印表機、終端機或 USB 限制，那才是硬體輪次變得必要的地方。

從掃描器工作流程開始

在多數 POS 系統裡，掃描器是大家最先擔心的相依項目。幸好它也是最容易模擬到位的項目之一，因為許多掃描器的行為就像鍵盤。

因此，條碼掃描器模擬器工具 是 POS 測試的有力起點。你可以驅動收銀台使用的同一個搜尋欄或商品輸入，並驗證當條碼值快速抵達時，無論後面有沒有 ENTER，畫面如何反應。

建立一套小而真實的測試矩陣

想得到淺層涵蓋，最容易的辦法是只測一個順利路徑上的商品。更好的做法是做一小套商品類型矩陣，反映 POS 在真實零售工作流程裡的表現。

我通常至少要有：

• 一個正常有庫存的商品
• 一個未知條碼
• 一個含前導零的商品
• 一個受限或有年齡門檻的商品
• 一個有促銷或價格規則的商品

這很重要，因為 POS 錯誤常常藏在業務規則裡，而不是掃描本身。測試集太簡單時，畫面看起來穩定，真實工作流程卻不是。

模擬操作人員行為，而不只是系統行為

一次 POS 作業不是整齊的單元測試。收銀員動作很快，會點錯欄位、重複掃描、過早關掉提示，並且在時間壓力下操作。如果你的無硬體案例沒有把這種現實建模進去，涵蓋率會看起來比實際更好。

試試這些情境：

1. 很快地連續掃描同一件商品兩次
2. 在強制回應視窗開啟時掃描
3. 移除一件商品再重新掃描
4. 觸發店長授權後再掃描
5. 故意丟掉焦點，並確認介面能夠回復

這些是真實的失敗，也正是條碼模擬器能幫你不疲勞地反覆重現的那一類情況。

有意識地分層使用環境

做 POS 測試時，我喜歡三層：

• 本機開發，帶種子資料與條碼模擬器
• 預發環境，帶真實價格、稅金與庫存邏輯
• 硬體驗證，發行前在真實終端機上進行

這樣，昂貴的硬體時間會集中在真正需要裝置的那一小撮錯誤上。開發人員可以在本機清掉大部分工作流程缺陷，QA 可以在預發環境驗證更廣的情境，硬體專家則專注裝置層面的問題。

知道哪些事仍然需要實體硬體

無硬體測試很強，但有界線。下面這些仍然需要真實裝置：

• 掃描器配對與驅動程式行為
• 收據印表機輸出與走紙
• 付款終端機通訊
• USB 集線器與自助機限制
• 門市特有的網路與終端機限制

對這些界線保持誠實，會讓其餘流程更扎實。目標不是假裝硬體不重要。目標是不再把硬體時間浪費在本來可以更早抓住的問題上。

團隊通常錯在哪裡

最常見的錯誤是等整條硬體通道就緒，才去測試任何有意義的東西。這聽起來謹慎，但通常是把錯誤延後了，而不是預防了。如果商品查詢失敗是因為折扣提示之後搜尋欄失去焦點，硬體不會神奇地讓這個錯誤更好理解。

另一個常見問題是只測一條平靜的順利路徑。真實結帳很吵。操作人員掃得快、重複商品、從提示裡退出來，並在工作流程之間切換。你的無硬體 POS 測試應當反映這種現實，否則就會漏掉店員最先注意到的那些問題。

一個實際例子

想像一個結帳畫面：掃描商品應當加入該商品、更新購物車，並立刻把焦點交還商品搜尋輸入。其中大部分都可以在沒有硬體時驗證：

• 向搜尋欄模擬條碼掃描器輸入
• 驗證商品被正確加入
• 驗證促銷與價格規則生效
• 確認下一次掃描落在同一個欄位

只有這些通過之後，你才需要實體掃描器來取得最終信心。這個順序節省時間，也通常讓硬體時段更有用。

快速的現實核對

你可以在沒有實體硬體的情況下測試 POS 系統，而且比許多團隊以為的有效得多。先做接近真實的掃描器模擬，配上穩定的測試資料，優先看工作流程行為。然後再用實體硬體處理只有裝置才能暴露的那一小部分問題。這種做法比一開始就依賴硬體更快、更省，通常也更有紀律。