testing-workflow

Testing Workflow 是一款专注于软件质量保障的元技能（Meta-skill），其核心定位并非直接生成测试代码，而是作为测试策略的"指挥中枢"，通过协调 testing-patterns、e2e-testing 等专项技能及测试代理，为项目构建从基线评估到持续维护的全生命周期测试体系。

该技能采用五阶段 orchestration 流程：首先是发现与基线，通过扫描现有测试基础设施、测量覆盖率并映射未测试代码，建立可量化的改进起点；其次是策略选择，依据项目类型（MVP、生产级应用、库或关键基础设施）设定差异化的覆盖目标，并选定适配的测试模式；第三阶段为实施，遵循测试金字塔原则（70%单元测试、集成测试次之、E2E 覆盖关键路径），系统性地填补测试空白；第四阶段验证确保所有测试通过且满足质量门禁；最后是维护，建立覆盖率棘轮机制、flaky 测试治理策略及季度健康审计制度。

其显著优势在于提供了工业级的测试治理框架：不仅包含具体的实施指南，更提供了测试策略文档模板、覆盖目标参考表（如生产级应用要求80%语句覆盖、70%分支覆盖）及质量门禁检查清单，确保测试工作从"可有可无"转变为"可度量、可 enforcing"的工程实践。此外，技能中"NEVER Do"章节明确禁止测试实现细节、跳过发现阶段、合并依赖执行顺序的测试等反模式，有效防范测试债务积累。

然而，该技能也存在一定局限性。作为纯文档型元技能，其实际效能高度依赖使用者对子技能（testing-patterns、e2e-testing）的掌握程度，对于缺乏测试经验的小型团队可能存在学习曲线陡峭的问题。同时，其推荐的多层测试策略对于快速验证的初创 MVP 可能显得过于繁重，需要使用者根据实际资源灵活调整，避免过度工程化。

该技能特别适合中大型开发团队、质量敏感型项目（如金融、医疗软件）以及正处于测试体系重构期的技术组织。对于需要在 CI/CD 流程中建立硬性质量门禁、或希望从"手工测试"向"自动化测试"转型的团队，此技能提供了可直接落地的标准化流程。

使用风险方面，尽管该技能本身为纯 Markdown 文档，无代码执行风险，但使用者需注意：文档中包含的 Bash 命令示例（如 npx add、mkdir/cp 等）需手动执行，操作前应验证命令安全性。此外，该技能来源为 GitHub 个人开发者（T3 可信度），建议企业用户在正式采用前进行内容审计，并结合自身技术栈调整其中的覆盖率阈值和工具链配置。

核心用法

testing-workflow 是一个纯文档型 Meta-Skill，本身不定义具体测试模式，而是通过五阶段编排流程协调多个专项技能：

| 阶段 | 关键动作 | 路由目标 |

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

| **Phase 1: Discovery** | 扫描现有测试基础设施、测量覆盖率基线、识别未覆盖代码 | 本地分析 |

| **Phase 2: Strategy** | 根据项目类型（MVP/生产应用/库/关键基础设施）设定覆盖率阈值，选择测试模式 | `testing-patterns` 技能 |

| **Phase 3: Implementation** | 按测试金字塔 70%/20%/10% 比例生成单元/集成/E2E 测试 | `e2e-testing` 技能（关键旅程） |

| **Phase 4: Validation** | 验证测试通过、覆盖率达标、无 flaky test、CI 集成正确 | `quality-gates` 技能 |

| **Phase 5: Maintenance** | 建立覆盖率棘轮机制、flaky test 策略、季度健康审计 | 持续运营 |

显著优点

1. 结构化方法论：提供完整的测试策略模板（Testing Strategy Template），强制要求文档化项目类型、基线数据、目标阈值、关键用户旅程及风险缺口，避免"拍脑袋"定指标。

2. 智能路由机制：通过 Skill Routing Table 自动将具体需求导向正确子技能（如单元模式 → testing-patterns，E2E → e2e-testing），减少选择负担。

3. 质量门禁体系：7 项硬性标准（All tests pass / Coverage targets / Critical journeys / No unjustified skips / Execution time budget / No test pollution / Justified mocks）确保测试有效性，而非仅追求数字。

4. 项目类型差异化：针对 Startup MVP（60%/50%/60%）、Production App（80%/70%/80%）、Library（90%/85%/95%）、Critical Infrastructure（95%/90%/95%）设定合理阈值，避免过度工程化。

潜在缺点与局限性

• 无自动化执行能力：作为纯编排技能，所有步骤需人工或外部工具执行，无法一键生成测试或自动修复失败。
• 语言/框架中性：不绑定具体技术栈（如 Jest/Pytest/Cypress），需配合 testing-patterns 等子技能才能落地。
• 学习曲线：五阶段流程对小型项目可能显得过重，MVP 阶段团队可能倾向于更快启动而非完整策略文档。
• 维护成本：Phase 5 要求的季度审计、覆盖率棘轮等机制需要团队文化支撑，否则易沦为"文档上的流程"。

适合人群

• 技术负责人/架构师：建立团队级测试规范与 CI/CD 质量门禁
• QA 工程师：系统化提升覆盖率，识别关键旅程缺口
• 开源维护者：为库项目设定高标准的公共 API 覆盖要求
• 发布经理：重大版本发布前执行完整质量验证清单

常规风险

• 基线测量被跳过：文档强调"NEVER skip the discovery phase"，但实践中团队常直接写新测试，导致无法量化改进。
• 覆盖率 vanity metrics：虽文档警告"100% coverage with weak assertions is worse"，但团队可能仍追求数字达标而忽视断言质量。
• E2E 测试维护成本：关键旅程的 E2E 覆盖建议与执行时间预算（<10min）存在天然张力，随功能增长易超时或被跳过。