適用對象

整體設計以全鏈路實作整合為主，技術說明為輔，如果技術說明有不夠詳細的部分，請自己問 Perplexity 補全相關知識。所以讀者最好具有基本的 Python 開發經驗、其他自動化測試腳本開發經驗，且想學習遊戲或交易所應用的協議測試的背景，以求最佳效果。

整體架構

這系列的設定範圍有點大，橫跨遊戲後台建置、Robot Framework 測試腳本撰寫跟一些基礎的容器化部署，會這樣做有幾點原因:

1. 設定測試對象時，要先有一套待測系統，Github 搜尋了一下沒有剛好適合的，只好自己開發一套。所以要把自己變成遊戲開發者，打造一套能夠完整遊玩的後臺服務器功能。裡面又牽涉到 WebSocket 跟 Protocol Buffers 協議的一些技術，也是個藉機了解服務器內部運作的機會。
2. 為了降低理解門檻，會從最小可行的範例（MVP）一路推進，先跑通核心流程，像是連線登入認證，再來才是各個功能的逐步實現，讓讀者能在相同結構下逐步加深理解。
3. Robot Framework 本身的部分，是這一次的重頭戲會佔用最多的篇幅。從個人的理解一一介紹它的主要構成，跟每一個功能怎麼實現它的測試腳本，並且會講解藏在腳本背後的底層 Python 函數實現。同時，會補充專案骨架、資源檔與自訂關鍵字的拆解脈絡，並提供可重用的導入架構參考，協助快速上手並減少重工。
4. 最後會用一點篇幅講在 Docker 中 Jenkins 服務相關的部署說明。

目的是想帶有點程式開發基礎能力的讀者走完整套過程，能知道如何把自動測試應用在遊戲協議測試這個題目中。

所以世界觀有點巨大，請各位看官耐心閱讀。

為了照顧初學者與進階讀者，內容會盡量說明清楚，並解釋必要的知識點，確保讀者能以同一套結構逐步累積成果。

AI 輔助

其次，想聊聊這次會用到的 AI 輔助。打從 2024 起算是AI元年，到了今年手上沒有好幾套 AI 工具的上班族都是瀕危動物了，所以會適度用 AI 支持程式碼跟內容修編。

不過，個人更偏好有溫度的做法，所以大部分的文章內容會是以本人經驗總結為主。或許不能像 AI 那樣詳盡面面俱到，不過卻是能最表達我的想法，也是貨真價實的經驗分享，而非看似完美的廢話。

程式碼的部分，大部分的程式碼是 AI 助手生成的，用了幾個月下來，目前對於 AI 程式開發的心得是這樣:

• Claude Code 調性比較適合我，不過有時候會鬼打牆，一直假裝思考但找不出所以然，最後還會自己承認部分有問題跟限制
• 這時切換到 OpenAI Codex CLI 往往能收到速解，只是會有點過度規劃，每次回答都像在寫論文，然後又過於親切的想無腦引導，不是想把他當作主力，被他的巧言令色迷惑

不過不用擔心品質，最終程式碼一定會經過人工再次確認測試調整後才會上傳。

功能範圍會盡量用最簡單的 POC (概念驗證) 來展示，以協助大家理解實作。

全部的程式碼也會上傳至 GitHub 供大家參閱，不過內容因為多次迭代修改，加上還有想做沒做完的部分，如果有未完善的部分，請多多包涵。

不過 AI 協助開發並不影響我們測試工作的本質。AI 只是個工具， 端看我們怎麼去應用它。

1. 我們要對技術領域有基本的認識，跟程式開發的基本功，才不會被 AI 幻覺中生成的自以為是、看似有用實則糞扣的程式碼牽着鼻子走。
2. AI 目前的技術能力僅接近一個初階的助手，開發完之後還是需要大量的人工審閱，而能不能從中發現架構跟設計上的問題並針對性的去提問解決，這才是一個身為自然人工程師在這時代更重要的能力。
3. 文字輸入的部分有借重 Whisper Flow 語音輸入的協助，在電腦端可以獲得類似手機的高速中英同步口說自動轉文字的舒適體感，也可以加速整個輸入的進度。
4. 在保持原始章節順序不變的情況下，會用 Notion AI 協助潤稿，並於重點段落補上簡短摘要，方便複習與串接到下一步的練習，讓閱讀節奏更流暢。

小結

這是個宏大的規劃，即使藉助 AI 輔助，依舊是工作量不小的企劃，需要一點自動化測試開發的能力，故事的設定背景如上小複雜，各位異世界的冒險者準備好來一趟奇幻之旅了嗎?