ln-523-auto-test-planner

**路径：**文件路径（references/、../ln-*）均相对于此技能目录。

自动化测试规划器

**类型：**L3 Worker

根据风险测试方法和真实的手动测试结果，为 Story 创建测试任务，并提供全面的自动化测试覆盖（E2E/集成/单元）。

输入

输入	必需	来源	描述
storyId	是	参数、git 分支、kanban、用户	要处理的 Story

**解析：**Story 解析链。 **状态筛选：**待审核

目的与范围

• 创建全面的 Story 自动化测试任务
• 计算基于风险的优先级（影响 × 概率）
• 根据手动测试结果生成包含 11 个部分的测试计划
• 委派给 ln-301-task-creator（CREATE）或 ln-302-task-replanner（REPLAN）
• **不适用于：**手动测试、研究或编排

适用场景

• 实现工作完成，且必须规划自动化测试覆盖时使用
• Story 中所有实现任务的状态均为 Done
• ln-521 研究：有结果时使用；没有时生成最简内联研究
• ln-522 手动测试：有结果时使用；没有时标记为“按策略跳过”

**自动化：**在托管运行中支持 autoApprove: true，以跳过手动确认。

工作流

阶段 0：工具配置

**必须读取：**加载 references/environment_state_contract.md、references/storage_mode_detection.md 和 references/input_resolution_pattern.md

提取：task_provider = 任务管理 → Provider（linear | file）。

阶段 1：发现（自动）

1. **解析 storyId：**按照指南运行 Story 解析链（状态筛选：[待审核]）。
2. 从 docs/tasks/kanban_board.md 自动发现 Team ID（参见 CLAUDE.md 中的“配置自动发现”）

阶段 2：Story 与任务分析（不进行对话）

步骤 0：检查项目测试文件

1. 扫描与测试相关的文件：
   • tests/README.md（命令、设置、环境）
   • 测试配置（jest.config.js、vitest.config.ts、pytest.ini）
   • 现有测试结构（tests/、tests/ 目录）
   • 覆盖率配置（.coveragerc、coverage.json）
2. 提取：测试命令、框架、模式、覆盖率阈值
3. 确保测试规划符合项目惯例

步骤 1：加载研究和手动测试结果

1. 获取 Story（必须带有标签 "user-story"）：
   • 如果 task_provider = linear：get_issue(storyId) — 提取 Story.id（UUID，不是短 ID）
   • 如果 task_provider = file：Read story.md — 提取 Story 元数据
2. 加载研究评论（来自 ln-521）：“## 测试研究：{Feature}”
   • 如果 task_provider = linear：list_comments(issueId=storyId) → 查找匹配的评论
   • 如果 task_provider = file：Glob("docs/tasks/epics/*/stories/*/comments/*.md") → 查找匹配的评论
   • 如果找不到研究评论：根据 Story AC 和任务描述，生成 3–5 条关键测试领域要点（内联生成，不进行外部研究）。
3. 加载手动测试结果评论（来自 ln-522）：“## 手动测试结果”
   • 方法同上方的研究评论
   • 如果找不到手动测试结果：跳过手动测试覆盖分析。在输出中注明：'手动测试：按策略跳过（简化模式）。'
4. 解析各部分：AC 结果（PASS/FAIL）、边缘案例、错误处理、集成流程
5. 映射到测试设计：通过的 AC → E2E，边缘案例 → 单元测试，错误 → 错误处理，流程 → 集成测试

步骤 2：分析 Story 与任务

1. 解析 Story：目标、测试策略、技术说明
2. 获取所有子任务（状态 = Done）：
   • 如果 task_provider = linear：list_issues(parentId=Story.id, state="Done")
   • 如果 task_provider = file：Glob("docs/tasks/epics/*/stories/*/tasks/*.md") → 按 **Status:** Done 筛选
3. 分析每项任务：
   • 已实现的组件
   • 新增的业务逻辑
   • 创建的集成点
   • 条件分支（if/else/switch）
4. 确定需要测试的内容

阶段 3：手动测试结果的解析策略

流程： 查找包含「手动测试结果」标题的 Linear 评论 -> 验证格式版本 1.0 -> 使用正则表达式提取结构化部分（验收标准、按 AC 划分的测试结果、边缘案例、错误处理、集成测试）-> 验证（至少有 1 个 PASSED AC、AC 数量与 Story 一致、完整性检查）-> 将解析后的数据映射到测试设计结构

错误处理： 缺少评论 -> 使用备用方案（内联调研，或按阶段 2 的逻辑跳过）；缺少格式版本 -> WARNING（尝试使用旧版解析）；缺少必需部分 -> 使用备用方案；没有 PASSED AC -> ERROR（修复实现）

阶段 4：基于风险的测试规划（自动化）

必须阅读： 加载 references/risk_based_testing_guide.md，了解评分和效用门槛。
条件阅读：仅在规划完整测试策略或风险／效用决策不明确时，加载 references/risk_based_testing_methodology.md。

E2E 优先方法： 按业务风险（优先级 = 影响 x 概率）确定优先级，而非覆盖率指标。

工作流：

步骤 1：风险评估

根据手动测试为每个场景计算优先级：

Priority = Business Impact (1-5) x Probability (1-5)

决策标准：

• 优先级 ≥15 -> 必须测试
• 优先级 9-14 -> 若尚未覆盖，则应测试
• 优先级 <=8 -> 跳过（手动测试已足够）

步骤 2：E2E 测试选择（2-5 项）： 始终包含基准 2 项（正向 + 负向）+ 额外 0-3 项（仅限优先级 ≥15）

步骤 3：单元测试选择（0-15 项）： 默认 0 项。仅针对复杂业务逻辑添加测试（优先级 ≥15）：金融、安全、算法

步骤 4：集成测试选择： 默认 0 项。仅在存在 E2E 缺口且优先级 ≥15 时添加：回滚、并发、外部 API 错误

步骤 5：验证： 每项测试均符合效用标准（优先级 ≥15、置信度 ROI、行为性、预测性、具体性、非重复性）

阶段 5：测试任务生成（自动化）

按照 test_task_template.md 生成完整测试任务（11 个部分）：

第 1-7 部分： 上下文、风险矩阵、E2E／集成／单元测试（附优先级分数和理由）、覆盖率、DoD

第 8 部分： 需要修复的现有测试（分析实现任务中受影响的测试）

第 9 部分： 基础设施变更（软件包、Docker、配置——根据测试依赖确定）

第 10 部分： 文档更新（README、CHANGELOG、tests/README、配置文档）

第 11 部分： 旧版代码清理（不受支持的模式、向后兼容、死代码）

提供预览以供审核。

阶段 6：确认与委派

**步骤 1：**预览生成的测试计划（始终显示，以确保透明度）

**步骤 2：**确认逻辑：

• autoApprove: true -> 自动继续
• 手动运行 -> 提示用户输入“confirm”

**步骤 3：**检查是否存在现有测试任务

• IF task_provider = linear：list_issues(parentId=Story.id, label="tests")
• IF task_provider = file：Glob("docs/tasks/epics/*/stories/*/tasks/*.md") → 筛选包含 **Labels:** 且包含 tests 的文件

决策：

• 数量 = 0 -> 创建模式（步骤 4a）
• 数量 >= 1 -> 重新规划模式（步骤 4b）

步骤 4a：创建模式（如果数量 = 0）

托管委派序列：

1. 计算 childRunId = {parent_run_id}--ln-301--{storyId}
2. 计算 childSummaryArtifactPath = .hex-skills/runtime-artifacts/runs/{parent_run_id}/task-plan/ln-301--{storyId}.json
3. 在 .hex-skills/test-planning/ln-301--{storyId}_manifest.json 生成子清单
4. 使用两个传输输入启动 task-plan-worker-runtime
5. 在 PHASE_6_DELEGATE_TASK_PLAN 中检查点记录 child_run 元数据
6. 使用 --run-id 和 --summary-artifact-path 调用 ln-301-task-creator
7. 仅读取生成的子 task-plan 工件

传递给工作器：

• taskType、teamId、storyData（Story.id、标题、AC、Technical Notes、Context）
• researchFindings（来自 ln-521 评论）
• manualTestResults（来自 ln-522 评论）
• testPlan（e2eTests、integrationTests、unitTests、riskPriorityMatrix）
• infrastructureChanges、documentationUpdates、legacyCleanup

**工作器返回：**任务 URL + task-plan 工件

步骤 4b：重新规划模式（如果数量 >= 1）

托管委派序列：

1. 计算 childRunId = {parent_run_id}--ln-302--{storyId}
2. 计算 childSummaryArtifactPath = .hex-skills/runtime-artifacts/runs/{parent_run_id}/task-plan/ln-302--{storyId}.json
3. 在 .hex-skills/test-planning/ln-302--{storyId}_manifest.json 生成子清单
4. 使用两个传输输入启动 task-plan-worker-runtime
5. 在 PHASE_6_DELEGATE_TASK_PLAN 中检查点记录 child_run 元数据
6. 使用 --run-id 和 --summary-artifact-path 调用 ln-302-task-replanner
7. 仅读取生成的子 task-plan 工件

传递给工作器：

• 与创建模式相同的数据 + existingTaskIds

**工作器返回：**操作摘要 + 子 task-plan 工件

**步骤 5：**向调用方返回结构化摘要

---

运行时摘要工件

**必须阅读：**加载 references/test_planning_summary_contract.md、references/test_planning_worker_runtime_contract.md、references/task_plan_worker_runtime_contract.md

运行时配置：

• family：test-planning-worker
• worker：ln-523
• summary kind：test-planning-worker
• 协调器使用的有效负载字段：worker、status、warnings、test_task_id、test_task_url、coverage_summary、planned_scenarios

调用规则：

• 独立运行：省略 runId 和 summaryArtifactPath
• 托管运行：传递 runId 和准确的 summaryArtifactPath
• 始终在终止结果前写入经过验证的摘要

委派子工作器规则：

• 委派给 ln-301 或 ln-302 时，ln-523 将成为父运行时
• 委派前启动 task-plan-worker-runtime
• 在调用子 Skill 前检查点记录 child_run 元数据
• 仅使用子 task-plan 工件，绝不使用子工作器的自然语言输出

完成定义

已加载研究和手动测试结果：

• 找到研究评论“## Test Research: {Feature}”（来自 ln-521）
• 找到手动测试结果“## Manual Testing Results”（来自 ln-522）
• 至少有 1 项 AC 标记为 PASSED

已生成基于风险的测试计划：

• 已计算所有场景的风险优先级矩阵
• E2E 测试：基线正向 + 负向测试，仅在优先级 ≥15 时添加其他测试
• 集成测试：仅在 E2E 未覆盖且优先级 ≥15 时添加
• 单元测试：仅针对优先级 ≥15 的复杂业务逻辑
• 每项测试均符合全部 6 项实用性标准
• 不测试框架/库：每项测试仅验证我们的业务逻辑

测试任务说明已完成（11 个部分）：

• 按模板填写全部 11 个部分
• 包含风险优先级矩阵
• 说明每项超出基线 2 项的测试的理由

已执行工作者委派：

• CREATE MODE：通过 task-plan-worker-runtime 委派给 ln-301-task-creator
• REPLAN MODE：通过 task-plan-worker-runtime 委派给 ln-302-task-replanner
• 在委派前记录子运行元数据检查点
• 在最终摘要前使用子级 task-plan 成品
• 返回 Tracker Issue/Story URL

输出：

• CREATE MODE： Tracker Issue/Story URL + 确认信息
• REPLAN MODE： 操作摘要 + URL

参考文件

• 环境状态： references/environment_state_contract.md
• 存储模式操作： references/storage_mode_detection.md
• 基于风险的测试约定： references/risk_based_testing_guide.md
• 可选方法目录： references/risk_based_testing_methodology.md
• 自动发现模式： references/auto_discovery_pattern.md
• 测试任务模板： references/templates/test_task_template.md（工作者 ln-301/ln-302 通过 Template Loading 加载）
• 测试示例： references/risk_based_testing_examples.md
• 必须阅读： 加载 references/research_tool_fallback.md

关键规则

• 优先使用手动测试结果： 有可用的 ln-522 手动测试结果时应使用。缺少结果时（简化模式），生成最精简的内联研究，并标记为跳过手动测试
• E2E 优先，而非单元测试优先： 基线始终为 2 项 E2E 测试（正向 + 负向）；仅在优先级 ≥ 15 时添加单元/集成测试
• 不测试框架： 每项测试都必须验证我们的业务逻辑；绝不测试库/框架行为
• 严格执行实用性标准： 每项超出基线的测试都必须符合全部 6 项实用性标准（参见 risk_based_testing_guide.md）
• 委派，不创建： 任务创建须交由 ln-301/ln-302 工作者完成；此技能仅生成计划
• 仅使用受管子运行： 委派给 ln-301/ln-302 的父子级任务必须使用 task-plan-worker-runtime、确定性的子级 runId、准确的子级 summaryArtifactPath，并且只能使用成品

最佳实践

最小可行测试： 从基线 E2E 测试（正向 + 负向）开始。每项额外测试都必须符合全部 6 项实用性标准。

基于风险的测试： 按业务影响 x 发生概率确定优先级。基于实际手动测试结果优先采用 E2E。优先级 ≥15 的场景必须由测试覆盖。

基于预期的测试： 对于确定性测试，使用 diff 比较实际结果与预期结果。必须阅读： 加载 ../ln-522-manual-tester/SKILL.md——“Test Design Principles”章节。

---

版本： 1.0.0 最后更新： 2026-01-15