Imported from Glepooek/optimus-plugins-official (plugins/optimus-qa-plugin/skills/optimus-qa-test-report/SKILL.md). Install upstream with npx skills add Glepooek/optimus-plugins-official --skill optimus-qa-test-report. Copyright stays with the author.

QA报告统一生成工具

概述

统一入口，支持三类 QA 报告的生成：

Step 0：识别模式

根据用户触发词判断执行哪个模式：

• 含"缺陷"/"bug"/"质量分析" → 模式 A
• 含"执行"/"执行记录"/"执行报告" → 模式 B
• 含"综合"/"总结"/"测试报告"/"上线" → 模式 C

若无法判断，询问用户：「请问您要：(A) 缺陷分析报告、(B) 测试执行记录，还是 (C) 综合测试报告？」

模式 A：缺陷分析报告

A-Step 1：收集缺陷数据

数据来源优先级：飞书项目 MQL 查询 > 本地文件 > 手动粘贴

方式一：飞书项目 MQL 查询（推荐）

前置信息收集：

• 项目空间标识（project_key 或 simpleName，如 jsgx2023）
• 项目名称筛选关键词（如"AI智课"）
• 工作项类型（默认 issue / 缺陷）

查询步骤：

1. 获取字段元数据：

   工具：get_workitem_field_meta
   参数：project_key={空间key}, work_item_type=issue
   

   ⚠️ list_workitem_field_config 可能因权限问题报错，优先使用 get_workitem_field_meta。

2. MQL 查询缺陷数据：

   工具：search_by_mql
   mql: SELECT `name`, `work_item_id`, `priority`, `severity`, `bug_classification`, `issue_stage`
        FROM `{空间名}`.`缺陷`
        WHERE `name` LIKE '%{关键词}%'
   

3. 分页获取全量数据（每页最多 50 条）：

   参数：session_id: {上次返回的session_id}
         group_pagination_list: [{"group_id": "{group_id}", "page_num": 2}]
   

4. 补充单条详情（如需）：

   工具：get_workitem_brief
   参数：project_key={空间key}, work_item_id={缺陷ID}
   

常用字段映射：

严重程度映射规则：

报告中统一使用 S级(中文) 格式展示，如 S1(严重)。

方式二：本地文件

在 docs/ 目录下查找 *缺陷* 相关文件，直接读取。

方式三：手动粘贴

询问用户提供：项目名称、缺陷列表（ID/标题/状态/严重程度/优先级/模块/创建日期/关闭日期）、统计截止日期。

A-Step 2：数据分析计算

总览指标：

• 总缺陷数、已修复（CLOSED）数、未修复（OPEN）数、遗留缺陷（OPEN 且超 7 天）数
• 修复率 = 已修复 / 总数 × 100%；平均修复周期（已修复缺陷的关闭日-创建日均值）

模块分布： 按缺陷标题中的模块标签分组，每模块统计总数/已修复/未修复/占比

严重程度分布： 按严重程度、优先级、端分类（Web前端/Server后端/移动端）分组统计

缺陷趋势： 按创建日期统计每日新增数及对应修复数

遗留缺陷清单： 列出所有 OPEN 缺陷，分析遗留原因和风险等级

A-Step 3：生成报告

按 references/bug-report-template.md 格式输出到 docs/{项目名}-缺陷分析报告.md。

生成规则：

• 文本图表用 ASCII 柱状图/趋势图模拟
• 数据不足时相应章节注明"暂无数据"并说明原因
• 根因分析需结合缺陷标题推断，不可凭空捏造
• 质量改进建议需与当前数据中的问题挂钩

模式 B：测试执行记录

B-Step 1：收集执行数据

方式一：飞书项目 URL + MQL（推荐）

当用户提供飞书项目 URL 时，不要询问用户确认，直接执行全流程。

1.1 解析 URL，获取空间信息

支持的 URL 格式：

• 测试计划：https://project.feishu.cn/{simple_name}/test_plans/detail/{work_item_id}
• 执行用例视图：https://project.feishu.cn/{simple_name}/workObjectView/using_test_case/{view_id}

从 URL 提取 simple_name，调用 search_project_info 获取 project_key 和空间名称。

1.2 获取测试计划基本信息

若 URL 含测试计划 ID，调用 get_workitem_brief 获取：名称、状态、创建人、执行人、时间。

1.3 MQL 查询执行用例列表

SELECT `work_item_id`, `name`, `更新时间`
FROM `{simple_name}`.`执行用例`
WHERE `关联测试计划` = '{测试计划名称}'

重要： 关联测试计划 的值必须使用测试计划名称（字符串），不能用 ID。每页最多 50 条，使用 session_id + group_pagination_list 翻页。

MQL 已验证不可用字段（会报 attr label not found，不要尝试）： status、执行状态、执行结果、priority、created_at、connection_test_plan_id、工作项ID

1.4 批量获取用例执行状态

执行用例状态（通过/不通过/阻塞/未执行）只能通过 get_workitem_brief 逐条获取。

高效策略：

1. 提取所有 work_item_id
2. 使用子代理批量查询（每批 80-100 条，每次最多 10 个并行调用）：

   使用 get_workitem_brief 批量查询执行用例状态。
   对每条用例提取：work_item_id、工作项名称、工作项状态、角色成员（执行人）、更新时间。
   将结果保存到 docs/{临时文件名}.md
   

3. 读取结果文件，合并全量数据，合并后删除临时文件

1.5 获取关联缺陷数据

SELECT `work_item_id`, `name`, `priority`, `severity`, `status`, `更新时间`
FROM `{simple_name}`.`缺陷`
WHERE `name` LIKE '%{关键词}%'

若查询缺陷失败，检查 docs/ 下是否有已生成的缺陷分析报告，直接引用其数据。

方式二：用户手动提供数据

询问用户提供：产品/版本、测试环境、执行日期、执行人、用例列表（ID/名称/用例分级/执行状态/更新时间）、发现缺陷（可选）。

B-Step 2：数据分析计算

用例汇总（按模块）： 从用例名称中提取模块标签（如 [模块名] 中的内容），每模块统计总数/通过/失败/阻塞/未执行/通过率。

用例分级提取： 从用例名称末尾的 [P0]/[P1]/[P2] 提取，无标记则为"未分级"。

风险评级：

• 高风险：P0 失败 / 通过率 < 70% / 多条阻塞
• 中风险：P1 失败 / 通过率 70-90% / 少量阻塞
• 低风险：仅 P2 失败 / 通过率 ≥ 90% / 无阻塞

需求覆盖率分析（自动检测）： 检查 docs/ 下是否有需求拆分文档，如存在则从用例名称 [FR-xxx,AC-xxx] 中提取编号与需求文档比对，统计 FR/AC/NFR 覆盖率。

B-Step 3：生成报告

按 references/execution-report-template.md 格式输出到 docs/{项目名}-测试执行记录.md。

生成规则：

• 通过用 ✅，失败用 ❌，阻塞用 🚫，未执行用 ⏭
• 用例明细表格仅列出失败/阻塞/未执行的用例，通过的用例不逐条列出
• 失败/阻塞用例在"阻塞与风险"章节写具体排查方向
• 数据不足时填"未记录（建议补充）"

飞书 MCP 常见错误处理：

模式 C：综合测试报告

C-Step 1：确定数据来源

优先级：飞书项目 URL + MQL > 本地文件 > 手动粘贴

方式一：飞书项目 URL + MQL（首选）

1a. 获取空间基础信息

工具：search_project_info
参数：project_key={simpleName}

记录空间全名（如"A 技术共享中心-产研项目空间（正式）"），后续 MQL FROM 子句需要。

1b. 通过视图 URL 获取缺陷明细

工具：get_view_detail
参数：url: {飞书视图URL}, view_id: {视图ID}
      fields: ["name","priority","severity","work_item_status","owner","created_at"]

⚠️ 视图可能包含全空间数据，必须通过 MQL 按关键词筛选，不能直接用视图总数。

1c. MQL 精确查询缺陷统计（核心步骤）

总量查询 + 按状态分别查询（建议并行调用）：

-- 总量
SELECT `name`, `work_item_status`, `severity` FROM `{空间全名}`.`缺陷`
WHERE `name` LIKE '%{项目关键词}%'

-- 分状态（OPEN / CLOSED / RESOLVED / IN PROGRESS / REOPENED）
SELECT `work_item_status`, `severity` FROM `{空间全名}`.`缺陷`
WHERE `name` LIKE '%{关键词}%' AND `work_item_status` = 'OPEN'

返回的 list[0].count 即为该条件的匹配数量。MQL 不支持 count(*) 聚合。

MQL 查询要点：

1d. 获取测试执行数据

工具：get_view_detail
参数：project_key: {真实project_key}  # 注意：测试用例视图需用真实key，非simpleName
      view_id: {测试执行视图ID}
      fields: ["name","priority","work_item_status","owner"]

方式二：本地文件读取

在 docs/ 下查找：

• docs/*缺陷分析报告*.md → 提取缺陷统计数据
• docs/*测试执行记录*.md → 提取用例执行数据

方式三：手动粘贴

询问用户提供飞书项目空间 ID、项目名称筛选关键词、缺陷列表和测试用例执行记录数据。

C-Step 2：信息汇总与分析

基本信息： 项目名称、测试版本、测试周期、测试人员

执行结果汇总：

• 从缺陷分析数据提取模块缺陷分布、总修复率
• 从测试执行数据提取各模块通过率汇总
• 需求覆盖率（无数据标注"待补充"）

遗留缺陷： 提取 OPEN 缺陷，评估遗留原因与风险等级

质量风险矩阵： 结合未修复缺陷、低修复率模块、未覆盖测试项，构建风险矩阵（高/中/低）

测试结论（综合判断）：

• 通过上线：修复率 ≥ 95%，无高风险遗留，P0 全部通过
• 条件上线：修复率 80-95%，有高风险遗留但有应对措施
• 不建议上线：修复率 < 80% 或 P0 失败 或 高风险阻塞未解决

C-Step 3：生成报告

按 references/test-report-template.md 格式输出到 docs/{项目名}-测试报告.md。

生成规则：

• 章节顺序固定（1~11），不可省略，无数据用"暂无数据（建议补充）"说明
• 非功能测试如无实际数据，标注"本轮未执行，建议上线前补充"
• 改进建议需与实际缺陷数据挂钩，不写空洞的通用建议
• 附件清单列出本次生成所引用的源文件

质量检查

模式 A（缺陷分析报告）

• 正确获取缺陷数据（飞书 MQL / 本地文件 / 手动输入）
• 严重程度已按规则映射为 S1~S5 格式
• 模块分布、严重程度分布、趋势数据均已计算
• 遗留缺陷清单完整，包含风险评级
• 质量改进建议与数据挂钩，可操作
• 报告已输出到 docs/{项目名}-缺陷分析报告.md

模式 B（测试执行记录）

• 执行用例状态通过 get_workitem_brief 逐条获取（非 MQL 查询）
• 用例分级（P0/P1/P2）已从名称中正确提取
• 用例明细仅列失败/阻塞/未执行，通过用例不逐条展示
• 需求覆盖率分析已自动检测需求拆分文档
• 风险评级有数据支撑
• 报告已输出到 docs/{项目名}-测试执行记录.md

模式 C（综合测试报告）

• 空间全名已通过 search_project_info 获取，用于 MQL FROM 子句
• 缺陷统计通过 MQL 按关键词精确筛选，非视图直接总数
• 测试结论（通过/条件/不建议）有明确量化依据
• 遗留缺陷风险矩阵完整
• 章节 1~11 完整，无数据章节已注明原因
• 报告已输出到 docs/{项目名}-测试报告.md

参考资源

• 缺陷分析报告模板
• 测试执行记录模板
• 综合测试报告模板