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

qa

测试与质量

查看项目

更新于 10-16 05:58

技能介绍

用途

qa 用于对应用程序进行系统化的质量测试（QA）。其设计目标是让测试过程像真实用户操作一样：点击所有可交互元素、填写每一个表单、检查每一种状态，并在发现缺陷后直接修复源码。它适用于 Web 应用、原生 macOS 应用、Electron 应用、CLI 工具、交互式 REPL 以及屏幕上可见的任何应用。

整个流程被描述为一个闭环：Plan -> Test -> Fix -> Verify（计划 -> 测试 -> 修复 -> 验证）。

主要能力

三种测试模式

  • browser 模式：当提供 URL（http/https/localhost）时使用，适用于 Web 应用，通过 CDP 获得 DOM 访问能力。若当前处于功能分支且没有 URL，也会以 diff-aware 方式在本地验证分支改动。
  • computer 模式：适用于原生应用（如 Slack、Notes、Figma）以及 Electron 应用，即使 Electron 应用基于 Web 技术也归入此类。
  • cli 模式：适用于 CLI 命令、REPL 或交互式终端，需要 tmux send-keys 与 capture-pane 支持。

模式默认自动检测，也可通过 --browser、--computer、--cli 手动覆盖；若无法判断则会询问用户决定。

测试层级与选项

  • Tier 默认 standard，可用 --quick 或 --exhaustive 覆盖。quick 模式只测主界面和 3-5 个顶层导航目标，跳过逐屏检查清单；exhaustive 则修复包括外观类在内的所有问题。
  • --report-only 表示只报告、不修复代码。
  • 输出目录默认为 .qa-reports/，可用参数改为其他位置（例如 /tmp/qa）。
  • 可指定 Scope，例如只关注计费页面。

八个阶段

  1. Phase 0：分析目标并选择模式。包括解析用户请求、自动选模式、按模式读取设置说明、清理工作区（若需修复代码则检查 git status，脏则询问提交、暂存或中止），并创建输出目录。
  2. Phase 1：制定测试计划。收集上下文（diff-aware 时用 git diff main...HEAD --name-only 与 git log main..HEAD --oneline 识别受影响页面），导航并截图，映射导航结构，生成包含目标、屏幕优先级、每屏测试用例、认证/前置条件、范围外内容的测试计划。quick 模式跳过用户确认直接执行，standard/exhaustive 允许用户先调整范围。
  3. Phase 2：熟悉应用。导航到起点、截图、识别框架、映射导航结构、记录当前状态。
  4. Phase 3：探索与记录。按计划逐屏访问，截图并按 references/issue-taxonomy.md 中的检查清单执行：视觉扫描、交互元素、表单、导航、状态（空、加载、错误、溢出）、滚动与折叠以下内容、控制台错误或视觉错误。交互类问题需操作前后截图并写出复现步骤；静态问题单张截图并放大受影响区域。问题即时记录，不批量处理。
  5. Phase 4：计算健康分。按文末评分标准计算基线健康分。
  6. Phase 5：分级。按严重程度排序，并按层级决定修复范围：quick 只修 critical 和 high；standard 修 critical、high、medium；exhaustive 全修。
  7. Phase 6：修复循环。先用 Grep/Glob 定位源码，做最小修复（不重构周边代码），只添加改动文件并单次提交，提交信息格式为 fix(qa): ISSUE-NNN — 简短描述。每次修复后重新测试并分三类：verified（重测确认）、best-effort（已修复但无法完全验证）、reverted（出现回归则 git revert HEAD 并标记 deferred）。另外设有自调节机制：每 5 次修复或任意一次回滚后计算 WTF 可能性，起始 0%，每次回滚 +15%，每次修改超过 3 个文件 +5%，第 15 次修复后每额外一次 +1%，剩余问题全为低严重度 +10%，触碰无关文件 +20%；超过 20% 则停止并询问用户是否继续。修复硬上限为 50 个。
  8. Phase 7：最终 QA。重测所有受影响屏幕，计算最终健康分；若最终分低于基线会显著警告。
  9. Phase 8：报告。写入 .qa-reports/qa-report-{target}-{YYYY-MM-DD}.md，内容包含测试计划摘要、每个问题的截图证据、修复状态、健康分变化，以及是否可发布的一句话结论。

健康分评分标准

每个类别 0-100 分，然后加权平均：

  • 控制台/错误 15%：0 个错误=100，1-3=70，4-10=40，10 以上=10
  • 导航 10%：全部正常=100，每条损坏路径 -15
  • 视觉 10%、功能 20%、UX 15%、性能 10%、内容 5%、无障碍 15%：均从 100 起，critical -25、high -15、medium -8、low -3

score = sum(category_score * weight)

使用方式

通过名称 qa 调用。可传入目标（URL、应用名、CLI 命令或 "current branch"）、模式、层级、是否仅报告、输出目录和范围等参数。本介绍中仅提供了参数表（Target、Mode、Tier、Report-only、Output dir、Scope）及其默认值与覆盖示例，未提供具体调用命令或安装方式，这些信息暂未提供。

重要规则

  • 先计划后测试，与任何应用交互前必须先生成测试计划。
  • 每个问题至少附一张截图；记录前先重试一次确认可复现。
  • 绝不写入凭据，密码一律写为 [REDACTED]。
  • 增量记录，发现一个问题就追加一个。
  • 像用户一样测试，使用真实数据，端到端完成工作流。
  • 深度优先：5-10 个记录充分的问题优于 20 个模糊描述。
  • 每个修复单独提交，绝不捆绑。
  • 出现回归立即 git revert HEAD。
  • 遵循自调节的 WTF 可能性启发式规则。

适用场景与限制

适用于需要在浏览器、桌面应用或命令行界面上进行可复现 UI/交互测试，并希望在同一流程中修复缺陷的场景。限制方面：需要参考资料文件（references/browser-mode.md、references/computer-mode.md、references/cli-mode.md、references/issue-taxonomy.md、templates/qa-report-template.md）才能完成对应模式的设置与问题分类，但本资料未提供这些文件的内容与获取方式；修复需要源码存在，否则跳过 Phase 6；其修复授权、凭据处理等规则明确。其他如收费标准、支持平台细节、效果指标等并未提供。