testing-strategies

测试策略

当核心问题是**“我们信任哪套验证方案、实际需要多高的置信度，以及团队接下来应该做什么？”**时，使用此技能。

这项工作的目的不是照搬通用的金字塔／奖杯宣言，也不是编写测试代码。 而是：

1. 规范当前的策略方案，
2. 明确当前要决定的具体门禁，
3. 选择一种主要策略模式，
4. 确定足以令人信服的最小测试层组合，
5. 区分本地、PR、发布和定期执行的要求，
6. 如实说明例外规则和不稳定测试规则，
7. 立即将实现、调试、发布执行、无障碍、游戏启动或性能相关工作转交给其他流程。

处理不熟悉的策略方案前，请阅读 references/intake-packets-and-route-outs.md。 如果不确定之处实际上是分支阻塞条件与仅限发布的验证或平台启动验证之间的区别，请阅读 references/gate-truth-and-release-handovers.md。 选择足以令人信服的最小测试层组合时，请阅读 references/validation-matrix.md。 决定下一步应由 testing-strategies、backend-testing、debugging、code-review、performance-optimization 还是 web-accessibility 负责时，请阅读 references/handoff-boundaries.md。

何时使用此技能

• 团队需要一份针对变更的验证简报，而不是模糊的“多加些测试”建议
• 开发者或审查者在询问本地、PR 上、发布前或定期／每晚应运行哪些内容
• 需要判断单元、集成、契约、冒烟、探索性或人工检查是否确有必要
• 不稳定或成本高昂的测试套件问题实际上是门禁策略问题
• 已逃逸的缺陷或事故需要建立合适的回归防护机制，而不是盲目扩大端到端测试覆盖范围
• 发布就绪或 QA 签核工作需要与实际变更风险挂钩

何时不使用此技能

• 主要任务是实现 API／服务／数据库／浏览器测试、测试夹具、模拟对象或 testcontainers → 使用 backend-testing 或特定技术栈的实现技能
• 主要任务是复现故障、查明测试失败原因或调试不稳定行为 → 使用 debugging
• 主要任务是评判某个具体 PR、差异或合并请求 → 使用 code-review
• 主要任务是以无障碍验证或视觉审查策略为主 → 使用 web-accessibility 或 web-accessibility
• 主要风险是性能基准测试、负载测试或帧预算策略 → 使用 performance-optimization 或 game-performance-profiler
• 尚无实际变更或决策点；应先明确变更内容以及需要做出的置信度决策

说明

步骤 1：从已有的策略方案着手

使用 references/intake-packets-and-route-outs.md。

将当前方案规范为以下其中一种形式：

• change-risk-packet — 功能、缺陷修复、迁移、API 变更、身份验证变更、UI 流程变更、配置／部署变更或事故后续处理
• gate-design-packet — 团队正在讨论本地、PR、发布或定期门禁应包含哪些内容
• flake-cost-packet — 测试套件运行缓慢、结果嘈杂、脆弱或成本高昂，且策略尚不明确
• release-readiness-packet — 涉及预发布环境冒烟测试、签核、推出或检查清单，但测试层的职责划分不清
• incident-ratchet-packet — 已逃逸的缺陷或停机修复需要最精简且持久的回归防护

收集最少但有用的信息：

Packet: change-risk-packet
Change type: API contract + DB migration
Hotspots: compatibility, migration safety, permissions
Decision point: PR + release
Current evidence: unit tests only

规则：从用户已有的方案着手。不要先要求用户提供理想的 QA 模板，才开始提供有用的帮助。

第 2 步：在选择测试层之前，明确真实的关卡

说明当前真正的决策点：

• merge-gate-truth — 阻止分支合并的证据、必需的状态检查，或阻止评审通过的证明
• release-gate-truth — 预发布冒烟测试、发布安全性、回滚说明、权限、打包或人工签核
• scheduled-breadth-truth — 提升信心的夜间／cron／矩阵覆盖，但不应阻止每个 PR

规则：

• 不要让受保护分支工具冒充完整的测试策略；它只负责执行阻塞性测试子集。
• 不要让发布／平台检查清单悄然扩大 PR 关卡，若它们实际属于发布或上线部署的责任范围。
• 如果存在多个关卡，请明确指出主要关卡和后续关卡。

第 3 步：选择一种主要策略模式

恰好选择一种主要模式：

• layer-selection — 哪些验证层能够证明变更后的行为？
• gate-shaping — 哪些内容应纳入本地、PR、发布或定期循环？
• flake-and-cost-policy — 哪些测试应阻塞、隔离、迁移或仅提供信息？
• incident-regression-ratchet — 能捕获已逃逸缺陷的最低测试层是什么？
• release-confidence — 还需要哪些最终冒烟测试、检查清单或上线证明，才能如实确认发布信心？

可选：指定一种次要模式，但不要把所有测试讨论都压成同一份检查清单。

第 4 步：划分风险等级和关键路径

使用精简的风险模型：

• Tier 0 — 低风险： 文档、注释、删除死代码、独立重命名、显而易见的配置元数据
• Tier 1 — 一般产品变更： 影响范围有限的常规功能或重构
• Tier 2 — 高风险： 公共 API、迁移、身份验证、计费、外部集成、状态机、并发、后台任务
• Tier 3 — 发布关键／关联事故： 已逃逸的缺陷、宕机修复、对回滚敏感的部署路径，或关键客户旅程

记录：

• 关键路径和受影响的用户
• 失败代价：造成不便、功能故障、信任受损、数据丢失、发布风险、安全风险
• 已有证据：测试、截图、预览、日志、契约说明、发布说明、检查清单
• 决策点：本地信心、PR／合并信心、发布信心，或长时间运行的定期广度覆盖

如果变更涉及多个风险等级，按最高等级规划。

第 5 步：选择最精简且有说服力的测试层组合

使用 references/validation-matrix.md。

默认测试层选择：

• 单元／组件／服务：主要风险在逻辑、验证、分支或映射时
• 集成：涉及连接、数据库语义、中间件、序列化、任务或真实依赖行为时
• 契约／API 级别：响应结构、模式、事件或跨服务／客户端边界发生变化时
• 冒烟测试／选择性 E2E：需要多个测试层共同验证一条关键端到端旅程时
• 手动探索／检查清单验证：视觉细节、设备差异、运维边缘情况或人工签核仍是合理选择时

始终说明以下两点：

• 当前需要什么
• 当前有意不纳入什么，以及原因

示例：

• “现在做集成 + 契约测试；用户旅程未变，因此不做大范围浏览器 E2E”
• “进行发布冒烟测试并执行上线部署检查清单；由于唯一风险存在于预发布配置和部署行为中，因此不新增单元测试”

步骤 6：区分本地、PR、发布和定期执行的预期

有用的策略简报不会假装一套测试适用于所有流程。

定义最小且真实的门禁划分：

• 本地 — 快速、低成本的开发循环验证
• PR / 合并 — 针对高风险路径的变更范围置信度
• 发布 — 面向生产环境的冒烟测试、迁移安全性、推出检查或人工签核事项
• 定期 / 夜间 — 大范围矩阵、高成本组合、兼容性扫描、长时间运行的测试套件

经验法则：

• 如果某个测试套件对 PR 来说太慢或太不稳定，就应有意调整其执行时机，而不是默默地无限重跑
• 如果启用了分支保护 / 必需状态检查，只列出真正必须阻止合并的检查
• 如果存在发布检查清单，应将其关联到仍需人工验证的具体风险
• 如果商店 / 平台发布检查清单已成为主要工作，应将其交由发布或交付负责人处理，而不是硬塞回合并覆盖范围
• 如果这份材料实际上只是发布协调，就应如实说明，而不是假装每一项都是测试层级的选择

步骤 7：明确例外和不稳定测试规则

这一步将策略转化为实际操作。

说明：

• 哪些检查会阻断流程，哪些仅提供信息
• 何时应隔离、修复、移至定期执行或从门禁中移除不稳定的测试
• 未新增回归覆盖时需要提供什么说明
• 覆盖率百分比在此处是否重要，还是仅作为背景报告
• 人工验证是临时安排、仅用于发布，还是有意长期采用的做法

良好默认做法：

• 反复出现的不稳定问题是策略问题，而不只是重跑流程
• 隔离可以减少 CI 噪声，但必须明确显示负责人、期限和后续跟进
• “覆盖率提高了”并不能证明高风险场景已受到保护
• 漏网缺陷应通过最低层级的回归测试来防止，而该测试必须确实能够捕获此类缺陷

步骤 8：立即确定下一位负责人

此技能负责策略和置信度决策，而非所有下游工作。

常见移交对象：

• backend-testing — 编写或修复选定的 API / 服务 / 数据库 / 测试夹具 / 契约测试
• debugging — 调查测试套件当前为何失败、不稳定或依赖特定环境
• code-review — 判断某个差异当前的验证证据是否足以批准
• deployment-automation — 在选定门禁后，负责推出执行、预发布 / 生产验证顺序、回滚步骤或发布运行手册
• game-ci-cd-pipeline — 当问题涉及游戏 CI/CD，而非策略选择时，负责引擎 / 构建流水线的实现或稳定性
• steam-store-launch-ops — 当剩余验证涉及发布检查清单、页面就绪状态或发布时间，而非合并置信度时，负责 Steam 专属的发布 / 商店 / 运行手册工作
• web-accessibility / web-accessibility — 处理以无障碍或视觉治理验证为主的材料
• performance-optimization / game-performance-profiler — 当性能是实际主要风险时，处理基准测试、负载、延迟或帧预算策略

如果用户问“我们应该测试什么？”，就留在此处。 如果用户问“如何编写或稳定这些测试？”，就移交处理。

步骤 9：生成一份简洁的验证简报

首选格式：

# Validation Strategy Brief

## Policy packet
- Packet:
- Gate truth:
- Primary mode:
- Risk tier:
- Decision point:

## Required validation now
1. [Layer] ... because ...
2. [Layer] ... because ...
3. [Manual / release check] ... because ...

## Gate split
- Local:
- PR:
- Release:
- Scheduled:

## Out of scope for now
- ...

## Exception / flake policy
- ...

## Next owner
- `backend-testing` / `debugging` / `code-review` / other

简短明确的简报胜过冗长的测试宣言。 如果诚实的答案是“减少测试，但放在正确层级”，就直接说明。

输出格式

始终返回一份验证策略简报、门禁制定备忘录或回归防护简报。

必备要点：

• 确定手头已有的材料
• 在扩展到更多层级之前，点明正在决策的实际门禁
• 选择一种主要策略模式
• 明确分类风险和关键路径
• 在相关情况下，区分本地、PR、发布和定期执行的预期
• 解释有意排除的内容，不要含糊带过
• 将实现、调试、评审、无障碍或性能工作移交给正确的相邻技能

示例

示例 1：API + 迁移数据包

输入

此 PR 更改了 API 契约并添加了数据库迁移。合并前应要求哪些验证？

输出示意

• 数据包：change-risk-packet
• 门禁判定：merge-gate-truth
• 主要模式：layer-selection
• 风险等级：2
• 必需的验证：
  1. 针对迁移读写路径的集成测试
  2. 检查响应兼容性的契约/API 检查
  3. 针对最高价值使用路径的发布冒烟测试
• 范围外：由于用户流程未变更，不进行大范围浏览器 E2E 测试
• 下一负责人：backend-testing

示例 2：浏览器套件易波动数据包

输入

我们的 Playwright 套件运行缓慢，而且经常出现波动。这个仓库应采用什么测试策略？

输出示意

• 数据包：flake-cost-packet
• 门禁判定：merge-gate-truth，后续配合 scheduled-breadth-truth
• 主要模式：flake-and-cost-policy
• 必需的变更：
  1. 将 PR 浏览器测试范围缩小到关键用户旅程
  2. 将更广泛的组合测试移至定期运行
  3. 为反复出现的波动制定隔离/修复规则
  4. 在适当情况下，将信心转移到更低层级的集成/组件检查
• 下一负责人：由 backend-testing 负责实施，由 debugging 负责查明当前波动的根本原因

示例 3：发布就绪数据包

输入

工程团队表示测试已通过，但这次发布前还需要其他要求吗？

输出示意

• 数据包：release-readiness-packet
• 门禁判定：release-gate-truth
• 主要模式：release-confidence
• 必需的验证：
  1. 针对变更所影响客户旅程的定向预发布环境冒烟测试
  2. 如果部署形态发生变化，则检查迁移/回滚清单项
  3. 明确说明，除定期覆盖范围外，不需要新增大范围回归测试
• 转交：如果变更涉及大量 UI 状态，则将无障碍专项签核交给 web-accessibility

示例 4：游戏上线清单数据包

输入

我们的构建已通过 CI，但还有 Steam 发布清单事项和打包工作要做。这些工作仍归这里负责吗？

输出示意

• 数据包：release-readiness-packet
• 门禁判定：release-gate-truth
• 主要模式：release-confidence
• 必需的验证：定向最终冒烟测试，以及证明上线/构建清单事项已满足所需的最低限度证据
• 范围外：不要仅仅因为仍有商店/平台上线工作，就扩大阻止分支合并的 PR 检查范围
• 下一负责人：steam-store-launch-ops 和/或 game-ci-cd-pipeline

最佳实践

1. 从手头已有的数据包入手，而不是从偏爱的测试口号入手。
2. 优先选择成本最低、仍能证明高风险行为的测试层级。
3. 明确区分本地、PR、发布和定期运行的循环。
4. 将易波动测试视为策略上的警示信号，而不只是需要重新运行的不便。
5. 将发布清单与实际风险挂钩，而不是把它们视作独立的体系。
6. 说明有意排除的内容，让剩余风险清晰可见。
7. 利用逃逸缺陷逐步补充能够在最低层级发现这些缺陷的回归测试。
8. 明确区分阻止合并的要求、仅发布时需要的验证和定期扩展覆盖范围，不要将它们混为一谈。
9. 将实施工作交给 backend-testing，诊断工作交给 debugging，发布执行工作交给 deployment-automation，平台/游戏上线工作交给 steam-store-launch-ops 或 game-ci-cd-pipeline，无障碍相关验证交给 web-accessibility。
10. 当人工验证是诚实可靠的答案时，就采用人工验证，不要将其视为可耻的退而求其次。
11. 一份简洁的验证简报比一份冗长的测试宣言更易复用。

参考资料

• Martin Fowler — 测试金字塔
• Martin Fowler — 实用测试金字塔
• Google Testing Blog — 对更多端到端测试说不
• Selenium — 测试实践
• Playwright — 最佳实践
• Pact 文档