agentleFS
Sign inStart free
KokxiKokxi/qa-test-skills/skills/qa-test-strategy-design/SKILL.md

qa-test-strategy-design

Skill31 starsChanged 48 days agoMITView on GitHub

当新项目启动需要制定测试方案、或者迭代开始前需要确定"这期怎么测"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道"测什么、不测什么、为什么"——其中"不测什么"往往比"测什么"更能体现决策质量。输出风险矩阵、分级测试方案与准入准出标准的测试策略文档。 触发场景：测试策略、怎么测、测试计划、方案设计、测试范围、质量策略、新项目启动确定测试方案时。 Use when the user asks about: test strategy for a new project or iteration — scope, layered approach, entry and exit criteria, risk matrix, and tooling.

The file

Create a free account to mount
Files
SKILL.md

⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

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

测试策略制定

核心原则

一个好的测试策略让团队知道 "测什么、不测什么、为什么"。

其中 "不测什么"往往比"测什么"更能体现决策质量——写不出排除项的策略，本质上是测试清单不是测试策略。

1. 六要素速查

#要素回答什么最容易漏
1项目背景什么阶段、什么团队、多长工期团队对技术栈的熟悉度
2风险分析哪些地方危险进度风险（往往被当成"非技术问题"忽略）
3测试范围测什么 / 不测什么不测什么
4分层策略单元/接口/E2E 各占多少E2E 占比（容易堆太多）
5手段选择哪些自动化、哪些手动判断标准（应看重复次数与结果确定度）
6准入准出什么时候能开始测、什么时候能发本项目采用值与依据

逐要素的评估方法见 references/six-elements.md。

2. 风险等级口径

不在本技能重新定义阈值——直接引用 qa-risk-intuition 的结论：

风险分数等级测试深度
≥ 45高深测
15 – 44中常规
≤ 14低冒烟

同一项目里出现两套风险口径是最容易引发扯皮的事。本技能引用上游 RISK- ID 即可。

3. 策略深度要求

复杂度要素覆盖文档篇幅典型场景
简单项目至少 4 个要素1-2 页摘要内部工具 / 低风险
中等项目全部 6 个要素3-5 页业务系统 / 中等风险
复杂项目全部 6 要素 + 风险评估5-10 页核心系统 / 高风险

4. 加载时机

什么时候读读哪个
逐要素展开评估方法，或要填具体数值references/six-elements.md
写测试策略文档assets/strategy-doc.md（八段式模板 + 填写要求 + 自检）

5. 产出：测试策略文档骨架

**策略 ID**：STRAT-PAY-001   **关联需求**：REQ-PAY-001

### 1. 项目背景      → 阶段/团队/技术栈熟悉度/工期/历史质量
### 2. 风险分析      → 引用 RISK- ID 与等级，本技能不重算阈值
### 3. 测试范围      → 测什么 / **不测什么** / 测到什么程度
### 4. 分层策略      → 单元 60% / 接口 30% / E2E 10% / 探索补充
### 5. 手段选择      → 自动化/手动/工具辅助 + 理由
### 6. 资源分配      → 人力/时间/环境/工具
### 7. 准入准出      → 本项目采用值 + 依据（非照抄模板）
### 8. 风险与应对    → 环境未就绪等外部依赖的预案

完整模板与填写要求见 assets/strategy-doc.md。

本技能不产出 9 列用例表——策略落地为用例由 qa-test-case-design 完成。

6. 两个容易做错的地方

  1. "不测什么"留空 → 策略变成测试清单。必须写出排除项与原因
  2. 准出标准照抄模板 → 长期执行率 100% 的团队把准出定在 95%， 等于没有拦截作用，反而让准出形同虚设。必须显式校准并写出依据。

7. 交付前自检

  • 六要素有内容；简单项目只覆盖 4 个时已说明省略原因
  • 风险等级引用上游 qa-risk-intuition，未另立阈值
  • "不测什么"已明确写出（策略价值一半在这里）
  • 分层占比合计 100%，偏离默认配比已说明理由
  • E2E 占比未超过核心路径所需
  • 准出标准写明了本项目采用值与依据
  • 外部依赖风险（环境/第三方联调）有应对预案
  • 策略 ID STRAT- / 需求 ID REQ- / 风险 ID RISK- 前缀正确
  • 无"全覆盖/100%"绝对化表述

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free