shenjingnan/e2e-coverage-analyzer

E2E 覆盖率分析器

分析当前分支相对于 main 的改动，评估 tests/e2e/ 中现有测试用例是否足以覆盖改动涉及的功能点。

上下文

• 当前分支: !git branch --show-current
• 分叉点 commit: !git merge-base main HEAD
• 改动文件列表: !git --no-pager diff --name-only main...HEAD
• 改动内容摘要（统计）: !git --no-pager diff --stat main...HEAD
• 改动详细内容: !git --no-pager diff main...HEAD

现有 e2e 测试用例清单

!find tests/e2e -maxdepth 1 -type d ! -path tests/e2e | sort

你的任务

按以下四个阶段执行，每个阶段输出清晰的中文报告。

---

阶段一：改动分析

1. 过滤核心逻辑文件：从改动文件列表中排除以下非逻辑文件类型：

   • 配置文件：*.config.*, *.env*, tsconfig*.json, .eslintrc*, .prettierrc*
   • 类型定义文件：*.d.ts, types/*.ts, interfaces/*.ts
   • 文档和说明文件：*.md, CHANGELOG*, LICENSE*
   • 锁定文件：package-lock.json, pnpm-lock.yaml, yarn.lock
   • CI/CD 配置：.github/**, .gitlab-ci*, Dockerfile*, docker-compose*
   • 测试文件本身：**/*.test.ts, **/*.spec.ts, tests/**, __tests__/**

   保留以下类型的文件作为核心逻辑文件：

   • apps/frontend/src/** 下的组件、页面、hooks、store、工具函数
   • apps/backend/** 下的服务、路由、控制器、中间件、处理器
   • packages/ 下各包的源码逻辑文件

2. 识别功能点：对每个核心逻辑文件，结合 git diff 的实际改动内容，分析其涉及的功能维度：

   • 页面/路由：涉及哪个页面或路由（如 /dashboard）
   • UI 组件：涉及哪些 UI 组件（如 MCP 工具表格、对话框、表单等）
   • 交互行为：涉及的点击、输入、切换、拖拽等用户操作
   • 数据流：涉及的数据请求、状态变更、事件处理
   • 视觉呈现：涉及的新增/修改的 UI 元素、样式变化

3. 输出改动分析报告，格式如下：

   === 改动分析报告 ===
   
   核心逻辑文件（共 N 个）：
   1. apps/frontend/src/pages/Dashboard.tsx
      - 涉及页面：Dashboard 页面
      - 涉及功能点：新增状态卡片 X、修改表格列 Y
   
   排除的非逻辑文件（共 M 个）：
   - package.json（依赖变更）
   ...
   

---

阶段二：覆盖匹配

1. 读取所有现有 e2e 测试用例：遍历 tests/e2e/ 下每个子目录中的 test.md 文件，提取每个用例覆盖的功能点关键词。

2. 建立映射关系：将阶段一识别的功能点与现有测试用例进行匹配。匹配规则：

   • 精确匹配：测试用例名称或步骤明确提及了改动的功能点
   • 关联匹配：测试用例覆盖了改动所在的页面/组件区域，虽然未直接测试该具体改动，但执行路径会经过相关代码
   • 无匹配：改动涉及的功能点没有任何测试用例覆盖

3. 输出覆盖匹配报告，格式如下：

   === 覆盖匹配报告 ===
   
   已覆盖的功能点：
   | 功能点 | 匹配测试用例 | 匹配类型 |
   |--------|-------------|---------|
   | Dashboard 页面加载 | 测试Dashboard页面加载 | 精确匹配 |
   
   缺少覆盖的功能点：
   | 功能点 | 涉及文件 | 风险等级 |
   |--------|---------|---------|
   | 新增的 XXX 功能 | apps/frontend/src/components/XXX.tsx | 高 |
   
   覆盖率总结：
   - 总功能点数：N
   - 已覆盖：M（X%）
   - 未覆盖：K（Y%）
   

   风险等级判定标准：

   • 高：涉及新的用户可见功能或交互流程变更
   • 中：涉及已有功能的逻辑修改或边界条件变化
   • 低：涉及内部实现优化、重构、错误处理改进

---

阶段三：结论与建议

根据覆盖匹配结果输出结论：

如果全部覆盖（覆盖率 100%）：

=== 结论 ✅ ===

当前分支的所有改动均有对应的 e2e 测试用例覆盖：

[列出所有匹配关系]

建议：可以直接提交 PR，或在提交前运行 /e2e 执行全量测试验证。

如果存在未覆盖项：

=== 结论 ⚠️ ===

当前分支存在 N 个缺少 e2e 覆盖的功能点：

[高优先级]
1. [功能点描述] — 涉及文件：xxx

[中优先级]
2. ...

是否需要为这些缺失的功能点创建新的 e2e 测试用例？
回复"是"将继续创建，回复"否"则仅保留上述报告。

特殊情况处理：

• 如果当前分支与 main 无差异（无改动），直接提示用户并退出
• 如果改动仅涉及非逻辑文件（纯配置、文档等），提示用户无需 e2e 覆盖并退出

---

阶段四：创建测试用例（仅在用户确认后执行）

当用户确认需要补充测试用例时：

1. 确定要创建的测试用例列表：按风险等级从高到低排列。

2. 为每个缺失的功能点创建 e2e 测试用例，遵循以下规范：

   a. 目录命名：使用中文 测试<功能描述> 格式，例如：

   • tests/e2e/测试新功能名称/

   b. test.md 格式：

   ## 前置条件（可选）
   如有特殊前置条件在此说明
   
   ## 测试步骤
   1. 打开页面 http://localhost:9999/dashboard
   2. 等待页面加载完成
   3. [具体的操作步骤]
   4. 截图（关键状态描述）
   5. [验证断言]
   

   c. 编写原则：

   • 每个步骤是单一、可执行的原子操作
   • 使用元素的可辨识特征定位（title、placeholder、文本内容、图标描述）
   • 关键状态变化后必须截图
   • 必须包含明确的验证断言
   • 如需清理测试数据，在最后一步说明

   d. 参考现有用例的风格：参考已有的测试用例写法保持一致

3. 输出创建结果报告：

   === 测试用例创建报告 ===
   
   已创建以下 e2e 测试用例：
   
   1. tests/e2e/测试XXX/test.md
      - 覆盖功能点：...
      - 步骤数：N
   
   创建完成后可使用以下命令执行：
   /e2e tests/e2e/测试XXX
   

注意事项

• 本技能只进行分析和测试用例创建，不执行测试。执行测试请使用 /e2e 命令。
• 所有输出使用中文。
• 分析时重点关注用户可感知的功能变化，不过度追求理论上的完美覆盖。