测试工作流

通过协调 testing-patterns 技能、e2e-testing 技能以及测试代理，实现对项目的全面测试编排。此元技能本身不定义测试模式，而是在每个阶段将任务路由到合适的技能或代理，并确保无遗漏。

适用场景

• 从零开始为新项目搭建测试体系
• 为现有项目中存在测试覆盖缺口的部分提升覆盖率
• 建立或修订测试策略
• 重大发布前验证质量门禁是否达标
• 大规模重构后确认未引入破坏性变更
• 代码审查期间，当测试充分性存疑时
• 团队成员新加入项目时进行测试流程培训

编排流程

请按顺序执行以下步骤。每一步都会指向特定的技能或代理——在进入下一步前，请先阅读并应用对应资源。

阶段一：发现与基线建立

扫描项目以了解现有的测试基础设施，测量当前覆盖率，并识别差距。没有基线数据，就无法衡量改进效果。

1. 识别测试基础设施 —— 确定当前使用的测试运行器、断言库、覆盖率工具和 CI 配置。若尚未配置，需标记为待设置。
2. 测量当前覆盖率 —— 运行现有测试套件，记录语句覆盖率、分支覆盖率和函数覆盖率。这是基准值。
3. 映射未覆盖代码 —— 识别无测试覆盖的模块、函数和代码路径。按风险优先级排序：业务关键逻辑优先，通用工具类最后。
4. 整理现有测试清单 —— 将已有测试分类为单元测试、集成测试或端到端测试。检查是否存在被跳过的测试、不稳定测试（flaky tests），以及无实际断言的测试。

阶段二：策略选择

根据发现结果，为本项目选择合适的测试方法。

1. 确定项目类型 —— 参考下方“覆盖率目标”表格，为项目类型设定合理的覆盖率阈值。
2. 选择测试模式 —— 阅读 ai/skills/testing/testing-patterns/SKILL.md，选择与项目架构、语言和框架相匹配的单元测试/集成测试模式。
3. 识别关键用户流程 —— 列出 3 到 10 个最重要的用户操作路径，这些路径需要端到端测试覆盖。这些是失败会直接影响收入、用户信任或安全性的流程。
4. 文档化测试策略 —— 填写下方的测试策略模板，并提交至代码仓库。

阶段三：实施

按照阶段二选定的模式生成测试用例。

1. 优先编写单元测试 —— 为未覆盖的业务逻辑编写单元测试，从高风险模块开始。遵循测试金字塔原则：约 70% 的测试应为单元测试。
2. 随后编写集成测试 —— 在模块边界、API 接口、数据库查询等交互点编写集成测试。聚焦于组件之间的连接处。
3. 对关键流程编写端到端测试 —— 阅读 ai/skills/testing/e2e-testing/SKILL.md，为阶段二中识别的关键用户流程编写端到端测试。
4. 补充边缘情况覆盖 —— 在正常流程覆盖完成后，增加对错误条件、边界值、空值/空输入、并发场景的测试。

阶段四：验证

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

1. 运行完整测试套件 —— 所有测试必须通过。在继续之前修复所有失败项。
2. 对比覆盖率目标 —— 将新覆盖率与项目类型的阈值进行比较。若未达标，返回阶段三。
3. 检查测试质量 —— 审查测试是否存在反模式，如无断言的测试、过度模拟（overmocking）、不稳定测试、测试污染等问题。发现问题立即修复。
4. 验证 CI 集成 —— 确认每次推送或 PR 都会自动运行测试，并且 CI 中已强制执行覆盖率阈值。

阶段五：维护

建立持续实践，保持测试套件健康。

1. 设置覆盖率递增机制 —— 配置 CI 使覆盖率下降时触发失败。覆盖率只能上升，不能下降。
2. 制定不稳定测试处理政策 —— 任何间歇性失败的测试必须在一个迭代周期内修复，或移除并附上合理说明。
3. 定义测试评审标准 —— 每个包含逻辑新增或修改的 PR 必须同步更新测试。评审者需检查此项。
4. 安排测试健康度审计 —— 每季度审查测试执行时间、不稳定测试率、被跳过的测试数量及覆盖率趋势。

技能路由表

使用此表格将具体需求导向正确资源：

当请求明确属于某一行时，可直接前往对应资源。仅在追求全面覆盖时才使用完整的编排流程。

覆盖率目标

不同项目类型的目标不同。请根据项目类型选择对应的行来设定预期：

测试流程

这些是最低要求。在时间允许的情况下应追求更高标准，但不要因虚荣的指标而阻塞发布——优先考虑有意义的测试覆盖，而非百分比数字。

测试策略模板

使用此模板记录项目的测试策略。在编排流程中填写，并保留在代码仓库中。

# 测试策略

## 项目概览
- **项目**: [name]
- **类型**: [初创MVP | 生产环境应用 | 库 | 关键基础设施]
- **主要语言**: [language]
- **框架**: [framework]
- **测试运行器**: [runner]
- **覆盖率工具**: [tool]

## 覆盖率基线
- **语句覆盖率**: [X%]
- **分支覆盖率**: [X%]
- **函数覆盖率**: [X%]
- **端到端旅程覆盖数**: [N / M]
- **测量日期**: [YYYY-MM-DD]

## 覆盖率目标
- **语句覆盖率**: [target%]
- **分支覆盖率**: [target%]
- **函数覆盖率**: [target%]
- **端到端旅程数量**: [target count]

## 选择的测试模式
- [ ] [模式1 — 选择原因]
- [ ] [模式2 — 选择原因]
- [ ] [模式3 — 选择原因]

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

## 差距与风险
- [未测试区域1 — 风险等级，缓解计划]
- [未测试区域2 — 风险等级，缓解计划]

## 质量门禁状态
- [ ] 所有测试通过
- [ ] 覆盖率目标达成
- [ ] 关键旅程具备端到端测试覆盖
- [ ] 无未经合理解释的跳过测试
- [ ] 测试执行时间在预算范围内
- [ ] CI 强制执行覆盖率阈值

测试完成的质量门禁

在标记测试完成前，必须满足以下所有条件：

绝对禁止的行为

1. 绝不要编写测试来验证实现细节而非行为 — 测试应验证代码的功能表现，而非内部实现方式
2. 绝不要跳过发现阶段 — 在编写新测试前必须先测量基线，否则无法证明改进效果
3. 绝不要合并依赖执行顺序的测试 — 每个测试必须独立且幂等
4. 绝不要模拟你无法控制的依赖 — 将第三方依赖封装在自定义适配器中，并模拟适配器而非直接模拟外部库
5. 绝不要将覆盖率百分比作为唯一的质量指标 — 100%覆盖率但断言薄弱，不如70%覆盖率但断言有力
6. 绝不要让测试套件处于失败状态 — 若测试失败，应在继续前修复或移除并附上合理说明
7. 绝不要跳过关键用户旅程的端到端测试 — 单元测试无法捕捉最关键的集成问题
8. 绝不要在未运行完整测试套件的情况下部署 — 局部测试运行会带来虚假信心