Skills
skills/naodeng/awesome-qa-skills/test-strategy

test-strategy

SKILL.md

测试策略（中文版）

英文版： 见技能 test-strategy-en。

提示词见本目录 prompts/test-strategy.md。

何时使用

  • 用户提到「测试策略」「test strategy」「测试计划」「质量策略」
  • 需要为项目制定测试策略或计划
  • 触发示例：「为这个项目制定测试策略」「编写测试计划文档」

输出格式选项

本技能默认输出为 Markdown（与 Standard-version 模板一致）。若需其他格式，请在需求末尾明确说明：

格式 说明 如何请求（示例）
Markdown 默认，便于阅读与版本管理 无需额外说明
Excel 制表符分隔，可粘贴到 Excel 「请以 Excel 可粘贴的制表符分隔表格输出」
PDF 正式文档格式 「请以 PDF 格式输出」
JSON 便于程序解析 「请以 JSON 形式输出」

详细说明与示例见本目录 output-formats.md。

如何使用

  1. 打开本目录 prompts/ 下对应提示词文件，复制虚线以下内容。
  2. 附加你的需求与上下文（业务流程、环境、约束、验收标准）。
  3. 若需非 Markdown 输出，在末尾追加 output-formats.md 中的请求句。

参考文件

代码示例 | Code Examples

本技能提供以下真实代码示例：

  1. 测试策略模板集 - 完整的测试策略模板

    • 敏捷项目测试策略
    • 瀑布项目测试策略
    • 移动应用测试策略
    • API 测试策略
    • 微服务测试策略
    • 风险评估矩阵
    • 资源规划模板

  2. 策略生成工具（即将推出）

  3. 风险评估工具（即将推出）

可参考 模板库 获取可复用模板。

常见误区 | Common Pitfalls

  • ❌ 策略太泛泛 → ✅ 针对项目特点制定具体策略
  • ❌ 忽略风险评估 → ✅ 识别和评估测试风险
  • ❌ 资源规划不足 → ✅ 明确人员、时间、工具需求
  • ❌ 缺少度量指标 → ✅ 定义明确的质量目标和度量
  • ❌ 策略一成不变 → ✅ 根据项目进展调整策略
  • ❌ 只关注功能测试 → ✅ 覆盖性能、安全、兼容性等
  • ❌ 没有退出标准 → ✅ 明确测试完成和发布标准

最佳实践 | Best Practices

1. 测试策略核心要素

完整的测试策略应包含：

# 测试策略文档

## 1. 项目概述
- 项目背景
- 项目目标
- 项目范围

## 2. 测试目标
- 质量目标
- 覆盖率目标
- 性能目标

## 3. 测试范围
- 包含的功能
- 排除的功能
- 测试类型

## 4. 测试方法
- 测试级别（单元/集成/系统/验收）
- 测试类型（功能/性能/安全/兼容性）
- 测试技术（黑盒/白盒/灰盒）

## 5. 测试环境
- 硬件要求
- 软件要求
- 网络要求
- 测试数据

## 6. 测试工具
- 测试管理工具
- 自动化工具
- 性能测试工具
- 缺陷管理工具

## 7. 资源规划
- 人员配置
- 时间安排
- 预算估算

## 8. 风险管理
- 风险识别
- 风险评估
- 缓解措施

## 9. 测试交付物
- 测试计划
- 测试用例
- 测试报告
- 缺陷报告

## 10. 进入/退出标准
- 测试开始条件
- 测试完成条件
- 发布标准

2. 测试金字塔策略

        /\
       /  \  E2E Tests (10%)
      /____\
     /      \
    / Integration \ (30%)
   /    Tests     \
  /______________\
 /                \
/  Unit Tests (60%) \
/____________________\

分层测试策略：

  • 单元测试（60%）: 快速、稳定、低成本
  • 集成测试（30%）: 验证模块间交互
  • 端到端测试（10%）: 验证关键业务流程

3. 风险驱动测试

风险评估矩阵：

功能模块 业务影响 技术复杂度 变更频率 风险等级 测试优先级
支付 高 高 低 高 P0
登录 高 中 低 高 P0
搜索 中 高 中 中 P1
推荐 中 高 高 中 P1
评论 低 低 低 低 P2

风险等级计算：

风险等级 = (业务影响 + 技术复杂度 + 变更频率) / 3

4. 敏捷测试策略

Sprint 测试活动：

## Sprint 规划（Day 1）
- [ ] 参与 Sprint Planning
- [ ] 理解用户故事
- [ ] 识别测试任务
- [ ] 估算测试工作量

## Sprint 执行（Day 2-9）
- [ ] 编写测试用例
- [ ] 执行探索性测试
- [ ] 自动化回归测试
- [ ] 缺陷跟踪

## Sprint 评审（Day 10）
- [ ] 演示测试结果
- [ ] 收集反馈
- [ ] 更新测试策略

## Sprint 回顾（Day 10）
- [ ] 总结测试经验
- [ ] 识别改进点
- [ ] 更新最佳实践

5. 测试类型覆盖

全面的测试类型：

测试类型 目标 工具 频率
单元测试 代码质量 Jest, Pytest 每次提交
集成测试 模块交互 Postman, Pytest 每日构建
功能测试 业务功能 Playwright, Selenium 每个 Sprint
性能测试 响应时间、吞吐量 K6, JMeter 每个版本
安全测试 漏洞扫描 OWASP ZAP 每个版本
兼容性测试 跨浏览器、设备 BrowserStack 发布前
可访问性测试 WCAG 合规 axe-core 发布前
探索性测试 发现未知问题 手工 持续进行

6. 自动化策略

自动化决策树：

测试是否重复执行？
  否 → 手工测试
  是 ↓

测试是否稳定？
  否 → 手工测试
  是 ↓

自动化成本 < 手工成本？
  否 → 手工测试
  是 → 自动化测试

自动化优先级：

  1. 高优先级：冒烟测试、回归测试、API 测试
  2. 中优先级：功能测试、集成测试
  3. 低优先级：探索性测试、可用性测试

7. 测试度量指标

关键指标：

## 过程指标
- 测试用例数量
- 测试执行率
- 自动化覆盖率
- 缺陷发现率

## 质量指标
- 缺陷密度（缺陷数/KLOC）
- 缺陷逃逸率
- 缺陷修复时间
- 测试通过率

## 效率指标
- 测试执行时间
- 自动化节省时间
- 测试 ROI
- 团队生产力

故障排除 | Troubleshooting

问题1：不知道如何开始制定策略

症状：面对新项目不知从何下手

解决方案：

使用 5W2H 分析法：

## 测试策略分析

### What（测什么）
- 功能需求
- 非功能需求
- 业务流程
- 用户体验

### Why（为什么测）
- 质量保证
- 风险控制
- 用户满意度
- 合规要求

### Who（谁来测）
- 测试团队
- 开发团队
- 业务团队
- 最终用户

### When（何时测）
- 单元测试：开发阶段
- 集成测试：集成阶段
- 系统测试：测试阶段
- 验收测试：发布前

### Where（在哪测）
- 开发环境
- 测试环境
- 预发布环境
- 生产环境

### How（如何测）
- 手工测试
- 自动化测试
- 探索性测试
- 性能测试

### How Much（投入多少）
- 人员：X 人
- 时间：Y 周
- 预算：Z 元
- 工具：列表

问题2：测试范围不清晰

症状：不确定哪些需要测试，哪些不需要

解决方案：

创建 测试范围矩阵：

## 测试范围定义

### 包含范围（In Scope）
| 功能模块 | 测试类型 | 优先级 | 负责人 |
|---------|---------|--------|--------|
| 用户登录 | 功能、安全、性能 | P0 | 张三 |
| 商品搜索 | 功能、性能 | P1 | 李四 |
| 订单支付 | 功能、安全、集成 | P0 | 王五 |

### 排除范围（Out of Scope）
| 项目 | 原因 | 备注 |
|------|------|------|
| 第三方支付内部逻辑 | 外部系统 | 只测试集成点 |
| 历史数据迁移 | 一次性任务 | 由 DBA 负责 |
| 管理后台（旧版） | 即将下线 | 不再维护 |

### 假设和依赖（Assumptions & Dependencies）
- 测试环境在 Sprint 开始前就绪
- 测试数据由开发团队提供
- 第三方 API 在测试环境可用

问题3：资源不足，无法完成所有测试

症状：时间、人员、预算有限

解决方案：

采用 基于风险的测试：

## 风险驱动的测试优先级

### 高风险区域（必须测试）
- 支付流程
- 用户认证
- 数据安全
- 核心业务逻辑

### 中风险区域（应该测试）
- 搜索功能
- 推荐算法
- 通知系统
- 报表生成

### 低风险区域（可选测试）
- UI 美化
- 帮助文档
- 统计分析
- 日志记录

### 资源分配
- 高风险：60% 资源
- 中风险：30% 资源
- 低风险：10% 资源

问题4：测试策略与实际脱节

症状：策略文档写得很好，但实际执行不了

解决方案：

制定 可执行的策略：

## 可执行测试策略

### 每日活动
- [ ] 09:00 - 站会同步测试进展
- [ ] 09:30 - 执行冒烟测试
- [ ] 10:00 - 执行新功能测试
- [ ] 14:00 - 缺陷验证和回归测试
- [ ] 17:00 - 更新测试报告

### 每周活动
- [ ] 周一：Sprint Planning，识别测试任务
- [ ] 周三：测试进度检查
- [ ] 周五：Sprint Review，演示测试结果

### 每 Sprint 活动
- [ ] Sprint 开始：制定测试计划
- [ ] Sprint 中期：执行测试，跟踪缺陷
- [ ] Sprint 结束：测试总结，回顾改进

### 检查点
- [ ] 代码提交后 30 分钟内完成冒烟测试
- [ ] 每个用户故事完成后 2 小时内完成功能测试
- [ ] Sprint 结束前 1 天完成回归测试

问题5：不同环境的测试策略

症状：不知道在不同环境应该做什么测试

解决方案：

环境测试矩阵：

## 环境测试策略

### 开发环境（Dev）
- **目的**：快速验证代码变更
- **测试类型**：单元测试、冒烟测试
- **频率**：每次代码提交
- **自动化**：100%

### 测试环境（QA）
- **目的**：全面功能测试
- **测试类型**：功能、集成、回归
- **频率**：每日构建
- **自动化**：80%

### 预发布环境（Staging）
- **目的**：生产环境模拟
- **测试类型**：端到端、性能、安全
- **频率**：发布前
- **自动化**：60%

### 生产环境（Production）
- **目的**：监控和验证
- **测试类型**：冒烟测试、监控
- **频率**：发布后、持续监控
- **自动化**：100%

问题6：敏捷项目中如何制定策略

症状：敏捷项目变化快，策略难以制定

解决方案：

采用 轻量级敏捷测试策略：

## 敏捷测试策略

### 测试四象限

**象限 1：技术面向，支持团队**
- 单元测试
- 组件测试
- 自动化优先

**象限 2：业务面向，支持团队**
- 功能测试
- 用户故事测试
- 示例驱动

**象限 3：业务面向，评价产品**
- 探索性测试
- 可用性测试
- 用户验收测试

**象限 4：技术面向，评价产品**
- 性能测试
- 安全测试
- 可维护性测试

### 测试活动融入 Sprint

**Sprint Planning**:
- 参与用户故事讨论
- 识别测试任务
- 定义验收标准

**Daily Standup**:
- 同步测试进展
- 识别阻塞问题
- 调整测试计划

**Sprint Review**:
- 演示测试结果
- 收集反馈
- 验证验收标准

**Sprint Retrospective**:
- 回顾测试过程
- 识别改进点
- 更新测试实践

问题7：如何衡量测试策略的有效性

症状：不知道策略是否有效

解决方案：

定义 测试策略 KPI：

## 测试策略有效性指标

### 质量指标
| 指标 | 目标 | 当前 | 状态 |
|------|------|------|------|
| 生产缺陷数 | < 5/月 | 3/月 | ✅ |
| 缺陷逃逸率 | < 5% | 3% | ✅ |
| 严重缺陷数 | 0 | 0 | ✅ |
| 客户投诉数 | < 2/月 | 1/月 | ✅ |

### 效率指标
| 指标 | 目标 | 当前 | 状态 |
|------|------|------|------|
| 测试自动化率 | > 80% | 85% | ✅ |
| 测试执行时间 | < 2h | 1.5h | ✅ |
| 缺陷修复时间 | < 2天 | 1.5天 | ✅ |
| 发布频率 | 2周/次 | 2周/次 | ✅ |

### 覆盖率指标
| 指标 | 目标 | 当前 | 状态 |
|------|------|------|------|
| 需求覆盖率 | 100% | 100% | ✅ |
| 代码覆盖率 | > 80% | 85% | ✅ |
| 自动化覆盖率 | > 70% | 75% | ✅ |

### 改进建议
- ✅ 质量指标达标，继续保持
- ⚠️  考虑提高发布频率到每周
- 💡 探索 AI 辅助测试提高效率

获取更多帮助

如果问题仍未解决：

  1. 查看 FAQ.md
  2. 查看示例的 README.md 文件
  3. 参考测试策略模板
  4. 咨询团队的测试经理

相关技能： requirements-analysis、test-case-writing、test-reporting、functional-testing。

目标受众

  • 在真实项目中执行该测试域工作的 QA 与开发人员
  • 需要结构化、可复用测试交付物的测试负责人
  • 需要快速生成可落地测试产出的 AI 使用者

不适用场景

  • 无测试范围上下文的纯线上应急处置
  • 需要法律/合规最终裁定但缺少专家复核的决策
  • 缺少最小输入（范围、环境、期望行为）的请求

关键成功因素

  • 先明确范围、环境与验收标准，再生成测试内容
  • 生成结果必须结合真实系统约束做二次校验
  • 保持产物可追踪（需求 -> 测试点 -> 缺陷 -> 决策）

输出模板与解析脚本

  • 模板目录：output-templates/
    • template-word.md（Word 友好结构）
    • template-excel.tsv（Excel 可直接粘贴）
    • template-xmind.md（XMind 结构化大纲）
    • template-json.json
    • template-csv.csv
    • template-markdown.md
  • 解析脚本目录：scripts/
    • 解析通用：parse_output_formats.py
    • 解析按格式：parse_word.py、parse_excel.py、parse_xmind.py、parse_json.py、parse_csv.py、parse_markdown.py
    • 转换通用：convert_output_formats.py
    • 转换按格式：convert_to_word.py、convert_to_excel.py、convert_to_xmind.py、convert_to_json.py、convert_to_csv.py、convert_to_markdown.py
    • 批量转换：batch_convert_templates.py（批量输出到 artifacts/）

示例：

python3 scripts/parse_json.py output-templates/template-json.json
python3 scripts/parse_markdown.py output-templates/template-markdown.md
python3 scripts/convert_to_json.py output-templates/template-markdown.md
python3 scripts/convert_output_formats.py output-templates/template-json.json --to csv
python3 scripts/batch_convert_templates.py --skip-same
Weekly Installs
8
Repository
naodeng/awesome…a-skills
GitHub Stars
3
First Seen
12 days ago
Security Audits
Gen Agent Trust HubPass
SocketFail
SnykPass
Installed on
cursor8
gemini-cli7
github-copilot7
codex7
amp7
cline7