大多數 OCPP 缺陷不是電氣問題。是少了一個欄位、寫錯一個列舉值，或者狀態機接受了一條本該拒絕的 StartTransaction。這些都不需要電流真的流過——也就是說，絕大部分 OCPP 測試可以在一台筆電上完成。
以下是我們推薦給那些還在等硬體、或者有硬體但沒法為每次提交都佔用它的團隊的方案。
先決定你在測哪一邊
這聽起來是廢話，卻是白費力氣的第一大來源。人們嘴裡的「OCPP 測試」其實是兩件互相獨立的事：
測一台充電樁。 你有一份應該會講 OCPP 的固件，你想知道它到底會不會。你需要一個行為像 CSMS、並且會評判充電樁發出內容的東西。
測一套 CSMS。 你有一個後端，你想知道它能不能接住真實充電樁的行為。你需要一個行為像充電樁、並且可以被指使去亂來的東西。
這兩件事需要的工具是相反的，為其中一件做的工具，對另一件幾乎沒用。先把這個決定做了。
測一台充電樁
把充電樁指向一個你自己控制的 CSMS，然後看它說什麼。充電樁並不知道、也不在乎那個端點是生產環境的基礎設施，還是你機器上的一個行程。
把充電樁的中央系統 URL 設成你的端點。幾乎每台充電樁都會在 Web 介面或設定檔裡揭露這一項，通常長這樣：
wss://10.0.1.50:9000/ocpp/CP001然後按順序走一遍訊息流程，因為後面的訊息依賴前面的：
- BootNotification。 檢查
chargePointVendor和chargePointModel是否都在——兩者都是必填，而早期固件裡兩者常常留空。確認充電樁遵守你回的interval，而不是用寫死的值。 - Heartbeat。 確認它按你在 BootNotification 回應裡給的間隔到來，並且當你用 ChangeConfiguration 改動之後，充電樁會跟著調整。
- StatusNotification。 讓接口依次走過 Available、Preparing、Charging、Finishing。留意規範不允許的狀態轉移，也留意那種在指整站時卻回報
connectorId: 0的充電樁。 - StartTransaction / StopTransaction。 用你能回傳的每一種 AuthorizationStatus 去檢驗
idTag的處理——Accepted、Blocked、Expired、Invalid、ConcurrentTx。拒絕一筆交易是被測得最少、壞得最多的那條路徑。 - MeterValues。 確認取樣間隔與設定一致，單位和
measurand的取值也和你預期的一樣。
這個練習裡最有價值的部分，是故意回傳失敗。能正確處理 Accepted、卻在 Blocked 上翻車的固件極其常見，因為幸福路徑是唯一被人走過的那條。
測一套 CSMS
這一邊你需要一台模擬充電樁，而讓模擬器有用的，不是它能把一次充電工作階段跑完。是它能做出真實充電樁在出岔子時會做的那些事。
值得自動化的情境：
- 冷啟動。 一台 CSMS 從未見過的充電樁發來 BootNotification。它是自動納管，還是拒絕？
- 交易中途重連。 在一筆進行中的交易期間斷掉 socket，然後重連。交易必須活下來；電表讀數不能從頭開始。
- 時鐘偏差。 傳送差了幾個小時的時間戳。無條件信任充電樁時鐘的 CSMS，會產出無法對帳的計費記錄。
- 重複的 StartTransaction。 同一個
idTag、同一個接口，發兩次。ConcurrentTx 的存在是有原因的。 - 離線佇列灌入。 斷線期間把訊息快取起來，重連時一次性灌過去。天真的 CSMS 實作就是在這裡掉資料的。
- 畸形封包。 缺必填欄位、型別錯誤、未知列舉值。CSMS 應該回一個 CALLERROR，而不是關掉連線或者把 worker 弄崩。
規模也重要，但比人們想的要晚。一百台模擬充電樁能幫你找出並行缺陷；一萬台找出的多半是你資料庫的上限，那是另一場調查。
放進 CI
把這一切用軟體來做的理由，是軟體可以在每次提交時跑。一個有用的 OCPP CI 任務大致長這樣：
- 啟動被測的 CSMS
- 對著它啟動 N 台模擬充電樁
- 跑一段腳本化的情境——連線、啟動、授權、充電、停止、斷線
- 對結果狀態下斷言：交易已關閉、電表讀數單調、沒有孤立工作階段
- 拆掉環境並輸出報告
這能抓住硬體測試抓得太晚的那些迴歸。一個改動破壞了 StopTransaction 的原因碼，在 CI 裡發現很便宜，在現場試點裡發現很貴。
這套方法涵蓋不到什麼
對侷限保持誠實很重要，因為一套綠燈卻掩蓋了一整類故障的測試集，比沒有測試集更糟。
電氣與安全行為。 接觸器時序、接地故障偵測、溫度降額、緊急停止。這些在 OCPP 上全都看不見，也全都無法模擬。
真實的網路狀況。 充電樁活在電信業者 NAT 後面的行動網路鏈路上。掉包、數秒級延遲、靜默斷線——localhost 上的模擬器不會重現這些，而它們要為相當大一部分生產事故負責。
廠商的怪癖。 每家製造商都會在規範的某個角落上做出不同的解讀。這些只能靠接上那家廠商的真實硬體才能發現，沒有替代品。
正式認證。 通過你自己的測試並不等於 OCPP 認證。那件事仍然要走 OCA 的流程和他們的測試工具。
所以一個合理的方案大致是這個形狀：軟體測試持續、低成本地抓住大多數缺陷；硬體測試確認只有硬體才能確認的東西；等前兩項都乾淨了，再去做認證。
工具
這個領域有不錯的開源工作——docile-charge-point 可腳本化，而且已經存在多年；Python 的 ocpp 函式庫給了你兩邊都能用的構件。
我們為第一件事做了 TestPilot——一個評判充電樁並匯出一致性報告的 CSMS——為第二件事做了 SimPilot，它對著你的後端模擬充電樁，包括上面那些故障模式。如果你想要的是把協定層放進自己的 Go 服務裡，而不是在旁邊放一個工具，那麼 OcppPilot 就是另外兩者所依賴的那個函式庫。