Automated Test Planner

自动化测试规划器

Creates Story test task with comprehensive automated test coverage (E2E/Integration/Unit) based on Risk-Based Testing methodology and REAL manual testing results.

基于基于风险的测试方法论和实际手动测试结果，创建具备全面自动化测试覆盖（E2E/集成/单元测试）的Story测试任务。

Purpose & Scope

目的与范围

Create comprehensive test task for Story automation
Calculate risk-based priorities (Impact × Probability)
Generate 11-section test plan from manual test results
Delegate to ln-301-task-creator (CREATE) or ln-302-task-replanner (REPLAN)
NOT for: manual testing (ln-512), research (ln-511), orchestration (ln-510)

创建具备全面自动化测试覆盖的Story测试任务
计算基于风险的测试优先级（影响 × 概率）
生成基于手动测试结果的11节测试计划
委派任务至ln-301-task-creator（创建模式）或ln-302-task-replanner（重规划模式）
不适用场景：手动测试（ln-512）、研究（ln-511）、编排（ln-510）

When to Use This Skill

何时使用该技能

This skill should be used when:

Invoked by ln-510-test-planner after ln-511 research and ln-512 manual testing
All implementation tasks in Story are Done
Manual testing results documented in Linear comment (from ln-512)
Research findings available in Linear comment (from ln-511)

Prerequisites:

All implementation Tasks in Story status = Done
ln-511-test-researcher completed (research comment exists)
ln-512-manual-tester completed (manual test results in Linear comment)

Automation: Supports

autoApprove: true

(default when invoked by ln-510) to skip manual confirmation.

应在以下场景使用本技能：

由ln-510-test-planner调用，且在ln-511研究和ln-512手动测试完成之后
Story中的所有实现任务均已完成
手动测试结果已记录在Linear评论中（来自ln-512）
研究结果已在Linear评论中可用（来自ln-511）

前置条件：

Story中的所有实现任务状态 = 已完成
ln-511-test-researcher已完成（存在研究评论）
ln-512-manual-tester已完成（手动测试结果在Linear评论中）

自动化支持： 支持

autoApprove: true

（由ln-510调用时默认启用），可跳过手动确认。

When NOT to Use

何时不使用

Do NOT use if:

Manual testing NOT completed → Wait for ln-512
Research NOT completed → Wait for ln-511
Implementation tasks NOT all Done → Complete impl tasks first

请勿在以下场景使用：

手动测试未完成 → 等待ln-512完成
研究未完成 → 等待ln-511完成
实现任务未全部完成 → 先完成所有实现任务

Workflow

工作流程

Phase 1: Discovery (Automated)

阶段1：自动发现

Auto-discovers Team ID from

docs/tasks/kanban_board.md

(see CLAUDE.md "Configuration Auto-Discovery").

Input: Story ID from orchestrator (ln-510)

从

docs/tasks/kanban_board.md

自动发现团队ID（参见CLAUDE.md中的“配置自动发现”）。

输入： 来自编排器（ln-510）的Story ID

Phase 2: Story + Tasks Analysis (NO Dialog)

阶段2：Story与任务分析（无交互）

Step 0: Study Project Test Files

Scan for test-related files:
- tests/README.md (commands, setup, environment)
- Test configs (jest.config.js, vitest.config.ts, pytest.ini)
- Existing test structure (tests/, tests/ directories)
- Coverage config (.coveragerc, coverage.json)
Extract: test commands, framework, patterns, coverage thresholds
Ensures test planning aligns with project practices

Step 1: Load Research and Manual Test Results

Fetch Story from Linear (must have label "user-story")
Extract Story.id (UUID) - Use UUID, NOT short ID (required for Linear API)
Load research comment (from ln-511): "## Test Research: {Feature}"
Load manual test results comment (from ln-512): "## Manual Testing Results"
- If not found → ERROR: Run ln-510-test-planner pipeline first
Parse sections: AC results (PASS/FAIL), Edge Cases, Error Handling, Integration flows
Map to test design: PASSED AC → E2E, Edge cases → Unit, Errors → Error handling, Flows → Integration

Step 2: Analyze Story + Tasks

Parse Story: Goal, Test Strategy, Technical Notes
Fetch all child Tasks (parentId = Story.id, status = Done) from Linear
Analyze each Task:
- Components implemented
- Business logic added
- Integration points created
- Conditional branches (if/else/switch)
Identify what needs testing

步骤0：研究项目测试文件

扫描测试相关文件：
- tests/README.md（命令、设置、环境）
- 测试配置文件（jest.config.js、vitest.config.ts、pytest.ini）
- 现有测试结构（tests/、tests/目录）
- 覆盖率配置文件（.coveragerc、coverage.json）
提取：测试命令、框架、模式、覆盖率阈值
确保测试规划与项目实践保持一致

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

从Linear获取Story（必须带有“user-story”标签）
提取Story.id（UUID）- 使用UUID，而非短ID（Linear API要求）
加载来自ln-511的研究评论："## Test Research: {Feature}"
加载来自ln-512的手动测试结果评论："## Manual Testing Results"
- 若未找到 → 错误：先运行ln-510-test-planner流水线
解析各部分：AC结果（通过/失败）、边缘情况、错误处理、集成流程
映射至测试设计：通过的AC → E2E测试，边缘情况 → 单元测试，错误场景 → 错误处理测试，流程 → 集成测试

步骤2：分析Story与任务

解析Story：目标、测试策略、技术说明
从Linear获取所有子任务（parentId = Story.id，状态 = 已完成）
分析每个任务：
- 已实现的组件
- 新增的业务逻辑
- 创建的集成点
- 条件分支（if/else/switch）
确定需要测试的内容

Phase 3: Parsing Strategy for Manual Test Results

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

Process: Locate Linear comment with "Manual Testing Results" header → Verify Format Version 1.0 → Extract structured sections (Acceptance Criteria, Test Results by AC, Edge Cases, Error Handling, Integration Testing) using regex → Validate (at least 1 PASSED AC, AC count matches Story, completeness check) → Map parsed data to test design structure

Error Handling: Missing comment → ERROR (run ln-512 first), Missing format version → WARNING (try legacy parsing), Required section missing → ERROR (re-run ln-512), No PASSED AC → ERROR (fix implementation)

流程： 定位带有“Manual Testing Results”标题的Linear评论 → 验证格式版本1.0 → 使用正则表达式提取结构化部分（验收标准、按AC分类的测试结果、边缘情况、错误处理、集成测试） → 验证（至少1个通过的AC，AC数量与Story匹配，完整性检查） → 将解析后的数据映射至测试设计结构

错误处理： 缺少评论 → 错误（先运行ln-512），缺少格式版本 → 警告（尝试旧版解析），缺少必填部分 → 错误（重新运行ln-512），无通过的AC → 错误（修复实现）

Phase 4: Risk-Based Test Planning (Automated)

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

Reference: See

references/risk_based_testing_guide.md

for complete methodology.

E2E-First Approach: Prioritize by business risk (Priority = Impact x Probability), not coverage metrics.

Workflow:

Step 1: Risk Assessment

Calculate Priority for each scenario from manual testing:

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

Decision Criteria:

Priority >=15 → MUST test
Priority 9-14 → SHOULD test if not covered
Priority <=8 → SKIP (manual testing sufficient)

Step 2: E2E Test Selection (2-5): Baseline 2 (positive + negative) ALWAYS + 0-3 additional (Priority >=15 only)

Step 3: Unit Test Selection (0-15): DEFAULT 0. Add ONLY for complex business logic (Priority >=15): financial, security, algorithms

Step 4: Integration Test Selection (0-8): DEFAULT 0. Add ONLY if E2E gaps AND Priority >=15: rollback, concurrency, external API errors

Step 5: Validation: Limits 2-28 total (realistic goal: 2-7). Auto-trim if >7 (keep 2 baseline + top 5 by Priority)

参考： 完整方法论请参见

references/risk_based_testing_guide.md

。

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

工作流程：

步骤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-8个）： 默认0个。仅当E2E测试存在缺口且优先级>=15时添加：回滚、并发、外部API错误场景

步骤5：验证： 限制总测试数为2-28个（合理目标：2-7个）。若超过7个则自动裁剪（保留2个基线测试 + 优先级最高的5个场景）

Phase 5: Test Task Generation (Automated)

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

Generates complete test task per

test_task_template.md

(11 sections):

Sections 1-7: Context, Risk Matrix, E2E/Integration/Unit Tests (with Priority scores + justifications), Coverage, DoD

Section 8: Existing Tests to Fix (analysis of affected tests from implementation tasks)

Section 9: Infrastructure Changes (packages, Docker, configs - based on test dependencies)

Section 10: Documentation Updates (README, CHANGELOG, tests/README, config docs)

Section 11: Legacy Code Cleanup (deprecated patterns, backward compat, dead code)

Shows preview for review.

根据

test_task_template.md

生成完整的测试任务（11节）：

第1-7节： 上下文、风险矩阵、E2E/集成/单元测试（含优先级分数+理由）、覆盖率、完成定义（DoD）

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

第9节： 基础设施变更（依赖的包、Docker、配置）

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

第11节： 遗留代码清理（已弃用模式、向后兼容、死代码）

显示预览供审核。

Phase 6: Confirmation & Delegation

阶段6：确认与委派

Step 1: Preview generated test plan (always displayed for transparency)

Step 2: Confirmation logic:

autoApprove: true (default from ln-510) → proceed automatically
Manual run → prompt user to type "confirm"

Step 3: Check for existing test task

Query Linear:

list_issues(parentId=Story.id, labels=["tests"])

Decision:

Count = 0 → CREATE MODE (Step 4a)
Count >= 1 → REPLAN MODE (Step 4b)

Step 4a: CREATE MODE (if Count = 0)

Invoke ln-301-task-creator worker with taskType: "test"

Pass to worker:

taskType, teamId, storyData (Story.id, title, AC, Technical Notes, Context)
researchFindings (from ln-511 comment)
manualTestResults (from ln-512 comment)
testPlan (e2eTests, integrationTests, unitTests, riskPriorityMatrix)
infrastructureChanges, documentationUpdates, legacyCleanup

Worker returns: Task URL + summary

Step 4b: REPLAN MODE (if Count >= 1)

Invoke ln-302-task-replanner worker with taskType: "test"

Pass to worker:

Same data as CREATE MODE + existingTaskIds

Worker returns: Operations summary + warnings

Step 5: Return summary to orchestrator (ln-510)

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

步骤2： 确认逻辑：

autoApprove: true（ln-510调用时默认启用）→ 自动执行
手动运行 → 提示用户输入"confirm"

步骤3： 检查现有测试任务

查询Linear：

list_issues(parentId=Story.id, labels=["tests"])

决策：

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

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

调用ln-301-task-creator工作单元，taskType: "test"

传递给工作单元的参数：

taskType、teamId、storyData（Story.id、标题、AC、技术说明、上下文）
researchFindings（来自ln-511的评论）
manualTestResults（来自ln-512的评论）
testPlan（e2eTests、integrationTests、unitTests、riskPriorityMatrix）
infrastructureChanges、documentationUpdates、legacyCleanup

工作单元返回： 任务URL + 摘要

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

调用ln-302-task-replanner工作单元，taskType: "test"

传递给工作单元的参数：

与创建模式相同的参数 + existingTaskIds

工作单元返回： 操作摘要 + 警告

步骤5： 向编排器（ln-510）返回摘要

Definition of Done

完成定义

Reference Files

参考文件

Risk-based testing methodology:
```
shared/references/risk_based_testing.md
```

Auto-discovery patterns:

shared/references/auto_discovery_pattern.md

基于风险的测试方法论：
```
shared/references/risk_based_testing.md
```

自动发现模式：

shared/references/auto_discovery_pattern.md

risk_based_testing_guide.md

Purpose: Risk-Based Testing methodology (detailed guide)

Location: references/risk_based_testing_guide.md

目的：基于风险的测试方法论（详细指南）

位置：references/risk_based_testing_guide.md

test_task_template.md (CENTRALIZED)

test_task_template.md（集中管理）

Location:

shared/templates/test_task_template.md

Usage: Workers (ln-301, ln-302) load via Template Loading logic

位置：

shared/templates/test_task_template.md

使用方式：工作单元（ln-301、ln-302）通过模板加载逻辑加载

Best Practices

最佳实践

Minimum Viable Testing: Start with 2 E2E tests (positive + negative). Add more ONLY with critical justification. Realistic goal: 2-7 tests per Story.

Risk-Based Testing: Prioritize by Business Impact x Probability. E2E-first from ACTUAL manual testing results. Priority >=15 scenarios covered by tests.

Expected-Based Testing: For deterministic tests, compare actual vs expected using

diff

. See ln-512-manual-tester Test Design Principles.

Version: 1.0.0 (Initial release - extracted from ln-510-test-planner) Last Updated: 2026-01-15

最小可行测试： 从2个E2E测试（正向+反向）开始。仅在有充分理由时添加更多测试。合理目标：每个Story 2-7个测试。

基于风险的测试： 按业务影响×概率排序优先级。基于实际手动测试结果优先进行E2E测试。覆盖优先级>=15的场景。

基于预期的测试： 对于确定性测试，使用

diff

比较实际结果与预期结果。参见ln-512-manual-tester测试设计原则。

版本： 1.0.0（初始版本 - 从ln-510-test-planner提取） 最后更新： 2026-01-15

ln-513-auto-test-planner

Original

Translation

Automated Test Planner

自动化测试规划器

Purpose & Scope

目的与范围

When to Use This Skill

何时使用该技能

When NOT to Use

何时不使用

Workflow

工作流程

Phase 1: Discovery (Automated)

阶段1：自动发现

Phase 2: Story + Tasks Analysis (NO Dialog)

阶段2：Story与任务分析（无交互）

Phase 3: Parsing Strategy for Manual Test Results

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

Phase 4: Risk-Based Test Planning (Automated)

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

Phase 5: Test Task Generation (Automated)

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

Phase 6: Confirmation & Delegation

阶段6：确认与委派

Definition of Done

完成定义

Reference Files

参考文件

risk_based_testing_guide.md

risk_based_testing_guide.md

test_task_template.md (CENTRALIZED)

test_task_template.md（集中管理）

Best Practices

最佳实践