# Test Strategy

> 定测试范围、分层、深度时使用。适用于新模块测试启动、版本测试规划、上线前总测策略。融合测试金字塔、测试象限、Beyoncé Rule。

- Skill: `zhaoxuya520/test-strategy` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add zhaoxuya520/test-strategy`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhaoxuya520/test-strategy/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zhaoxuya520 (https://skillmd.com/u/zhaoxuya520)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhaoxuya520/test-strategy

---


# 测试策略（Test Strategy）

参考来源：Mike Cohn《Succeeding with Agile》测试金字塔、Brian Marick 测试象限、Google《Software Engineering at Google》Beyoncé Rule、ISTQB Foundation。

## 适用场景

- 新模块测试启动（决定测多深 / 哪些层）
- 版本发布前总测规划
- 测试资源 / 时间紧张时的取舍
- 自动化与手工测试的边界划分
- 跨工作流测试责任划分

## 核心原则

```text
1. 风险驱动，不是覆盖驱动
   "覆盖每个分支" ≠ "覆盖每个风险"

2. 分层不分割
   单元 + 集成 + E2E + 探索，缺一层都漏

3. Beyoncé Rule（Google）
   "If you liked it, you should have put a test on it."
   用例必须能阻止回归，不能只是文档

4. 不重复测同一件事
   下层测过的，上层不用重复

5. 测试不是验证开发对，是发现"它错了"
   QA 视角 ≠ Dev 视角
```

## 测试金字塔（Mike Cohn）

```text
        /\
       /E2\         少：5%~10%（用户旅程，慢、贵）
      /----\
     / 集成 \       中：20%~30%（API、跨模块）
    /--------\
   /   单元   \    多：60%~70%（快、便宜）
  /------------\
```

倒金字塔（反模式）：E2E 多 + 单元少 → 慢、脆弱、定位难。

## 测试象限（Brian Marick）

```text
                  支持团队 (Q1, Q2)
                  ↑
   Q2 业务面手工 ─┼─ Q1 技术面自动
   (探索式 / UAT) │ (单元 / 集成)
   ───────────────┼───────────────
   Q3 业务面探索 │ Q4 技术面工具
   (可用性 / β)   │ (性能 / 安全)
                  ↓
                  评估产品 (Q3, Q4)
```

测试策略需要 4 个象限都覆盖（按比例不同）。

## 工作流程

```text
1. 输入收集
   - PRD / API 契约 / 变更说明 / 风险点

2. 范围划分
   - 哪些必测（核心业务）
   - 哪些选测（次要功能）
   - 哪些不测（已废弃 / 风险极低）

3. 分层规划
   - 单元层（开发负责）
   - 集成层（API 契约 / 跨模块）
   - E2E 层（关键用户旅程，5~15 条）
   - 探索式（无脚本，1~2 小时 session）

4. 自动化 vs 手工
   - 自动化：稳定、重复、回归核心
   - 手工：探索、UI 视觉、新功能首次测

5. 资源和时间分配
   - 风险高优先
   - 历史 Bug 多优先

6. 输出测试策略文档
   - 1 页纸说清范围、分层、责任、时间
```

## 范围划分决策表

| 模块特征 | 必测 | 选测 | 不测 |
|---|---|---|---|
| 涉及钱 / 支付 / 扣减 | ✅ 全路径 | - | - |
| 涉及权限 / 隐私 | ✅ 全路径 | - | - |
| 数据写入 / 状态流转 | ✅ 主要状态 | 边缘状态 | - |
| 新增功能 | ✅ 主路径 + 失败 | 边界 | - |
| Bug 修复 | ✅ 复现路径 + 回归 | - | - |
| 重构（行为不变） | ✅ 影响面 | - | 内部实现 |
| 实验性功能 | 主路径 | - | 完整覆盖 |
| 已废弃 | - | - | ✅ 跳过 |

## 分层选择决策表

| 测试类型 | 适合层 | 不适合层 |
|---|---|---|
| 业务规则正确性 | 单元 / 集成 | E2E（慢） |
| API 契约 | 集成 / 契约测试 | 单元（不真实） |
| 用户关键旅程 | E2E（少量） | 单元（无业务价值） |
| 性能 | 性能专项 | 单元 / E2E |
| 视觉回归 | 视觉测试工具 | 手工肉眼 |
| 探索式 | 手工 session | 自动化 |

## 自动化优先级

```text
高优先（必自动化）：
  - 核心业务主路径
  - 高频回归路径
  - 数据校验 / 计算 / 状态流转

中优先（可自动化）：
  - 失败路径（错误码 / 校验）
  - 权限矩阵

低优先（保留手工）：
  - UI 视觉 / 交互流畅度
  - 新功能首测
  - 探索式

不自动化：
  - 一次性测试
  - 频繁变化的 UI
  - 第三方不可控依赖
```

## 测试策略输出（一页纸模板）

```markdown
# [模块] 测试策略

## 范围
必测：[列表]
选测：[列表]
不测：[列表 + 原因]

## 分层
- 单元：[由谁 / 覆盖率目标]
- 集成：[API 契约 / 跨模块]
- E2E：[5~15 条关键旅程]
- 探索式：[2 个 90 分钟 session]

## 风险关注
- 高风险：[路径 + 测试方式]
- 中风险：[路径 + 测试方式]

## 自动化策略
- 自动化：[范围]
- 手工保留：[范围]

## 时间和资源
预计工时：X 小时
依赖：[环境 / 数据 / 人]

## 退出条件
- 必测用例 100% 通过
- 高风险 Bug 0
- 中风险 Bug ≤ 2 且有 workaround
```

## 质量自检

```text
□ 是否覆盖所有验收标准
□ 是否按风险分配测试时间
□ 是否四个测试象限都有覆盖
□ 是否明确"不测"的范围和原因
□ 是否定义了退出条件
□ 是否给出自动化 vs 手工的边界
□ 历史 Bug 是否纳入回归
□ 是否考虑测试数据和环境
```

## 常见坑

1. **覆盖驱动而非风险驱动**——平均用力，高风险测得不深
2. **倒金字塔**——E2E 太多、单元太少，跑 1 小时定位 4 小时
3. **不分层重复测**——同一规则单元、集成、E2E 各测一遍
4. **不写"不测"清单**——边界模糊，事后扯皮
5. **没有退出条件**——什么时候算测完不知道
6. **自动化追求 100%**——把不该自动化的也自动化，维护爆炸
7. **忽略象限 Q3/Q4**——只测功能，漏可用性、性能、安全
8. **第三方依赖没策略**——CI 时断时续

## 配套模板

- `templates/test-strategy-template.md` — 测试策略一页纸 + 范围 + 分层 + 退出条件

## 与其他 skill 的协作

```text
上游：
  （工作流入口）→ PRD / API 契约 / 变更说明

下游：
  risk-based-testing → 风险分级
  test-case-design → 设计用例
  regression-testing → 回归套件维护
  quality-gate → 退出条件落地为门禁
```