e2e-varify

name	e2e-varify
description	E2E测试设计完整性检查与完善。对测试实现分析报告进行深度检查，包括变更点覆盖分析、外部依赖异常场景、测试数据设计完善。当用户说"/e2e-varify"、"完善测试设计"、"验证测试用例"、"测试用例审查"，或需要将测试设计草稿打造成完善的可指导测试代码落地的文档时使用此技能。

用户输入

$ARGUMENTS

在继续之前, 你必须考虑用户输入(如果不为空).

概述

执行 E2E 测试设计的完整性检查和完善工作流，作为 e2e-design 的下游动作。

调用场景：

• 下游调用（推荐）：在 e2e-design 生成 e2e-impl-design.md 后自动执行
• 独立调用：直接执行测试设计完善（需要已有 e2e-impl-design.md）

输入要求：

• spec.md：功能规范文档
• design.md：设计文档
• e2e-test.md：黑盒测试用例文档
• e2e-impl-design.md：测试实现分析报告（e2e-design 输出）

输出：

• 更新后的 e2e-impl-design.md：完善的测试实现分析报告

执行流程

1. [ ] 设置环境

1. 判断操作系统：Windows 或 Linux
2. 运行前置检查脚本：
   • Windows: scripts/powershell/check-prerequisites.ps1 --json --require-e2e-impl-design
   • Linux: scripts/bash/check-prerequisites.sh --json --require-e2e-impl-design
3. 解析输出：
   • 提取 FEATURE_DIR（特性目录绝对路径）
   • 提取 SPEC_FILE（规范文件路径）
   • 提取 DESIGN_FILE（设计文件路径）
   • 提取 E2E_TEST_FILE（黑盒测试用例文件路径）
   • 提取 E2E_IMPL_DESIGN_FILE（测试实现分析报告路径）
   • 提取 AVAILABLE_DOCS（可用文档列表）

重要：所有路径必须是绝对路径。

2. [ ] 验证前置文件

验证以下必需文件是否存在：

1. 检查规范文件：

   • {FEATURE_DIR}/spec.md 是否存在
   • 如果不存在：错误 "规范文件不存在，请先执行 /specify"

2. 检查设计文件：

   • {FEATURE_DIR}/design.md 是否存在
   • 如果不存在：错误 "设计文件不存在，请先执行 /design"

3. 检查测试用例文件：

   • {FEATURE_DIR}/e2e-test.md 是否存在
   • 如果不存在：错误 "黑盒测试用例文件不存在，请先执行 /e2e-specify"

4. 检查测试实现分析报告：

   • {FEATURE_DIR}/e2e-impl-design.md 是否存在
   • 如果不存在：错误 "测试实现分析报告不存在，请先执行 /e2e-design"

5. 报告验证结果：

   • 所有文件存在：继续执行步骤3
   • 任何文件缺失：终止流程并报错

3. [ ] 加载上下文文档

加载用于测试设计完善的上下文文档：

必需文档：

1. spec.md：读取用户故事、功能需求、验收场景
2. design.md：读取架构设计、详细设计、接口定义、数据结构
3. e2e-test.md：读取所有黑盒测试用例（Given-When-Then 格式）
4. e2e-impl-design.md：读取测试实现分析报告

可选文档（按优先级加载）：

1. baseline 文档：

   • baseline/code-structure.md：现有代码结构
   • baseline/existing-apis.md：现有接口定义
   • baseline/call-graph.md：调用链路（用于确定外部依赖）
   • baseline/detailed-design.md：现有架构设计

2. 存量测试代码：

   • 搜索现有测试目录（如 tests/、test/）
   • 查找类似功能的测试实现
   • 提取测试模式、异常场景处理、测试数据构造方法

加载策略：

• 每个文档独立容错，失败不中断流程
• 记录成功加载的文档列表
• 标注缺失的文档

4. [ ] 执行变更点覆盖分析

1. 识别需求变更点：

   • 阅读 spec.md，提取本次需求变更内容
   • 与 design.md 对照，识别受影响的模块和接口
   • 与 baseline 对照，识别新增或修改的功能点

2. 生成变更点清单： 从本次需求变更内容的角度，梳理变更点清单，格式如下：

   ## 变更点清单
   
   | 变更点编号 | 变更描述 | 影响模块 | 影响接口 |
   | ---------- | -------- | -------- | -------- |
   | CP-001     | ...      | ...      | ...      |
   | CP-002     | ...      | ...      | ...      |
   

3. 生成用例覆盖表： 查看是否所有变更点在 e2e-test.md 和 e2e-impl-design.md 中都有覆盖，输出对应表：

   ## 变更点用例覆盖表
   
   | 变更点 | 用例编号 | 覆盖状态 | 备注 |
   | ------ | -------- | -------- | ---- |
   | CP-001 | TC-001   | ✅       |      |
   | CP-002 | TC-002   | ✅       |      |
   | CP-003 | -        | ❌       | 需补充 |
   

5. [ ] 执行深度用例设计

应用以下规则设计用例，将设计的用例及时回写到 e2e-impl-design.md 文档中：

规则 1：参考存量测试设计核心模块

1. 查找存量测试代码：

   • 搜索测试目录（如 tests/、test/、*_test.go、*_test.py 等）
   • 查找针对核心模块的测试用例

2. 识别核心测试场景：

   • 比如：存量用例中有大量针对 reconcile 的测试
   • 判断：本变更是否可以从 reconcile 进行测试
   • 补充：在 e2e-impl-design.md 中添加相应的测试用例

3. 补充测试用例： 将识别出的核心模块测试用例添加到 e2e-impl-design.md 的用例实现映射表中。

规则 2：分析外部依赖异常场景

1. 提取外部交互点： 分析 e2e-impl-design.md 中的"外部依赖详细分析"章节，找出每个用例与外部系统进行交互的地方。

2. 设计异常场景用例： 针对每个外部依赖，考虑以下异常情况：

   a) HTTP 接口交互：

   • 不同的返回值区间（2xx、3xx、4xx、5xx）
   • 只要处理不一样就需要有对应的用例设计
   • 超时场景
   • 无返回/连接中断场景
   • 接口数据超出边界情况

   b) 数据库 IO 操作：

   • IO 操作失败时的多种返回
   • 连接失败
   • 查询超时
   • 事务回滚
   • 数据冲突

   c) 消息队列交互：

   • 消息发送失败
   • 消息消费超时
   • 消息格式错误
   • 队列满/不可用

   d) 文件系统操作：

   • 文件不存在
   • 权限不足
   • 磁盘空间不足
   • 读写失败

3. 补充异常用例： 将设计出的异常场景用例添加到 e2e-impl-design.md 中，并更新变更点覆盖表。

规则 3：设计测试数据

1. 分析测试数据需求： 逐个遍历测试用例条目的测试数据，列出需要的数据清单。

2. 构造测试数据：

   • 输入数据：参数、配置、请求体
   • Fake 数据：数据库记录、消息内容、外部服务响应

3. 参考存量测试数据： 遇到不确定的地方，先查找存量代码库中测试代码是否有类似的用例，然后根据这些用例构造方式进行数据构造。

4. 标注风险点： 最终每个数据需要给一个检查建议，对于可能构造错误的数据标注出：【必须关注】

5. 补充到文档： 构造数据的设计内容，补充到 e2e-impl-design.md 文档中，格式如下：

   ### TC-XXX: [用例名称]
   
   **测试数据**：
   - 输入数据：
     ```json
     {具体数据}
   

   • [必须关注] 数据有效性说明
   • Fake 数据：
     • 数据库记录：

       {具体数据}
       

     • 外部服务响应：

       {具体数据}
       

6. [ ] 更新测试实现分析报告

将完善的内容更新到 e2e-impl-design.md 文档中：

1. 添加新章节：

   • 变更点清单
   • 变更点用例覆盖表

2. 更新现有章节：

   • 用例实现映射表：补充新增的用例
   • 入口函数详细分析：补充新增的入口函数
   • 外部依赖详细分析：补充异常场景分析
   • 测试数据清单：补充具体的测试数据设计
   • 验证点详细清单：补充异常场景的验证点

3. 更新覆盖表： 确认是否所有变更点都有对应的测试用例覆盖

7. [ ] 验证完善结果

1. 检查覆盖完整性：

   • 所有变更点是否都有对应的测试用例
   • 每个外部依赖是否都有异常场景测试
   • 每个用例是否有完整的测试数据设计

2. 生成完善报告： 输出以下统计信息：

   • 原始用例数量
   • 新增用例数量
   • 新增异常场景数量
   • 新增测试数据项数量
   • 变更点覆盖率

3. 输出风险清单： 列出所有标注为 【必须关注】 的测试数据项，提示实施时重点关注。

8. [ ] 报告完成情况

输出完成报告，包括：

• 更新文档：

  • e2e-impl-design.md 路径

• 完善统计：

  • 原始用例数量
  • 新增用例数量（按类型分组：正常场景/异常场景）
  • 变更点覆盖率
  • 测试数据完整性评估

• 风险提示：

  • 【必须关注】的测试数据项列表
  • 测试实施建议

• 下一步建议：

  • 如果测试设计完整：建议执行 /tasks 生成任务列表
  • 如果仍有遗漏：建议手动补充后再次执行 /e2e-varify

错误处理

1. 前置文件缺失：

   • 明确指出缺失的文件
   • 提供解决建议（执行相应的前置命令）
   • 终止流程

2. 变更点覆盖不全：

   • 输出未覆盖的变更点列表
   • 提示需要补充的用例类型
   • 不终止流程，但记录警告

3. 测试数据构造失败：

   • 记录无法构造数据的用例
   • 提供替代方案或手动补充建议
   • 标注为 【必须关注】

通用指南

快速指南

• 专注于测试设计的完整性，不涉及测试代码编写
• 基于测试实现分析报告进行深度细化
• 参考存量测试设计，避免重复劳动
• 重点关注外部依赖的异常场景
• 测试数据要具体可用，无需补充

关键原则

1. 变更点覆盖：

   • 确保所有需求变更点都有对应的测试用例
   • 优先覆盖核心功能和关键路径
   • 补充容易被忽略的边界场景

2. 异常场景设计：

   • 每个外部依赖都要考虑异常场景
   • 覆盖不同的失败模式和错误返回
   • 考虑超时、中断、边界等特殊情况

3. 测试数据具体化：

   • 数据要具体可用，无需补充
   • 考虑边界值和特殊值
   • 标注构造风险点

4. 复用存量设计：

   • 参考存量测试的核心模块测试
   • 复用测试数据构造方法
   • 遵守项目的测试约定

建议后续步骤

测试设计完善后，可继续执行：

• tasks：重新生成任务列表，确保测试用例对应的实施任务完整
• implement：开始功能实施（包含测试实施）