测试工作流

通过协调 testing-patterns 技能、e2e-testing 技能以及各类测试智能体（testing agents），统筹执行项目范围内的全面测试。该元技能（meta-skill）本身不定义具体测试模式，而是在各阶段将任务精准路由至合适的技能或智能体，确保无遗漏。

适用场景

• 从零开始为新项目搭建测试体系
• 针对现有项目中存在覆盖缺口的部分提升测试覆盖率
• 建立或重构整体测试策略
• 重大版本发布前，验证质量门禁（quality gates）是否达标
• 大规模重构后，确认未引入回归缺陷
• 代码评审过程中，当测试完备性存疑时
• 团队成员入职时，统一导入标准化测试工作流

编排流程

请严格按以下顺序执行各步骤。每个步骤均需路由至特定技能或智能体——务必先阅读并应用对应资源，再进入下一步。

阶段 1：调研与基线建立

扫描项目，了解当前测试基础设施、量化现有覆盖率、识别待覆盖缺口，再开展后续改进。若无基线数据，则无法证明改进成效。

1. 识别测试基础设施 —— 明确当前使用的测试运行器（test runner）、断言库（assertion library）、覆盖率工具（coverage tool）及 CI 配置。若尚未配置，需标记“待搭建”。
2. 测量当前覆盖率 —— 运行现有测试套件，记录语句（statement）、分支（branch）和函数（function）覆盖率。此即基准值（baseline）。
3. 映射未覆盖代码 —— 标出无任何测试覆盖的模块、函数及执行路径。按风险优先级排序：业务核心逻辑优先，工具类函数靠后。
4. 梳理现有测试 —— 将已有测试归类为单元测试、集成测试或 E2E 测试；检查是否存在被跳过（skipped）、不稳定（flaky）或无实质断言（assert-free）的测试。

阶段 2：策略选型

基于阶段 1 的调研结果，为本项目选定适配的测试方法论。

1. 判定项目类型 —— 参考下方《覆盖率目标》表格，为项目类型设定合理的覆盖率阈值。
2. 选取测试模式 —— 阅读 ai/skills/testing/testing-patterns/SKILL.md，结合项目的架构、编程语言与框架，选择匹配的单元/集成测试模式。
3. 识别关键用户旅程 —— 列出 3–10 条最需 E2E 覆盖的核心用户工作流（user workflows）。这些流程一旦失败，将直接影响收入、用户信任或安全性。
4. 文档化测试策略 —— 填写下方《测试策略模板》，并将文档提交至代码仓库。

阶段 3：实施落地

依据阶段 2 所选模式，生成对应测试用例。

1. 优先编写单元测试 —— 针对未覆盖的业务逻辑编写单元测试，从最高风险模块入手。遵循测试金字塔原则：约 70% 的测试应为单元测试。
2. 其次编写集成测试 —— 编写模块边界、API 接口与数据库查询相关的集成测试，聚焦组件交互的“接缝处”（seams）。
3. 为关键旅程编写 E2E 测试 —— 阅读 ai/skills/testing/e2e-testing/SKILL.md，为阶段 2 中识别的每条关键用户旅程编写 E2E 测试。
4. 补充边缘场景覆盖 —— 在主路径（happy paths）覆盖完成后，增加对错误条件、边界值、空/空字符串输入、并发场景等的测试。

阶段 4：验证确认

验证新增测试是否符合质量标准及覆盖率目标。

1. 运行完整测试套件 —— 所有测试必须全部通过。修复失败项后方可继续。
2. 比对覆盖率目标 —— 将新测得的覆盖率与项目类型对应的阈值进行比对。若未达标，返回阶段 3 补充测试。
3. 审查测试质量 —— 检查测试是否违反 testing-patterns 中列出的反模式（如无断言测试、过度 Mock、不稳定测试、测试污染等），发现问题须立即修正。
4. 验证 CI 集成 —— 确认测试在每次推送（push）或合并请求（PR）时自动运行，且 CI 中已强制执行覆盖率阈值校验。

阶段 5：持续维护

建立长效机制，保障测试套件长期健康运转。

1. 启用覆盖率收紧机制（coverage ratcheting） —— 配置 CI，当覆盖率低于当前水平时构建失败。覆盖率只允许上升，不可下降。
2. 制定不稳定测试治理策略 —— 对任意间歇性失败（flaky）的测试，须在一迭代周期内修复，或提供充分理由后移除。
3. 明确定义测试评审标准 —— 所有新增或修改业务逻辑的 PR，必须同步包含对应的测试变更；评审人须对此进行核查。
4. 定期开展测试健康审计 —— 每季度审查测试执行耗时、不稳定测试率、被跳过测试数量及覆盖率趋势。

技能路由表

使用本表将具体需求精准路由至对应资源：

当某项需求明确匹配表中某一行时，请直接访问对应资源。仅当目标是实现**全面覆盖**时，才需执行完整编排流程。

覆盖率目标

目标值依项目类型而异。请根据对应行设定合理预期：

以上为最低要求。时间充裕时建议追求更高目标，但切勿因“虚荣指标”（vanity metrics）阻塞发布——应优先保障**有意义的覆盖**，而非单纯堆砌百分比。

测试策略模板

使用本模板记录项目的测试策略。在编排流程中填写完毕，并长期保存于代码仓库中。

# 测试策略

## 项目概览
- **项目**: [名称]
- **类型**: [startup MVP | production app | library | critical infrastructure]
- **主要语言**: [语言]
- **框架**: [框架]
- **测试运行器**: [runner]
- **覆盖率工具**: [tool]

## 覆盖率基线
- **语句覆盖率**: [X%]
- **分支覆盖率**: [X%]
- **函数覆盖率**: [X%]
- **已覆盖 E2E 用户旅程数**: [N of M]
- **测量日期**: [YYYY-MM-DD]

## 覆盖率目标
- **语句覆盖率**: [目标%]
- **分支覆盖率**: [目标%]
- **函数覆盖率**: [目标%]
- **E2E 用户旅程数**: [目标数量]

## 已选测试模式
- [ ] [模式 1 —— 选用原因]
- [ ] [模式 2 —— 选用原因]
- [ ] [模式 3 —— 选用原因]

## 关键用户旅程（E2E）
1. [旅程 1 —— 例如：注册 → 入门引导 → 首次操作]
2. [旅程 2 —— 例如：登录 → 仪表盘 → 导出]
3. [旅程 3 —— 例如：结算 → 支付 → 确认]

## 待覆盖缺口与风险
- [未覆盖区域 1 —— 风险等级，缓解方案]
- [未覆盖区域 2 —— 风险等级，缓解方案]

## 质量门禁状态
- [ ] 所有测试通过
- [ ] 覆盖率目标达成
- [ ] 关键用户旅程已由 E2E 测试覆盖
- [ ] 无未经说明的跳过测试
- [ ] 测试执行耗时在预算范围内
- [ ] CI 已强制执行覆盖率阈值

测试完成的质量门禁

满足以下全部条件，方可标记测试工作完成：

绝对禁止事项

1. 绝对禁止编写测试实现细节而非行为的测试 —— 测试必须验证代码“做什么”，而非“如何做”
2. 绝对禁止跳过调研阶段 —— 编写新测试前必须测量基线，否则无法证明改进效果
3. 绝对禁止合并依赖执行顺序的测试 —— 每个测试必须独立且幂等
4. 绝对禁止 Mock 自身不拥有的外部依赖 —— 应将第三方依赖封装为自有适配器（adapter），并仅 Mock 适配器
5. 绝对禁止将覆盖率百分比视为唯一质量指标 —— 弱断言下的 100% 覆盖率，劣于强断言下的 70% 覆盖率
6. 绝对禁止让测试套件处于失败状态 —— 若测试失败，必须修复或提供充分理由后移除，方可继续推进
7. 绝对禁止跳过关键用户旅程的 E2E 测试 —— 单元测试无法捕获最重要用户流程中的集成缺陷
8. 绝对禁止未运行完整测试套件即部署 —— 局部测试运行会制造虚假信心