mcpField
O
openclaw-qa-testing

openclaw-qa-testing

github.com/openclawテスト・品質393.3k472 回インストール今日更新
リポジトリ

openclaw-qa-testing について

openclaw-qa-testing は、OpenClaw リポジトリ内で QA Lab と qa-channel のテストを実行・保守するためのスキルです。テストスイート、シナリオ作成、モック・ライブ実行、認証情報、キャラクター評価を扱います。

主な機能

  1. 01モックとライブ QA スイートの実行ガイド
  2. 02シナリオ作成とエンドツーエンド検証
  3. 03OTel スモークテストの手順
  4. 04キャラクターとペルソナの評価
  5. 05認証情報とライブチャネルのテスト手順

活用シーン

  1. 01指定レーンで OpenClaw QA スイートを実行
  2. 02YAML QA シナリオの追加・更新
  3. 03OpenTelemetry のトレース出力をローカル検証
  4. 04モデル間のキャラクター挙動を比較

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/openclaw/openclaw --skill openclaw-qa-testing

インストール後、Claude Code で/openclaw-qa-testingを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

OpenClaw QA テスト

qa-lab / qa-channel の作業には、このスキルを使用します。リポジトリ内の QA のみに対応します。

最初に読むもの

  • docs/concepts/qa-e2e-automation.md
  • docs/help/testing.md
  • docs/channels/qa-channel.md
  • qa/README.md
  • qa/scenarios/index.yaml
  • extensions/qa-lab/src/suite.ts
  • extensions/qa-lab/src/character-eval.ts

モデルポリシー

  • 通常のライブスイート実行では、QA Lab のソースと認証情報を考慮したデフォルト設定を使用します。
  • デフォルトでは、--model、--alt-model、--fast を渡さないでください。--fast を省略しても、高速モードが無効になるわけではありません。高速動作はソース側で制御されます。
  • シナリオ固有の実行では、execution.summary の全内容を優先し、他のフラグが必要な場合も含め、一般的なデフォルトの指針より優先します。明示的にプロバイダー／モデルを指定するのは、execution.config.requiredProvider または requiredModel で必要とされる場合に限ります。

デフォルトのワークフロー

  1. シナリオパックと現在のスイート実装を読みます。
  2. 実行レーンを決定します。
    • モック／開発：mock-openai
    • 実環境での検証：live-frontier
  3. 通常のライブスイートでは、次を使用します。
pnpm openclaw qa suite \
  --provider-mode live-frontier \
  --output-dir .artifacts/qa-e2e/run-all-live-frontier-<tag>
  1. 出力を確認します。
    • サマリー：.artifacts/qa-e2e/run-all-live-frontier-<tag>/qa-suite-summary.json
    • レポート：.artifacts/qa-e2e/run-all-live-frontier-<tag>/qa-suite-report.md
  2. ユーザーがライブ UI の表示を希望する場合は、現在の openclaw-qa のリッスンポートを確認し、http://127.0.0.1:<port> を報告します。
  3. シナリオが失敗した場合は、製品またはハーネスの根本原因を修正してから、レーン全体を再実行します。

OTEL スモークテスト

ローカルの QA-lab で OpenTelemetry を検証するには、次を使用します。

pnpm qa:otel:smoke

これにより、ローカルの OTLP/HTTP トレースレシーバーが起動し、qa-channel を介して otel-trace-smoke シナリオが実行され、出力された protobuf スパンがデコードされます。そのうえで、エクスポートされたトレース名とプライバシー要件が検証されます。Opik、Langfuse、外部コレクターの認証情報は不要です。

QA の認証情報と 1Password

  • このリポジトリで QA のシークレットを検索する場合は、op を tmux 内でのみ使用してください。
  • tmux 内での簡易認証チェック：
op account list
  • Telegram の npm ライブテストで直接使用するシークレットは、現在 1Password の次のアイテムにあります。
    • vault：OpenClaw
    • item：Telegram E2E
  • 次の値は、まずこのアイテムを確認してください。
    • OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN
    • OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN
    • OPENCLAW_QA_PROVIDER_MODE
    • OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC
  • Convex の QA シークレットは、現在 1Password の次のアイテムにあります。
    • vault：OpenClaw
    • item：OPENCLAW_QA_CONVEX_SITE_URL
    • item：OPENCLAW_QA_CONVEX_SECRET_MAINTAINER
    • item：OPENCLAW_QA_CONVEX_SECRET_CI
  • QA の認証情報作業中に確認された、関連する追加のメモ／ログインアイテム：
    • vault：Private
    • items：OPENCLAW QA、Convex、Telegram
  • 必要な値がこれらのメモにない場合：
    • 推測しないでください。
    • メンテナー／オペレーターに、現在の値または現在の 1Password アイテム名を確認してください。
    • Telegram の直接実行では、OPENCLAW_QA_TELEGRAM_GROUP_ID が Telegram E2E とは別に保存されている場合があります。
    • Convex での実行では、貸し出された Telegram 認証情報に Telegram グループ ID とボットトークンがまとめて含まれている必要があります。OPENCLAW_QA_TELEGRAM_GROUP_ID を別途要求しないでください。
    • Convex での実行では、OpenClaw/OPENCLAW_QA_CONVEX_SITE_URL を優先してください。古い値である、または不明瞭な場合は、実行前に現在有効なプール URL を確認してください。
  • 利用可能な場合は、npm Telegram Docker レーンで Telegram の直接指定環境変数を優先してください。
OPENCLAW_QA_TELEGRAM_GROUP_ID="..." \
OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN="..." \
OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN="..." \
OPENCLAW_QA_PROVIDER_MODE="mock-openai" \
OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC="openclaw@beta" \
pnpm test:docker:npm-telegram-live
  • 安定した共有 QA インフラが目的の場合は、Convex モードを優先してください。
    • ラウンドロビン方式での認証情報の貸し出し
    • チャネル固有のセットアップを行う薄いラッパー
    • プールされた認証情報を扱う CLI／管理者向けフロー
  • npm Telegram Docker ライブレーンに関する注意：
    • scripts/e2e/npm-telegram-live-runner.ts は OPENCLAW_NPM_TELEGRAM_PROVIDER_MODE を読み取ります。
    • このラッパーが OPENCLAW_QA_PROVIDER_MODE を使用すると決めつけないでください。
    • 1Password のメモに OPENCLAW_QA_PROVIDER_MODE しか記載されていない場合、Docker レーンの実行前に明示的に OPENCLAW_NPM_TELEGRAM_PROVIDER_MODE に割り当ててください。
  • 検証済みのライブ実行構成：
    • Convex モードでは、Telegram の直接指定環境変数なしで実際の Docker レーンを通過できます。
    • 貸し出される Telegram ペイロードには、ドライバー／SUT トークンと関連付けられたグループ ID が含まれます。
    • 次の値を指定した pnpm test:docker:npm-telegram-live の実際の実行は成功しました。
      • OPENCLAW_QA_CREDENTIAL_SOURCE=convex
      • OPENCLAW_QA_CREDENTIAL_ROLE=maintainer
      • OPENCLAW_QA_CONVEX_SITE_URL
      • OPENCLAW_QA_CONVEX_SECRET_MAINTAINER
      • OPENCLAW_NPM_TELEGRAM_PROVIDER_MODE=mock-openai
  • Telegram の直接指定環境変数がローカルにない状態で op signin がブロックされる場合は、qa-live-shared 環境に Convex CI 認証情報がすでにあるため、手動の GitHub レーンをディスパッチしてください。
gh workflow run "NPM Telegram Beta E2E" --repo openclaw/openclaw --ref main \
  -f [email protected] \
  -f [email protected] \
  -f provider_mode=mock-openai
  • ディスパッチ URL に記載された正確な実行 ID をポーリングしてください。gh run view --json artifacts はサポートされていません。次のコマンドでアーティファクトを一覧表示してください。
gh api repos/openclaw/openclaw/actions/runs/<run-id>/artifacts

WhatsApp のライブ認証情報

Convex の kind=whatsapp 認証情報を設定または置き換える場合に使用します。

  • WhatsApp QA 認証情報は、生成されたフィクスチャではなく、オペレーターが所有するライブアカウントとして扱います。
  • WhatsApp に対応した専用のテスト番号を2つ用意します。1つはドライバーアカウント、もう1つは SUT アカウントです。個人番号や個人用の OpenClaw WhatsApp アカウントを共有プールで使用しないでください。
  • WhatsApp または WhatsApp Business を使って各アカウントを手動で登録およびリンクし、Web 認証情報はリポジトリ外の分離されたローカル認証ディレクトリにのみ保存します。
  • グループのカバレッジをテストする場合は、両方の QA アカウントを含む専用のテストグループを作成し、その JID を groupJid として保存します。そうしない場合、グループのメンションゲーティングシナリオはデフォルトでスキップされ、明示的に要求された場合は失敗する必要があります。
  • 2つの Baileys 認証ディレクトリを base64 の .tgz ペイロードフィールドにまとめ、新しい有効な Convex 認証情報行を追加します。認証情報をその場で上書きするより、新しい行を追加して、古い行や壊れた行を無効化することを推奨します。
  • 予期されるペイロードフィールド：driverPhoneE164、sutPhoneE164、driverAuthArchiveBase64、sutAuthArchiveBase64、および任意の groupJid。
  • 認証情報をリポジトリ、ログ、PR、スクリーンショットに含めないでください。オペレーターからローカルでのデバッグを明示的に依頼された場合を除き、電話番号は伏せてください。
  • pnpm openclaw qa whatsapp --credential-source convex --credential-role maintainer --provider-mode mock-openai で検証し、アーティファクトのパスと、情報を伏せた合否サマリーを保存します。
  • WhatsApp の有効期限が切れた場合、またはリンク済みの Web セッションが無効になった場合は、ローカルで再リンクし、新しい認証アーカイブを作成して新しい Convex 行を追加した後、古い行を無効化します。

キャラクター評価

複数のライブモデルを対象にスタイル／ペルソナ／雰囲気を確認するには、qa character-eval を使用します。

pnpm openclaw qa character-eval \
  --output-dir .artifacts/qa-e2e/character-eval-<tag>
  • Docker ではなく、ローカルの QA ゲートウェイ子プロセスを実行します。
  • パッケージ化された pnpm build では、設計上 QA Lab と qa-channel は除外されます（ソースチェックアウトのみ）。ビルド済みの dist から openclaw qa／qa-channel を実行するには、OPENCLAW_BUILD_PRIVATE_QA=1 pnpm build でビルドするか（dist/plugin-sdk/qa-lab.js、qa-runtime.js、dist/extensions/{qa-lab,qa-channel} が生成されます）、pnpm dev で実行します。
  • モデルフラグを指定しない場合、キャラクター評価では現在ソースで定義されている候補、判定、思考、fast のデフォルト値が使用されます。
  • 対応するインベントリを明示的に置き換える場合に限り、--model provider/model,thinking=<level>[,fast|,no-fast|,fast=<bool>] または --judge-model ... を繰り返し指定します。
  • --model-thinking を別途指定する新しい例は追加しないでください。このフラグはレガシー互換性のためだけに残します。
  • レポートには判定ランキング、実行統計、所要時間、完全なトランスクリプトが含まれます。判定の生の応答は含めないでください。所要時間はベンチマークの参考情報であり、評価指標ではありません。
  • 候補と判定の同時実行数はデフォルトで16です。ローカルゲートウェイやプロバイダーの制限に応じて負荷を抑える必要がある場合は、--concurrency <n> と --judge-concurrency <n> で上書きします。
  • シナリオのソースは qa/scenarios/ 配下の YAML のみです。index.yaml と、トップレベルに title、scenario、任意の flow を含むシナリオごとの *.yaml ファイルを使用します。フェンス付きの qa-scenario／qa-flow Markdown ファイルは追加しないでください。
  • キャラクター／ペルソナを個別に評価する場合は、シナリオフローでペルソナを SOUL.md に記述し、IDENTITY.md を空にします。通常の OpenClaw のアイデンティティがキャラクターとどのように組み合わさるかを意図的にテストする場合に限り、SOUL.md + IDENTITY.md を使用します。
  • プロンプトは自然で、タスクに即したものにしてください。候補モデルには、まず SOUL.md を通じてキャラクター設定を与え、その後、チャット、ワークスペースのサポート、小規模なファイル作業など、通常のユーザーとのやり取りを行います。「どう反応しますか？」と尋ねたり、モデルに評価中であると伝えたりしないでください。
  • 純粋なロールプレイではなく、通常のツール利用時のキャラクターがトランスクリプトに記録されるよう、小さなワークスペース成果物の作成や編集など、実際のタスクを少なくとも1つ含めることを推奨します。

Codex CLI モデルレーン

QA で Codex をモデルバックエンドとしてテストする場合は、codex-cli/<codex-model> 形式のモデル参照を使用します。

例：

pnpm openclaw qa suite \
  --provider-mode live-frontier \
  --model codex-cli/<codex-model> \
  --alt-model codex-cli/<codex-model> \
  --scenario <scenario-id> \
  --output-dir .artifacts/qa-e2e/codex-<tag>

pnpm openclaw qa manual \
  --model codex-cli/<codex-model> \
  --message "Reply exactly: CODEX_OK"
  • 具体的な Codex モデル名はユーザー／設定からの入力として扱い、ソース、ドキュメントの例、シナリオにハードコードしないでください。
  • ライブ QA では CODEX_HOME を維持して Codex CLI の認証／設定を機能させる一方、HOME と OPENCLAW_HOME はサンドボックス化します。
  • モック QA では CODEX_HOME を消去してください。
  • Codex が毎ターン、フォールバック／認証に関するテキストを返す場合は、シナリオのアサーションを変更する前に、まず CODEX_HOME、関連するシークレットベースの認証、ゲートウェイの子プロセスログを確認してください。
  • モデルを比較する場合は、qa character-eval に別候補として codex-cli/<codex-model> を含めてください。レポートでは、不透明なモデル名として表示してください。

リポジトリの情報

  • シードシナリオは qa/scenarios/index.yaml と qa/scenarios/<theme>/*.yaml にあります。
  • メインのライブランナー：extensions/qa-lab/src/suite.ts
  • QA ラボサーバー：extensions/qa-lab/src/lab-server.ts
  • 子ゲートウェイハーネス：extensions/qa-lab/src/gateway-child.ts
  • 合成チャンネル：extensions/qa-channel/

「完了」の状態

  • リクエストされたレーンのスイート全体が成功している。
  • ユーザーに以下を提供する：
    • 該当する場合はウォッチ URL
    • 成功／失敗の件数
    • 成果物のパス
    • 修正内容についての簡潔な説明

よくある失敗パターン

  • ライブのタイムアウトが短すぎる：
    • extensions/qa-lab/src/suite.ts のライブ待機時間を延ばしてください
  • リポジトリのファイルを検出できない：
    • シードされたワークスペース内の repo/... をプロンプトで指定してください
  • サブエージェントの証拠が不安定すぎる：
    • 一時的な子セッションの一覧表示より、安定した最終応答の証拠を優先してください
  • ハーネスの「再ビルド」による遅延：
    • ツリーがダーティだと、実行前にビルドが行われることがあります。ポートが表示される前に発生するものとして想定してください

シナリオを追加する場合

  • qa/scenarios/ にシナリオ YAML を追加または更新してください。.md 形式のシナリオファイルや、コードフェンスで囲んだ YAML ブロックは追加しないでください。
  • qa/scenarios/index.yaml のキックオフ時の期待内容を整合させてください
  • 実行可能なカバレッジを extensions/qa-lab/src/suite.ts に追加してください
  • モックのみのチェックより、エンドツーエンドのアサーションを優先してください
  • 出力は .artifacts/qa-e2e/ に保存してください

コメント

Markdown 対応