zhaoxuya520 测试策略（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 是否纳入回归
□ 是否考虑测试数据和环境
常见坑
- 覆盖驱动而非风险驱动——平均用力，高风险测得不深
- 倒金字塔——E2E 太多、单元太少，跑 1 小时定位 4 小时
- 不分层重复测——同一规则单元、集成、E2E 各测一遍
- 不写"不测"清单——边界模糊，事后扯皮
- 没有退出条件——什么时候算测完不知道
- 自动化追求 100%——把不该自动化的也自动化，维护爆炸
- 忽略象限 Q3/Q4——只测功能，漏可用性、性能、安全
- 第三方依赖没策略——CI 时断时续
配套模板
templates/test-strategy-template.md— 测试策略一页纸 + 范围 + 分层 + 退出条件
与其他 skill 的协作
上游：
（工作流入口）→ PRD / API 契约 / 变更说明
下游：
risk-based-testing → 风险分级
test-case-design → 设计用例
regression-testing → 回归套件维护
quality-gate → 退出条件落地为门禁