test-analyze

测试分析与修复规划

分析任意测试框架的测试结果，使用 Zen 规划器制定系统化的修复策略，并将修复任务委派给合适的子 Agent。

何时使用此技能

在以下情况下使用此技能……	在以下情况下改用 test-report……
将包含失败测试结果的目录分类整理为修复计划	只需要快速读取缓存状态
对不稳定、性能、无障碍或安全问题进行分类	首次运行测试（使用 test-run）
将修复任务委派给专门的子 Agent	询问“我们应该如何测试 X？”这类策略性问题（使用 test-consult）
根据 JUnit XML 或覆盖率输出生成结构化计划	逐步处理单个失败的测试规范（使用 test-focus）

用法

/test:analyze <results-path> [--type <test-type>] [--focus <area>]

参数

• <results-path>：测试结果目录或文件的路径（必需）

  • 示例：./test-results/、./coverage/、pytest-report.xml

• --type <test-type>：测试类型（可选；若省略则自动检测）

  • accessibility - Playwright a11y、axe-core
  • unit - Jest、pytest、cargo test
  • integration - API 测试、数据库测试
  • e2e - Playwright、Cypress、Selenium
  • security - OWASP ZAP、Snyk、TruffleHog
  • performance - Lighthouse、k6、JMeter

• --focus <area>：要重点关注的具体领域（可选）

  • 示例：authentication、api、ui-components、database

示例

# Analyze Playwright accessibility test results
/test:analyze ./test-results/ --type accessibility

# Analyze unit test failures with focus on auth
/test:analyze ./coverage/junit.xml --type unit --focus authentication

# Auto-detect test type and analyze all issues
/test:analyze ./test-output/

# Analyze security scan results
/test:analyze ./security-report.json --type security

命令流程

1. 分析测试结果

   • 解析测试结果文件（XML、JSON、HTML、文本）
   • 提取失败、错误和警告
   • 按类型和严重程度对问题进行分类
   • 识别规律和根本原因

2. 使用 PAL Planner 规划修复

   • 使用 mcp__pal__planner 进行系统化规划
   • 将复杂修复拆解为可执行的步骤
   • 识别修复项之间的依赖关系
   • 评估工作量和优先级

3. 委派给子 Agent

   • 无障碍问题 → code-review Agent（WCAG 合规性）
   • 安全漏洞 → security-audit Agent
   • 性能问题 → system-debugging Agent
   • 代码质量问题 → code-refactoring Agent
   • 测试基础设施 → test-architecture Agent
   • 集成失败 → system-debugging Agent
   • 文档缺失 → documentation Agent

4. 执行计划

   • 根据依赖关系按顺序执行
   • 每次修复后进行验证
   • 重新运行测试以确认问题已解决

子 Agent 选择逻辑

该命令使用以下决策树进行任务委派：

• 无障碍违规（WCAG、ARIA、对比度） → 将任务委派给侧重无障碍的 code-review Agent

• 安全问题（XSS、SQLi、身份验证绕过） → 将任务委派给进行 OWASP 分析的 security-audit Agent

• 性能瓶颈（查询缓慢、内存泄漏） → 将任务委派给使用性能分析的 system-debugging Agent

• 代码异味（重复、复杂性、耦合） → 将任务委派给遵循 SOLID 原则的 code-refactoring Agent

• 不稳定的测试（竞态条件、时序问题） → 将任务委派给进行稳定性分析的 test-architecture Agent

• 构建/CI 失败（流水线错误、依赖项问题） → 将任务委派给进行工作流优化的 cicd-pipelines Agent

输出

该命令会生成：

1. 摘要报告

   • 发现的问题总数
   • 按类别/严重程度划分的问题
   • 最高优先级的问题

2. 修复计划（来自 PAL planner）

   • 分步修复策略
   • 依赖关系图
   • 工作量估算

3. 子 Agent 任务分配

   • 各 Agent 负责处理的问题
   • 委派理由
   • 执行顺序

4. 可执行的后续步骤

   • 要运行的命令
   • 要修改的文件
   • 验证步骤

备注

• 适用于任何能生成结构化输出的测试框架
• 自动检测常见的测试结果格式（JUnit XML、JSON、TAP）
• 保留测试证据以便调试
• 可与 /git:smartcommit 串联，实现自动修复
• 遵循 TDD 工作流（RED → GREEN → REFACTOR）

相关命令

• /test:run - 检测框架并运行测试
• /code:review - 手动审查测试文件
• /docs:update - 更新测试文档
• /git:smartcommit - 使用约定式提交消息提交修复

---

提示词：

分析来自 {{ARG1}} 的测试结果，并制定系统化的修复计划。

{{#if ARG2}} 测试类型：{{ARG2}} {{else}} 根据文件格式和内容自动检测测试类型。 {{/if}}

{{#if ARG3}} 关注领域：{{ARG3}} {{/if}}

步骤 1：分析测试结果

读取来自 {{ARG1}} 的测试结果文件，并提取：

• 失败的测试及错误消息
• 警告和弃用提示
• 性能指标（如果可用）
• 覆盖率缺口（如果可用）
• 按以下维度分类：严重程度（严重/高/中/低）、类型（功能/安全/性能/无障碍）

步骤 2：使用 PAL Planner

调用 mcp__pal__planner，并指定模型 "gemini-2.5-pro"，以制定系统化的修复计划：

• 步骤 1：总结发现并确定根本原因
• 步骤 2：确定问题优先级（影响 × 工作量矩阵）
• 步骤 3：将修复拆解为可执行的任务
• 步骤 4：确定各项修复之间的依赖关系
• 步骤 5：将每个修复类别分配给合适的子 Agent
• 对于复杂场景，根据需要继续规划

步骤 3：子 Agent 委派策略

根据问题类别，委派给：

• 无障碍违规（WCAG、ARIA、颜色对比度、键盘导航） → 使用 Task 工具，并设置 subagent_type: code-review → 重点：符合 WCAG 2.1、语义化 HTML、ARIA 最佳实践

• 安全漏洞（XSS、SQLi、CSRF、身份验证问题） → 使用 Task 工具，并设置 subagent_type: security-audit → 重点：OWASP Top 10、输入验证、身份验证

• 性能问题（测试缓慢、内存泄漏、超时） → 使用 Task 工具，并设置 subagent_type: system-debugging → 重点：性能分析、瓶颈识别、优化

• 代码质量（重复、复杂度、可维护性） → 使用 Task 工具，并设置 subagent_type: code-refactoring → 重点：SOLID 原则、DRY、代码异味

• 不稳定/不可靠的测试（竞态条件、时序问题、依赖项） → 使用 Task 工具，并设置 subagent_type: test-architecture → 重点：测试稳定性、隔离性、确定性

• CI/CD 失败（构建错误、流水线问题） → 使用 Task 工具，并设置 subagent_type: cicd-pipelines → 重点：GitHub Actions、依赖管理、缓存

• 文档缺口（缺少文档、示例过时） → 使用 Task 工具，并设置 subagent_type: documentation → 重点：API 文档、测试文档、迁移指南

步骤 4：制定执行计划

对于分配给每个子 Agent 的任务：

1. 上下文：需要关注的文件/领域
2. 目标：具体的修复目标
3. 成功标准：如何验证修复
4. 依赖关系：必须先完成哪些事项
5. 验证：需要重新运行测试的命令

步骤 5：提供摘要

提供：

• 📊 问题细分：按类别和严重程度统计数量
• 🎯 优先级：最先修复的 3-5 个问题
• 🤖 子 Agent 计划：哪些 Agent 将处理哪些事项
• ✅ 后续步骤：具体操作
• 🔍 验证：如何确认修复有效

{{#if ARG3}} 重点关注 {{ARG3}}：优先处理与此领域相关的问题，并为相关子 Agent 提供额外背景信息。 {{/if}}

文档优先提醒：在实施修复之前，使用 context7 查阅相关文档，确认以下内容：

• 测试框架最佳实践
• 无障碍标准（WCAG 2.1）
• 安全模式（OWASP）
• 性能优化技术

TDD 工作流：遵循 RED → GREEN → REFACTOR：

1. 确认测试失败（RED）✓（已完成）
2. 实施最小修复（GREEN）
3. 重构以提升质量
4. 重新运行测试以确认

你要我继续进行分析和规划，还是想先审阅计划？