{"id":"f0dea4a5-a878-4884-af86-93de58a88d9a","entityType":"agent","slug":"clawhub-kokxi-qa-test-strategy-design","name":"qa-test-strategy-design","canonicalUrl":"https://www.xpersona.co/agent/clawhub-kokxi-qa-test-strategy-design","canonicalPath":"/agent/clawhub-kokxi-qa-test-strategy-design","generatedAt":"2026-10-11T04:34:54.710Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T02:12:21.460Z","emptyReason":null},"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. 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","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.2K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s170jw3s1atcj5jwhqb4r7v7eh8912kp:qa-test-strategy-design","sourceUrl":"https://clawhub.ai/kokxi/qa-test-strategy-design","homepage":"https://clawhub.ai/kokxi/skills/qa-test-strategy-design","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/kokxi/qa-test-strategy-design","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/kokxi/skills/qa-test-strategy-design","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":62,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"当新项目启动需要制定测试方案、或者迭代开始前需要确定\"这期怎么测\"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道\"测什么、不测什么、为什么\"——其中\"不测什么\"往往比\"测什么\"更能体现决策质量。输"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T02:12:21.460Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T02:12:21.460Z","emptyReason":null},"stars":null,"forks":null,"downloads":1193,"packageName":null,"latestVersion":"1.8.0","tractionLabel":"1.2K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T02:12:21.323Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T02:12:21.460Z","lastCrawledAt":"2026-10-11T02:12:21.323Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T02:12:21.323Z","lastVerifiedAt":null,"highlights":[{"version":"1.8.0","createdAt":"2026-09-29T04:29:49.195Z","changelog":"# Test Strategy Design v1.8.0 - Major revision: split and modularized documentation, clarified requirements, and improved output structure. - Added two referenced documents: `assets/strategy-doc.md` (strategy doc template) and `references/six-elements.md` (evaluation method). - Removed embedded use case table/9-column test case structure—now only strategy doc output (test case design handled separately). - Output format and references now explicitly require stating \"what will NOT be tested\" and justifying exit criteria with project-specific rationale. - Streamlined SKILL.md: merged English/Chinese context, added error recovery, clarified traceability and element coverage requirements. - Dropped the old `skill-card.md` file.","fileCount":5,"zipByteSize":9843},{"version":"1.7.7","createdAt":"2026-09-27T14:44:04.819Z","changelog":"1.7.7","fileCount":3,"zipByteSize":4764},{"version":"1.7.6","createdAt":"2026-09-01T12:49:58.490Z","changelog":"显示名改中文","fileCount":3,"zipByteSize":5068},{"version":"1.7.5","createdAt":"2026-08-30T15:22:25.075Z","changelog":"1.7.5: 版本号升级","fileCount":3,"zipByteSize":5076},{"version":"1.7.0","createdAt":"2026-08-16T14:33:51.313Z","changelog":"- Removed the skill-card.md file to clean up redundant or outdated documentation. - Updated SKILL.md version to 1.7.0; no content or logic changes detected—structure, features, and guidance remain the same. - No impact on skill usage or external interfaces.","fileCount":3,"zipByteSize":4737},{"version":"1.6.3","createdAt":"2026-08-12T15:31:17.350Z","changelog":"- Added slug and displayName fields for improved metadata and skill identification. - Version bump to 1.6.3. - Removed legacy \"skill-card.md\" file. - No functional or logic changes to the strategy content or workflows.","fileCount":3,"zipByteSize":4750},{"version":"1.6.0","createdAt":"2026-07-06T17:34:05.829Z","changelog":"- 增加下游关联技能支持（如 CI/CD 测试、自动化架构、测试环境与数据等）。 - 输出结构新增“traceability”，支持策略唯一ID与需求ID关联。 - 新增 categories 字段，分类为 Development、Testing、DevOps。 - 明确深度量化要求与最低输出维度。 - 加入错误恢复与重试策略说明。 - 安全提示和输出范围说明（不执行实际操作，仅本地输出）。 - 移除 skill-card.md 文件，优化文档结构。","fileCount":3,"zipByteSize":4683},{"version":"1.5.0","createdAt":"2026-06-29T12:37:25.436Z","changelog":"Version 1.5.0 – Major structure and documentation update - Added explicit version field and expanded structured metadata in SKILL.md. - Refined and expanded the description to clarify use cases and expected outputs. - Enhanced input/output format specifications, detailing required/optional inputs and structured outputs. - Introduced depth requirements and output length guidance for projects of varying complexity. - Updated examples and checklists for better practical application. - Removed skill-card.md for simplification and to avoid redundancy.","fileCount":3,"zipByteSize":4255}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s170jw3s1atcj5jwhqb4r7v7eh8912kp:qa-test-strategy-design","setupComplexity":"low","setupSteps":["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":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-strategy-design/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-strategy-design/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-strategy-design/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-strategy-design/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-strategy-design/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-strategy-design/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T04:34:54.709Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-strategy-design/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-strategy-design/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-strategy-design/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-strategy-design/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T02:12:21.460Z","emptyReason":null},"readme":"Skill: qa-test-strategy-design\n\nOwner: kokxi\n\nSummary: 当新项目启动需要制定测试方案、或者迭代开始前需要确定\"这期怎么测\"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道\"测什么、不测什么、为什么\"——其中\"不测什么\"往往比\"测什么\"更能体现决策质量。输出风险矩阵、分级测试方案与准入准出标准的测试策略文档。 触发场景：测试策略、怎么测、测试计划、方案设计、测试范围、质量策略、新项目启动确定测试方案时。 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.\n\nTags: latest:1.8.0\n\nVersion history:\n\nv1.8.0 | 2026-09-29T04:29:49.195Z | auto\n\n# Test Strategy Design v1.8.0\n\n- Major revision: split and modularized documentation, clarified requirements, and improved output structure.\n- Added two referenced documents: `assets/strategy-doc.md` (strategy doc template) and `references/six-elements.md` (evaluation method).\n- Removed embedded use case table/9-column test case structure—now only strategy doc output (test case design handled separately).\n- Output format and references now explicitly require stating \"what will NOT be tested\" and justifying exit criteria with project-specific rationale.\n- Streamlined SKILL.md: merged English/Chinese context, added error recovery, clarified traceability and element coverage requirements.\n- Dropped the old `skill-card.md` file.\n\nv1.7.7 | 2026-09-27T14:44:04.819Z | user\n\n1.7.7\n\nv1.7.6 | 2026-09-01T12:49:58.490Z | user\n\n显示名改中文\n\nv1.7.5 | 2026-08-30T15:22:25.075Z | user\n\n1.7.5: 版本号升级\n\nv1.7.0 | 2026-08-16T14:33:51.313Z | auto\n\n- Removed the skill-card.md file to clean up redundant or outdated documentation.\n- Updated SKILL.md version to 1.7.0; no content or logic changes detected—structure, features, and guidance remain the same.\n- No impact on skill usage or external interfaces.\n\nv1.6.3 | 2026-08-12T15:31:17.350Z | auto\n\n- Added slug and displayName fields for improved metadata and skill identification.\n- Version bump to 1.6.3.\n- Removed legacy \"skill-card.md\" file.\n- No functional or logic changes to the strategy content or workflows.\n\nv1.6.0 | 2026-07-06T17:34:05.829Z | auto\n\n- 增加下游关联技能支持（如 CI/CD 测试、自动化架构、测试环境与数据等）。\n- 输出结构新增“traceability”，支持策略唯一ID与需求ID关联。\n- 新增 categories 字段，分类为 Development、Testing、DevOps。\n- 明确深度量化要求与最低输出维度。\n- 加入错误恢复与重试策略说明。\n- 安全提示和输出范围说明（不执行实际操作，仅本地输出）。\n- 移除 skill-card.md 文件，优化文档结构。\n\nv1.5.0 | 2026-06-29T12:37:25.436Z | auto\n\nVersion 1.5.0 – Major structure and documentation update\n\n- Added explicit version field and expanded structured metadata in SKILL.md.\n- Refined and expanded the description to clarify use cases and expected outputs.\n- Enhanced input/output format specifications, detailing required/optional inputs and structured outputs.\n- Introduced depth requirements and output length guidance for projects of varying complexity.\n- Updated examples and checklists for better practical application.\n- Removed skill-card.md for simplification and to avoid redundancy.\n\nv1.4.1 | 2026-06-25T16:58:00.958Z | auto\n\n- 优化描述，更加简洁明确分层策略、手段和准入准出要求\n- 删除 skill-card.md 文件，简化技能结构\n- 精简激活场景说明，突出测试计划与方案场景\n- 保留测试策略六要素和输出模板，未调整主要结构\n- 去除冗余关键词与重复说明，提高易读性\n\nv1.4.0 | 2026-06-24T05:16:13.688Z | auto\n\n- Removed the file skill-card.md.\n- No changes to the core logic or description of the skill.\n- No new features or user-facing modifications in this version.\n\nv1.3.0 | 2026-06-23T19:44:27.740Z | auto\n\n- 优化了测试策略制定的流程，详细拆解为六大核心要素，覆盖背景、风险、分层、手段、资源和准入准出。\n- 增加了分层测试比例建议和可视化金字塔模型，便于制定分层测试方案。\n- 明确自动化与手动测试的适用场景和选择依据，强化测试手段决策。\n- 丰富了策略输出模板、资源分配细则，以及准入准出标准，提升落地指导性。\n- 提供实际案例与自查指引，帮助用户快速制定和检查测试策略。\n\nArchive index:\n\nArchive v1.8.0: 5 files, 9843 bytes\n\nFiles: assets/strategy-doc.md (4428b), references/six-elements.md (4127b), skill-card.md (1926b), SKILL.md (7817b), _meta.json (142b)\n\nFile v1.8.0:SKILL.md\n\n---\nname: qa-test-strategy-design\ndescription: >-\n  当新项目启动需要制定测试方案、或者迭代开始前需要确定\"这期怎么测\"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道\"测什么、不测什么、为什么\"——其中\"不测什么\"往往比\"测什么\"更能体现决策质量。输出风险矩阵、分级测试方案与准入准出标准的测试策略文档。\n  触发场景：测试策略、怎么测、测试计划、方案设计、测试范围、质量策略、新项目启动确定测试方案时。 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.\nlicense: MIT\nallowed-tools: Read Grep Glob\nmetadata:\n  display-name: \"Test Strategy Design\"\n  version: \"1.8.0\"\n  when-to-use: \"用户说\\\"测试策略\\\"、\\\"怎么测\\\"、\\\"测试计划\\\"、\\\"方案设计\\\"、\\\"测试范围\\\"、\\\"质量策略\\\"、需要制定测试策略、新项目启动确定测试方案时\"\n  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\\\"]}\"\n  references: \"[\\\"references/six-elements.md\\\",\\\"assets/strategy-doc.md\\\"]\"\n  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\\\":\\\"测试资源限制\\\"}]}\"\n  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%\\\\\\\"绝对化表述\\\"]}\"\n  error-recovery-guidance: \"{\\\"on_failure\\\":\\\"策略遗漏高风险区域时回退到风险评估补充\\\",\\\"retry_behavior\\\":\\\"补充评估后重新制定策略\\\"}\"\n  categories: \"[\\\"Development\\\",\\\"Testing\\\",\\\"DevOps\\\"]\"\n  depth-requirement: \"{\\\"reference_value\\\":\\\"见正文「策略深度要求」表：简单/中等/复杂项目对应不同要素覆盖数与文档篇幅\\\",\\\"minimum\\\":\\\"至少覆盖 项目背景/测试范围/风险分析/资源分配 4 个核心维度；未覆盖要素须说明原因\\\"}\"\n---\n\n> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills\n\n> **⚠️ 安全警告**：本技能的示例可能涉及发布评估和 CI/CD 流水线的策略引用。\n> 这些是策略参考不是直接操作；请勿未经授权即执行发布或变更流水线配置。\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\n\n# 测试策略制定\n\n## 核心原则\n\n一个好的测试策略让团队知道 **\"测什么、不测什么、为什么\"**。\n\n其中 **\"不测什么\"往往比\"测什么\"更能体现决策质量**——写不出排除项的策略，本质上是测试清单不是测试策略。\n\n## 1. 六要素速查\n\n| # | 要素 | 回答什么 | 最容易漏 |\n|---|------|---------|---------|\n| 1 | 项目背景 | 什么阶段、什么团队、多长工期 | **团队对技术栈的熟悉度** |\n| 2 | 风险分析 | 哪些地方危险 | 进度风险（往往被当成\"非技术问题\"忽略） |\n| 3 | 测试范围 | **测什么 / 不测什么** | **不测什么** |\n| 4 | 分层策略 | 单元/接口/E2E 各占多少 | E2E 占比（容易堆太多） |\n| 5 | 手段选择 | 哪些自动化、哪些手动 | 判断标准（应看重复次数与结果确定度） |\n| 6 | 准入准出 | 什么时候能开始测、什么时候能发 | **本项目采用值与依据** |\n\n> 逐要素的评估方法见 `references/six-elements.md`。\n\n## 2. 风险等级口径\n\n**不在本技能重新定义阈值**——直接引用 `qa-risk-intuition` 的结论：\n\n| 风险分数 | 等级 | 测试深度 |\n|---------|------|---------|\n| ≥ 45 | 高 | 深测 |\n| 15 – 44 | 中 | 常规 |\n| ≤ 14 | 低 | 冒烟 |\n\n> 同一项目里出现两套风险口径是最容易引发扯皮的事。本技能引用上游 `RISK-` ID 即可。\n\n## 3. 策略深度要求\n\n| 复杂度 | 要素覆盖 | 文档篇幅 | 典型场景 |\n|--------|---------|---------|---------|\n| 简单项目 | 至少 4 个要素 | 1-2 页摘要 | 内部工具 / 低风险 |\n| 中等项目 | 全部 6 个要素 | 3-5 页 | 业务系统 / 中等风险 |\n| 复杂项目 | 全部 6 要素 + 风险评估 | 5-10 页 | 核心系统 / 高风险 |\n\n## 4. 加载时机\n\n| 什么时候读 | 读哪个 |\n|-----------|--------|\n| 逐要素展开评估方法，或要填具体数值 | [`references/six-elements.md`](references/six-elements.md) |\n| 写测试策略文档 | [`assets/strategy-doc.md`](assets/strategy-doc.md)（八段式模板 + 填写要求 + 自检） |\n\n## 5. 产出：测试策略文档骨架\n\n```markdown\n**策略 ID**：STRAT-PAY-001   **关联需求**：REQ-PAY-001\n\n### 1. 项目背景      → 阶段/团队/技术栈熟悉度/工期/历史质量\n### 2. 风险分析      → 引用 RISK- ID 与等级，本技能不重算阈值\n### 3. 测试范围      → 测什么 / **不测什么** / 测到什么程度\n### 4. 分层策略      → 单元 60% / 接口 30% / E2E 10% / 探索补充\n### 5. 手段选择      → 自动化/手动/工具辅助 + 理由\n### 6. 资源分配      → 人力/时间/环境/工具\n### 7. 准入准出      → 本项目采用值 + 依据（非照抄模板）\n### 8. 风险与应对    → 环境未就绪等外部依赖的预案\n```\n\n> 完整模板与填写要求见 `assets/strategy-doc.md`。\n\n**本技能不产出 9 列用例表**——策略落地为用例由 `qa-test-case-design` 完成。\n\n## 6. 两个容易做错的地方\n\n1. **\"不测什么\"留空** → 策略变成测试清单。必须写出排除项与原因\n2. **准出标准照抄模板** → 长期执行率 100% 的团队把准出定在 95%，\n   等于没有拦截作用，反而让准出形同虚设。**必须显式校准并写出依据。**\n\n## 7. 交付前自检\n\n- [ ] 六要素有内容；简单项目只覆盖 4 个时已说明省略原因\n- [ ] 风险等级引用上游 `qa-risk-intuition`，**未另立阈值**\n- [ ] **\"不测什么\"已明确写出**（策略价值一半在这里）\n- [ ] 分层占比合计 100%，偏离默认配比已说明理由\n- [ ] E2E 占比未超过核心路径所需\n- [ ] 准出标准写明了**本项目采用值与依据**\n- [ ] 外部依赖风险（环境/第三方联调）有应对预案\n- [ ] 策略 ID `STRAT-` / 需求 ID `REQ-` / 风险 ID `RISK-` 前缀正确\n- [ ] 无\"全覆盖/100%\"绝对化表述\n\nFile v1.8.0:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-test-strategy-design\",\n  \"version\": \"1.8.0\",\n  \"publishedAt\": 1790656189195\n}\n\nFile v1.8.0:references/six-elements.md\n\n# 测试策略六要素详解\n\n> 本文是 `qa-test-strategy-design` 的**方法详图**。需要逐要素展开、或要填具体数值时读本文；\n> 只想知道策略该覆盖哪几块时读 `SKILL.md` 的六要素速查即可。\n\n---\n\n## 要素 1：项目背景评估\n\n```text\n评估维度：\n├─ 项目阶段：新项目 / 迭代优化 / 维护阶段\n├─ 团队规模：人员数量和经验水平\n├─ 技术栈：技术复杂度和团队熟悉度\n├─ 工期：开发周期和测试周期\n└─ 历史质量：历史 Bug 密度和漏测率\n\n评估结果：\n- 项目阶段：[新项目/迭代/维护]\n- 团队：[X 人，经验水平]\n- 技术栈：[复杂度 + 团队熟悉度]\n- 工期：[开发 X 周 / 测试 Y 周]\n- 历史质量：[Bug 密度、漏测率]\n```\n\n> **\"团队熟悉度\"比\"技术复杂度\"更重要**。团队不熟的新技术栈，风险主要来自\n> 理解偏差而非实现难度——这两类风险要用不同手段应对。\n\n---\n\n## 要素 2：风险分析\n\n```text\n风险识别：\n├─ 业务风险：核心功能 / 资金 / 安全\n├─ 技术风险：新架构 / 复杂逻辑 / 第三方\n├─ 进度风险：工期紧 / 人员不足\n└─ 质量风险：历史问题多 / 复杂度高\n```\n\n> **风险等级与测试深度的映射统一由 `qa-risk-intuition` 定义**（≥45 高→深测 /\n> 15-44 中→常规 / ≤14 低→冒烟）。本技能**不重新定义阈值**，\n> 直接引用上游评估结论——避免同一项目里出现两套风险口径。\n\n---\n\n## 要素 3：分层策略\n\n```text\n测试金字塔：\n                ┌─────────┐\n                │  E2E测试 │  10%\n                ├─────────┤\n                │ 接口测试 │  30%\n                ├─────────┤\n                │ 单元测试 │  60%\n                └─────────┘\n\n分层比例（按业务风险调整）：\n├─ 单元测试：60-70%（核心逻辑，开发者自测）\n├─ 接口测试：20-30%（业务流程，服务间契约）\n├─ E2E 测试：10%（核心路径，成本最高）\n└─ 探索测试：补充（复杂场景、自动化难覆盖的部分）\n```\n\n> **不要在 CI 里堆满慢的 E2E**。E2E 只跑核心路径，其余靠接口层拦截。\n> 分层配比的具体落地（流水线卡点）交 `qa-ci-cd-testing`。\n\n---\n\n## 要素 4：手段选择\n\n```text\n自动化 vs 手动：\n├─ 自动化：回归测试 / 冒烟测试 / 数据驱动\n├─ 手动：探索测试 / 用户体验 / 兼容性\n└─ 工具辅助：性能测试 / 安全测试 / 接口测试\n\n选择依据：\n- 重复执行 → 自动化\n- 复杂判断 → 手动\n- 数据驱动 → 自动化\n- 探索性 → 手动\n```\n\n> 判断标准是**重复次数**与**结果确定度**，不是\"这个功能重不重要\"。\n> 一次性的核心功能手工测完全合理；天天跑的边缘功能反而必须自动化。\n\n---\n\n## 要素 5：资源分配\n\n```text\n资源分配：\n├─ 人力分配：测试人员角色和任务\n├─ 时间分配：各阶段测试时间\n├─ 环境分配：测试环境准备\n└─ 工具分配：测试工具准备\n\n时间分配（参考值，按项目调整）：\n- 需求分析：10%\n- 用例设计：20%\n- 测试执行：50%\n- 回归测试：15%\n- 报告总结：5%\n```\n\n---\n\n## 要素 6：准入准出标准\n\n```text\n准入标准（可开始测试的前提）：\n├─ 需求评审通过\n├─ 开发自测通过\n├─ 冒烟测试通过\n├─ 测试环境就绪\n└─ 测试数据准备\n\n准出标准（可发布的门槛）：\n├─ 用例执行率 ≥ 95%\n├─ 用例通过率 ≥ 90%\n├─ 高严重度 Bug 修复率 = 100%\n├─ 中严重度 Bug 修复率 ≥ 90%\n└─ 无阻塞性 Bug\n```\n\n> 上述百分比是**默认模板值**，不是行业标准。项目应根据历史数据校准：\n> 一个长期执行率 100% 的团队，把准出定在 95% 等于形同虚设。\n> 定得太松会让准出失去拦截作用，定得太严会逼着团队刷执行率。\n> **每个项目应显式写出自己采用的值与依据。**\n\nFile v1.8.0:assets/strategy-doc.md\n\n# 测试策略文档模板\n\n> 复制下面整块板填写。六要素的评估方法见 [`six-elements.md`](six-elements.md)。\n\n## 测试策略\n\n**策略 ID**：STRAT-{模块缩写}-{三位序号}\n**关联需求**：REQ-{模块缩写}-{序号}\n**版本 / 日期**：v1.0 / YYYY-MM-DD\n\n### 1. 项目背景\n\n| 项 | 内容 |\n|----|------|\n| 项目阶段 | [新项目/迭代/维护] |\n| 团队 | [X 人，经验水平] |\n| 技术栈 | [复杂度 + 团队熟悉度] |\n| 工期 | [开发 X 周 / 测试 Y 周] |\n| 历史质量 | [Bug 密度、漏测率] |\n\n### 2. 风险分析\n\n> 风险等级直接引用 `qa-risk-intuition` 的结论（≥45 高→深测 / 15-44 中→常规 / ≤14 低→冒烟），\n> 本策略不重新定义阈值。\n\n| 风险等级 | 区域 | 测试深度 | 依据 |\n|---------|------|---------|------|\n| 高 | [如 支付/并发回调] | 深测 | RISK-PAY-CONC-002（125 分） |\n| 中 | [如 订单/导出] | 常规 | RISK-ORDER-EXPORT-005（27 分） |\n| 低 | [如 通知/推送] | 冒烟 | RISK-NOTIFY-PUSH-004（3 分） |\n\n**本项目不测什么**（写明比不写更有价值）：\n- [如：后台运营管理页面 —— 内部使用、无资金风险、不在本次迭代范围]\n\n### 3. 测试范围\n\n| 范围类型 | 内容 |\n|---------|------|\n| **测什么** | [功能模块清单 + 对应需求 ID] |\n| **不测什么** | [明确排除项 + 原因] |\n| **测到什么程度** | [深度定义：冒烟/常规/深测] |\n\n### 4. 分层策略\n\n| 层级 | 占比 | 覆盖内容 | 执行时机 |\n|------|------|---------|---------|\n| 单元测试 | 60% | 核心逻辑 | 开发者自测，提交时 |\n| 接口测试 | 30% | 业务流程、服务间契约 | 提交后 / 每日 |\n| E2E 测试 | 10% | 核心路径 | 发版前 |\n| 探索测试 | 补充 | 自动化难覆盖部分 | 迭代中穿插 |\n\n### 5. 手段选择\n\n| 手段 | 范围 | 理由 |\n|------|------|------|\n| 自动化 | [回归/冒烟/数据驱动] | 重复执行，结果确定 |\n| 手动 | [探索/体验/兼容性] | 需人工判断 |\n| 工具辅助 | [性能/安全/接口] | [选择与理由] |\n\n### 6. 资源分配\n\n| 维度 | 方案 |\n|------|------|\n| 人力 | [角色与任务分配] |\n| 时间 | 需求分析 10% / 用例设计 20% / 执行 50% / 回归 15% / 报告 5%（按项目调整） |\n| 环境 | [环境数量与准备时间] |\n| 工具 | [工具清单与选型理由] |\n\n### 7. 准入准出标准\n\n**准入**（可开始测试）\n- [ ] 需求评审通过\n- [ ] 开发自测通过\n- [ ] 冒烟测试通过\n- [ ] 测试环境就绪\n- [ ] 测试数据准备\n\n**准出**（可发布）\n\n| 指标 | 本项目采用值 | 默认模板 | 依据 |\n|------|------------|---------|------|\n| 用例执行率 | [ ] | ≥95% | [历史数据/项目约定] |\n| 用例通过率 | [ ] | ≥90% | [ ] |\n| 高严重度 Bug 修复率 | [ ] | 100% | [ ] |\n| 中严重度 Bug 修复率 | [ ] | ≥90% | [ ] |\n| 阻塞性 Bug | [ ] | 0 | [ ] |\n\n> **必须写明本项目采用值与依据**。直接抄默认模板而不校准，准出会形同虚设\n> （长期执行率 100% 的团队把准出定在 95% 没有任何拦截作用）。\n\n### 8. 风险与应对\n\n| 风险 | 影响 | 应对 |\n|------|------|------|\n| [如 第三方支付联调环境未就绪] | [阻塞接口层测试] | [提前 Mock / 申请沙箱] |\n\n## 填写要求\n\n| 项 | 要求 | 常见错误 |\n|----|------|---------|\n| 策略 ID | `STRAT-{模块缩写}-{三位序号}` | 用 `TC_` 或 `REQ-` 前缀 |\n| 风险等级 | 引用 `qa-risk-intuition` 结论，不自己重算 | 本技能另定一套阈值 |\n| **不测什么** | **必填**，写明排除项与原因 | 留空（等于没做取舍决策） |\n| 分层占比 | 合计 100%；按业务风险可调但要说明 | 各层都是\"重要\"导致全是 100% |\n| 准出标准 | 写本项目采用值 + 依据 | 照抄模板不校准 |\n| 覆盖率 | 标注口径（如\"基于现有需求文档\"） | \"全覆盖\"\"100%\" |\n\n## 交付前自检\n\n- [ ] 六要素全部有内容；简单项目可只覆盖 4 个但需说明省略原因\n- [ ] 风险等级引用上游 `qa-risk-intuition`，未另立阈值\n- [ ] **\"不测什么\"已明确写出**（策略的价值一半在这里）\n- [ ] 分层占比合计 100%，且说明了偏离默认配比的理由\n- [ ] 准出标准写明了本项目采用值与依据\n- [ ] 关联需求 ID 格式为 `REQ-`\n- [ ] 策略 ID 格式为 `STRAT-`\n- [ ] 无\"全覆盖/100%\"绝对化表述\n\nFile v1.8.0:skill-card.md\n\n## Description:\n\nDesigns risk-based test strategies for new projects and iterations, defining test scope, layered coverage, resources, and project-specific entry and exit criteria.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA 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.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Installing the broader workflow may bring in additional, unreviewed skills.\n\nMitigation: Review its source and use a pinned, trusted package version before installing.\n\nRisk: Strategy examples could be mistaken for approval to change release or CI/CD settings.\n\nMitigation: Treat the document as planning guidance and require authorized review before applying operational changes.\n\n## Reference(s):\n\n- [ClawHub skill release](https://clawhub.ai/kokxi/skills/qa-test-strategy-design)\n- [Six Elements of Test Strategy](references/six-elements.md)\n- [Test Strategy Document Template](assets/strategy-doc.md)\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Guidance]\n\n**Output Format:** [Markdown test strategy document]\n\n**Output Parameters:** [1D]\n\n**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.]\n\n## Skill Version(s):\n\n1.8.0 (source: skill frontmatter and ClawHub release)\n\n## Ethical Considerations:\n\nUsers 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.\n\nArchive v1.7.7: 3 files, 4764 bytes\n\nFiles: skill-card.md (1530b), SKILL.md (7910b), _meta.json (142b)\n\nFile v1.7.7:SKILL.md\n\n---\nname: qa-test-strategy-design\nslug: qa-test-strategy-design\ndisplayName: Test Strategy Design\nversion: 1.7.7\ndescription: >-\n  当新项目启动需要制定测试方案、或者迭代开始前需要确定\"这期怎么测\"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道\"测什么、不测什么、为什么\"。输出包含风险矩阵、分级测试方案的测试策略文档。\n\nwhen_to_use: 用户说\"测试策略\"、\"怎么测\"、\"测试计划\"、\"方案设计\"、\"测试范围\"、\"质量策略\"、需要制定测试策略、新项目启动确定测试方案时\nallowed-tools: Read Grep Glob\nrelated_skills:\n  upstream:\n    - qa-risk-intuition          # 输入：风险评估结果\n    - qa-req-deconstruction      # 输入：需求分析结果\n  downstream:\n    - qa-release-risk-governance # 输出：测试策略用于发布评估\n    - qa-ci-cd-testing\n    - qa-specialized-testing\n    - qa-tech-selection\n    - qa-test-automation-arch\n    - qa-test-env-data\ninput_format:\n  required:\n    - name: 风险评估\n      type: object\n      description: 来自qa-risk-intuition的风险评估结果\n    - name: 需求分析\n      type: object\n      description: 来自qa-req-deconstruction的需求分析结果\n  optional:\n    - name: 项目计划\n      type: string\n      description: 项目时间线和里程碑\n    - name: 资源约束\n      type: string\n      description: 测试资源限制\noutput_format:\n  traceability:\n    - 每份策略带唯一ID（STRAT-XXXX）\n    - 关联需求ID（TC_{需求模块缩写}_{功能缩写}_{序号}）\n  structure:\n    - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）\n    - 用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）\n    - 覆盖率：标注口径（基于现有需求/输入文档），禁止\"全覆盖/100%\"绝对化表述；缺失模块标注\"未覆盖+原因\"\n    - test_strategy: 分层测试策略\n    - scope_definition: 测试范围定义\n    - means_selection: 测试手段选择\n    - resource_allocation: 资源分配方案\n    - entry_exit_criteria: 准入准出标准\ncategories: ['Development','Testing','DevOps']\ndepth_requirement_quantification:\n  reference_value: \"根据项目复杂度调整策略深度：简单×1/中等×2/复杂×3\"\n  minimum: \"至少覆盖范围、层级、风险、资源4个核心维度\"\nerror_recovery_guidance:\n  on_failure: \"策略遗漏高风险区域时回退到风险评估补充\"\n  retry_behavior: \"补充评估后重新制定策略\"\n---\n> **⚠️ 安全警告**：本技能的示例可能涉及发布评估和 CI/CD 流水线的策略引用。\n> 这些是策略参考不是直接操作；请勿未经授权即执行发布或变更流水线配置。\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\n\n# 测试策略制定\n\n## 核心原则\n\n根据项目特征（工期/复杂度/团队/风险）制定分层测试策略。\n\n## 深度要求（参考值）\n\n**关键指标**：根据项目复杂度调整策略深度\n\n| 复杂度 | 策略要素要求 | 输出要求 | 说明 |\n|--------|------------|---------|------|\n| 简单项目 | 至少覆盖4个要素 | 1-2页策略摘要 | 内部工具/低风险 |\n| 中等项目 | 全部6个要素 | 3-5页策略文档 | 业务系统/中等风险 |\n| 复杂项目 | 全部6个要素+风险评估 | 5-10页完整策略 | 核心系统/高风险 |\n\n## 测试策略六要素\n\n### 要素1：项目背景评估\n\n```text\n评估维度：\n├─ 项目阶段：新项目/迭代优化/维护阶段\n├─ 团队规模：人员数量和经验水平\n├─ 技术栈：技术复杂度和团队熟悉度\n├─ 工期：开发周期和测试周期\n└─ 历史质量：历史Bug密度和漏测率\n\n评估结果：\n- 项目阶段：[新项目/迭代/维护]\n- 团队：[X人，经验水平]\n- 技术栈：[复杂度]\n- 工期：[X周]\n- 历史质量：[Bug密度/漏测率]\n```\n\n### 要素2：风险分析\n\n```text\n风险识别：\n├─ 业务风险：核心功能/资金/安全\n├─ 技术风险：新架构/复杂逻辑/第三方\n├─ 进度风险：工期紧/人员不足\n└─ 质量风险：历史问题多/复杂度高\n\n风险等级：\n- 高风险：必须深测\n- 中风险：常规测试\n- 低风险：冒烟测试\n```\n\n### 要素3：分层策略\n\n```text\n测试金字塔：\n                    ┌─────────┐\n                    │  E2E测试  │  10%\n                    ├─────────┤\n                    │  接口测试  │  30%\n                    ├─────────┤\n                    │  单元测试  │  60%\n                    └─────────┘\n\n分层比例：\n├─ 单元测试：60-70%（核心逻辑）\n├─ 接口测试：20-30%（业务流程）\n├─ E2E测试：10%（核心路径）\n└─ 探索测试：补充（复杂场景）\n```\n\n### 要素4：手段选择\n\n```text\n自动化 vs 手动：\n├─ 自动化：回归测试/冒烟测试/数据驱动\n├─ 手动：探索测试/用户体验/兼容性\n└─ 工具辅助：性能测试/安全测试/接口测试\n\n选择依据：\n- 重复执行：自动化\n- 复杂判断：手动\n- 数据驱动：自动化\n- 探索性：手动\n```\n\n### 要素5：资源分配\n\n```text\n资源分配：\n├─ 人力分配：测试人员角色和任务\n├─ 时间分配：各阶段测试时间\n├─ 环境分配：测试环境准备\n└─ 工具分配：测试工具准备\n\n时间分配：\n- 需求分析：10%\n- 用例设计：20%\n- 测试执行：50%\n- 回归测试：15%\n- 报告总结：5%\n```\n\n### 要素6：准入准出标准\n\n```text\n准入标准：\n├─ 需求评审通过\n├─ 开发自测通过\n├─ 冒烟测试通过\n├─ 测试环境就绪\n└─ 测试数据准备\n\n准出标准：\n├─ 用例执行率 ≥ 95%\n├─ 用例通过率 ≥ 90%\n├─ 高严重度Bug修复率 = 100%\n├─ 中严重度Bug修复率 ≥ 90%\n└─ 无阻塞性Bug\n```\n\n## 策略输出模板\n\n```markdown\n# 测试策略\n\n## 1. 项目背景\n- 项目阶段：[阶段]\n- 团队：[规模和经验]\n- 技术栈：[复杂度]\n- 工期：[周期]\n\n## 2. 风险分析\n- 高风险区域：[列表]\n- 中风险区域：[列表]\n- 低风险区域：[列表]\n\n## 3. 测试策略\n- 单元测试：[比例和范围]\n- 接口测试：[比例和范围]\n- E2E测试：[比例和范围]\n- 探索测试：[比例和范围]\n\n## 4. 手段选择\n- 自动化范围：[哪些需要自动化]\n- 手动范围：[哪些需要手动]\n- 工具选择：[使用什么工具]\n\n## 5. 资源分配\n- 人力：[分配方案]\n- 时间：[时间节点]\n- 环境：[环境准备]\n- 工具：[工具准备]\n\n## 6. 准入准出\n- 准入标准：[标准列表]\n- 准出标准：[标准列表]\n```\n\n## 输出示例\n\n**电商下单功能测试策略（工期2周，团队4人）**\n→ 背景评估：核心功能+高并发+三方支付，中高风险\n→ 分层策略：单元（开发自测）→集成（支付接口深测）→E2E（全流程冒烟）\n→ 手段选择：接口自动化为主，UI自动化覆盖核心路径，探索式测试做补盲\n→ 资源分配：接口自动化3人×5天，UI自动化1人×3天，探索1人×2天\n\n**新项目启动，PM问\"怎么测\"**\n→ 启动测试策略六要素系统化评估，输出可执行的测试方案\n\n## 检查清单\n\n测试策略完成后检查：\n- [ ] 项目背景评估是否完整？\n- [ ] 风险分析是否准确？\n- [ ] 分层策略是否合理？\n- [ ] 手段选择是否恰当？\n- [ ] 资源分配是否可行？\n- [ ] 准入准出是否明确？\n\nFile v1.7.7:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-test-strategy-design\",\n  \"version\": \"1.7.7\",\n  \"publishedAt\": 1790520244819\n}\n\nFile v1.7.7:skill-card.md\n\n## Description:\n\nDesigns risk-based, layered test strategies for new projects and iterations, covering scope, testing methods, resources, and entry and exit criteria.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA leads, testers, developers, and project teams use this skill to plan testing around project risks and resource constraints, including coverage priorities, test levels, and release-readiness criteria.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: A generated test strategy could be mistaken for approval to change CI/CD pipelines or authorize a release.\n\nMitigation: Review the strategy with the responsible team and obtain authorization before changing pipelines or making release decisions.\n\n## Reference(s):\n\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Guidance]\n\n**Output Format:** [Chinese-language Markdown test strategy document]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Includes a risk matrix, layered test plan, resource allocation, entry and exit criteria, and traceability IDs.]\n\n## Skill Version(s):\n\n1.7.7 (source: frontmatter and ClawHub release)\n\n## Ethical Considerations:\n\nUsers 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.\n\nArchive v1.7.6: 3 files, 5068 bytes\n\nFiles: skill-card.md (1806b), SKILL.md (8442b), _meta.json (142b)\n\nFile v1.7.6:SKILL.md\n\n---\r\nname: qa-test-strategy-design\r\nslug: qa-test-strategy-design\r\ndisplayName: 测试策略设计\r\nversion: 1.7.5\r\ndescription: >-\r\n  当新项目启动需要制定测试方案、或者迭代开始前需要确定\"这期怎么测\"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道\"测什么、不测什么、为什么\"。输出包含风险矩阵、分级测试方案的测试策略文档。\r\n  本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills\r\n\r\nwhen_to_use: 用户说\"测试策略\"、\"怎么测\"、\"测试计划\"、\"方案设计\"、\"测试范围\"、\"质量策略\"、需要制定测试策略、新项目启动确定测试方案时\r\nallowed-tools: Read Grep Glob\r\nrelated_skills:\r\n  upstream:\r\n    - qa-risk-intuition          # 输入：风险评估结果\r\n    - qa-req-deconstruction      # 输入：需求分析结果\r\n  downstream:\r\n    - qa-release-risk-governance # 输出：测试策略用于发布评估\r\n    - qa-ci-cd-testing\r\n    - qa-specialized-testing\r\n    - qa-tech-selection\r\n    - qa-test-automation-arch\r\n    - qa-test-env-data\r\ninput_format:\r\n  required:\r\n    - name: 风险评估\r\n      type: object\r\n      description: 来自qa-risk-intuition的风险评估结果\r\n    - name: 需求分析\r\n      type: object\r\n      description: 来自qa-req-deconstruction的需求分析结果\r\n  optional:\r\n    - name: 项目计划\r\n      type: string\r\n      description: 项目时间线和里程碑\r\n    - name: 资源约束\r\n      type: string\r\n      description: 测试资源限制\r\noutput_format:\r\n  traceability:\r\n    - 每份策略带唯一ID（STRAT-XXXX）\r\n    - 关联需求ID（TC_{需求模块缩写}_{功能缩写}_{序号}）\r\n  structure:\r\n    - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）\r\n    - 用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）\r\n    - 覆盖率：标注口径（基于现有需求/输入文档），禁止\"全覆盖/100%\"绝对化表述；缺失模块标注\"未覆盖+原因\"\r\n    - test_strategy: 分层测试策略\r\n    - scope_definition: 测试范围定义\r\n    - means_selection: 测试手段选择\r\n    - resource_allocation: 资源分配方案\r\n    - entry_exit_criteria: 准入准出标准\r\ncategories: ['Development','Testing','DevOps']\r\ndepth_requirement_quantification:\r\n  reference_value: \"根据项目复杂度调整策略深度：简单×1/中等×2/复杂×3\"\r\n  minimum: \"至少覆盖范围、层级、风险、资源4个核心维度\"\r\nerror_recovery_guidance:\r\n  on_failure: \"策略遗漏高风险区域时回退到风险评估补充\"\r\n  retry_behavior: \"补充评估后重新制定策略\"\r\n---\r\n> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills\r\n\r\n> **⚠️ 安全警告**：本技能的示例可能涉及发布评估和 CI/CD 流水线的策略引用。\r\n> 这些是策略参考不是直接操作；请勿未经授权即执行发布或变更流水线配置。\r\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\r\n\r\n# 测试策略制定\r\n\r\n## 核心原则\r\n\r\n根据项目特征（工期/复杂度/团队/风险）制定分层测试策略。\r\n\r\n## 深度要求（参考值）\r\n\r\n**关键指标**：根据项目复杂度调整策略深度\r\n\r\n| 复杂度 | 策略要素要求 | 输出要求 | 说明 |\r\n|--------|------------|---------|------|\r\n| 简单项目 | 至少覆盖4个要素 | 1-2页策略摘要 | 内部工具/低风险 |\r\n| 中等项目 | 全部6个要素 | 3-5页策略文档 | 业务系统/中等风险 |\r\n| 复杂项目 | 全部6个要素+风险评估 | 5-10页完整策略 | 核心系统/高风险 |\r\n\r\n## 测试策略六要素\r\n\r\n### 要素1：项目背景评估\r\n\r\n```text\r\n评估维度：\r\n├─ 项目阶段：新项目/迭代优化/维护阶段\r\n├─ 团队规模：人员数量和经验水平\r\n├─ 技术栈：技术复杂度和团队熟悉度\r\n├─ 工期：开发周期和测试周期\r\n└─ 历史质量：历史Bug密度和漏测率\r\n\r\n评估结果：\r\n- 项目阶段：[新项目/迭代/维护]\r\n- 团队：[X人，经验水平]\r\n- 技术栈：[复杂度]\r\n- 工期：[X周]\r\n- 历史质量：[Bug密度/漏测率]\r\n```\r\n\r\n### 要素2：风险分析\r\n\r\n```text\r\n风险识别：\r\n├─ 业务风险：核心功能/资金/安全\r\n├─ 技术风险：新架构/复杂逻辑/第三方\r\n├─ 进度风险：工期紧/人员不足\r\n└─ 质量风险：历史问题多/复杂度高\r\n\r\n风险等级：\r\n- 高风险：必须深测\r\n- 中风险：常规测试\r\n- 低风险：冒烟测试\r\n```\r\n\r\n### 要素3：分层策略\r\n\r\n```text\r\n测试金字塔：\r\n                    ┌─────────┐\r\n                    │  E2E测试  │  10%\r\n                    ├─────────┤\r\n                    │  接口测试  │  30%\r\n                    ├─────────┤\r\n                    │  单元测试  │  60%\r\n                    └─────────┘\r\n\r\n分层比例：\r\n├─ 单元测试：60-70%（核心逻辑）\r\n├─ 接口测试：20-30%（业务流程）\r\n├─ E2E测试：10%（核心路径）\r\n└─ 探索测试：补充（复杂场景）\r\n```\r\n\r\n### 要素4：手段选择\r\n\r\n```text\r\n自动化 vs 手动：\r\n├─ 自动化：回归测试/冒烟测试/数据驱动\r\n├─ 手动：探索测试/用户体验/兼容性\r\n└─ 工具辅助：性能测试/安全测试/接口测试\r\n\r\n选择依据：\r\n- 重复执行：自动化\r\n- 复杂判断：手动\r\n- 数据驱动：自动化\r\n- 探索性：手动\r\n```\r\n\r\n### 要素5：资源分配\r\n\r\n```text\r\n资源分配：\r\n├─ 人力分配：测试人员角色和任务\r\n├─ 时间分配：各阶段测试时间\r\n├─ 环境分配：测试环境准备\r\n└─ 工具分配：测试工具准备\r\n\r\n时间分配：\r\n- 需求分析：10%\r\n- 用例设计：20%\r\n- 测试执行：50%\r\n- 回归测试：15%\r\n- 报告总结：5%\r\n```\r\n\r\n### 要素6：准入准出标准\r\n\r\n```text\r\n准入标准：\r\n├─ 需求评审通过\r\n├─ 开发自测通过\r\n├─ 冒烟测试通过\r\n├─ 测试环境就绪\r\n└─ 测试数据准备\r\n\r\n准出标准：\r\n├─ 用例执行率 ≥ 95%\r\n├─ 用例通过率 ≥ 90%\r\n├─ 高严重度Bug修复率 = 100%\r\n├─ 中严重度Bug修复率 ≥ 90%\r\n└─ 无阻塞性Bug\r\n```\r\n\r\n## 策略输出模板\r\n\r\n```markdown\r\n# 测试策略\r\n\r\n## 1. 项目背景\r\n- 项目阶段：[阶段]\r\n- 团队：[规模和经验]\r\n- 技术栈：[复杂度]\r\n- 工期：[周期]\r\n\r\n## 2. 风险分析\r\n- 高风险区域：[列表]\r\n- 中风险区域：[列表]\r\n- 低风险区域：[列表]\r\n\r\n## 3. 测试策略\r\n- 单元测试：[比例和范围]\r\n- 接口测试：[比例和范围]\r\n- E2E测试：[比例和范围]\r\n- 探索测试：[比例和范围]\r\n\r\n## 4. 手段选择\r\n- 自动化范围：[哪些需要自动化]\r\n- 手动范围：[哪些需要手动]\r\n- 工具选择：[使用什么工具]\r\n\r\n## 5. 资源分配\r\n- 人力：[分配方案]\r\n- 时间：[时间节点]\r\n- 环境：[环境准备]\r\n- 工具：[工具准备]\r\n\r\n## 6. 准入准出\r\n- 准入标准：[标准列表]\r\n- 准出标准：[标准列表]\r\n```\r\n\r\n## 输出示例\r\n\r\n**电商下单功能测试策略（工期2周，团队4人）**\r\n→ 背景评估：核心功能+高并发+三方支付，中高风险\r\n→ 分层策略：单元（开发自测）→集成（支付接口深测）→E2E（全流程冒烟）\r\n→ 手段选择：接口自动化为主，UI自动化覆盖核心路径，探索式测试做补盲\r\n→ 资源分配：接口自动化3人×5天，UI自动化1人×3天，探索1人×2天\r\n\r\n**新项目启动，PM问\"怎么测\"**\r\n→ 启动测试策略六要素系统化评估，输出可执行的测试方案\r\n\r\n## 检查清单\r\n\r\n测试策略完成后检查：\r\n- [ ] 项目背景评估是否完整？\r\n- [ ] 风险分析是否准确？\r\n- [ ] 分层策略是否合理？\r\n- [ ] 手段选择是否恰当？\r\n- [ ] 资源分配是否可行？\r\n- [ ] 准入准出是否明确？\n\nFile v1.7.6:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-test-strategy-design\",\n  \"version\": \"1.7.6\",\n  \"publishedAt\": 1788266998490\n}\n\nFile v1.7.6:skill-card.md\n\n## Description:\n\nThis skill helps QA practitioners design layered test strategies for new projects, iterations, refactors, or urgent fixes by defining test scope, methods, entry and exit criteria, tool choices, and a risk-based strategy document.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, developers, and release teams use this skill to turn risk assessment, requirements analysis, project plans, and resource constraints into a practical test strategy. The output clarifies what to test, what not to test, and why.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill recommends an unpinned full-suite install command that can install additional mutable third-party skills outside this reviewed artifact.\n\nMitigation: Install only the reviewed skill when possible, or review the referenced collection and use an immutable pinned version before running the full-suite command.\n\n## Reference(s):\n\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown test strategy document with structured tables and checklists]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May include risk matrices, layered test plans, scope definitions, resource allocation, entry and exit criteria, and traceability identifiers.]\n\n## Skill Version(s):\n\n1.7.6 (source: server release evidence; artifact frontmatter reports 1.7.5)\n\n## Ethical Considerations:\n\nUsers 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.\n\nArchive v1.7.5: 3 files, 5076 bytes\n\nFiles: skill-card.md (2352b), SKILL.md (7910b), _meta.json (142b)\n\nFile v1.7.5:SKILL.md\n\n---\nname: qa-test-strategy-design\nslug: qa-test-strategy-design\ndisplayName: Test Strategy Design\nversion: 1.7.5\ndescription: >-\n  当新项目启动需要制定测试方案、或者迭代开始前需要确定\"这期怎么测\"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道\"测什么、不测什么、为什么\"。输出包含风险矩阵、分级测试方案的测试策略文档。\n\nwhen_to_use: 用户说\"测试策略\"、\"怎么测\"、\"测试计划\"、\"方案设计\"、\"测试范围\"、\"质量策略\"、需要制定测试策略、新项目启动确定测试方案时\nallowed-tools: Read Grep Glob\nrelated_skills:\n  upstream:\n    - qa-risk-intuition          # 输入：风险评估结果\n    - qa-req-deconstruction      # 输入：需求分析结果\n  downstream:\n    - qa-release-risk-governance # 输出：测试策略用于发布评估\n    - qa-ci-cd-testing\n    - qa-specialized-testing\n    - qa-tech-selection\n    - qa-test-automation-arch\n    - qa-test-env-data\ninput_format:\n  required:\n    - name: 风险评估\n      type: object\n      description: 来自qa-risk-intuition的风险评估结果\n    - name: 需求分析\n      type: object\n      description: 来自qa-req-deconstruction的需求分析结果\n  optional:\n    - name: 项目计划\n      type: string\n      description: 项目时间线和里程碑\n    - name: 资源约束\n      type: string\n      description: 测试资源限制\noutput_format:\n  traceability:\n    - 每份策略带唯一ID（STRAT-XXXX）\n    - 关联需求ID（TC_{需求模块缩写}_{功能缩写}_{序号}）\n  structure:\n    - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）\n    - 用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）\n    - 覆盖率：标注口径（基于现有需求/输入文档），禁止\"全覆盖/100%\"绝对化表述；缺失模块标注\"未覆盖+原因\"\n    - test_strategy: 分层测试策略\n    - scope_definition: 测试范围定义\n    - means_selection: 测试手段选择\n    - resource_allocation: 资源分配方案\n    - entry_exit_criteria: 准入准出标准\ncategories: ['Development','Testing','DevOps']\ndepth_requirement_quantification:\n  reference_value: \"根据项目复杂度调整策略深度：简单×1/中等×2/复杂×3\"\n  minimum: \"至少覆盖范围、层级、风险、资源4个核心维度\"\nerror_recovery_guidance:\n  on_failure: \"策略遗漏高风险区域时回退到风险评估补充\"\n  retry_behavior: \"补充评估后重新制定策略\"\n---\n> **⚠️ 安全警告**：本技能的示例可能涉及发布评估和 CI/CD 流水线的策略引用。\n> 这些是策略参考不是直接操作；请勿未经授权即执行发布或变更流水线配置。\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\n\n# 测试策略制定\n\n## 核心原则\n\n根据项目特征（工期/复杂度/团队/风险）制定分层测试策略。\n\n## 深度要求（参考值）\n\n**关键指标**：根据项目复杂度调整策略深度\n\n| 复杂度 | 策略要素要求 | 输出要求 | 说明 |\n|--------|------------|---------|------|\n| 简单项目 | 至少覆盖4个要素 | 1-2页策略摘要 | 内部工具/低风险 |\n| 中等项目 | 全部6个要素 | 3-5页策略文档 | 业务系统/中等风险 |\n| 复杂项目 | 全部6个要素+风险评估 | 5-10页完整策略 | 核心系统/高风险 |\n\n## 测试策略六要素\n\n### 要素1：项目背景评估\n\n```text\n评估维度：\n├─ 项目阶段：新项目/迭代优化/维护阶段\n├─ 团队规模：人员数量和经验水平\n├─ 技术栈：技术复杂度和团队熟悉度\n├─ 工期：开发周期和测试周期\n└─ 历史质量：历史Bug密度和漏测率\n\n评估结果：\n- 项目阶段：[新项目/迭代/维护]\n- 团队：[X人，经验水平]\n- 技术栈：[复杂度]\n- 工期：[X周]\n- 历史质量：[Bug密度/漏测率]\n```\n\n### 要素2：风险分析\n\n```text\n风险识别：\n├─ 业务风险：核心功能/资金/安全\n├─ 技术风险：新架构/复杂逻辑/第三方\n├─ 进度风险：工期紧/人员不足\n└─ 质量风险：历史问题多/复杂度高\n\n风险等级：\n- 高风险：必须深测\n- 中风险：常规测试\n- 低风险：冒烟测试\n```\n\n### 要素3：分层策略\n\n```text\n测试金字塔：\n                    ┌─────────┐\n                    │  E2E测试  │  10%\n                    ├─────────┤\n                    │  接口测试  │  30%\n                    ├─────────┤\n                    │  单元测试  │  60%\n                    └─────────┘\n\n分层比例：\n├─ 单元测试：60-70%（核心逻辑）\n├─ 接口测试：20-30%（业务流程）\n├─ E2E测试：10%（核心路径）\n└─ 探索测试：补充（复杂场景）\n```\n\n### 要素4：手段选择\n\n```text\n自动化 vs 手动：\n├─ 自动化：回归测试/冒烟测试/数据驱动\n├─ 手动：探索测试/用户体验/兼容性\n└─ 工具辅助：性能测试/安全测试/接口测试\n\n选择依据：\n- 重复执行：自动化\n- 复杂判断：手动\n- 数据驱动：自动化\n- 探索性：手动\n```\n\n### 要素5：资源分配\n\n```text\n资源分配：\n├─ 人力分配：测试人员角色和任务\n├─ 时间分配：各阶段测试时间\n├─ 环境分配：测试环境准备\n└─ 工具分配：测试工具准备\n\n时间分配：\n- 需求分析：10%\n- 用例设计：20%\n- 测试执行：50%\n- 回归测试：15%\n- 报告总结：5%\n```\n\n### 要素6：准入准出标准\n\n```text\n准入标准：\n├─ 需求评审通过\n├─ 开发自测通过\n├─ 冒烟测试通过\n├─ 测试环境就绪\n└─ 测试数据准备\n\n准出标准：\n├─ 用例执行率 ≥ 95%\n├─ 用例通过率 ≥ 90%\n├─ 高严重度Bug修复率 = 100%\n├─ 中严重度Bug修复率 ≥ 90%\n└─ 无阻塞性Bug\n```\n\n## 策略输出模板\n\n```markdown\n# 测试策略\n\n## 1. 项目背景\n- 项目阶段：[阶段]\n- 团队：[规模和经验]\n- 技术栈：[复杂度]\n- 工期：[周期]\n\n## 2. 风险分析\n- 高风险区域：[列表]\n- 中风险区域：[列表]\n- 低风险区域：[列表]\n\n## 3. 测试策略\n- 单元测试：[比例和范围]\n- 接口测试：[比例和范围]\n- E2E测试：[比例和范围]\n- 探索测试：[比例和范围]\n\n## 4. 手段选择\n- 自动化范围：[哪些需要自动化]\n- 手动范围：[哪些需要手动]\n- 工具选择：[使用什么工具]\n\n## 5. 资源分配\n- 人力：[分配方案]\n- 时间：[时间节点]\n- 环境：[环境准备]\n- 工具：[工具准备]\n\n## 6. 准入准出\n- 准入标准：[标准列表]\n- 准出标准：[标准列表]\n```\n\n## 输出示例\n\n**电商下单功能测试策略（工期2周，团队4人）**\n→ 背景评估：核心功能+高并发+三方支付，中高风险\n→ 分层策略：单元（开发自测）→集成（支付接口深测）→E2E（全流程冒烟）\n→ 手段选择：接口自动化为主，UI自动化覆盖核心路径，探索式测试做补盲\n→ 资源分配：接口自动化3人×5天，UI自动化1人×3天，探索1人×2天\n\n**新项目启动，PM问\"怎么测\"**\n→ 启动测试策略六要素系统化评估，输出可执行的测试方案\n\n## 检查清单\n\n测试策略完成后检查：\n- [ ] 项目背景评估是否完整？\n- [ ] 风险分析是否准确？\n- [ ] 分层策略是否合理？\n- [ ] 手段选择是否恰当？\n- [ ] 资源分配是否可行？\n- [ ] 准入准出是否明确？\n\nFile v1.7.5:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-test-strategy-design\",\n  \"version\": \"1.7.5\",\n  \"publishedAt\": 1788103345075\n}\n\nFile v1.7.5:skill-card.md\n\n## Description:\n\nHelps teams design layered QA test strategies for new projects, iterations, refactors, and urgent fixes based on project characteristics, risk distribution, and resource constraints.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, test leads, and delivery teams use this skill to turn requirements, risk assessments, project plans, and resource constraints into a practical test strategy. It produces scope definitions, layered testing approaches, entry and exit criteria, resource allocation guidance, and risk-aware test coverage decisions.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may read workspace files while preparing a test strategy.\n\nMitigation: Use it only in workspaces where project requirements, risk assessments, and planning documents are appropriate for the agent to inspect.\n\nRisk: The generated strategy may reference release evaluation or CI/CD pipeline practices.\n\nMitigation: Treat those references as planning guidance and require authorized review before executing release or pipeline changes.\n\nRisk: Ambiguous Chinese-language requests about test planning may activate the skill.\n\nMitigation: Confirm that the user is asking for QA strategy output before using workspace documents to prepare the plan.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-test-strategy-design)\n- [Publisher profile](https://clawhub.ai/user/kokxi)\n\n## Skill Output:\n\n**Output Type(s):** [Analysis, Markdown, Guidance]\n\n**Output Format:** [Markdown strategy document with tables, risk matrix, scope definition, layered test plan, and entry and exit criteria]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Outputs should include a unique strategy ID, requirement traceability, priority distribution guidance, and coverage caveats based on available inputs.]\n\n## Skill Version(s):\n\n1.7.5 (source: frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers 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.\n\nArchive v1.7.0: 3 files, 4737 bytes\n\nFiles: skill-card.md (2051b), SKILL.md (7430b), _meta.json (142b)\n\nFile v1.7.0:SKILL.md\n\n---\nname: qa-test-strategy-design\nslug: qa-test-strategy-design\ndisplayName: Test Strategy Design\nversion: 1.7.0\ndescription: >-\n  当新项目启动需要制定测试方案、或者迭代开始前需要确定\"这期怎么测\"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道\"测什么、不测什么、为什么\"。输出包含风险矩阵、分级测试方案的测试策略文档。\n\nwhen_to_use: 用户说\"测试策略\"、\"怎么测\"、\"测试计划\"、\"方案设计\"、\"测试范围\"、\"质量策略\"、需要制定测试策略、新项目启动确定测试方案时\nallowed-tools: Read Grep Glob\nrelated_skills:\n  upstream:\n    - qa-risk-intuition          # 输入：风险评估结果\n    - qa-req-deconstruction      # 输入：需求分析结果\n  downstream:\n    - qa-release-risk-governance # 输出：测试策略用于发布评估\n    - qa-ci-cd-testing\n    - qa-specialized-testing\n    - qa-tech-selection\n    - qa-test-automation-arch\n    - qa-test-env-data\ninput_format:\n  required:\n    - name: 风险评估\n      type: object\n      description: 来自qa-risk-intuition的风险评估结果\n    - name: 需求分析\n      type: object\n      description: 来自qa-req-deconstruction的需求分析结果\n  optional:\n    - name: 项目计划\n      type: string\n      description: 项目时间线和里程碑\n    - name: 资源约束\n      type: string\n      description: 测试资源限制\noutput_format:\n  traceability:\n    - 每份策略带唯一ID（STRAT-XXXX）\n    - 关联需求ID（REQ-XXXX）\n  structure:\n    - test_strategy: 分层测试策略\n    - scope_definition: 测试范围定义\n    - means_selection: 测试手段选择\n    - resource_allocation: 资源分配方案\n    - entry_exit_criteria: 准入准出标准\ncategories: ['Development','Testing','DevOps']\ndepth_requirement_quantification:\n  reference_value: \"根据项目复杂度调整策略深度：简单×1/中等×2/复杂×3\"\n  minimum: \"至少覆盖范围、层级、风险、资源4个核心维度\"\nerror_recovery_guidance:\n  on_failure: \"策略遗漏高风险区域时回退到风险评估补充\"\n  retry_behavior: \"补充评估后重新制定策略\"\n---\n> **⚠️ 安全警告**：本技能的示例可能涉及发布评估和 CI/CD 流水线的策略引用。\n> 这些是策略参考不是直接操作；请勿未经授权即执行发布或变更流水线配置。\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\n\n# 测试策略制定\n\n## 核心原则\n\n根据项目特征（工期/复杂度/团队/风险）制定分层测试策略。\n\n## 深度要求（参考值）\n\n**关键指标**：根据项目复杂度调整策略深度\n\n| 复杂度 | 策略要素要求 | 输出要求 | 说明 |\n|--------|------------|---------|------|\n| 简单项目 | 至少覆盖4个要素 | 1-2页策略摘要 | 内部工具/低风险 |\n| 中等项目 | 全部6个要素 | 3-5页策略文档 | 业务系统/中等风险 |\n| 复杂项目 | 全部6个要素+风险评估 | 5-10页完整策略 | 核心系统/高风险 |\n\n## 测试策略六要素\n\n### 要素1：项目背景评估\n\n```text\n评估维度：\n├─ 项目阶段：新项目/迭代优化/维护阶段\n├─ 团队规模：人员数量和经验水平\n├─ 技术栈：技术复杂度和团队熟悉度\n├─ 工期：开发周期和测试周期\n└─ 历史质量：历史Bug密度和漏测率\n\n评估结果：\n- 项目阶段：[新项目/迭代/维护]\n- 团队：[X人，经验水平]\n- 技术栈：[复杂度]\n- 工期：[X周]\n- 历史质量：[Bug密度/漏测率]\n```\n\n### 要素2：风险分析\n\n```text\n风险识别：\n├─ 业务风险：核心功能/资金/安全\n├─ 技术风险：新架构/复杂逻辑/第三方\n├─ 进度风险：工期紧/人员不足\n└─ 质量风险：历史问题多/复杂度高\n\n风险等级：\n- 高风险：必须深测\n- 中风险：常规测试\n- 低风险：冒烟测试\n```\n\n### 要素3：分层策略\n\n```text\n测试金字塔：\n                    ┌─────────┐\n                    │  E2E测试  │  10%\n                    ├─────────┤\n                    │  接口测试  │  30%\n                    ├─────────┤\n                    │  单元测试  │  60%\n                    └─────────┘\n\n分层比例：\n├─ 单元测试：60-70%（核心逻辑）\n├─ 接口测试：20-30%（业务流程）\n├─ E2E测试：10%（核心路径）\n└─ 探索测试：补充（复杂场景）\n```\n\n### 要素4：手段选择\n\n```text\n自动化 vs 手动：\n├─ 自动化：回归测试/冒烟测试/数据驱动\n├─ 手动：探索测试/用户体验/兼容性\n└─ 工具辅助：性能测试/安全测试/接口测试\n\n选择依据：\n- 重复执行：自动化\n- 复杂判断：手动\n- 数据驱动：自动化\n- 探索性：手动\n```\n\n### 要素5：资源分配\n\n```text\n资源分配：\n├─ 人力分配：测试人员角色和任务\n├─ 时间分配：各阶段测试时间\n├─ 环境分配：测试环境准备\n└─ 工具分配：测试工具准备\n\n时间分配：\n- 需求分析：10%\n- 用例设计：20%\n- 测试执行：50%\n- 回归测试：15%\n- 报告总结：5%\n```\n\n### 要素6：准入准出标准\n\n```text\n准入标准：\n├─ 需求评审通过\n├─ 开发自测通过\n├─ 冒烟测试通过\n├─ 测试环境就绪\n└─ 测试数据准备\n\n准出标准：\n├─ 用例执行率 ≥ 95%\n├─ 用例通过率 ≥ 90%\n├─ 高严重度Bug修复率 = 100%\n├─ 中严重度Bug修复率 ≥ 90%\n└─ 无阻塞性Bug\n```\n\n## 策略输出模板\n\n```markdown\n# 测试策略\n\n## 1. 项目背景\n- 项目阶段：[阶段]\n- 团队：[规模和经验]\n- 技术栈：[复杂度]\n- 工期：[周期]\n\n## 2. 风险分析\n- 高风险区域：[列表]\n- 中风险区域：[列表]\n- 低风险区域：[列表]\n\n## 3. 测试策略\n- 单元测试：[比例和范围]\n- 接口测试：[比例和范围]\n- E2E测试：[比例和范围]\n- 探索测试：[比例和范围]\n\n## 4. 手段选择\n- 自动化范围：[哪些需要自动化]\n- 手动范围：[哪些需要手动]\n- 工具选择：[使用什么工具]\n\n## 5. 资源分配\n- 人力：[分配方案]\n- 时间：[时间节点]\n- 环境：[环境准备]\n- 工具：[工具准备]\n\n## 6. 准入准出\n- 准入标准：[标准列表]\n- 准出标准：[标准列表]\n```\n\n## 输出示例\n\n**电商下单功能测试策略（工期2周，团队4人）**\n→ 背景评估：核心功能+高并发+三方支付，中高风险\n→ 分层策略：单元（开发自测）→集成（支付接口深测）→E2E（全流程冒烟）\n→ 手段选择：接口自动化为主，UI自动化覆盖核心路径，探索式测试做补盲\n→ 资源分配：接口自动化3人×5天，UI自动化1人×3天，探索1人×2天\n\n**新项目启动，PM问\"怎么测\"**\n→ 启动测试策略六要素系统化评估，输出可执行的测试方案\n\n## 检查清单\n\n测试策略完成后检查：\n- [ ] 项目背景评估是否完整？\n- [ ] 风险分析是否准确？\n- [ ] 分层策略是否合理？\n- [ ] 手段选择是否恰当？\n- [ ] 资源分配是否可行？\n- [ ] 准入准出是否明确？\n\nFile v1.7.0:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-test-strategy-design\",\n  \"version\": \"1.7.0\",\n  \"publishedAt\": 1786890831313\n}\n\nFile v1.7.0:skill-card.md\n\n## Description:\n\nHelps teams design layered QA test strategies for new projects, iterations, refactors, or urgent fixes by defining risk-based scope, testing methods, entry and exit criteria, resource allocation, and tool choices.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, developers, and project teams use this skill to turn requirements, risk assessments, schedule constraints, and resource limits into a practical testing strategy. It produces guidance for what to test, what not to test, and why.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may read workspace project materials while helping plan QA strategy.\n\nMitigation: Installers should review activation scope and narrow trigger language if broad workspace analysis is not appropriate.\n\nRisk: The skill includes release assessment and CI/CD pipeline strategy references that could be mistaken for operational instructions.\n\nMitigation: Treat generated recommendations as planning guidance and require authorized review before making release or pipeline changes.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-test-strategy-design)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown testing strategy document with risk matrix, layered test plan, scope definition, method selection, resource allocation, and entry/exit criteria.]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Each strategy is expected to include traceability IDs for the strategy and related requirements.]\n\n## Skill Version(s):\n\n1.7.0 (source: frontmatter and release evidence)\n\n## Ethical Considerations:\n\nUsers 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.\n\nArchive v1.6.3: 3 files, 4750 bytes\n\nFiles: skill-card.md (2195b), SKILL.md (7430b), _meta.json (142b)\n\nFile v1.6.3:SKILL.md\n\n---\nname: qa-test-strategy-design\nslug: qa-test-strategy-design\ndisplayName: Test Strategy Design\nversion: 1.6.3\ndescription: >-\n  当新项目启动需要制定测试方案、或者迭代开始前需要确定\"这期怎么测\"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道\"测什么、不测什么、为什么\"。输出包含风险矩阵、分级测试方案的测试策略文档。\n\nwhen_to_use: 用户说\"测试策略\"、\"怎么测\"、\"测试计划\"、\"方案设计\"、\"测试范围\"、\"质量策略\"、需要制定测试策略、新项目启动确定测试方案时\nallowed-tools: Read Grep Glob\nrelated_skills:\n  upstream:\n    - qa-risk-intuition          # 输入：风险评估结果\n    - qa-req-deconstruction      # 输入：需求分析结果\n  downstream:\n    - qa-release-risk-governance # 输出：测试策略用于发布评估\n    - qa-ci-cd-testing\n    - qa-specialized-testing\n    - qa-tech-selection\n    - qa-test-automation-arch\n    - qa-test-env-data\ninput_format:\n  required:\n    - name: 风险评估\n      type: object\n      description: 来自qa-risk-intuition的风险评估结果\n    - name: 需求分析\n      type: object\n      description: 来自qa-req-deconstruction的需求分析结果\n  optional:\n    - name: 项目计划\n      type: string\n      description: 项目时间线和里程碑\n    - name: 资源约束\n      type: string\n      description: 测试资源限制\noutput_format:\n  traceability:\n    - 每份策略带唯一ID（STRAT-XXXX）\n    - 关联需求ID（REQ-XXXX）\n  structure:\n    - test_strategy: 分层测试策略\n    - scope_definition: 测试范围定义\n    - means_selection: 测试手段选择\n    - resource_allocation: 资源分配方案\n    - entry_exit_criteria: 准入准出标准\ncategories: ['Development','Testing','DevOps']\ndepth_requirement_quantification:\n  reference_value: \"根据项目复杂度调整策略深度：简单×1/中等×2/复杂×3\"\n  minimum: \"至少覆盖范围、层级、风险、资源4个核心维度\"\nerror_recovery_guidance:\n  on_failure: \"策略遗漏高风险区域时回退到风险评估补充\"\n  retry_behavior: \"补充评估后重新制定策略\"\n---\n> **⚠️ 安全警告**：本技能的示例可能涉及发布评估和 CI/CD 流水线的策略引用。\n> 这些是策略参考不是直接操作；请勿未经授权即执行发布或变更流水线配置。\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\n\n# 测试策略制定\n\n## 核心原则\n\n根据项目特征（工期/复杂度/团队/风险）制定分层测试策略。\n\n## 深度要求（参考值）\n\n**关键指标**：根据项目复杂度调整策略深度\n\n| 复杂度 | 策略要素要求 | 输出要求 | 说明 |\n|--------|------------|---------|------|\n| 简单项目 | 至少覆盖4个要素 | 1-2页策略摘要 | 内部工具/低风险 |\n| 中等项目 | 全部6个要素 | 3-5页策略文档 | 业务系统/中等风险 |\n| 复杂项目 | 全部6个要素+风险评估 | 5-10页完整策略 | 核心系统/高风险 |\n\n## 测试策略六要素\n\n### 要素1：项目背景评估\n\n```text\n评估维度：\n├─ 项目阶段：新项目/迭代优化/维护阶段\n├─ 团队规模：人员数量和经验水平\n├─ 技术栈：技术复杂度和团队熟悉度\n├─ 工期：开发周期和测试周期\n└─ 历史质量：历史Bug密度和漏测率\n\n评估结果：\n- 项目阶段：[新项目/迭代/维护]\n- 团队：[X人，经验水平]\n- 技术栈：[复杂度]\n- 工期：[X周]\n- 历史质量：[Bug密度/漏测率]\n```\n\n### 要素2：风险分析\n\n```text\n风险识别：\n├─ 业务风险：核心功能/资金/安全\n├─ 技术风险：新架构/复杂逻辑/第三方\n├─ 进度风险：工期紧/人员不足\n└─ 质量风险：历史问题多/复杂度高\n\n风险等级：\n- 高风险：必须深测\n- 中风险：常规测试\n- 低风险：冒烟测试\n```\n\n### 要素3：分层策略\n\n```text\n测试金字塔：\n                    ┌─────────┐\n                    │  E2E测试  │  10%\n                    ├─────────┤\n                    │  接口测试  │  30%\n                    ├─────────┤\n                    │  单元测试  │  60%\n                    └─────────┘\n\n分层比例：\n├─ 单元测试：60-70%（核心逻辑）\n├─ 接口测试：20-30%（业务流程）\n├─ E2E测试：10%（核心路径）\n└─ 探索测试：补充（复杂场景）\n```\n\n### 要素4：手段选择\n\n```text\n自动化 vs 手动：\n├─ 自动化：回归测试/冒烟测试/数据驱动\n├─ 手动：探索测试/用户体验/兼容性\n└─ 工具辅助：性能测试/安全测试/接口测试\n\n选择依据：\n- 重复执行：自动化\n- 复杂判断：手动\n- 数据驱动：自动化\n- 探索性：手动\n```\n\n### 要素5：资源分配\n\n```text\n资源分配：\n├─ 人力分配：测试人员角色和任务\n├─ 时间分配：各阶段测试时间\n├─ 环境分配：测试环境准备\n└─ 工具分配：测试工具准备\n\n时间分配：\n- 需求分析：10%\n- 用例设计：20%\n- 测试执行：50%\n- 回归测试：15%\n- 报告总结：5%\n```\n\n### 要素6：准入准出标准\n\n```text\n准入标准：\n├─ 需求评审通过\n├─ 开发自测通过\n├─ 冒烟测试通过\n├─ 测试环境就绪\n└─ 测试数据准备\n\n准出标准：\n├─ 用例执行率 ≥ 95%\n├─ 用例通过率 ≥ 90%\n├─ 高严重度Bug修复率 = 100%\n├─ 中严重度Bug修复率 ≥ 90%\n└─ 无阻塞性Bug\n```\n\n## 策略输出模板\n\n```markdown\n# 测试策略\n\n## 1. 项目背景\n- 项目阶段：[阶段]\n- 团队：[规模和经验]\n- 技术栈：[复杂度]\n- 工期：[周期]\n\n## 2. 风险分析\n- 高风险区域：[列表]\n- 中风险区域：[列表]\n- 低风险区域：[列表]\n\n## 3. 测试策略\n- 单元测试：[比例和范围]\n- 接口测试：[比例和范围]\n- E2E测试：[比例和范围]\n- 探索测试：[比例和范围]\n\n## 4. 手段选择\n- 自动化范围：[哪些需要自动化]\n- 手动范围：[哪些需要手动]\n- 工具选择：[使用什么工具]\n\n## 5. 资源分配\n- 人力：[分配方案]\n- 时间：[时间节点]\n- 环境：[环境准备]\n- 工具：[工具准备]\n\n## 6. 准入准出\n- 准入标准：[标准列表]\n- 准出标准：[标准列表]\n```\n\n## 输出示例\n\n**电商下单功能测试策略（工期2周，团队4人）**\n→ 背景评估：核心功能+高并发+三方支付，中高风险\n→ 分层策略：单元（开发自测）→集成（支付接口深测）→E2E（全流程冒烟）\n→ 手段选择：接口自动化为主，UI自动化覆盖核心路径，探索式测试做补盲\n→ 资源分配：接口自动化3人×5天，UI自动化1人×3天，探索1人×2天\n\n**新项目启动，PM问\"怎么测\"**\n→ 启动测试策略六要素系统化评估，输出可执行的测试方案\n\n## 检查清单\n\n测试策略完成后检查：\n- [ ] 项目背景评估是否完整？\n- [ ] 风险分析是否准确？\n- [ ] 分层策略是否合理？\n- [ ] 手段选择是否恰当？\n- [ ] 资源分配是否可行？\n- [ ] 准入准出是否明确？\n\nFile v1.6.3:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-test-strategy-design\",\n  \"version\": \"1.6.3\",\n  \"publishedAt\": 1786548677350\n}\n\nFile v1.6.3:skill-card.md\n\n## Description:\n\nHelps QA teams design layered test strategies for new projects, iterations, refactors, or urgent fixes using project risks and resource constraints.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, test leads, and delivery teams use this skill to turn requirement analysis, risk assessment, project timing, and resource constraints into a practical test strategy. It helps define scope, layered testing approach, test methods, resource allocation, and entry and exit criteria.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may activate on broad test-planning phrases and produce strategy guidance that influences release or CI/CD decisions.\n\nMitigation: Review generated strategies with the responsible QA, engineering, and release owners before applying them to release readiness or pipeline decisions.\n\nRisk: The skill is intended for Chinese-language QA and test-strategy workflows, which may reduce clarity for teams outside that operating context.\n\nMitigation: Use it in Chinese-language QA planning contexts or have a qualified reviewer confirm translated or adapted outputs before adoption.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-test-strategy-design)\n- [ClawHub publisher profile](https://clawhub.ai/user/kokxi)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown test strategy document with risk matrix, layered test plan, scope definition, resource allocation, and entry and exit criteria]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Outputs are advisory planning artifacts and should be reviewed before being used for release or CI/CD decisions.]\n\n## Skill Version(s):\n\n1.6.3 (source: frontmatter and release evidence)\n\n## Ethical Considerations:\n\nUsers 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.\n\nArchive v1.6.0: 3 files, 4683 bytes\n\nFiles: skill-card.md (1978b), SKILL.md (7600b), _meta.json (142b)\n\nFile v1.6.0:SKILL.md\n\n---\r\nname: qa-test-strategy-design\r\nversion: 1.6.0\r\ndescription: >-\r\n  当新项目启动需要制定测试方案、或者迭代开始前需要确定\"这期怎么测\"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道\"测什么、不测什么、为什么\"。输出包含风险矩阵、分级测试方案的测试策略文档。\r\n\r\nwhen_to_use: 用户说\"测试策略\"、\"怎么测\"、\"测试计划\"、\"方案设计\"、\"测试范围\"、\"质量策略\"、需要制定测试策略、新项目启动确定测试方案时\r\nallowed-tools: Read Grep Glob\r\nrelated_skills:\r\n  upstream:\r\n    - qa-risk-intuition          # 输入：风险评估结果\r\n    - qa-req-deconstruction      # 输入：需求分析结果\r\n  downstream:\r\n    - qa-release-risk-governance # 输出：测试策略用于发布评估\r\n    - qa-ci-cd-testing\r\n    - qa-specialized-testing\r\n    - qa-tech-selection\r\n    - qa-test-automation-arch\r\n    - qa-test-env-data\r\ninput_format:\r\n  required:\r\n    - name: 风险评估\r\n      type: object\r\n      description: 来自qa-risk-intuition的风险评估结果\r\n    - name: 需求分析\r\n      type: object\r\n      description: 来自qa-req-deconstruction的需求分析结果\r\n  optional:\r\n    - name: 项目计划\r\n      type: string\r\n      description: 项目时间线和里程碑\r\n    - name: 资源约束\r\n      type: string\r\n      description: 测试资源限制\r\noutput_format:\r\n  traceability:\r\n    - 每份策略带唯一ID（STRAT-XXXX）\r\n    - 关联需求ID（REQ-XXXX）\r\n  structure:\r\n    - test_strategy: 分层测试策略\r\n    - scope_definition: 测试范围定义\r\n    - means_selection: 测试手段选择\r\n    - resource_allocation: 资源分配方案\r\n    - entry_exit_criteria: 准入准出标准\r\ncategories: ['Development','Testing','DevOps']\r\ndepth_requirement_quantification:\r\n  reference_value: \"根据项目复杂度调整策略深度：简单×1/中等×2/复杂×3\"\r\n  minimum: \"至少覆盖范围、层级、风险、资源4个核心维度\"\r\nerror_recovery_guidance:\r\n  on_failure: \"策略遗漏高风险区域时回退到风险评估补充\"\r\n  retry_behavior: \"补充评估后重新制定策略\"\r\n---\r\n> **⚠️ 安全警告**：本技能的示例可能涉及发布评估和 CI/CD 流水线的策略引用。\r\n> 这些是策略参考不是直接操作；请勿未经授权即执行发布或变更流水线配置。\r\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\r\n\r\n# 测试策略制定\r\n\r\n## 核心原则\r\n\r\n根据项目特征（工期/复杂度/团队/风险）制定分层测试策略。\r\n\r\n## 深度要求（参考值）\r\n\r\n**关键指标**：根据项目复杂度调整策略深度\r\n\r\n| 复杂度 | 策略要素要求 | 输出要求 | 说明 |\r\n|--------|------------|---------|------|\r\n| 简单项目 | 至少覆盖4个要素 | 1-2页策略摘要 | 内部工具/低风险 |\r\n| 中等项目 | 全部6个要素 | 3-5页策略文档 | 业务系统/中等风险 |\r\n| 复杂项目 | 全部6个要素+风险评估 | 5-10页完整策略 | 核心系统/高风险 |\r\n\r\n## 测试策略六要素\r\n\r\n### 要素1：项目背景评估\r\n\r\n```text\r\n评估维度：\r\n├─ 项目阶段：新项目/迭代优化/维护阶段\r\n├─ 团队规模：人员数量和经验水平\r\n├─ 技术栈：技术复杂度和团队熟悉度\r\n├─ 工期：开发周期和测试周期\r\n└─ 历史质量：历史Bug密度和漏测率\r\n\r\n评估结果：\r\n- 项目阶段：[新项目/迭代/维护]\r\n- 团队：[X人，经验水平]\r\n- 技术栈：[复杂度]\r\n- 工期：[X周]\r\n- 历史质量：[Bug密度/漏测率]\r\n```\r\n\r\n### 要素2：风险分析\r\n\r\n```text\r\n风险识别：\r\n├─ 业务风险：核心功能/资金/安全\r\n├─ 技术风险：新架构/复杂逻辑/第三方\r\n├─ 进度风险：工期紧/人员不足\r\n└─ 质量风险：历史问题多/复杂度高\r\n\r\n风险等级：\r\n- 高风险：必须深测\r\n- 中风险：常规测试\r\n- 低风险：冒烟测试\r\n```\r\n\r\n### 要素3：分层策略\r\n\r\n```text\r\n测试金字塔：\r\n                    ┌─────────┐\r\n                    │  E2E测试  │  10%\r\n                    ├─────────┤\r\n                    │  接口测试  │  30%\r\n                    ├─────────┤\r\n                    │  单元测试  │  60%\r\n                    └─────────┘\r\n\r\n分层比例：\r\n├─ 单元测试：60-70%（核心逻辑）\r\n├─ 接口测试：20-30%（业务流程）\r\n├─ E2E测试：10%（核心路径）\r\n└─ 探索测试：补充（复杂场景）\r\n```\r\n\r\n### 要素4：手段选择\r\n\r\n```text\r\n自动化 vs 手动：\r\n├─ 自动化：回归测试/冒烟测试/数据驱动\r\n├─ 手动：探索测试/用户体验/兼容性\r\n└─ 工具辅助：性能测试/安全测试/接口测试\r\n\r\n选择依据：\r\n- 重复执行：自动化\r\n- 复杂判断：手动\r\n- 数据驱动：自动化\r\n- 探索性：手动\r\n```\r\n\r\n### 要素5：资源分配\r\n\r\n```text\r\n资源分配：\r\n├─ 人力分配：测试人员角色和任务\r\n├─ 时间分配：各阶段测试时间\r\n├─ 环境分配：测试环境准备\r\n└─ 工具分配：测试工具准备\r\n\r\n时间分配：\r\n- 需求分析：10%\r\n- 用例设计：20%\r\n- 测试执行：50%\r\n- 回归测试：15%\r\n- 报告总结：5%\r\n```\r\n\r\n### 要素6：准入准出标准\r\n\r\n```text\r\n准入标准：\r\n├─ 需求评审通过\r\n├─ 开发自测通过\r\n├─ 冒烟测试通过\r\n├─ 测试环境就绪\r\n└─ 测试数据准备\r\n\r\n准出标准：\r\n├─ 用例执行率 ≥ 95%\r\n├─ 用例通过率 ≥ 90%\r\n├─ 高严重度Bug修复率 = 100%\r\n├─ 中严重度Bug修复率 ≥ 90%\r\n└─ 无阻塞性Bug\r\n```\r\n\r\n## 策略输出模板\r\n\r\n```markdown\r\n# 测试策略\r\n\r\n## 1. 项目背景\r\n- 项目阶段：[阶段]\r\n- 团队：[规模和经验]\r\n- 技术栈：[复杂度]\r\n- 工期：[周期]\r\n\r\n## 2. 风险分析\r\n- 高风险区域：[列表]\r\n- 中风险区域：[列表]\r\n- 低风险区域：[列表]\r\n\r\n## 3. 测试策略\r\n- 单元测试：[比例和范围]\r\n- 接口测试：[比例和范围]\r\n- E2E测试：[比例和范围]\r\n- 探索测试：[比例和范围]\r\n\r\n## 4. 手段选择\r\n- 自动化范围：[哪些需要自动化]\r\n- 手动范围：[哪些需要手动]\r\n- 工具选择：[使用什么工具]\r\n\r\n## 5. 资源分配\r\n- 人力：[分配方案]\r\n- 时间：[时间节点]\r\n- 环境：[环境准备]\r\n- 工具：[工具准备]\r\n\r\n## 6. 准入准出\r\n- 准入标准：[标准列表]\r\n- 准出标准：[标准列表]\r\n```\r\n\r\n## 输出示例\r\n\r\n**电商下单功能测试策略（工期2周，团队4人）**\r\n→ 背景评估：核心功能+高并发+三方支付，中高风险\r\n→ 分层策略：单元（开发自测）→集成（支付接口深测）→E2E（全流程冒烟）\r\n→ 手段选择：接口自动化为主，UI自动化覆盖核心路径，探索式测试做补盲\r\n→ 资源分配：接口自动化3人×5天，UI自动化1人×3天，探索1人×2天\r\n\r\n**新项目启动，PM问\"怎么测\"**\r\n→ 启动测试策略六要素系统化评估，输出可执行的测试方案\r\n\r\n## 检查清单\r\n\r\n测试策略完成后检查：\r\n- [ ] 项目背景评估是否完整？\r\n- [ ] 风险分析是否准确？\r\n- [ ] 分层策略是否合理？\r\n- [ ] 手段选择是否恰当？\r\n- [ ] 资源分配是否可行？\r\n- [ ] 准入准出是否明确？\n\nFile v1.6.0:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-test-strategy-design\",\n  \"version\": \"1.6.0\",\n  \"publishedAt\": 1783359245829\n}\n\nFile v1.6.0:skill-card.md\n\n## Description: <br>\nHelps QA teams design layered, risk-based test strategies for new projects, iterations, refactors, and urgent fixes. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[kokxi](https://clawhub.ai/user/kokxi) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nQA engineers, test leads, and development teams use this skill to turn risk assessments and requirement analysis into an actionable test strategy covering scope, layered test approach, resource allocation, and entry and exit criteria. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill can be triggered by broad Chinese testing-planning phrases, which may produce a test strategy when the request is not actually about QA strategy. <br>\nMitigation: Confirm that the user is asking for test strategy design before relying on the generated plan. <br>\nRisk: Generated release, CI/CD, and testing recommendations could be mistaken for approved operational actions. <br>\nMitigation: Treat outputs as planning guidance only and review them before any release decision, pipeline change, or production action. <br>\n\n\n## Reference(s): <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance] <br>\n**Output Format:** [Markdown strategy document with structured sections and checklists] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Outputs risk matrices, strategy IDs, requirement traceability, scope definitions, test approach guidance, resource plans, and entry and exit criteria.] <br>\n\n## Skill Version(s): <br>\n1.6.0 (source: frontmatter and server evidence) <br>\n\n## Ethical Considerations: <br>\nUsers 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. <br>\n\nArchive v1.5.0: 3 files, 4255 bytes\n\nFiles: skill-card.md (2146b), SKILL.md (6845b), _meta.json (142b)\n\nFile v1.5.0:SKILL.md\n\n---\r\nname: qa-test-strategy-design\r\nversion: 1.5.0\r\ndescription: >-\r\n  当新项目启动需要制定测试方案、或者迭代开始前需要确定\"这期怎么测\"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道\"测什么、不测什么、为什么\"。输出包含风险矩阵、分级测试方案的测试策略文档。\r\n\r\nwhen_to_use: 用户说\"测试策略\"、\"怎么测\"、\"测试计划\"、\"方案设计\"、\"测试范围\"、\"质量策略\"、需要制定测试策略、新项目启动确定测试方案时\r\nallowed-tools: Read Grep Glob\r\nrelated_skills:\r\n  upstream:\r\n    - qa-risk-intuition          # 输入：风险评估结果\r\n    - qa-req-deconstruction      # 输入：需求分析结果\r\n  downstream:\r\n    - qa-release-risk-governance # 输出：测试策略用于发布评估\r\ninput_format:\r\n  required:\r\n    - name: 风险评估\r\n      type: object\r\n      description: 来自qa-risk-intuition的风险评估结果\r\n    - name: 需求分析\r\n      type: object\r\n      description: 来自qa-req-deconstruction的需求分析结果\r\n  optional:\r\n    - name: 项目计划\r\n      type: string\r\n      description: 项目时间线和里程碑\r\n    - name: 资源约束\r\n      type: string\r\n      description: 测试资源限制\r\noutput_format:\r\n  structure:\r\n    - test_strategy: 分层测试策略\r\n    - scope_definition: 测试范围定义\r\n    - means_selection: 测试手段选择\r\n    - resource_allocation: 资源分配方案\r\n    - entry_exit_criteria: 准入准出标准\r\n---\r\n\r\n# 测试策略制定\r\n\r\n## 核心原则\r\n\r\n你是一位测试策略专家，擅长根据项目特征制定分层测试策略。\r\n**核心原则**：根据项目特征（工期/复杂度/团队/风险）制定分层测试策略。\r\n本技能覆盖测试策略六要素（背景/风险/分层/手段/资源/准入准出）。\r\n\r\n## 深度要求（参考值）\r\n\r\n**关键指标**：根据项目复杂度调整策略深度\r\n\r\n| 复杂度 | 策略要素要求 | 输出要求 | 说明 |\r\n|--------|------------|---------|------|\r\n| 简单项目 | 至少覆盖4个要素 | 1-2页策略摘要 | 内部工具/低风险 |\r\n| 中等项目 | 全部6个要素 | 3-5页策略文档 | 业务系统/中等风险 |\r\n| 复杂项目 | 全部6个要素+风险评估 | 5-10页完整策略 | 核心系统/高风险 |\r\n\r\n## 测试策略六要素\r\n\r\n### 要素1：项目背景评估\r\n\r\n```text\r\n评估维度：\r\n├─ 项目阶段：新项目/迭代优化/维护阶段\r\n├─ 团队规模：人员数量和经验水平\r\n├─ 技术栈：技术复杂度和团队熟悉度\r\n├─ 工期：开发周期和测试周期\r\n└─ 历史质量：历史Bug密度和漏测率\r\n\r\n评估结果：\r\n- 项目阶段：[新项目/迭代/维护]\r\n- 团队：[X人，经验水平]\r\n- 技术栈：[复杂度]\r\n- 工期：[X周]\r\n- 历史质量：[Bug密度/漏测率]\r\n```\r\n\r\n### 要素2：风险分析\r\n\r\n```text\r\n风险识别：\r\n├─ 业务风险：核心功能/资金/安全\r\n├─ 技术风险：新架构/复杂逻辑/第三方\r\n├─ 进度风险：工期紧/人员不足\r\n└─ 质量风险：历史问题多/复杂度高\r\n\r\n风险等级：\r\n- 高风险：必须深测\r\n- 中风险：常规测试\r\n- 低风险：冒烟测试\r\n```\r\n\r\n### 要素3：分层策略\r\n\r\n```text\r\n测试金字塔：\r\n                    ┌─────────┐\r\n                    │  E2E测试  │  10%\r\n                    ├─────────┤\r\n                    │  接口测试  │  30%\r\n                    ├─────────┤\r\n                    │  单元测试  │  60%\r\n                    └─────────┘\r\n\r\n分层比例：\r\n├─ 单元测试：60-70%（核心逻辑）\r\n├─ 接口测试：20-30%（业务流程）\r\n├─ E2E测试：10%（核心路径）\r\n└─ 探索测试：补充（复杂场景）\r\n```\r\n\r\n### 要素4：手段选择\r\n\r\n```text\r\n自动化 vs 手动：\r\n├─ 自动化：回归测试/冒烟测试/数据驱动\r\n├─ 手动：探索测试/用户体验/兼容性\r\n└─ 工具辅助：性能测试/安全测试/接口测试\r\n\r\n选择依据：\r\n- 重复执行：自动化\r\n- 复杂判断：手动\r\n- 数据驱动：自动化\r\n- 探索性：手动\r\n```\r\n\r\n### 要素5：资源分配\r\n\r\n```text\r\n资源分配：\r\n├─ 人力分配：测试人员角色和任务\r\n├─ 时间分配：各阶段测试时间\r\n├─ 环境分配：测试环境准备\r\n└─ 工具分配：测试工具准备\r\n\r\n时间分配：\r\n- 需求分析：10%\r\n- 用例设计：20%\r\n- 测试执行：50%\r\n- 回归测试：15%\r\n- 报告总结：5%\r\n```\r\n\r\n### 要素6：准入准出标准\r\n\r\n```text\r\n准入标准：\r\n├─ 需求评审通过\r\n├─ 开发自测通过\r\n├─ 冒烟测试通过\r\n├─ 测试环境就绪\r\n└─ 测试数据准备\r\n\r\n准出标准：\r\n├─ 用例执行率 ≥ 95%\r\n├─ 用例通过率 ≥ 90%\r\n├─ 高严重度Bug修复率 = 100%\r\n├─ 中严重度Bug修复率 ≥ 90%\r\n└─ 无阻塞性Bug\r\n```\r\n\r\n## 策略输出模板\r\n\r\n```markdown\r\n# 测试策略\r\n\r\n## 1. 项目背景\r\n- 项目阶段：[阶段]\r\n- 团队：[规模和经验]\r\n- 技术栈：[复杂度]\r\n- 工期：[周期]\r\n\r\n## 2. 风险分析\r\n- 高风险区域：[列表]\r\n- 中风险区域：[列表]\r\n- 低风险区域：[列表]\r\n\r\n## 3. 测试策略\r\n- 单元测试：[比例和范围]\r\n- 接口测试：[比例和范围]\r\n- E2E测试：[比例和范围]\r\n- 探索测试：[比例和范围]\r\n\r\n## 4. 手段选择\r\n- 自动化范围：[哪些需要自动化]\r\n- 手动范围：[哪些需要手动]\r\n- 工具选择：[使用什么工具]\r\n\r\n## 5. 资源分配\r\n- 人力：[分配方案]\r\n- 时间：[时间节点]\r\n- 环境：[环境准备]\r\n- 工具：[工具准备]\r\n\r\n## 6. 准入准出\r\n- 准入标准：[标准列表]\r\n- 准出标准：[标准列表]\r\n```\r\n\r\n## 输出示例\r\n\r\n**电商下单功能测试策略（工期2周，团队4人）**\r\n→ 背景评估：核心功能+高并发+三方支付，中高风险\r\n→ 分层策略：单元（开发自测）→集成（支付接口深测）→E2E（全流程冒烟）\r\n→ 手段选择：接口自动化为主，UI自动化覆盖核心路径，探索式测试做补盲\r\n→ 资源分配：接口自动化3人×5天，UI自动化1人×3天，探索1人×2天\r\n\r\n**新项目启动，PM问\"怎么测\"**\r\n→ 启动测试策略六要素系统化评估，输出可执行的测试方案\r\n\r\n## 检查清单\r\n\r\n测试策略完成后检查：\r\n- [ ] 项目背景评估是否完整？\r\n- [ ] 风险分析是否准确？\r\n- [ ] 分层策略是否合理？\r\n- [ ] 手段选择是否恰当？\r\n- [ ] 资源分配是否可行？\r\n- [ ] 准入准出是否明确？\n\nFile v1.5.0:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-test-strategy-design\",\n  \"version\": \"1.5.0\",\n  \"publishedAt\": 1782736645436\n}\n\nFile v1.5.0:skill-card.md\n\n## Description: <br>\nHelps teams design layered QA test strategies for new projects, iterations, refactors, or urgent fixes by defining risk areas, test scope, methods, resource allocation, and entry and exit criteria. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[kokxi](https://clawhub.ai/user/kokxi) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nQA engineers, test leads, and delivery teams use this skill to turn project context, risk assessment, and requirement analysis into a practical test strategy. It produces guidance for what to test, what not to test, why those choices are appropriate, and how to allocate testing effort. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may activate on broad testing or planning requests and produce guidance when the user's intent is ambiguous. <br>\nMitigation: Confirm the request is for QA test strategy design before relying on the output. <br>\nRisk: The skill is written for Chinese-language QA workflows and may be less clear in a non-Chinese team. <br>\nMitigation: Review or translate the generated strategy with the target team before using it for delivery planning. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-test-strategy-design) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Analysis, Markdown, Guidance] <br>\n**Output Format:** [Markdown test strategy document with risk matrix, scoped test layers, resource plan, and entry and exit criteria] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Chinese-language QA strategy guidance; review output when activation is ambiguous or when working in a non-Chinese team.] <br>\n\n## Skill Version(s): <br>\n1.5.0 (source: frontmatter and server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers 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. <br>\n\nArchive v1.4.1: 3 files, 3719 bytes\n\nFiles: skill-card.md (2133b), SKILL.md (5478b), _meta.json (142b)\n\nFile v1.4.1:SKILL.md\n\n---\r\nname: qa-test-strategy-design\r\ndescription: >-\r\n  测试策略制定，根据项目特征/风险/资源设计分层测试策略，明确范围/手段/准入准出。当需要制定测试计划或测试方案时激活。\r\n\r\nwhen_to_use: 用户说\"测试策略\"、\"怎么测\"、\"测试计划\"、\"方案设计\"、\"测试范围\"、\"质量策略\"、需要制定测试策略、新项目启动确定测试方案时\r\nallowed-tools: Read Grep Glob\r\nrelated_skills:\r\n  upstream:\r\n    - qa-risk-intuition          # 输入：风险评估结果\r\n    - qa-req-deconstruction      # 输入：需求分析结果\r\n  downstream:\r\n    - qa-release-risk-governance # 输出：测试策略用于发布评估\r\ninput_format: 风险评估 + 需求分析\r\noutput_format: 测试策略（分层策略 + 手段选择 + 资源分配 + 准入准出）\r\n---\r\n\r\n# 测试策略制定\r\n\r\n## Overview\r\n\r\n你是一位测试策略专家，擅长根据项目特征制定分层测试策略。\r\n**核心原则**：根据项目特征（工期/复杂度/团队/风险）制定分层测试策略。\r\n本技能覆盖测试策略六要素（背景/风险/分层/手段/资源/准入准出）。\r\n\r\n## 测试策略六要素\r\n\r\n### 要素1：项目背景评估\r\n\r\n```\r\n评估维度：\r\n├─ 项目阶段：新项目/迭代优化/维护阶段\r\n├─ 团队规模：人员数量和经验水平\r\n├─ 技术栈：技术复杂度和团队熟悉度\r\n├─ 工期：开发周期和测试周期\r\n└─ 历史质量：历史Bug密度和漏测率\r\n\r\n评估结果：\r\n- 项目阶段：[新项目/迭代/维护]\r\n- 团队：[X人，经验水平]\r\n- 技术栈：[复杂度]\r\n- 工期：[X周]\r\n- 历史质量：[Bug密度/漏测率]\r\n```\r\n\r\n### 要素2：风险分析\r\n\r\n```\r\n风险识别：\r\n├─ 业务风险：核心功能/资金/安全\r\n├─ 技术风险：新架构/复杂逻辑/第三方\r\n├─ 进度风险：工期紧/人员不足\r\n└─ 质量风险：历史问题多/复杂度高\r\n\r\n风险等级：\r\n- 高风险：必须深测\r\n- 中风险：常规测试\r\n- 低风险：冒烟测试\r\n```\r\n\r\n### 要素3：分层策略\r\n\r\n```\r\n测试金字塔：\r\n                    ┌─────────┐\r\n                    │  E2E测试  │  10%\r\n                    ├─────────┤\r\n                    │  接口测试  │  30%\r\n                    ├─────────┤\r\n                    │  单元测试  │  60%\r\n                    └─────────┘\r\n\r\n分层比例：\r\n├─ 单元测试：60-70%（核心逻辑）\r\n├─ 接口测试：20-30%（业务流程）\r\n├─ E2E测试：10%（核心路径）\r\n└─ 探索测试：补充（复杂场景）\r\n```\r\n\r\n### 要素4：手段选择\r\n\r\n```\r\n自动化 vs 手动：\r\n├─ 自动化：回归测试/冒烟测试/数据驱动\r\n├─ 手动：探索测试/用户体验/兼容性\r\n└─ 工具辅助：性能测试/安全测试/接口测试\r\n\r\n选择依据：\r\n- 重复执行：自动化\r\n- 复杂判断：手动\r\n- 数据驱动：自动化\r\n- 探索性：手动\r\n```\r\n\r\n### 要素5：资源分配\r\n\r\n```\r\n资源分配：\r\n├─ 人力分配：测试人员角色和任务\r\n├─ 时间分配：各阶段测试时间\r\n├─ 环境分配：测试环境准备\r\n└─ 工具分配：测试工具准备\r\n\r\n时间分配：\r\n- 需求分析：10%\r\n- 用例设计：20%\r\n- 测试执行：50%\r\n- 回归测试：15%\r\n- 报告总结：5%\r\n```\r\n\r\n### 要素6：准入准出标准\r\n\r\n```\r\n准入标准：\r\n├─ 需求评审通过\r\n├─ 开发自测通过\r\n├─ 冒烟测试通过\r\n├─ 测试环境就绪\r\n└─ 测试数据准备\r\n\r\n准出标准：\r\n├─ 用例执行率 ≥ 95%\r\n├─ 用例通过率 ≥ 90%\r\n├─ 高严重度Bug修复率 = 100%\r\n├─ 中严重度Bug修复率 ≥ 90%\r\n└─ 无阻塞性Bug\r\n```\r\n\r\n## 策略输出模板\r\n\r\n```markdown\r\n# 测试策略\r\n\r\n## 1. 项目背景\r\n- 项目阶段：[阶段]\r\n- 团队：[规模和经验]\r\n- 技术栈：[复杂度]\r\n- 工期：[周期]\r\n\r\n## 2. 风险分析\r\n- 高风险区域：[列表]\r\n- 中风险区域：[列表]\r\n- 低风险区域：[列表]\r\n\r\n## 3. 测试策略\r\n- 单元测试：[比例和范围]\r\n- 接口测试：[比例和范围]\r\n- E2E测试：[比例和范围]\r\n- 探索测试：[比例和范围]\r\n\r\n## 4. 手段选择\r\n- 自动化范围：[哪些需要自动化]\r\n- 手动范围：[哪些需要手动]\r\n- 工具选择：[使用什么工具]\r\n\r\n## 5. 资源分配\r\n- 人力：[分配方案]\r\n- 时间：[时间节点]\r\n- 环境：[环境准备]\r\n- 工具：[工具准备]\r\n\r\n## 6. 准入准出\r\n- 准入标准：[标准列表]\r\n- 准出标准：[标准列表]\r\n```\r\n\r\n## Examples\r\n\r\n**电商下单功能测试策略（工期2周，团队4人）**\r\n→ 背景评估：核心功能+高并发+三方支付，中高风险\r\n→ 分层策略：单元（开发自测）→集成（支付接口深测）→E2E（全流程冒烟）\r\n→ 手段选择：接口自动化为主，UI自动化覆盖核心路径，探索式测试做补盲\r\n→ 资源分配：接口自动化3人×5天，UI自动化1人×3天，探索1人×2天\r\n\r\n**新项目启动，PM问\"怎么测\"**\r\n→ 启动测试策略六要素系统化评估，输出可执行的测试方案\r\n\r\n## Guidelines\r\n\r\n测试策略完成后检查：\r\n- [ ] 项目背景评估是否完整？\r\n- [ ] 风险分析是否准确？\r\n- [ ] 分层策略是否合理？\r\n- [ ] 手段选择是否恰当？\r\n- [ ] 资源分配是否可行？\r\n- [ ] 准入准出是否明确？\n\nFile v1.4.1:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-test-strategy-design\",\n  \"version\": \"1.4.1\",\n  \"publishedAt\": 1782406680958\n}\n\nFile v1.4.1:skill-card.md\n\n## Description: <br>\nHelps QA practitioners design layered test strategies from project characteristics, risks, resources, test scope, methods, and entry and exit criteria. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[kokxi](https://clawhub.ai/user/kokxi) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nQA engineers, test leads, and delivery teams use this skill to turn requirements, risk analysis, and project constraints into a practical test plan or strategy. It is most relevant when planning test scope, test levels, automation versus manual coverage, resource allocation, and entry or exit criteria. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad test-planning phrases may activate the skill when the conversation is not specifically about QA strategy. <br>\nMitigation: Manually choose a more specific skill or clarify the task when the user needs a narrower QA workflow. <br>\nRisk: Generated test strategies may omit project-specific constraints or overfit the built-in template. <br>\nMitigation: Review the output against current requirements, known risks, resources, environments, and release criteria before using it for project decisions. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-test-strategy-design) <br>\n- [ClawHub publisher profile](https://clawhub.ai/user/kokxi) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance] <br>\n**Output Format:** [Markdown test-strategy outline with concise planning guidance] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Chinese-language QA planning template; no code or shell execution output is expected.] <br>\n\n## Skill Version(s): <br>\n1.4.1 (source: ClawHub release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers 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. <br>\n\nArchive v1.4.0: 3 files, 3681 bytes\n\nFiles: skill-card.md (1962b), SKILL.md (5725b), _meta.json (142b)\n\nFile v1.4.0:SKILL.md\n\n---\r\nname: qa-test-strategy-design\r\ndescription: >-\r\n  测试策略制定，根据项目特征制定分层测试策略。当用户需要制定测试策略、确定测试方法或编写测试计划时自动触发。\r\n  也适用于：新项目启动需要确定测试方案，或现有测试策略需要优化调整时。\r\n   关键词：测试策略、分层测试、测试计划、方案设计、测试范围、风险策略、自动化策略、质量策略、测试分层模型。\nwhen_to_use: 用户说\"测试策略\"、\"怎么测\"、\"测试计划\"、\"方案设计\"、\"测试范围\"、\"质量策略\"、需要制定测试策略、新项目启动确定测试方案时\r\nallowed-tools: Read Grep Glob\r\nrelated_skills:\r\n  upstream:\r\n    - qa-risk-intuition          # 输入：风险评估结果\r\n    - qa-req-deconstruction      # 输入：需求分析结果\r\n  downstream:\r\n    - qa-release-risk-governance # 输出：测试策略用于发布评估\r\ninput_format: 风险评估 + 需求分析\r\noutput_format: 测试策略（分层策略 + 手段选择 + 资源分配 + 准入准出）\r\n---\r\n\r\n# 测试策略制定\r\n\r\n## Overview\r\n\r\n你是一位测试策略专家，擅长根据项目特征制定分层测试策略。\r\n**核心原则**：根据项目特征（工期/复杂度/团队/风险）制定分层测试策略。\r\n本技能覆盖测试策略六要素（背景/风险/分层/手段/资源/准入准出）。\r\n\r\n## 测试策略六要素\r\n\r\n### 要素1：项目背景评估\r\n\r\n```\r\n评估维度：\r\n├─ 项目阶段：新项目/迭代优化/维护阶段\r\n├─ 团队规模：人员数量和经验水平\r\n├─ 技术栈：技术复杂度和团队熟悉度\r\n├─ 工期：开发周期和测试周期\r\n└─ 历史质量：历史Bug密度和漏测率\r\n\r\n评估结果：\r\n- 项目阶段：[新项目/迭代/维护]\r\n- 团队：[X人，经验水平]\r\n- 技术栈：[复杂度]\r\n- 工期：[X周]\r\n- 历史质量：[Bug密度/漏测率]\r\n```\r\n\r\n### 要素2：风险分析\r\n\r\n```\r\n风险识别：\r\n├─ 业务风险：核心功能/资金/安全\r\n├─ 技术风险：新架构/复杂逻辑/第三方\r\n├─ 进度风险：工期紧/人员不足\r\n└─ 质量风险：历史问题多/复杂度高\r\n\r\n风险等级：\r\n- 高风险：必须深测\r\n- 中风险：常规测试\r\n- 低风险：冒烟测试\r\n```\r\n\r\n### 要素3：分层策略\r\n\r\n```\r\n测试金字塔：\r\n                    ┌─────────┐\r\n                    │  E2E测试  │  10%\r\n                    ├─────────┤\r\n                    │  接口测试  │  30%\r\n                    ├─────────┤\r\n                    │  单元测试  │  60%\r\n                    └─────────┘\r\n\r\n分层比例：\r\n├─ 单元测试：60-70%（核心逻辑）\r\n├─ 接口测试：20-30%（业务流程）\r\n├─ E2E测试：10%（核心路径）\r\n└─ 探索测试：补充（复杂场景）\r\n```\r\n\r\n### 要素4：手段选择\r\n\r\n```\r\n自动化 vs 手动：\r\n├─ 自动化：回归测试/冒烟测试/数据驱动\r\n├─ 手动：探索测试/用户体验/兼容性\r\n└─ 工具辅助：性能测试/安全测试/接口测试\r\n\r\n选择依据：\r\n- 重复执行：自动化\r\n- 复杂判断：手动\r\n- 数据驱动：自动化\r\n- 探索性：手动\r\n```\r\n\r\n### 要素5：资源分配\r\n\r\n```\r\n资源分配：\r\n├─ 人力分配：测试人员角色和任务\r\n├─ 时间分配：各阶段测试时间\r\n├─ 环境分配：测试环境准备\r\n└─ 工具分配：测试工具准备\r\n\r\n时间分配：\r\n- 需求分析：10%\r\n- 用例设计：20%\r\n- 测试执行：50%\r\n- 回归测试：15%\r\n- 报告总结：5%\r\n```\r\n\r\n### 要素6：准入准出标准\r\n\r\n```\r\n准入标准：\r\n├─ 需求评审通过\r\n├─ 开发自测通过\r\n├─ 冒烟测试通过\r\n├─ 测试环境就绪\r\n└─ 测试数据准备\r\n\r\n准出标准：\r\n├─ 用例执行率 ≥ 95%\r\n├─ 用例通过率 ≥ 90%\r\n├─ 高严重度Bug修复率 = 100%\r\n├─ 中严重度Bug修复率 ≥ 90%\r\n└─ 无阻塞性Bug\r\n```\r\n\r\n## 策略输出模板\r\n\r\n```markdown\r\n# 测试策略\r\n\r\n## 1. 项目背景\r\n- 项目阶段：[阶段]\r\n- 团队：[规模和经验]\r\n- 技术栈：[复杂度]\r\n- 工期：[周期]\r\n\r\n## 2. 风险分析\r\n- 高风险区域：[列表]\r\n- 中风险区域：[列表]\r\n- 低风险区域：[列表]\r\n\r\n## 3. 测试策略\r\n- 单元测试：[比例和范围]\r\n- 接口测试：[比例和范围]\r\n- E2E测试：[比例和范围]\r\n- 探索测试：[比例和范围]\r\n\r\n## 4. 手段选择\r\n- 自动化范围：[哪些需要自动化]\r\n- 手动范围：[哪些需要手动]\r\n- 工具选择：[使用什么工具]\r\n\r\n## 5. 资源分配\r\n- 人力：[分配方案]\r\n- 时间：[时间节点]\r\n- 环境：[环境准备]\r\n- 工具：[工具准备]\r\n\r\n## 6. 准入准出\r\n- 准入标准：[标准列表]\r\n- 准出标准：[标准列表]\r\n```\r\n\r\n## Examples\r\n\r\n**电商下单功能测试策略（工期2周，团队4人）**\r\n→ 背景评估：核心功能+高并发+三方支付，中高风险\r\n→ 分层策略：单元（开发自测）→集成（支付接口深测）→E2E（全流程冒烟）\r\n→ 手段选择：接口自动化为主，UI自动化覆盖核心路径，探索式测试做补盲\r\n→ 资源分配：接口自动化3人×5天，UI自动化1人×3天，探索1人×2天\r\n\r\n**新项目启动，PM问\"怎么测\"**\r\n→ 启动测试策略六要素系统化评估，输出可执行的测试方案\r\n\r\n## Guidelines\r\n\r\n测试策略完成后检查：\r\n- [ ] 项目背景评估是否完整？\r\n- [ ] 风险分析是否准确？\r\n- [ ] 分层策略是否合理？\r\n- [ ] 手段选择是否恰当？\r\n- [ ] 资源分配是否可行？\r\n- [ ] 准入准出是否明确？\n\nFile v1.4.0:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-test-strategy-design\",\n  \"version\": \"1.4.0\",\n  \"publishedAt\": 1782278173688\n}\n\nFile v1.4.0:skill-card.md\n\n## Description: <br>\nHelps agents design layered QA test strategies from project context, risk analysis, testing methods, resource allocation, and entry and exit criteria. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[kokxi](https://clawhub.ai/user/kokxi) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nQA engineers, developers, and project teams use this skill when they need a test strategy, test plan, test scope, or quality approach for a new or existing project. It guides an agent to produce a six-part strategy covering background, risks, layered test coverage, method selection, resources, and entry and exit criteria. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may activate on broad testing phrases and read workspace context while forming a plan. <br>\nMitigation: Use it in workspaces where project-file inspection for QA planning is acceptable. <br>\nRisk: Generated test strategies may miss project-specific risks or suggest unsuitable coverage, resources, or release criteria. <br>\nMitigation: Review the strategy against requirements, risk assessment, team capacity, and release criteria before relying on it. <br>\n\n\n## Reference(s): <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Markdown, Guidance] <br>\n**Output Format:** [Markdown test strategy plan] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Covers project background, risk analysis, layered testing, method choice, resource allocation, and entry/exit criteria.] <br>\n\n## Skill Version(s): <br>\n1.4.0 (source: server evidence release.version) <br>\n\n## Ethical Considerations: <br>\nUsers 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. <br>","readmeExcerpt":"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","codeSnippets":[],"executableExamples":[{"language":"markdown","snippet":"**策略 ID**：STRAT-PAY-001   **关联需求**：REQ-PAY-001\n\n### 1. 项目背景      → 阶段/团队/技术栈熟悉度/工期/历史质量\n### 2. 风险分析      → 引用 RISK- ID 与等级，本技能不重算阈值\n### 3. 测试范围      → 测什么 / **不测什么** / 测到什么程度\n### 4. 分层策略      → 单元 60% / 接口 30% / E2E 10% / 探索补充\n### 5. 手段选择      → 自动化/手动/工具辅助 + 理由\n### 6. 资源分配      → 人力/时间/环境/工具\n### 7. 准入准出      → 本项目采用值 + 依据（非照抄模板）\n### 8. 风险与应对    → 环境未就绪等外部依赖的预案"},{"language":"text","snippet":"评估维度：\n├─ 项目阶段：新项目 / 迭代优化 / 维护阶段\n├─ 团队规模：人员数量和经验水平\n├─ 技术栈：技术复杂度和团队熟悉度\n├─ 工期：开发周期和测试周期\n└─ 历史质量：历史 Bug 密度和漏测率\n\n评估结果：\n- 项目阶段：[新项目/迭代/维护]\n- 团队：[X 人，经验水平]\n- 技术栈：[复杂度 + 团队熟悉度]\n- 工期：[开发 X 周 / 测试 Y 周]\n- 历史质量：[Bug 密度、漏测率]"},{"language":"text","snippet":"风险识别：\n├─ 业务风险：核心功能 / 资金 / 安全\n├─ 技术风险：新架构 / 复杂逻辑 / 第三方\n├─ 进度风险：工期紧 / 人员不足\n└─ 质量风险：历史问题多 / 复杂度高"},{"language":"text","snippet":"测试金字塔：\n                ┌─────────┐\n                │  E2E测试 │  10%\n                ├─────────┤\n                │ 接口测试 │  30%\n                ├─────────┤\n                │ 单元测试 │  60%\n                └─────────┘\n\n分层比例（按业务风险调整）：\n├─ 单元测试：60-70%（核心逻辑，开发者自测）\n├─ 接口测试：20-30%（业务流程，服务间契约）\n├─ E2E 测试：10%（核心路径，成本最高）\n└─ 探索测试：补充（复杂场景、自动化难覆盖的部分）"},{"language":"text","snippet":"自动化 vs 手动：\n├─ 自动化：回归测试 / 冒烟测试 / 数据驱动\n├─ 手动：探索测试 / 用户体验 / 兼容性\n└─ 工具辅助：性能测试 / 安全测试 / 接口测试\n\n选择依据：\n- 重复执行 → 自动化\n- 复杂判断 → 手动\n- 数据驱动 → 自动化\n- 探索性 → 手动"},{"language":"text","snippet":"资源分配：\n├─ 人力分配：测试人员角色和任务\n├─ 时间分配：各阶段测试时间\n├─ 环境分配：测试环境准备\n└─ 工具分配：测试工具准备\n\n时间分配（参考值，按项目调整）：\n- 需求分析：10%\n- 用例设计：20%\n- 测试执行：50%\n- 回归测试：15%\n- 报告总结：5%"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: qa-test-strategy-design\ndescription: >-\n  当新项目启动需要制定测试方案、或者迭代开始前需要确定\"这期怎么测\"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道\"测什么、不测什么、为什么\"——其中\"不测什么\"往往比\"测什么\"更能体现决策质量。输出风险矩阵、分级测试方案与准入准出标准的测试策略文档。\n  触发场景：测试策略、怎么测、测试计划、方案设计、测试范围、质量策略、新项目启动确定测试方案时。 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.\nlicense: MIT\nallowed-tools: Read Grep Glob\nmetadata:\n  display-name: \"Test Strategy Design\"\n  version: \"1.8.0\"\n  when-to-use: \"用户说\\\"测试策略\\\"、\\\"怎么测\\\"、\\\"测试计划\\\"、\\\"方案设计\\\"、\\\"测试范围\\\"、\\\"质量策略\\\"、需要制定测试策略、新项目启动确定测试方案时\"\n  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\\\"]}\"\n  references: \"[\\\"references/six-elements.md\\\",\\\"assets/strategy-doc.md\\\"]\"\n  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\\\":\\\"测试资源限制\\\"}]}\"\n  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%\\\\\\\"绝对化表述\\\"]}\"\n  error-recovery-guidance: \"{\\\"on_failure\\\":\\\"策略遗漏高风险区域时回退到风险评估补充\\\",\\\"retry_behavior\\\":\\\"补充评估后重新制定策略\\\"}\"\n  categories: \"[\\\"Development\\\",\\\"Testing\\\",\\\"DevOps\\\"]\"\n  depth-requirement: \"{\\\"reference_value\\\":\\\"见正文「策略深度要求」表：简单/中等/复杂项目对应不同要素覆盖数与文档篇幅\\\",\\\"minimum\\\":\\\"至少覆盖 项目背景/测试范围/风险分析/资源分配 4 个核心维度；未覆盖要素须说明原因\\\"}\"\n---\n\n> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills\n\n> **⚠️ 安全警告**：本技能的示例可能涉及发布评估和 CI/CD 流水线的策略引用。\n> 这些是策略参考不是直接操作；请勿未经授权即执行发布或变更流水线配置。\n> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。\n\n# 测试策略制定\n\n## 核心原则\n\n一个好的测试策略让团队知道 **\"测什么、不测什么、为什么\"**。\n\n其中 **\"不测什么\"往往比\"测什么\"更能体现决策质量**——写不出排除项的策略，本质上是测试清单不是测试策略。\n\n## 1. 六要素速查\n\n| # | 要素 | 回答什么 | 最容易漏 |\n|---|------|---------|---------|\n| 1 | 项目背景 | 什么阶段、什么团队、多长工期 | **团队对技术栈的熟悉度** |\n| 2 | 风险分析 | 哪些地方危险 | 进度风险（往往被当成\"非技术问题\"忽略） |\n| 3 | 测试范围 | **测什么 / 不测什么** | **不测什么** |\n| 4 | 分层策略 | 单元/接口/E2E 各占多少 | E2E 占比（容易堆太多） |\n| 5 | 手段选择 | 哪些自动化、哪些手动 | 判断标准（应看重复次数与结果确定度） |\n| 6 | 准入准出 | 什么时候能开始测、什么时候能发 | **本项目采用值与依据** |\n\n> 逐要素的评估方法见 `references/six-elements.md`。\n\n## 2. 风险等级口径\n\n**不在本技能重新定义阈值**——直接引用 `qa-risk-intuition` 的结论：\n\n| 风险分数 | 等级 | 测试深度 |\n|---------|------|---------|\n| ≥ 45 | 高 | 深测 |\n| 15 – 44 | 中 | 常规 |\n| ≤ 14 | "},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-test-strategy-design\",\n  \"version\": \"1.8.0\",\n  \"publishedAt\": 1790656189195\n}"},{"path":"references/six-elements.md","content":"# 测试策略六要素详解\n\n> 本文是 `qa-test-strategy-design` 的**方法详图**。需要逐要素展开、或要填具体数值时读本文；\n> 只想知道策略该覆盖哪几块时读 `SKILL.md` 的六要素速查即可。\n\n---\n\n## 要素 1：项目背景评估\n\n```text\n评估维度：\n├─ 项目阶段：新项目 / 迭代优化 / 维护阶段\n├─ 团队规模：人员数量和经验水平\n├─ 技术栈：技术复杂度和团队熟悉度\n├─ 工期：开发周期和测试周期\n└─ 历史质量：历史 Bug 密度和漏测率\n\n评估结果：\n- 项目阶段：[新项目/迭代/维护]\n- 团队：[X 人，经验水平]\n- 技术栈：[复杂度 + 团队熟悉度]\n- 工期：[开发 X 周 / 测试 Y 周]\n- 历史质量：[Bug 密度、漏测率]\n```\n\n> **\"团队熟悉度\"比\"技术复杂度\"更重要**。团队不熟的新技术栈，风险主要来自\n> 理解偏差而非实现难度——这两类风险要用不同手段应对。\n\n---\n\n## 要素 2：风险分析\n\n```text\n风险识别：\n├─ 业务风险：核心功能 / 资金 / 安全\n├─ 技术风险：新架构 / 复杂逻辑 / 第三方\n├─ 进度风险：工期紧 / 人员不足\n└─ 质量风险：历史问题多 / 复杂度高\n```\n\n> **风险等级与测试深度的映射统一由 `qa-risk-intuition` 定义**（≥45 高→深测 /\n> 15-44 中→常规 / ≤14 低→冒烟）。本技能**不重新定义阈值**，\n> 直接引用上游评估结论——避免同一项目里出现两套风险口径。\n\n---\n\n## 要素 3：分层策略\n\n```text\n测试金字塔：\n                ┌─────────┐\n                │  E2E测试 │  10%\n                ├─────────┤\n                │ 接口测试 │  30%\n                ├─────────┤\n                │ 单元测试 │  60%\n                └─────────┘\n\n分层比例（按业务风险调整）：\n├─ 单元测试：60-70%（核心逻辑，开发者自测）\n├─ 接口测试：20-30%（业务流程，服务间契约）\n├─ E2E 测试：10%（核心路径，成本最高）\n└─ 探索测试：补充（复杂场景、自动化难覆盖的部分）\n```\n\n> **不要在 CI 里堆满慢的 E2E**。E2E 只跑核心路径，其余靠接口层拦截。\n> 分层配比的具体落地（流水线卡点）交 `qa-ci-cd-testing`。\n\n---\n\n## 要素 4：手段选择\n\n```text\n自动化 vs 手动：\n├─ 自动化：回归测试 / 冒烟测试 / 数据驱动\n├─ 手动：探索测试 / 用户体验 / 兼容性\n└─ 工具辅助：性能测试 / 安全测试 / 接口测试\n\n选择依据：\n- 重复执行 → 自动化\n- 复杂判断 → 手动\n- 数据驱动 → 自动化\n- 探索性 → 手动\n```\n\n> 判断标准是**重复次数**与**结果确定度**，不是\"这个功能重不重要\"。\n> 一次性的核心功能手工测完全合理；天天跑的边缘功能反而必须自动化。\n\n---\n\n## 要素 5：资源分配\n\n```text\n资源分配：\n├─ 人力分配：测试人员角色和任务\n├─ 时间分配：各阶段测试时间\n├─ 环境分配：测试环境准备\n└─ 工具分配：测试工具准备\n\n时间分配（参考值，按项目调整）：\n- 需求分析：10%\n- 用例设计：20%\n- 测试执行：50%\n- 回归测试：15%\n- 报告总结：5%\n```\n\n---\n\n## 要素 6：准入准出标准\n\n```text\n准入标准（可开始测试的前提）：\n├─ 需求评审通过\n├─ 开发自测通过\n├─ 冒烟测试通过\n├─ 测试环境就绪\n└─ 测试数据准备\n\n准出标准（可发布的门槛）：\n├─ 用例执行率 ≥ 95%\n├─ 用例通过率 ≥ 90%\n├─ 高严重度 Bug 修复率 = 100%\n├─ 中严重度 Bug 修复率 ≥ 90%\n└─ 无阻塞性 Bug\n```\n\n> 上述百分比是**默认模板值**，不是行业标准。项目应根据历史数据校准：\n> 一个长期执行率 100% 的团队，把准出定在 95% 等于形同虚设。\n> 定得太松会让准出失去拦截作用，定得太严会逼着团队刷执行率。\n> **每个项目应显式写出自己采用的值与依据。**"},{"path":"assets/strategy-doc.md","content":"# 测试策略文档模板\n\n> 复制下面整块板填写。六要素的评估方法见 [`six-elements.md`](six-elements.md)。\n\n## 测试策略\n\n**策略 ID**：STRAT-{模块缩写}-{三位序号}\n**关联需求**：REQ-{模块缩写}-{序号}\n**版本 / 日期**：v1.0 / YYYY-MM-DD\n\n### 1. 项目背景\n\n| 项 | 内容 |\n|----|------|\n| 项目阶段 | [新项目/迭代/维护] |\n| 团队 | [X 人，经验水平] |\n| 技术栈 | [复杂度 + 团队熟悉度] |\n| 工期 | [开发 X 周 / 测试 Y 周] |\n| 历史质量 | [Bug 密度、漏测率] |\n\n### 2. 风险分析\n\n> 风险等级直接引用 `qa-risk-intuition` 的结论（≥45 高→深测 / 15-44 中→常规 / ≤14 低→冒烟），\n> 本策略不重新定义阈值。\n\n| 风险等级 | 区域 | 测试深度 | 依据 |\n|---------|------|---------|------|\n| 高 | [如 支付/并发回调] | 深测 | RISK-PAY-CONC-002（125 分） |\n| 中 | [如 订单/导出] | 常规 | RISK-ORDER-EXPORT-005（27 分） |\n| 低 | [如 通知/推送] | 冒烟 | RISK-NOTIFY-PUSH-004（3 分） |\n\n**本项目不测什么**（写明比不写更有价值）：\n- [如：后台运营管理页面 —— 内部使用、无资金风险、不在本次迭代范围]\n\n### 3. 测试范围\n\n| 范围类型 | 内容 |\n|---------|------|\n| **测什么** | [功能模块清单 + 对应需求 ID] |\n| **不测什么** | [明确排除项 + 原因] |\n| **测到什么程度** | [深度定义：冒烟/常规/深测] |\n\n### 4. 分层策略\n\n| 层级 | 占比 | 覆盖内容 | 执行时机 |\n|------|------|---------|---------|\n| 单元测试 | 60% | 核心逻辑 | 开发者自测，提交时 |\n| 接口测试 | 30% | 业务流程、服务间契约 | 提交后 / 每日 |\n| E2E 测试 | 10% | 核心路径 | 发版前 |\n| 探索测试 | 补充 | 自动化难覆盖部分 | 迭代中穿插 |\n\n### 5. 手段选择\n\n| 手段 | 范围 | 理由 |\n|------|------|------|\n| 自动化 | [回归/冒烟/数据驱动] | 重复执行，结果确定 |\n| 手动 | [探索/体验/兼容性] | 需人工判断 |\n| 工具辅助 | [性能/安全/接口] | [选择与理由] |\n\n### 6. 资源分配\n\n| 维度 | 方案 |\n|------|------|\n| 人力 | [角色与任务分配] |\n| 时间 | 需求分析 10% / 用例设计 20% / 执行 50% / 回归 15% / 报告 5%（按项目调整） |\n| 环境 | [环境数量与准备时间] |\n| 工具 | [工具清单与选型理由] |\n\n### 7. 准入准出标准\n\n**准入**（可开始测试）\n- [ ] 需求评审通过\n- [ ] 开发自测通过\n- [ ] 冒烟测试通过\n- [ ] 测试环境就绪\n- [ ] 测试数据准备\n\n**准出**（可发布）\n\n| 指标 | 本项目采用值 | 默认模板 | 依据 |\n|------|------------|---------|------|\n| 用例执行率 | [ ] | ≥95% | [历史数据/项目约定] |\n| 用例通过率 | [ ] | ≥90% | [ ] |\n| 高严重度 Bug 修复率 | [ ] | 100% | [ ] |\n| 中严重度 Bug 修复率 | [ ] | ≥90% | [ ] |\n| 阻塞性 Bug | [ ] | 0 | [ ] |\n\n> **必须写明本项目采用值与依据**。直接抄默认模板而不校准，准出会形同虚设\n> （长期执行率 100% 的团队把准出定在 95% 没有任何拦截作用）。\n\n### 8. 风险与应对\n\n| 风险 | 影响 | 应对 |\n|------|------|------|\n| [如 第三方支付联调环境未就绪] | [阻塞接口层测试] | [提前 Mock / 申请沙箱] |\n\n## 填写要求\n\n| 项 | 要求 | 常见错误 |\n|----|------|---------|\n| 策略 ID | `STRAT-{模块缩写}-{三位序号}` | 用 `TC_` 或 `REQ-` 前缀 |\n| 风险等级 | 引用 `qa-risk-intuition` 结论，不自己重算 | 本技能另定一套阈值 |\n| **不测什么** | **必填**，写明排除项与原因 | 留空（等于没做取舍决策） |\n| 分层占比 | 合计 100%；按业务风险可调但要说明 | 各层都是\"重要\"导致全是 100% |\n| 准出标准 | 写本项目采用值 + 依据 | 照抄模板不校准 |\n| 覆盖率 | 标注口径（如\"基于现有需求文档\"） | \"全覆盖\"\"100%\" |\n\n## 交付前自检\n\n- [ ] 六要素全部有内容；简单项目可只覆盖 4 个但需说明省略原因\n- [ ] 风险等级引用上游 `qa-risk-intuition`，未另立阈值\n- [ ] **\"不测什么\"已明确写出**（策略的价值一半在这里）\n- [ ] 分层占比合计 100%，且说明了偏离默认配比的理由\n- [ ] 准出标准写明了本项目采用值与依据\n- [ ] 关联需求 ID 格式为 `REQ-`\n- [ ] 策略 ID 格式为 `STRAT-`\n- [ ] 无\"全覆盖/100%\"绝对化表述"},{"path":"skill-card.md","content":"## Description:\n\nDesigns risk-based test strategies for new projects and iterations, defining test scope, layered coverage, resources, and project-specific entry and exit criteria.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA 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.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Installing the broader workflow may bring in additional, unreviewed skills.\n\nMitigation: Review its source and use a pinned, trusted package version before installing.\n\nRisk: Strategy examples could be mistaken for approval to change release or CI/CD settings.\n\nMitigation: Treat the document as planning guidance and require authorized review before applying operational changes.\n\n## Reference(s):\n\n- [ClawHub skill release](https://clawhub.ai/kokxi/skills/qa-test-strategy-design)\n- [Six Elements of Test Strategy](references/six-elements.md)\n- [Test Strategy Document Template](assets/strategy-doc.md)\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Guidance]\n\n**Output Format:** [Markdown test strategy document]\n\n**Output Parameters:** [1D]\n\n**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.]\n\n## Skill Version(s):\n\n1.8.0 (source: skill frontmatter and ClawHub release)\n\n## Ethical Considerations:\n\nUsers 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."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"当新项目启动需要制定测试方案、或者迭代开始前需要确定\"这期怎么测\"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道\"测什么、不测什么、为什么\"——其中\"不测什么\"往往比\"测什么\"更能体现决策质量。输出风险矩阵、分级测试方案与准入准出标准的测试策略文档。 触发场景：测试策略、怎么测、测试计划、方案设计、测试范围、质量策略、新项目启动确定测试方案时。 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","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1149,"uniquenessScore":48,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T02:12:21.460Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T02:12:21.460Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T04:34:54.710Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"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!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"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","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}