OpenClaw E2E 自動化測試指南：建立 QA Lab 與實時傳輸測試

身為開發者，我們最怕的就是寫好的功能在單元測試中看起來完美，實際部署到真實環境卻狀況百出。要確保 OpenClaw 在各種複雜場景下都能穩定運作，我們需要一套更貼近真實使用情境的自動化測試方案，而不僅僅是依賴簡單的測試腳本。

這套 OpenClaw QA E2E 自動化測試系統，能讓你以更真實的管道模擬方式來驗證系統行為。

QA E2E 自動化

私有的 QA 堆疊旨在以比單一單元測試更真實、更貼近頻道運作的方式來測試 OpenClaw。

目前的組成部分：

extensions/qa-channel：合成訊息頻道，具備 DM、頻道、討論串、反應、編輯和刪除等介面。
extensions/qa-lab：除錯 UI 和 QA 匯流排，用於觀察轉錄內容、注入傳入訊息以及匯出 Markdown 報告。
qa/：以 repo 為基礎的種子資源，用於啟動任務和基準 QA 場景。

目前的 QA 操作流程是一個雙欄位的 QA 網站：

左側：帶有 agent 的 Gateway 儀表板（控制 UI）。
右側：QA Lab，顯示類似 Slack 的轉錄內容和場景規劃。

使用以下指令執行：

pnpm qa:lab:up

這會建置 QA 網站，啟動基於 Docker 的 Gateway 通道，並公開 QA Lab 頁面，讓操作員或自動化迴圈可以為 agent 指派 QA 任務、觀察真實的頻道行為，並記錄哪些功能運作正常、失敗或持續受阻。

若要在不每次重新建置 Docker 映像檔的情況下更快地迭代 QA Lab UI，請使用綁定掛載（bind-mounted）的 QA Lab 套件來啟動堆疊：

pnpm openclaw qa docker-build-image
pnpm qa:lab:build
pnpm qa:lab:up:fast
pnpm qa:lab:watch

qa:lab:up:fast 會將 Docker 服務保持在預先建置的映像檔上，並將 extensions/qa-lab/web/dist 綁定掛載到 qa-lab 容器中。qa:lab:watch 會在變更時重新建置該套件，當 QA Lab 資源雜湊值變更時，瀏覽器會自動重新載入。

若要進行真實傳輸的 Matrix 冒煙測試通道，請執行：

pnpm openclaw qa matrix

該通道會在 Docker 中配置一個拋棄式的 Tuwunel 伺服器，註冊臨時驅動程式、SUT 和觀察者使用者，建立一個私有房間，然後在 QA Gateway 子程序中執行真實的 Matrix 外掛程式。即時傳輸通道會將子程序配置限制在受測的傳輸層，因此 Matrix 在執行時，其子程序配置中不會包含 qa-channel。它會將結構化的報告產物和合併後的 stdout/stderr 日誌寫入選定的 Matrix QA 輸出目錄。若要同時擷取外部 scripts/run-node.mjs 建置/啟動器的輸出，請將 OPENCLAW_RUN_NODE_OUTPUT_LOG=<path> 設定為 repo 本地的日誌檔案。

若要進行真實傳輸的 Telegram 冒煙測試通道，請執行：

pnpm openclaw qa telegram

該通道針對一個真實的私有 Telegram 群組，而不是配置拋棄式伺服器。它需要 OPENCLAW_QA_TELEGRAM_GROUP_ID、OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN 和 OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN，外加同一個私有群組中的兩個不同機器人。SUT 機器人必須擁有 Telegram 使用者名稱，且當兩個機器人在 @BotFather 中啟用「機器人對機器人通訊模式」（Bot-to-Bot Communication Mode）時，機器人之間的觀察效果最佳。

即時傳輸通道現在共用一個較小的合約，而不是各自發明自己的場景列表格式：

qa-channel 仍然是廣泛的合成產品行為套件，並不屬於即時傳輸覆蓋矩陣的一部分。

Lane	Canary	Mention gating	Allowlist block	Top-level reply	Restart resume	Thread follow-up	Thread isolation	Reaction observation	Help command
Matrix	x	x	x	x	x	x	x	x
Telegram	x								x

這使得 qa-channel 保持為廣泛的產品行為套件，同時 Matrix、Telegram 和未來的即時傳輸方式共用一個明確的傳輸合約檢查清單。

若要在不將 Docker 引入 QA 路徑的情況下使用拋棄式 Linux VM 通道，請執行：

pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline

這會啟動一個全新的 Multipass 客體機，安裝依賴項，在客體機內建置 OpenClaw，執行 qa suite，然後將正常的 QA 報告和摘要複製回主機上的 .artifacts/qa-e2e/...。它會重複使用與主機上 qa suite 相同的場景選擇行為。主機和 Multipass 套件執行預設會並行執行多個選定的場景，並使用隔離的 Gateway 工作執行緒，最多支援 64 個工作執行緒或選定的場景數量。使用 --concurrency <count> 來調整工作執行緒數量，或使用 --concurrency 1 進行序列執行。即時執行會轉發客體機實用的支援 QA 驗證輸入：基於環境變數的提供者金鑰、QA 即時提供者配置路徑，以及存在時的 CODEX_HOME。請將 --output-dir 保持在 repo 根目錄下，以便客體機可以透過掛載的工作區寫回資料。

Repo-backed seeds

種子資源位於 qa/ 目錄中，這些檔案被納入版本控制，確保 QA 規劃對人類和 agent 都是可見的。

qa/scenarios/index.md
qa/scenarios/*.md

這些檔案刻意存放在 git 中，以便 QA 規劃對人類和 agent 都是可見的。

qa-lab 應該保持為一個通用的 Markdown 執行器。每個場景 Markdown 檔案都是單次測試執行的事實來源，並應定義：

場景元資料
文件和程式碼參考
選用的外掛程式需求
選用的 Gateway 配置修補程式
可執行的 qa-flow

支援 qa-flow 的可重複使用執行階段介面允許保持通用且跨領域。例如，Markdown 場景可以將傳輸端輔助工具與瀏覽器端輔助工具結合，透過 Gateway browser.request 接縫驅動嵌入式控制 UI，而無需增加特殊情況的執行器。

基準列表應保持足夠廣泛，以涵蓋：

DM 和頻道聊天
討論串行為
訊息動作生命週期
cron 回呼
記憶回想
模型切換
子代理交接
repo 閱讀和文件閱讀
小型建置任務，例如 Lobster Invaders

Transport adapters

qa-lab 擁有用於 Markdown QA 場景的通用傳輸接縫。qa-channel 是該接縫上的第一個轉接器，但設計目標更廣泛：未來的真實或合成頻道應插入同一個套件執行器，而不是增加特定於傳輸的 QA 執行器。

在架構層面上，分工如下：

qa-lab 負責通用場景執行、工作執行緒並發、產物寫入和報告。
傳輸轉接器負責 Gateway 配置、就緒狀態、傳入和傳出觀察、傳輸動作以及標準化的傳輸狀態。
qa/scenarios/ 下的 Markdown 場景檔案定義測試執行；qa-lab 提供執行它們的可重複使用執行階段介面。

維護人員關於新頻道轉接器的採用指南位於 Testing。

Reporting

qa-lab 從觀察到的匯流排時間軸匯出 Markdown 協定報告。報告應回答以下問題：

哪些功能運作正常
哪些功能失敗
哪些功能持續受阻
哪些後續場景值得新增

若要進行字元和風格檢查，請跨多個即時模型參考執行相同的場景，並撰寫一份評估後的 Markdown 報告：

pnpm openclaw qa character-eval \
  --model openai/gpt-5.4,thinking=xhigh \
  --model openai/gpt-5.2,thinking=xhigh \
  --model openai/gpt-5,thinking=xhigh \
  --model anthropic/claude-opus-4-6,thinking=high \
  --model anthropic/claude-sonnet-4-6,thinking=high \
  --model zai/glm-5.1,thinking=high \
  --model moonshot/kimi-k2.5,thinking=high \
  --model google/gemini-3.1-pro-preview,thinking=high \
  --judge-model openai/gpt-5.4,thinking=xhigh,fast \
  --judge-model anthropic/claude-opus-4-6,thinking=high \
  --blind-judge-models \
  --concurrency 16 \
  --judge-concurrency 16

此指令執行本地 QA Gateway 子程序，而非 Docker。字元評估場景應透過 SOUL.md 設定角色，然後執行一般的用戶回合，例如聊天、工作區協助和小檔案任務。候選模型不應被告知正在接受評估。該指令會保留每個完整的轉錄內容，記錄基本的執行統計資料，然後以快速模式並使用 xhigh 推理要求評審模型根據自然度、氛圍和幽默感對執行結果進行排名。比較提供者時，請使用 --blind-judge-models：評審提示詞仍會收到每個轉錄內容和執行狀態，但候選參考會被替換為中性標籤（例如 candidate-01）；報告會在解析後將排名對應回真實參考。候選執行預設為 high 推理，對於支援它的 OpenAI 模型則為 xhigh。使用 --model provider/model,thinking=<level> 在行內覆寫特定候選模型。--thinking <level> 仍會設定全域後備，舊的 --model-thinking <provider/model=level> 格式則保留以供相容。 OpenAI 候選參考預設為快速模式，以便在提供者支援的情況下使用優先處理。當單一候選或評審需要覆寫時，請在行內新增 ,fast、,no-fast 或 ,fast=false。僅在想要強制對每個候選模型開啟快速模式時才傳遞 --fast。候選和評審持續時間會記錄在報告中以進行基準分析，但評審提示詞會明確說明不要按速度排名。候選和評審模型執行預設並發數均為 16。當提供者限制或本地 Gateway 壓力導致執行過於嘈雜時，請降低 --concurrency 或 --judge-concurrency。當未傳遞候選 --model 時，字元評估預設為 openai/gpt-5.4、openai/gpt-5.2、openai/gpt-5、anthropic/claude-opus-4-6、anthropic/claude-sonnet-4-6、zai/glm-5.1、moonshot/kimi-k2.5 和 google/gemini-3.1-pro-preview。當未傳遞 --judge-model 時，評審預設為 openai/gpt-5.4,thinking=xhigh,fast 和 anthropic/claude-opus-4-6,thinking=high。

如果你在設定過程中遇到任何問題，歡迎隨時透過 AI Setup Assistant 尋求協助。

OpenClaw Expert

還是卡住了？

如果這篇文件沒有解決你的情境，直接問 OpenClaw Expert，拿到可執行步驟。