SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场testing

testing

测试与质量

查看项目

更新于 10-15 15:17

技能介绍

用途

Testing 技能包含两种相互关联但彼此独立的模式。第一种是技能一致性校验，属于 gbrain 自身的合规标准；第二种是项目测试套件健康（v0.25.1 扩展），用于运行项目分层测试并生成回归分类报告，被每日 cron、容器重启引导以及“测试情况如何”这类询问所使用。触发方式决定使用哪种模式。

主要能力：模式一 技能一致性校验

该模式保证以下内容：每个技能目录都有 SKILL.md 文件；每个 SKILL.md 都有合法的 YAML frontmatter（包含 name、description）；每个 SKILL.md 都按 test/skills-conformance.test.ts 的要求具备必需章节；skills/manifest.json 列出所有技能目录；skills/RESOLVER.md 引用 manifest 中的每个技能；openclaw.plugin.json 的 skills[] 与二者往返一致；openclaw.plugin.json 保留 OpenClaw 安装所需的原生插件字段（id、对象类型的 configSchema，以及适用时的 contracts.contextEngines）；不存在 MECE 违规（技能之间触发条件重复）。

执行阶段

依次为：遍历技能目录，列出所有包含 SKILL.md 的子目录；校验 frontmatter，解析 YAML 并检查必填字段；校验章节，检查必需标题；检查 manifest，每个技能目录都必须在 manifest.json 中；检查 resolver，每个 manifest 技能都必须有 RESOLVER 行；检查往返，RESOLVER 触发条件与 frontmatter 触发条件必须一致；最后报告结果。

自动化与输出

自动运行命令为：bun test test/skills-conformance.test.ts test/resolver.test.ts test/openclaw-plugin-manifest.test.ts。CI 门禁检查是 package.json 中的 test 脚本。输出格式为一份技能校验报告，包含发现的技能数、一致性通过数、manifest 覆盖数、resolver 覆盖数、往返一致数、MECE 违规数以及问题清单。

主要能力：模式二 项目测试套件健康

使用时机

每日测试 cron 触发时；用户要求“运行测试”“测试情况如何”“哪里坏了”时；重大代码变更后（通常经由 cross-modal-review）；容器重启后（bootstrap）；以及感觉异常、想验证系统健康时。

测试层级

Unit：运行 bun test，确定性、零外部调用，耗时小于 2 秒，每次提交都执行。Evals：LLM 评审或质量评估，约 60 秒，每日执行。Integration：针对真实 Postgres 的端到端测试，约 5 分钟，发版前与每晚执行。System health：磁盘、内存、CPU、服务存活检查，小于 10 秒，每日执行。

每日运行流程

  1. 运行单元测试：bun test 2>&1，解析通过、失败、跳过总数及文件级结果。
  2. 运行评估（若项目有 evals 配置）：bun test --filter eval 2>&1，按同样格式解析，并记录因 API 超时而非代码缺陷导致的偶发失败。
  3. 运行系统健康检查：磁盘、内存、CPU，使用 gbrain doctor --fast --json；数据库连接（如适用）；关键文件是否存在（如 CLAUDE.md、AGENTS.md 等）。
  4. 进行 git diff 分析（关键，用于回归智能）：用 git log --oneline --since="24 hours ago" 查看变更；对每个失败测试，检查该测试本身是否近期被改动（属测试改动而非回归）、其所测代码是否近期被改动（可能是回归）、是否为已知偶发（API 超时、服务宕机）、依赖是否被更新（gbrain、bun 等）。
  5. 对每个失败进行分类：REGRESSION（代码变了、测试坏了，🔴，标出导致问题的提交）；STALE（测试期望旧行为、代码正确，🟡，修测试而非代码）；FLAKE（API 超时、服务宕机、LLM 波动，⚠️，记录但不报警，重试一次）；NEW（测试刚加入尚未通过，🟢，确认是否有意为之）；INFRA（容器重启清除状态，🛠，运行 bootstrap 后重测）。
  6. 按报告格式输出：日期、Unit、Evals、System 摘要，以及 REGRESSIONS、STALE TESTS、FLAKES 或 ALL CLEAR。
  7. 自动修复协议：可自动修复的情况包括——重命名后测试仍期望旧文件路径、测试期望旧版本字符串、测试期望一个被有意删除的文件、文件移动导致导入路径断裂。不可自动修复的情况包括——测试期望行为 A 但代码变为 B（须先询问，也许测试是对的、代码有 bug）、安全测试失败（始终上报，绝不自动修复）、以 TODO 跳过的测试（不理解原因不要取消跳过）。不确定时：查看改动代码的提交信息，检查是否有相关 PR 或对话，仍不清晰则询问用户。

状态与趋势

在 ~/.gbrain/test-state.json 中记录结果，结构包含 lastRun、unit、evals、system 与 failureHistory。这支持趋势跟踪（变好还是变差）、偶发检测（同一测试间歇性失败）以及回归速度（改动后多快出问题）。

失败处理

遇到任何 gbrain 错误码、退出码、[AGENT] 块或 notice 块时，遵循 agent operator protocol。本技能特定规则：因缺少 API key 或提供方不稳定导致的测试失败，应归类为环境失败而非代码失败，并指出是哪个 key；安全测试失败，始终上报用户，绝不自动修复；gbrain doctor 无法访问 brain（GBRAIN_DB_ACCESS）时，先路由到 db-repair 技能，再运行集成测试。

反模式

新增技能后跳过一致性校验；把技能加入 manifest.json 却不加入 RESOLVER.md；把每个红色测试都当作回归（应先分类，很多是过时或偶发）；不理解跳过原因就自动取消跳过；自动“修复”安全测试失败；没有真正运行系统健康检查就报告“全部正常”。

适用场景

适合在 gbrain 项目及其技能体系中做技能合规检查、每日测试巡检、代码变更后的回归排查以及容器重启后的健康验证。

限制

该技能的契约保证：路由匹配 frontmatter 中的规范触发条件；输出写入 writes_to 所列目录（如适用）；遵循所引用的约定（quality.md、brain-first.md、_brain-filing-rules.md）；保持隐私契约（无真实姓名、无特定于 fork 的文件系统路径字面量、无上游 fork 引用）。关于收费、价格、可用平台与具体效果等，资料中暂未提供。