SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场wtf.report-bug

wtf.report-bug

测试与质量

查看项目

更新于 10-16 02:18

技能介绍

用途

wtf.report-bug 用于从 QA 发现中提交结构化的 Bug 工单。开发者或 QA 工程师在报告缺陷、创建 Bug 工单、记录测试失败或登记问题时可以使用它。失败的 Gherkin 场景会成为可复现的测试证据，Bug 中引用场景名称以及声称该行为的 Trace，场景文本以 Feature 正文为准，来源 Trace 与 Feature 会被关联以保留上下文。

主要能力

  • 从 QA 发现生成结构化 Bug 工单，包含关联信息、预期行为、实际行为、复现步骤、违反的契约、建议修复和回归风险等部分。
  • 将失败的 Gherkin 场景作为可复现证据，引用场景名称与来源 Trace。
  • 关联来源 Trace 与 Feature，保留上下文。
  • 支持从 wtf.hotfix 调用的快速路径：跳过 Gherkin 推导与统一语言映射，仅收集观察行为、预期行为和复现步骤，以便尽快建单开始修复。
  • 通过 Grep 查找覆盖失败场景的自动化测试文件以及针对被违反契约的现有测试，作为测试证据。
  • 将实现词汇映射回 Trace 故事与 Feature 的统一语言。
  • 使用子代理生成简洁标题，并通过 gh body 辅助脚本创建工单，以支持 Windows 上的多行 UTF-8 内容。
  • 创建后将工单分类为 Bug，并可向来源 Trace 发布关联评论。

使用方式

流程包括以下步骤：

  1. GitHub CLI 环境检查：运行 gh-setup 参考中的安装检查与认证检查，若 gh 未安装或未认证则停止。若本次会话已运行过 gh-setup 则跳过。
  2. 识别来源：若从 wtf.verify-trace 调用，Trace 编号与失败场景已在上下文中，直接进入第 2 步；若直接调用，则询问一句话描述的 Bug 以及声称失败行为的 Trace 编号（或 unknown）。若已知 Trace 编号，按 spec-hierarchy 参考从 Trace 走到 Feature，提取 Scenario Claim、同步场景副本、契约与 DoD，并从 Feature 提取所声称场景的规范文本、AC 与用户故事。若关联的是遗留 Task，则作为遗留 Trace 链接，其 Gherkin 位于 Task 正文中。
  3. 确定失败场景：若 Trace 有 Scenario Claim，展示所声称的场景名称，其规范文本位于 Feature 正文中，应从那里引用而非同步副本。对遗留 Task，则展示 Task 正文中的场景列表。然后通过 AskUserQuestion 询问哪些场景失败，选项包括每个所声称的场景名称以及“New — 未被现有场景覆盖”。对每个失败场景记录场景名称、自动化测试文件路径（若存在）或“manual”、以及失败步骤（第一个未成立的 Then / When）。若此 Bug 没有 Gherkin，则跳过此步，依赖第 3 步。
  4. 收集 Bug 细节：若从 wtf.verify-trace 调用且以下六项细节均已在上下文中，则完全跳过此步。否则对每项未知内容通过 AskUserQuestion 询问：a. 观察行为；b. 预期行为；c. 复现步骤；d. 契约违反；e. 回归风险；f. 建议修复。
  5. 映射到统一语言：检查 Bug 描述与复现步骤，若混入实现词汇（如“数据库返回 null”“HTTP 500 响应”“JSON 字段”），则用与 Trace 故事及其 Feature 的统一语言一致的领域术语重述（如“Order 无法找到”“Payment Settlement 失败”“Shipment Reference 缺失”）。继续前与用户确认重述。若从 wtf.verify-trace 调用且需提交多个失败，则静默应用重述，不请求确认，而是在草稿中注明语言变更。
  6. 查找关联测试文件：使用 Grep 工具定位覆盖失败 Gherkin 场景的自动化测试文件（按场景名称或功能区域搜索）以及针对被违反契约部分的现有测试。列出每个找到的文件并附一行说明，作为 Bug 报告中的测试证据。
  7. 起草 Bug 报告：在写入任何持久正文前，按 ste-writing 参考应用严格 STE。按 issue-template-loading 参考加载 BUG 模板（验证存在性，缺失则停止或设置，读取第二个 --- 分隔符以下的正文）。填写所有部分：Related（Feature、Trace、失败场景、失败测试）、Expected Behavior（逐字引用相关 Gherkin Then 步骤或 Feature AC，并附通俗重述）、Actual Behavior（用领域术语描述实际发生的情况，包括可观察症状）、Steps to Reproduce（具体编号步骤，将 Given 映射为 setup、When 映射为 action、Then 映射为失败断言）、Contracts Violated（粘贴 Trace 中相关契约部分，若无则写“None identified.”）、Suggested Fix（若有假设则填写，否则留空）、Regression Risk（列出触及同一代码路径的其他行为、聚合或集成点）。
  8. 与用户复核：展示草稿，通过 AskUserQuestion 询问是否准确捕捉了 Bug 及其影响，选项为“Yes — 创建工单”或“I have changes — 先调整”。应用修改后继续。
  9. 创建工单：以下命令为伪代码。用 Write 工具将每个正文写入临时文件，然后通过 gh body 辅助脚本（.wtf/gh-body.py）创建，以便多行 UTF-8 内容在 Windows 上存活。标题生成：使用 claude-haiku-4-5-20251001 模型的子代理从 Bug 的一句话描述生成简洁标题，传入描述并要求短标题（无需前缀 emoji/标签，稍后添加）。若子代理未返回可用内容，则直接从一句话描述推导标题。创建工单时不带 kind 标签，由后续分类步骤设置。将工单分类为 Bug，设置 TYPE="Bug" 与 ISSUE_NUMBER，然后运行 issue-classification 参考中的“Classify a new issue”块。若已知来源 Trace，则写入评论并发布以关联 Bug。打印 Bug 工单 URL 与编号，删除临时文件。
  10. 提供后续步骤：通过 AskUserQuestion 询问下一步，选项为“Report another bug — 从本次 QA 会话再提交一个 Bug”（若还有失败则为默认）、“Mark Trace blocked — 重新打开 Trace 并标记被此 Bug 阻塞”、“Done — 退出，无进一步操作”（若无更多失败则为默认）。选择 Report another bug 则从第 2 步以相同 Trace 上下文重新开始；选择 Mark Trace blocked 则重新打开 Trace 并添加阻塞评论；选择 Done 则退出。

适用场景

  • 开发者或 QA 工程师需要报告 Bug、创建 Bug 工单、记录测试失败或登记缺陷时。
  • 从 wtf.verify-trace 发现失败场景后需要建单时。
  • 从 wtf.hotfix 调用时，需要快速建单以便开始修复。

限制

  • 需要安装并认证 GitHub CLI（gh），否则流程停止。
  • 快速路径仅收集观察行为、预期行为和复现步骤，契约违反、回归风险与建议修复留待 hotfix 期间补充。
  • 若此 Bug 没有 Gherkin，则跳过失败场景识别步骤。
  • 关于收费、价格、平台支持范围等具体信息，资料中暂未提供。