{"id":"f983cb04-5197-4420-bf0a-a1e10a30a4b4","entityType":"agent","slug":"clawhub-kokxi-qa-test-case-design","name":"qa-test-case-design","canonicalUrl":"https://www.xpersona.co/agent/clawhub-kokxi-qa-test-case-design","canonicalPath":"/agent/clawhub-kokxi-qa-test-case-design","generatedAt":"2026-10-11T03:55:04.890Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T01:49:26.225Z","emptyReason":null},"description":"当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。 触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing structured test cases with P0-P3 prioritization, the canonical 9-column format, coverage strategy, and requirement traceability. Skill: qa-test-case-design Owner: kokxi Summary: 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。 触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing structured test cases with P0-P3 prioritization, the canonical 9-column format, coverage strategy, and requirement traceability. Tags: la","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-case-design","sourceUrl":"https://clawhub.ai/kokxi/qa-test-case-design","homepage":"https://clawhub.ai/kokxi/skills/qa-test-case-design","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/kokxi/qa-test-case-design","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/kokxi/skills/qa-test-case-design","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":62,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。 触发场景：设计测试用例、用例评审、用例覆盖、测试"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T01:49:26.225Z","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-11T01:49:26.225Z","emptyReason":null},"stars":null,"forks":null,"downloads":1200,"packageName":null,"latestVersion":"1.8.0","tractionLabel":"1.2K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T01:49:26.209Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T01:49:26.225Z","lastCrawledAt":"2026-10-11T01:49:26.209Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T01:49:26.209Z","lastVerifiedAt":null,"highlights":[{"version":"1.8.0","createdAt":"2026-09-29T04:17:23.725Z","changelog":"1.8.0","fileCount":8,"zipByteSize":17974},{"version":"1.7.7","createdAt":"2026-09-27T14:42:44.151Z","changelog":"1.7.7","fileCount":7,"zipByteSize":13779},{"version":"1.7.6","createdAt":"2026-09-01T12:48:00.412Z","changelog":"显示名改中文","fileCount":7,"zipByteSize":14069},{"version":"1.7.5","createdAt":"2026-08-30T15:20:42.259Z","changelog":"1.7.5: 版本号升级","fileCount":7,"zipByteSize":13956},{"version":"1.7.0","createdAt":"2026-08-16T14:33:20.118Z","changelog":"- Removed the redundant file skill-card.md to streamline documentation. - No user-facing changes were made to the skill's logic or guidance; documentation cleanup only.","fileCount":7,"zipByteSize":13568},{"version":"1.6.3","createdAt":"2026-08-12T15:29:46.748Z","changelog":"- 增加 skill 配置字段 slug 和 displayName，更规范技能元数据定义。 - 升级版本为 1.6.3。 - 移除多余的 skill-card.md 文件，简化项目结构。 - 优化 references/output-template-full.md 的引用/说明，强调详细模板存放位置。 - 其余文档内容保持一致，无破坏性调整。","fileCount":7,"zipByteSize":13663},{"version":"1.6.0","createdAt":"2026-07-06T17:18:37.674Z","changelog":"- Added full output template as a dedicated reference file (`references/output-template-full.md`) - Moved detailed字段模板、编号规则和输出格式等结构内容到外部引用，主文档只保留核心字段与简要说明 - 明确 references 列表，增加 categories 字段，并新增 error_recovery_guidance 指南 - 删除冗余 skill-card.md，精简主文档篇幅，提升查阅效率 - 补充下游衔接技能（如 qa-regression-testing）以完善用例设计全流程","fileCount":7,"zipByteSize":13702},{"version":"1.5.0","createdAt":"2026-06-29T12:36:38.186Z","changelog":"qa-test-case-design 1.5.0 - ✨ 结构与内容全面升级，部分深度内容拆分为独立参考文件（references/）。 - 新增 references/design-methods.md、references/coverage-and-quality.md、references/review-standards.md，整理用例设计方法、覆盖评价、评审标准等细节。 - skill-card.md 文件移除，参考资源集中至 references/ 目录。 - SKILL.md 大量精简，聚焦用例结构规范、分级规则与输出模板，引用外部详解以减少正文冗杂。 - 明确输入输出格式、追溯及层次化深度要求，更易与上游分析衔接，保证用例全面可追溯","fileCount":6,"zipByteSize":12800}]},"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-case-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-case-design/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-case-design/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-case-design/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-case-design/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-case-design/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-case-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-11T03:55:04.886Z"}},"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-case-design/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-case-design/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-case-design/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-case-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-11T01:49:26.225Z","emptyReason":null},"readme":"Skill: qa-test-case-design\n\nOwner: kokxi\n\nSummary: 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。 触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing structured test cases with P0-P3 prioritization, the canonical 9-column format, coverage strategy, and requirement traceability.\n\nTags: latest:1.8.0\n\nVersion history:\n\nv1.8.0 | 2026-09-29T04:17:23.725Z | user\n\n1.8.0\n\nv1.7.7 | 2026-09-27T14:42:44.151Z | user\n\n1.7.7\n\nv1.7.6 | 2026-09-01T12:48:00.412Z | user\n\n显示名改中文\n\nv1.7.5 | 2026-08-30T15:20:42.259Z | user\n\n1.7.5: 版本号升级\n\nv1.7.0 | 2026-08-16T14:33:20.118Z | auto\n\n- Removed the redundant file skill-card.md to streamline documentation.\n- No user-facing changes were made to the skill's logic or guidance; documentation cleanup only.\n\nv1.6.3 | 2026-08-12T15:29:46.748Z | auto\n\n- 增加 skill 配置字段 slug 和 displayName，更规范技能元数据定义。\n- 升级版本为 1.6.3。\n- 移除多余的 skill-card.md 文件，简化项目结构。\n- 优化 references/output-template-full.md 的引用/说明，强调详细模板存放位置。\n- 其余文档内容保持一致，无破坏性调整。\n\nv1.6.0 | 2026-07-06T17:18:37.674Z | auto\n\n- Added full output template as a dedicated reference file (`references/output-template-full.md`)\n- Moved detailed字段模板、编号规则和输出格式等结构内容到外部引用，主文档只保留核心字段与简要说明\n- 明确 references 列表，增加 categories 字段，并新增 error_recovery_guidance 指南\n- 删除冗余 skill-card.md，精简主文档篇幅，提升查阅效率\n- 补充下游衔接技能（如 qa-regression-testing）以完善用例设计全流程\n\nv1.5.0 | 2026-06-29T12:36:38.186Z | auto\n\nqa-test-case-design 1.5.0\n\n- ✨ 结构与内容全面升级，部分深度内容拆分为独立参考文件（references/）。\n- 新增 references/design-methods.md、references/coverage-and-quality.md、references/review-standards.md，整理用例设计方法、覆盖评价、评审标准等细节。\n- skill-card.md 文件移除，参考资源集中至 references/ 目录。\n- SKILL.md 大量精简，聚焦用例结构规范、分级规则与输出模板，引用外部详解以减少正文冗杂。\n- 明确输入输出格式、追溯及层次化深度要求，更易与上游分析衔接，保证用例全面可追溯\n\nv1.4.1 | 2026-06-25T16:57:22.156Z | auto\n\n## Version 1.4.1 Changelog\n\n- Major refactor: simplified and streamlined the documentation and process guidance.\n- Rewrote SKILL.md content for improved clarity, conciseness, and focus on actionable standards.\n- Removed skill-card.md.\n- Updated downstream dependency from qa-test-workflow to qa-test-skills.\n- Core methodology, use case structure, coverage strategy, and review standards remain robust but with less redundancy and clearer instructions.\n\nv1.4.0 | 2026-06-24T05:13:23.409Z | auto\n\n- Expanded skill关键词，增加了用例评审、用例规范、用例模板等相关表述，覆盖更多测试用例设计和评审场景\n- 放宽了自动触发条件，支持“用例模板”“用例规范”等场景，提升使用覆盖面\n- 移除了 skill-card.md，精简 skill 结构\n- 其他内容保持一致，保持测试用例设计原则、方法和模板的规范性\n\nv1.3.0 | 2026-06-23T10:50:59.994Z | auto\n\n- 增强说明文档，系统化阐述测试用例结构、分类和覆盖策略，强调用例设计严禁读取代码、必须基于需求文档。\n- 明确输出规范，提供标准用例字段模板、编号规则和输出格式，强制测试步骤留空以适配多系统场景。\n- 补充页面跳转、路由参数、跨页面联动等复杂场景的需求文档要求，细化需求检查清单与需求不足时处理。\n- 丰富覆盖策略与测试方法，详列功能、数据、权限、集成和非功能测试的覆盖维度及实践要点。\n- 扩充评审标准，提高用例完整性、独立性、可维护性与可执行性要求。\n- 适合需要提升测试用例系统设计、结构规范和覆盖全面性的场景。\n\nArchive index:\n\nArchive v1.8.0: 8 files, 17974 bytes\n\nFiles: assets/case-table.md (4315b), references/coverage-and-quality.md (3596b), references/design-methods.md (5605b), references/output-template-full.md (6015b), references/review-standards.md (3326b), skill-card.md (2190b), SKILL.md (10312b), _meta.json (138b)\n\nFile v1.8.0:SKILL.md\n\n---\nname: qa-test-case-design\ndescription: >-\n 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。\n 触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing structured test cases with P0-P3 prioritization, the canonical 9-column format, coverage strategy, and requirement traceability.\nlicense: MIT\nallowed-tools: Read Grep Glob\nmetadata:\n display-name: \"Test Case Design\"\n version: \"1.8.0\"\n when-to-use: \"用户说\\\"设计测试用例\\\"、\\\"用例评审\\\"、\\\"用例覆盖\\\"、\\\"测试用例设计\\\"、\\\"用例模板\\\"、\\\"用例规范\\\"、\\\"用例格式\\\"、需要测试用例结构指导、需要编写或规范测试用例时\"\n related-skills: \"{\\\"upstream\\\":[\\\"qa-req-deconstruction\\\",\\\"qa-boundary-deep-dive\\\",\\\"qa-scenario-tree\\\"],\\\"downstream\\\":[\\\"qa-test-skills\\\",\\\"qa-expert-review\\\",\\\"qa-regression-testing\\\"]}\"\n references: \"[\\\"assets/case-table.md\\\",\\\"references/output-template-full.md\\\",\\\"references/design-methods.md\\\",\\\"references/coverage-and-quality.md\\\",\\\"references/review-standards.md\\\"]\"\n input-format: \"{\\\"required\\\":[{\\\"name\\\":\\\"需求描述\\\",\\\"type\\\":\\\"string\\\",\\\"description\\\":\\\"功能需求的详细说明\\\"}],\\\"optional\\\":[{\\\"name\\\":\\\"场景分析\\\",\\\"type\\\":\\\"object\\\",\\\"description\\\":\\\"来自qa-scenario-tree的场景树\\\"},{\\\"name\\\":\\\"边界条件\\\",\\\"type\\\":\\\"object\\\",\\\"description\\\":\\\"来自qa-boundary-deep-dive的边界分析结果\\\"},{\\\"name\\\":\\\"业务背景\\\",\\\"type\\\":\\\"string\\\",\\\"description\\\":\\\"业务目标和用户角色\\\"}]}\"\n output-format: \"{\\\"traceability\\\":[\\\"每个用例带唯一ID：TC_{模块缩写}_{功能缩写}_{三位序号}（如 TC_API_LOGIN_001）——不使用场景后缀\\\",\\\"关联需求ID：REQ-{需求模块缩写}-{序号}\\\",\\\"关联场景ID：SC-{场景模块缩写}-{序号}\\\"],\\\"structure\\\":[{\\\"test_case_table\\\":\\\"测试用例表：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）——全项目唯一标准，见 references/output-template-full.md\\\"},\\\"用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）\\\",\\\"测试步骤：协议/接口/规则/计算类必填（含 method+path+关键参数）；UI/业务流程类可留空并标注「由执行人按实际系统补充」\\\",\\\"子功能并入「功能模块」用 模块/子功能 表示，不单设列；无「实际结果」列——那是 qa-execution-observation 的执行记录字段\\\",\\\"覆盖率：标注口径（基于现有需求/上游分析产出），禁止\\\\\\\"全覆盖/100%\\\\\\\"绝对化表述；缺失模块标注\\\\\\\"未覆盖+原因\\\\\\\"\\\"]}\"\n error-recovery-guidance: \"{\\\"on_failure\\\":\\\"用例设计遗漏维度时回退到边界分析和场景树补充\\\",\\\"retry_behavior\\\":\\\"补充上游后重新设计用例\\\"}\"\n categories: \"[\\\"Development\\\",\\\"Testing\\\"]\"\n depth-requirement: \"{\\\"reference_value\\\":\\\"见 references/output-template-full.md；用例总数不低于需求点的 3 倍\\\",\\\"minimum\\\":\\\"9 列齐全、编号唯一且合格式、P0-P3 占比达标、覆盖率标注口径\\\"}\"\n---\n\n> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills\n\n# 测试用例设计专项\n\n## 核心原则\n\n测试用例设计的核心——明确\"测什么\"，而非\"怎么测\"。\n\n> **重要限制**：禁止读取代码。测试用例必须基于需求文档，不得读取代码实现。\n> 确保验证\"系统应该做什么\"，而非\"系统如何实现\"。\n\n> **上游未完成就不要开始**：没有充分输入（需求解构 / 场景树 / 边界清单）时，\n> 生成的用例一定是泛泛的。先补上游，再做本步。\n\n## 1. 九列标准格式（本技能是全项目格式定义者）\n\n| # | 列名 | 必填 | 要点 |\n|---|------|------|------|\n| 1 | 用例编号 | ✅ | `TC_{模块缩写}_{功能缩写}_{三位序号}`，同批不重号 |\n| 2 | 测试类型 | ✅ | 按所属技能维度：功能/安全/异常/性能/契约/兼容性 |\n| 3 | 功能模块 | ✅ | 必要时 `模块/子功能` 两级（子功能并入本列） |\n| 4 | 测试标题 | ✅ | 动词开头，点明验证点 |\n| 5 | 用例级别 | ✅ | P0/P1/P2/P3，占比见下 |\n| 6 | 预置条件 | ✅ | 环境+数据+权限+状态，具体到可复现 |\n| 7 | 测试步骤 | ⚠️ | **协议/规则/计算类必填**；UI/业务流程类可留空 |\n| 8 | 预期结果 | ✅ | 可量化：状态码 / 返回结构 / 数据状态 / 副作用 |\n| 9 | 风险等级 | ✅ | 高（资损/越权/数据错误/安全）/ 中 / 低 |\n\n**为什么是 9 列**：这是 `validate_testcase_table.py` 与最终 `测试用例.csv` 的硬约束，\n**不可增减列**。历史上曾有 10 列版本（含\"子功能\"\"实际结果\"），已废止：\n- 「子功能」并入「功能模块」用 `模块/子功能` 表示，信息不丢\n- 「实际结果」是**执行阶段**字段，由 `qa-execution-observation` 承载，\n 放进设计模板会导致执行时回填污染设计产物\n\n**编号规则**：\n```\nTC_{模块缩写}_{功能缩写}_{三位序号}\nTC_API_LOGIN_001 TC_CART_ADD_007 TC_ORDER_REFUND_003\n```\n> **不使用场景后缀**（如 `_NORMAL`）。场景类别写进「测试类型」与「测试标题」。\n> 旧格式 `TC_USER_LOGIN_001_NORMAL` 已废止。\n\n**级别占比**：P0 ≤ 20% / P1 ≤ 40% / P2 ≤ 30% / P3 ≤ 10%\n\n**小规模例外**：用例总数 < 10 条时配额数学上不成立（20% 不足 1 条）。\n加 `--no-quota` 跳过校验并在报告注明口径。**不要为凑比例编造用例或随意改级别。**\n\n## 2. 「测试步骤」留空还是填（历史分歧的裁决）\n\n| 用例类型 | 步骤 | 理由 |\n|---------|------|------|\n| **协议 / 接口类**（API、gRPC、WebSocket、Webhook、数据库） | **必填**，含 method + path + 关键参数 | 步骤由协议契约决定，不依赖实现，AI 能准确写出 |\n| **配置 / 规则 / 计算类** | **必填** | 同上，规则本身确定 |\n| **UI / 业务流程类** | **可留空**，标注「由执行人按实际系统补充」 | 同一\"登录\"不同系统实现完全不同，AI 强写必然与实际不符 |\n\n> 历史版本一刀切要求\"留空\"，导致 API 类用例丢掉可执行性——而 API 的 method/path\n> 恰恰是**规格的一部分**、不是实现细节。现按类型区分。\n\n## 3. 加载时机\n\n**需要时才读，不要一上来全读**：\n\n| 什么时候读 | 读哪个 |\n|-----------|--------|\n| 拿 9 列模板来填 | [`assets/case-table.md`](assets/case-table.md)（表格 + 展开块两形态 + 逐列填写要求） |\n| 查编号规则、级别定义、两处历史格式变更的来龙去脉 | [`references/output-template-full.md`](references/output-template-full.md)（**格式唯一真源**） |\n| 选设计方法（等价类、判定表、正交、状态迁移、错误推测…） | [`references/design-methods.md`](references/design-methods.md) |\n| 评估覆盖是否够、算覆盖率 | [`references/coverage-and-quality.md`](references/coverage-and-quality.md) |\n| 做用例评审 | [`references/review-standards.md`](references/review-standards.md) |\n\n## 4. 产出\n\n```markdown\n| 用例编号 | 测试类型 | 功能模块 | 测试标题 | 用例级别 | 预置条件 | 测试步骤 | 预期结果 | 风险等级 |\n|---------|---------|---------|---------|---------|---------|---------|---------|---------|\n| TC_API_LOGIN_001 | 功能测试 | 认证/登录 | 正确凭证登录成功 | P0 | 账号 u1 已就绪，接口文档已提供 | POST /api/login，body {\"user\":\"u1\",\"pass\":\"***\"} | 返回 200，响应含 token；调 /api/profile 有效；无堆栈泄露 | 高 |\n| TC_API_LOGIN_002 | 安全测试 | 认证/登录 | 伪造 Token 被拒 | P0 | 已知合法 token 与签名算法 | 改 1 个字符后请求 /api/profile | 返回 401；响应不含内部信息与用户数据 | 高 |\n| TC_API_LOGIN_003 | 异常测试 | 认证/登录 | 写操作超时重试不产生重复副作用 | P1 | 网关可注入延迟；写接口有幂等键 | 令首次请求延迟至超时，按服务端策略重放 2 次 | 重试成功且最终仅 1 次登录成功记录 | 中 |\n```\n\n> 上面 3 行只展示每列写法，完整模板见 `assets/case-table.md`。\n> **任何技能产出用例都必须用这套 9 列**，有冲突以 `references/output-template-full.md` 为准。\n\n## 5. 用例设计原则\n\n**DO**\n- 每个用例只验证一个明确目标\n- 预期结果使用\"应该/必须/会\"等确定性词汇\n- 同时包含正向与反向验证\n- 标注敏感信息的脱敏处理方式\n- 协议类填写具体 method/path/参数\n\n**DON'T**\n- 模糊描述如\"检查是否可以正常工作\"\n- 一个用例混合多个验证点\n- 忽略前置条件与环境配置\n- 用主观判断代替客观测量\n- 忽略异常处理流程\n- 强制生成与实际系统不符的 UI 操作步骤\n\n## 6. 交付前自检\n\n- [ ] **9 列齐全**，无列错位、无单元格含 `|`\n- [ ] 用例编号唯一、3 段式 `TC_{模块}_{功能}_{三位序号}`、无场景后缀\n- [ ] 「功能模块」含子功能时用 `模块/子功能` 表达，未单设列\n- [ ] 未出现「实际结果」列（属执行阶段）\n- [ ] 测试步骤：协议/规则/计算类已填写；UI 类已标注\"由执行人补充\"\n- [ ] 每条用例只验证一个目标\n- [ ] 预期结果可客观验证（不是\"正确\"\"正常\"）\n- [ ] P0-P3 占比达标；<10 条时已注明实际分布口径\n- [ ] 风险等级已填，非全高\n- [ ] 覆盖率已标注口径，无\"全覆盖/100%\"绝对化表述\n- [ ] 缺失模块已标\"未覆盖 + 原因\"\n\n**机器校验**（列数、编号唯一性、级别/风险取值、占比、覆盖率措辞）：\n\n```bash\npython scripts/validate_testcase_table.py <用例文件>\n```\n\nFile v1.8.0:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-test-case-design\",\n \"version\": \"1.8.0\",\n \"publishedAt\": 1790655443725\n}\n\nFile v1.8.0:references/coverage-and-quality.md\n\n# 测试覆盖策略与质量标准\n\n## 覆盖维度\n\n```\n测试覆盖：\n├─ 功能覆盖\n│ ├─ 主流程覆盖：核心业务流程是否完整测试\n│ ├─ 分支流程覆盖：各种条件分支路径是否覆盖\n│ ├─ 异常场景覆盖：错误输入、异常操作是否测试\n│ ├─ 边界条件覆盖：输入范围边界、数量边界是否测试\n│ ├─ 退出流程覆盖：退出登录、注销、超时退出等场景\n│ └─ 状态转换覆盖：系统状态变化是否测试\n│\n├─ 数据覆盖\n│ ├─ 有效数据覆盖：正常数据是否测试\n│ ├─ 无效数据覆盖：异常数据是否测试\n│ ├─ 边界数据覆盖：边界值数据是否测试\n│ ├─ 特殊数据覆盖：特殊字符、超长数据是否测试\n│ ├─ 格式校验覆盖：邮箱、手机号、身份证等格式验证\n│ └─ 注入测试覆盖：SQL注入、XSS攻击等安全测试\n│\n├─ 字段级验证覆盖（每个表单字段必须测试）\n│ ├─ 长度边界：1位、最大长度、最大长度+1\n│ ├─ 格式校验：正则表达式验证（邮箱、手机号、身份证等）\n│ ├─ 注入测试：SQL注入、XSS攻击、命令注入\n│ ├─ 特殊字符：空格、特殊符号、Unicode字符\n│ ├─ 空值处理：必填字段为空、选填字段为空\n│ └─ 默认值：字段默认值是否正确\n│\n├─ 权限覆盖\n│ ├─ 角色权限覆盖：不同角色权限是否测试\n│ ├─ 越权访问覆盖：越权操作是否拦截\n│ ├─ 数据权限覆盖：数据隔离是否验证\n│ ├─ 功能权限覆盖：功能访问控制是否测试\n│ ├─ CSRF防护覆盖：跨站请求伪造防护是否测试\n│ └─ 路径遍历覆盖：目录遍历攻击防护是否测试\n│\n├─ 集成覆盖\n│ ├─ 模块集成覆盖：模块间协作是否测试\n│ ├─ 接口集成覆盖：接口调用是否测试\n│ ├─ 数据集成覆盖：数据流转是否测试\n│ └─ 异常集成覆盖：异常处理是否测试\n│\n└─ 非功能覆盖\n ├─ 性能覆盖：响应时间、吞吐量、并发性能是否测试\n ├─ 兼容性覆盖：浏览器、操作系统、设备兼容性是否测试\n ├─ 可用性覆盖：用户体验、易用性是否测试\n ├─ 安全性覆盖：数据加密、传输安全是否测试\n └─ 可靠性覆盖：稳定性、容错性是否测试\n```\n\n### 覆盖率评估\n\n| 覆盖率类型 | 计算方式 | 目标值 |\n|------------|----------|--------|\n| 需求覆盖率 | 已测需求点 / 总需求点 × 100% | ≥95% |\n| 功能覆盖率 | 已测功能点 / 总功能点 × 100% | ≥90% |\n| 用例覆盖率 | 已执行用例 / 总用例 × 100% | ≥100% |\n| 缺陷覆盖率 | 已修复缺陷 / 总缺陷 × 100% | ≥90% |\n\n## 质量保证标准\n\n### 用例质量指标\n\n| 指标 | 计算方式 | 目标值 |\n|------|----------|--------|\n| 用例有效性 | 有效用例数 / 总用例数 × 100% | ≥95% |\n| 用例执行率 | 已执行用例数 / 总用例数 × 100% | ≥100% |\n| 用例通过率 | 通过用例数 / 已执行用例数 × 100% | ≥98% |\n| 缺陷发现率 | 缺陷数 / 用例数 × 100% | 持续优化 |\n\n### 交付质量标准\n\n- 用例总数不低于需求点的3倍（包含异常场景）\n- P0+P1用例占比不低于60%\n- 每条用例平均预期结果3-5条\n- 无空洞描述，预期结果均可客观验证\n- 符合企业测试管理规范格式要求\n- 测试步骤留空，由用户根据实际系统补充\n\nFile v1.8.0:references/design-methods.md\n\n# 用例设计方法参考\n\n## 常用设计方法\n\n| 方法 | 适用场景 | 说明 | 必用场景 |\n|------|----------|------|----------|\n| 等价类划分法 | 输入域测试 | 将输入域划分为有效/无效等价类，减少冗余用例 | 所有输入字段 |\n| 边界值分析法 | 边界测试 | 针对边界情况设计专项测试，发现常见错误 | 所有有边界限制的字段 |\n| 场景法 | 业务流程测试 | 基于用户业务流程构建端到端测试场景 | 核心业务流程 |\n| 判定表驱动法 | 多条件组合 | 穷举所有条件组合可能性 | **必须使用**：多条件组合场景 |\n| 错误推测法 | 经验驱动 | 基于历史缺陷数据和开发经验预测潜在问题 | **必须使用**：异常场景覆盖 |\n| 风险驱动测试 | 风险优先 | 优先覆盖高风险区域和高频使用场景 | 高风险功能 |\n| 状态转换法 | 状态机测试 | 测试状态机的合法/非法转换 | 有状态变化的功能 |\n| 因果图法 | 复杂条件组合 | 分析输入条件与输出结果的因果关系 | **必须使用**：复杂条件依赖关系 |\n| 正交试验法 | 多因素多水平 | 用最少的试验覆盖最多的因素组合 | **必须使用**：多因素兼容性测试 |\n| 功能图法 | 功能组合测试 | 分析功能点的输入输出关系，生成功能测试用例 | **必须使用**：功能点组合覆盖 |\n\n### 方法应用要点\n\n**等价类划分法**：有效等价类（正常业务数据范围）、无效等价类（异常/边界/特殊数据）。划分依据：业务规则、数据类型、用户角色。示例：用户年龄输入（1-120有效，<1或>120无效）。\n\n**边界值分析法**：数值边界（最小值、最小值+1、最大值-1、最大值）、字符串边界（空、1字符、最大长度、最大长度+1）、日期边界（当天、前一天、后一天）。示例：密码长度8位（测试7位、8位、9位）。\n\n**场景法**：主成功场景（正常业务流程）、扩展场景（分支流程）、异常场景（错误处理流程）。示例：电商下单（浏览→加购→结算→支付→完成）。\n\n**判定表驱动法**：条件桩（所有输入条件）、动作桩（所有可能输出）、规则（条件组合与动作对应关系）。示例：登录（用户名正确/错误 × 密码正确/错误 → 不同结果）。\n\n**错误推测法**：基于经验（历史缺陷/常见错误模式）、基于直觉（测试人员经验判断）、基于领域知识（业务规则边界）。示例：输入框输入特殊字符/超长字符串/SQL注入语句。\n\n**因果图法**：原因（输入条件）、结果（输出结果）、关系（与/或/非逻辑）、约束（条件间依赖）。示例：优惠券使用条件（金额≥100且有券 → 可使用）。\n\n**正交试验法**：因素（测试变量）、水平（取值）、用例（最少组合覆盖最多因素）。示例：兼容性测试（3浏览器×3系统×3分辨率 → 正交表选9组）。\n\n**功能图法**：功能点（系统功能）、输入（条件）、输出（结果）、组合（调用关系）。示例：电商系统（登录→浏览→加购→结算→支付→功能组合测试）。\n\n## 复杂场景覆盖\n\n| 场景类型 | 测试重点 | 示例 |\n|----------|----------|------|\n| 页面跳转测试 | 跳转目标、参数传递、权限校验 | 列表跳详情页、菜单跳转、外部链接跳转 |\n| 路由参数测试 | 参数缺失、非法、越界处理 | URL参数传递、query参数、path参数 |\n| 跨页面联动 | 数据传递、状态同步、缓存一致性 | 订单页与用户页关联、购物车与结算页联动 |\n| 并发场景测试 | 多人同时操作、数据竞争 | 同时下单、库存并发扣减 |\n| 异常兜底测试 | 服务降级、熔断、重试机制 | 接口超时、服务不可用、网络异常 |\n\n### 页面跳转测试深度覆盖\n\n**测试要点**：跳转触发点、跳转目标页、跳转条件、异常跳转。检查：正常跳转目标正确、参数传递完整、权限校验拦截正确、404处理、空状态、浏览器回退、返回按钮、面包屑导航、外部跳转新标签页、循环跳转检测。\n\n### 路由参数测试深度覆盖\n\n**测试要点**：参数定义（query/path/hash）、格式（数据类型/长度限制）、传递方式（URL/session/cookie/localStorage）、验证（缺失/非法/越界/安全）。检查：参数存在性、类型、长度、格式、安全（SQL注入/XSS）、边界、组合、编码。\n\n### 跨页面联动测试深度覆盖\n\n**测试要点**：数据依赖（页面间数据关系）、状态同步（操作后更新）、缓存策略（刷新机制）、业务流程（完整闭环）。检查：数据传递正确、关联页面状态更新、缓存策略合理、消息通知跳转正确、业务闭环完整、多页面数据一致、操作反馈同步。\n\n## 常用测试方法速查\n\n**等价类划分示例**：年龄输入框（有效[1,120]，无效<1/>120/非数字）；状态下拉（有效[启用/禁用/冻结]，无效其他）。\n\n**边界值分析示例**：文件上传10MB（9MB/10MB/10.1MB）；文本框200字符（199/200/201字）；列表分页（第1页/最后1页/超出最大页码）。\n\n**判定表示例**：\n\n| 条件 | A(有优惠券) | B(满100元) | C(可用) | 结果 |\n|------|-------------|------------|---------|------|\n| 1 | Y | Y | Y | 可以使用 |\n| 2 | Y | Y | N | 不可用（已过期） |\n| 3 | Y | N | Y | 不可用（不满足门槛） |\n| 4 | N | Y/Y | Y/Y | 不适用 |\n\nFile v1.8.0:references/output-template-full.md\n\n# 测试用例 9 列标准格式（权威定义）\n\n> **本文件是全项目测试用例格式的唯一真源。** 其他技能（`qa-api-testing`、`qa-agent-testing`、\n> `qa-regression-testing` 等）产出用例时以本定义为准；有冲突以本文件为准。\n> 校验工具：`python scripts/validate_testcase_table.py <用例文件>`\n\n## 1. 九列定义\n\n| # | 列名 | 必填 | 填写要求 | 常见错误 |\n|---|------|------|---------|---------|\n| 1 | 用例编号 | ✅ | `TC_{模块缩写}_{功能缩写}_{三位序号}`，同批内不重号 | 用 `TC_USER_LOGIN_001_NORMAL` 四段式；用 `AGENT-001` |\n| 2 | 测试类型 | ✅ | 按所属技能维度填写：功能/安全/异常/性能/契约/兼容性；API 类补安全与契约 | 写\"正常用例\"\"异常用例\" |\n| 3 | 功能模块 | ✅ | 业务模块，必要时用 `模块/子功能` 两级（**子功能并入本列，不单设列**） | 只写\"系统\"\"后端\" |\n| 4 | 测试标题 | ✅ | 动词开头，点明验证点 | 写\"测试登录\" |\n| 5 | 用例级别 | ✅ | P0/P1/P2/P3，占比见 §3 | 全标 P0 |\n| 6 | 预置条件 | ✅ | 环境 + 数据 + 权限 + 状态，具体到可复现 | 只写\"环境正常\" |\n| 7 | 测试步骤 | ⚠️ 见 §4 | 协议类必填；实现相关类可留空 | 全留空（丢了可执行性） |\n| 8 | 预期结果 | ✅ | 可量化：状态码 / 返回结构 / 数据状态 / 副作用 | 写\"正确\"\"正常\" |\n| 9 | 风险等级 | ✅ | 高（资损/越权/数据错误/安全）/ 中（体验与稳定性）/ 低 | 留空或全标高 |\n\n> **为什么没有\"实际结果\"列**：那是**执行阶段**的记录字段，由 `qa-execution-observation` 的\n> 观察记录承载，不属于设计阶段的用例定义。设计模板塞执行字段会导致执行时被回填污染设计产物。\n>\n> **为什么没有\"子功能\"列**：并入「功能模块」用 `模块/子功能` 表示，信息不丢且不增加列宽。\n> 9 列是 `validate_testcase_table.py` 与 `测试用例.csv` 的硬约束，不可增减。\n\n## 2. 编号规则\n\n```\nTC_{模块缩写}_{功能缩写}_{三位序号}\n```\n\n- 模块缩写：业务模块，2-10 位大写字母或数字（`API` / `CART` / `LOGIN` / `ORDER`）\n- 功能缩写：功能点，2-10 位（`LOGIN` / `CREATE` / `REFUND`）\n- 三位序号：同批内从 `001` 连续递增\n\n示例：\n- `TC_API_LOGIN_001` — API 模块 / 登录功能 / 第 1 条\n- `TC_CART_ADD_007` — 购物车 / 添加商品 / 第 7 条\n- `TC_ORDER_REFUND_003` — 订单 / 退款 / 第 3 条\n\n> **不使用场景后缀**（如 `_NORMAL` / `_JUMP`）。场景类别信息应写进「测试类型」与「测试标题」，\n> 塞进 ID 会让 ID 失去稳定的\"用例\"语义，也破坏与 `SC-{模块缩写}-{序号}` 场景 ID 的对应关系。\n\n## 3. 级别与占比\n\n| 级别 | 含义 | 适用场景 |\n|------|------|---------|\n| P0 | 关键 | 核心业务流程、主流程验证、资损/安全相关 |\n| P1 | 重要 | 主要功能、重要分支流程 |\n| P2 | 一般 | 次要功能、异常场景 |\n| P3 | 可选 | 边缘场景、极端异常 |\n\n**占比约束**：P0 ≤ 20% / P1 ≤ 40% / P2 ≤ 30% / P3 ≤ 10%\n\n**小规模例外**：用例总数 < 10 条时上述配额在数学上无法成立（20% 不足 1 条）。\n此时加 `--no-quota` 跳过校验，并在报告中注明「小规模用例集，按每维至少 1 条覆盖」。\n**不要为凑比例编造用例或随意拉高/压低级别。**\n\n## 4. 「测试步骤」该留空还是该填\n\n这是历史上最容易产生分歧的一列，裁决如下：\n\n| 用例类型 | 步骤 | 理由 |\n|---------|------|------|\n| **协议 / 接口类**（API、gRPC、WebSocket、Webhook、数据库协议） | **必填**，含 method + path + 关键参数 | 步骤由协议契约决定，不依赖实现细节，AI 能准确写出来 |\n| **配置 / 规则 / 计算类**（配置项、金额计算、权限矩阵） | **必填** | 同上，规则本身是确定的 |\n| **UI / 业务流程类**（页面跳转、交互流程） | **可留空**，标注「由执行人按实际系统补充」 | 同一\"登录\"功能不同系统实现完全不同，AI 强写必然与实际不符，反而增加修正成本 |\n\n> 历史版本曾一刀切要求\"测试步骤留空\"，导致 API 类用例丢失了可执行性——\n> 而 API 的 method/path 恰恰是**规格的一部分**，不是实现细节。\n> 现按类型区分：协议类必填，实现相关类可留空。\n\n## 5. 两种产出形态\n\n### A. 表格形态（默认，批量评审/流转用）\n\n```markdown\n| 用例编号 | 测试类型 | 功能模块 | 测试标题 | 用例级别 | 预置条件 | 测试步骤 | 预期结果 | 风险等级 |\n|---------|---------|---------|---------|---------|---------|---------|---------|---------|\n| TC_API_LOGIN_001 | 功能测试 | 认证/登录 | 正确凭证登录成功 | P0 | 账号 u1 已就绪，接口文档已提供 | POST /api/login，body {\"user\":\"u1\",\"pass\":\"***\"} | 返回 200，响应含 token；调 /api/profile 有效；无堆栈泄露 | 高 |\n| TC_API_LOGIN_002 | 安全测试 | 认证/登录 | 伪造 Token 被拒 | P0 | 已知合法 token 与签名算法 | 改 1 个字符后请求 /api/profile | 返回 401；响应不含内部信息与用户数据 | 高 |\n```\n\n### B. 展开块（单条用例评审/执行时用）\n\n```markdown\n### TC_API_LOGIN_001 — 正确凭证登录成功\n\n- **测试类型**：功能测试\n- **功能模块**：认证/登录\n- **用例级别**：P0\n- **预置条件**：账号 u1 已就绪；接口文档已提供\n- **测试步骤**：POST /api/login，body {\"user\":\"u1\",\"pass\":\"***\"}\n- **预期结果**：返回 200，响应含 token；调 /api/profile 有效；无堆栈泄露\n- **风险等级**：高\n```\n\n## 6. 交付前必过校验\n\n```bash\npython scripts/validate_testcase_table.py <用例文件>\n```\n\n校验 9 列完整、编号唯一且合格式、级别/风险取值合法、P0-P3 占比、\n覆盖率措辞带口径、绝对化措辞禁令。**报错先修再交付。**\n\nFile v1.8.0:references/review-standards.md\n\n# 需求文档要求与用例评审标准\n\n## 需求文档要求\n\n### 页面跳转、路由参数、跨页面联动场景的需求要求\n\n#### 1. 页面跳转需求要求\n- **跳转触发点**：明确哪些操作会触发页面跳转（按钮、链接、菜单等）\n- **跳转目标页**：明确跳转到哪个页面，页面标识（URL、页面名称等）\n- **跳转条件**：在什么条件下允许跳转（权限、数据状态等）\n- **跳转参数**：需要传递哪些参数（ID、类型、来源等）\n- **异常处理**：跳转失败时的处理方式（错误提示、回退逻辑等）\n\n#### 2. 路由参数需求要求\n- **参数定义**：明确URL中包含哪些参数（query参数、path参数等）\n- **参数格式**：参数的数据类型、格式要求、长度限制\n- **参数传递**：参数如何在页面间传递（URL、session、cookie等）\n- **参数验证**：参数缺失、非法、越界时的处理逻辑\n- **参数安全**：参数的权限控制、防篡改机制\n\n#### 3. 跨页面联动需求要求\n- **数据依赖**：页面间的数据依赖关系（哪些数据需要同步）\n- **状态同步**：页面状态变更后，其他页面如何同步更新\n- **缓存策略**：页面数据的缓存机制和刷新策略\n- **业务流程**：跨页面的完整业务流程描述\n- **异常处理**：联动失败时的处理方式（数据回滚、状态恢复等）\n\n#### 4. 需求文档质量要求\n- **完整性**：所有跳转、参数、联动场景都有明确描述\n- **一致性**：不同部分的需求描述不矛盾\n- **可测试性**：需求描述足够具体，可以设计测试用例\n- **无歧义**：需求描述清晰，没有多种理解方式\n\n### 需求文档检查清单\n\n- [ ] 所有页面跳转的触发条件和目标页面\n- [ ] 路由参数的定义、格式和传递规则\n- [ ] 跨页面数据依赖和状态同步机制\n- [ ] 异常场景的处理逻辑\n- [ ] 权限控制要求\n- [ ] 业务流程的完整描述\n\n### 需求不足时的处理\n\n如果需求文档信息不足，应该：标记缺失信息、提出澄清问题、基于经验假设（注明假设条件）、在测试报告中说明需求不足带来的测试风险。\n\n## 用例评审标准\n\n### 完整性检查\n- [ ] 是否覆盖所有需求点和隐性场景？\n- [ ] 主流程、分支流程、异常场景是否覆盖？\n- [ ] 边界条件、特殊数据是否覆盖？\n- [ ] 权限控制、安全场景是否覆盖？\n\n### 独立性检查\n- [ ] 用例之间是否存在强依赖关系？\n- [ ] 用例执行顺序是否影响结果？\n- [ ] 用例数据是否相互独立？\n\n### 可执行性检查\n- [ ] 预置条件是否明确可准备？\n- [ ] 预期结果是否客观可测量？\n- [ ] 测试标题是否准确反映测试目的？\n- [ ] 用例级别是否合理？\n\n### 可维护性检查\n- [ ] 用例编号是否规范？\n- [ ] 命名是否清晰一致？\n- [ ] 变更是否可追溯？\n\n### 评审通过标准\n\n1. ✅ **覆盖率达标**: 核心功能P0用例覆盖率100%\n2. ✅ **逻辑自洽**: 无矛盾或冲突的用例描述\n3. ✅ **可执行性**: 预期结果均可客观验证\n4. ✅ **边界覆盖**: 输入边界、异常场景均有对应用例\n5. ✅ **优先级合理**: P0用例不超过总数30%\n6. ✅ **格式规范**: 符合标准模板要求\n\nFile v1.8.0:assets/case-table.md\n\n# 测试用例表模板（9 列标准格式）\n\n> 复制下面任一块板填写。格式的完整定义与两处历史变更说明见\n> [`../references/output-template-full.md`](../references/output-template-full.md)。\n\n## A. 表格形态（默认：批量评审、流转、汇总用）\n\n```markdown\n| 用例编号 | 测试类型 | 功能模块 | 测试标题 | 用例级别 | 预置条件 | 测试步骤 | 预期结果 | 风险等级 |\n|---------|---------|---------|---------|---------|---------|---------|---------|---------|\n| TC_API_LOGIN_001 | 功能测试 | 认证/登录 | 正确凭证登录成功 | P0 | 账号 u1 已就绪，接口文档已提供 | POST /api/login，body {\"user\":\"u1\",\"pass\":\"***\"} | 返回 200，响应含 token；调 /api/profile 有效；无堆栈泄露 | 高 |\n| TC_API_LOGIN_002 | 安全测试 | 认证/登录 | 伪造 Token 被拒 | P0 | 已知合法 token 与签名算法 | 改 1 个字符后请求 /api/profile | 返回 401；响应不含内部信息与用户数据 | 高 |\n| TC_API_LOGIN_003 | 异常测试 | 认证/登录 | 写操作超时重试不产生重复副作用 | P1 | 网关可注入延迟；写接口有幂等键 | 令首次请求延迟至超时，按服务端策略重放 2 次 | 重试成功且最终仅 1 次登录成功记录 | 中 |\n| TC_CART_ADD_001 | 功能测试 | 购物车/添加商品 | 正常加入购物车 | P0 | 用户已登录，商品库存 10 | （由执行人按实际系统补充） | 购物车数量 +1，金额按单价×数量计算，无库存超扣 | 高 |\n| TC_CART_ADD_002 | 边界测试 | 购物车/添加商品 | 加入数量超过库存 | P1 | 用户已登录，商品库存 2 | （由执行人按实际系统补充） | 提示库存不足，购物车数量不超过 2 | 中 |\n| TC_ORDER_REFUND_001 | 功能测试 | 订单/退款 | 已支付订单不可取消 | P0 | 订单处于\"已支付\" | （由执行人按实际系统补充） | 拒绝取消并返回明确错误码；订单状态不变；不产生退款流水 | 高 |\n```\n\n## B. 展开块（单条用例评审 / 执行用）\n\n```markdown\n### TC_API_ORDER_007 — 深分页越界不拖垮 DB\n\n- **测试类型**：功能测试\n- **功能模块**：订单/查询\n- **用例级别**：P1\n- **预置条件**：账号 A 名下 25 笔订单；接口支持 page/size 分页\n- **测试步骤**：\n 1. GET /api/orders?page=999&size=20\n 2. GET /api/orders?size=0\n 3. GET /api/orders?size=100000\n- **预期结果**：\n - page 越界：返回 200 + 空数组，或 400 带明确错误码，**不得 500**\n - size=0：返回明确错误（400），**不返回全量数据**\n - size 超上限：被服务端截断到上限或返回 400，**不得因未限制而拖垮 DB**\n- **风险等级**：中\n```\n\n## 逐列填写要求\n\n| 列 | 要求 | 常见错误 |\n|----|------|---------|\n| 用例编号 | `TC_{模块缩写}_{功能缩写}_{三位序号}`，同批不重号 | `TC_USER_LOGIN_001_NORMAL`（四段式已废止）、`AGENT-001` |\n| 测试类型 | 功能/安全/异常/性能/契约/兼容性；API 类补安全与契约 | \"正常用例\"\"异常用例\" |\n| 功能模块 | 必要时 `模块/子功能` 两级 | 只写\"系统\"\"后端\"；单设\"子功能\"列 |\n| 测试标题 | 动词开头，点明验证点 | \"测试登录\" |\n| 用例级别 | P0 核心 / P1 主要 / P2 次要 / P3 边缘 | 全标 P0 |\n| 预置条件 | 环境+数据+权限+状态，具体到可复现 | \"环境正常\" |\n| 测试步骤 | **协议/规则/计算类必填**；UI/业务流程类填「（由执行人按实际系统补充）」 | 一律留空（API 类丢了可执行性）；一律瞎写（UI 类与实际不符） |\n| 预期结果 | 可量化：状态码/返回结构/数据状态/副作用 | \"正确\"\"正常\" |\n| 风险等级 | 高（资损/越权/数据错误/安全）/ 中（体验与稳定性）/ 低 | 留空、全标高 |\n\n> **不要加「实际结果」列** —— 那是执行阶段记录，由 `qa-execution-observation` 承载。\n> **不要加「子功能」列** —— 并入「功能模块」用 `模块/子功能`。\n> 9 列是硬约束，`validate_testcase_table.py` 与 `测试用例.csv` 都按它校验。\n\n## 交付前必过\n\n```bash\npython scripts/validate_testcase_table.py <用例文件>\n# 用例数 <10 时配额数学上不成立，加 --no-quota 并在报告注明口径\n```\n\nFile v1.8.0:skill-card.md\n\n## Description:\n\nGuides QA teams in turning analyzed requirements, scenarios, and boundary conditions into prioritized, traceable test cases using a consistent nine-column format.\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 and developers use this skill to design and review requirement-linked test cases after analyzing requirements, scenarios, and boundaries. It organizes cases by test type, priority, risk, preconditions, steps, and measurable expected results.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Optional installation of the related skill collection may fetch unverified code.\n\nMitigation: Verify the source before running the installation command and prefer a pinned trusted version where available.\n\nRisk: Incomplete requirements or missing scenario and boundary analysis may yield generic or misleading test cases.\n\nMitigation: Complete upstream analysis first and flag uncovered modules and assumptions for review.\n\n## Reference(s):\n\n- [ClawHub release: qa-test-case-design](https://clawhub.ai/kokxi/skills/qa-test-case-design)\n- [Nine-column test case template](assets/case-table.md)\n- [Test case format and numbering](references/output-template-full.md)\n- [Test design methods](references/design-methods.md)\n- [Coverage and quality criteria](references/coverage-and-quality.md)\n- [Review standards](references/review-standards.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Guidance]\n\n**Output Format:** [Markdown nine-column test case table or expanded case entries]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Unique case IDs, P0–P3 priorities, risk levels, measurable expected outcomes, and coverage scope notes.]\n\n## Skill Version(s):\n\n1.8.0 (source: skill frontmatter and server 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: 7 files, 13779 bytes\n\nFiles: references/coverage-and-quality.md (3596b), references/design-methods.md (5605b), references/output-template-full.md (4982b), references/review-standards.md (3326b), skill-card.md (2121b), SKILL.md (9546b), _meta.json (138b)\n\nFile v1.7.7:SKILL.md\n\n---\nname: qa-test-case-design\nslug: qa-test-case-design\ndisplayName: Test Case Design\nversion: 1.7.7\ndescription: >-\n 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。适用于将前面的分析产出物整合为 P0-P3 分级、可追溯的标准格式测试用例。\n\nwhen_to_use: 用户说\"设计测试用例\"、\"用例评审\"、\"用例覆盖\"、\"测试用例设计\"、\"用例模板\"、\"用例规范\"、\"用例格式\"、需要测试用例结构指导、需要编写或规范测试用例时\nallowed-tools: Read Grep Glob\nrelated_skills:\n upstream:\n - qa-req-deconstruction # 输入：需求解构结果\n - qa-boundary-deep-dive # 输入：边界分析结果\n - qa-scenario-tree # 输入：场景树构建结果\n downstream:\n - qa-test-skills # 输出：测试用例设计结果\n - qa-expert-review # 输出：用例评审反馈\n - qa-regression-testing\nreferences:\n - references/coverage-and-quality.md\n - references/design-methods.md\n - references/review-standards.md\ninput_format:\n required:\n - name: 需求描述\n type: string\n description: 功能需求的详细说明\n optional:\n - name: 场景分析\n type: object\n description: 来自qa-scenario-tree的场景树\n - name: 边界条件\n type: object\n description: 来自qa-boundary-deep-dive的边界分析结果\n - name: 业务背景\n type: string\n description: 业务目标和用户角色\noutput_format:\n structure:\n - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）\n - 覆盖率：标注口径（基于现有需求/输入文档），禁止\"全覆盖/100%\"绝对化表述；缺失模块标注\"未覆盖+原因\"\n - test_case_id: \"TC_模块_功能_序列\"\n - test_type: \"功能/性能/安全/兼容性\"\n - priority: \"P0/P1/P2/P3\"\n - test_title: \"测试标题\"\n - preconditions: \"预置条件\"\n - test_steps: \"留空（用户补充）\"\n - expected_results: \"预期结果\"\n traceability:\n - 每个用例带唯一ID（TC_{模块缩写}_{功能缩写}_{序号}，如 TC_API_LOGIN_001）\n - 关联需求ID（TC_{需求模块缩写}_{功能缩写}_{序号}）\n - 关联场景ID（TC_{场景模块缩写}_{功能缩写}_{序号}）\ndepth_requirement_quantification:\n reference_value: \"根据需求复杂度调整用例设计深度：简单×2/中等×3/复杂×4\"\n minimum: \"用例总数不低于需求点的3倍\"\ncategories: ['Development','Testing']\nerror_recovery_guidance:\n on_failure: \"用例设计遗漏维度时回退到边界分析和场景树补充\"\n retry_behavior: \"补充上游后重新设计用例\"\n---\n# 高级测试用例设计专项\n\n## 核心原则\n\n测试用例设计的核心——明确\"测什么\"，而非\"怎么测\"。\n\n我们专注于：用例结构设计、场景覆盖策略、分类优先级、测试点识别组织。\n\n> **重要限制**：禁止读取代码——测试用例必须基于需求文档，不得读取代码实现。确保验证\"系统应该做什么\"，而非\"系统如何实现\"。\n>\n> 详细的设计方法、覆盖策略和评审标准参见 `references/` 目录：\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\n\n## 设计理念\n\n### 为什么测试步骤留空？\n\n```\n同一个\"登录\"功能，不同系统实现完全不同。\nAI不知道你们系统用的是哪种实现方式：\n- 强制生成步骤 → 步骤与实际不符 → 测试人员需要大量修正 → 增加工作量\n- 测试步骤留空 → 用户基于实际系统补充 → 只需补充细节 → 减少工作量\n```\n\n## 测试用例结构设计\n\n**重要：输出格式、用例分级、编号规则是固定的，必须严格遵守。**\n\n### 标准用例字段模板\n\n> 📖 完整的字段模板、用例编号规则、级别定义、输出格式和报告结构详见 [`references/output-template-full.md`](references/output-template-full.md)。\n>\n> 本节保留核心字段概览，详细模板按需加载以节省 context。\n\n## 使用方法\n\n### 触发场景\n\n当用户提供以下类型的请求时，此技能自动激活：\n\n1. **生成测试用例**：\"帮我设计用户登录功能的测试用例\"\n2. **完善用例**：\"这些测试用例不够全面，请补充异常场景\"\n3. **审查用例**：\"检查一下这些测试用例是否有遗漏\"\n4. **评审辅助**：\"我需要准备测试用例评审，生成一套完整的用例\"\n5. **覆盖优化**：\"这个功能还缺哪些测试场景\"\n6. **质量评估**：\"评估一下这些测试用例的质量\"\n\n### 输入要素\n\n为生成高质量的测试用例，尽量提供以下信息：\n\n1. **需求描述**：功能需求的详细说明\n2. **业务背景**：该功能在整体产品中的定位\n3. **约束条件**：技术限制、合规要求等\n4. **目标用户**：主要使用人群及其特征\n5. **关联系统**：涉及的其他模块或第三方服务\n6. **风险点**：已知的高风险区域\n7. **历史缺陷**：类似功能的历史问题\n\n### 输出内容\n\n1. **完整测试用例集**：涵盖所有识别出的测试点\n2. **测试优先级排序**：按P0-P3分级展示\n3. **覆盖率说明**：已覆盖的测试维度列表\n4. **缺失风险提示**：可能存在的测试盲区建议\n5. **测试建议**：针对测试执行的建议\n\n## 最佳实践\n\n### 用例设计原则\n\n✅ **DO - 推荐做法**\n- 每个用例只验证一个明确的目标\n- 使用清晰的数字序号标记预期结果\n- 预期结果使用\"应该/必须/会\"等确定性词汇\n- 包含正向和反向两种情况的验证\n- 标注敏感信息的脱敏处理方式\n- 为复杂场景添加截图或伪代码说明\n- 测试步骤留空，由用户根据实际系统补充\n\n❌ **DON'T - 避免做法**\n- 模糊的描述如\"检查是否可以正常工作\"\n- 一次性验证过多无关功能\n- 忽略前置条件和环境配置\n- 混合多个验证点在一个预期结果中\n- 使用主观判断代替客观测量\n- 忽略异常处理流程\n- 强制生成可能与实际不符的测试步骤\n\n### 用例评审要点\n\n1. **完整性检查**：是否覆盖所有需求点和隐性场景\n2. **独立性检查**：用例之间是否存在强依赖关系\n3. **可执行性检查**：预期结果是否清晰、客观可测量\n4. **可维护性检查**：命名规范、变更可追溯\n5. **优先级合理性**：P0用例是否真正关键\n6. **覆盖全面性**：功能、数据、权限、集成是否覆盖\n\n## 输出示例\n\n### 示例1：电商下单功能测试用例设计\n\n```markdown\n## 订单模块 - 商品下单 - P0\n\n### TC_ORDER_CREATE_001 正常下单流程\n\n**测试类型**: 功能测试\n**功能模块**: 订单管理\n**子功能**: 商品下单\n**用例级别**: P0\n**预置条件**:\n1. 用户已登录且账户余额充足\n2. 商品库存大于0\n3. 收货地址已配置\n\n**测试步骤**:\n（留空，由用户根据实际系统补充）\n\n**预期结果**:\n1. 进入订单确认页\n2. 订单金额计算准确（含运费优惠）\n3. 订单创建成功，返回订单号\n4. 库存扣减正确\n5. 收到订单confirmation通知\n\n**实际结果**: 待执行\n```\n\n### 示例2：用户注册功能异常场景\n\n```markdown\n## 用户模块 - 注册 - P1\n\n### TC_USER_REGISTER_002 邮箱格式错误\n\n**测试类型**: 功能测试\n**功能模块**: 用户管理\n**子功能**: 用户注册\n**用例级别**: P1\n**预置条件**: 访问注册页面\n\n**测试步骤**:\n（留空，由用户根据实际系统补充）\n\n**预期结果**:\n1. 邮箱字段显示红色错误提示\n2. 提示内容明确告知格式要求\n3. 无法继续提交表单\n4. 控制台无报错日志\n\n**实际结果**: 待执行\n```\n\n### 示例3：页面跳转测试用例设计\n\n```markdown\n## 商品模块 - 列表跳详情 - P0\n\n### TC_PRODUCT_LIST_001 正常跳转详情页\n\n**测试类型**: 功能测试\n**功能模块**: 商品管理\n**子功能**: 列表跳详情\n**用例级别**: P0\n**预置条件**:\n1. 用户已登录\n2. 商品列表页有数据\n\n**测试步骤**:\n（留空，由用户根据实际系统补充）\n\n**预期结果**:\n1. 成功跳转到商品详情页\n2. URL包含正确的商品ID（如/product/12345）\n3. 详情页展示的商品信息与列表一致\n4. 商品图片、价格、库存等关键信息正确\n5. 详情页功能按钮（购买、收藏等）可用\n\n**实际结果**: 待执行\n```\n\n## 检查清单\n\n测试用例设计完成后检查：\n- [ ] 是否覆盖了所有需求点和隐性场景？\n- [ ] 是否包含了正常、异常、边界三种场景？\n- [ ] 每条用例是否只验证一个明确目标？\n- [ ] 预期结果是否可客观验证？\n- [ ] 用例优先级（P0-P3）是否合理？\n\n## 参考资源\n\n- `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n- `references/coverage-and-quality.md` — 覆盖维度 + 覆盖评估 + 质量指标\n- `references/review-standards.md` — 需求文档要求 + 用例评审标准\n- ISTQB测试术语标准 / ISO/IEC/IEEE 29119 / Google Testing Blog\n\nFile v1.7.7:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-test-case-design\",\n \"version\": \"1.7.7\",\n \"publishedAt\": 1790520164151\n}\n\nFile v1.7.7:references/coverage-and-quality.md\n\n# 测试覆盖策略与质量标准\n\n## 覆盖维度\n\n```\n测试覆盖：\n├─ 功能覆盖\n│ ├─ 主流程覆盖：核心业务流程是否完整测试\n│ ├─ 分支流程覆盖：各种条件分支路径是否覆盖\n│ ├─ 异常场景覆盖：错误输入、异常操作是否测试\n│ ├─ 边界条件覆盖：输入范围边界、数量边界是否测试\n│ ├─ 退出流程覆盖：退出登录、注销、超时退出等场景\n│ └─ 状态转换覆盖：系统状态变化是否测试\n│\n├─ 数据覆盖\n│ ├─ 有效数据覆盖：正常数据是否测试\n│ ├─ 无效数据覆盖：异常数据是否测试\n│ ├─ 边界数据覆盖：边界值数据是否测试\n│ ├─ 特殊数据覆盖：特殊字符、超长数据是否测试\n│ ├─ 格式校验覆盖：邮箱、手机号、身份证等格式验证\n│ └─ 注入测试覆盖：SQL注入、XSS攻击等安全测试\n│\n├─ 字段级验证覆盖（每个表单字段必须测试）\n│ ├─ 长度边界：1位、最大长度、最大长度+1\n│ ├─ 格式校验：正则表达式验证（邮箱、手机号、身份证等）\n│ ├─ 注入测试：SQL注入、XSS攻击、命令注入\n│ ├─ 特殊字符：空格、特殊符号、Unicode字符\n│ ├─ 空值处理：必填字段为空、选填字段为空\n│ └─ 默认值：字段默认值是否正确\n│\n├─ 权限覆盖\n│ ├─ 角色权限覆盖：不同角色权限是否测试\n│ ├─ 越权访问覆盖：越权操作是否拦截\n│ ├─ 数据权限覆盖：数据隔离是否验证\n│ ├─ 功能权限覆盖：功能访问控制是否测试\n│ ├─ CSRF防护覆盖：跨站请求伪造防护是否测试\n│ └─ 路径遍历覆盖：目录遍历攻击防护是否测试\n│\n├─ 集成覆盖\n│ ├─ 模块集成覆盖：模块间协作是否测试\n│ ├─ 接口集成覆盖：接口调用是否测试\n│ ├─ 数据集成覆盖：数据流转是否测试\n│ └─ 异常集成覆盖：异常处理是否测试\n│\n└─ 非功能覆盖\n ├─ 性能覆盖：响应时间、吞吐量、并发性能是否测试\n ├─ 兼容性覆盖：浏览器、操作系统、设备兼容性是否测试\n ├─ 可用性覆盖：用户体验、易用性是否测试\n ├─ 安全性覆盖：数据加密、传输安全是否测试\n └─ 可靠性覆盖：稳定性、容错性是否测试\n```\n\n### 覆盖率评估\n\n| 覆盖率类型 | 计算方式 | 目标值 |\n|------------|----------|--------|\n| 需求覆盖率 | 已测需求点 / 总需求点 × 100% | ≥95% |\n| 功能覆盖率 | 已测功能点 / 总功能点 × 100% | ≥90% |\n| 用例覆盖率 | 已执行用例 / 总用例 × 100% | ≥100% |\n| 缺陷覆盖率 | 已修复缺陷 / 总缺陷 × 100% | ≥90% |\n\n## 质量保证标准\n\n### 用例质量指标\n\n| 指标 | 计算方式 | 目标值 |\n|------|----------|--------|\n| 用例有效性 | 有效用例数 / 总用例数 × 100% | ≥95% |\n| 用例执行率 | 已执行用例数 / 总用例数 × 100% | ≥100% |\n| 用例通过率 | 通过用例数 / 已执行用例数 × 100% | ≥98% |\n| 缺陷发现率 | 缺陷数 / 用例数 × 100% | 持续优化 |\n\n### 交付质量标准\n\n- 用例总数不低于需求点的3倍（包含异常场景）\n- P0+P1用例占比不低于60%\n- 每条用例平均预期结果3-5条\n- 无空洞描述，预期结果均可客观验证\n- 符合企业测试管理规范格式要求\n- 测试步骤留空，由用户根据实际系统补充\n\nFile v1.7.7:references/design-methods.md\n\n# 用例设计方法参考\n\n## 常用设计方法\n\n| 方法 | 适用场景 | 说明 | 必用场景 |\n|------|----------|------|----------|\n| 等价类划分法 | 输入域测试 | 将输入域划分为有效/无效等价类，减少冗余用例 | 所有输入字段 |\n| 边界值分析法 | 边界测试 | 针对边界情况设计专项测试，发现常见错误 | 所有有边界限制的字段 |\n| 场景法 | 业务流程测试 | 基于用户业务流程构建端到端测试场景 | 核心业务流程 |\n| 判定表驱动法 | 多条件组合 | 穷举所有条件组合可能性 | **必须使用**：多条件组合场景 |\n| 错误推测法 | 经验驱动 | 基于历史缺陷数据和开发经验预测潜在问题 | **必须使用**：异常场景覆盖 |\n| 风险驱动测试 | 风险优先 | 优先覆盖高风险区域和高频使用场景 | 高风险功能 |\n| 状态转换法 | 状态机测试 | 测试状态机的合法/非法转换 | 有状态变化的功能 |\n| 因果图法 | 复杂条件组合 | 分析输入条件与输出结果的因果关系 | **必须使用**：复杂条件依赖关系 |\n| 正交试验法 | 多因素多水平 | 用最少的试验覆盖最多的因素组合 | **必须使用**：多因素兼容性测试 |\n| 功能图法 | 功能组合测试 | 分析功能点的输入输出关系，生成功能测试用例 | **必须使用**：功能点组合覆盖 |\n\n### 方法应用要点\n\n**等价类划分法**：有效等价类（正常业务数据范围）、无效等价类（异常/边界/特殊数据）。划分依据：业务规则、数据类型、用户角色。示例：用户年龄输入（1-120有效，<1或>120无效）。\n\n**边界值分析法**：数值边界（最小值、最小值+1、最大值-1、最大值）、字符串边界（空、1字符、最大长度、最大长度+1）、日期边界（当天、前一天、后一天）。示例：密码长度8位（测试7位、8位、9位）。\n\n**场景法**：主成功场景（正常业务流程）、扩展场景（分支流程）、异常场景（错误处理流程）。示例：电商下单（浏览→加购→结算→支付→完成）。\n\n**判定表驱动法**：条件桩（所有输入条件）、动作桩（所有可能输出）、规则（条件组合与动作对应关系）。示例：登录（用户名正确/错误 × 密码正确/错误 → 不同结果）。\n\n**错误推测法**：基于经验（历史缺陷/常见错误模式）、基于直觉（测试人员经验判断）、基于领域知识（业务规则边界）。示例：输入框输入特殊字符/超长字符串/SQL注入语句。\n\n**因果图法**：原因（输入条件）、结果（输出结果）、关系（与/或/非逻辑）、约束（条件间依赖）。示例：优惠券使用条件（金额≥100且有券 → 可使用）。\n\n**正交试验法**：因素（测试变量）、水平（取值）、用例（最少组合覆盖最多因素）。示例：兼容性测试（3浏览器×3系统×3分辨率 → 正交表选9组）。\n\n**功能图法**：功能点（系统功能）、输入（条件）、输出（结果）、组合（调用关系）。示例：电商系统（登录→浏览→加购→结算→支付→功能组合测试）。\n\n## 复杂场景覆盖\n\n| 场景类型 | 测试重点 | 示例 |\n|----------|----------|------|\n| 页面跳转测试 | 跳转目标、参数传递、权限校验 | 列表跳详情页、菜单跳转、外部链接跳转 |\n| 路由参数测试 | 参数缺失、非法、越界处理 | URL参数传递、query参数、path参数 |\n| 跨页面联动 | 数据传递、状态同步、缓存一致性 | 订单页与用户页关联、购物车与结算页联动 |\n| 并发场景测试 | 多人同时操作、数据竞争 | 同时下单、库存并发扣减 |\n| 异常兜底测试 | 服务降级、熔断、重试机制 | 接口超时、服务不可用、网络异常 |\n\n### 页面跳转测试深度覆盖\n\n**测试要点**：跳转触发点、跳转目标页、跳转条件、异常跳转。检查：正常跳转目标正确、参数传递完整、权限校验拦截正确、404处理、空状态、浏览器回退、返回按钮、面包屑导航、外部跳转新标签页、循环跳转检测。\n\n### 路由参数测试深度覆盖\n\n**测试要点**：参数定义（query/path/hash）、格式（数据类型/长度限制）、传递方式（URL/session/cookie/localStorage）、验证（缺失/非法/越界/安全）。检查：参数存在性、类型、长度、格式、安全（SQL注入/XSS）、边界、组合、编码。\n\n### 跨页面联动测试深度覆盖\n\n**测试要点**：数据依赖（页面间数据关系）、状态同步（操作后更新）、缓存策略（刷新机制）、业务流程（完整闭环）。检查：数据传递正确、关联页面状态更新、缓存策略合理、消息通知跳转正确、业务闭环完整、多页面数据一致、操作反馈同步。\n\n## 常用测试方法速查\n\n**等价类划分示例**：年龄输入框（有效[1,120]，无效<1/>120/非数字）；状态下拉（有效[启用/禁用/冻结]，无效其他）。\n\n**边界值分析示例**：文件上传10MB（9MB/10MB/10.1MB）；文本框200字符（199/200/201字）；列表分页（第1页/最后1页/超出最大页码）。\n\n**判定表示例**：\n\n| 条件 | A(有优惠券) | B(满100元) | C(可用) | 结果 |\n|------|-------------|------------|---------|------|\n| 1 | Y | Y | Y | 可以使用 |\n| 2 | Y | Y | N | 不可用（已过期） |\n| 3 | Y | N | Y | 不可用（不满足门槛） |\n| 4 | N | Y/Y | Y/Y | 不适用 |\n\nFile v1.7.7:references/output-template-full.md\n\n# 测试用例字段模板与输出格式（完整版）\n\n> 本文件由 qa-test-case-design SKILL.md 拆分而来，按需加载。\n\n### 标准用例字段模板\n\n| 字段 | 说明 | 是否必填 |\n|------|------|----------|\n| 用例编号 | 唯一标识，便于追踪和管理 | ✅ 必填 |\n| 测试类型 | 功能/性能/安全/兼容性等 | ✅ 必填 |\n| 功能模块 | 所属的业务模块或系统组件 | ✅ 必填 |\n| 子功能 | 具体的功能点或操作场景 | ✅ 必填 |\n| 测试标题 | 简明扼要地描述测试目的 | ✅ 必填 |\n| 用例级别 | P0(关键)、P1(重要)、P2(一般)、P3(可选) | ✅ 必填 |\n| 预置条件 | 执行测试前必须满足的状态或数据准备 | ✅ 必填 |\n| 测试步骤 | 详细的操作步骤（留空，由用户补充） | ⚠️ 留空 |\n| 预期结果 | 每个步骤对应的预期产出或状态变化 | ✅ 必填 |\n| 实际结果 | 测试执行后的真实结果记录（留空） | ⚠️ 留空 |\n\n### 用例编号规则\n\n`TC_{模块缩写}_{功能序列号}_{场景后缀}`\n\n示例：\n- `TC_USER_LOGIN_001_NORMAL` - 用户模块 - 登录功能 - 第001条 - 正常场景\n- `TC_ORDER_DETAIL_002_JUMP` - 订单模块 - 详情页 - 第002条 - 跳转场景\n- `TC_PRODUCT_LINK_003_CROSS` - 商品模块 - 关联页面 - 第003条 - 跨页面联动\n\n### 用例级别定义\n\n| 级别 | 说明 | 适用场景 |\n|------|------|----------|\n| P0 | 关键用例 | 核心业务流程、阻碍系统正常使用的问题、主流程验证 |\n| P1 | 重要用例 | 主要功能、影响用户体验的问题、重要分支流程 |\n| P2 | 一般用例 | 次要功能、不影响主体流程的问题、异常场景 |\n| P3 | 可选用例 | 边缘场景、美化优化相关、极端异常情况 |\n\n> 详细的设计方法、覆盖策略和评审标准参见 `references/`：\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\n\n## 输出模板\n\n**重要：以下输出格式是固定的，必须严格遵守。**\n\n### 测试用例设计输出格式\n\n```markdown\n## 测试用例设计报告\n\n### 基本信息\n- 功能模块：[模块名称]\n- 设计日期：[日期]\n- 设计人员：[姓名]\n- 用例总数：[数量]\n\n### 用例统计\n| 级别 | 数量 | 占比 |\n|------|------|------|\n| P0 | [数量] | [百分比] |\n| P1 | [数量] | [百分比] |\n| P2 | [数量] | [百分比] |\n| P3 | [数量] | [百分比] |\n\n### 测试用例列表\n\n#### P0 关键用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_001 | [测试标题] | 功能测试 | 等价类划分法 | REQ-XXX-001 | [预期结果] |\n\n#### P1 重要用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_002 | [测试标题] | 功能测试 | 边界值分析法 | REQ-XXX-002 | [预期结果] |\n\n#### P2 一般用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_003 | [测试标题] | 异常测试 | 错误推测法 | REQ-XXX-003 | [预期结果] |\n\n#### P3 可选用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_004 | [测试标题] | 边界测试 | 边界值分析法 | REQ-XXX-004 | [预期结果] |\n\n### 覆盖率分析\n- 需求覆盖率：[百分比]\n- 功能覆盖率：[百分比]\n- 风险覆盖率：[百分比]\n\n### 测试建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\n### 单条用例输出格式\n\n```markdown\n## 测试用例\n\n### 基本信息\n- 用例编号：TC_XXX_001\n- 测试类型：功能测试\n- 功能模块：用户管理\n- 子功能：登录\n- 测试标题：验证正确的用户名和密码可以成功登录\n- 用例级别：P0\n- 需求追溯ID：REQ-AUTH-001\n- 测试方法：等价类划分法、边界值分析法\n\n### 预置条件\n1. 用户已注册\n2. 网络正常\n3. 服务正常运行\n4. 前置依赖：无\n\n### 测试步骤\n（留空，由用户根据实际系统补充）\n\n### 预期结果\n1. 跳转至首页\n2. 显示用户信息\n3. 登录状态保持正常\n\n### 实际结果\n（测试执行后填写）\n\n### 字段级验证（如适用）\n- 用户名字段：\n - 长度边界：1位、20位、21位\n - 格式校验：无特殊格式要求\n - 注入测试：SQL注入、XSS攻击\n - 特殊字符：空格、@、#等\n- 密码字段：\n - 长度边界：1位、8位、9位\n - 格式校验：至少8位，包含字母、数字、特殊字符\n - 注入测试：SQL注入、XSS攻击\n - 特殊字符：空格、@、#等\n```\n\nFile v1.7.7:references/review-standards.md\n\n# 需求文档要求与用例评审标准\n\n## 需求文档要求\n\n### 页面跳转、路由参数、跨页面联动场景的需求要求\n\n#### 1. 页面跳转需求要求\n- **跳转触发点**：明确哪些操作会触发页面跳转（按钮、链接、菜单等）\n- **跳转目标页**：明确跳转到哪个页面，页面标识（URL、页面名称等）\n- **跳转条件**：在什么条件下允许跳转（权限、数据状态等）\n- **跳转参数**：需要传递哪些参数（ID、类型、来源等）\n- **异常处理**：跳转失败时的处理方式（错误提示、回退逻辑等）\n\n#### 2. 路由参数需求要求\n- **参数定义**：明确URL中包含哪些参数（query参数、path参数等）\n- **参数格式**：参数的数据类型、格式要求、长度限制\n- **参数传递**：参数如何在页面间传递（URL、session、cookie等）\n- **参数验证**：参数缺失、非法、越界时的处理逻辑\n- **参数安全**：参数的权限控制、防篡改机制\n\n#### 3. 跨页面联动需求要求\n- **数据依赖**：页面间的数据依赖关系（哪些数据需要同步）\n- **状态同步**：页面状态变更后，其他页面如何同步更新\n- **缓存策略**：页面数据的缓存机制和刷新策略\n- **业务流程**：跨页面的完整业务流程描述\n- **异常处理**：联动失败时的处理方式（数据回滚、状态恢复等）\n\n#### 4. 需求文档质量要求\n- **完整性**：所有跳转、参数、联动场景都有明确描述\n- **一致性**：不同部分的需求描述不矛盾\n- **可测试性**：需求描述足够具体，可以设计测试用例\n- **无歧义**：需求描述清晰，没有多种理解方式\n\n### 需求文档检查清单\n\n- [ ] 所有页面跳转的触发条件和目标页面\n- [ ] 路由参数的定义、格式和传递规则\n- [ ] 跨页面数据依赖和状态同步机制\n- [ ] 异常场景的处理逻辑\n- [ ] 权限控制要求\n- [ ] 业务流程的完整描述\n\n### 需求不足时的处理\n\n如果需求文档信息不足，应该：标记缺失信息、提出澄清问题、基于经验假设（注明假设条件）、在测试报告中说明需求不足带来的测试风险。\n\n## 用例评审标准\n\n### 完整性检查\n- [ ] 是否覆盖所有需求点和隐性场景？\n- [ ] 主流程、分支流程、异常场景是否覆盖？\n- [ ] 边界条件、特殊数据是否覆盖？\n- [ ] 权限控制、安全场景是否覆盖？\n\n### 独立性检查\n- [ ] 用例之间是否存在强依赖关系？\n- [ ] 用例执行顺序是否影响结果？\n- [ ] 用例数据是否相互独立？\n\n### 可执行性检查\n- [ ] 预置条件是否明确可准备？\n- [ ] 预期结果是否客观可测量？\n- [ ] 测试标题是否准确反映测试目的？\n- [ ] 用例级别是否合理？\n\n### 可维护性检查\n- [ ] 用例编号是否规范？\n- [ ] 命名是否清晰一致？\n- [ ] 变更是否可追溯？\n\n### 评审通过标准\n\n1. ✅ **覆盖率达标**: 核心功能P0用例覆盖率100%\n2. ✅ **逻辑自洽**: 无矛盾或冲突的用例描述\n3. ✅ **可执行性**: 预期结果均可客观验证\n4. ✅ **边界覆盖**: 输入边界、异常场景均有对应用例\n5. ✅ **优先级合理**: P0用例不超过总数30%\n6. ✅ **格式规范**: 符合标准模板要求\n\nFile v1.7.7:skill-card.md\n\n## Description:\n\nTurns completed requirements, scenario, and boundary analyses into prioritized, traceable Chinese-language QA test cases.\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 and testers use this skill to turn completed requirement and scenario analysis into reviewable test-case sets with P0–P3 priorities, expected results, and coverage notes. Testers supply execution steps for their actual system.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Chinese-only output and fixed templates may not fit an English-language or differently formatted QA workflow.\n\nMitigation: Confirm language and test-management format requirements before adoption; adapt or review the cases before importing them.\n\nRisk: Broad activation for testing-related requests may produce cases before the underlying requirements and scenarios are ready.\n\nMitigation: Complete requirements, scenario, and boundary analysis first; review coverage and fill in system-specific execution steps.\n\n## Reference(s):\n\n- [ClawHub skill release](https://clawhub.ai/kokxi/skills/qa-test-case-design)\n- [Test-case design methods](references/design-methods.md)\n- [Coverage and quality standards](references/coverage-and-quality.md)\n- [Full output template](references/output-template-full.md)\n- [Review standards](references/review-standards.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Guidance]\n\n**Output Format:** [Chinese-language Markdown tables and reports]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Traceable case IDs, P0–P3 priorities, coverage notes, and test steps left for testers to complete.]\n\n## Skill Version(s):\n\n1.7.7 (source: frontmatter and server-resolved 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: 7 files, 14069 bytes\n\nFiles: references/coverage-and-quality.md (3596b), references/design-methods.md (5605b), references/output-template-full.md (4982b), references/review-standards.md (3326b), skill-card.md (2332b), SKILL.md (10103b), _meta.json (138b)\n\nFile v1.7.6:SKILL.md\n\n---\r\nname: qa-test-case-design\r\nslug: qa-test-case-design\r\ndisplayName: 测试用例设计\r\nversion: 1.7.5\r\ndescription: >-\r\n 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。适用于将前面的分析产出物整合为 P0-P3 分级、可追溯的标准格式测试用例。\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-req-deconstruction # 输入：需求解构结果\r\n - qa-boundary-deep-dive # 输入：边界分析结果\r\n - qa-scenario-tree # 输入：场景树构建结果\r\n downstream:\r\n - qa-test-skills # 输出：测试用例设计结果\r\n - qa-expert-review # 输出：用例评审反馈\r\n - qa-regression-testing\r\nreferences:\r\n - references/coverage-and-quality.md\r\n - references/design-methods.md\r\n - references/review-standards.md\r\ninput_format:\r\n required:\r\n - name: 需求描述\r\n type: string\r\n description: 功能需求的详细说明\r\n optional:\r\n - name: 场景分析\r\n type: object\r\n description: 来自qa-scenario-tree的场景树\r\n - name: 边界条件\r\n type: object\r\n description: 来自qa-boundary-deep-dive的边界分析结果\r\n - name: 业务背景\r\n type: string\r\n description: 业务目标和用户角色\r\noutput_format:\r\n structure:\r\n - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）\r\n - 覆盖率：标注口径（基于现有需求/输入文档），禁止\"全覆盖/100%\"绝对化表述；缺失模块标注\"未覆盖+原因\"\r\n - test_case_id: \"TC_模块_功能_序列\"\r\n - test_type: \"功能/性能/安全/兼容性\"\r\n - priority: \"P0/P1/P2/P3\"\r\n - test_title: \"测试标题\"\r\n - preconditions: \"预置条件\"\r\n - test_steps: \"留空（用户补充）\"\r\n - expected_results: \"预期结果\"\r\n traceability:\r\n - 每个用例带唯一ID（TC_{模块缩写}_{功能缩写}_{序号}，如 TC_API_LOGIN_001）\r\n - 关联需求ID（TC_{需求模块缩写}_{功能缩写}_{序号}）\r\n - 关联场景ID（TC_{场景模块缩写}_{功能缩写}_{序号}）\r\ndepth_requirement_quantification:\r\n reference_value: \"根据需求复杂度调整用例设计深度：简单×2/中等×3/复杂×4\"\r\n minimum: \"用例总数不低于需求点的3倍\"\r\ncategories: ['Development','Testing']\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# 高级测试用例设计专项\r\n\r\n## 核心原则\r\n\r\n测试用例设计的核心——明确\"测什么\"，而非\"怎么测\"。\r\n\r\n我们专注于：用例结构设计、场景覆盖策略、分类优先级、测试点识别组织。\r\n\r\n> **重要限制**：禁止读取代码——测试用例必须基于需求文档，不得读取代码实现。确保验证\"系统应该做什么\"，而非\"系统如何实现\"。\r\n>\r\n> 详细的设计方法、覆盖策略和评审标准参见 `references/` 目录：\r\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\r\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\r\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\r\n\r\n## 设计理念\r\n\r\n### 为什么测试步骤留空？\r\n\r\n```\r\n同一个\"登录\"功能，不同系统实现完全不同。\r\nAI不知道你们系统用的是哪种实现方式：\r\n- 强制生成步骤 → 步骤与实际不符 → 测试人员需要大量修正 → 增加工作量\r\n- 测试步骤留空 → 用户基于实际系统补充 → 只需补充细节 → 减少工作量\r\n```\r\n\r\n## 测试用例结构设计\r\n\r\n**重要：输出格式、用例分级、编号规则是固定的，必须严格遵守。**\r\n\r\n### 标准用例字段模板\r\n\r\n> 📖 完整的字段模板、用例编号规则、级别定义、输出格式和报告结构详见 [`references/output-template-full.md`](references/output-template-full.md)。\r\n>\r\n> 本节保留核心字段概览，详细模板按需加载以节省 context。\r\n\r\n## 使用方法\r\n\r\n### 触发场景\r\n\r\n当用户提供以下类型的请求时，此技能自动激活：\r\n\r\n1. **生成测试用例**：\"帮我设计用户登录功能的测试用例\"\r\n2. **完善用例**：\"这些测试用例不够全面，请补充异常场景\"\r\n3. **审查用例**：\"检查一下这些测试用例是否有遗漏\"\r\n4. **评审辅助**：\"我需要准备测试用例评审，生成一套完整的用例\"\r\n5. **覆盖优化**：\"这个功能还缺哪些测试场景\"\r\n6. **质量评估**：\"评估一下这些测试用例的质量\"\r\n\r\n### 输入要素\r\n\r\n为生成高质量的测试用例，尽量提供以下信息：\r\n\r\n1. **需求描述**：功能需求的详细说明\r\n2. **业务背景**：该功能在整体产品中的定位\r\n3. **约束条件**：技术限制、合规要求等\r\n4. **目标用户**：主要使用人群及其特征\r\n5. **关联系统**：涉及的其他模块或第三方服务\r\n6. **风险点**：已知的高风险区域\r\n7. **历史缺陷**：类似功能的历史问题\r\n\r\n### 输出内容\r\n\r\n1. **完整测试用例集**：涵盖所有识别出的测试点\r\n2. **测试优先级排序**：按P0-P3分级展示\r\n3. **覆盖率说明**：已覆盖的测试维度列表\r\n4. **缺失风险提示**：可能存在的测试盲区建议\r\n5. **测试建议**：针对测试执行的建议\r\n\r\n## 最佳实践\r\n\r\n### 用例设计原则\r\n\r\n✅ **DO - 推荐做法**\r\n- 每个用例只验证一个明确的目标\r\n- 使用清晰的数字序号标记预期结果\r\n- 预期结果使用\"应该/必须/会\"等确定性词汇\r\n- 包含正向和反向两种情况的验证\r\n- 标注敏感信息的脱敏处理方式\r\n- 为复杂场景添加截图或伪代码说明\r\n- 测试步骤留空，由用户根据实际系统补充\r\n\r\n❌ **DON'T - 避免做法**\r\n- 模糊的描述如\"检查是否可以正常工作\"\r\n- 一次性验证过多无关功能\r\n- 忽略前置条件和环境配置\r\n- 混合多个验证点在一个预期结果中\r\n- 使用主观判断代替客观测量\r\n- 忽略异常处理流程\r\n- 强制生成可能与实际不符的测试步骤\r\n\r\n### 用例评审要点\r\n\r\n1. **完整性检查**：是否覆盖所有需求点和隐性场景\r\n2. **独立性检查**：用例之间是否存在强依赖关系\r\n3. **可执行性检查**：预期结果是否清晰、客观可测量\r\n4. **可维护性检查**：命名规范、变更可追溯\r\n5. **优先级合理性**：P0用例是否真正关键\r\n6. **覆盖全面性**：功能、数据、权限、集成是否覆盖\r\n\r\n## 输出示例\r\n\r\n### 示例1：电商下单功能测试用例设计\r\n\r\n```markdown\r\n## 订单模块 - 商品下单 - P0\r\n\r\n### TC_ORDER_CREATE_001 正常下单流程\r\n\r\n**测试类型**: 功能测试\r\n**功能模块**: 订单管理\r\n**子功能**: 商品下单\r\n**用例级别**: P0\r\n**预置条件**:\r\n1. 用户已登录且账户余额充足\r\n2. 商品库存大于0\r\n3. 收货地址已配置\r\n\r\n**测试步骤**:\r\n（留空，由用户根据实际系统补充）\r\n\r\n**预期结果**:\r\n1. 进入订单确认页\r\n2. 订单金额计算准确（含运费优惠）\r\n3. 订单创建成功，返回订单号\r\n4. 库存扣减正确\r\n5. 收到订单confirmation通知\r\n\r\n**实际结果**: 待执行\r\n```\r\n\r\n### 示例2：用户注册功能异常场景\r\n\r\n```markdown\r\n## 用户模块 - 注册 - P1\r\n\r\n### TC_USER_REGISTER_002 邮箱格式错误\r\n\r\n**测试类型**: 功能测试\r\n**功能模块**: 用户管理\r\n**子功能**: 用户注册\r\n**用例级别**: P1\r\n**预置条件**: 访问注册页面\r\n\r\n**测试步骤**:\r\n（留空，由用户根据实际系统补充）\r\n\r\n**预期结果**:\r\n1. 邮箱字段显示红色错误提示\r\n2. 提示内容明确告知格式要求\r\n3. 无法继续提交表单\r\n4. 控制台无报错日志\r\n\r\n**实际结果**: 待执行\r\n```\r\n\r\n### 示例3：页面跳转测试用例设计\r\n\r\n```markdown\r\n## 商品模块 - 列表跳详情 - P0\r\n\r\n### TC_PRODUCT_LIST_001 正常跳转详情页\r\n\r\n**测试类型**: 功能测试\r\n**功能模块**: 商品管理\r\n**子功能**: 列表跳详情\r\n**用例级别**: P0\r\n**预置条件**:\r\n1. 用户已登录\r\n2. 商品列表页有数据\r\n\r\n**测试步骤**:\r\n（留空，由用户根据实际系统补充）\r\n\r\n**预期结果**:\r\n1. 成功跳转到商品详情页\r\n2. URL包含正确的商品ID（如/product/12345）\r\n3. 详情页展示的商品信息与列表一致\r\n4. 商品图片、价格、库存等关键信息正确\r\n5. 详情页功能按钮（购买、收藏等）可用\r\n\r\n**实际结果**: 待执行\r\n```\r\n\r\n## 检查清单\r\n\r\n测试用例设计完成后检查：\r\n- [ ] 是否覆盖了所有需求点和隐性场景？\r\n- [ ] 是否包含了正常、异常、边界三种场景？\r\n- [ ] 每条用例是否只验证一个明确目标？\r\n- [ ] 预期结果是否可客观验证？\r\n- [ ] 用例优先级（P0-P3）是否合理？\r\n\r\n## 参考资源\r\n\r\n- `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\r\n- `references/coverage-and-quality.md` — 覆盖维度 + 覆盖评估 + 质量指标\r\n- `references/review-standards.md` — 需求文档要求 + 用例评审标准\r\n- ISTQB测试术语标准 / ISO/IEC/IEEE 29119 / Google Testing Blog\n\nFile v1.7.6:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-test-case-design\",\n \"version\": \"1.7.6\",\n \"publishedAt\": 1788266880412\n}\n\nFile v1.7.6:references/coverage-and-quality.md\n\n# 测试覆盖策略与质量标准\n\n## 覆盖维度\n\n```\n测试覆盖：\n├─ 功能覆盖\n│ ├─ 主流程覆盖：核心业务流程是否完整测试\n│ ├─ 分支流程覆盖：各种条件分支路径是否覆盖\n│ ├─ 异常场景覆盖：错误输入、异常操作是否测试\n│ ├─ 边界条件覆盖：输入范围边界、数量边界是否测试\n│ ├─ 退出流程覆盖：退出登录、注销、超时退出等场景\n│ └─ 状态转换覆盖：系统状态变化是否测试\n│\n├─ 数据覆盖\n│ ├─ 有效数据覆盖：正常数据是否测试\n│ ├─ 无效数据覆盖：异常数据是否测试\n│ ├─ 边界数据覆盖：边界值数据是否测试\n│ ├─ 特殊数据覆盖：特殊字符、超长数据是否测试\n│ ├─ 格式校验覆盖：邮箱、手机号、身份证等格式验证\n│ └─ 注入测试覆盖：SQL注入、XSS攻击等安全测试\n│\n├─ 字段级验证覆盖（每个表单字段必须测试）\n│ ├─ 长度边界：1位、最大长度、最大长度+1\n│ ├─ 格式校验：正则表达式验证（邮箱、手机号、身份证等）\n│ ├─ 注入测试：SQL注入、XSS攻击、命令注入\n│ ├─ 特殊字符：空格、特殊符号、Unicode字符\n│ ├─ 空值处理：必填字段为空、选填字段为空\n│ └─ 默认值：字段默认值是否正确\n│\n├─ 权限覆盖\n│ ├─ 角色权限覆盖：不同角色权限是否测试\n│ ├─ 越权访问覆盖：越权操作是否拦截\n│ ├─ 数据权限覆盖：数据隔离是否验证\n│ ├─ 功能权限覆盖：功能访问控制是否测试\n│ ├─ CSRF防护覆盖：跨站请求伪造防护是否测试\n│ └─ 路径遍历覆盖：目录遍历攻击防护是否测试\n│\n├─ 集成覆盖\n│ ├─ 模块集成覆盖：模块间协作是否测试\n│ ├─ 接口集成覆盖：接口调用是否测试\n│ ├─ 数据集成覆盖：数据流转是否测试\n│ └─ 异常集成覆盖：异常处理是否测试\n│\n└─ 非功能覆盖\n ├─ 性能覆盖：响应时间、吞吐量、并发性能是否测试\n ├─ 兼容性覆盖：浏览器、操作系统、设备兼容性是否测试\n ├─ 可用性覆盖：用户体验、易用性是否测试\n ├─ 安全性覆盖：数据加密、传输安全是否测试\n └─ 可靠性覆盖：稳定性、容错性是否测试\n```\n\n### 覆盖率评估\n\n| 覆盖率类型 | 计算方式 | 目标值 |\n|------------|----------|--------|\n| 需求覆盖率 | 已测需求点 / 总需求点 × 100% | ≥95% |\n| 功能覆盖率 | 已测功能点 / 总功能点 × 100% | ≥90% |\n| 用例覆盖率 | 已执行用例 / 总用例 × 100% | ≥100% |\n| 缺陷覆盖率 | 已修复缺陷 / 总缺陷 × 100% | ≥90% |\n\n## 质量保证标准\n\n### 用例质量指标\n\n| 指标 | 计算方式 | 目标值 |\n|------|----------|--------|\n| 用例有效性 | 有效用例数 / 总用例数 × 100% | ≥95% |\n| 用例执行率 | 已执行用例数 / 总用例数 × 100% | ≥100% |\n| 用例通过率 | 通过用例数 / 已执行用例数 × 100% | ≥98% |\n| 缺陷发现率 | 缺陷数 / 用例数 × 100% | 持续优化 |\n\n### 交付质量标准\n\n- 用例总数不低于需求点的3倍（包含异常场景）\n- P0+P1用例占比不低于60%\n- 每条用例平均预期结果3-5条\n- 无空洞描述，预期结果均可客观验证\n- 符合企业测试管理规范格式要求\n- 测试步骤留空，由用户根据实际系统补充\n\nFile v1.7.6:references/design-methods.md\n\n# 用例设计方法参考\n\n## 常用设计方法\n\n| 方法 | 适用场景 | 说明 | 必用场景 |\n|------|----------|------|----------|\n| 等价类划分法 | 输入域测试 | 将输入域划分为有效/无效等价类，减少冗余用例 | 所有输入字段 |\n| 边界值分析法 | 边界测试 | 针对边界情况设计专项测试，发现常见错误 | 所有有边界限制的字段 |\n| 场景法 | 业务流程测试 | 基于用户业务流程构建端到端测试场景 | 核心业务流程 |\n| 判定表驱动法 | 多条件组合 | 穷举所有条件组合可能性 | **必须使用**：多条件组合场景 |\n| 错误推测法 | 经验驱动 | 基于历史缺陷数据和开发经验预测潜在问题 | **必须使用**：异常场景覆盖 |\n| 风险驱动测试 | 风险优先 | 优先覆盖高风险区域和高频使用场景 | 高风险功能 |\n| 状态转换法 | 状态机测试 | 测试状态机的合法/非法转换 | 有状态变化的功能 |\n| 因果图法 | 复杂条件组合 | 分析输入条件与输出结果的因果关系 | **必须使用**：复杂条件依赖关系 |\n| 正交试验法 | 多因素多水平 | 用最少的试验覆盖最多的因素组合 | **必须使用**：多因素兼容性测试 |\n| 功能图法 | 功能组合测试 | 分析功能点的输入输出关系，生成功能测试用例 | **必须使用**：功能点组合覆盖 |\n\n### 方法应用要点\n\n**等价类划分法**：有效等价类（正常业务数据范围）、无效等价类（异常/边界/特殊数据）。划分依据：业务规则、数据类型、用户角色。示例：用户年龄输入（1-120有效，<1或>120无效）。\n\n**边界值分析法**：数值边界（最小值、最小值+1、最大值-1、最大值）、字符串边界（空、1字符、最大长度、最大长度+1）、日期边界（当天、前一天、后一天）。示例：密码长度8位（测试7位、8位、9位）。\n\n**场景法**：主成功场景（正常业务流程）、扩展场景（分支流程）、异常场景（错误处理流程）。示例：电商下单（浏览→加购→结算→支付→完成）。\n\n**判定表驱动法**：条件桩（所有输入条件）、动作桩（所有可能输出）、规则（条件组合与动作对应关系）。示例：登录（用户名正确/错误 × 密码正确/错误 → 不同结果）。\n\n**错误推测法**：基于经验（历史缺陷/常见错误模式）、基于直觉（测试人员经验判断）、基于领域知识（业务规则边界）。示例：输入框输入特殊字符/超长字符串/SQL注入语句。\n\n**因果图法**：原因（输入条件）、结果（输出结果）、关系（与/或/非逻辑）、约束（条件间依赖）。示例：优惠券使用条件（金额≥100且有券 → 可使用）。\n\n**正交试验法**：因素（测试变量）、水平（取值）、用例（最少组合覆盖最多因素）。示例：兼容性测试（3浏览器×3系统×3分辨率 → 正交表选9组）。\n\n**功能图法**：功能点（系统功能）、输入（条件）、输出（结果）、组合（调用关系）。示例：电商系统（登录→浏览→加购→结算→支付→功能组合测试）。\n\n## 复杂场景覆盖\n\n| 场景类型 | 测试重点 | 示例 |\n|----------|----------|------|\n| 页面跳转测试 | 跳转目标、参数传递、权限校验 | 列表跳详情页、菜单跳转、外部链接跳转 |\n| 路由参数测试 | 参数缺失、非法、越界处理 | URL参数传递、query参数、path参数 |\n| 跨页面联动 | 数据传递、状态同步、缓存一致性 | 订单页与用户页关联、购物车与结算页联动 |\n| 并发场景测试 | 多人同时操作、数据竞争 | 同时下单、库存并发扣减 |\n| 异常兜底测试 | 服务降级、熔断、重试机制 | 接口超时、服务不可用、网络异常 |\n\n### 页面跳转测试深度覆盖\n\n**测试要点**：跳转触发点、跳转目标页、跳转条件、异常跳转。检查：正常跳转目标正确、参数传递完整、权限校验拦截正确、404处理、空状态、浏览器回退、返回按钮、面包屑导航、外部跳转新标签页、循环跳转检测。\n\n### 路由参数测试深度覆盖\n\n**测试要点**：参数定义（query/path/hash）、格式（数据类型/长度限制）、传递方式（URL/session/cookie/localStorage）、验证（缺失/非法/越界/安全）。检查：参数存在性、类型、长度、格式、安全（SQL注入/XSS）、边界、组合、编码。\n\n### 跨页面联动测试深度覆盖\n\n**测试要点**：数据依赖（页面间数据关系）、状态同步（操作后更新）、缓存策略（刷新机制）、业务流程（完整闭环）。检查：数据传递正确、关联页面状态更新、缓存策略合理、消息通知跳转正确、业务闭环完整、多页面数据一致、操作反馈同步。\n\n## 常用测试方法速查\n\n**等价类划分示例**：年龄输入框（有效[1,120]，无效<1/>120/非数字）；状态下拉（有效[启用/禁用/冻结]，无效其他）。\n\n**边界值分析示例**：文件上传10MB（9MB/10MB/10.1MB）；文本框200字符（199/200/201字）；列表分页（第1页/最后1页/超出最大页码）。\n\n**判定表示例**：\n\n| 条件 | A(有优惠券) | B(满100元) | C(可用) | 结果 |\n|------|-------------|------------|---------|------|\n| 1 | Y | Y | Y | 可以使用 |\n| 2 | Y | Y | N | 不可用（已过期） |\n| 3 | Y | N | Y | 不可用（不满足门槛） |\n| 4 | N | Y/Y | Y/Y | 不适用 |\n\nFile v1.7.6:references/output-template-full.md\n\n# 测试用例字段模板与输出格式（完整版）\n\n> 本文件由 qa-test-case-design SKILL.md 拆分而来，按需加载。\n\n### 标准用例字段模板\n\n| 字段 | 说明 | 是否必填 |\n|------|------|----------|\n| 用例编号 | 唯一标识，便于追踪和管理 | ✅ 必填 |\n| 测试类型 | 功能/性能/安全/兼容性等 | ✅ 必填 |\n| 功能模块 | 所属的业务模块或系统组件 | ✅ 必填 |\n| 子功能 | 具体的功能点或操作场景 | ✅ 必填 |\n| 测试标题 | 简明扼要地描述测试目的 | ✅ 必填 |\n| 用例级别 | P0(关键)、P1(重要)、P2(一般)、P3(可选) | ✅ 必填 |\n| 预置条件 | 执行测试前必须满足的状态或数据准备 | ✅ 必填 |\n| 测试步骤 | 详细的操作步骤（留空，由用户补充） | ⚠️ 留空 |\n| 预期结果 | 每个步骤对应的预期产出或状态变化 | ✅ 必填 |\n| 实际结果 | 测试执行后的真实结果记录（留空） | ⚠️ 留空 |\n\n### 用例编号规则\n\n`TC_{模块缩写}_{功能序列号}_{场景后缀}`\n\n示例：\n- `TC_USER_LOGIN_001_NORMAL` - 用户模块 - 登录功能 - 第001条 - 正常场景\n- `TC_ORDER_DETAIL_002_JUMP` - 订单模块 - 详情页 - 第002条 - 跳转场景\n- `TC_PRODUCT_LINK_003_CROSS` - 商品模块 - 关联页面 - 第003条 - 跨页面联动\n\n### 用例级别定义\n\n| 级别 | 说明 | 适用场景 |\n|------|------|----------|\n| P0 | 关键用例 | 核心业务流程、阻碍系统正常使用的问题、主流程验证 |\n| P1 | 重要用例 | 主要功能、影响用户体验的问题、重要分支流程 |\n| P2 | 一般用例 | 次要功能、不影响主体流程的问题、异常场景 |\n| P3 | 可选用例 | 边缘场景、美化优化相关、极端异常情况 |\n\n> 详细的设计方法、覆盖策略和评审标准参见 `references/`：\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\n\n## 输出模板\n\n**重要：以下输出格式是固定的，必须严格遵守。**\n\n### 测试用例设计输出格式\n\n```markdown\n## 测试用例设计报告\n\n### 基本信息\n- 功能模块：[模块名称]\n- 设计日期：[日期]\n- 设计人员：[姓名]\n- 用例总数：[数量]\n\n### 用例统计\n| 级别 | 数量 | 占比 |\n|------|------|------|\n| P0 | [数量] | [百分比] |\n| P1 | [数量] | [百分比] |\n| P2 | [数量] | [百分比] |\n| P3 | [数量] | [百分比] |\n\n### 测试用例列表\n\n#### P0 关键用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_001 | [测试标题] | 功能测试 | 等价类划分法 | REQ-XXX-001 | [预期结果] |\n\n#### P1 重要用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_002 | [测试标题] | 功能测试 | 边界值分析法 | REQ-XXX-002 | [预期结果] |\n\n#### P2 一般用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_003 | [测试标题] | 异常测试 | 错误推测法 | REQ-XXX-003 | [预期结果] |\n\n#### P3 可选用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_004 | [测试标题] | 边界测试 | 边界值分析法 | REQ-XXX-004 | [预期结果] |\n\n### 覆盖率分析\n- 需求覆盖率：[百分比]\n- 功能覆盖率：[百分比]\n- 风险覆盖率：[百分比]\n\n### 测试建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\n### 单条用例输出格式\n\n```markdown\n## 测试用例\n\n### 基本信息\n- 用例编号：TC_XXX_001\n- 测试类型：功能测试\n- 功能模块：用户管理\n- 子功能：登录\n- 测试标题：验证正确的用户名和密码可以成功登录\n- 用例级别：P0\n- 需求追溯ID：REQ-AUTH-001\n- 测试方法：等价类划分法、边界值分析法\n\n### 预置条件\n1. 用户已注册\n2. 网络正常\n3. 服务正常运行\n4. 前置依赖：无\n\n### 测试步骤\n（留空，由用户根据实际系统补充）\n\n### 预期结果\n1. 跳转至首页\n2. 显示用户信息\n3. 登录状态保持正常\n\n### 实际结果\n（测试执行后填写）\n\n### 字段级验证（如适用）\n- 用户名字段：\n - 长度边界：1位、20位、21位\n - 格式校验：无特殊格式要求\n - 注入测试：SQL注入、XSS攻击\n - 特殊字符：空格、@、#等\n- 密码字段：\n - 长度边界：1位、8位、9位\n - 格式校验：至少8位，包含字母、数字、特殊字符\n - 注入测试：SQL注入、XSS攻击\n - 特殊字符：空格、@、#等\n```\n\nFile v1.7.6:references/review-standards.md\n\n# 需求文档要求与用例评审标准\n\n## 需求文档要求\n\n### 页面跳转、路由参数、跨页面联动场景的需求要求\n\n#### 1. 页面跳转需求要求\n- **跳转触发点**：明确哪些操作会触发页面跳转（按钮、链接、菜单等）\n- **跳转目标页**：明确跳转到哪个页面，页面标识（URL、页面名称等）\n- **跳转条件**：在什么条件下允许跳转（权限、数据状态等）\n- **跳转参数**：需要传递哪些参数（ID、类型、来源等）\n- **异常处理**：跳转失败时的处理方式（错误提示、回退逻辑等）\n\n#### 2. 路由参数需求要求\n- **参数定义**：明确URL中包含哪些参数（query参数、path参数等）\n- **参数格式**：参数的数据类型、格式要求、长度限制\n- **参数传递**：参数如何在页面间传递（URL、session、cookie等）\n- **参数验证**：参数缺失、非法、越界时的处理逻辑\n- **参数安全**：参数的权限控制、防篡改机制\n\n#### 3. 跨页面联动需求要求\n- **数据依赖**：页面间的数据依赖关系（哪些数据需要同步）\n- **状态同步**：页面状态变更后，其他页面如何同步更新\n- **缓存策略**：页面数据的缓存机制和刷新策略\n- **业务流程**：跨页面的完整业务流程描述\n- **异常处理**：联动失败时的处理方式（数据回滚、状态恢复等）\n\n#### 4. 需求文档质量要求\n- **完整性**：所有跳转、参数、联动场景都有明确描述\n- **一致性**：不同部分的需求描述不矛盾\n- **可测试性**：需求描述足够具体，可以设计测试用例\n- **无歧义**：需求描述清晰，没有多种理解方式\n\n### 需求文档检查清单\n\n- [ ] 所有页面跳转的触发条件和目标页面\n- [ ] 路由参数的定义、格式和传递规则\n- [ ] 跨页面数据依赖和状态同步机制\n- [ ] 异常场景的处理逻辑\n- [ ] 权限控制要求\n- [ ] 业务流程的完整描述\n\n### 需求不足时的处理\n\n如果需求文档信息不足，应该：标记缺失信息、提出澄清问题、基于经验假设（注明假设条件）、在测试报告中说明需求不足带来的测试风险。\n\n## 用例评审标准\n\n### 完整性检查\n- [ ] 是否覆盖所有需求点和隐性场景？\n- [ ] 主流程、分支流程、异常场景是否覆盖？\n- [ ] 边界条件、特殊数据是否覆盖？\n- [ ] 权限控制、安全场景是否覆盖？\n\n### 独立性检查\n- [ ] 用例之间是否存在强依赖关系？\n- [ ] 用例执行顺序是否影响结果？\n- [ ] 用例数据是否相互独立？\n\n### 可执行性检查\n- [ ] 预置条件是否明确可准备？\n- [ ] 预期结果是否客观可测量？\n- [ ] 测试标题是否准确反映测试目的？\n- [ ] 用例级别是否合理？\n\n### 可维护性检查\n- [ ] 用例编号是否规范？\n- [ ] 命名是否清晰一致？\n- [ ] 变更是否可追溯？\n\n### 评审通过标准\n\n1. ✅ **覆盖率达标**: 核心功能P0用例覆盖率100%\n2. ✅ **逻辑自洽**: 无矛盾或冲突的用例描述\n3. ✅ **可执行性**: 预期结果均可客观验证\n4. ✅ **边界覆盖**: 输入边界、异常场景均有对应用例\n5. ✅ **优先级合理**: P0用例不超过总数30%\n6. ✅ **格式规范**: 符合标准模板要求\n\nFile v1.7.6:skill-card.md\n\n## Description:\n\nGuides agents to convert completed QA analysis into structured, prioritized, traceable test cases with coverage notes and review 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 engineers and product teams use this skill after requirements, scenario, and boundary analysis to produce P0-P3 test case sets, coverage summaries, risk notes, and review-ready Markdown tables.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill recommends an unpinned npx install for a broader external skill collection.\n\nMitigation: Use the reviewed single skill by default; only run the collection install after trusting the publisher and pinning or auditing the exact version in a least-privilege environment.\n\nRisk: Generated test cases may be incomplete or misleading when requirement, scenario, or boundary analysis inputs are missing.\n\nMitigation: Provide requirements and upstream analysis artifacts, mark assumptions and uncovered modules, and have QA reviewers confirm priority, coverage, and expected results before execution.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-test-case-design)\n- [Testing coverage strategy and quality standards](references/coverage-and-quality.md)\n- [Test case design methods reference](references/design-methods.md)\n- [Full output template](references/output-template-full.md)\n- [Requirements and review standards](references/review-standards.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Guidance]\n\n**Output Format:** [Markdown test case tables, coverage summaries, risk notes, and review guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Test steps are intentionally left for users to complete against the actual system; coverage claims should be scoped to the provided requirements.]\n\n## Skill Version(s):\n\n1.7.6 (source: ClawHub release metadata; artifact frontmatter lists 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: 7 files, 13956 bytes\n\nFiles: references/coverage-and-quality.md (3596b), references/design-methods.md (5605b), references/output-template-full.md (4982b), references/review-standards.md (3326b), skill-card.md (2489b), SKILL.md (9546b), _meta.json (138b)\n\nFile v1.7.5:SKILL.md\n\n---\nname: qa-test-case-design\nslug: qa-test-case-design\ndisplayName: Test Case Design\nversion: 1.7.5\ndescription: >-\n 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。适用于将前面的分析产出物整合为 P0-P3 分级、可追溯的标准格式测试用例。\n\nwhen_to_use: 用户说\"设计测试用例\"、\"用例评审\"、\"用例覆盖\"、\"测试用例设计\"、\"用例模板\"、\"用例规范\"、\"用例格式\"、需要测试用例结构指导、需要编写或规范测试用例时\nallowed-tools: Read Grep Glob\nrelated_skills:\n upstream:\n - qa-req-deconstruction # 输入：需求解构结果\n - qa-boundary-deep-dive # 输入：边界分析结果\n - qa-scenario-tree # 输入：场景树构建结果\n downstream:\n - qa-test-skills # 输出：测试用例设计结果\n - qa-expert-review # 输出：用例评审反馈\n - qa-regression-testing\nreferences:\n - references/coverage-and-quality.md\n - references/design-methods.md\n - references/review-standards.md\ninput_format:\n required:\n - name: 需求描述\n type: string\n description: 功能需求的详细说明\n optional:\n - name: 场景分析\n type: object\n description: 来自qa-scenario-tree的场景树\n - name: 边界条件\n type: object\n description: 来自qa-boundary-deep-dive的边界分析结果\n - name: 业务背景\n type: string\n description: 业务目标和用户角色\noutput_format:\n structure:\n - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）\n - 覆盖率：标注口径（基于现有需求/输入文档），禁止\"全覆盖/100%\"绝对化表述；缺失模块标注\"未覆盖+原因\"\n - test_case_id: \"TC_模块_功能_序列\"\n - test_type: \"功能/性能/安全/兼容性\"\n - priority: \"P0/P1/P2/P3\"\n - test_title: \"测试标题\"\n - preconditions: \"预置条件\"\n - test_steps: \"留空（用户补充）\"\n - expected_results: \"预期结果\"\n traceability:\n - 每个用例带唯一ID（TC_{模块缩写}_{功能缩写}_{序号}，如 TC_API_LOGIN_001）\n - 关联需求ID（TC_{需求模块缩写}_{功能缩写}_{序号}）\n - 关联场景ID（TC_{场景模块缩写}_{功能缩写}_{序号}）\ndepth_requirement_quantification:\n reference_value: \"根据需求复杂度调整用例设计深度：简单×2/中等×3/复杂×4\"\n minimum: \"用例总数不低于需求点的3倍\"\ncategories: ['Development','Testing']\nerror_recovery_guidance:\n on_failure: \"用例设计遗漏维度时回退到边界分析和场景树补充\"\n retry_behavior: \"补充上游后重新设计用例\"\n---\n# 高级测试用例设计专项\n\n## 核心原则\n\n测试用例设计的核心——明确\"测什么\"，而非\"怎么测\"。\n\n我们专注于：用例结构设计、场景覆盖策略、分类优先级、测试点识别组织。\n\n> **重要限制**：禁止读取代码——测试用例必须基于需求文档，不得读取代码实现。确保验证\"系统应该做什么\"，而非\"系统如何实现\"。\n>\n> 详细的设计方法、覆盖策略和评审标准参见 `references/` 目录：\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\n\n## 设计理念\n\n### 为什么测试步骤留空？\n\n```\n同一个\"登录\"功能，不同系统实现完全不同。\nAI不知道你们系统用的是哪种实现方式：\n- 强制生成步骤 → 步骤与实际不符 → 测试人员需要大量修正 → 增加工作量\n- 测试步骤留空 → 用户基于实际系统补充 → 只需补充细节 → 减少工作量\n```\n\n## 测试用例结构设计\n\n**重要：输出格式、用例分级、编号规则是固定的，必须严格遵守。**\n\n### 标准用例字段模板\n\n> 📖 完整的字段模板、用例编号规则、级别定义、输出格式和报告结构详见 [`references/output-template-full.md`](references/output-template-full.md)。\n>\n> 本节保留核心字段概览，详细模板按需加载以节省 context。\n\n## 使用方法\n\n### 触发场景\n\n当用户提供以下类型的请求时，此技能自动激活：\n\n1. **生成测试用例**：\"帮我设计用户登录功能的测试用例\"\n2. **完善用例**：\"这些测试用例不够全面，请补充异常场景\"\n3. **审查用例**：\"检查一下这些测试用例是否有遗漏\"\n4. **评审辅助**：\"我需要准备测试用例评审，生成一套完整的用例\"\n5. **覆盖优化**：\"这个功能还缺哪些测试场景\"\n6. **质量评估**：\"评估一下这些测试用例的质量\"\n\n### 输入要素\n\n为生成高质量的测试用例，尽量提供以下信息：\n\n1. **需求描述**：功能需求的详细说明\n2. **业务背景**：该功能在整体产品中的定位\n3. **约束条件**：技术限制、合规要求等\n4. **目标用户**：主要使用人群及其特征\n5. **关联系统**：涉及的其他模块或第三方服务\n6. **风险点**：已知的高风险区域\n7. **历史缺陷**：类似功能的历史问题\n\n### 输出内容\n\n1. **完整测试用例集**：涵盖所有识别出的测试点\n2. **测试优先级排序**：按P0-P3分级展示\n3. **覆盖率说明**：已覆盖的测试维度列表\n4. **缺失风险提示**：可能存在的测试盲区建议\n5. **测试建议**：针对测试执行的建议\n\n## 最佳实践\n\n### 用例设计原则\n\n✅ **DO - 推荐做法**\n- 每个用例只验证一个明确的目标\n- 使用清晰的数字序号标记预期结果\n- 预期结果使用\"应该/必须/会\"等确定性词汇\n- 包含正向和反向两种情况的验证\n- 标注敏感信息的脱敏处理方式\n- 为复杂场景添加截图或伪代码说明\n- 测试步骤留空，由用户根据实际系统补充\n\n❌ **DON'T - 避免做法**\n- 模糊的描述如\"检查是否可以正常工作\"\n- 一次性验证过多无关功能\n- 忽略前置条件和环境配置\n- 混合多个验证点在一个预期结果中\n- 使用主观判断代替客观测量\n- 忽略异常处理流程\n- 强制生成可能与实际不符的测试步骤\n\n### 用例评审要点\n\n1. **完整性检查**：是否覆盖所有需求点和隐性场景\n2. **独立性检查**：用例之间是否存在强依赖关系\n3. **可执行性检查**：预期结果是否清晰、客观可测量\n4. **可维护性检查**：命名规范、变更可追溯\n5. **优先级合理性**：P0用例是否真正关键\n6. **覆盖全面性**：功能、数据、权限、集成是否覆盖\n\n## 输出示例\n\n### 示例1：电商下单功能测试用例设计\n\n```markdown\n## 订单模块 - 商品下单 - P0\n\n### TC_ORDER_CREATE_001 正常下单流程\n\n**测试类型**: 功能测试\n**功能模块**: 订单管理\n**子功能**: 商品下单\n**用例级别**: P0\n**预置条件**:\n1. 用户已登录且账户余额充足\n2. 商品库存大于0\n3. 收货地址已配置\n\n**测试步骤**:\n（留空，由用户根据实际系统补充）\n\n**预期结果**:\n1. 进入订单确认页\n2. 订单金额计算准确（含运费优惠）\n3. 订单创建成功，返回订单号\n4. 库存扣减正确\n5. 收到订单confirmation通知\n\n**实际结果**: 待执行\n```\n\n### 示例2：用户注册功能异常场景\n\n```markdown\n## 用户模块 - 注册 - P1\n\n### TC_USER_REGISTER_002 邮箱格式错误\n\n**测试类型**: 功能测试\n**功能模块**: 用户管理\n**子功能**: 用户注册\n**用例级别**: P1\n**预置条件**: 访问注册页面\n\n**测试步骤**:\n（留空，由用户根据实际系统补充）\n\n**预期结果**:\n1. 邮箱字段显示红色错误提示\n2. 提示内容明确告知格式要求\n3. 无法继续提交表单\n4. 控制台无报错日志\n\n**实际结果**: 待执行\n```\n\n### 示例3：页面跳转测试用例设计\n\n```markdown\n## 商品模块 - 列表跳详情 - P0\n\n### TC_PRODUCT_LIST_001 正常跳转详情页\n\n**测试类型**: 功能测试\n**功能模块**: 商品管理\n**子功能**: 列表跳详情\n**用例级别**: P0\n**预置条件**:\n1. 用户已登录\n2. 商品列表页有数据\n\n**测试步骤**:\n（留空，由用户根据实际系统补充）\n\n**预期结果**:\n1. 成功跳转到商品详情页\n2. URL包含正确的商品ID（如/product/12345）\n3. 详情页展示的商品信息与列表一致\n4. 商品图片、价格、库存等关键信息正确\n5. 详情页功能按钮（购买、收藏等）可用\n\n**实际结果**: 待执行\n```\n\n## 检查清单\n\n测试用例设计完成后检查：\n- [ ] 是否覆盖了所有需求点和隐性场景？\n- [ ] 是否包含了正常、异常、边界三种场景？\n- [ ] 每条用例是否只验证一个明确目标？\n- [ ] 预期结果是否可客观验证？\n- [ ] 用例优先级（P0-P3）是否合理？\n\n## 参考资源\n\n- `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n- `references/coverage-and-quality.md` — 覆盖维度 + 覆盖评估 + 质量指标\n- `references/review-standards.md` — 需求文档要求 + 用例评审标准\n- ISTQB测试术语标准 / ISO/IEC/IEEE 29119 / Google Testing Blog\n\nFile v1.7.5:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-test-case-design\",\n \"version\": \"1.7.5\",\n \"publishedAt\": 1788103242259\n}\n\nFile v1.7.5:references/coverage-and-quality.md\n\n# 测试覆盖策略与质量标准\n\n## 覆盖维度\n\n```\n测试覆盖：\n├─ 功能覆盖\n│ ├─ 主流程覆盖：核心业务流程是否完整测试\n│ ├─ 分支流程覆盖：各种条件分支路径是否覆盖\n│ ├─ 异常场景覆盖：错误输入、异常操作是否测试\n│ ├─ 边界条件覆盖：输入范围边界、数量边界是否测试\n│ ├─ 退出流程覆盖：退出登录、注销、超时退出等场景\n│ └─ 状态转换覆盖：系统状态变化是否测试\n│\n├─ 数据覆盖\n│ ├─ 有效数据覆盖：正常数据是否测试\n│ ├─ 无效数据覆盖：异常数据是否测试\n│ ├─ 边界数据覆盖：边界值数据是否测试\n│ ├─ 特殊数据覆盖：特殊字符、超长数据是否测试\n│ ├─ 格式校验覆盖：邮箱、手机号、身份证等格式验证\n│ └─ 注入测试覆盖：SQL注入、XSS攻击等安全测试\n│\n├─ 字段级验证覆盖（每个表单字段必须测试）\n│ ├─ 长度边界：1位、最大长度、最大长度+1\n│ ├─ 格式校验：正则表达式验证（邮箱、手机号、身份证等）\n│ ├─ 注入测试：SQL注入、XSS攻击、命令注入\n│ ├─ 特殊字符：空格、特殊符号、Unicode字符\n│ ├─ 空值处理：必填字段为空、选填字段为空\n│ └─ 默认值：字段默认值是否正确\n│\n├─ 权限覆盖\n│ ├─ 角色权限覆盖：不同角色权限是否测试\n│ ├─ 越权访问覆盖：越权操作是否拦截\n│ ├─ 数据权限覆盖：数据隔离是否验证\n│ ├─ 功能权限覆盖：功能访问控制是否测试\n│ ├─ CSRF防护覆盖：跨站请求伪造防护是否测试\n│ └─ 路径遍历覆盖：目录遍历攻击防护是否测试\n│\n├─ 集成覆盖\n│ ├─ 模块集成覆盖：模块间协作是否测试\n│ ├─ 接口集成覆盖：接口调用是否测试\n│ ├─ 数据集成覆盖：数据流转是否测试\n│ └─ 异常集成覆盖：异常处理是否测试\n│\n└─ 非功能覆盖\n ├─ 性能覆盖：响应时间、吞吐量、并发性能是否测试\n ├─ 兼容性覆盖：浏览器、操作系统、设备兼容性是否测试\n ├─ 可用性覆盖：用户体验、易用性是否测试\n ├─ 安全性覆盖：数据加密、传输安全是否测试\n └─ 可靠性覆盖：稳定性、容错性是否测试\n```\n\n### 覆盖率评估\n\n| 覆盖率类型 | 计算方式 | 目标值 |\n|------------|----------|--------|\n| 需求覆盖率 | 已测需求点 / 总需求点 × 100% | ≥95% |\n| 功能覆盖率 | 已测功能点 / 总功能点 × 100% | ≥90% |\n| 用例覆盖率 | 已执行用例 / 总用例 × 100% | ≥100% |\n| 缺陷覆盖率 | 已修复缺陷 / 总缺陷 × 100% | ≥90% |\n\n## 质量保证标准\n\n### 用例质量指标\n\n| 指标 | 计算方式 | 目标值 |\n|------|----------|--------|\n| 用例有效性 | 有效用例数 / 总用例数 × 100% | ≥95% |\n| 用例执行率 | 已执行用例数 / 总用例数 × 100% | ≥100% |\n| 用例通过率 | 通过用例数 / 已执行用例数 × 100% | ≥98% |\n| 缺陷发现率 | 缺陷数 / 用例数 × 100% | 持续优化 |\n\n### 交付质量标准\n\n- 用例总数不低于需求点的3倍（包含异常场景）\n- P0+P1用例占比不低于60%\n- 每条用例平均预期结果3-5条\n- 无空洞描述，预期结果均可客观验证\n- 符合企业测试管理规范格式要求\n- 测试步骤留空，由用户根据实际系统补充\n\nFile v1.7.5:references/design-methods.md\n\n# 用例设计方法参考\n\n## 常用设计方法\n\n| 方法 | 适用场景 | 说明 | 必用场景 |\n|------|----------|------|----------|\n| 等价类划分法 | 输入域测试 | 将输入域划分为有效/无效等价类，减少冗余用例 | 所有输入字段 |\n| 边界值分析法 | 边界测试 | 针对边界情况设计专项测试，发现常见错误 | 所有有边界限制的字段 |\n| 场景法 | 业务流程测试 | 基于用户业务流程构建端到端测试场景 | 核心业务流程 |\n| 判定表驱动法 | 多条件组合 | 穷举所有条件组合可能性 | **必须使用**：多条件组合场景 |\n| 错误推测法 | 经验驱动 | 基于历史缺陷数据和开发经验预测潜在问题 | **必须使用**：异常场景覆盖 |\n| 风险驱动测试 | 风险优先 | 优先覆盖高风险区域和高频使用场景 | 高风险功能 |\n| 状态转换法 | 状态机测试 | 测试状态机的合法/非法转换 | 有状态变化的功能 |\n| 因果图法 | 复杂条件组合 | 分析输入条件与输出结果的因果关系 | **必须使用**：复杂条件依赖关系 |\n| 正交试验法 | 多因素多水平 | 用最少的试验覆盖最多的因素组合 | **必须使用**：多因素兼容性测试 |\n| 功能图法 | 功能组合测试 | 分析功能点的输入输出关系，生成功能测试用例 | **必须使用**：功能点组合覆盖 |\n\n### 方法应用要点\n\n**等价类划分法**：有效等价类（正常业务数据范围）、无效等价类（异常/边界/特殊数据）。划分依据：业务规则、数据类型、用户角色。示例：用户年龄输入（1-120有效，<1或>120无效）。\n\n**边界值分析法**：数值边界（最小值、最小值+1、最大值-1、最大值）、字符串边界（空、1字符、最大长度、最大长度+1）、日期边界（当天、前一天、后一天）。示例：密码长度8位（测试7位、8位、9位）。\n\n**场景法**：主成功场景（正常业务流程）、扩展场景（分支流程）、异常场景（错误处理流程）。示例：电商下单（浏览→加购→结算→支付→完成）。\n\n**判定表驱动法**：条件桩（所有输入条件）、动作桩（所有可能输出）、规则（条件组合与动作对应关系）。示例：登录（用户名正确/错误 × 密码正确/错误 → 不同结果）。\n\n**错误推测法**：基于经验（历史缺陷/常见错误模式）、基于直觉（测试人员经验判断）、基于领域知识（业务规则边界）。示例：输入框输入特殊字符/超长字符串/SQL注入语句。\n\n**因果图法**：原因（输入条件）、结果（输出结果）、关系（与/或/非逻辑）、约束（条件间依赖）。示例：优惠券使用条件（金额≥100且有券 → 可使用）。\n\n**正交试验法**：因素（测试变量）、水平（取值）、用例（最少组合覆盖最多因素）。示例：兼容性测试（3浏览器×3系统×3分辨率 → 正交表选9组）。\n\n**功能图法**：功能点（系统功能）、输入（条件）、输出（结果）、组合（调用关系）。示例：电商系统（登录→浏览→加购→结算→支付→功能组合测试）。\n\n## 复杂场景覆盖\n\n| 场景类型 | 测试重点 | 示例 |\n|----------|----------|------|\n| 页面跳转测试 | 跳转目标、参数传递、权限校验 | 列表跳详情页、菜单跳转、外部链接跳转 |\n| 路由参数测试 | 参数缺失、非法、越界处理 | URL参数传递、query参数、path参数 |\n| 跨页面联动 | 数据传递、状态同步、缓存一致性 | 订单页与用户页关联、购物车与结算页联动 |\n| 并发场景测试 | 多人同时操作、数据竞争 | 同时下单、库存并发扣减 |\n| 异常兜底测试 | 服务降级、熔断、重试机制 | 接口超时、服务不可用、网络异常 |\n\n### 页面跳转测试深度覆盖\n\n**测试要点**：跳转触发点、跳转目标页、跳转条件、异常跳转。检查：正常跳转目标正确、参数传递完整、权限校验拦截正确、404处理、空状态、浏览器回退、返回按钮、面包屑导航、外部跳转新标签页、循环跳转检测。\n\n### 路由参数测试深度覆盖\n\n**测试要点**：参数定义（query/path/hash）、格式（数据类型/长度限制）、传递方式（URL/session/cookie/localStorage）、验证（缺失/非法/越界/安全）。检查：参数存在性、类型、长度、格式、安全（SQL注入/XSS）、边界、组合、编码。\n\n### 跨页面联动测试深度覆盖\n\n**测试要点**：数据依赖（页面间数据关系）、状态同步（操作后更新）、缓存策略（刷新机制）、业务流程（完整闭环）。检查：数据传递正确、关联页面状态更新、缓存策略合理、消息通知跳转正确、业务闭环完整、多页面数据一致、操作反馈同步。\n\n## 常用测试方法速查\n\n**等价类划分示例**：年龄输入框（有效[1,120]，无效<1/>120/非数字）；状态下拉（有效[启用/禁用/冻结]，无效其他）。\n\n**边界值分析示例**：文件上传10MB（9MB/10MB/10.1MB）；文本框200字符（199/200/201字）；列表分页（第1页/最后1页/超出最大页码）。\n\n**判定表示例**：\n\n| 条件 | A(有优惠券) | B(满100元) | C(可用) | 结果 |\n|------|-------------|------------|---------|------|\n| 1 | Y | Y | Y | 可以使用 |\n| 2 | Y | Y | N | 不可用（已过期） |\n| 3 | Y | N | Y | 不可用（不满足门槛） |\n| 4 | N | Y/Y | Y/Y | 不适用 |\n\nFile v1.7.5:references/output-template-full.md\n\n# 测试用例字段模板与输出格式（完整版）\n\n> 本文件由 qa-test-case-design SKILL.md 拆分而来，按需加载。\n\n### 标准用例字段模板\n\n| 字段 | 说明 | 是否必填 |\n|------|------|----------|\n| 用例编号 | 唯一标识，便于追踪和管理 | ✅ 必填 |\n| 测试类型 | 功能/性能/安全/兼容性等 | ✅ 必填 |\n| 功能模块 | 所属的业务模块或系统组件 | ✅ 必填 |\n| 子功能 | 具体的功能点或操作场景 | ✅ 必填 |\n| 测试标题 | 简明扼要地描述测试目的 | ✅ 必填 |\n| 用例级别 | P0(关键)、P1(重要)、P2(一般)、P3(可选) | ✅ 必填 |\n| 预置条件 | 执行测试前必须满足的状态或数据准备 | ✅ 必填 |\n| 测试步骤 | 详细的操作步骤（留空，由用户补充） | ⚠️ 留空 |\n| 预期结果 | 每个步骤对应的预期产出或状态变化 | ✅ 必填 |\n| 实际结果 | 测试执行后的真实结果记录（留空） | ⚠️ 留空 |\n\n### 用例编号规则\n\n`TC_{模块缩写}_{功能序列号}_{场景后缀}`\n\n示例：\n- `TC_USER_LOGIN_001_NORMAL` - 用户模块 - 登录功能 - 第001条 - 正常场景\n- `TC_ORDER_DETAIL_002_JUMP` - 订单模块 - 详情页 - 第002条 - 跳转场景\n- `TC_PRODUCT_LINK_003_CROSS` - 商品模块 - 关联页面 - 第003条 - 跨页面联动\n\n### 用例级别定义\n\n| 级别 | 说明 | 适用场景 |\n|------|------|----------|\n| P0 | 关键用例 | 核心业务流程、阻碍系统正常使用的问题、主流程验证 |\n| P1 | 重要用例 | 主要功能、影响用户体验的问题、重要分支流程 |\n| P2 | 一般用例 | 次要功能、不影响主体流程的问题、异常场景 |\n| P3 | 可选用例 | 边缘场景、美化优化相关、极端异常情况 |\n\n> 详细的设计方法、覆盖策略和评审标准参见 `references/`：\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\n\n## 输出模板\n\n**重要：以下输出格式是固定的，必须严格遵守。**\n\n### 测试用例设计输出格式\n\n```markdown\n## 测试用例设计报告\n\n### 基本信息\n- 功能模块：[模块名称]\n- 设计日期：[日期]\n- 设计人员：[姓名]\n- 用例总数：[数量]\n\n### 用例统计\n| 级别 | 数量 | 占比 |\n|------|------|------|\n| P0 | [数量] | [百分比] |\n| P1 | [数量] | [百分比] |\n| P2 | [数量] | [百分比] |\n| P3 | [数量] | [百分比] |\n\n### 测试用例列表\n\n#### P0 关键用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_001 | [测试标题] | 功能测试 | 等价类划分法 | REQ-XXX-001 | [预期结果] |\n\n#### P1 重要用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_002 | [测试标题] | 功能测试 | 边界值分析法 | REQ-XXX-002 | [预期结果] |\n\n#### P2 一般用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_003 | [测试标题] | 异常测试 | 错误推测法 | REQ-XXX-003 | [预期结果] |\n\n#### P3 可选用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_004 | [测试标题] | 边界测试 | 边界值分析法 | REQ-XXX-004 | [预期结果] |\n\n### 覆盖率分析\n- 需求覆盖率：[百分比]\n- 功能覆盖率：[百分比]\n- 风险覆盖率：[百分比]\n\n### 测试建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\n### 单条用例输出格式\n\n```markdown\n## 测试用例\n\n### 基本信息\n- 用例编号：TC_XXX_001\n- 测试类型：功能测试\n- 功能模块：用户管理\n- 子功能：登录\n- 测试标题：验证正确的用户名和密码可以成功登录\n- 用例级别：P0\n- 需求追溯ID：REQ-AUTH-001\n- 测试方法：等价类划分法、边界值分析法\n\n### 预置条件\n1. 用户已注册\n2. 网络正常\n3. 服务正常运行\n4. 前置依赖：无\n\n### 测试步骤\n（留空，由用户根据实际系统补充）\n\n### 预期结果\n1. 跳转至首页\n2. 显示用户信息\n3. 登录状态保持正常\n\n### 实际结果\n（测试执行后填写）\n\n### 字段级验证（如适用）\n- 用户名字段：\n - 长度边界：1位、20位、21位\n - 格式校验：无特殊格式要求\n - 注入测试：SQL注入、XSS攻击\n - 特殊字符：空格、@、#等\n- 密码字段：\n - 长度边界：1位、8位、9位\n - 格式校验：至少8位，包含字母、数字、特殊字符\n - 注入测试：SQL注入、XSS攻击\n - 特殊字符：空格、@、#等\n```\n\nFile v1.7.5:references/review-standards.md\n\n# 需求文档要求与用例评审标准\n\n## 需求文档要求\n\n### 页面跳转、路由参数、跨页面联动场景的需求要求\n\n#### 1. 页面跳转需求要求\n- **跳转触发点**：明确哪些操作会触发页面跳转（按钮、链接、菜单等）\n- **跳转目标页**：明确跳转到哪个页面，页面标识（URL、页面名称等）\n- **跳转条件**：在什么条件下允许跳转（权限、数据状态等）\n- **跳转参数**：需要传递哪些参数（ID、类型、来源等）\n- **异常处理**：跳转失败时的处理方式（错误提示、回退逻辑等）\n\n#### 2. 路由参数需求要求\n- **参数定义**：明确URL中包含哪些参数（query参数、path参数等）\n- **参数格式**：参数的数据类型、格式要求、长度限制\n- **参数传递**：参数如何在页面间传递（URL、session、cookie等）\n- **参数验证**：参数缺失、非法、越界时的处理逻辑\n- **参数安全**：参数的权限控制、防篡改机制\n\n#### 3. 跨页面联动需求要求\n- **数据依赖**：页面间的数据依赖关系（哪些数据需要同步）\n- **状态同步**：页面状态变更后，其他页面如何同步更新\n- **缓存策略**：页面数据的缓存机制和刷新策略\n- **业务流程**：跨页面的完整业务流程描述\n- **异常处理**：联动失败时的处理方式（数据回滚、状态恢复等）\n\n#### 4. 需求文档质量要求\n- **完整性**：所有跳转、参数、联动场景都有明确描述\n- **一致性**：不同部分的需求描述不矛盾\n- **可测试性**：需求描述足够具体，可以设计测试用例\n- **无歧义**：需求描述清晰，没有多种理解方式\n\n### 需求文档检查清单\n\n- [ ] 所有页面跳转的触发条件和目标页面\n- [ ] 路由参数的定义、格式和传递规则\n- [ ] 跨页面数据依赖和状态同步机制\n- [ ] 异常场景的处理逻辑\n- [ ] 权限控制要求\n- [ ] 业务流程的完整描述\n\n### 需求不足时的处理\n\n如果需求文档信息不足，应该：标记缺失信息、提出澄清问题、基于经验假设（注明假设条件）、在测试报告中说明需求不足带来的测试风险。\n\n## 用例评审标准\n\n### 完整性检查\n- [ ] 是否覆盖所有需求点和隐性场景？\n- [ ] 主流程、分支流程、异常场景是否覆盖？\n- [ ] 边界条件、特殊数据是否覆盖？\n- [ ] 权限控制、安全场景是否覆盖？\n\n### 独立性检查\n- [ ] 用例之间是否存在强依赖关系？\n- [ ] 用例执行顺序是否影响结果？\n- [ ] 用例数据是否相互独立？\n\n### 可执行性检查\n- [ ] 预置条件是否明确可准备？\n- [ ] 预期结果是否客观可测量？\n- [ ] 测试标题是否准确反映测试目的？\n- [ ] 用例级别是否合理？\n\n### 可维护性检查\n- [ ] 用例编号是否规范？\n- [ ] 命名是否清晰一致？\n- [ ] 变更是否可追溯？\n\n### 评审通过标准\n\n1. ✅ **覆盖率达标**: 核心功能P0用例覆盖率100%\n2. ✅ **逻辑自洽**: 无矛盾或冲突的用例描述\n3. ✅ **可执行性**: 预期结果均可客观验证\n4. ✅ **边界覆盖**: 输入边界、异常场景均有对应用例\n5. ✅ **优先级合理**: P0用例不超过总数30%\n6. ✅ **格式规范**: 符合标准模板要求\n\nFile v1.7.5:skill-card.md\n\n## Description:\n\nThis skill helps QA practitioners turn completed requirement, scenario, boundary, and combination analysis into prioritized, traceable test cases with coverage guidance.\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 test leads use this skill after upstream analysis is complete to design or review structured test cases for feature requirements, coverage gaps, and priority planning.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may activate too broadly during general QA discussions.\n\nMitigation: Clarify whether the user wants formal test-case generation before producing a structured test-case report.\n\nRisk: Incomplete requirements or missing upstream analysis can lead to generic or misleading test cases.\n\nMitigation: Provide requirement details, scenario analysis, boundary conditions, and business context; label assumptions and coverage gaps when inputs are incomplete.\n\nRisk: Generated execution steps may not match the target system implementation.\n\nMitigation: Keep test steps blank for the user to complete against the actual system, while generating preconditions and objective expected results.\n\nRisk: Coverage claims can be overstated when based on partial input.\n\nMitigation: State the coverage basis, avoid absolute full-coverage claims, and mark missing modules with the reason they are not covered.\n\n## Reference(s):\n\n- [Design Methods](references/design-methods.md)\n- [Coverage and Quality](references/coverage-and-quality.md)\n- [Output Template Full](references/output-template-full.md)\n- [Review Standards](references/review-standards.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown test-case reports, tables, coverage notes, and review guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces P0-P3 priorities, traceability IDs, objective expected results, coverage notes, and blank test steps for user completion.]\n\n## Skill Version(s):\n\n1.7.5 (source: SKILL.md 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: 7 files, 13568 bytes\n\nFiles: references/coverage-and-quality.md (3596b), references/design-methods.md (5605b), references/output-template-full.md (4982b), references/review-standards.md (3326b), skill-card.md (2068b), SKILL.md (9101b), _meta.json (138b)\n\nFile v1.7.0:SKILL.md\n\n---\nname: qa-test-case-design\nslug: qa-test-case-design\ndisplayName: Test Case Design\nversion: 1.7.0\ndescription: >-\n 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。适用于将前面的分析产出物整合为 P0-P3 分级、可追溯的标准格式测试用例。\n\nwhen_to_use: 用户说\"设计测试用例\"、\"用例评审\"、\"用例覆盖\"、\"测试用例设计\"、\"用例模板\"、\"用例规范\"、\"用例格式\"、需要测试用例结构指导、需要编写或规范测试用例时\nallowed-tools: Read Grep Glob\nrelated_skills:\n upstream:\n - qa-req-deconstruction # 输入：需求解构结果\n - qa-boundary-deep-dive # 输入：边界分析结果\n - qa-scenario-tree # 输入：场景树构建结果\n downstream:\n - qa-test-skills # 输出：测试用例设计结果\n - qa-expert-review # 输出：用例评审反馈\n - qa-regression-testing\nreferences:\n - references/coverage-and-quality.md\n - references/design-methods.md\n - references/review-standards.md\ninput_format:\n required:\n - name: 需求描述\n type: string\n description: 功能需求的详细说明\n optional:\n - name: 场景分析\n type: object\n description: 来自qa-scenario-tree的场景树\n - name: 边界条件\n type: object\n description: 来自qa-boundary-deep-dive的边界分析结果\n - name: 业务背景\n type: string\n description: 业务目标和用户角色\noutput_format:\n structure:\n - test_case_id: \"TC_模块_功能_序列\"\n - test_type: \"功能/性能/安全/兼容性\"\n - priority: \"P0/P1/P2/P3\"\n - test_title: \"测试标题\"\n - preconditions: \"预置条件\"\n - test_steps: \"留空（用户补充）\"\n - expected_results: \"预期结果\"\n traceability:\n - 每个用例带唯一ID（TC-XXXX）\n - 关联需求ID（REQ-XXXX）\n - 关联场景ID（SC-XXXX）\ndepth_requirement_quantification:\n reference_value: \"根据需求复杂度调整用例设计深度：简单×2/中等×3/复杂×4\"\n minimum: \"用例总数不低于需求点的3倍\"\ncategories: ['Development','Testing']\nerror_recovery_guidance:\n on_failure: \"用例设计遗漏维度时回退到边界分析和场景树补充\"\n retry_behavior: \"补充上游后重新设计用例\"\n---\n# 高级测试用例设计专项\n\n## 核心原则\n\n测试用例设计的核心——明确\"测什么\"，而非\"怎么测\"。\n\n我们专注于：用例结构设计、场景覆盖策略、分类优先级、测试点识别组织。\n\n> **重要限制**：禁止读取代码——测试用例必须基于需求文档，不得读取代码实现。确保验证\"系统应该做什么\"，而非\"系统如何实现\"。\n>\n> 详细的设计方法、覆盖策略和评审标准参见 `references/` 目录：\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\n\n## 设计理念\n\n### 为什么测试步骤留空？\n\n```\n同一个\"登录\"功能，不同系统实现完全不同。\nAI不知道你们系统用的是哪种实现方式：\n- 强制生成步骤 → 步骤与实际不符 → 测试人员需要大量修正 → 增加工作量\n- 测试步骤留空 → 用户基于实际系统补充 → 只需补充细节 → 减少工作量\n```\n\n## 测试用例结构设计\n\n**重要：输出格式、用例分级、编号规则是固定的，必须严格遵守。**\n\n### 标准用例字段模板\n\n> 📖 完整的字段模板、用例编号规则、级别定义、输出格式和报告结构详见 [`references/output-template-full.md`](references/output-template-full.md)。\n>\n> 本节保留核心字段概览，详细模板按需加载以节省 context。\n\n## 使用方法\n\n### 触发场景\n\n当用户提供以下类型的请求时，此技能自动激活：\n\n1. **生成测试用例**：\"帮我设计用户登录功能的测试用例\"\n2. **完善用例**：\"这些测试用例不够全面，请补充异常场景\"\n3. **审查用例**：\"检查一下这些测试用例是否有遗漏\"\n4. **评审辅助**：\"我需要准备测试用例评审，生成一套完整的用例\"\n5. **覆盖优化**：\"这个功能还缺哪些测试场景\"\n6. **质量评估**：\"评估一下这些测试用例的质量\"\n\n### 输入要素\n\n为生成高质量的测试用例，尽量提供以下信息：\n\n1. **需求描述**：功能需求的详细说明\n2. **业务背景**：该功能在整体产品中的定位\n3. **约束条件**：技术限制、合规要求等\n4. **目标用户**：主要使用人群及其特征\n5. **关联系统**：涉及的其他模块或第三方服务\n6. **风险点**：已知的高风险区域\n7. **历史缺陷**：类似功能的历史问题\n\n### 输出内容\n\n1. **完整测试用例集**：涵盖所有识别出的测试点\n2. **测试优先级排序**：按P0-P3分级展示\n3. **覆盖率说明**：已覆盖的测试维度列表\n4. **缺失风险提示**：可能存在的测试盲区建议\n5. **测试建议**：针对测试执行的建议\n\n## 最佳实践\n\n### 用例设计原则\n\n✅ **DO - 推荐做法**\n- 每个用例只验证一个明确的目标\n- 使用清晰的数字序号标记预期结果\n- 预期结果使用\"应该/必须/会\"等确定性词汇\n- 包含正向和反向两种情况的验证\n- 标注敏感信息的脱敏处理方式\n- 为复杂场景添加截图或伪代码说明\n- 测试步骤留空，由用户根据实际系统补充\n\n❌ **DON'T - 避免做法**\n- 模糊的描述如\"检查是否可以正常工作\"\n- 一次性验证过多无关功能\n- 忽略前置条件和环境配置\n- 混合多个验证点在一个预期结果中\n- 使用主观判断代替客观测量\n- 忽略异常处理流程\n- 强制生成可能与实际不符的测试步骤\n\n### 用例评审要点\n\n1. **完整性检查**：是否覆盖所有需求点和隐性场景\n2. **独立性检查**：用例之间是否存在强依赖关系\n3. **可执行性检查**：预期结果是否清晰、客观可测量\n4. **可维护性检查**：命名规范、变更可追溯\n5. **优先级合理性**：P0用例是否真正关键\n6. **覆盖全面性**：功能、数据、权限、集成是否覆盖\n\n## 输出示例\n\n### 示例1：电商下单功能测试用例设计\n\n```markdown\n## 订单模块 - 商品下单 - P0\n\n### TC_ORDER_CREATE_001 正常下单流程\n\n**测试类型**: 功能测试\n**功能模块**: 订单管理\n**子功能**: 商品下单\n**用例级别**: P0\n**预置条件**:\n1. 用户已登录且账户余额充足\n2. 商品库存大于0\n3. 收货地址已配置\n\n**测试步骤**:\n（留空，由用户根据实际系统补充）\n\n**预期结果**:\n1. 进入订单确认页\n2. 订单金额计算准确（含运费优惠）\n3. 订单创建成功，返回订单号\n4. 库存扣减正确\n5. 收到订单confirmation通知\n\n**实际结果**: 待执行\n```\n\n### 示例2：用户注册功能异常场景\n\n```markdown\n## 用户模块 - 注册 - P1\n\n### TC_USER_REGISTER_002 邮箱格式错误\n\n**测试类型**: 功能测试\n**功能模块**: 用户管理\n**子功能**: 用户注册\n**用例级别**: P1\n**预置条件**: 访问注册页面\n\n**测试步骤**:\n（留空，由用户根据实际系统补充）\n\n**预期结果**:\n1. 邮箱字段显示红色错误提示\n2. 提示内容明确告知格式要求\n3. 无法继续提交表单\n4. 控制台无报错日志\n\n**实际结果**: 待执行\n```\n\n### 示例3：页面跳转测试用例设计\n\n```markdown\n## 商品模块 - 列表跳详情 - P0\n\n### TC_PRODUCT_LIST_001 正常跳转详情页\n\n**测试类型**: 功能测试\n**功能模块**: 商品管理\n**子功能**: 列表跳详情\n**用例级别**: P0\n**预置条件**:\n1. 用户已登录\n2. 商品列表页有数据\n\n**测试步骤**:\n（留空，由用户根据实际系统补充）\n\n**预期结果**:\n1. 成功跳转到商品详情页\n2. URL包含正确的商品ID（如/product/12345）\n3. 详情页展示的商品信息与列表一致\n4. 商品图片、价格、库存等关键信息正确\n5. 详情页功能按钮（购买、收藏等）可用\n\n**实际结果**: 待执行\n```\n\n## 检查清单\n\n测试用例设计完成后检查：\n- [ ] 是否覆盖了所有需求点和隐性场景？\n- [ ] 是否包含了正常、异常、边界三种场景？\n- [ ] 每条用例是否只验证一个明确目标？\n- [ ] 预期结果是否可客观验证？\n- [ ] 用例优先级（P0-P3）是否合理？\n\n## 参考资源\n\n- `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n- `references/coverage-and-quality.md` — 覆盖维度 + 覆盖评估 + 质量指标\n- `references/review-standards.md` — 需求文档要求 + 用例评审标准\n- ISTQB测试术语标准 / ISO/IEC/IEEE 29119 / Google Testing Blog\n\nFile v1.7.0:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-test-case-design\",\n \"version\": \"1.7.0\",\n \"publishedAt\": 1786890800118\n}\n\nFile v1.7.0:references/coverage-and-quality.md\n\n# 测试覆盖策略与质量标准\n\n## 覆盖维度\n\n```\n测试覆盖：\n├─ 功能覆盖\n│ ├─ 主流程覆盖：核心业务流程是否完整测试\n│ ├─ 分支流程覆盖：各种条件分支路径是否覆盖\n│ ├─ 异常场景覆盖：错误输入、异常操作是否测试\n│ ├─ 边界条件覆盖：输入范围边界、数量边界是否测试\n│ ├─ 退出流程覆盖：退出登录、注销、超时退出等场景\n│ └─ 状态转换覆盖：系统状态变化是否测试\n│\n├─ 数据覆盖\n│ ├─ 有效数据覆盖：正常数据是否测试\n│ ├─ 无效数据覆盖：异常数据是否测试\n│ ├─ 边界数据覆盖：边界值数据是否测试\n│ ├─ 特殊数据覆盖：特殊字符、超长数据是否测试\n│ ├─ 格式校验覆盖：邮箱、手机号、身份证等格式验证\n│ └─ 注入测试覆盖：SQL注入、XSS攻击等安全测试\n│\n├─ 字段级验证覆盖（每个表单字段必须测试）\n│ ├─ 长度边界：1位、最大长度、最大长度+1\n│ ├─ 格式校验：正则表达式验证（邮箱、手机号、身份证等）\n│ ├─ 注入测试：SQL注入、XSS攻击、命令注入\n│ ├─ 特殊字符：空格、特殊符号、Unicode字符\n│ ├─ 空值处理：必填字段为空、选填字段为空\n│ └─ 默认值：字段默认值是否正确\n│\n├─ 权限覆盖\n│ ├─ 角色权限覆盖：不同角色权限是否测试\n│ ├─ 越权访问覆盖：越权操作是否拦截\n│ ├─ 数据权限覆盖：数据隔离是否验证\n│ ├─ 功能权限覆盖：功能访问控制是否测试\n│ ├─ CSRF防护覆盖：跨站请求伪造防护是否测试\n│ └─ 路径遍历覆盖：目录遍历攻击防护是否测试\n│\n├─ 集成覆盖\n│ ├─ 模块集成覆盖：模块间协作是否测试\n│ ├─ 接口集成覆盖：接口调用是否测试\n│ ├─ 数据集成覆盖：数据流转是否测试\n│ └─ 异常集成覆盖：异常处理是否测试\n│\n└─ 非功能覆盖\n ├─ 性能覆盖：响应时间、吞吐量、并发性能是否测试\n ├─ 兼容性覆盖：浏览器、操作系统、设备兼容性是否测试\n ├─ 可用性覆盖：用户体验、易用性是否测试\n ├─ 安全性覆盖：数据加密、传输安全是否测试\n └─ 可靠性覆盖：稳定性、容错性是否测试\n```\n\n### 覆盖率评估\n\n| 覆盖率类型 | 计算方式 | 目标值 |\n|------------|----------|--------|\n| 需求覆盖率 | 已测需求点 / 总需求点 × 100% | ≥95% |\n| 功能覆盖率 | 已测功能点 / 总功能点 × 100% | ≥90% |\n| 用例覆盖率 | 已执行用例 / 总用例 × 100% | ≥100% |\n| 缺陷覆盖率 | 已修复缺陷 / 总缺陷 × 100% | ≥90% |\n\n## 质量保证标准\n\n### 用例质量指标\n\n| 指标 | 计算方式 | 目标值 |\n|------|----------|--------|\n| 用例有效性 | 有效用例数 / 总用例数 × 100% | ≥95% |\n| 用例执行率 | 已执行用例数 / 总用例数 × 100% | ≥100% |\n| 用例通过率 | 通过用例数 / 已执行用例数 × 100% | ≥98% |\n| 缺陷发现率 | 缺陷数 / 用例数 × 100% | 持续优化 |\n\n### 交付质量标准\n\n- 用例总数不低于需求点的3倍（包含异常场景）\n- P0+P1用例占比不低于60%\n- 每条用例平均预期结果3-5条\n- 无空洞描述，预期结果均可客观验证\n- 符合企业测试管理规范格式要求\n- 测试步骤留空，由用户根据实际系统补充\n\nFile v1.7.0:references/design-methods.md\n\n# 用例设计方法参考\n\n## 常用设计方法\n\n| 方法 | 适用场景 | 说明 | 必用场景 |\n|------|----------|------|----------|\n| 等价类划分法 | 输入域测试 | 将输入域划分为有效/无效等价类，减少冗余用例 | 所有输入字段 |\n| 边界值分析法 | 边界测试 | 针对边界情况设计专项测试，发现常见错误 | 所有有边界限制的字段 |\n| 场景法 | 业务流程测试 | 基于用户业务流程构建端到端测试场景 | 核心业务流程 |\n| 判定表驱动法 | 多条件组合 | 穷举所有条件组合可能性 | **必须使用**：多条件组合场景 |\n| 错误推测法 | 经验驱动 | 基于历史缺陷数据和开发经验预测潜在问题 | **必须使用**：异常场景覆盖 |\n| 风险驱动测试 | 风险优先 | 优先覆盖高风险区域和高频使用场景 | 高风险功能 |\n| 状态转换法 | 状态机测试 | 测试状态机的合法/非法转换 | 有状态变化的功能 |\n| 因果图法 | 复杂条件组合 | 分析输入条件与输出结果的因果关系 | **必须使用**：复杂条件依赖关系 |\n| 正交试验法 | 多因素多水平 | 用最少的试验覆盖最多的因素组合 | **必须使用**：多因素兼容性测试 |\n| 功能图法 | 功能组合测试 | 分析功能点的输入输出关系，生成功能测试用例 | **必须使用**：功能点组合覆盖 |\n\n### 方法应用要点\n\n**等价类划分法**：有效等价类（正常业务数据范围）、无效等价类（异常/边界/特殊数据）。划分依据：业务规则、数据类型、用户角色。示例：用户年龄输入（1-120有效，<1或>120无效）。\n\n**边界值分析法**：数值边界（最小值、最小值+1、最大值-1、最大值）、字符串边界（空、1字符、最大长度、最大长度+1）、日期边界（当天、前一天、后一天）。示例：密码长度8位（测试7位、8位、9位）。\n\n**场景法**：主成功场景（正常业务流程）、扩展场景（分支流程）、异常场景（错误处理流程）。示例：电商下单（浏览→加购→结算→支付→完成）。\n\n**判定表驱动法**：条件桩（所有输入条件）、动作桩（所有可能输出）、规则（条件组合与动作对应关系）。示例：登录（用户名正确/错误 × 密码正确/错误 → 不同结果）。\n\n**错误推测法**：基于经验（历史缺陷/常见错误模式）、基于直觉（测试人员经验判断）、基于领域知识（业务规则边界）。示例：输入框输入特殊字符/超长字符串/SQL注入语句。\n\n**因果图法**：原因（输入条件）、结果（输出结果）、关系（与/或/非逻辑）、约束（条件间依赖）。示例：优惠券使用条件（金额≥100且有券 → 可使用）。\n\n**正交试验法**：因素（测试变量）、水平（取值）、用例（最少组合覆盖最多因素）。示例：兼容性测试（3浏览器×3系统×3分辨率 → 正交表选9组）。\n\n**功能图法**：功能点（系统功能）、输入（条件）、输出（结果）、组合（调用关系）。示例：电商系统（登录→浏览→加购→结算→支付→功能组合测试）。\n\n## 复杂场景覆盖\n\n| 场景类型 | 测试重点 | 示例 |\n|----------|----------|------|\n| 页面跳转测试 | 跳转目标、参数传递、权限校验 | 列表跳详情页、菜单跳转、外部链接跳转 |\n| 路由参数测试 | 参数缺失、非法、越界处理 | URL参数传递、query参数、path参数 |\n| 跨页面联动 | 数据传递、状态同步、缓存一致性 | 订单页与用户页关联、购物车与结算页联动 |\n| 并发场景测试 | 多人同时操作、数据竞争 | 同时下单、库存并发扣减 |\n| 异常兜底测试 | 服务降级、熔断、重试机制 | 接口超时、服务不可用、网络异常 |\n\n### 页面跳转测试深度覆盖\n\n**测试要点**：跳转触发点、跳转目标页、跳转条件、异常跳转。检查：正常跳转目标正确、参数传递完整、权限校验拦截正确、404处理、空状态、浏览器回退、返回按钮、面包屑导航、外部跳转新标签页、循环跳转检测。\n\n### 路由参数测试深度覆盖\n\n**测试要点**：参数定义（query/path/hash）、格式（数据类型/长度限制）、传递方式（URL/session/cookie/localStorage）、验证（缺失/非法/越界/安全）。检查：参数存在性、类型、长度、格式、安全（SQL注入/XSS）、边界、组合、编码。\n\n### 跨页面联动测试深度覆盖\n\n**测试要点**：数据依赖（页面间数据关系）、状态同步（操作后更新）、缓存策略（刷新机制）、业务流程（完整闭环）。检查：数据传递正确、关联页面状态更新、缓存策略合理、消息通知跳转正确、业务闭环完整、多页面数据一致、操作反馈同步。\n\n## 常用测试方法速查\n\n**等价类划分示例**：年龄输入框（有效[1,120]，无效<1/>120/非数字）；状态下拉（有效[启用/禁用/冻结]，无效其他）。\n\n**边界值分析示例**：文件上传10MB（9MB/10MB/10.1MB）；文本框200字符（199/200/201字）；列表分页（第1页/最后1页/超出最大页码）。\n\n**判定表示例**：\n\n| 条件 | A(有优惠券) | B(满100元) | C(可用) | 结果 |\n|------|-------------|------------|---------|------|\n| 1 | Y | Y | Y | 可以使用 |\n| 2 | Y | Y | N | 不可用（已过期） |\n| 3 | Y | N | Y | 不可用（不满足门槛） |\n| 4 | N | Y/Y | Y/Y | 不适用 |\n\nFile v1.7.0:references/output-template-full.md\n\n# 测试用例字段模板与输出格式（完整版）\n\n> 本文件由 qa-test-case-design SKILL.md 拆分而来，按需加载。\n\n### 标准用例字段模板\n\n| 字段 | 说明 | 是否必填 |\n|------|------|----------|\n| 用例编号 | 唯一标识，便于追踪和管理 | ✅ 必填 |\n| 测试类型 | 功能/性能/安全/兼容性等 | ✅ 必填 |\n| 功能模块 | 所属的业务模块或系统组件 | ✅ 必填 |\n| 子功能 | 具体的功能点或操作场景 | ✅ 必填 |\n| 测试标题 | 简明扼要地描述测试目的 | ✅ 必填 |\n| 用例级别 | P0(关键)、P1(重要)、P2(一般)、P3(可选) | ✅ 必填 |\n| 预置条件 | 执行测试前必须满足的状态或数据准备 | ✅ 必填 |\n| 测试步骤 | 详细的操作步骤（留空，由用户补充） | ⚠️ 留空 |\n| 预期结果 | 每个步骤对应的预期产出或状态变化 | ✅ 必填 |\n| 实际结果 | 测试执行后的真实结果记录（留空） | ⚠️ 留空 |\n\n### 用例编号规则\n\n`TC_{模块缩写}_{功能序列号}_{场景后缀}`\n\n示例：\n- `TC_USER_LOGIN_001_NORMAL` - 用户模块 - 登录功能 - 第001条 - 正常场景\n- `TC_ORDER_DETAIL_002_JUMP` - 订单模块 - 详情页 - 第002条 - 跳转场景\n- `TC_PRODUCT_LINK_003_CROSS` - 商品模块 - 关联页面 - 第003条 - 跨页面联动\n\n### 用例级别定义\n\n| 级别 | 说明 | 适用场景 |\n|------|------|----------|\n| P0 | 关键用例 | 核心业务流程、阻碍系统正常使用的问题、主流程验证 |\n| P1 | 重要用例 | 主要功能、影响用户体验的问题、重要分支流程 |\n| P2 | 一般用例 | 次要功能、不影响主体流程的问题、异常场景 |\n| P3 | 可选用例 | 边缘场景、美化优化相关、极端异常情况 |\n\n> 详细的设计方法、覆盖策略和评审标准参见 `references/`：\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\n\n## 输出模板\n\n**重要：以下输出格式是固定的，必须严格遵守。**\n\n### 测试用例设计输出格式\n\n```markdown\n## 测试用例设计报告\n\n### 基本信息\n- 功能模块：[模块名称]\n- 设计日期：[日期]\n- 设计人员：[姓名]\n- 用例总数：[数量]\n\n### 用例统计\n| 级别 | 数量 | 占比 |\n|------|------|------|\n| P0 | [数量] | [百分比] |\n| P1 | [数量] | [百分比] |\n| P2 | [数量] | [百分比] |\n| P3 | [数量] | [百分比] |\n\n### 测试用例列表\n\n#### P0 关键用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_001 | [测试标题] | 功能测试 | 等价类划分法 | REQ-XXX-001 | [预期结果] |\n\n#### P1 重要用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_002 | [测试标题] | 功能测试 | 边界值分析法 | REQ-XXX-002 | [预期结果] |\n\n#### P2 一般用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_003 | [测试标题] | 异常测试 | 错误推测法 | REQ-XXX-003 | [预期结果] |\n\n#### P3 可选用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_004 | [测试标题] | 边界测试 | 边界值分析法 | REQ-XXX-004 | [预期结果] |\n\n### 覆盖率分析\n- 需求覆盖率：[百分比]\n- 功能覆盖率：[百分比]\n- 风险覆盖率：[百分比]\n\n### 测试建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\n### 单条用例输出格式\n\n```markdown\n## 测试用例\n\n### 基本信息\n- 用例编号：TC_XXX_001\n- 测试类型：功能测试\n- 功能模块：用户管理\n- 子功能：登录\n- 测试标题：验证正确的用户名和密码可以成功登录\n- 用例级别：P0\n- 需求追溯ID：REQ-AUTH-001\n- 测试方法：等价类划分法、边界值分析法\n\n### 预置条件\n1. 用户已注册\n2. 网络正常\n3. 服务正常运行\n4. 前置依赖：无\n\n### 测试步骤\n（留空，由用户根据实际系统补充）\n\n### 预期结果\n1. 跳转至首页\n2. 显示用户信息\n3. 登录状态保持正常\n\n### 实际结果\n（测试执行后填写）\n\n### 字段级验证（如适用）\n- 用户名字段：\n - 长度边界：1位、20位、21位\n - 格式校验：无特殊格式要求\n - 注入测试：SQL注入、XSS攻击\n - 特殊字符：空格、@、#等\n- 密码字段：\n - 长度边界：1位、8位、9位\n - 格式校验：至少8位，包含字母、数字、特殊字符\n - 注入测试：SQL注入、XSS攻击\n - 特殊字符：空格、@、#等\n```\n\nFile v1.7.0:references/review-standards.md\n\n# 需求文档要求与用例评审标准\n\n## 需求文档要求\n\n### 页面跳转、路由参数、跨页面联动场景的需求要求\n\n#### 1. 页面跳转需求要求\n- **跳转触发点**：明确哪些操作会触发页面跳转（按钮、链接、菜单等）\n- **跳转目标页**：明确跳转到哪个页面，页面标识（URL、页面名称等）\n- **跳转条件**：在什么条件下允许跳转（权限、数据状态等）\n- **跳转参数**：需要传递哪些参数（ID、类型、来源等）\n- **异常处理**：跳转失败时的处理方式（错误提示、回退逻辑等）\n\n#### 2. 路由参数需求要求\n- **参数定义**：明确URL中包含哪些参数（query参数、path参数等）\n- **参数格式**：参数的数据类型、格式要求、长度限制\n- **参数传递**：参数如何在页面间传递（URL、session、cookie等）\n- **参数验证**：参数缺失、非法、越界时的处理逻辑\n- **参数安全**：参数的权限控制、防篡改机制\n\n#### 3. 跨页面联动需求要求\n- **数据依赖**：页面间的数据依赖关系（哪些数据需要同步）\n- **状态同步**：页面状态变更后，其他页面如何同步更新\n- **缓存策略**：页面数据的缓存机制和刷新策略\n- **业务流程**：跨页面的完整业务流程描述\n- **异常处理**：联动失败时的处理方式（数据回滚、状态恢复等）\n\n#### 4. 需求文档质量要求\n- **完整性**：所有跳转、参数、联动场景都有明确描述\n- **一致性**：不同部分的需求描述不矛盾\n- **可测试性**：需求描述足够具体，可以设计测试用例\n- **无歧义**：需求描述清晰，没有多种理解方式\n\n### 需求文档检查清单\n\n- [ ] 所有页面跳转的触发条件和目标页面\n- [ ] 路由参数的定义、格式和传递规则\n- [ ] 跨页面数据依赖和状态同步机制\n- [ ] 异常场景的处理逻辑\n- [ ] 权限控制要求\n- [ ] 业务流程的完整描述\n\n### 需求不足时的处理\n\n如果需求文档信息不足，应该：标记缺失信息、提出澄清问题、基于经验假设（注明假设条件）、在测试报告中说明需求不足带来的测试风险。\n\n## 用例评审标准\n\n### 完整性检查\n- [ ] 是否覆盖所有需求点和隐性场景？\n- [ ] 主流程、分支流程、异常场景是否覆盖？\n- [ ] 边界条件、特殊数据是否覆盖？\n- [ ] 权限控制、安全场景是否覆盖？\n\n### 独立性检查\n- [ ] 用例之间是否存在强依赖关系？\n- [ ] 用例执行顺序是否影响结果？\n- [ ] 用例数据是否相互独立？\n\n### 可执行性检查\n- [ ] 预置条件是否明确可准备？\n- [ ] 预期结果是否客观可测量？\n- [ ] 测试标题是否准确反映测试目的？\n- [ ] 用例级别是否合理？\n\n### 可维护性检查\n- [ ] 用例编号是否规范？\n- [ ] 命名是否清晰一致？\n- [ ] 变更是否可追溯？\n\n### 评审通过标准\n\n1. ✅ **覆盖率达标**: 核心功能P0用例覆盖率100%\n2. ✅ **逻辑自洽**: 无矛盾或冲突的用例描述\n3. ✅ **可执行性**: 预期结果均可客观验证\n4. ✅ **边界覆盖**: 输入边界、异常场景均有对应用例\n5. ✅ **优先级合理**: P0用例不超过总数30%\n6. ✅ **格式规范**: 符合标准模板要求\n\nFile v1.7.0:skill-card.md\n\n## Description:\n\nThis skill helps QA practitioners turn completed requirements, scenario, boundary, and combination analysis into structured, prioritized, traceable test cases.\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, testers, and product teams use this skill to convert finished requirements analysis into P0-P3 test case sets with coverage notes, traceability, and review guidance.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may activate for many test-case-related requests and could be used before requirements analysis is complete.\n\nMitigation: Use it after requirements, scenarios, boundaries, and combinations have been analyzed, and provide that prior analysis as input.\n\nRisk: Generated test cases can be incomplete or mismatched to the actual system if the user supplies limited requirements.\n\nMitigation: Review the generated cases against product requirements, fill in system-specific execution steps, and validate coverage before operational use.\n\n## Reference(s):\n\n- [Design Methods](references/design-methods.md)\n- [Coverage and Quality](references/coverage-and-quality.md)\n- [Review Standards](references/review-standards.md)\n- [Output Template Full](references/output-template-full.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown test case templates and QA review guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces prioritized P0-P3 test cases with traceability fields, coverage notes, risk reminders, and user-completed execution steps.]\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: 7 files, 13663 bytes\n\nFiles: references/coverage-and-quality.md (3596b), references/design-methods.md (5605b), references/output-template-full.md (4982b), references/review-standards.md (3326b), skill-card.md (2256b), SKILL.md (9101b), _meta.json (138b)\n\nFile v1.6.3:SKILL.md\n\n---\nname: qa-test-case-design\nslug: qa-test-case-design\ndisplayName: Test Case Design\nversion: 1.6.3\ndescription: >-\n 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。适用于将前面的分析产出物整合为 P0-P3 分级、可追溯的标准格式测试用例。\n\nwhen_to_use: 用户说\"设计测试用例\"、\"用例评审\"、\"用例覆盖\"、\"测试用例设计\"、\"用例模板\"、\"用例规范\"、\"用例格式\"、需要测试用例结构指导、需要编写或规范测试用例时\nallowed-tools: Read Grep Glob\nrelated_skills:\n upstream:\n - qa-req-deconstruction # 输入：需求解构结果\n - qa-boundary-deep-dive # 输入：边界分析结果\n - qa-scenario-tree # 输入：场景树构建结果\n downstream:\n - qa-test-skills # 输出：测试用例设计结果\n - qa-expert-review # 输出：用例评审反馈\n - qa-regression-testing\nreferences:\n - references/coverage-and-quality.md\n - references/design-methods.md\n - references/review-standards.md\ninput_format:\n required:\n - name: 需求描述\n type: string\n description: 功能需求的详细说明\n optional:\n - name: 场景分析\n type: object\n description: 来自qa-scenario-tree的场景树\n - name: 边界条件\n type: object\n description: 来自qa-boundary-deep-dive的边界分析结果\n - name: 业务背景\n type: string\n description: 业务目标和用户角色\noutput_format:\n structure:\n - test_case_id: \"TC_模块_功能_序列\"\n - test_type: \"功能/性能/安全/兼容性\"\n - priority: \"P0/P1/P2/P3\"\n - test_title: \"测试标题\"\n - preconditions: \"预置条件\"\n - test_steps: \"留空（用户补充）\"\n - expected_results: \"预期结果\"\n traceability:\n - 每个用例带唯一ID（TC-XXXX）\n - 关联需求ID（REQ-XXXX）\n - 关联场景ID（SC-XXXX）\ndepth_requirement_quantification:\n reference_value: \"根据需求复杂度调整用例设计深度：简单×2/中等×3/复杂×4\"\n minimum: \"用例总数不低于需求点的3倍\"\ncategories: ['Development','Testing']\nerror_recovery_guidance:\n on_failure: \"用例设计遗漏维度时回退到边界分析和场景树补充\"\n retry_behavior: \"补充上游后重新设计用例\"\n---\n# 高级测试用例设计专项\n\n## 核心原则\n\n测试用例设计的核心——明确\"测什么\"，而非\"怎么测\"。\n\n我们专注于：用例结构设计、场景覆盖策略、分类优先级、测试点识别组织。\n\n> **重要限制**：禁止读取代码——测试用例必须基于需求文档，不得读取代码实现。确保验证\"系统应该做什么\"，而非\"系统如何实现\"。\n>\n> 详细的设计方法、覆盖策略和评审标准参见 `references/` 目录：\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\n\n## 设计理念\n\n### 为什么测试步骤留空？\n\n```\n同一个\"登录\"功能，不同系统实现完全不同。\nAI不知道你们系统用的是哪种实现方式：\n- 强制生成步骤 → 步骤与实际不符 → 测试人员需要大量修正 → 增加工作量\n- 测试步骤留空 → 用户基于实际系统补充 → 只需补充细节 → 减少工作量\n```\n\n## 测试用例结构设计\n\n**重要：输出格式、用例分级、编号规则是固定的，必须严格遵守。**\n\n### 标准用例字段模板\n\n> 📖 完整的字段模板、用例编号规则、级别定义、输出格式和报告结构详见 [`references/output-template-full.md`](references/output-template-full.md)。\n>\n> 本节保留核心字段概览，详细模板按需加载以节省 context。\n\n## 使用方法\n\n### 触发场景\n\n当用户提供以下类型的请求时，此技能自动激活：\n\n1. **生成测试用例**：\"帮我设计用户登录功能的测试用例\"\n2. **完善用例**：\"这些测试用例不够全面，请补充异常场景\"\n3. **审查用例**：\"检查一下这些测试用例是否有遗漏\"\n4. **评审辅助**：\"我需要准备测试用例评审，生成一套完整的用例\"\n5. **覆盖优化**：\"这个功能还缺哪些测试场景\"\n6. **质量评估**：\"评估一下这些测试用例的质量\"\n\n### 输入要素\n\n为生成高质量的测试用例，尽量提供以下信息：\n\n1. **需求描述**：功能需求的详细说明\n2. **业务背景**：该功能在整体产品中的定位\n3. **约束条件**：技术限制、合规要求等\n4. **目标用户**：主要使用人群及其特征\n5. **关联系统**：涉及的其他模块或第三方服务\n6. **风险点**：已知的高风险区域\n7. **历史缺陷**：类似功能的历史问题\n\n### 输出内容\n\n1. **完整测试用例集**：涵盖所有识别出的测试点\n2. **测试优先级排序**：按P0-P3分级展示\n3. **覆盖率说明**：已覆盖的测试维度列表\n4. **缺失风险提示**：可能存在的测试盲区建议\n5. **测试建议**：针对测试执行的建议\n\n## 最佳实践\n\n### 用例设计原则\n\n✅ **DO - 推荐做法**\n- 每个用例只验证一个明确的目标\n- 使用清晰的数字序号标记预期结果\n- 预期结果使用\"应该/必须/会\"等确定性词汇\n- 包含正向和反向两种情况的验证\n- 标注敏感信息的脱敏处理方式\n- 为复杂场景添加截图或伪代码说明\n- 测试步骤留空，由用户根据实际系统补充\n\n❌ **DON'T - 避免做法**\n- 模糊的描述如\"检查是否可以正常工作\"\n- 一次性验证过多无关功能\n- 忽略前置条件和环境配置\n- 混合多个验证点在一个预期结果中\n- 使用主观判断代替客观测量\n- 忽略异常处理流程\n- 强制生成可能与实际不符的测试步骤\n\n### 用例评审要点\n\n1. **完整性检查**：是否覆盖所有需求点和隐性场景\n2. **独立性检查**：用例之间是否存在强依赖关系\n3. **可执行性检查**：预期结果是否清晰、客观可测量\n4. **可维护性检查**：命名规范、变更可追溯\n5. **优先级合理性**：P0用例是否真正关键\n6. **覆盖全面性**：功能、数据、权限、集成是否覆盖\n\n## 输出示例\n\n### 示例1：电商下单功能测试用例设计\n\n```markdown\n## 订单模块 - 商品下单 - P0\n\n### TC_ORDER_CREATE_001 正常下单流程\n\n**测试类型**: 功能测试\n**功能模块**: 订单管理\n**子功能**: 商品下单\n**用例级别**: P0\n**预置条件**:\n1. 用户已登录且账户余额充足\n2. 商品库存大于0\n3. 收货地址已配置\n\n**测试步骤**:\n（留空，由用户根据实际系统补充）\n\n**预期结果**:\n1. 进入订单确认页\n2. 订单金额计算准确（含运费优惠）\n3. 订单创建成功，返回订单号\n4. 库存扣减正确\n5. 收到订单confirmation通知\n\n**实际结果**: 待执行\n```\n\n### 示例2：用户注册功能异常场景\n\n```markdown\n## 用户模块 - 注册 - P1\n\n### TC_USER_REGISTER_002 邮箱格式错误\n\n**测试类型**: 功能测试\n**功能模块**: 用户管理\n**子功能**: 用户注册\n**用例级别**: P1\n**预置条件**: 访问注册页面\n\n**测试步骤**:\n（留空，由用户根据实际系统补充）\n\n**预期结果**:\n1. 邮箱字段显示红色错误提示\n2. 提示内容明确告知格式要求\n3. 无法继续提交表单\n4. 控制台无报错日志\n\n**实际结果**: 待执行\n```\n\n### 示例3：页面跳转测试用例设计\n\n```markdown\n## 商品模块 - 列表跳详情 - P0\n\n### TC_PRODUCT_LIST_001 正常跳转详情页\n\n**测试类型**: 功能测试\n**功能模块**: 商品管理\n**子功能**: 列表跳详情\n**用例级别**: P0\n**预置条件**:\n1. 用户已登录\n2. 商品列表页有数据\n\n**测试步骤**:\n（留空，由用户根据实际系统补充）\n\n**预期结果**:\n1. 成功跳转到商品详情页\n2. URL包含正确的商品ID（如/product/12345）\n3. 详情页展示的商品信息与列表一致\n4. 商品图片、价格、库存等关键信息正确\n5. 详情页功能按钮（购买、收藏等）可用\n\n**实际结果**: 待执行\n```\n\n## 检查清单\n\n测试用例设计完成后检查：\n- [ ] 是否覆盖了所有需求点和隐性场景？\n- [ ] 是否包含了正常、异常、边界三种场景？\n- [ ] 每条用例是否只验证一个明确目标？\n- [ ] 预期结果是否可客观验证？\n- [ ] 用例优先级（P0-P3）是否合理？\n\n## 参考资源\n\n- `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n- `references/coverage-and-quality.md` — 覆盖维度 + 覆盖评估 + 质量指标\n- `references/review-standards.md` — 需求文档要求 + 用例评审标准\n- ISTQB测试术语标准 / ISO/IEC/IEEE 29119 / Google Testing Blog\n\nFile v1.6.3:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-test-case-design\",\n \"version\": \"1.6.3\",\n \"publishedAt\": 1786548586748\n}\n\nFile v1.6.3:references/coverage-and-quality.md\n\n# 测试覆盖策略与质量标准\n\n## 覆盖维度\n\n```\n测试覆盖：\n├─ 功能覆盖\n│ ├─ 主流程覆盖：核心业务流程是否完整测试\n│ ├─ 分支流程覆盖：各种条件分支路径是否覆盖\n│ ├─ 异常场景覆盖：错误输入、异常操作是否测试\n│ ├─ 边界条件覆盖：输入范围边界、数量边界是否测试\n│ ├─ 退出流程覆盖：退出登录、注销、超时退出等场景\n│ └─ 状态转换覆盖：系统状态变化是否测试\n│\n├─ 数据覆盖\n│ ├─ 有效数据覆盖：正常数据是否测试\n│ ├─ 无效数据覆盖：异常数据是否测试\n│ ├─ 边界数据覆盖：边界值数据是否测试\n│ ├─ 特殊数据覆盖：特殊字符、超长数据是否测试\n│ ├─ 格式校验覆盖：邮箱、手机号、身份证等格式验证\n│ └─ 注入测试覆盖：SQL注入、XSS攻击等安全测试\n│\n├─ 字段级验证覆盖（每个表单字段必须测试）\n│ ├─ 长度边界：1位、最大长度、最大长度+1\n│ ├─ 格式校验：正则表达式验证（邮箱、手机号、身份证等）\n│ ├─ 注入测试：SQL注入、XSS攻击、命令注入\n│ ├─ 特殊字符：空格、特殊符号、Unicode字符\n│ ├─ 空值处理：必填字段为空、选填字段为空\n│ └─ 默认值：字段默认值是否正确\n│\n├─ 权限覆盖\n│ ├─ 角色权限覆盖：不同角色权限是否测试\n│ ├─ 越权访问覆盖：越权操作是否拦截\n│ ├─ 数据权限覆盖：数据隔离是否验证\n│ ├─ 功能权限覆盖：功能访问控制是否测试\n│ ├─ CSRF防护覆盖：跨站请求伪造防护是否测试\n│ └─ 路径遍历覆盖：目录遍历攻击防护是否测试\n│\n├─ 集成覆盖\n│ ├─ 模块集成覆盖：模块间协作是否测试\n│ ├─ 接口集成覆盖：接口调用是否测试\n│ ├─ 数据集成覆盖：数据流转是否测试\n│ └─ 异常集成覆盖：异常处理是否测试\n│\n└─ 非功能覆盖\n ├─ 性能覆盖：响应时间、吞吐量、并发性能是否测试\n ├─ 兼容性覆盖：浏览器、操作系统、设备兼容性是否测试\n ├─ 可用性覆盖：用户体验、易用性是否测试\n ├─ 安全性覆盖：数据加密、传输安全是否测试\n └─ 可靠性覆盖：稳定性、容错性是否测试\n```\n\n### 覆盖率评估\n\n| 覆盖率类型 | 计算方式 | 目标值 |\n|------------|----------|--------|\n| 需求覆盖率 | 已测需求点 / 总需求点 × 100% | ≥95% |\n| 功能覆盖率 | 已测功能点 / 总功能点 × 100% | ≥90% |\n| 用例覆盖率 | 已执行用例 / 总用例 × 100% | ≥100% |\n| 缺陷覆盖率 | 已修复缺陷 / 总缺陷 × 100% | ≥90% |\n\n## 质量保证标准\n\n### 用例质量指标\n\n| 指标 | 计算方式 | 目标值 |\n|------|----------|--------|\n| 用例有效性 | 有效用例数 / 总用例数 × 100% | ≥95% |\n| 用例执行率 | 已执行用例数 / 总用例数 × 100% | ≥100% |\n| 用例通过率 | 通过用例数 / 已执行用例数 × 100% | ≥98% |\n| 缺陷发现率 | 缺陷数 / 用例数 × 100% | 持续优化 |\n\n### 交付质量标准\n\n- 用例总数不低于需求点的3倍（包含异常场景）\n- P0+P1用例占比不低于60%\n- 每条用例平均预期结果3-5条\n- 无空洞描述，预期结果均可客观验证\n- 符合企业测试管理规范格式要求\n- 测试步骤留空，由用户根据实际系统补充\n\nFile v1.6.3:references/design-methods.md\n\n# 用例设计方法参考\n\n## 常用设计方法\n\n| 方法 | 适用场景 | 说明 | 必用场景 |\n|------|----------|------|----------|\n| 等价类划分法 | 输入域测试 | 将输入域划分为有效/无效等价类，减少冗余用例 | 所有输入字段 |\n| 边界值分析法 | 边界测试 | 针对边界情况设计专项测试，发现常见错误 | 所有有边界限制的字段 |\n| 场景法 | 业务流程测试 | 基于用户业务流程构建端到端测试场景 | 核心业务流程 |\n| 判定表驱动法 | 多条件组合 | 穷举所有条件组合可能性 | **必须使用**：多条件组合场景 |\n| 错误推测法 | 经验驱动 | 基于历史缺陷数据和开发经验预测潜在问题 | **必须使用**：异常场景覆盖 |\n| 风险驱动测试 | 风险优先 | 优先覆盖高风险区域和高频使用场景 | 高风险功能 |\n| 状态转换法 | 状态机测试 | 测试状态机的合法/非法转换 | 有状态变化的功能 |\n| 因果图法 | 复杂条件组合 | 分析输入条件与输出结果的因果关系 | **必须使用**：复杂条件依赖关系 |\n| 正交试验法 | 多因素多水平 | 用最少的试验覆盖最多的因素组合 | **必须使用**：多因素兼容性测试 |\n| 功能图法 | 功能组合测试 | 分析功能点的输入输出关系，生成功能测试用例 | **必须使用**：功能点组合覆盖 |\n\n### 方法应用要点\n\n**等价类划分法**：有效等价类（正常业务数据范围）、无效等价类（异常/边界/特殊数据）。划分依据：业务规则、数据类型、用户角色。示例：用户年龄输入（1-120有效，<1或>120无效）。\n\n**边界值分析法**：数值边界（最小值、最小值+1、最大值-1、最大值）、字符串边界（空、1字符、最大长度、最大长度+1）、日期边界（当天、前一天、后一天）。示例：密码长度8位（测试7位、8位、9位）。\n\n**场景法**：主成功场景（正常业务流程）、扩展场景（分支流程）、异常场景（错误处理流程）。示例：电商下单（浏览→加购→结算→支付→完成）。\n\n**判定表驱动法**：条件桩（所有输入条件）、动作桩（所有可能输出）、规则（条件组合与动作对应关系）。示例：登录（用户名正确/错误 × 密码正确/错误 → 不同结果）。\n\n**错误推测法**：基于经验（历史缺陷/常见错误模式）、基于直觉（测试人员经验判断）、基于领域知识（业务规则边界）。示例：输入框输入特殊字符/超长字符串/SQL注入语句。\n\n**因果图法**：原因（输入条件）、结果（输出结果）、关系（与/或/非逻辑）、约束（条件间依赖）。示例：优惠券使用条件（金额≥100且有券 → 可使用）。\n\n**正交试验法**：因素（测试变量）、水平（取值）、用例（最少组合覆盖最多因素）。示例：兼容性测试（3浏览器×3系统×3分辨率 → 正交表选9组）。\n\n**功能图法**：功能点（系统功能）、输入（条件）、输出（结果）、组合（调用关系）。示例：电商系统（登录→浏览→加购→结算→支付→功能组合测试）。\n\n## 复杂场景覆盖\n\n| 场景类型 | 测试重点 | 示例 |\n|----------|----------|------|\n| 页面跳转测试 | 跳转目标、参数传递、权限校验 | 列表跳详情页、菜单跳转、外部链接跳转 |\n| 路由参数测试 | 参数缺失、非法、越界处理 | URL参数传递、query参数、path参数 |\n| 跨页面联动 | 数据传递、状态同步、缓存一致性 | 订单页与用户页关联、购物车与结算页联动 |\n| 并发场景测试 | 多人同时操作、数据竞争 | 同时下单、库存并发扣减 |\n| 异常兜底测试 | 服务降级、熔断、重试机制 | 接口超时、服务不可用、网络异常 |\n\n### 页面跳转测试深度覆盖\n\n**测试要点**：跳转触发点、跳转目标页、跳转条件、异常跳转。检查：正常跳转目标正确、参数传递完整、权限校验拦截正确、404处理、空状态、浏览器回退、返回按钮、面包屑导航、外部跳转新标签页、循环跳转检测。\n\n### 路由参数测试深度覆盖\n\n**测试要点**：参数定义（query/path/hash）、格式（数据类型/长度限制）、传递方式（URL/session/cookie/localStorage）、验证（缺失/非法/越界/安全）。检查：参数存在性、类型、长度、格式、安全（SQL注入/XSS）、边界、组合、编码。\n\n### 跨页面联动测试深度覆盖\n\n**测试要点**：数据依赖（页面间数据关系）、状态同步（操作后更新）、缓存策略（刷新机制）、业务流程（完整闭环）。检查：数据传递正确、关联页面状态更新、缓存策略合理、消息通知跳转正确、业务闭环完整、多页面数据一致、操作反馈同步。\n\n## 常用测试方法速查\n\n**等价类划分示例**：年龄输入框（有效[1,120]，无效<1/>120/非数字）；状态下拉（有效[启用/禁用/冻结]，无效其他）。\n\n**边界值分析示例**：文件上传10MB（9MB/10MB/10.1MB）；文本框200字符（199/200/201字）；列表分页（第1页/最后1页/超出最大页码）。\n\n**判定表示例**：\n\n| 条件 | A(有优惠券) | B(满100元) | C(可用) | 结果 |\n|------|-------------|------------|---------|------|\n| 1 | Y | Y | Y | 可以使用 |\n| 2 | Y | Y | N | 不可用（已过期） |\n| 3 | Y | N | Y | 不可用（不满足门槛） |\n| 4 | N | Y/Y | Y/Y | 不适用 |\n\nFile v1.6.3:references/output-template-full.md\n\n# 测试用例字段模板与输出格式（完整版）\n\n> 本文件由 qa-test-case-design SKILL.md 拆分而来，按需加载。\n\n### 标准用例字段模板\n\n| 字段 | 说明 | 是否必填 |\n|------|------|----------|\n| 用例编号 | 唯一标识，便于追踪和管理 | ✅ 必填 |\n| 测试类型 | 功能/性能/安全/兼容性等 | ✅ 必填 |\n| 功能模块 | 所属的业务模块或系统组件 | ✅ 必填 |\n| 子功能 | 具体的功能点或操作场景 | ✅ 必填 |\n| 测试标题 | 简明扼要地描述测试目的 | ✅ 必填 |\n| 用例级别 | P0(关键)、P1(重要)、P2(一般)、P3(可选) | ✅ 必填 |\n| 预置条件 | 执行测试前必须满足的状态或数据准备 | ✅ 必填 |\n| 测试步骤 | 详细的操作步骤（留空，由用户补充） | ⚠️ 留空 |\n| 预期结果 | 每个步骤对应的预期产出或状态变化 | ✅ 必填 |\n| 实际结果 | 测试执行后的真实结果记录（留空） | ⚠️ 留空 |\n\n### 用例编号规则\n\n`TC_{模块缩写}_{功能序列号}_{场景后缀}`\n\n示例：\n- `TC_USER_LOGIN_001_NORMAL` - 用户模块 - 登录功能 - 第001条 - 正常场景\n- `TC_ORDER_DETAIL_002_JUMP` - 订单模块 - 详情页 - 第002条 - 跳转场景\n- `TC_PRODUCT_LINK_003_CROSS` - 商品模块 - 关联页面 - 第003条 - 跨页面联动\n\n### 用例级别定义\n\n| 级别 | 说明 | 适用场景 |\n|------|------|----------|\n| P0 | 关键用例 | 核心业务流程、阻碍系统正常使用的问题、主流程验证 |\n| P1 | 重要用例 | 主要功能、影响用户体验的问题、重要分支流程 |\n| P2 | 一般用例 | 次要功能、不影响主体流程的问题、异常场景 |\n| P3 | 可选用例 | 边缘场景、美化优化相关、极端异常情况 |\n\n> 详细的设计方法、覆盖策略和评审标准参见 `references/`：\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\n\n## 输出模板\n\n**重要：以下输出格式是固定的，必须严格遵守。**\n\n### 测试用例设计输出格式\n\n```markdown\n## 测试用例设计报告\n\n### 基本信息\n- 功能模块：[模块名称]\n- 设计日期：[日期]\n- 设计人员：[姓名]\n- 用例总数：[数量]\n\n### 用例统计\n| 级别 | 数量 | 占比 |\n|------|------|------|\n| P0 | [数量] | [百分比] |\n| P1 | [数量] | [百分比] |\n| P2 | [数量] | [百分比] |\n| P3 | [数量] | [百分比] |\n\n### 测试用例列表\n\n#### P0 关键用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_001 | [测试标题] | 功能测试 | 等价类划分法 | REQ-XXX-001 | [预期结果] |\n\n#### P1 重要用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_002 | [测试标题] | 功能测试 | 边界值分析法 | REQ-XXX-002 | [预期结果] |\n\n#### P2 一般用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_003 | [测试标题] | 异常测试 | 错误推测法 | REQ-XXX-003 | [预期结果] |\n\n#### P3 可选用例\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\n|----------|----------|----------|----------|------------|----------|\n| TC_XXX_004 | [测试标题] | 边界测试 | 边界值分析法 | REQ-XXX-004 | [预期结果] |\n\n### 覆盖率分析\n- 需求覆盖率：[百分比]\n- 功能覆盖率：[百分比]\n- 风险覆盖率：[百分比]\n\n### 测试建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\n### 单条用例输出格式\n\n```markdown\n## 测试用例\n\n### 基本信息\n- 用例编号：TC_XXX_001\n- 测试类型：功能测试\n- 功能模块：用户管理\n- 子功能：登录\n- 测试标题：验证正确的用户名和密码可以成功登录\n- 用例级别：P0\n- 需求追溯ID：REQ-AUTH-001\n- 测试方法：等价类划分法、边界值分析法\n\n### 预置条件\n1. 用户已注册\n2. 网络正常\n3. 服务正常运行\n4. 前置依赖：无\n\n### 测试步骤\n（留空，由用户根据实际系统补充）\n\n### 预期结果\n1. 跳转至首页\n2. 显示用户信息\n3. 登录状态保持正常\n\n### 实际结果\n（测试执行后填写）\n\n### 字段级验证（如适用）\n- 用户名字段：\n - 长度边界：1位、20位、21位\n - 格式校验：无特殊格式要求\n - 注入测试：SQL注入、XSS攻击\n - 特殊字符：空格、@、#等\n- 密码字段：\n - 长度边界：1位、8位、9位\n - 格式校验：至少8位，包含字母、数字、特殊字符\n - 注入测试：SQL注入、XSS攻击\n - 特殊字符：空格、@、#等\n```\n\nFile v1.6.3:references/review-standards.md\n\n# 需求文档要求与用例评审标准\n\n## 需求文档要求\n\n### 页面跳转、路由参数、跨页面联动场景的需求要求\n\n#### 1. 页面跳转需求要求\n- **跳转触发点**：明确哪些操作会触发页面跳转（按钮、链接、菜单等）\n- **跳转目标页**：明确跳转到哪个页面，页面标识（URL、页面名称等）\n- **跳转条件**：在什么条件下允许跳转（权限、数据状态等）\n- **跳转参数**：需要传递哪些参数（ID、类型、来源等）\n- **异常处理**：跳转失败时的处理方式（错误提示、回退逻辑等）\n\n#### 2. 路由参数需求要求\n- **参数定义**：明确URL中包含哪些参数（query参数、path参数等）\n- **参数格式**：参数的数据类型、格式要求、长度限制\n- **参数传递**：参数如何在页面间传递（URL、session、cookie等）\n- **参数验证**：参数缺失、非法、越界时的处理逻辑\n- **参数安全**：参数的权限控制、防篡改机制\n\n#### 3. 跨页面联动需求要求\n- **数据依赖**：页面间的数据依赖关系（哪些数据需要同步）\n- **状态同步**：页面状态变更后，其他页面如何同步更新\n- **缓存策略**：页面数据的缓存机制和刷新策略\n- **业务流程**：跨页面的完整业务流程描述\n- **异常处理**：联动失败时的处理方式（数据回滚、状态恢复等）\n\n#### 4. 需求文档质量要求\n- **完整性**：所有跳转、参数、联动场景都有明确描述\n- **一致性**：不同部分的需求描述不矛盾\n- **可测试性**：需求描述足够具体，可以设计测试用例\n- **无歧义**：需求描述清晰，没有多种理解方式\n\n### 需求文档检查清单\n\n- [ ] 所有页面跳转的触发条件和目标页面\n- [ ] 路由参数的定义、格式和传递规则\n- [ ] 跨页面数据依赖和状态同步机制\n- [ ] 异常场景的处理逻辑\n- [ ] 权限控制要求\n- [ ] 业务流程的完整描述\n\n### 需求不足时的处理\n\n如果需求文档信息不足，应该：标记缺失信息、提出澄清问题、基于经验假设（注明假设条件）、在测试报告中说明需求不足带来的测试风险。\n\n## 用例评审标准\n\n### 完整性检查\n- [ ] 是否覆盖所有需求点和隐性场景？\n- [ ] 主流程、分支流程、异常场景是否覆盖？\n- [ ] 边界条件、特殊数据是否覆盖？\n- [ ] 权限控制、安全场景是否覆盖？\n\n### 独立性检查\n- [ ] 用例之间是否存在强依赖关系？\n- [ ] 用例执行顺序是否影响结果？\n- [ ] 用例数据是否相互独立？\n\n### 可执行性检查\n- [ ] 预置条件是否明确可准备？\n- [ ] 预期结果是否客观可测量？\n- [ ] 测试标题是否准确反映测试目的？\n- [ ] 用例级别是否合理？\n\n### 可维护性检查\n- [ ] 用例编号是否规范？\n- [ ] 命名是否清晰一致？\n- [ ] 变更是否可追溯？\n\n### 评审通过标准\n\n1. ✅ **覆盖率达标**: 核心功能P0用例覆盖率100%\n2. ✅ **逻辑自洽**: 无矛盾或冲突的用例描述\n3. ✅ **可执行性**: 预期结果均可客观验证\n4. ✅ **边界覆盖**: 输入边界、异常场景均有对应用例\n5. ✅ **优先级合理**: P0用例不超过总数30%\n6. ✅ **格式规范**: 符合标准模板要求\n\nFile v1.6.3:skill-card.md\n\n## Description:\n\nTransforms completed QA analysis, including requirements, scenario trees, boundary lists, and combination matrices, into structured, prioritized, traceable test cases.\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, testers, and development teams use this skill to turn sufficiently analyzed requirements into standardized P0-P3 test-case reports with coverage notes, traceability IDs, expected results, and review guidance.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Users may need general QA discussion instead of full structured test-case generation.\n\nMitigation: Clarify whether the requested work is test-case generation, review, coverage analysis, or lightweight QA guidance before applying the full structure.\n\nRisk: Generated test cases can be generic or incomplete when requirements, scenarios, boundaries, or business context are missing.\n\nMitigation: Request missing inputs and clearly mark assumptions, missing information, and residual coverage risks in the output.\n\n## Reference(s):\n\n- [Test Coverage Strategy and Quality Standards](references/coverage-and-quality.md)\n- [Test Case Design Methods](references/design-methods.md)\n- [Full Test Case Output Template](references/output-template-full.md)\n- [Requirements Documentation and Test Case Review Standards](references/review-standards.md)\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Analysis, Guidance]\n\n**Output Format:** [Markdown test-case reports, tables, checklists, and structured guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Generates prioritized P0-P3 test cases with traceability IDs, expected results, coverage analysis, and risk notes; test steps are intentionally left for users to fill from the actual system.]\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: 7 files, 13702 bytes\n\nFiles: references/coverage-and-quality.md (3596b), references/design-methods.md (5605b), references/output-template-full.md (5123b), references/review-standards.md (3326b), skill-card.md (2303b), SKILL.md (9301b), _meta.json (138b)\n\nFile v1.6.0:SKILL.md\n\n---\r\nname: qa-test-case-design\r\nversion: 1.6.0\r\ndescription: >-\r\n 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。适用于将前面的分析产出物整合为 P0-P3 分级、可追溯的标准格式测试用例。\r\n\r\nwhen_to_use: 用户说\"设计测试用例\"、\"用例评审\"、\"用例覆盖\"、\"测试用例设计\"、\"用例模板\"、\"用例规范\"、\"用例格式\"、需要测试用例结构指导、需要编写或规范测试用例时\r\nallowed-tools: Read Grep Glob\r\nrelated_skills:\r\n upstream:\r\n - qa-req-deconstruction # 输入：需求解构结果\r\n - qa-boundary-deep-dive # 输入：边界分析结果\r\n - qa-scenario-tree # 输入：场景树构建结果\r\n downstream:\r\n - qa-test-skills # 输出：测试用例设计结果\r\n - qa-expert-review # 输出：用例评审反馈\r\n - qa-regression-testing\r\nreferences:\r\n - references/coverage-and-quality.md\r\n - references/design-methods.md\r\n - references/review-standards.md\r\ninput_format:\r\n required:\r\n - name: 需求描述\r\n type: string\r\n description: 功能需求的详细说明\r\n optional:\r\n - name: 场景分析\r\n type: object\r\n description: 来自qa-scenario-tree的场景树\r\n - name: 边界条件\r\n type: object\r\n description: 来自qa-boundary-deep-dive的边界分析结果\r\n - name: 业务背景\r\n type: string\r\n description: 业务目标和用户角色\r\noutput_format:\r\n structure:\r\n - test_case_id: \"TC_模块_功能_序列\"\r\n - test_type: \"功能/性能/安全/兼容性\"\r\n - priority: \"P0/P1/P2/P3\"\r\n - test_title: \"测试标题\"\r\n - preconditions: \"预置条件\"\r\n - test_steps: \"留空（用户补充）\"\r\n - expected_results: \"预期结果\"\r\n traceability:\r\n - 每个用例带唯一ID（TC-XXXX）\r\n - 关联需求ID（REQ-XXXX）\r\n - 关联场景ID（SC-XXXX）\r\ndepth_requirement_quantification:\r\n reference_value: \"根据需求复杂度调整用例设计深度：简单×2/中等×3/复杂×4\"\r\n minimum: \"用例总数不低于需求点的3倍\"\r\ncategories: ['Development','Testing']\r\nerror_recovery_guidance:\r\n on_failure: \"用例设计遗漏维度时回退到边界分析和场景树补充\"\r\n retry_behavior: \"补充上游后重新设计用例\"\r\n---\r\n# 高级测试用例设计专项\r\n\r\n## 核心原则\r\n\r\n测试用例设计的核心——明确\"测什么\"，而非\"怎么测\"。\r\n\r\n我们专注于：用例结构设计、场景覆盖策略、分类优先级、测试点识别组织。\r\n\r\n> **重要限制**：禁止读取代码——测试用例必须基于需求文档，不得读取代码实现。确保验证\"系统应该做什么\"，而非\"系统如何实现\"。\r\n>\r\n> 详细的设计方法、覆盖策略和评审标准参见 `references/` 目录：\r\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\r\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\r\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\r\n\r\n## 设计理念\r\n\r\n### 为什么测试步骤留空？\r\n\r\n```\r\n同一个\"登录\"功能，不同系统实现完全不同。\r\nAI不知道你们系统用的是哪种实现方式：\r\n- 强制生成步骤 → 步骤与实际不符 → 测试人员需要大量修正 → 增加工作量\r\n- 测试步骤留空 → 用户基于实际系统补充 → 只需补充细节 → 减少工作量\r\n```\r\n\r\n## 测试用例结构设计\r\n\r\n**重要：输出格式、用例分级、编号规则是固定的，必须严格遵守。**\r\n\r\n### 标准用例字段模板\r\n\r\n> 📖 完整的字段模板、用例编号规则、级别定义、输出格式和报告结构详见 [`references/output-template-full.md`](references/output-template-full.md)。\r\n>\r\n> 本节保留核心字段概览，详细模板按需加载以节省 context。\r\n\r\n## 使用方法\r\n\r\n### 触发场景\r\n\r\n当用户提供以下类型的请求时，此技能自动激活：\r\n\r\n1. **生成测试用例**：\"帮我设计用户登录功能的测试用例\"\r\n2. **完善用例**：\"这些测试用例不够全面，请补充异常场景\"\r\n3. **审查用例**：\"检查一下这些测试用例是否有遗漏\"\r\n4. **评审辅助**：\"我需要准备测试用例评审，生成一套完整的用例\"\r\n5. **覆盖优化**：\"这个功能还缺哪些测试场景\"\r\n6. **质量评估**：\"评估一下这些测试用例的质量\"\r\n\r\n### 输入要素\r\n\r\n为生成高质量的测试用例，尽量提供以下信息：\r\n\r\n1. **需求描述**：功能需求的详细说明\r\n2. **业务背景**：该功能在整体产品中的定位\r\n3. **约束条件**：技术限制、合规要求等\r\n4. **目标用户**：主要使用人群及其特征\r\n5. **关联系统**：涉及的其他模块或第三方服务\r\n6. **风险点**：已知的高风险区域\r\n7. **历史缺陷**：类似功能的历史问题\r\n\r\n### 输出内容\r\n\r\n1. **完整测试用例集**：涵盖所有识别出的测试点\r\n2. **测试优先级排序**：按P0-P3分级展示\r\n3. **覆盖率说明**：已覆盖的测试维度列表\r\n4. **缺失风险提示**：可能存在的测试盲区建议\r\n5. **测试建议**：针对测试执行的建议\r\n\r\n## 最佳实践\r\n\r\n### 用例设计原则\r\n\r\n✅ **DO - 推荐做法**\r\n- 每个用例只验证一个明确的目标\r\n- 使用清晰的数字序号标记预期结果\r\n- 预期结果使用\"应该/必须/会\"等确定性词汇\r\n- 包含正向和反向两种情况的验证\r\n- 标注敏感信息的脱敏处理方式\r\n- 为复杂场景添加截图或伪代码说明\r\n- 测试步骤留空，由用户根据实际系统补充\r\n\r\n❌ **DON'T - 避免做法**\r\n- 模糊的描述如\"检查是否可以正常工作\"\r\n- 一次性验证过多无关功能\r\n- 忽略前置条件和环境配置\r\n- 混合多个验证点在一个预期结果中\r\n- 使用主观判断代替客观测量\r\n- 忽略异常处理流程\r\n- 强制生成可能与实际不符的测试步骤\r\n\r\n### 用例评审要点\r\n\r\n1. **完整性检查**：是否覆盖所有需求点和隐性场景\r\n2. **独立性检查**：用例之间是否存在强依赖关系\r\n3. **可执行性检查**：预期结果是否清晰、客观可测量\r\n4. **可维护性检查**：命名规范、变更可追溯\r\n5. **优先级合理性**：P0用例是否真正关键\r\n6. **覆盖全面性**：功能、数据、权限、集成是否覆盖\r\n\r\n## 输出示例\r\n\r\n### 示例1：电商下单功能测试用例设计\r\n\r\n```markdown\r\n## 订单模块 - 商品下单 - P0\r\n\r\n### TC_ORDER_CREATE_001 正常下单流程\r\n\r\n**测试类型**: 功能测试\r\n**功能模块**: 订单管理\r\n**子功能**: 商品下单\r\n**用例级别**: P0\r\n**预置条件**:\r\n1. 用户已登录且账户余额充足\r\n2. 商品库存大于0\r\n3. 收货地址已配置\r\n\r\n**测试步骤**:\r\n（留空，由用户根据实际系统补充）\r\n\r\n**预期结果**:\r\n1. 进入订单确认页\r\n2. 订单金额计算准确（含运费优惠）\r\n3. 订单创建成功，返回订单号\r\n4. 库存扣减正确\r\n5. 收到订单confirmation通知\r\n\r\n**实际结果**: 待执行\r\n```\r\n\r\n### 示例2：用户注册功能异常场景\r\n\r\n```markdown\r\n## 用户模块 - 注册 - P1\r\n\r\n### TC_USER_REGISTER_002 邮箱格式错误\r\n\r\n**测试类型**: 功能测试\r\n**功能模块**: 用户管理\r\n**子功能**: 用户注册\r\n**用例级别**: P1\r\n**预置条件**: 访问注册页面\r\n\r\n**测试步骤**:\r\n（留空，由用户根据实际系统补充）\r\n\r\n**预期结果**:\r\n1. 邮箱字段显示红色错误提示\r\n2. 提示内容明确告知格式要求\r\n3. 无法继续提交表单\r\n4. 控制台无报错日志\r\n\r\n**实际结果**: 待执行\r\n```\r\n\r\n### 示例3：页面跳转测试用例设计\r\n\r\n```markdown\r\n## 商品模块 - 列表跳详情 - P0\r\n\r\n### TC_PRODUCT_LIST_001 正常跳转详情页\r\n\r\n**测试类型**: 功能测试\r\n**功能模块**: 商品管理\r\n**子功能**: 列表跳详情\r\n**用例级别**: P0\r\n**预置条件**:\r\n1. 用户已登录\r\n2. 商品列表页有数据\r\n\r\n**测试步骤**:\r\n（留空，由用户根据实际系统补充）\r\n\r\n**预期结果**:\r\n1. 成功跳转到商品详情页\r\n2. URL包含正确的商品ID（如/product/12345）\r\n3. 详情页展示的商品信息与列表一致\r\n4. 商品图片、价格、库存等关键信息正确\r\n5. 详情页功能按钮（购买、收藏等）可用\r\n\r\n**实际结果**: 待执行\r\n```\r\n\r\n## 检查清单\r\n\r\n测试用例设计完成后检查：\r\n- [ ] 是否覆盖了所有需求点和隐性场景？\r\n- [ ] 是否包含了正常、异常、边界三种场景？\r\n- [ ] 每条用例是否只验证一个明确目标？\r\n- [ ] 预期结果是否可客观验证？\r\n- [ ] 用例优先级（P0-P3）是否合理？\r\n\r\n## 参考资源\r\n\r\n- `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\r\n- `references/coverage-and-quality.md` — 覆盖维度 + 覆盖评估 + 质量指标\r\n- `references/review-standards.md` — 需求文档要求 + 用例评审标准\r\n- ISTQB测试术语标准 / ISO/IEC/IEEE 29119 / Google Testing Blog\n\nFile v1.6.0:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-test-case-design\",\n \"version\": \"1.6.0\",\n \"publishedAt\": 1783358317674\n}\n\nFile v1.6.0:references/coverage-and-quality.md\n\n# 测试覆盖策略与质量标准\n\n## 覆盖维度\n\n```\n测试覆盖：\n├─ 功能覆盖\n│ ├─ 主流程覆盖：核心业务流程是否完整测试\n│ ├─ 分支流程覆盖：各种条件分支路径是否覆盖\n│ ├─ 异常场景覆盖：错误输入、异常操作是否测试\n│ ├─ 边界条件覆盖：输入范围边界、数量边界是否测试\n│ ├─ 退出流程覆盖：退出登录、注销、超时退出等场景\n│ └─ 状态转换覆盖：系统状态变化是否测试\n│\n├─ 数据覆盖\n│ ├─ 有效数据覆盖：正常数据是否测试\n│ ├─ 无效数据覆盖：异常数据是否测试\n│ ├─ 边界数据覆盖：边界值数据是否测试\n│ ├─ 特殊数据覆盖：特殊字符、超长数据是否测试\n│ ├─ 格式校验覆盖：邮箱、手机号、身份证等格式验证\n│ └─ 注入测试覆盖：SQL注入、XSS攻击等安全测试\n│\n├─ 字段级验证覆盖（每个表单字段必须测试）\n│ ├─ 长度边界：1位、最大长度、最大长度+1\n│ ├─ 格式校验：正则表达式验证（邮箱、手机号、身份证等）\n│ ├─ 注入测试：SQL注入、XSS攻击、命令注入\n│ ├─ 特殊字符：空格、特殊符号、Unicode字符\n│ ├─ 空值处理：必填字段为空、选填字段为空\n│ └─ 默认值：字段默认值是否正确\n│\n├─ 权限覆盖\n│ ├─ 角色权限覆盖：不同角色权限是否测试\n│ ├─ 越权访问覆盖：越权操作是否拦截\n│ ├─ 数据权限覆盖：数据隔离是否验证\n│ ├─ 功能权限覆盖：功能访问控制是否测试\n│ ├─ CSRF防护覆盖：跨站请求伪造防护是否测试\n│ └─ 路径遍历覆盖：目录遍历攻击防护是否测试\n│\n├─ 集成覆盖\n│ ├─ 模块集成覆盖：模块间协作是否测试\n│ ├─ 接口集成覆盖：接口调用是否测试\n│ ├─ 数据集成覆盖：数据流转是否测试\n│ └─ 异常集成覆盖：异常处理是否测试\n│\n└─ 非功能覆盖\n ├─ 性能覆盖：响应时间、吞吐量、并发性能是否测试\n ├─ 兼容性覆盖：浏览器、操作系统、设备兼容性是否测试\n ├─ 可用性覆盖：用户体验、易用性是否测试\n ├─ 安全性覆盖：数据加密、传输安全是否测试\n └─ 可靠性覆盖：稳定性、容错性是否测试\n```\n\n### 覆盖率评估\n\n| 覆盖率类型 | 计算方式 | 目标值 |\n|------------|----------|--------|\n| 需求覆盖率 | 已测需求点 / 总需求点 × 100% | ≥95% |\n| 功能覆盖率 | 已测功能点 / 总功能点 × 100% | ≥90% |\n| 用例覆盖率 | 已执行用例 / 总用例 × 100% | ≥100% |\n| 缺陷覆盖率 | 已修复缺陷 / 总缺陷 × 100% | ≥90% |\n\n## 质量保证标准\n\n### 用例质量指标\n\n| 指标 | 计算方式 | 目标值 |\n|------|----------|--------|\n| 用例有效性 | 有效用例数 / 总用例数 × 100% | ≥95% |\n| 用例执行率 | 已执行用例数 / 总用例数 × 100% | ≥100% |\n| 用例通过率 | 通过用例数 / 已执行用例数 × 100% | ≥98% |\n| 缺陷发现率 | 缺陷数 / 用例数 × 100% | 持续优化 |\n\n### 交付质量标准\n\n- 用例总数不低于需求点的3倍（包含异常场景）\n- P0+P1用例占比不低于60%\n- 每条用例平均预期结果3-5条\n- 无空洞描述，预期结果均可客观验证\n- 符合企业测试管理规范格式要求\n- 测试步骤留空，由用户根据实际系统补充\n\nFile v1.6.0:references/design-methods.md\n\n# 用例设计方法参考\n\n## 常用设计方法\n\n| 方法 | 适用场景 | 说明 | 必用场景 |\n|------|----------|------|----------|\n| 等价类划分法 | 输入域测试 | 将输入域划分为有效/无效等价类，减少冗余用例 | 所有输入字段 |\n| 边界值分析法 | 边界测试 | 针对边界情况设计专项测试，发现常见错误 | 所有有边界限制的字段 |\n| 场景法 | 业务流程测试 | 基于用户业务流程构建端到端测试场景 | 核心业务流程 |\n| 判定表驱动法 | 多条件组合 | 穷举所有条件组合可能性 | **必须使用**：多条件组合场景 |\n| 错误推测法 | 经验驱动 | 基于历史缺陷数据和开发经验预测潜在问题 | **必须使用**：异常场景覆盖 |\n| 风险驱动测试 | 风险优先 | 优先覆盖高风险区域和高频使用场景 | 高风险功能 |\n| 状态转换法 | 状态机测试 | 测试状态机的合法/非法转换 | 有状态变化的功能 |\n| 因果图法 | 复杂条件组合 | 分析输入条件与输出结果的因果关系 | **必须使用**：复杂条件依赖关系 |\n| 正交试验法 | 多因素多水平 | 用最少的试验覆盖最多的因素组合 | **必须使用**：多因素兼容性测试 |\n| 功能图法 | 功能组合测试 | 分析功能点的输入输出关系，生成功能测试用例 | **必须使用**：功能点组合覆盖 |\n\n### 方法应用要点\n\n**等价类划分法**：有效等价类（正常业务数据范围）、无效等价类（异常/边界/特殊数据）。划分依据：业务规则、数据类型、用户角色。示例：用户年龄输入（1-120有效，<1或>120无效）。\n\n**边界值分析法**：数值边界（最小值、最小值+1、最大值-1、最大值）、字符串边界（空、1字符、最大长度、最大长度+1）、日期边界（当天、前一天、后一天）。示例：密码长度8位（测试7位、8位、9位）。\n\n**场景法**：主成功场景（正常业务流程）、扩展场景（分支流程）、异常场景（错误处理流程）。示例：电商下单（浏览→加购→结算→支付→完成）。\n\n**判定表驱动法**：条件桩（所有输入条件）、动作桩（所有可能输出）、规则（条件组合与动作对应关系）。示例：登录（用户名正确/错误 × 密码正确/错误 → 不同结果）。\n\n**错误推测法**：基于经验（历史缺陷/常见错误模式）、基于直觉（测试人员经验判断）、基于领域知识（业务规则边界）。示例：输入框输入特殊字符/超长字符串/SQL注入语句。\n\n**因果图法**：原因（输入条件）、结果（输出结果）、关系（与/或/非逻辑）、约束（条件间依赖）。示例：优惠券使用条件（金额≥100且有券 → 可使用）。\n\n**正交试验法**：因素（测试变量）、水平（取值）、用例（最少组合覆盖最多因素）。示例：兼容性测试（3浏览器×3系统×3分辨率 → 正交表选9组）。\n\n**功能图法**：功能点（系统功能）、输入（条件）、输出（结果）、组合（调用关系）。示例：电商系统（登录→浏览→加购→结算→支付→功能组合测试）。\n\n## 复杂场景覆盖\n\n| 场景类型 | 测试重点 | 示例 |\n|----------|----------|------|\n| 页面跳转测试 | 跳转目标、参数传递、权限校验 | 列表跳详情页、菜单跳转、外部链接跳转 |\n| 路由参数测试 | 参数缺失、非法、越界处理 | URL参数传递、query参数、path参数 |\n| 跨页面联动 | 数据传递、状态同步、缓存一致性 | 订单页与用户页关联、购物车与结算页联动 |\n| 并发场景测试 | 多人同时操作、数据竞争 | 同时下单、库存并发扣减 |\n| 异常兜底测试 | 服务降级、熔断、重试机制 | 接口超时、服务不可用、网络异常 |\n\n### 页面跳转测试深度覆盖\n\n**测试要点**：跳转触发点、跳转目标页、跳转条件、异常跳转。检查：正常跳转目标正确、参数传递完整、权限校验拦截正确、404处理、空状态、浏览器回退、返回按钮、面包屑导航、外部跳转新标签页、循环跳转检测。\n\n### 路由参数测试深度覆盖\n\n**测试要点**：参数定义（query/path/hash）、格式（数据类型/长度限制）、传递方式（URL/session/cookie/localStorage）、验证（缺失/非法/越界/安全）。检查：参数存在性、类型、长度、格式、安全（SQL注入/XSS）、边界、组合、编码。\n\n### 跨页面联动测试深度覆盖\n\n**测试要点**：数据依赖（页面间数据关系）、状态同步（操作后更新）、缓存策略（刷新机制）、业务流程（完整闭环）。检查：数据传递正确、关联页面状态更新、缓存策略合理、消息通知跳转正确、业务闭环完整、多页面数据一致、操作反馈同步。\n\n## 常用测试方法速查\n\n**等价类划分示例**：年龄输入框（有效[1,120]，无效<1/>120/非数字）；状态下拉（有效[启用/禁用/冻结]，无效其他）。\n\n**边界值分析示例**：文件上传10MB（9MB/10MB/10.1MB）；文本框200字符（199/200/201字）；列表分页（第1页/最后1页/超出最大页码）。\n\n**判定表示例**：\n\n| 条件 | A(有优惠券) | B(满100元) | C(可用) | 结果 |\n|------|-------------|------------|---------|------|\n| 1 | Y | Y | Y | 可以使用 |\n| 2 | Y | Y | N | 不可用（已过期） |\n| 3 | Y | N | Y | 不可用（不满足门槛） |\n| 4 | N | Y/Y | Y/Y | 不适用 |\n\nFile v1.6.0:references/output-template-full.md\n\n# 测试用例字段模板与输出格式（完整版）\r\n\r\n> 本文件由 qa-test-case-design SKILL.md 拆分而来，按需加载。\r\n\r\n### 标准用例字段模板\r\n\r\n| 字段 | 说明 | 是否必填 |\r\n|------|------|----------|\r\n| 用例编号 | 唯一标识，便于追踪和管理 | ✅ 必填 |\r\n| 测试类型 | 功能/性能/安全/兼容性等 | ✅ 必填 |\r\n| 功能模块 | 所属的业务模块或系统组件 | ✅ 必填 |\r\n| 子功能 | 具体的功能点或操作场景 | ✅ 必填 |\r\n| 测试标题 | 简明扼要地描述测试目的 | ✅ 必填 |\r\n| 用例级别 | P0(关键)、P1(重要)、P2(一般)、P3(可选) | ✅ 必填 |\r\n| 预置条件 | 执行测试前必须满足的状态或数据准备 | ✅ 必填 |\r\n| 测试步骤 | 详细的操作步骤（留空，由用户补充） | ⚠️ 留空 |\r\n| 预期结果 | 每个步骤对应的预期产出或状态变化 | ✅ 必填 |\r\n| 实际结果 | 测试执行后的真实结果记录（留空） | ⚠️ 留空 |\r\n\r\n### 用例编号规则\r\n\r\n`TC_{模块缩写}_{功能序列号}_{场景后缀}`\r\n\r\n示例：\r\n- `TC_USER_LOGIN_001_NORMAL` - 用户模块 - 登录功能 - 第001条 - 正常场景\r\n- `TC_ORDER_DETAIL_002_JUMP` - 订单模块 - 详情页 - 第002条 - 跳转场景\r\n- `TC_PRODUCT_LINK_003_CROSS` - 商品模块 - 关联页面 - 第003条 - 跨页面联动\r\n\r\n### 用例级别定义\r\n\r\n| 级别 | 说明 | 适用场景 |\r\n|------|------|----------|\r\n| P0 | 关键用例 | 核心业务流程、阻碍系统正常使用的问题、主流程验证 |\r\n| P1 | 重要用例 | 主要功能、影响用户体验的问题、重要分支流程 |\r\n| P2 | 一般用例 | 次要功能、不影响主体流程的问题、异常场景 |\r\n| P3 | 可选用例 | 边缘场景、美化优化相关、极端异常情况 |\r\n\r\n> 详细的设计方法、覆盖策略和评审标准参见 `references/`：\r\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\r\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\r\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\r\n\r\n## 输出模板\r\n\r\n**重要：以下输出格式是固定的，必须严格遵守。**\r\n\r\n### 测试用例设计输出格式\r\n\r\n```markdown\r\n## 测试用例设计报告\r\n\r\n### 基本信息\r\n- 功能模块：[模块名称]\r\n- 设计日期：[日期]\r\n- 设计人员：[姓名]\r\n- 用例总数：[数量]\r\n\r\n### 用例统计\r\n| 级别 | 数量 | 占比 |\r\n|------|------|------|\r\n| P0 | [数量] | [百分比] |\r\n| P1 | [数量] | [百分比] |\r\n| P2 | [数量] | [百分比] |\r\n| P3 | [数量] | [百分比] |\r\n\r\n### 测试用例列表\r\n\r\n#### P0 关键用例\r\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\r\n|----------|----------|----------|----------|------------|----------|\r\n| TC_XXX_001 | [测试标题] | 功能测试 | 等价类划分法 | REQ-XXX-001 | [预期结果] |\r\n\r\n#### P1 重要用例\r\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\r\n|----------|----------|----------|----------|------------|----------|\r\n| TC_XXX_002 | [测试标题] | 功能测试 | 边界值分析法 | REQ-XXX-002 | [预期结果] |\r\n\r\n#### P2 一般用例\r\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\r\n|----------|----------|----------|----------|------------|----------|\r\n| TC_XXX_003 | [测试标题] | 异常测试 | 错误推测法 | REQ-XXX-003 | [预期结果] |\r\n\r\n#### P3 可选用例\r\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\r\n|----------|----------|----------|----------|------------|----------|\r\n| TC_XXX_004 | [测试标题] | 边界测试 | 边界值分析法 | REQ-XXX-004 | [预期结果] |\r\n\r\n### 覆盖率分析\r\n- 需求覆盖率：[百分比]\r\n- 功能覆盖率：[百分比]\r\n- 风险覆盖率：[百分比]\r\n\r\n### 测试建议\r\n1. [建议1]\r\n2. [建议2]\r\n3. [建议3]\r\n```\r\n\r\n### 单条用例输出格式\r\n\r\n```markdown\r\n## 测试用例\r\n\r\n### 基本信息\r\n- 用例编号：TC_XXX_001\r\n- 测试类型：功能测试\r\n- 功能模块：用户管理\r\n- 子功能：登录\r\n- 测试标题：验证正确的用户名和密码可以成功登录\r\n- 用例级别：P0\r\n- 需求追溯ID：REQ-AUTH-001\r\n- 测试方法：等价类划分法、边界值分析法\r\n\r\n### 预置条件\r\n1. 用户已注册\r\n2. 网络正常\r\n3. 服务正常运行\r\n4. 前置依赖：无\r\n\r\n### 测试步骤\r\n（留空，由用户根据实际系统补充）\r\n\r\n### 预期结果\r\n1. 跳转至首页\r\n2. 显示用户信息\r\n3. 登录状态保持正常\r\n\r\n### 实际结果\r\n（测试执行后填写）\r\n\r\n### 字段级验证（如适用）\r\n- 用户名字段：\r\n - 长度边界：1位、20位、21位\r\n - 格式校验：无特殊格式要求\r\n - 注入测试：SQL注入、XSS攻击\r\n - 特殊字符：空格、@、#等\r\n- 密码字段：\r\n - 长度边界：1位、8位、9位\r\n - 格式校验：至少8位，包含字母、数字、特殊字符\r\n - 注入测试：SQL注入、XSS攻击\r\n - 特殊字符：空格、@、#等\r\n```\n\nFile v1.6.0:references/review-standards.md\n\n# 需求文档要求与用例评审标准\n\n## 需求文档要求\n\n### 页面跳转、路由参数、跨页面联动场景的需求要求\n\n#### 1. 页面跳转需求要求\n- **跳转触发点**：明确哪些操作会触发页面跳转（按钮、链接、菜单等）\n- **跳转目标页**：明确跳转到哪个页面，页面标识（URL、页面名称等）\n- **跳转条件**：在什么条件下允许跳转（权限、数据状态等）\n- **跳转参数**：需要传递哪些参数（ID、类型、来源等）\n- **异常处理**：跳转失败时的处理方式（错误提示、回退逻辑等）\n\n#### 2. 路由参数需求要求\n- **参数定义**：明确URL中包含哪些参数（query参数、path参数等）\n- **参数格式**：参数的数据类型、格式要求、长度限制\n- **参数传递**：参数如何在页面间传递（URL、session、cookie等）\n- **参数验证**：参数缺失、非法、越界时的处理逻辑\n- **参数安全**：参数的权限控制、防篡改机制\n\n#### 3. 跨页面联动需求要求\n- **数据依赖**：页面间的数据依赖关系（哪些数据需要同步）\n- **状态同步**：页面状态变更后，其他页面如何同步更新\n- **缓存策略**：页面数据的缓存机制和刷新策略\n- **业务流程**：跨页面的完整业务流程描述\n- **异常处理**：联动失败时的处理方式（数据回滚、状态恢复等）\n\n#### 4. 需求文档质量要求\n- **完整性**：所有跳转、参数、联动场景都有明确描述\n- **一致性**：不同部分的需求描述不矛盾\n- **可测试性**：需求描述足够具体，可以设计测试用例\n- **无歧义**：需求描述清晰，没有多种理解方式\n\n### 需求文档检查清单\n\n- [ ] 所有页面跳转的触发条件和目标页面\n- [ ] 路由参数的定义、格式和传递规则\n- [ ] 跨页面数据依赖和状态同步机制\n- [ ] 异常场景的处理逻辑\n- [ ] 权限控制要求\n- [ ] 业务流程的完整描述\n\n### 需求不足时的处理\n\n如果需求文档信息不足，应该：标记缺失信息、提出澄清问题、基于经验假设（注明假设条件）、在测试报告中说明需求不足带来的测试风险。\n\n## 用例评审标准\n\n### 完整性检查\n- [ ] 是否覆盖所有需求点和隐性场景？\n- [ ] 主流程、分支流程、异常场景是否覆盖？\n- [ ] 边界条件、特殊数据是否覆盖？\n- [ ] 权限控制、安全场景是否覆盖？\n\n### 独立性检查\n- [ ] 用例之间是否存在强依赖关系？\n- [ ] 用例执行顺序是否影响结果？\n- [ ] 用例数据是否相互独立？\n\n### 可执行性检查\n- [ ] 预置条件是否明确可准备？\n- [ ] 预期结果是否客观可测量？\n- [ ] 测试标题是否准确反映测试目的？\n- [ ] 用例级别是否合理？\n\n### 可维护性检查\n- [ ] 用例编号是否规范？\n- [ ] 命名是否清晰一致？\n- [ ] 变更是否可追溯？\n\n### 评审通过标准\n\n1. ✅ **覆盖率达标**: 核心功能P0用例覆盖率100%\n2. ✅ **逻辑自洽**: 无矛盾或冲突的用例描述\n3. ✅ **可执行性**: 预期结果均可客观验证\n4. ✅ **边界覆盖**: 输入边界、异常场景均有对应用例\n5. ✅ **优先级合理**: P0用例不超过总数30%\n6. ✅ **格式规范**: 符合标准模板要求\n\nFile v1.6.0:skill-card.md\n\n## Description:
\nTransforms completed QA analysis inputs into structured, prioritized, traceable test case designs with coverage notes and review guidance.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[kokxi](https://clawhub.ai/user/kokxi)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nQA engineers, developers, and test leads use this skill after requirements, scenario, boundary, or combination analysis to turn those inputs into P0-P3 test case sets with traceability, coverage summaries, and review-ready expected results.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Broad trigger phrases may activate the skill before enough upstream QA analysis is available.
\nMitigation: Provide clear requirements and, when possible, completed scenario, boundary, or combination analysis before using the generated case design.
\nRisk: Generated test cases can miss product-specific details or include assumptions that do not match the target system.
\nMitigation: Have a QA owner review the cases, fill in system-specific test steps, and verify traceability and coverage before execution.
\n\n\n## Reference(s):
\n- [ClawHub Skill Page](https://clawhub.ai/kokxi/skills/qa-test-case-design)
\n- [Coverage and Quality Standards](references/coverage-and-quality.md)
\n- [Design Methods Reference](references/design-methods.md)
\n- [Output Template](references/output-template-full.md)
\n- [Review Standards](references/review-standards.md)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, guidance]
\n**Output Format:** [Markdown reports and tables with structured test case fields]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Leaves test steps for the user to complete and emphasizes requirement-based design rather than code inspection.]
\n\n## Skill Version(s):
\n1.6.0 (source: frontmatter and server release evidence)
\n\n## Ethical Considerations:
\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.5.0: 6 files, 12800 bytes\n\nFiles: references/coverage-and-quality.md (3596b), references/design-methods.md (5605b), references/review-standards.md (3326b), skill-card.md (2763b), SKILL.md (13772b), _meta.json (138b)\n\nFile v1.5.0:SKILL.md\n\n---\r\nname: qa-test-case-design\r\nversion: 1.5.0\r\ndescription: >-\r\n 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。适用于将前面的分析产出物整合为 P0-P3 分级、可追溯的标准格式测试用例。\r\n\r\nwhen_to_use: 用户说\"设计测试用例\"、\"用例评审\"、\"用例覆盖\"、\"测试用例设计\"、\"用例模板\"、\"用例规范\"、\"用例格式\"、需要测试用例结构指导、需要编写或规范测试用例时\r\nallowed-tools: Read Grep Glob\r\nrelated_skills:\r\n upstream:\r\n - qa-req-deconstruction # 输入：需求解构结果\r\n - qa-boundary-deep-dive # 输入：边界分析结果\r\n - qa-scenario-tree # 输入：场景树构建结果\r\n downstream:\r\n - qa-test-skills # 输出：测试用例设计结果\r\n - qa-expert-review # 输出：用例评审反馈\r\ninput_format:\r\n required:\r\n - name: 需求描述\r\n type: string\r\n description: 功能需求的详细说明\r\n optional:\r\n - name: 场景分析\r\n type: object\r\n description: 来自qa-scenario-tree的场景树\r\n - name: 边界条件\r\n type: object\r\n description: 来自qa-boundary-deep-dive的边界分析结果\r\n - name: 业务背景\r\n type: string\r\n description: 业务目标和用户角色\r\noutput_format:\r\n structure:\r\n - test_case_id: \"TC_模块_功能_序列\"\r\n - test_type: \"功能/性能/安全/兼容性\"\r\n - priority: \"P0/P1/P2/P3\"\r\n - test_title: \"测试标题\"\r\n - preconditions: \"预置条件\"\r\n - test_steps: \"留空（用户补充）\"\r\n - expected_results: \"预期结果\"\r\n traceability:\r\n - 每个用例带唯一ID（TC-XXXX）\r\n - 关联需求ID（REQ-XXXX）\r\n - 关联场景ID（SC-XXXX）\r\ndepth_requirement_quantification:\r\n reference_value: \"根据需求复杂度调整用例设计深度：简单×2/中等×3/复杂×4\"\r\n minimum: \"用例总数不低于需求点的3倍\"\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> 详细的设计方法、覆盖策略和评审标准参见 `references/` 目录：\r\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\r\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\r\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\r\n\r\n## 设计理念\r\n\r\n### 为什么测试步骤留空？\r\n\r\n```\r\n同一个\"登录\"功能，不同系统实现完全不同。\r\nAI不知道你们系统用的是哪种实现方式：\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| 测试标题 | 简明扼要地描述测试目的 | ✅ 必填 |\r\n| 用例级别 | P0(关键)、P1(重要)、P2(一般)、P3(可选) | ✅ 必填 |\r\n| 预置条件 | 执行测试前必须满足的状态或数据准备 | ✅ 必填 |\r\n| 测试步骤 | 详细的操作步骤（留空，由用户补充） | ⚠️ 留空 |\r\n| 预期结果 | 每个步骤对应的预期产出或状态变化 | ✅ 必填 |\r\n| 实际结果 | 测试执行后的真实结果记录（留空） | ⚠️ 留空 |\r\n\r\n### 用例编号规则\r\n\r\n`TC_{模块缩写}_{功能序列号}_{场景后缀}`\r\n\r\n示例：\r\n- `TC_USER_LOGIN_001_NORMAL` - 用户模块 - 登录功能 - 第001条 - 正常场景\r\n- `TC_ORDER_DETAIL_002_JUMP` - 订单模块 - 详情页 - 第002条 - 跳转场景\r\n- `TC_PRODUCT_LINK_003_CROSS` - 商品模块 - 关联页面 - 第003条 - 跨页面联动\r\n\r\n### 用例级别定义\r\n\r\n| 级别 | 说明 | 适用场景 |\r\n|------|------|----------|\r\n| P0 | 关键用例 | 核心业务流程、阻碍系统正常使用的问题、主流程验证 |\r\n| P1 | 重要用例 | 主要功能、影响用户体验的问题、重要分支流程 |\r\n| P2 | 一般用例 | 次要功能、不影响主体流程的问题、异常场景 |\r\n| P3 | 可选用例 | 边缘场景、美化优化相关、极端异常情况 |\r\n\r\n> 详细的设计方法、覆盖策略和评审标准参见 `references/`：\r\n> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\r\n> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标\r\n> - `references/review-standards.md` — 需求文档要求 + 评审标准\r\n\r\n## 输出模板\r\n\r\n**重要：以下输出格式是固定的，必须严格遵守。**\r\n\r\n### 测试用例设计输出格式\r\n\r\n```markdown\r\n## 测试用例设计报告\r\n\r\n### 基本信息\r\n- 功能模块：[模块名称]\r\n- 设计日期：[日期]\r\n- 设计人员：[姓名]\r\n- 用例总数：[数量]\r\n\r\n### 用例统计\r\n| 级别 | 数量 | 占比 |\r\n|------|------|------|\r\n| P0 | [数量] | [百分比] |\r\n| P1 | [数量] | [百分比] |\r\n| P2 | [数量] | [百分比] |\r\n| P3 | [数量] | [百分比] |\r\n\r\n### 测试用例列表\r\n\r\n#### P0 关键用例\r\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\r\n|----------|----------|----------|----------|------------|----------|\r\n| TC_XXX_001 | [测试标题] | 功能测试 | 等价类划分法 | REQ-XXX-001 | [预期结果] |\r\n\r\n#### P1 重要用例\r\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\r\n|----------|----------|----------|----------|------------|----------|\r\n| TC_XXX_002 | [测试标题] | 功能测试 | 边界值分析法 | REQ-XXX-002 | [预期结果] |\r\n\r\n#### P2 一般用例\r\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\r\n|----------|----------|----------|----------|------------|----------|\r\n| TC_XXX_003 | [测试标题] | 异常测试 | 错误推测法 | REQ-XXX-003 | [预期结果] |\r\n\r\n#### P3 可选用例\r\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\r\n|----------|----------|----------|----------|------------|----------|\r\n| TC_XXX_004 | [测试标题] | 边界测试 | 边界值分析法 | REQ-XXX-004 | [预期结果] |\r\n\r\n### 覆盖率分析\r\n- 需求覆盖率：[百分比]\r\n- 功能覆盖率：[百分比]\r\n- 风险覆盖率：[百分比]\r\n\r\n### 测试建议\r\n1. [建议1]\r\n2. [建议2]\r\n3. [建议3]\r\n```\r\n\r\n### 单条用例输出格式\r\n\r\n```markdown\r\n## 测试用例\r\n\r\n### 基本信息\r\n- 用例编号：TC_XXX_001\r\n- 测试类型：功能测试\r\n- 功能模块：用户管理\r\n- 子功能：登录\r\n- 测试标题：验证正确的用户名和密码可以成功登录\r\n- 用例级别：P0\r\n- 需求追溯ID：REQ-AUTH-001\r\n- 测试方法：等价类划分法、边界值分析法\r\n\r\n### 预置条件\r\n1. 用户已注册\r\n2. 网络正常\r\n3. 服务正常运行\r\n4. 前置依赖：无\r\n\r\n### 测试步骤\r\n（留空，由用户根据实际系统补充）\r\n\r\n### 预期结果\r\n1. 跳转至首页\r\n2. 显示用户信息\r\n3. 登录状态保持正常\r\n\r\n### 实际结果\r\n（测试执行后填写）\r\n\r\n### 字段级验证（如适用）\r\n- 用户名字段：\r\n - 长度边界：1位、20位、21位\r\n - 格式校验：无特殊格式要求\r\n - 注入测试：SQL注入、XSS攻击\r\n - 特殊字符：空格、@、#等\r\n- 密码字段：\r\n - 长度边界：1位、8位、9位\r\n - 格式校验：至少8位，包含字母、数字、特殊字符\r\n - 注入测试：SQL注入、XSS攻击\r\n - 特殊字符：空格、@、#等\r\n```\r\n\r\n## 使用方法\r\n\r\n### 触发场景\r\n\r\n当用户提供以下类型的请求时，此技能自动激活：\r\n\r\n1. **生成测试用例**：\"帮我设计用户登录功能的测试用例\"\r\n2. **完善用例**：\"这些测试用例不够全面，请补充异常场景\"\r\n3. **审查用例**：\"检查一下这些测试用例是否有遗漏\"\r\n4. **评审辅助**：\"我需要准备测试用例评审，生成一套完整的用例\"\r\n5. **覆盖优化**：\"这个功能还缺哪些测试场景\"\r\n6. **质量评估**：\"评估一下这些测试用例的质量\"\r\n\r\n### 输入要素\r\n\r\n为生成高质量的测试用例，尽量提供以下信息：\r\n\r\n1. **需求描述**：功能需求的详细说明\r\n2. **业务背景**：该功能在整体产品中的定位\r\n3. **约束条件**：技术限制、合规要求等\r\n4. **目标用户**：主要使用人群及其特征\r\n5. **关联系统**：涉及的其他模块或第三方服务\r\n6. **风险点**：已知的高风险区域\r\n7. **历史缺陷**：类似功能的历史问题\r\n\r\n### 输出内容\r\n\r\n1. **完整测试用例集**：涵盖所有识别出的测试点\r\n2. **测试优先级排序**：按P0-P3分级展示\r\n3. **覆盖率说明**：已覆盖的测试维度列表\r\n4. **缺失风险提示**：可能存在的测试盲区建议\r\n5. **测试建议**：针对测试执行的建议\r\n\r\n## 最佳实践\r\n\r\n### 用例设计原则\r\n\r\n✅ **DO - 推荐做法**\r\n- 每个用例只验证一个明确的目标\r\n- 使用清晰的数字序号标记预期结果\r\n- 预期结果使用\"应该/必须/会\"等确定性词汇\r\n- 包含正向和反向两种情况的验证\r\n- 标注敏感信息的脱敏处理方式\r\n- 为复杂场景添加截图或伪代码说明\r\n- 测试步骤留空，由用户根据实际系统补充\r\n\r\n❌ **DON'T - 避免做法**\r\n- 模糊的描述如\"检查是否可以正常工作\"\r\n- 一次性验证过多无关功能\r\n- 忽略前置条件和环境配置\r\n- 混合多个验证点在一个预期结果中\r\n- 使用主观判断代替客观测量\r\n- 忽略异常处理流程\r\n- 强制生成可能与实际不符的测试步骤\r\n\r\n### 用例评审要点\r\n\r\n1. **完整性检查**：是否覆盖所有需求点和隐性场景\r\n2. **独立性检查**：用例之间是否存在强依赖关系\r\n3. **可执行性检查**：预期结果是否清晰、客观可测量\r\n4. **可维护性检查**：命名规范、变更可追溯\r\n5. **优先级合理性**：P0用例是否真正关键\r\n6. **覆盖全面性**：功能、数据、权限、集成是否覆盖\r\n\r\n## 输出示例\r\n\r\n### 示例1：电商下单功能测试用例设计\r\n\r\n```markdown\r\n## 订单模块 - 商品下单 - P0\r\n\r\n### TC_ORDER_CREATE_001 正常下单流程\r\n\r\n**测试类型**: 功能测试\r\n**功能模块**: 订单管理\r\n**子功能**: 商品下单\r\n**用例级别**: P0\r\n**预置条件**:\r\n1. 用户已登录且账户余额充足\r\n2. 商品库存大于0\r\n3. 收货地址已配置\r\n\r\n**测试步骤**:\r\n（留空，由用户根据实际系统补充）\r\n\r\n**预期结果**:\r\n1. 进入订单确认页\r\n2. 订单金额计算准确（含运费优惠）\r\n3. 订单创建成功，返回订单号\r\n4. 库存扣减正确\r\n5. 收到订单confirmation通知\r\n\r\n**实际结果**: 待执行\r\n```\r\n\r\n### 示例2：用户注册功能异常场景\r\n\r\n```markdown\r\n## 用户模块 - 注册 - P1\r\n\r\n### TC_USER_REGISTER_002 邮箱格式错误\r\n\r\n**测试类型**: 功能测试\r\n**功能模块**: 用户管理\r\n**子功能**: 用户注册\r\n**用例级别**: P1\r\n**预置条件**: 访问注册页面\r\n\r\n**测试步骤**:\r\n（留空，由用户根据实际系统补充）\r\n\r\n**预期结果**:\r\n1. 邮箱字段显示红色错误提示\r\n2. 提示内容明确告知格式要求\r\n3. 无法继续提交表单\r\n4. 控制台无报错日志\r\n\r\n**实际结果**: 待执行\r\n```\r\n\r\n### 示例3：页面跳转测试用例设计\r\n\r\n```markdown\r\n## 商品模块 - 列表跳详情 - P0\r\n\r\n### TC_PRODUCT_LIST_001 正常跳转详情页\r\n\r\n**测试类型**: 功能测试\r\n**功能模块**: 商品管理\r\n**子功能**: 列表跳详情\r\n**用例级别**: P0\r\n**预置条件**:\r\n1. 用户已登录\r\n2. 商品列表页有数据\r\n\r\n**测试步骤**:\r\n（留空，由用户根据实际系统补充）\r\n\r\n**预期结果**:\r\n1. 成功跳转到商品详情页\r\n2. URL包含正确的商品ID（如/product/12345）\r\n3. 详情页展示的商品信息与列表一致\r\n4. 商品图片、价格、库存等关键信息正确\r\n5. 详情页功能按钮（购买、收藏等）可用\r\n\r\n**实际结果**: 待执行\r\n```\r\n\r\n## 检查清单\r\n\r\n测试用例设计完成后检查：\r\n- [ ] 是否覆盖了所有需求点和隐性场景？\r\n- [ ] 是否包含了正常、异常、边界三种场景？\r\n- [ ] 每条用例是否只验证一个明确目标？\r\n- [ ] 预期结果是否可客观验证？\r\n- [ ] 用例优先级（P0-P3）是否合理？\r\n\r\n## 参考资源\r\n\r\n- `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖\r\n- `references/coverage-and-quality.md` — 覆盖维度 + 覆盖评估 + 质量指标\r\n- `references/review-standards.md` — 需求文档要求 + 用例评审标准\r\n- ISTQB测试术语标准 / ISO/IEC/IEEE 29119 / Google Testing Blog\n\nFile v1.5.0:_meta.json\n\n{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-test-case-design\",\n \"version\": \"1.5.0\",\n \"publishedAt\": 1782736598186\n}\n\nFile v1.5.0:references/coverage-and-quality.md\n\n# 测试覆盖策略与质量标准\n\n## 覆盖维度\n\n```\n测试覆盖：\n├─ 功能覆盖\n│ ├─ 主流程覆盖：核心业务流程是否完整测试\n│ ├─ 分支流程覆盖：各种条件分支路径是否覆盖\n│ ├─ 异常场景覆盖：错误输入、异常操作是否测试\n│ ├─ 边界条件覆盖：输入范围边界、数量边界是否测试\n│ ├─ 退出流程覆盖：退出登录、注销、超时退出等场景\n│ └─ 状态转换覆盖：系统状态变化是否测试\n│\n├─ 数据覆盖\n│ ├─ 有效数据覆盖：正常数据是否测试\n│ ├─ 无效数据覆盖：异常数据是否测试\n│ ├─ 边界数据覆盖：边界值数据是否测试\n│ ├─ 特殊数据覆盖：特殊字符、超长数据是否测试\n│ ├─ 格式校验覆盖：邮箱、手机号、身份证等格式验证\n│ └─ 注入测试覆盖：SQL注入、XSS攻击等安全测试\n│\n├─ 字段级验证覆盖（每个表单字段必须测试）\n│ ├─ 长度边界：1位、最大长度、最大长度+1\n│ ├─ 格式校验：正则表达式验证（邮箱、手机号、身份证等）\n│ ├─ 注入测试：SQL注入、XSS攻击、命令注入\n│ ├─ 特殊字符：空格、特殊符号、Unicode字符\n│ ├─ 空值处理：必填字段为空、选填字段为空\n│ └─ 默认值：字段默认值是否正确\n│\n├─ 权限覆盖\n│ ├─ 角色权限覆盖：不同角色权限是否测试\n│ ├─ 越权访问覆盖：越权操作是否拦截\n│ ├─ 数据权限覆盖：数据隔离是否验证\n│ ├─ 功能权限覆盖：功能访问控制是否测试\n│ ├─ CSRF防护覆盖：跨站请求伪造防护是否测试\n│ └─ 路径遍历覆盖：目录遍历攻击防护是否测试\n│\n├─ 集成覆盖\n│ ├─ 模块集成覆盖：模块间协作是否测试\n│ ├─ 接口集成覆盖：接口调用是否测试\n│ ├─ 数据集成覆盖：数据流转是否测试\n│ └─ 异常集成覆盖：异常处理是否测试\n│\n└─ 非功能覆盖\n ├─ 性能覆盖：响应时间、吞吐量、并发性能是否测试\n ├─ 兼容性覆盖：浏览器、操作系统、设备兼容性是否测试\n ├─ 可用性覆盖：用户体验、易用性是否测试\n ├─ 安全性覆盖：数据加密、传输安全是否测试\n └─ 可靠性覆盖：稳定性、容错性是否测试\n```\n\n### 覆盖率评估\n\n| 覆盖率类型 | 计算方式 | 目标值 |\n|------------|----------|--------|\n| 需求覆盖率 | 已测需求点 / 总需求点 × 100% | ≥95% |\n| 功能覆盖率 | 已测功能点 / 总功能点 × 100% | ≥90% |\n| 用例覆盖率 | 已执行用例 / 总用例 × 100% | ≥100% |\n| 缺陷覆盖率 | 已修复缺陷 / 总缺陷 × 100% | ≥90% |\n\n## 质量保证标准\n\n### 用例质量指标\n\n| 指标 | 计算方式 | 目标值 |\n|------|----------|--------|\n| 用例有效性 | 有效用例数 / 总用例数 × 100% | ≥95% |\n| 用例执行率 | 已执行用例数 / 总用例数 × 100% | ≥100% |\n| 用例通过率 | 通过用例数 / 已执行用例数 × 100% | ≥98% |\n| 缺陷发现率 | 缺陷数 / 用例数 × 100% | 持续优化 |\n\n### 交付质量标准\n\n- 用例总数不低于需求点的3倍（包含异常场景）\n- P0+P1用例占比不低于60%\n- 每条用例平均预期结果3-5条\n- 无空洞描述，预期结果均可客观验证\n- 符合企业测试管理规范格式要求\n- 测试步骤留空，由用户根据实际系统补充\n\nFile v1.5.0:references/design-methods.md\n\n# 用例设计方法参考\n\n## 常用设计方法\n\n| 方法 | 适用场景 | 说明 | 必用场景 |\n|------|----------|------|----------|\n| 等价类划分法 | 输入域测试 | 将输入域划分为有效/无效等价类，减少冗余用例 | 所有输入字段 |\n| 边界值分析法 | 边界测试 | 针对边界情况设计专项测试，发现常见错误 | 所有有边界限制的字段 |\n| 场景法 | 业务流程测试 | 基于用户业务流程构建端到端测试场景 | 核心业务流程 |\n| 判定表驱动法 | 多条件组合 | 穷举所有条件组合可能性 | **必须使用**：多条件组合场景 |\n| 错误推测法 | 经验驱动 | 基于历史缺陷数据和开发经验预测潜在问题 | **必须使用**：异常场景覆盖 |\n| 风险驱动测试 | 风险优先 | 优先覆盖高风险区域和高频使用场景 | 高风险功能 |\n| 状态转换法 | 状态机测试 | 测试状态机的合法/非法转换 | 有状态变化的功能 |\n| 因果图法 | 复杂条件组合 | 分析输入条件与输出结果的因果关系 | **必须使用**：复杂条件依赖关系 |\n| 正交试验法 | 多因素多水平 | 用最少的试验覆盖最多的因素组合 | **必须使用**：多因素兼容性测试 |\n| 功能图法 | 功能组合测试 | 分析功能点的输入输出关系，生成功能测试用例 | **必须使用**：功能点组合覆盖 |\n\n### 方法应用要点\n\n**等价类划分法**：有效等价类（正常业务数据范围）、无效等价类（异常/边界/特殊数据）。划分依据：业务规则、数据类型、用户角色。示例：用户年龄输入（1-120有效，<1或>120无效）。\n\n**边界值分析法**：数值边界（最小值、最小值+1、最大值-1、最大值）、字符串边界（空、1字符、最大长度、最大长度+1）、日期边界（当天、前一天、后一天）。示例：密码长度8位（测试7位、8位、9位）。\n\n**场景法**：主成功场景（正常业务流程）、扩展场景（分支流程）、异常场景（错误处理流程）。示例：电商下单（浏览→加购→结算→支付→完成）。\n\n**判定表驱动法**：条件桩（所有输入条件）、动作桩（所有可能输出）、规则（条件组合与动作对应关系）。示例：登录（用户名正确/错误 × 密码正确/错误 → 不同结果）。\n\n**错误推测法**：基于经验（历史缺陷/常见错误模式）、基于直觉（测试人员经验判断）、基于领域知识（业务规则边界）。示例：输入框输入特殊字符/超长字符串/SQL注入语句。\n\n**因果图法**：原因（输入条件）、结果（输出结果）、关系（与/或/非逻辑）、约束（条件间依赖）。示例：优惠券使用条件（金额≥100且有券 → 可使用）。\n\n**正交试验法**：因素（测试变量）、水平（取值）、用例（最少组合覆盖最多因素）。示例：兼容性测试（3浏览器×3系统×3分辨率 → 正交表选9组）。\n\n**功能图法**：功能点（系统功能）、输入（条件）、输出（结果）、组合（调用关系）。示例：电商系统（登录→浏览→加购→结算→支付→功能组合测试）。\n\n## 复杂场景覆盖\n\n| 场景类型 | 测试重点 | 示例 |\n|----------|----------|------|\n| 页面跳转测试 | 跳转目标、参数传递、权限校验 | 列表跳详情页、菜单跳转、外部链接跳转 |\n| 路由参数测试 | 参数缺失、非法、越界处理 | URL参数传递、query参数、path参数 |\n| 跨页面联动 | 数据传递、状态同步、缓存一致性 | 订单页与用户页关联、购物车与结算页联动 |\n| 并发场景测试 | 多人同时操作、数据竞争 | 同时下单、库存并发扣减 |\n| 异常兜底测试 | 服务降级、熔断、重试机制 | 接口超时、服务不可用、网络异常 |\n\n### 页面跳转测试深度覆盖\n\n**测试要点**：跳转触发点、跳转目标页、跳转条件、异常跳转。检查：正常跳转目标正确、参数传递完整、权限校验拦截正确、404处理、空状态、浏览器回退、返回按钮、面包屑导航、外部跳转新标签页、循环跳转检测。\n\n### 路由参数测试深度覆盖\n\n**测试要点**：参数定义（query/path/hash）、格式（数据类型/长度限制）、传递方式（URL/session/cookie/localStorage）、验证（缺失/非法/越界/安全）。检查：参数存在性、类型、长度、格式、安全（SQL注入/XSS）、边界、组合、编码。\n\n### 跨页面联动测试深度覆盖\n\n**测试要点**：数据依赖（页面间数据关系）、状态同步（操作后更新）、缓存策略（刷新机制）、业务流程（完整闭环）。检查：数据传递正确、关联页面状态更新、缓存策略合理、消息通知跳转正确、业务闭环完整、多页面数据一致、操作反馈同步。\n\n## 常用测试方法速查\n\n**等价类划分示例**：年龄输入框（有效[1,120]，无效<1/>120/非数字）；状态下拉（有效[启用/禁用/冻结]，无效其他）。\n\n**边界值分析示例**：文件上传10MB（9MB/10MB/10.1MB）；文本框200字符（199/200/201字）；列表分页（第1页/最后1页/超出最大页码）。\n\n**判定表示例**：\n\n| 条件 | A(有优惠券) | B(满100元) | C(可用) | 结果 |\n|------|-------------|------------|---------|------|\n| 1 | Y | Y | Y | 可以使用 |\n| 2 | Y | Y | N | 不可用（已过期） |\n| 3 | Y | N | Y | 不可用（不满足门槛） |\n| 4 | N | Y/Y | Y/Y | 不适用 |\n\nFile v1.5.0:references/review-standards.md\n\n# 需求文档要求与用例评审标准\n\n## 需求文档要求\n\n### 页面跳转、路由参数、跨页面联动场景的需求要求\n\n#### 1. 页面跳转需求要求\n- **跳转触发点**：明确哪些操作会触发页面跳转（按钮、链接、菜单等）\n- **跳转目标页**：明确跳转到哪个页面，页面标识（URL、页面名称等）\n- **跳转条件**：在什么条件下允许跳转（权限、数据状态等）\n- **跳转参数**：需要传递哪些参数（ID、类型、来源等）\n- **异常处理**：跳转失败时的处理方式（错误提示、回退逻辑等）\n\n#### 2. 路由参数需求要求\n- **参数定义**：明确URL中包含哪些参数（query参数、path参数等）\n- **参数格式**：参数的数据类型、格式要求、长度限制\n- **参数传递**：参数如何在页面间传递（URL、session、cookie等）\n- **参数验证**：参数缺失、非法、越界时的处理逻辑\n- **参数安全**：参数的权限控制、防篡改机制\n\n#### 3. 跨页面联动需求要求\n- **数据依赖**：页面间的数据依赖关系（哪些数据需要同步）\n- **状态同步**：页面状态变更后，其他页面如何同步更新\n- **缓存策略**：页面数据的缓存机制和刷新策略\n- **业务流程**：跨页面的完整业务流程描述\n- **异常处理**：联动失败时的处理方式（数据回滚、状态恢复等）\n\n#### 4. 需求文档质量要求\n- **完整性**：所有跳转、参数、联动场景都有明确描述\n- **一致性**：不同部分的需求描述不矛盾\n- **可测试性**：需求描述足够具体，可以设计测试用例\n- **无歧义**：需求描述清晰，没有多种理解方式\n\n### 需求文档检查清单\n\n- [ ] 所有页面跳转的触发条件和目标页面\n- [ ] 路由参数的定义、格式和传递规则\n- [ ] 跨页面数据依赖和状态同步机制\n- [ ] 异常场景的处理逻辑\n- [ ] 权限控制要求\n- [ ] 业务流程的完整描述\n\n### 需求不足时的处理\n\n如果需求文档信息不足，应该：标记缺失信息、提出澄清问题、基于经验假设（注明假设条件）、在测试报告中说明需求不足带来的测试风险。\n\n## 用例评审标准\n\n### 完整性检查\n- [ ] 是否覆盖所有需求点和隐性场景？\n- [ ] 主流程、分支流程、异常场景是否覆盖？\n- [ ] 边界条件、特殊数据是否覆盖？\n- [ ] 权限控制、安全场景是否覆盖？\n\n### 独立性检查\n- [ ] 用例之间是否存在强依赖关系？\n- [ ] 用例执行顺序是否影响结果？\n- [ ] 用例数据是否相互独立？\n\n### 可执行性检查\n- [ ] 预置条件是否明确可准备？\n- [ ] 预期结果是否客观可测量？\n- [ ] 测试标题是否准确反映测试目的？\n- [ ] 用例级别是否合理？\n\n### 可维护性检查\n- [ ] 用例编号是否规范？\n- [ ] 命名是否清晰一致？\n- [ ] 变更是否可追溯？\n\n### 评审通过标准\n\n1. ✅ **覆盖率达标**: 核心功能P0用例覆盖率100%\n2. ✅ **逻辑自洽**: 无矛盾或冲突的用例描述\n3. ✅ **可执行性**: 预期结果均可客观验证\n4. ✅ **边界覆盖**: 输入边界、异常场景均有对应用例\n5. ✅ **优先级合理**: P0用例不超过总数30%\n6. ✅ **格式规范**: 符合标准模板要求\n\nFile v1.5.0:skill-card.md\n\n## Description:
\nDesigns structured, traceable QA test cases from completed requirement, scenario, boundary, and combination analysis, with P0-P3 prioritization and standardized test-case fields.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[kokxi](https://clawhub.ai/user/kokxi)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nQA engineers, developers, and product teams use this skill to turn requirement context into structured test-case reports with priorities, traceability IDs, coverage notes, and review-ready expected results. It is intended for use after upstream analysis is complete, not as a replacement for requirement clarification or human test execution planning.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Users may include secrets or unrelated private data when providing requirement context.
\nMitigation: Provide only the requirements and business context needed for test design, and avoid pasting credentials, secrets, or unrelated private data.
\nRisk: Generated test cases can be incomplete or generic when requirement, scenario, boundary, or combination analysis is missing.
\nMitigation: Use the skill after upstream analysis is complete, supply clear requirements and constraints, and review the output for missing scenarios before relying on it.
\nRisk: The skill does not inspect implementation code and may not capture system-specific execution details.
\nMitigation: Use the output as requirement-based test design guidance, then have testers complete execution steps and validate expected results against the actual system.
\n\n\n## Reference(s):
\n- [ClawHub release page](https://clawhub.ai/kokxi/skills/qa-test-case-design)
\n- [Design methods reference](references/design-methods.md)
\n- [Coverage and quality reference](references/coverage-and-quality.md)
\n- [Review standards reference](references/review-standards.md)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, guidance]
\n**Output Format:** [Markdown test-case reports and tables with traceability fields, priority groupings, coverage analysis, and test guidance]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Test steps are intentionally left for users to complete against the actual system.]
\n\n## Skill Version(s):
\n1.5.0 (source: frontmatter and server release evidence)
\n\n## Ethical Considerations:
\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.4.1: 3 files, 11193 bytes\n\nFiles: skill-card.md (2074b), SKILL.md (27428b), _meta.json (138b)\n\nFile v1.4.1:SKILL.md\n\n---\r\nname: qa-test-case-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-req-deconstruction # 输入：需求解构结果\r\n - qa-boundary-deep-dive # 输入：边界分析结果\r\n - qa-scenario-tree # 输入：场景树构建结果\r\n downstream:\r\n - qa-test-skills # 输出：测试用例设计结果\r\n - qa-expert-review # 输出：用例评审反馈\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\r\n## 设计理念\r\n\r\n### 为什么测试步骤留空？\r\n\r\n```\r\n同一个\"登录\"功能：\r\n\r\n系统A的登录步骤：\r\n1. 打开登录页面\r\n2. 输入手机号\r\n3. 获取验证码\r\n4. 输入验证码\r\n5. 点击登录\r\n\r\n系统B的登录步骤：\r\n1. 打开登录页面\r\n2. 输入用户名\r\n3. 输入密码\r\n4. 点击登录按钮\r\n5. 完成二次验证\r\n\r\n系统C的登录步骤：\r\n1. 打开APP\r\n2. 点击\"一键登录\"\r\n3. 获取本机号码\r\n4. 自动登录\r\n```\r\n\r\n**AI不知道你们系统用的是哪种实现方式**，所以：\r\n- 强制生成步骤 → 步骤与实际不符 → 测试人员需要大量修正 → 反而增加工作量\r\n- 测试步骤留空 → 用户基于实际系统补充 → 测试人员只需补充细节 → 减少工作量\r\n\r\n## 需求文档要求\r\n\r\n### 页面跳转、路由参数、跨页面联动场景的需求要求\r\n\r\n这些复杂场景对需求文档有较高要求，需求文档需要提供以下信息：\r\n\r\n#### 1. 页面跳转需求要求\r\n- **跳转触发点**：明确哪些操作会触发页面跳转（按钮、链接、菜单等）\r\n- **跳转目标页**：明确跳转到哪个页面，页面标识（URL、页面名称等）\r\n- **跳转条件**：在什么条件下允许跳转（权限、数据状态等）\r\n- **跳转参数**：需要传递哪些参数（ID、类型、来源等）\r\n- **异常处理**：跳转失败时的处理方式（错误提示、回退逻辑等）\r\n\r\n#### 2. 路由参数需求要求\r\n- **参数定义**：明确URL中包含哪些参数（query参数、path参数等）\r\n- **参数格式**：参数的数据类型、格式要求、长度限制\r\n- **参数传递**：参数如何在页面间传递（URL、session、cookie等）\r\n- **参数验证**：参数缺失、非法、越界时的处理逻辑\r\n- **参数安全**：参数的权限控制、防篡改机制\r\n\r\n#### 3. 跨页面联动需求要求\r\n- **数据依赖**：页面间的数据依赖关系（哪些数据需要同步）\r\n- **状态同步**：页面状态变更后，其他页面如何同步更新\r\n- **缓存策略**：页面数据的缓存机制和刷新策略\r\n- **业务流程**：跨页面的完整业务流程描述\r\n- **异常处理**：联动失败时的处理方式（数据回滚、状态恢复等）\r\n\r\n#### 4. 需求文档质量要求\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### 需求不足时的处理\r\n\r\n如果需求文档信息不足，应该：\r\n1. **标记缺失信息**：在测试用例中标注需求不明确的地方\r\n2. **提出澄清问题**：向产品经理/业务分析师提出具体问题\r\n3. **基于经验假设**：在测试用例中注明假设条件\r\n4. **风险提示**：在测试报告中说明需求不足带来的测试风险\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| 用例级别 | P0(关键)、P1(重要)、P2(一般)、P3(可选) | ✅ 必填 |\r\n| 预置条件 | 执行测试前必须满足的状态或数据准备 | ✅ 必填 |\r\n| 测试步骤 | 详细的操作步骤（留空，由用户补充） | ⚠️ 留空 |\r\n| 预期结果 | 每个步骤对应的预期产出或状态变化 | ✅ 必填 |\r\n| 实际结果 | 测试执行后的真实结果记录（留空） | ⚠️ 留空 |\r\n\r\n### 用例编号规则\r\n\r\n`TC_{模块缩写}_{功能序列号}_{场景后缀}`\r\n\r\n示例：\r\n- `TC_USER_LOGIN_001_NORMAL` - 用户模块 - 登录功能 - 第001条 - 正常场景\r\n- `TC_ORDER_DETAIL_002_JUMP` - 订单模块 - 详情页 - 第002条 - 跳转场景\r\n- `TC_PRODUCT_LINK_003_CROSS` - 商品模块 - 关联页面 - 第003条 - 跨页面联动\r\n\r\n### 用例级别定义\r\n\r\n| 级别 | 说明 | 适用场景 |\r\n|------|------|----------|\r\n| P0 | 关键用例 | 核心业务流程、阻碍系统正常使用的问题、主流程验证 |\r\n| P1 | 重要用例 | 主要功能、影响用户体验的问题、重要分支流程 |\r\n| P2 | 一般用例 | 次要功能、不影响主体流程的问题、异常场景 |\r\n| P3 | 可选用例 | 边缘场景、美化优化相关、极端异常情况 |\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│ ├─ 有效数据覆盖：正常数据是否测试\r\n│ ├─ 无效数据覆盖：异常数据是否测试\r\n│ ├─ 边界数据覆盖：边界值数据是否测试\r\n│ ├─ 特殊数据覆盖：特殊字符、超长数据是否测试\r\n│ ├─ 格式校验覆盖：邮箱、手机号、身份证等格式验证\r\n│ └─ 注入测试覆盖：SQL注入、XSS攻击等安全测试\r\n│\r\n├─ 字段级验证覆盖（每个表单字段必须测试）\r\n│ ├─ 长度边界：1位、最大长度、最大长度+1\r\n│ ├─ 格式校验：正则表达式验证（邮箱、手机号、身份证等）\r\n│ ├─ 注入测试：SQL注入、XSS攻击、命令注入\r\n│ ├─ 特殊字符：空格、特殊符号、Unicode字符\r\n│ ├─ 空值处理：必填字段为空、选填字段为空\r\n│ └─ 默认值：字段默认值是否正确\r\n│\r\n├─ 权限覆盖\r\n│ ├─ 角色权限覆盖：不同角色权限是否测试\r\n│ ├─ 越权访问覆盖：越权操作是否拦截\r\n│ ├─ 数据权限覆盖：数据隔离是否验证\r\n│ ├─ 功能权限覆盖：功能访问控制是否测试\r\n│ ├─ CSRF防护覆盖：跨站请求伪造防护是否测试\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### 覆盖率评估\r\n\r\n| 覆盖率类型 | 计算方式 | 目标值 |\r\n|------------|----------|--------|\r\n| 需求覆盖率 | 已测需求点 / 总需求点 × 100% | ≥95% |\r\n| 功能覆盖率 | 已测功能点 / 总功能点 × 100% | ≥90% |\r\n| 用例覆盖率 | 已执行用例 / 总用例 × 100% | ≥100% |\r\n| 缺陷覆盖率 | 已修复缺陷 / 总缺陷 × 100% | ≥90% |\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| 功能图法 | 功能组合测试 | 分析功能点的输入输出关系，生成功能测试用例 | **必须使用**：功能点组合覆盖 |\r\n\r\n#### 方法应用要点\r\n\r\n**等价类划分法应用**：\r\n- 有效等价类：正常业务数据范围\r\n- 无效等价类：异常、边界、特殊数据\r\n- 划分依据：业务规则、数据类型、用户角色\r\n- 示例：用户年龄输入（1-120有效，<1或>120无效）\r\n\r\n**边界值分析法应用**：\r\n- 数值边界：最小值、最小值+1、最大值-1、最大值\r\n- 字符串边界：空字符串、1个字符、最大长度、最大长度+1\r\n- 日期边界：当天、前一天、后一天、边界日期\r\n- 示例：密码长度要求8位（测试7位、8位、9位）\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- 基于领域知识：业务规则的边界情况\r\n- 示例：输入框输入特殊字符、超长字符串、SQL注入语句\r\n\r\n**因果图法应用**：\r\n- 原因：输入条件（因）\r\n- 结果：输出结果（果）\r\n- 关系：因果之间的逻辑关系（与、或、非）\r\n- 约束：条件之间的依赖关系\r\n- 示例：优惠券使用条件（满减券：金额≥100且有券 → 可使用）\r\n\r\n**正交试验法应用**：\r\n- 因素：测试变量（如浏览器、操作系统、分辨率）\r\n- 水平：每个因素的取值（如Chrome/Firefox/Edge）\r\n- 用例：最少的试验组合覆盖最多的因素\r\n- 示例：兼容性测试（3浏览器×3系统×3分辨率 → 正交表选9组）\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| 路由参数测试 | 参数缺失、非法、越界处理 | URL参数传递、query参数、path参数 |\r\n| 跨页面联动 | 数据传递、状态同步、缓存一致性 | 订单页与用户页关联、购物车与结算页联动 |\r\n| 并发场景测试 | 多人同时操作、数据竞争 | 同时下单、库存并发扣减 |\r\n| 异常兜底测试 | 服务降级、熔断、重试机制 | 接口超时、服务不可用、网络异常 |\r\n\r\n#### 页面跳转测试深度覆盖\r\n\r\n**测试要点**：\r\n- **跳转触发点**：按钮、链接、菜单、自动跳转等\r\n- **跳转目标页**：正确页面、参数传递、状态保持\r\n- **跳转条件**：权限控制、数据状态、业务规则\r\n- **异常跳转**：404页面、空数据、错误参数、循环跳转\r\n\r\n**检查清单**：\r\n- [ ] 正常跳转：点击跳转目标正确\r\n- [ ] 参数传递：URL参数完整且正确\r\n- [ ] 权限校验：未登录/无权限拦截正确\r\n- [ ] 404处理：不存在资源跳转404页\r\n- [ ] 空状态：无数据时展示空状态页\r\n- [ ] 浏览器回退：历史栈管理正确\r\n- [ ] 返回按钮：页面内返回功能正常\r\n- [ ] 面包屑导航：层级导航准确\r\n- [ ] 外部跳转：新标签页打开外部链接\r\n- [ ] 循环跳转：检测并阻止循环重定向\r\n\r\n#### 路由参数测试深度覆盖\r\n\r\n**测试要点**：\r\n- **参数定义**：query参数、path参数、hash参数\r\n- **参数格式**：数据类型、格式要求、长度限制\r\n- **参数传递**：URL、session、cookie、localStorage\r\n- **参数验证**：缺失、非法、越界、安全校验\r\n\r\n**检查清单**：\r\n- [ ] 参数存在性：参数缺失时的处理\r\n- [ ] 参数类型：错误类型参数的处理\r\n- [ ] 参数长度：超长参数的处理\r\n- [ ] 参数格式：非法格式参数的处理\r\n- [ ] 参数安全：SQL注入、XSS攻击防护\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- [ ] 消息通知：通知点击跳转正确页面\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- [ ] 用例执行顺序是否影响结果？\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\n1. ✅ **覆盖率达标**: 核心功能P0用例覆盖率100%\r\n2. ✅ **逻辑自洽**: 无矛盾或冲突的用例描述\r\n3. ✅ **可执行性**: 预期结果均可客观验证\r\n4. ✅ **边界覆盖**: 输入边界、异常场景均有对应用例\r\n5. ✅ **优先级合理**: P0用例不超过总数30%\r\n6. ✅ **格式规范**: 符合标准模板要求\r\n\r\n## 输出模板\r\n\r\n**重要：以下输出格式是固定的，必须严格遵守。**\r\n\r\n### 测试用例设计输出格式\r\n\r\n```markdown\r\n## 测试用例设计报告\r\n\r\n### 基本信息\r\n- 功能模块：[模块名称]\r\n- 设计日期：[日期]\r\n- 设计人员：[姓名]\r\n- 用例总数：[数量]\r\n\r\n### 用例统计\r\n| 级别 | 数量 | 占比 |\r\n|------|------|------|\r\n| P0 | [数量] | [百分比] |\r\n| P1 | [数量] | [百分比] |\r\n| P2 | [数量] | [百分比] |\r\n| P3 | [数量] | [百分比] |\r\n\r\n### 测试用例列表\r\n\r\n#### P0 关键用例\r\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\r\n|----------|----------|----------|----------|------------|----------|\r\n| TC_XXX_001 | [测试标题] | 功能测试 | 等价类划分法 | REQ-XXX-001 | [预期结果] |\r\n\r\n#### P1 重要用例\r\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\r\n|----------|----------|----------|----------|------------|----------|\r\n| TC_XXX_002 | [测试标题] | 功能测试 | 边界值分析法 | REQ-XXX-002 | [预期结果] |\r\n\r\n#### P2 一般用例\r\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\r\n|----------|----------|----------|----------|------------|----------|\r\n| TC_XXX_003 | [测试标题] | 异常测试 | 错误推测法 | REQ-XXX-003 | [预期结果] |\r\n\r\n#### P3 可选用例\r\n| 用例编号 | 测试标题 | 测试类型 | 测试方法 | 需求追溯ID | 预期结果 |\r\n|----------|----------|----------|----------|------------|----------|\r\n| TC_XXX_004 | [测试标题] | 边界测试 | 边界值分析法 | REQ-XXX-004 | [预期结果] |\r\n\r\n### 覆盖率分析\r\n- 需求覆盖率：[百分比]\r\n- 功能覆盖率：[百分比]\r\n- 风险覆盖率：[百分比]\r\n\r\n### 测试建议\r\n1. [建议1]\r\n2. [建议2]\r\n3. [建议3]\r\n```\r\n\r\n### 单条用例输出格式\r\n\r\n```markdown\r\n## 测试用例\r\n\r\n### 基本信息\r\n- 用例编号：TC_XXX_001\r\n- 测试类型：功能测试\r\n- 功能模块：用户管理\r\n- 子功能：登录\r\n- 测试标题：验证正确的用户名和密码可以成功登录\r\n- 用例级别：P0\r\n- 需求追溯ID：REQ-AUTH-001\r\n- 测试方法：等价类划分法、边界值分析法\r\n\r\n### 预置条件\r\n1. 用户已注册\r\n2. 网络正常\r\n3. 服务正常运行\r\n4. 前置依赖：无\r\n\r\n### 测试步骤\r\n（留空，由用户根据实际系统补充）\r\n\r\n### 预期结果\r\n1. 跳转至首页\r\n2. 显示用户信息\r\n3. 登录状态保持正常\r\n\r\n### 实际结果\r\n（测试执行后填写）\r\n\r\n### 字段级验证（如适用）\r\n- 用户名字段：\r\n - 长度边界：1位、20位、21位\r\n - 格式校验：无特殊格式要求\r\n - 注入测试：SQL注入、XSS攻击\r\n - 特殊字符：空格、@、#等\r\n- 密码字段：\r\n - 长度边界：1位、8位、9位\r\n - 格式校验：至少8位，包含字母、数字、特殊字符\r\n - 注入测试：SQL注入、XSS攻击\r\n - 特殊字符：空格、@、#等\r\n```\r\n\r\n## 质量保证标准\r\n\r\n### 用例质量指标\r\n\r\n| 指标 | 计算方式 | 目标值 |\r\n|------|----------|--------|\r\n| 用例有效性 | 有效用例数 / 总用例数 × 100% | ≥95% |\r\n| 用例执行率 | 已执行用例数 / 总用例数 × 100% | ≥100% |\r\n| 用例通过率 | 通过用例数 / 已执行用例数 × 100% | ≥98% |\r\n| 缺陷发现率 | 缺陷数 / 用例数 × 100% | 持续优化 |\r\n\r\n### 交付质量标准\r\n\r\n- 用例总数不低于需求点的3倍（包含异常场景）\r\n- P0+P1用例占比不低于60%\r\n- 每条用例平均预期结果3-5条\r\n- 无空洞描述，预期结果均可客观验证\r\n- 符合企业测试管理规范格式要求\r\n- 测试步骤留空，由用户根据实际系统补充\r\n\r\n## 使用方法\r\n\r\n### 触发场景\r\n\r\n当用户提供以下类型的请求时，此技能自动激活：\r\n\r\n1. **生成测试用例**：\"帮我设计用户登录功能的测试用例\"\r\n2. **完善用例**：\"这些测试用例不够全面，请补充异常场景\"\r\n3. **审查用例**：\"检查一下这些测试用例是否有遗漏\"\r\n4. **评审辅助**：\"我需要准备测试用例评审，生成一套完整的用例\"\r\n5. **覆盖优化**：\"这个功能还缺哪些测试场景\"\r\n6. **质量评估**：\"评估一下这些测试用例的质量\"\r\n\r\n### 输入要素\r\n\r\n为生成高质量的测试用例，尽量提供以下信息：\r\n\r\n1. **需求描述**：功能需求的详细说明\r\n2. **业务背景**：该功能在整体产品中的定位\r\n3. **约束条件**：技术限制、合规要求等\r\n4. **目标用户**：主要使用人群及其特征\r\n5. **关联系统**：涉及的其他模块或第三方服务\r\n6. **风险点**：已知的高风险区域\r\n7. **历史缺陷**：类似功能的历史问题\r\n\r\n### 输出内容\r\n\r\n1. **完整测试用例集**：涵盖所有识别出的测试点\r\n2. **测试优先级排序**：按P0-P3分级展示\r\n3. **覆盖率说明**：已覆盖的测试维度列表\r\n4. **缺失风险提示**：可能存在的测试盲区建议\r\n5. **测试建议**：针对测试执行的建议\r\n\r\n## 最佳实践\r\n\r\n### 用例设计原则\r\n\r\n✅ **DO - 推荐做法**\r\n- 每个用例只验证一个明确的目标\r\n- 使用清晰的数字序号标记预期结果\r\n- 预期结果使用\"应该/必须/会\"等确定性词汇\r\n- 包含正向和反向两种情况的验证\r\n- 标注敏感信息的脱敏处理方式\r\n- 为复杂场景添加截图或伪代码说明\r\n- 测试步骤留空，由用户根据实际系统补充\r\n\r\n❌ **DON'T - 避免做法**\r\n- 模糊的描述如\"检查是否可以正常工作\"\r\n- 一次性验证过多无关功能\r\n- 忽略前置条件和环境配置\r\n- 混合多个验证点在一个预期结果中\r\n- 使用主观判断代替客观测量\r\n- 忽略异常处理流程\r\n- 强制生成可能与实际不符的测试步骤\r\n\r\n### 用例评审要点\r\n\r\n1. **完整性检查**：是否覆盖所有需求点和隐性场景\r\n2. **独立性检查**：用例之间是否存在强依赖关系\r\n3. **可执行性检查**：预期结果是否清晰、客观可测量\r\n4. **可维护性检查**：命名规范、变更可追溯\r\n5. **优先级合理性**：P0用例是否真正关键\r\n6. **覆盖全面性**：功能、数据、权限、集成是否覆盖\r\n\r\n## Examples\r\n\r\n### 示例1：电商下单功能测试用例设计\r\n\r\n```markdown\r\n## 订单模块 - 商品下单 - P0\r\n\r\n### TC_ORDER_CREATE_001 正常下单流程\r\n\r\n**测试类型**: 功能测试\r\n**功能模块**: 订单管理\r\n**子功能**: 商品下单\r\n**用例级别**: P0\r\n**预置条件**:\r\n1. 用户已登录且账户余额充足\r\n2. 商品库存大于0\r\n3. 收货地址已配置\r\n\r\n**测试步骤**:\r\n（留空，由用户根据实际系统补充）\r\n\r\n**预期结果**:\r\n1. 进入订单确认页\r\n2. 订单金额计算准确（含运费优惠）\r\n3. 订单创建成功，返回订单号\r\n4. 库存扣减正确\r\n5. 收到订单confirmation通知\r\n\r\n**实际结果**: 待执行\r\n```\r\n\r\n### 示\n\nArchive v1.4.0: 3 files, 11235 bytes\n\nFiles: skill-card.md (2167b), SKILL.md (27059b), _meta.json (138b)","readmeExcerpt":"Skill: qa-test-case-design Owner: kokxi Summary: 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。 触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing structured test cases with P0-P3 prioritization, the canonical 9-column format, coverage strategy, and requirement traceability. Tags: la","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"TC_{模块缩写}_{功能缩写}_{三位序号}\nTC_API_LOGIN_001 TC_CART_ADD_007 TC_ORDER_REFUND_003"},{"language":"markdown","snippet":"| 用例编号 | 测试类型 | 功能模块 | 测试标题 | 用例级别 | 预置条件 | 测试步骤 | 预期结果 | 风险等级 |\n|---------|---------|---------|---------|---------|---------|---------|---------|---------|\n| TC_API_LOGIN_001 | 功能测试 | 认证/登录 | 正确凭证登录成功 | P0 | 账号 u1 已就绪，接口文档已提供 | POST /api/login，body {\"user\":\"u1\",\"pass\":\"***\"} | 返回 200，响应含 token；调 /api/profile 有效；无堆栈泄露 | 高 |\n| TC_API_LOGIN_002 | 安全测试 | 认证/登录 | 伪造 Token 被拒 | P0 | 已知合法 token 与签名算法 | 改 1 个字符后请求 /api/profile | 返回 401；响应不含内部信息与用户数据 | 高 |\n| TC_API_LOGIN_003 | 异常测试 | 认证/登录 | 写操作超时重试不产生重复副作用 | P1 | 网关可注入延迟；写接口有幂等键 | 令首次请求延迟至超时，按服务端策略重放 2 次 | 重试成功且最终仅 1 次登录成功记录 | 中 |"},{"language":"bash","snippet":"python scripts/validate_testcase_table.py <用例文件>"},{"language":"text","snippet":"测试覆盖：\n├─ 功能覆盖\n│ ├─ 主流程覆盖：核心业务流程是否完整测试\n│ ├─ 分支流程覆盖：各种条件分支路径是否覆盖\n│ ├─ 异常场景覆盖：错误输入、异常操作是否测试\n│ ├─ 边界条件覆盖：输入范围边界、数量边界是否测试\n│ ├─ 退出流程覆盖：退出登录、注销、超时退出等场景\n│ └─ 状态转换覆盖：系统状态变化是否测试\n│\n├─ 数据覆盖\n│ ├─ 有效数据覆盖：正常数据是否测试\n│ ├─ 无效数据覆盖：异常数据是否测试\n│ ├─ 边界数据覆盖：边界值数据是否测试\n│ ├─ 特殊数据覆盖：特殊字符、超长数据是否测试\n│ ├─ 格式校验覆盖：邮箱、手机号、身份证等格式验证\n│ └─ 注入测试覆盖：SQL注入、XSS攻击等安全测试\n│\n├─ 字段级验证覆盖（每个表单字段必须测试）\n│ ├─ 长度边界：1位、最大长度、最大长度+1\n│ ├─ 格式校验：正则表达式验证（邮箱、手机号、身份证等）\n│ ├─ 注入测试：SQL注入、XSS攻击、命令注入\n│ ├─ 特殊字符：空格、特殊符号、Unicode字符\n│ ├─ 空值处理：必填字段为空、选填字段为空\n│ └─ 默认值：字段默认值是否正确\n│\n├─ 权限覆盖\n│ ├─ 角色权限覆盖：不同角色权限是否测试\n│ ├─ 越权访问覆盖：越权操作是否拦截\n│ ├─ 数据权限覆盖：数据隔离是否验证\n│ ├─ 功能权限覆盖：功能访问控制是否测试\n│ ├─ CSRF防护覆盖：跨站请求伪造防护是否测试\n│ └─ 路径遍历覆盖：目录遍历攻击防护是否测试\n│\n├─ 集成覆盖\n│ ├─ 模块集成覆盖：模块间协作是否测试\n│ ├─ 接口集成覆盖：接口调用是否测试\n│ ├─ 数据集成覆盖：数据流转是否测试\n│ └─ 异常集成覆盖：异常处理是否测试\n│\n└─ 非功能覆盖\n ├─ 性能覆盖：响应时间、吞吐量、并发性能是否测试\n ├─ 兼容性覆盖：浏览器、操作系统、设备兼容性是否测试\n ├─ 可用性覆盖：用户体验、易用性是否测试\n ├─ 安全性覆盖：数据加密、传输安全是否测试\n └─ 可靠性覆盖：稳定性、容错性是否测试"},{"language":"text","snippet":"TC_{模块缩写}_{功能缩写}_{三位序号}"},{"language":"markdown","snippet":"| 用例编号 | 测试类型 | 功能模块 | 测试标题 | 用例级别 | 预置条件 | 测试步骤 | 预期结果 | 风险等级 |\n|---------|---------|---------|---------|---------|---------|---------|---------|---------|\n| TC_API_LOGIN_001 | 功能测试 | 认证/登录 | 正确凭证登录成功 | P0 | 账号 u1 已就绪，接口文档已提供 | POST /api/login，body {\"user\":\"u1\",\"pass\":\"***\"} | 返回 200，响应含 token；调 /api/profile 有效；无堆栈泄露 | 高 |\n| TC_API_LOGIN_002 | 安全测试 | 认证/登录 | 伪造 Token 被拒 | P0 | 已知合法 token 与签名算法 | 改 1 个字符后请求 /api/profile | 返回 401；响应不含内部信息与用户数据 | 高 |"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: qa-test-case-design\ndescription: >-\n 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。\n 触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing structured test cases with P0-P3 prioritization, the canonical 9-column format, coverage strategy, and requirement traceability.\nlicense: MIT\nallowed-tools: Read Grep Glob\nmetadata:\n display-name: \"Test Case Design\"\n version: \"1.8.0\"\n when-to-use: \"用户说\\\"设计测试用例\\\"、\\\"用例评审\\\"、\\\"用例覆盖\\\"、\\\"测试用例设计\\\"、\\\"用例模板\\\"、\\\"用例规范\\\"、\\\"用例格式\\\"、需要测试用例结构指导、需要编写或规范测试用例时\"\n related-skills: \"{\\\"upstream\\\":[\\\"qa-req-deconstruction\\\",\\\"qa-boundary-deep-dive\\\",\\\"qa-scenario-tree\\\"],\\\"downstream\\\":[\\\"qa-test-skills\\\",\\\"qa-expert-review\\\",\\\"qa-regression-testing\\\"]}\"\n references: \"[\\\"assets/case-table.md\\\",\\\"references/output-template-full.md\\\",\\\"references/design-methods.md\\\",\\\"references/coverage-and-quality.md\\\",\\\"references/review-standards.md\\\"]\"\n input-format: \"{\\\"required\\\":[{\\\"name\\\":\\\"需求描述\\\",\\\"type\\\":\\\"string\\\",\\\"description\\\":\\\"功能需求的详细说明\\\"}],\\\"optional\\\":[{\\\"name\\\":\\\"场景分析\\\",\\\"type\\\":\\\"object\\\",\\\"description\\\":\\\"来自qa-scenario-tree的场景树\\\"},{\\\"name\\\":\\\"边界条件\\\",\\\"type\\\":\\\"object\\\",\\\"description\\\":\\\"来自qa-boundary-deep-dive的边界分析结果\\\"},{\\\"name\\\":\\\"业务背景\\\",\\\"type\\\":\\\"string\\\",\\\"description\\\":\\\"业务目标和用户角色\\\"}]}\"\n output-format: \"{\\\"traceability\\\":[\\\"每个用例带唯一ID：TC_{模块缩写}_{功能缩写}_{三位序号}（如 TC_API_LOGIN_001）——不使用场景后缀\\\",\\\"关联需求ID：REQ-{需求模块缩写}-{序号}\\\",\\\"关联场景ID：SC-{场景模块缩写}-{序号}\\\"],\\\"structure\\\":[{\\\"test_case_table\\\":\\\"测试用例表：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）——全项目唯一标准，见 references/output-template-full.md\\\"},\\\"用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）\\\",\\\"测试步骤：协议/接口/规则/计算类必填（含 method+path+关键参数）；UI/业务流程类可留空并标注「由执行人按实际系统补充」\\\",\\\"子功能并入「功能模块」用 模块/子功能 表示，不单设列；无「实际结果」列——那是 qa-execution-observation 的执行记录字段\\\",\\\"覆盖率：标注口径（基于现有需求/上游分析产出），禁止\\\\\\\"全覆盖/100%\\\\\\\"绝对化表述；缺失模块标注\\\\\\\"未覆盖+原因\\\\\\\"\\\"]}\"\n error-recovery-guidance: \"{\\\"on_failure\\\":\\\"用例设计遗漏维度时回退到边界分析和场景树补充\\\",\\\"retry_behavior\\\":\\\"补充上游后重新设计用例\\\"}\"\n categories: \"[\\\"Development\\\",\\\"Testing\\\"]\"\n depth-requirement: \"{\\\"reference_value\\\":\\\"见 references/output-template-full.md；用例总数不低于需求点的 3 倍\\\",\\\"minimum\\\":\\\"9 列齐全、编号唯一且合格式、P0-P3 占比达标、覆盖率标注口径\\\"}\"\n---\n\n> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills\n\n# 测试用例设计专项\n\n## 核心原则\n\n测试用例设计的核心——明确\"测什么\"，而非\"怎么测\"。\n\n> **重要限制**：禁止读取代码。测试用例必须基于需求文档，不得读取代码实现。\n> 确保验证\"系统应该做什么\"，而非\"系统如何实现\"。\n\n> **上游未完成就不要开始**：没有充分输入（需求解构 / 场景树 / 边界清单）时，\n> 生成的用例一定是泛泛的。先补上游，再做本步。\n\n## 1. 九列标准格式（本技能是全项目格式定义者）\n\n| # | 列名 | 必填 | 要点 |\n|---|------|------|------|\n| 1 | 用例编号 | ✅ | `TC_{模块缩写}_{功能缩写}_{三位序号}`，同批不重号 |\n| 2 | 测试类型 | ✅ | 按所属技能维度：功能/安全/异常/性能/契约/兼容性 |\n| 3 | 功能模块 | ✅ | 必要时 `模块/子功能` 两级（子功能并入本列） |\n| 4 | 测试标题 | ✅ | 动词开头，点明验证点 |\n| 5 | 用例级别 | ✅ | P0/P1/P2/P3，占比见下 |\n| 6 | 预置条件 | ✅ | 环境+数据+权限+状态，具体到可复现 |\n| 7 | 测试步骤 | ⚠️ | **协议/规则/计算类必填**；UI/业务流程类可留空 |\n| 8 | 预期结果 | ✅ | 可量化：状态码 / 返回结构 / 数据状态 / 副作用 |\n| 9 | 风险等级 | ✅ | 高（资损/越权/数据错误"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n \"slug\": \"qa-test-case-design\",\n \"version\": \"1.8.0\",\n \"publishedAt\": 1790655443725\n}"},{"path":"references/coverage-and-quality.md","content":"# 测试覆盖策略与质量标准\n\n## 覆盖维度\n\n```\n测试覆盖：\n├─ 功能覆盖\n│ ├─ 主流程覆盖：核心业务流程是否完整测试\n│ ├─ 分支流程覆盖：各种条件分支路径是否覆盖\n│ ├─ 异常场景覆盖：错误输入、异常操作是否测试\n│ ├─ 边界条件覆盖：输入范围边界、数量边界是否测试\n│ ├─ 退出流程覆盖：退出登录、注销、超时退出等场景\n│ └─ 状态转换覆盖：系统状态变化是否测试\n│\n├─ 数据覆盖\n│ ├─ 有效数据覆盖：正常数据是否测试\n│ ├─ 无效数据覆盖：异常数据是否测试\n│ ├─ 边界数据覆盖：边界值数据是否测试\n│ ├─ 特殊数据覆盖：特殊字符、超长数据是否测试\n│ ├─ 格式校验覆盖：邮箱、手机号、身份证等格式验证\n│ └─ 注入测试覆盖：SQL注入、XSS攻击等安全测试\n│\n├─ 字段级验证覆盖（每个表单字段必须测试）\n│ ├─ 长度边界：1位、最大长度、最大长度+1\n│ ├─ 格式校验：正则表达式验证（邮箱、手机号、身份证等）\n│ ├─ 注入测试：SQL注入、XSS攻击、命令注入\n│ ├─ 特殊字符：空格、特殊符号、Unicode字符\n│ ├─ 空值处理：必填字段为空、选填字段为空\n│ └─ 默认值：字段默认值是否正确\n│\n├─ 权限覆盖\n│ ├─ 角色权限覆盖：不同角色权限是否测试\n│ ├─ 越权访问覆盖：越权操作是否拦截\n│ ├─ 数据权限覆盖：数据隔离是否验证\n│ ├─ 功能权限覆盖：功能访问控制是否测试\n│ ├─ CSRF防护覆盖：跨站请求伪造防护是否测试\n│ └─ 路径遍历覆盖：目录遍历攻击防护是否测试\n│\n├─ 集成覆盖\n│ ├─ 模块集成覆盖：模块间协作是否测试\n│ ├─ 接口集成覆盖：接口调用是否测试\n│ ├─ 数据集成覆盖：数据流转是否测试\n│ └─ 异常集成覆盖：异常处理是否测试\n│\n└─ 非功能覆盖\n ├─ 性能覆盖：响应时间、吞吐量、并发性能是否测试\n ├─ 兼容性覆盖：浏览器、操作系统、设备兼容性是否测试\n ├─ 可用性覆盖：用户体验、易用性是否测试\n ├─ 安全性覆盖：数据加密、传输安全是否测试\n └─ 可靠性覆盖：稳定性、容错性是否测试\n```\n\n### 覆盖率评估\n\n| 覆盖率类型 | 计算方式 | 目标值 |\n|------------|----------|--------|\n| 需求覆盖率 | 已测需求点 / 总需求点 × 100% | ≥95% |\n| 功能覆盖率 | 已测功能点 / 总功能点 × 100% | ≥90% |\n| 用例覆盖率 | 已执行用例 / 总用例 × 100% | ≥100% |\n| 缺陷覆盖率 | 已修复缺陷 / 总缺陷 × 100% | ≥90% |\n\n## 质量保证标准\n\n### 用例质量指标\n\n| 指标 | 计算方式 | 目标值 |\n|------|----------|--------|\n| 用例有效性 | 有效用例数 / 总用例数 × 100% | ≥95% |\n| 用例执行率 | 已执行用例数 / 总用例数 × 100% | ≥100% |\n| 用例通过率 | 通过用例数 / 已执行用例数 × 100% | ≥98% |\n| 缺陷发现率 | 缺陷数 / 用例数 × 100% | 持续优化 |\n\n### 交付质量标准\n\n- 用例总数不低于需求点的3倍（包含异常场景）\n- P0+P1用例占比不低于60%\n- 每条用例平均预期结果3-5条\n- 无空洞描述，预期结果均可客观验证\n- 符合企业测试管理规范格式要求\n- 测试步骤留空，由用户根据实际系统补充"},{"path":"references/design-methods.md","content":"# 用例设计方法参考\n\n## 常用设计方法\n\n| 方法 | 适用场景 | 说明 | 必用场景 |\n|------|----------|------|----------|\n| 等价类划分法 | 输入域测试 | 将输入域划分为有效/无效等价类，减少冗余用例 | 所有输入字段 |\n| 边界值分析法 | 边界测试 | 针对边界情况设计专项测试，发现常见错误 | 所有有边界限制的字段 |\n| 场景法 | 业务流程测试 | 基于用户业务流程构建端到端测试场景 | 核心业务流程 |\n| 判定表驱动法 | 多条件组合 | 穷举所有条件组合可能性 | **必须使用**：多条件组合场景 |\n| 错误推测法 | 经验驱动 | 基于历史缺陷数据和开发经验预测潜在问题 | **必须使用**：异常场景覆盖 |\n| 风险驱动测试 | 风险优先 | 优先覆盖高风险区域和高频使用场景 | 高风险功能 |\n| 状态转换法 | 状态机测试 | 测试状态机的合法/非法转换 | 有状态变化的功能 |\n| 因果图法 | 复杂条件组合 | 分析输入条件与输出结果的因果关系 | **必须使用**：复杂条件依赖关系 |\n| 正交试验法 | 多因素多水平 | 用最少的试验覆盖最多的因素组合 | **必须使用**：多因素兼容性测试 |\n| 功能图法 | 功能组合测试 | 分析功能点的输入输出关系，生成功能测试用例 | **必须使用**：功能点组合覆盖 |\n\n### 方法应用要点\n\n**等价类划分法**：有效等价类（正常业务数据范围）、无效等价类（异常/边界/特殊数据）。划分依据：业务规则、数据类型、用户角色。示例：用户年龄输入（1-120有效，<1或>120无效）。\n\n**边界值分析法**：数值边界（最小值、最小值+1、最大值-1、最大值）、字符串边界（空、1字符、最大长度、最大长度+1）、日期边界（当天、前一天、后一天）。示例：密码长度8位（测试7位、8位、9位）。\n\n**场景法**：主成功场景（正常业务流程）、扩展场景（分支流程）、异常场景（错误处理流程）。示例：电商下单（浏览→加购→结算→支付→完成）。\n\n**判定表驱动法**：条件桩（所有输入条件）、动作桩（所有可能输出）、规则（条件组合与动作对应关系）。示例：登录（用户名正确/错误 × 密码正确/错误 → 不同结果）。\n\n**错误推测法**：基于经验（历史缺陷/常见错误模式）、基于直觉（测试人员经验判断）、基于领域知识（业务规则边界）。示例：输入框输入特殊字符/超长字符串/SQL注入语句。\n\n**因果图法**：原因（输入条件）、结果（输出结果）、关系（与/或/非逻辑）、约束（条件间依赖）。示例：优惠券使用条件（金额≥100且有券 → 可使用）。\n\n**正交试验法**：因素（测试变量）、水平（取值）、用例（最少组合覆盖最多因素）。示例：兼容性测试（3浏览器×3系统×3分辨率 → 正交表选9组）。\n\n**功能图法**：功能点（系统功能）、输入（条件）、输出（结果）、组合（调用关系）。示例：电商系统（登录→浏览→加购→结算→支付→功能组合测试）。\n\n## 复杂场景覆盖\n\n| 场景类型 | 测试重点 | 示例 |\n|----------|----------|------|\n| 页面跳转测试 | 跳转目标、参数传递、权限校验 | 列表跳详情页、菜单跳转、外部链接跳转 |\n| 路由参数测试 | 参数缺失、非法、越界处理 | URL参数传递、query参数、path参数 |\n| 跨页面联动 | 数据传递、状态同步、缓存一致性 | 订单页与用户页关联、购物车与结算页联动 |\n| 并发场景测试 | 多人同时操作、数据竞争 | 同时下单、库存并发扣减 |\n| 异常兜底测试 | 服务降级、熔断、重试机制 | 接口超时、服务不可用、网络异常 |\n\n### 页面跳转测试深度覆盖\n\n**测试要点**：跳转触发点、跳转目标页、跳转条件、异常跳转。检查：正常跳转目标正确、参数传递完整、权限校验拦截正确、404处理、空状态、浏览器回退、返回按钮、面包屑导航、外部跳转新标签页、循环跳转检测。\n\n### 路由参数测试深度覆盖\n\n**测试要点**：参数定义（query/path/hash）、格式（数据类型/长度限制）、传递方式（URL/session/cookie/localStorage）、验证（缺失/非法/越界/安全）。检查：参数存在性、类型、长度、格式、安全（SQL注入/XSS）、边界、组合、编码。\n\n### 跨页面联动测试深度覆盖\n\n**测试要点**：数据依赖（页面间数据关系）、状态同步（操作后更新）、缓存策略（刷新机制）、业务流程（完整闭环）。检查：数据传递正确、关联页面状态更新、缓存策略合理、消息通知跳转正确、业务闭环完整、多页面数据一致、操作反馈同步。\n\n## 常用测试方法速查\n\n**等价类划分示例**：年龄输入框（有效[1,120]，无效<1/>120/非数字）；状态下拉（有效[启用/禁用/冻结]，无效其他）。\n\n**边界值分析示例**：文件上传10MB（9MB/10MB/10.1MB）；文本框200字符（199/200/201字）；列表分页（第1页/最后1页/超出最大页码）。\n\n**判定表示例**：\n\n| 条件 | A(有优惠券) | B(满100元) | C(可用) | 结果 |\n|------|-------------|------------|---------|------|\n| 1 | Y | Y | Y | 可以使用 |\n| 2 | Y | Y | N | 不可用（已过期） |\n| 3 | Y | N | Y | 不可用（不满足门槛） |\n| 4 | N | Y/Y | Y/Y | 不适用 |"},{"path":"references/output-template-full.md","content":"# 测试用例 9 列标准格式（权威定义）\n\n> **本文件是全项目测试用例格式的唯一真源。** 其他技能（`qa-api-testing`、`qa-agent-testing`、\n> `qa-regression-testing` 等）产出用例时以本定义为准；有冲突以本文件为准。\n> 校验工具：`python scripts/validate_testcase_table.py <用例文件>`\n\n## 1. 九列定义\n\n| # | 列名 | 必填 | 填写要求 | 常见错误 |\n|---|------|------|---------|---------|\n| 1 | 用例编号 | ✅ | `TC_{模块缩写}_{功能缩写}_{三位序号}`，同批内不重号 | 用 `TC_USER_LOGIN_001_NORMAL` 四段式；用 `AGENT-001` |\n| 2 | 测试类型 | ✅ | 按所属技能维度填写：功能/安全/异常/性能/契约/兼容性；API 类补安全与契约 | 写\"正常用例\"\"异常用例\" |\n| 3 | 功能模块 | ✅ | 业务模块，必要时用 `模块/子功能` 两级（**子功能并入本列，不单设列**） | 只写\"系统\"\"后端\" |\n| 4 | 测试标题 | ✅ | 动词开头，点明验证点 | 写\"测试登录\" |\n| 5 | 用例级别 | ✅ | P0/P1/P2/P3，占比见 §3 | 全标 P0 |\n| 6 | 预置条件 | ✅ | 环境 + 数据 + 权限 + 状态，具体到可复现 | 只写\"环境正常\" |\n| 7 | 测试步骤 | ⚠️ 见 §4 | 协议类必填；实现相关类可留空 | 全留空（丢了可执行性） |\n| 8 | 预期结果 | ✅ | 可量化：状态码 / 返回结构 / 数据状态 / 副作用 | 写\"正确\"\"正常\" |\n| 9 | 风险等级 | ✅ | 高（资损/越权/数据错误/安全）/ 中（体验与稳定性）/ 低 | 留空或全标高 |\n\n> **为什么没有\"实际结果\"列**：那是**执行阶段**的记录字段，由 `qa-execution-observation` 的\n> 观察记录承载，不属于设计阶段的用例定义。设计模板塞执行字段会导致执行时被回填污染设计产物。\n>\n> **为什么没有\"子功能\"列**：并入「功能模块」用 `模块/子功能` 表示，信息不丢且不增加列宽。\n> 9 列是 `validate_testcase_table.py` 与 `测试用例.csv` 的硬约束，不可增减。\n\n## 2. 编号规则\n\n```\nTC_{模块缩写}_{功能缩写}_{三位序号}\n```\n\n- 模块缩写：业务模块，2-10 位大写字母或数字（`API` / `CART` / `LOGIN` / `ORDER`）\n- 功能缩写：功能点，2-10 位（`LOGIN` / `CREATE` / `REFUND`）\n- 三位序号：同批内从 `001` 连续递增\n\n示例：\n- `TC_API_LOGIN_001` — API 模块 / 登录功能 / 第 1 条\n- `TC_CART_ADD_007` — 购物车 / 添加商品 / 第 7 条\n- `TC_ORDER_REFUND_003` — 订单 / 退款 / 第 3 条\n\n> **不使用场景后缀**（如 `_NORMAL` / `_JUMP`）。场景类别信息应写进「测试类型」与「测试标题」，\n> 塞进 ID 会让 ID 失去稳定的\"用例\"语义，也破坏与 `SC-{模块缩写}-{序号}` 场景 ID 的对应关系。\n\n## 3. 级别与占比\n\n| 级别 | 含义 | 适用场景 |\n|------|------|---------|\n| P0 | 关键 | 核心业务流程、主流程验证、资损/安全相关 |\n| P1 | 重要 | 主要功能、重要分支流程 |\n| P2 | 一般 | 次要功能、异常场景 |\n| P3 | 可选 | 边缘场景、极端异常 |\n\n**占比约束**：P0 ≤ 20% / P1 ≤ 40% / P2 ≤ 30% / P3 ≤ 10%\n\n**小规模例外**：用例总数 < 10 条时上述配额在数学上无法成立（20% 不足 1 条）。\n此时加 `--no-quota` 跳过校验，并在报告中注明「小规模用例集，按每维至少 1 条覆盖」。\n**不要为凑比例编造用例或随意拉高/压低级别。**\n\n## 4. 「测试步骤」该留空还是该填\n\n这是历史上最容易产生分歧的一列，裁决如下：\n\n| 用例类型 | 步骤 | 理由 |\n|---------|------|------|\n| **协议 / 接口类**（API、gRPC、WebSocket、Webhook、数据库协议） | **必填**，含 method + path + 关键参数 | 步骤由协议契约决定，不依赖实现细节，AI 能准确写出来 |\n| **配置 / 规则 / 计算类**（配置项、金额计算、权限矩阵） | **必填** | 同上，规则本身是确定的 |\n| **UI / 业务流程类**（页面跳转、交互流程） | **可留空**，标注「由执行人按实际系统补充」 | 同一\"登录\"功能不同系统实现完全不同，AI 强写必然与实际不符，反而增加修正成本 |\n\n> 历史版本曾一刀切要求\"测试步骤留空\"，导致 API 类用例丢失了可执行性——\n> 而 API 的 method/path 恰恰是**规格的一部分**，不是实现细节。\n> 现按类型区分：协议类必填，实现相关类可留空。\n\n## 5. 两种产出形态\n\n### A. 表格形态（默认，批量评审/流转用）\n\n```markdown\n| 用例编号 | 测试类型 | 功能模块 | 测试标题 | 用例级别 | 预置条件 | 测试步骤 | 预期结果 | 风险等级 |\n|---------|---------|---------|---------|---------|---------|---------|---------|---------|\n| TC_API_LOGIN_001 | 功能测试 | 认证/登录 | 正确凭证登录成功 | P0 | 账号 u1 已就绪，接口文档已提供 | POST /api/login，body {\"user\":\"u1\",\"pass\":\"***\"} | 返回 200，响应含 token；调 /api/profile 有效；无堆栈泄露 | 高 |\n| TC_API_LOGIN_002 | 安全测试 | 认证/登录 | 伪造 Token 被拒 | P0 | 已知合法 token 与签名算法 | 改 1 个字符后请求 /api/profile | 返回 401；响应不含内部信息与用户数据 | 高 |\n```\n\n### B. 展开块（单条用例评审/执行时用）\n\n```markdown\n### TC_API_LOGIN_001 — 正确凭证登录成功\n\n- **测试类型**：功能测试\n- **功能模块**：认证/登录\n- **用例级别**：P0\n- **预置条件**：账号 u1 已就绪；接口文档已提供\n- **测试步骤**：POST"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。 触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing structured test cases with P0-P3 prioritization, the canonical 9-column format, coverage strategy, and requirement traceability. Skill: qa-test-case-design Owner: kokxi Summary: 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。 触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing structured test cases with P0-P3 prioritization, the canonical 9-column format, coverage strategy, and requirement traceability. Tags: la","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":828,"uniquenessScore":49,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T01:49:26.225Z","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-11T01:49:26.225Z","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-11T03:55:04.890Z","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"}]}}}