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. 02新增或更新 YAML QA 场景
  3. 03在本地验证 OpenTelemetry 轨迹导出
  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

  • 在此仓库中，仅在 tmux 内使用 op 查询 QA 密钥。
  • 在 tmux 内快速检查身份验证：
op account list
  • 直接 Telegram npm 实时测试的密钥目前存放在 1Password 条目中：
    • 保管库：OpenClaw
    • 条目：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 条目中：
    • 保管库：OpenClaw
    • 条目：OPENCLAW_QA_CONVEX_SITE_URL
    • 条目：OPENCLAW_QA_CONVEX_SECRET_MAINTAINER
    • 条目：OPENCLAW_QA_CONVEX_SECRET_CI
  • QA 凭据相关工作中还发现了以下相关备注/登录条目：
    • 保管库：Private
    • 条目：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
  • 如果有直接 Telegram 环境变量，npm Telegram Docker 流程优先使用它们：
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 受阻，优先调度手动 GitHub 流程，因为 qa-live-shared 环境已经配置了 Convex CI 凭据：
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 测试号码：一个驱动账号和一个 SUT 账号。共享池中不得使用个人号码或个人 OpenClaw WhatsApp 账号。
  • 手动注册每个账号并通过 WhatsApp 或 WhatsApp Business 关联账号，仅将 Web 身份验证信息存储在仓库外相互隔离的本地身份验证目录中。
  • 如需覆盖群组场景，请创建一个包含两个 QA 账号的专用测试群组，并将其 JID 存储为 groupJid；否则，默认应跳过群组提及门控场景，并在明确要求运行时失败。
  • 将两个 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>
  • 运行本地 QA 网关子进程，而非 Docker。
  • 按设计，打包后的 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 运行。
  • 未指定模型标志时，角色评估会使用当前由源码定义的候选模型、评审模型、思考和快速模式默认值。
  • 仅在明确替换相应模型列表时，才重复使用 --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 和各场景的 *.yaml 文件，顶层字段为 title、scenario，以及可选的 flow。切勿添加带围栏的 qa-scenario/qa-flow Markdown 文件。
  • 对于隔离的人设/角色评估，请在场景流程中将人设写入 SOUL.md，并将 IDENTITY.md 留空。仅当有意测试正常 OpenClaw 身份与角色的组合方式时，才使用 SOUL.md + IDENTITY.md。
  • 提示词应自然且围绕任务编写。候选模型应通过 SOUL.md 接收角色设定，然后处理正常的用户请求，例如聊天、工作区帮助和小型文件任务；不要询问“你会如何反应？”，也不要告诉模型它正在参与评估。
  • 尽量至少包含一项实际任务，例如创建或编辑一个小型工作区产物，这样对话记录就能呈现模型在正常工具使用场景下的角色表现，而非纯角色扮演。

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 lab 服务端：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/...
  • 子 Agent 的验证过于脆弱：
    • 优先采用稳定的最终回复证据，而非短暂的子会话列表
  • 测试框架“重建”延迟：
    • 脏工作树可能会触发运行前构建；请预期端口会在构建完成后才出现

添加场景时

  • 在 qa/scenarios/ 下添加或更新场景 YAML；不要添加 .md 场景 文件或围栏 YAML 代码块。
  • 确保 qa/scenarios/index.yaml 中的启动预期保持一致
  • 在 extensions/qa-lab/src/suite.ts 中添加可执行覆盖
  • 优先采用端到端断言，而非仅模拟检查
  • 将输出保存在 .artifacts/qa-e2e/ 下

评论

支持 Markdown