测试策略设计

⚠️ 安全警告：本技能的示例可能涉及发布评估和 CI/CD 流水线的策略引用。 这些是策略参考不是直接操作；请勿未经授权即执行发布或变更流水线配置。 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

测试策略制定

核心原则

根据项目特征（工期/复杂度/团队/风险）制定分层测试策略。

深度要求（参考值）

关键指标：根据项目复杂度调整策略深度

测试策略六要素

要素1：项目背景评估

评估维度：
├─ 项目阶段：新项目/迭代优化/维护阶段
├─ 团队规模：人员数量和经验水平
├─ 技术栈：技术复杂度和团队熟悉度
├─ 工期：开发周期和测试周期
└─ 历史质量：历史Bug密度和漏测率

评估结果：
- 项目阶段：[新项目/迭代/维护]
- 团队：[X人，经验水平]
- 技术栈：[复杂度]
- 工期：[X周]
- 历史质量：[Bug密度/漏测率]

要素2：风险分析

风险识别：
├─ 业务风险：核心功能/资金/安全
├─ 技术风险：新架构/复杂逻辑/第三方
├─ 进度风险：工期紧/人员不足
└─ 质量风险：历史问题多/复杂度高

风险等级：
- 高风险：必须深测
- 中风险：常规测试
- 低风险：冒烟测试

要素3：分层策略

测试金字塔：
                    ┌─────────┐
                    │  E2E测试  │  10%
                    ├─────────┤
                    │  接口测试  │  30%
                    ├─────────┤
                    │  单元测试  │  60%
                    └─────────┘

分层比例：
├─ 单元测试：60-70%（核心逻辑）
├─ 接口测试：20-30%（业务流程）
├─ E2E测试：10%（核心路径）
└─ 探索测试：补充（复杂场景）

要素4：手段选择

自动化 vs 手动：
├─ 自动化：回归测试/冒烟测试/数据驱动
├─ 手动：探索测试/用户体验/兼容性
└─ 工具辅助：性能测试/安全测试/接口测试

选择依据：
- 重复执行：自动化
- 复杂判断：手动
- 数据驱动：自动化
- 探索性：手动

要素5：资源分配

资源分配：
├─ 人力分配：测试人员角色和任务
├─ 时间分配：各阶段测试时间
├─ 环境分配：测试环境准备
└─ 工具分配：测试工具准备

时间分配：
- 需求分析：10%
- 用例设计：20%
- 测试执行：50%
- 回归测试：15%
- 报告总结：5%

要素6：准入准出标准

准入标准：
├─ 需求评审通过
├─ 开发自测通过
├─ 冒烟测试通过
├─ 测试环境就绪
└─ 测试数据准备

准出标准：
├─ 用例执行率 ≥ 95%
├─ 用例通过率 ≥ 90%
├─ 高严重度Bug修复率 = 100%
├─ 中严重度Bug修复率 ≥ 90%
└─ 无阻塞性Bug

策略输出模板

# 测试策略

## 1. 项目背景
- 项目阶段：[阶段]
- 团队：[规模和经验]
- 技术栈：[复杂度]
- 工期：[周期]

## 2. 风险分析
- 高风险区域：[列表]
- 中风险区域：[列表]
- 低风险区域：[列表]

## 3. 测试策略
- 单元测试：[比例和范围]
- 接口测试：[比例和范围]
- E2E测试：[比例和范围]
- 探索测试：[比例和范围]

## 4. 手段选择
- 自动化范围：[哪些需要自动化]
- 手动范围：[哪些需要手动]
- 工具选择：[使用什么工具]

## 5. 资源分配
- 人力：[分配方案]
- 时间：[时间节点]
- 环境：[环境准备]
- 工具：[工具准备]

## 6. 准入准出
- 准入标准：[标准列表]
- 准出标准：[标准列表]

输出示例

电商下单功能测试策略（工期2周，团队4人） → 背景评估：核心功能+高并发+三方支付，中高风险 → 分层策略：单元（开发自测）→集成（支付接口深测）→E2E（全流程冒烟） → 手段选择：接口自动化为主，UI自动化覆盖核心路径，探索式测试做补盲 → 资源分配：接口自动化3人×5天，UI自动化1人×3天，探索1人×2天

新项目启动，PM问"怎么测" → 启动测试策略六要素系统化评估，输出可执行的测试方案

检查清单

测试策略完成后检查：

• 项目背景评估是否完整？
• 风险分析是否准确？
• 分层策略是否合理？
• 手段选择是否恰当？
• 资源分配是否可行？
• 准入准出是否明确？