References: Mike Cohn's test pyramid in "Succeeding with Agile", Brian Marick's testing quadrants, the Beyoncé Rule from Google's "Software Engineering at Google", ISTQB Foundation.
Applicable Scenarios
- New module test kickoff (deciding how deep to test / which layers)
- Overall test planning before a release
- Trade-offs when test resources / time are tight
- Drawing the boundary between automated and manual testing
- Dividing test responsibilities across workflows
Core Principles
1. 风险驱动，不是覆盖驱动
"覆盖每个分支" ≠ "覆盖每个风险"
-
Layered, not siloed Unit + integration + E2E + exploratory; missing any layer leaves gaps
-
Beyoncé Rule (Google) "If you liked it, you should have put a test on it." Test cases must be able to prevent regressions, not just serve as documentation
-
Don't test the same thing twice What has been tested at a lower layer need not be repeated at a higher layer
-
Testing is not about verifying that development is correct, but about discovering "it's wrong" QA perspective ≠ Dev perspective
## 测试金字塔（Mike Cohn）
```text
/\
/E2\ 少：5%~10%（用户旅程，慢、贵）
/----\
/ 集成 \ 中：20%~30%（API、跨模块）
/--------\
/ 单元 \ 多：60%~70%（快、便宜）
/------------\
Inverted pyramid (anti-pattern): many E2E + few unit → slow, fragile, hard to localize.
Testing Quadrants (Brian Marick)
支持团队 (Q1, Q2)
↑
Q2 业务面手工 ─┼─ Q1 技术面自动
(探索式 / UAT) │ (单元 / 集成)
───────────────┼───────────────
Q3 业务面探索 │ Q4 技术面工具
(可用性 / β) │ (性能 / 安全)
↓
评估产品 (Q3, Q4)
A test strategy needs to cover all 4 quadrants (in different proportions).
Workflow
1. 输入收集
- PRD / API 契约 / 变更说明 / 风险点
2. 范围划分
- 哪些必测（核心业务）
- 哪些选测（次要功能）
- 哪些不测（已废弃 / 风险极低）
3. 分层规划
- 单元层（开发负责）
- 集成层（API 契约 / 跨模块）
- E2E 层（关键用户旅程，5~15 条）
- 探索式（无脚本，1~2 小时 session）
4. 自动化 vs 手工
- 自动化：稳定、重复、回归核心
- 手工：探索、UI 视觉、新功能首次测
5. 资源和时间分配
- 风险高优先
- 历史 Bug 多优先
6. 输出测试策略文档
- 1 页纸说清范围、分层、责任、时间
Scope Division Decision Table
| Module Characteristic | Must Test | Optional Test | Do Not Test |
|---|---|---|---|
| Involves money / payment / deduction | ✅ All paths | - | - |
| Involves permissions / privacy | ✅ All paths | - | - |
| Data writes / state transitions | ✅ Main states | Edge states | - |
| New feature | ✅ Main path + failure | Boundaries | - |
| Bug fix | ✅ Reproduction path + regression | - | - |
| Refactoring (behavior unchanged) | ✅ Impact surface | - | Internal implementation |
| Experimental feature | Main path | - | Full coverage |
| Deprecated | - | - | ✅ Skip |
Layer Selection Decision Table
| Test Type | Suitable Layer | Unsuitable Layer |
|---|---|---|
| Business rule correctness | Unit / integration | E2E (slow) |
| API contract | Integration / contract testing | Unit (unrealistic) |
| Critical user journeys | E2E (a small number) | Unit (no business value) |
| Performance | Dedicated performance testing | Unit / E2E |
| Visual regression | Visual testing tools | Manual eyeballing |
| Exploratory | Manual session | Automation |
Automation Priority
高优先（必自动化）：
- 核心业务主路径
- 高频回归路径
- 数据校验 / 计算 / 状态流转
中优先（可自动化）：
- 失败路径（错误码 / 校验）
- 权限矩阵
低优先（保留手工）：
- UI 视觉 / 交互流畅度
- 新功能首测
- 探索式
不自动化：
- 一次性测试
- 频繁变化的 UI
- 第三方不可控依赖
Test Strategy Output (One-Page Template)
# [模块] 测试策略
## 范围
必测：[列表]
选测：[列表]
不测：[列表 + 原因]
## 分层
- 单元：[由谁 / 覆盖率目标]
- 集成：[API 契约 / 跨模块]
- E2E：[5~15 条关键旅程]
- 探索式：[2 个 90 分钟 session]
## 风险关注
- 高风险：[路径 + 测试方式]
- 中风险：[路径 + 测试方式]
## 自动化策略
- 自动化：[范围]
- 手工保留：[范围]
## 时间和资源
预计工时：X 小时
依赖：[环境 / 数据 / 人]
## 退出条件
- 必测用例 100% 通过
- 高风险 Bug 0
- 中风险 Bug ≤ 2 且有 workaround
Quality Self-Check
□ 是否覆盖所有验收标准
□ 是否按风险分配测试时间
□ 是否四个测试象限都有覆盖
□ 是否明确"不测"的范围和原因
□ 是否定义了退出条件
□ 是否给出自动化 vs 手工的边界
□ 历史 Bug 是否纳入回归
□ 是否考虑测试数据和环境
Common Pitfalls
- Coverage-driven rather than risk-driven— Even effort across the board, high risks are not tested deeply
- Inverted pyramid— Too many E2E, too few unit tests; run for 1 hour, spend 4 hours localizing
- Repeated testing without layering— The same rule is tested once each at unit, integration, and E2E levels
- Not writing a "not tested" list— Boundaries are vague, leading to disputes afterward
- No exit criteria— No one knows when testing is considered complete
- Automation pursues 100%— Automating what should not be automated, causing a maintenance explosion
- Ignoring quadrants Q3/Q4— Testing only functionality, missing usability, performance, and security
- No strategy for third-party dependencies— CI is intermittent
Supporting templates
templates/test-strategy-template.md— Test strategy one-pager + scope + layering + exit criteria
Collaboration with other skills
上游：
（工作流入口）→ PRD / API 契约 / 变更说明
下游：
risk-based-testing → 风险分级
test-case-design → 设计用例
regression-testing → 回归套件维护
quality-gate → 退出条件落地为门禁