What makes qa-test-strategy-design notable?

1.2K downloads. Trust evidence available

How should qa-test-strategy-design be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

qa-test-strategy-design

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

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.2k

Updated

Oct 11, 2026

Version

1.8.0

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.2K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.2K downloadsadoption · observed Oct 11, 2026
Latest release: 1.8.0release · observed Sep 29, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s170jw3s1atcj5jwhqb4r7v7eh8912kp:qa-test-strategy-design

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-strategy-design/snapshot"

Documentation

CLAWHUB

69,392 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: qa-test-strategy-design
description: >-
  当新项目启动需要制定测试方案、或者迭代开始前需要确定"这期怎么测"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道"测什么、不测什么、为什么"——其中"不测什么"往往比"测什么"更能体现决策质量。输出风险矩阵、分级测试方案与准入准出标准的测试策略文档。
  触发场景：测试策略、怎么测、测试计划、方案设计、测试范围、质量策略、新项目启动确定测试方案时。 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.
license: MIT
allowed-tools: Read Grep Glob
metadata:
  display-name: "Test Strategy Design"
  version: "1.8.0"
  when-to-use: "用户说\"测试策略\"、\"怎么测\"、\"测试计划\"、\"方案设计\"、\"测试范围\"、\"质量策略\"、需要制定测试策略、新项目启动确定测试方案时"
  related-skills: "{\"upstream\":[\"qa-risk-intuition\",\"qa-req-deconstruction\"],\"downstream\":[\"qa-release-risk-governance\",\"qa-ci-cd-testing\",\"qa-specialized-testing\",\"qa-tech-selection\",\"qa-test-automation-arch\",\"qa-test-env-data\"]}"
  references: "[\"references/six-elements.md\",\"assets/strategy-doc.md\"]"
  input-format: "{\"required\":[{\"name\":\"风险评估\",\"type\":\"object\",\"description\":\"来自qa-risk-intuition的风险评估结果（含 RISK- ID 与等级）\"},{\"name\":\"需求分析\",\"type\":\"object\",\"description\":\"来自qa-req-deconstruction的需求分析结果\"}],\"optional\":[{\"name\":\"项目计划\",\"type\":\"string\",\"description\":\"项目时间线和里程碑\"},{\"name\":\"资源约束\",\"type\":\"string\",\"description\":\"测试资源限制\"}]}"
  output-format: "{\"traceability\":[\"每份策略带唯一ID：STRAT-{模块缩写}-{三位序号}\",\"关联需求ID：REQ-{需求模块缩写}-{序号}\",\"引用上游风险ID：RISK-{模块缩写}-{风险类型}-{三位序号}（风险等级直接沿用 qa-risk-intuition 结论，本技能不重算）\"],\"structure\":[{\"strategy_doc\":\"测试策略文档：项目背景|风险分析|测试范围(含不测什么)|分层策略|手段选择|资源分配|准入准出|风险应对\"},\"深度要求：简单项目至少覆盖4个要素（1-2页摘要）/ 中等与复杂项目覆盖全部6个要素（3-10页）\",\"准出百分比为默认模板值，必须由项目显式校准并写出依据\",\"本技能不产出 9 列用例表 —— 策略落地为用例由 qa-test-case-design 完成\",\"覆盖率：标注口径（基于现有需求/风险评估范围），禁止\\\"全覆盖/100%\\\"绝对化表述\"]}"
  error-recovery-guidance: "{\"on_failure\":\"策略遗漏高风险区域时回退到风险评估补充\",\"retry_behavior\":\"补充评估后重新制定策略\"}"
  categories: "[\"Development\",\"Testing\",\"DevOps\"]"
  depth-requirement: "{\"reference_value\":\"见正文「策略深度要求」表：简单/中等/复杂项目对应不同要素覆盖数与文档篇幅\",\"minimum\":\"至少覆盖 项目背景/测试范围/风险分析/资源分配 4 个核心维度；未覆盖要素须说明原因\"}"
---

> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（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 |

_meta.json

{
  "ownerId": "kn71y9b23csfx0ykgm55d5m9x5891zt8",
  "slug": "qa-test-strategy-design",
  "version": "1.8.0",
  "publishedAt": 1790656189195
}

references/six-elements.md

# 测试策略六要素详解

> 本文是 `qa-test-strategy-design` 的**方法详图**。需要逐要素展开、或要填具体数值时读本文；
> 只想知道策略该覆盖哪几块时读 `SKILL.md` 的六要素速查即可。

---

## 要素 1：项目背景评估

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

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

> **"团队熟悉度"比"技术复杂度"更重要**。团队不熟的新技术栈，风险主要来自
> 理解偏差而非实现难度——这两类风险要用不同手段应对。

---

## 要素 2：风险分析

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

> **风险等级与测试深度的映射统一由 `qa-risk-intuition` 定义**（≥45 高→深测 /
> 15-44 中→常规 / ≤14 低→冒烟）。本技能**不重新定义阈值**，
> 直接引用上游评估结论——避免同一项目里出现两套风险口径。

---

## 要素 3：分层策略

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

分层比例（按业务风险调整）：
├─ 单元测试：60-70%（核心逻辑，开发者自测）
├─ 接口测试：20-30%（业务流程，服务间契约）
├─ E2E 测试：10%（核心路径，成本最高）
└─ 探索测试：补充（复杂场景、自动化难覆盖的部分）
```

> **不要在 CI 里堆满慢的 E2E**。E2E 只跑核心路径，其余靠接口层拦截。
> 分层配比的具体落地（流水线卡点）交 `qa-ci-cd-testing`。

---

## 要素 4：手段选择

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

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

> 判断标准是**重复次数**与**结果确定度**，不是"这个功能重不重要"。
> 一次性的核心功能手工测完全合理；天天跑的边缘功能反而必须自动化。

---

## 要素 5：资源分配

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

时间分配（参考值，按项目调整）：
- 需求分析：10%
- 用例设计：20%
- 测试执行：50%
- 回归测试：15%
- 报告总结：5%
```

---

## 要素 6：准入准出标准

```text
准入标准（可开始测试的前提）：
├─ 需求评审通过
├─ 开发自测通过
├─ 冒烟测试通过
├─ 测试环境就绪
└─ 测试数据准备

准出标准（可发布的门槛）：
├─ 用例执行率 ≥ 95%
├─ 用例通过率 ≥ 90%
├─ 高严重度 Bug 修复率 = 100%
├─ 中严重度 Bug 修复率 ≥ 90%
└─ 无阻塞性 Bug
```

> 上述百分比是**默认模板值**，不是行业标准。项目应根据历史数据校准：
> 一个长期执行率 100% 的团队，把准出定在 95% 等于形同虚设。
> 定得太松会让准出失去拦截作用，定得太严会逼着团队刷执行率。
> **每个项目应显式写出自己采用的值与依据。**

assets/strategy-doc.md

# 测试策略文档模板

> 复制下面整块板填写。六要素的评估方法见 [`six-elements.md`](six-elements.md)。

## 测试策略

**策略 ID**：STRAT-{模块缩写}-{三位序号}
**关联需求**：REQ-{模块缩写}-{序号}
**版本 / 日期**：v1.0 / YYYY-MM-DD

### 1. 项目背景

| 项 | 内容 |
|----|------|
| 项目阶段 | [新项目/迭代/维护] |
| 团队 | [X 人，经验水平] |
| 技术栈 | [复杂度 + 团队熟悉度] |
| 工期 | [开发 X 周 / 测试 Y 周] |
| 历史质量 | [Bug 密度、漏测率] |

### 2. 风险分析

> 风险等级直接引用 `qa-risk-intuition` 的结论（≥45 高→深测 / 15-44 中→常规 / ≤14 低→冒烟），
> 本策略不重新定义阈值。

| 风险等级 | 区域 | 测试深度 | 依据 |
|---------|------|---------|------|
| 高 | [如 支付/并发回调] | 深测 | RISK-PAY-CONC-002（125 分） |
| 中 | [如 订单/导出] | 常规 | RISK-ORDER-EXPORT-005（27 分） |
| 低 | [如 通知/推送] | 冒烟 | RISK-NOTIFY-PUSH-004（3 分） |

**本项目不测什么**（写明比不写更有价值）：
- [如：后台运营管理页面 —— 内部使用、无资金风险、不在本次迭代范围]

### 3. 测试范围

| 范围类型 | 内容 |
|---------|------|
| **测什么** | [功能模块清单 + 对应需求 ID] |
| **不测什么** | [明确排除项 + 原因] |
| **测到什么程度** | [深度定义：冒烟/常规/深测] |

### 4. 分层策略

| 层级 | 占比 | 覆盖内容 | 执行时机 |
|------|------|---------|---------|
| 单元测试 | 60% | 核心逻辑 | 开发者自测，提交时 |
| 接口测试 | 30% | 业务流程、服务间契约 | 提交后 / 每日 |
| E2E 测试 | 10% | 核心路径 | 发版前 |
| 探索测试 | 补充 | 自动化难覆盖部分 | 迭代中穿插 |

### 5. 手段选择

| 手段 | 范围 | 理由 |
|------|------|------|
| 自动化 | [回归/冒烟/数据驱动] | 重复执行，结果确定 |
| 手动 | [探索/体验/兼容性] | 需人工判断 |
| 工具辅助 | [性能/安全/接口] | [选择与理由] |

### 6. 资源分配

| 维度 | 方案 |
|------|------|
| 人力 | [角色与任务分配] |
| 时间 | 需求分析 10% / 用例设计 20% / 执行 50% / 回归 15% / 报告 5%（按项目调整） |
| 环境 | [环境数量与准备时间] |
| 工具 | [工具清单与选型理由] |

### 7. 准入准出标准

**准入**（可开始测试）
- [ ] 需求评审通过
- [ ] 开发自测通过
- [ ] 冒烟测试通过
- [ ] 测试环境就绪
- [ ] 测试数据准备

**准出**（可发布）

| 指标 | 本项目采用值 | 默认模板 | 依据 |
|------|------------|---------|------|
| 用例执行率 | [ ] | ≥95% | [历史数据/项目约定] |
| 用例通过率 | [ ] | ≥90% | [ ] |
| 高严重度 Bug 修复率 | [ ] | 100% | [ ] |
| 中严重度 Bug 修复率 | [ ] | ≥90% | [ ] |
| 阻塞性 Bug | [ ] | 0 | [ ] |

> **必须写明本项目采用值与依据**。直接抄默认模板而不校准，准出会形同虚设
> （长期执行率 100% 的团队把准出定在 95% 没有任何拦截作用）。

### 8. 风险与应对

| 风险 | 影响 | 应对 |
|------|------|------|
| [如 第三方支付联调环境未就绪] | [阻塞接口层测试] | [提前 Mock / 申请沙箱] |

## 填写要求

| 项 | 要求 | 常见错误 |
|----|------|---------|
| 策略 ID | `STRAT-{模块缩写}-{三位序号}` | 用 `TC_` 或 `REQ-` 前缀 |
| 风险等级 | 引用 `qa-risk-intuition` 结论，不自己重算 | 本技能另定一套阈值 |
| **不测什么** | **必填**，写明排除项与原因 | 留空（等于没做取舍决策） |
| 分层占比 | 合计 100%；按业务风险可调但要说明 | 各层都是"重要"导致全是 100% |
| 准出标准 | 写本项目采用值 + 依据 | 照抄模板不校准 |
| 覆盖率 | 标注口径（如"基于现有需求文档"） | "全覆盖""100%" |

## 交付前自检

- [ ] 六要素全部有内容；简单项目可只覆盖 4 个但需说明省略原因
- [ ] 风险等级引用上游 `qa-risk-intuition`，未另立阈值
- [ ] **"不测什么"已明确写出**（策略的价值一半在这里）
- [ ] 分层占比合计 100%，且说明了偏离默认配比的理由
- [ ] 准出标准写明了本项目采用值与依据
- [ ] 关联需求 ID 格式为 `REQ-`
- [ ] 策略 ID 格式为 `STRAT-`
- [ ] 无"全覆盖/100%"绝对化表述

skill-card.md

## Description:

Designs risk-based test strategies for new projects and iterations, defining test scope, layered coverage, resources, and project-specific entry and exit criteria.

This skill is ready for commercial/non-commercial use.

## Publisher:

[kokxi](https://clawhub.ai/user/kokxi)

### License/Terms of Use:

MIT-0

## Use Case:

QA teams and developers use this skill to plan testing for a new project or iteration, prioritizing assessed risks, defining what will and will not be tested, and setting justified release criteria.

### Deployment Geography for Use:

Global

## Known Risks and Mitigations:

Risk: Installing the broader workflow may bring in additional, unreviewed skills.

Mitigation: Review its source and use a pinned, trusted package version before installing.

Risk: Strategy examples could be mistaken for approval to change release or CI/CD settings.

Mitigation: Treat the document as planning guidance and require authorized review before applying operational changes.

## Reference(s):

- [ClawHub skill release](https://clawhub.ai/kokxi/skills/qa-test-strategy-design)
- [Six Elements of Test Strategy](references/six-elements.md)
- [Test Strategy Document Template](assets/strategy-doc.md)

## Skill Output:

**Output Type(s):** [Markdown, Guidance]

**Output Format:** [Markdown test strategy document]

**Output Parameters:** [1D]

**Other Properties Related to Output:** [Includes risk and requirement IDs, explicit exclusions, layered testing, resource allocation, and justified entry and exit criteria; does not produce test case tables.]

## Skill Version(s):

1.8.0 (source: skill frontmatter and ClawHub release)

## Ethical Considerations:

Users should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.

Github ReposUpdated 1d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.