test-strategy

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

测试策略（Test Strategy）

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

适用场景

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

核心原则

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）

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

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

测试象限（Brian Marick）

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

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

工作流程

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	自动化

自动化优先级

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

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

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

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

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

# [模块] 测试策略

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

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

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

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

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

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

质量自检

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

常见坑

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

配套模板

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

与其他 skill 的协作

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

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