name: 解决失败的端到端测试 description: 分析一个失败的端到端测试，修复根本问题，并验证修复。在 /test-e2e 报告失败后使用。 argument-hint: [测试结果-json] allowed-tools: 读取，写入，编辑，Bash，Glob，Grep

解决失败的端到端测试

分析一个失败的端到端测试，修复根本问题，并验证修复。

变量

test_result: $ARGUMENTS - 来自 /test-e2e 命令的 JSON 对象，包含失败的测试详情

输入格式

期望来自 /test-e2e 命令的 JSON 对象：

{
  "test_name": "基本查询执行",
  "status": "失败",
  "screenshots": [
    "screenshots/01_初始状态.png",
    "screenshots/02_查询输入.png"
  ],
  "error": "步骤 8 失败：5 秒内未出现结果"
}

指令

1. 分析端到端失败

审查测试结果：

test_name: 哪个用户旅程失败
error: 失败的具体步骤
screenshots: 失败前状态的视觉证据

提取关键信息：

哪个步骤号失败
预期行为是什么
实际发生了什么
来自截图的视觉线索

2. 定位测试规范

阅读原始测试规范以理解：

完整的用户故事
所有测试步骤
成功标准
失败步骤的上下文

3. 分析截图

审查捕获的截图以：

理解失败时的应用状态
识别视觉异常
确定 UI 元素是否存在/缺失
检查屏幕上的错误消息

4. 识别根本原因

常见的端到端失败原因：

症状	可能原因
元素未找到	选择器改变，加载缓慢
错误文本	逻辑错误，数据问题
超时	性能问题，缺失元素
意外重定向	认证问题，错误状态
缺失元素	组件未渲染

5. 修复问题

基于根本原因应用修复：

UI 问题: 修复组件渲染
逻辑问题: 修复业务逻辑
时序问题: 添加适当的等待/加载状态
数据问题: 修复数据处理

重要: 修复应用程序，而不是测试（除非测试确实不正确）。

6. 重新运行端到端测试

再次执行原始端到端测试：

/test-e2e {原始测试文件}

成功标准: 测试状态为“通过”

7. 验证无回归

运行相关的端到端测试以确保修复不会破坏其他流程。

输出格式

报告您的解决方案：

## 端到端解决方案完成

### 失败分析
- **测试**: {test_name}
- **失败步骤**: [步骤号和描述]
- **根本原因**: [导致失败的原因]
- **截图证据**: [来自截图的观察]

### 应用修复
- **修改的文件**: [文件列表]
- **更改摘要**: [简要描述]
- **修复类型**: [UI/逻辑/性能/数据]

### 验证
- **端到端测试**: 通过
- **相关测试**: 通过/失败
- **新截图**: [验证截图路径]

### 笔记
[任何观察或建议]

重试逻辑

如果修复不起作用：

查看新截图以获取线索
考虑时序/异步问题
检查环境特定问题
应用替代修复

最多尝试 2 次，然后升级（端到端测试较慢）。

与闭环集成

此命令是端到端的解决阶段：

/test-e2e {spec} → [失败 JSON] → /resolve-failed-e2e-test {result} → /test-e2e
                                                                            ↓
                                                                     [验证修复]