從 OCA 的 OCTT 走到自動化測試

兩件不同的工作

開放充電聯盟（OCA）的 OCPP 一致性測試工具服務的是一個明確目的：在產品上市之前，證明它符合 OCPP 規範。它詳盡、官方，而且產出的一致性結論對採購團隊是有分量的。

它不是為開發流程設計的。這不是批評——只是不同的工作需要不同的工具。

把這個差別想清楚，能省掉很多挫敗感。

OCTT 擅長什麼

OCTT 會對你的實作跑一套全面、標準化的測試集，以結構化的方式涵蓋規範中必需與選用的功能。通過之後，你手上有一份成文的一致性證據，在大型客戶和電力公司那裡是有說服力的。

這個流程本身也是個有用的約束。必須正式認證，就意味著你不能帶著「差不多能用」的協定一致性出貨。門檻是明確劃好的。

OCTT 為什麼套不進開發

認證流程是圍繞里程碑模型設計的：你做出東西，測這個東西，認證這個東西。開發是迭代的。你在每一次有意義的改動之後都要測，而不是最後測一次。

OCTT 還需要協調——約測試時段、取得工具的使用權、提交結果。對一個認證里程碑來說，這些開銷是可以接受的；作為每天的開發迴路，它無法承受。

中間的那段空檔

開發者真正需要的，是這樣一個東西：

1. 立刻就能跑，不需要排期
2. 針對具體的訊息往返給出快速回饋
3. 能在 CI 環境裡工作
4. 細節足夠多，能迅速定位失敗原因

這就是 TestPilot 要補的那段空檔。它不取代 OCTT——如果你需要 OCA 認證，那條路還是得走。但在你準備好做正式認證之前，那 95% 的測試它都能接下來。

一條典型的流程

實務上，流程大致是這樣：

1. 開發階段：在本機環境裡跑 TestPilot。每實作一個訊息流就測一個。放進 CI 裡防迴歸。

1. 認證前：拿完整的實作跑一遍 TestPilot，作為起飛前檢查。把失敗的都修掉。

1. 認證：提交給 OCA 的 OCTT。到這一步，核心流程能過，你應該早就知道了。

1. 認證之後：繼續用 TestPilot 開發下一個版本。認證是一張快照，開發是持續的。

關於 OCTT 對接的幾點實務

如果你在準備 OCTT 認證，有幾件事值得先知道：

測試集是按功能檔（Core、Remote Trigger、Smart Charging 等）組織的。在啟動流程之前，先弄清楚你要聲明哪幾個功能檔的一致性。

OCTT 會測一些你平常跑不到的邊界情況——錯誤回應、意料之外的狀態轉移、缺失的選用欄位。開發階段就盡量把這些情境都對著實作跑一遍。

留好你的測試日誌。正式認證裡出問題時，手上有開發測試留下的詳細日誌，根因分析會快得多。