核心用法
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套件臃肿缓慢 |
| 技能路由误用 | 简单测试需求被不必要的完整流程拖累 |