shenjingnan 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
你的任务
按以下四个阶段执行，每个阶段输出清晰的中文报告。
阶段一：改动分析
过滤核心逻辑文件：从改动文件列表中排除以下非逻辑文件类型：
- 配置文件：
*.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__/**
保留以下类型的文件作为核心逻辑文件：
src/web/**下的组件、页面、hooks、store、工具函数src/server/**下的服务、路由、控制器、中间件、处理器src/下各模块的源码逻辑文件
- 配置文件：
识别功能点：对每个核心逻辑文件，结合 git diff 的实际改动内容，分析其涉及的功能维度：
- 页面/路由：涉及哪个页面或路由（如
/dashboard） - UI 组件：涉及哪些 UI 组件（如 MCP 工具表格、对话框、表单等）
- 交互行为：涉及的点击、输入、切换、拖拽等用户操作
- 数据流：涉及的数据请求、状态变更、事件处理
- 视觉呈现：涉及的新增/修改的 UI 元素、样式变化
- 页面/路由：涉及哪个页面或路由（如
输出改动分析报告，格式如下：
=== 改动分析报告 === 核心逻辑文件（共 N 个）： 1. src/web/pages/Dashboard.tsx - 涉及页面：Dashboard 页面 - 涉及功能点：新增状态卡片 X、修改表格列 Y 排除的非逻辑文件（共 M 个）： - package.json（依赖变更） ...
阶段二：覆盖匹配
读取所有现有 e2e 测试用例：遍历
tests/e2e/下每个子目录中的test.md文件，提取每个用例覆盖的功能点关键词。建立映射关系：将阶段一识别的功能点与现有测试用例进行匹配。匹配规则：
- 精确匹配：测试用例名称或步骤明确提及了改动的功能点
- 关联匹配：测试用例覆盖了改动所在的页面/组件区域，虽然未直接测试该具体改动，但执行路径会经过相关代码
- 无匹配：改动涉及的功能点没有任何测试用例覆盖
输出覆盖匹配报告，格式如下：
=== 覆盖匹配报告 === 已覆盖的功能点： | 功能点 | 匹配测试用例 | 匹配类型 | |--------|-------------|---------| | Dashboard 页面加载 | 测试Dashboard页面加载 | 精确匹配 | 缺少覆盖的功能点： | 功能点 | 涉及文件 | 风险等级 | |--------|---------|---------| | 新增的 XXX 功能 | src/web/components/XXX.tsx | 高 | 覆盖率总结： - 总功能点数：N - 已覆盖：M（X%） - 未覆盖：K（Y%）风险等级判定标准：
- 高：涉及新的用户可见功能或交互流程变更
- 中：涉及已有功能的逻辑修改或边界条件变化
- 低：涉及内部实现优化、重构、错误处理改进
阶段三：结论与建议
根据覆盖匹配结果输出结论：
如果全部覆盖（覆盖率 100%）：
=== 结论 ✅ ===
当前分支的所有改动均有对应的 e2e 测试用例覆盖：
[列出所有匹配关系]
建议：可以直接提交 PR，或在提交前运行 /e2e 执行全量测试验证。
如果存在未覆盖项：
=== 结论 ⚠️ ===
当前分支存在 N 个缺少 e2e 覆盖的功能点：
[高优先级]
1. [功能点描述] — 涉及文件：xxx
[中优先级]
2. ...
是否需要为这些缺失的功能点创建新的 e2e 测试用例？
回复"是"将继续创建，回复"否"则仅保留上述报告。
特殊情况处理：
- 如果当前分支与 main 无差异（无改动），直接提示用户并退出
- 如果改动仅涉及非逻辑文件（纯配置、文档等），提示用户无需 e2e 覆盖并退出
阶段四：创建测试用例（仅在用户确认后执行）
当用户确认需要补充测试用例时：
确定要创建的测试用例列表：按风险等级从高到低排列。
为每个缺失的功能点创建 e2e 测试用例，遵循以下规范：
a. 目录命名：使用中文
测试<功能描述>格式，例如：tests/e2e/测试新功能名称/
b. test.md 格式：
## 前置条件（可选） 如有特殊前置条件在此说明 ## 测试步骤 1. 打开页面 http://localhost:9999/dashboard 2. 等待页面加载完成 3. [具体的操作步骤] 4. 截图（关键状态描述） 5. [验证断言]c. 编写原则：
- 每个步骤是单一、可执行的原子操作
- 使用元素的可辨识特征定位（title、placeholder、文本内容、图标描述）
- 关键状态变化后必须截图
- 必须包含明确的验证断言
- 如需清理测试数据，在最后一步说明
d. 参考现有用例的风格：参考已有的测试用例写法保持一致
输出创建结果报告：
=== 测试用例创建报告 === 已创建以下 e2e 测试用例： 1. tests/e2e/测试XXX/test.md - 覆盖功能点：... - 步骤数：N 创建完成后可使用以下命令执行： /e2e tests/e2e/测试XXX
注意事项
- 本技能只进行分析和测试用例创建，不执行测试。执行测试请使用
/e2e命令。 - 所有输出使用中文。
- 分析时重点关注用户可感知的功能变化，不过度追求理论上的完美覆盖。