Testing Workflow

核心用法

testing-workflow 是一个元技能（meta-skill），不直接定义测试模式，而是通过编排协调 testing-patterns、e2e-testing 技能及各类测试代理，为项目建立完整的测试体系。其工作流程分为五个严格顺序的阶段：

1. Phase 1: Discovery and Baseline — 扫描现有测试基础设施，测量覆盖率基线，识别未覆盖代码并分类现有测试
2. Phase 2: Strategy Selection — 根据项目类型（MVP/生产应用/库/关键基础设施）设定覆盖率目标，选择测试模式，识别关键用户旅程
3. Phase 3: Implementation — 遵循测试金字塔（70%单元→集成→E2E），先生成单元测试，再处理集成与端到端场景
4. Phase 4: Validation — 运行完整测试套件，验证覆盖率达标，检查测试反模式（无断言、过度mock、不稳定测试）
5. Phase 5: Maintenance — 建立覆盖率棘轮机制、不稳定测试策略、PR测试审查标准及季度健康审计

显著优点

• 系统化编排：五阶段流程确保测试建设不遗漏关键环节，避免"写到哪算哪"的混乱
• 风险导向的优先级：明确区分业务关键逻辑与工具类代码的测试优先级
• 强约束的质量门：定义7项硬性完成标准，包括执行时间预算（单元<60s，E2E<10min）、无未解释跳过、无测试污染等
• 可维护性设计：内置覆盖率棘轮（只升不降）、季度健康审计等长期机制

潜在缺点与局限性

• 启动成本较高：完整流程需要经历5个阶段，对紧急修复或小改动场景可能过于沉重
• 依赖多技能协同：需配合 testing-patterns、e2e-testing 等技能才能实际生成代码，单独使用仅为"空壳编排"
• 目标刚性可能引发博弈：覆盖率阈值若僵化执行，可能导致为达标而写的低质量测试
• 无自动工具集成：需手动配置 CI、覆盖率工具等，未提供一键式环境搭建

适合人群

• 技术负责人/架构师：为团队建立标准化测试流程
• QA工程师与测试自动化专家：系统化提升测试覆盖率
• 代码审查者：验证PR是否满足测试质量门
• 新项目启动团队：从0到1建立测试体系

常规风险

| 风险 | 说明 |

|------|------|

| 流程形式主义 | 团队机械执行五阶段却忽视实际测试质量 |

| 覆盖率 vanity metrics | 过度关注百分比，忽视断言强度与行为验证 |

| E2E维护负担 | 关键用户旅程定义过多导致E2E套件臃肿缓慢 |

| 技能路由误用 | 简单测试需求被不必要的完整流程拖累 |

核心用法

Testing Workflow 是一个元级协调技能（Meta-Skill），本身不定义具体的测试代码模式，而是通过五阶段标准化流程，将用户的测试需求路由到专业化的子技能中。整个编排流程分为：发现基线（Discovery and Baseline）、策略选择（Strategy Selection）、测试实现（Implementation）、验证确认（Validation）和持续维护（Maintenance）。

在发现阶段，技能会指导用户扫描现有测试基础设施、测量覆盖率基线、识别未测试代码并分类现有测试。策略阶段则根据项目类型（Startup MVP、Production App、Library、Critical Infrastructure）设定差异化的覆盖率目标，并选择匹配的测试模式。实现阶段遵循测试金字塔原则：约 70% 单元测试、适当比例集成测试、少量但关键的 E2E 测试。验证阶段确保所有测试通过、覆盖率达标、无质量反模式。维护阶段建立覆盖率棘轮机制、脆弱测试处理策略和季度健康审计制度。

技能内置完整的路由表，可将具体需求定向到 testing-patterns、e2e-testing、clean-code、code-review、quality-gates、debugging 等下游技能。同时提供覆盖目标参考表、测试策略文档模板和质量门禁检查清单，形成可落地、可审计的测试工程体系。

显著优点

体系化而非碎片化：区别于单点测试技巧，该技能构建了从基线测量到持续维护的完整闭环，避免"头痛医头"的局部优化。

项目类型自适应：针对四种典型项目形态（MVP、生产应用、开源库、关键基础设施）设定差异化的覆盖目标，拒绝一刀切的虚荣指标。

质量门禁可操作：将抽象的"高质量"转化为 7 项可检查的门禁条件，包括测试执行时间预算、无跳过测试、无测试污染等工程实践细节。

元技能架构解耦：通过路由表将专业领域（E2E 模式、代码审查、调试技巧）分离到独立技能，用户可按需组合，避免单个技能过度膨胀。

文档即契约：强制要求产出《测试策略文档》并纳入版本控制，使测试策略成为团队共享的工程契约，而非个人隐性知识。

潜在缺点与局限性

依赖下游技能质量：作为纯协调层，实际测试能力完全取决于被引用的 testing-patterns、e2e-testing 等下游技能。若子技能质量不足，协调层无法弥补。

T3 来源可信度：作者为个人开发者（wpank），未建立组织级可信账号（T2）或基金会背书（T1），在长期维护承诺、社区支持广度方面存在不确定性。

无自动执行能力：纯文档型设计意味着所有流程需人工或外部 Agent 逐步执行，无法实现"一键生成完整测试套件"的自动化体验。

行业特定场景缺失：当前覆盖目标表未针对金融合规、医疗软件（FDA 验证）、汽车功能安全（ISO 26262）等强监管行业的特殊要求进行扩展。

执行成本认知不足：文档未充分警示五阶段完整流程的时间投入——对遗留大型项目，发现阶段可能耗时数周，易被团队低估。

适合的目标群体

• 技术负责人/架构师：需要为团队建立标准化测试流程，统一代码审查中的测试 adequacy 标准
• DevOps/质量工程师：负责 CI/CD 管道中测试门禁的配置与覆盖率趋势监控
• 新项目启动团队：在从零搭建技术栈时，希望规避"先写功能后补测试"的债务陷阱
• 遗留系统维护者：面对测试覆盖率极低的老项目，需要系统性的改进路径而非盲目补测试
• 技术驱动型创业公司：在资源受限情况下，需要明确"MVP 阶段测试投入边界"的决策框架

使用风险

依赖链传播风险：虽然本技能本身安全（无可执行代码、无网络调用），但执行工作流时会加载多个下游技能。建议在使用前独立审查 testing-patterns 和 e2e-testing 等关键子技能的 CLS 认证报告，防止安全薄弱点沿依赖链传导。

版本漂移风险：个人开发者维护的项目可能存在更新不规律问题。建议采用版本锁定安装（指定 commit hash），并建立 Skill 更新审查流程，防止行为变更导致 CI 管道意外失败。

认知过载风险：五阶段完整流程对小型团队可能过于沉重。建议根据项目阶段选择性裁剪——MVP 可仅执行 Phase 1-3 的核心子集，避免流程成本超越实际价值。

覆盖率虚荣指标风险：文档虽已强调"有意义的覆盖优于百分比"，但团队仍可能机械追求表格中的数字目标。建议在采纳前明确：覆盖率是必要非充分条件，断言质量和测试意图表达同样关键。

许可法律风险：当前 Skill 未指定 LICENSE，存在潜在的使用权限模糊性。建议在正式采用前联系作者确认许可条款，或优先选择已明确开源协议（MIT/Apache）的替代方案。