PM Skills 测试场景技能全解析从用户故事到可执行 QA 测试用例的标准化生成流程【免费下载链接】pm-skillsPM Skills Marketplace: 100 agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills导读本文以 pm-skills 仓库中pm-execution插件下的 test-scenarios 技能 为骨架系统讲解如何把用户故事与验收标准转化为带测试目标、前置条件、用户角色、分步操作与预期结果的完整测试场景。你将掌握该技能的 8 步生成流程、标准化场景模板、与/test-scenarios命令的配合方式以及它如何与 user-stories、dummy-dataset 等上下游技能串联直接产出可供 QA 团队执行的质量测试资产。一、技能定位一个把验收标准翻译成测试场景的 PM 技能test-scenarios是 pm-skills 仓库pm-execution插件详见 插件 README中 16 个技能之一其核心职责一句话概括源自 SKILL.mdCreate comprehensive test scenarios from user stories with test objectives, starting conditions, user roles, step-by-step test actions, and expected outcomes.即从用户故事出发产出包含测试目标、起始条件、用户角色、分步测试动作和预期结果的完整测试场景。它面向三类典型使用时机Use when见 SKILL.md编写 QA 测试用例Writing QA test cases创建测试计划creating test plans定义验收测试场景、验证用户故事实现defining acceptance test scenarios, or validating user story implementations。在 pm-skills 的插件体系中技能是名词/概念型资产——它是领域知识与引导式工作流的载体由 Claude 等 Agent 在对话主题相关时自动加载无需显式调用见仓库根 README 与 CLAUDE.md 的 Key Design Rules。如果希望强制优先使用该技能可以用/test-scenarios或/pm-execution:test-scenarios显式触发。由于 SKILL.md 采用通用技能格式它同样适用于其他读取 SKILL.md 的 AI 助手如 Gemini CLI、Cursor、OpenCode 等详见根 README 的兼容性说明。二、输入参数三个占位符定义测试上下文技能的 frontmatterSKILL.md声明了三个参数占位符用于在调用时圈定测试范围参数含义示例$PRODUCT被测产品/系统名称E-commerce Web Store$USER_STORY待测试的用户故事标题 验收标准作为在线购物者我希望在产品页看到最近浏览区域以便快速回到考虑过的商品$CONTEXT附加测试上下文或约束仅桌面端 Chrome/Safari 需要支持涉及第三方支付 SDK 的场景需 mock$CONTEXT是最容易被忽视但价值最高的参数——它承载测试环境限制、跨浏览器/设备要求、第三方服务 mock 策略等约束直接影响后续场景设计的深度。根据 CLAUDE.md 的设计规则技能本身不需要占位符Skills need no placeholders, they read context from the conversation这里的$PRODUCT、$USER_STORY、$CONTEXT属于技能正文定义的语义参数用于引导 Agent 组织输出。三、8 步生成流程从故事评审到 QA 就绪SKILL.md 给出了结构化的 Step-by-Step Process每一步职责明确Review the user story and acceptance criteria—— 先通读用户故事与其验收标准这是后续一切场景的需求契约Define test objectives—— 明确本次要验证的具体行为测什么比怎么测更先决Establish starting conditions—— 界定系统状态、数据准备、配置项前置条件是保证场景可复现的关键Identify user roles—— 确认由谁执行测试动作不同角色权限不同场景也不同Create test steps—— 把交互逐步拆解一步一个可观察动作Define expected outcomes—— 为每一步定义可观察的预期结果步进式断言而非到最后才看结果Consider edge cases—— 覆盖无效输入、边界条件等异常路径Output detailed test scenarios—— 输出结构化、可直接交给 QA 执行与归档的场景文档。这套流程的核心设计意图是先设计后执行测试目标步骤 2必须先于测试步骤步骤 5避免想到哪测到哪同时强制在输出前完成边界思考步骤 7确保场景不是快乐路径的简单复述。四、场景模板每个场景必须包含的 5 个要素SKILL.md 定义了一套可复用的标准化模板任何一条测试场景都包含以下五要素**Test Scenario:** [Clear scenario name] ← 场景名一眼可读 **Test Objective:** [What this test validates] ← 验证目标 **Starting Conditions:** - [System state required] ← 系统状态 - [Data or configuration needed] ← 数据/配置 - [User setup or permissions] ← 用户设置/权限 **User Role:** [Who performs the test] ← 执行角色 **Test Steps:** 1. [First action and its expected result] ← 动作 该步预期 2. [Second action and observable outcome] 3. [Third action and system behavior] 4. [Completion action and final state] **Expected Outcomes:** - [Observable result 1] ← 最终可观察结果 - [Observable result 2] - [Observable result 3]这套模板的精妙之处在于每步都绑定预期结果Test Steps 中动作 → expected result成对出现既方便执行者逐步核对也让失败时能精确定位到具体步骤而不是笼统的功能坏了。五、完整示例为最近浏览功能编写测试场景SKILL.md 附带了一个完整的电商示例场景承接自 user-stories 技能 中的同款示例故事Recently Viewed Section两者形成了故事 → 场景的完美对照。以下完整继承原文示例**Test Scenario:** View Recently Viewed Products on Product Page **Test Objective:** Verify that the Recently viewed section displays correctly and excludes the current product. **Starting Conditions:** - User is logged in or has browser history enabled - User has viewed at least 2 products in the current session - User is now on a product page different from previously viewed items **User Role:** Online Shopper **Test Steps:** 1. Navigate to any product page → Section should appear at bottom with previously viewed items 2. Scroll to bottom of page → Recently viewed section is visible with product cards 3. Verify product thumbnails → Images, titles, and prices are displayed correctly 4. Check current product → Current product is NOT in the recently viewed list 5. Click on a product card → User navigates to the corresponding product page **Expected Outcomes:** - Recently viewed section appears only after viewing at least 1 prior product - Section displays 4-8 product cards with complete information - Current product is excluded from the list - Each card shows Viewed X minutes/hours ago timestamp - Clicking cards navigates to correct product pages - Performance: Section loads within 2 seconds值得注意的细节该示例将性能预期2 秒内加载直接写进了 Expected Outcomes同时用当前商品必须被排除这条否定性预期覆盖了业务的隐藏规则——这正是好的测试场景与泛泛描述之间的分水岭。六、输出交付物QA 可直接执行的质量资产根据 SKILL.md每次调用技能应产出以下交付物覆盖每一条验收标准的完整测试场景Comprehensive test scenarios for each acceptance criterion与用户故事意图对齐的清晰测试目标Clear test objectives aligned with user story intent详细的分步测试动作Detailed step-by-step test actions每一步之后的可观察预期结果Observable expected outcomes after each step边界与错误场景覆盖Edge case and error scenario coverage可直接交予 QA 团队执行与文档归档的格式Ready for QA team execution and documentation。这里隐含一条重要原则对应 CLAUDE.md 中的验收标准应可由 QA 无需额外解读即可测试验收标准与测试场景之间应是一一映射的关系技能的输出交付物第一条即强制每个验收标准至少对应一个场景。七、命令联动/test-scenarios命令与完整工作流与技能配套pm-execution插件还提供了 test-scenarios.md 命令命令是动词型资产由用户以/斜杠触发可链式调用一个或多个技能见 CLAUDE.md 与根 README。该命令把技能固化为 4 步端到端工作流Step 1: 接受输入接受用户故事、验收标准、PRD 片段、功能描述等任意规格说明示例调用方式见 命令文件/test-scenarios [paste user stories or acceptance criteria] /test-scenarios [upload a PRD or feature spec] /test-scenarios User can reset their password via email linkStep 2: 调用技能生成五类场景对每条用户故事/需求分别生成Happy Path Scenarios预期用户流程正常工作Edge Cases边界条件、异常输入、并发操作Error Scenarios出错时的行为Security Scenarios如适用认证、权限、数据访问Performance Scenarios如适用负载、超时、大数据量。Step 3: 结构化输出命令规定了统一的输出骨架命令文件包含场景级表格Step / Action / Expected Result 三列、优先级字段、覆盖矩阵与测试数据需求## Test Scenarios: [Feature] **Source**: [user stories / PRD / description] **Total scenarios**: [count] **Coverage**: [happy path / edge cases / errors / security / performance] ### Scenario 1: [Title] **Tests**: [which story or requirement] **Preconditions**: [setup needed] **User role**: [who is performing this] | Step | Action | Expected Result | |------|--------|----------------| | 1 | [user action] | [expected system response] | | 2 | [user action] | [expected system response] | **Postconditions**: [state after completion] **Priority**: [Critical / High / Medium / Low] --- ### Coverage Matrix | Requirement | Happy Path | Edge Cases | Error Handling | Notes | |------------|-----------|-----------|---------------|-------| ### Test Data Requirements [What test data is needed to execute these scenarios]覆盖矩阵Coverage Matrix是这套输出的点睛之笔——它把需求 × 场景类型二维展开任何一条需求缺少某类覆盖都会在矩阵上直接暴露成空格是向团队可视化展示测试充分性的利器。Step 4: 提供后续动作命令完成后会给出自然语言建议这是 pm-skills 的命令间衔接惯例见 CLAUDE.md 的 No cross-plugin references 规则跨插件建议一律以自然语言表达不做硬引用Want me togenerate the test datafor these scenarios?Should Iadd more edge casesfor any specific scenario?Want me tocreate the user storiesthat these scenarios test?八、命令的实战纪律Notes命令文件 还沉淀了四条实战纪律可作为任何团队编写测试场景的底线Happy paths first, then layer in edge cases—— 先保证基本流程可用再叠加边界测试基础流程没通就测边界是浪费Every acceptance criterion maps to at least one test scenario—— 原故事的每条验收标准至少映射一个场景保证需求 → 测试可追溯Include both positive tests (it works) and negative tests (it fails gracefully)—— 正向测试证明能用负向测试证明坏得优雅两者缺一不可For APIs, include scenarios for rate limiting, timeout, malformed requests, and auth failures—— API 场景必须覆盖限流、超时、畸形请求与认证失败四类同时标记需要特定测试环境或第三方服务 mock 的场景Flag scenarios that require specific test environments or third-party service mocking避免场景因外部依赖而不可执行。九、上下游协同与 user-stories、dummy-dataset 等技能的完整测试链路test-scenarios在 pm-execution 插件中不是孤立的它与多条技能/命令构成完整的需求 → 测试 → 数据闭环上游需求定义。用户故事由 user-stories 技能 按 3 CsCard / Conversation / Confirmation与 INVEST 标准产出每条故事强制包含 4-6 条可测试的验收标准——这正是 test-scenarios 的输入源头。配套的 write-stories 命令 在生成 backlog 后会主动建议 Want me togenerate test scenariosfor these stories?两个技能因此被设计为天然衔接。此外pm-execution还提供wwasWhy-What-Acceptance、job-stories等故事格式它们同样以验收标准为公共接口均可作为 test-scenarios 的输入。下游测试数据。场景中的 Starting Conditions 往往需要真实感测试数据支撑这正是 dummy-dataset 技能 的职责——它可按列定义、行数、约束与业务规则生成 CSV/JSON/SQL/Python 脚本四种格式的仿真数据集对应的 /generate-data 命令 在完成后同样会反问 Want me towrite test scenariosthat use this data?。由此形成故事 → 场景 → 数据的完整交付链。横向执行验证与结果分析。若被测对象是 AI 构建的代码仓库pm-ai-shipping插件的 /derive-tests 命令 提供另一条思路——从系统文档中提取承重规则推导测试用例并将测试划分为 unit / integration / guarded live / manual 四类与 test-scenarios 的场景级视角互补前者是规则级、后者是故事级。场景执行后的结果评估则可衔接pm-data-analytics插件的 /analyze-test 命令面向 A/B 测试的统计显著性分析不过两者面向的测试类型不同使用时应按需选择。十、仓库实现事实从结构看技能如何被校验与分发从仓库源码结构可以确认test-scenarios的工程化落地方式依据 CLAUDE.md 与根 README目录与命名强制一致技能必须位于pm-execution/skills/test-scenarios/SKILL.md且 frontmatter 的name必须等于目录名test-scenarios否则无法通过仓库校验frontmatter 是触发元数据description字段会被 Cowork 技能列表与 Claude 自动加载机制读取因此 SKILL.md 的 description 中嵌入了 writing QA test cases, creating test plans, defining acceptance tests, validating user story implementations 等触发短语确保在相关话题出现时技能能被正确唤起可被校验器验证仓库根目录的 validate_plugins.py 会检查技能 frontmatternamedescription与name 匹配目录名等规则运行方式为仓库根目录执行python3 validate_plugins.py随插件整体分发test-scenarios随pm-execution插件安装插件级清单位于pm-execution/.claude-plugin/plugin.json9 个插件由根marketplace.json聚合——安装方式参见根 READMEClaude Cowork 通过 Add marketplace from GitHub 一键安装全部插件Claude Code / Codex CLI 通过plugin install/add命令按需安装如claude plugin install pm-executionpm-skills。十一、最佳实践小结综合技能与命令将test-scenarios落地到团队测试流程时的关键实践可归纳为以验收标准为锚每个测试场景明确标注其验证的故事/需求与验收标准条目保证可追溯先快乐路径再边界与错误分阶段叠层避免基础流程未验证就深入边界正向 负向成对设计每类核心行为同时准备能工作与优雅失败两个方向前置条件必须可复现系统状态、数据、权限三者缺一不可否则场景无法被稳定执行善用$CONTEXT把环境约束、mock 策略、性能 SLA 写进上下文让 Agent 生成的场景更贴合真实执行环境用覆盖矩阵做体检任何需求 × 场景类型交叉处的空格就是测试计划中的已知风险点。这套方法论的最终价值正如 命令文件 所述把用户故事或功能描述变成 QA 可以立即执行的测试场景——快乐路径、边界、错误处理乃至跨浏览器/设备考量全部就位让验证功能实现从口头约定变为可执行、可归档、可追溯的工程资产。【免费下载链接】pm-skillsPM Skills Marketplace: 100 agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
PM Skills 测试场景技能全解析：从用户故事到可执行 QA 测试用例的标准化生成流程
PM Skills 测试场景技能全解析从用户故事到可执行 QA 测试用例的标准化生成流程【免费下载链接】pm-skillsPM Skills Marketplace: 100 agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills导读本文以 pm-skills 仓库中pm-execution插件下的 test-scenarios 技能 为骨架系统讲解如何把用户故事与验收标准转化为带测试目标、前置条件、用户角色、分步操作与预期结果的完整测试场景。你将掌握该技能的 8 步生成流程、标准化场景模板、与/test-scenarios命令的配合方式以及它如何与 user-stories、dummy-dataset 等上下游技能串联直接产出可供 QA 团队执行的质量测试资产。一、技能定位一个把验收标准翻译成测试场景的 PM 技能test-scenarios是 pm-skills 仓库pm-execution插件详见 插件 README中 16 个技能之一其核心职责一句话概括源自 SKILL.mdCreate comprehensive test scenarios from user stories with test objectives, starting conditions, user roles, step-by-step test actions, and expected outcomes.即从用户故事出发产出包含测试目标、起始条件、用户角色、分步测试动作和预期结果的完整测试场景。它面向三类典型使用时机Use when见 SKILL.md编写 QA 测试用例Writing QA test cases创建测试计划creating test plans定义验收测试场景、验证用户故事实现defining acceptance test scenarios, or validating user story implementations。在 pm-skills 的插件体系中技能是名词/概念型资产——它是领域知识与引导式工作流的载体由 Claude 等 Agent 在对话主题相关时自动加载无需显式调用见仓库根 README 与 CLAUDE.md 的 Key Design Rules。如果希望强制优先使用该技能可以用/test-scenarios或/pm-execution:test-scenarios显式触发。由于 SKILL.md 采用通用技能格式它同样适用于其他读取 SKILL.md 的 AI 助手如 Gemini CLI、Cursor、OpenCode 等详见根 README 的兼容性说明。二、输入参数三个占位符定义测试上下文技能的 frontmatterSKILL.md声明了三个参数占位符用于在调用时圈定测试范围参数含义示例$PRODUCT被测产品/系统名称E-commerce Web Store$USER_STORY待测试的用户故事标题 验收标准作为在线购物者我希望在产品页看到最近浏览区域以便快速回到考虑过的商品$CONTEXT附加测试上下文或约束仅桌面端 Chrome/Safari 需要支持涉及第三方支付 SDK 的场景需 mock$CONTEXT是最容易被忽视但价值最高的参数——它承载测试环境限制、跨浏览器/设备要求、第三方服务 mock 策略等约束直接影响后续场景设计的深度。根据 CLAUDE.md 的设计规则技能本身不需要占位符Skills need no placeholders, they read context from the conversation这里的$PRODUCT、$USER_STORY、$CONTEXT属于技能正文定义的语义参数用于引导 Agent 组织输出。三、8 步生成流程从故事评审到 QA 就绪SKILL.md 给出了结构化的 Step-by-Step Process每一步职责明确Review the user story and acceptance criteria—— 先通读用户故事与其验收标准这是后续一切场景的需求契约Define test objectives—— 明确本次要验证的具体行为测什么比怎么测更先决Establish starting conditions—— 界定系统状态、数据准备、配置项前置条件是保证场景可复现的关键Identify user roles—— 确认由谁执行测试动作不同角色权限不同场景也不同Create test steps—— 把交互逐步拆解一步一个可观察动作Define expected outcomes—— 为每一步定义可观察的预期结果步进式断言而非到最后才看结果Consider edge cases—— 覆盖无效输入、边界条件等异常路径Output detailed test scenarios—— 输出结构化、可直接交给 QA 执行与归档的场景文档。这套流程的核心设计意图是先设计后执行测试目标步骤 2必须先于测试步骤步骤 5避免想到哪测到哪同时强制在输出前完成边界思考步骤 7确保场景不是快乐路径的简单复述。四、场景模板每个场景必须包含的 5 个要素SKILL.md 定义了一套可复用的标准化模板任何一条测试场景都包含以下五要素**Test Scenario:** [Clear scenario name] ← 场景名一眼可读 **Test Objective:** [What this test validates] ← 验证目标 **Starting Conditions:** - [System state required] ← 系统状态 - [Data or configuration needed] ← 数据/配置 - [User setup or permissions] ← 用户设置/权限 **User Role:** [Who performs the test] ← 执行角色 **Test Steps:** 1. [First action and its expected result] ← 动作 该步预期 2. [Second action and observable outcome] 3. [Third action and system behavior] 4. [Completion action and final state] **Expected Outcomes:** - [Observable result 1] ← 最终可观察结果 - [Observable result 2] - [Observable result 3]这套模板的精妙之处在于每步都绑定预期结果Test Steps 中动作 → expected result成对出现既方便执行者逐步核对也让失败时能精确定位到具体步骤而不是笼统的功能坏了。五、完整示例为最近浏览功能编写测试场景SKILL.md 附带了一个完整的电商示例场景承接自 user-stories 技能 中的同款示例故事Recently Viewed Section两者形成了故事 → 场景的完美对照。以下完整继承原文示例**Test Scenario:** View Recently Viewed Products on Product Page **Test Objective:** Verify that the Recently viewed section displays correctly and excludes the current product. **Starting Conditions:** - User is logged in or has browser history enabled - User has viewed at least 2 products in the current session - User is now on a product page different from previously viewed items **User Role:** Online Shopper **Test Steps:** 1. Navigate to any product page → Section should appear at bottom with previously viewed items 2. Scroll to bottom of page → Recently viewed section is visible with product cards 3. Verify product thumbnails → Images, titles, and prices are displayed correctly 4. Check current product → Current product is NOT in the recently viewed list 5. Click on a product card → User navigates to the corresponding product page **Expected Outcomes:** - Recently viewed section appears only after viewing at least 1 prior product - Section displays 4-8 product cards with complete information - Current product is excluded from the list - Each card shows Viewed X minutes/hours ago timestamp - Clicking cards navigates to correct product pages - Performance: Section loads within 2 seconds值得注意的细节该示例将性能预期2 秒内加载直接写进了 Expected Outcomes同时用当前商品必须被排除这条否定性预期覆盖了业务的隐藏规则——这正是好的测试场景与泛泛描述之间的分水岭。六、输出交付物QA 可直接执行的质量资产根据 SKILL.md每次调用技能应产出以下交付物覆盖每一条验收标准的完整测试场景Comprehensive test scenarios for each acceptance criterion与用户故事意图对齐的清晰测试目标Clear test objectives aligned with user story intent详细的分步测试动作Detailed step-by-step test actions每一步之后的可观察预期结果Observable expected outcomes after each step边界与错误场景覆盖Edge case and error scenario coverage可直接交予 QA 团队执行与文档归档的格式Ready for QA team execution and documentation。这里隐含一条重要原则对应 CLAUDE.md 中的验收标准应可由 QA 无需额外解读即可测试验收标准与测试场景之间应是一一映射的关系技能的输出交付物第一条即强制每个验收标准至少对应一个场景。七、命令联动/test-scenarios命令与完整工作流与技能配套pm-execution插件还提供了 test-scenarios.md 命令命令是动词型资产由用户以/斜杠触发可链式调用一个或多个技能见 CLAUDE.md 与根 README。该命令把技能固化为 4 步端到端工作流Step 1: 接受输入接受用户故事、验收标准、PRD 片段、功能描述等任意规格说明示例调用方式见 命令文件/test-scenarios [paste user stories or acceptance criteria] /test-scenarios [upload a PRD or feature spec] /test-scenarios User can reset their password via email linkStep 2: 调用技能生成五类场景对每条用户故事/需求分别生成Happy Path Scenarios预期用户流程正常工作Edge Cases边界条件、异常输入、并发操作Error Scenarios出错时的行为Security Scenarios如适用认证、权限、数据访问Performance Scenarios如适用负载、超时、大数据量。Step 3: 结构化输出命令规定了统一的输出骨架命令文件包含场景级表格Step / Action / Expected Result 三列、优先级字段、覆盖矩阵与测试数据需求## Test Scenarios: [Feature] **Source**: [user stories / PRD / description] **Total scenarios**: [count] **Coverage**: [happy path / edge cases / errors / security / performance] ### Scenario 1: [Title] **Tests**: [which story or requirement] **Preconditions**: [setup needed] **User role**: [who is performing this] | Step | Action | Expected Result | |------|--------|----------------| | 1 | [user action] | [expected system response] | | 2 | [user action] | [expected system response] | **Postconditions**: [state after completion] **Priority**: [Critical / High / Medium / Low] --- ### Coverage Matrix | Requirement | Happy Path | Edge Cases | Error Handling | Notes | |------------|-----------|-----------|---------------|-------| ### Test Data Requirements [What test data is needed to execute these scenarios]覆盖矩阵Coverage Matrix是这套输出的点睛之笔——它把需求 × 场景类型二维展开任何一条需求缺少某类覆盖都会在矩阵上直接暴露成空格是向团队可视化展示测试充分性的利器。Step 4: 提供后续动作命令完成后会给出自然语言建议这是 pm-skills 的命令间衔接惯例见 CLAUDE.md 的 No cross-plugin references 规则跨插件建议一律以自然语言表达不做硬引用Want me togenerate the test datafor these scenarios?Should Iadd more edge casesfor any specific scenario?Want me tocreate the user storiesthat these scenarios test?八、命令的实战纪律Notes命令文件 还沉淀了四条实战纪律可作为任何团队编写测试场景的底线Happy paths first, then layer in edge cases—— 先保证基本流程可用再叠加边界测试基础流程没通就测边界是浪费Every acceptance criterion maps to at least one test scenario—— 原故事的每条验收标准至少映射一个场景保证需求 → 测试可追溯Include both positive tests (it works) and negative tests (it fails gracefully)—— 正向测试证明能用负向测试证明坏得优雅两者缺一不可For APIs, include scenarios for rate limiting, timeout, malformed requests, and auth failures—— API 场景必须覆盖限流、超时、畸形请求与认证失败四类同时标记需要特定测试环境或第三方服务 mock 的场景Flag scenarios that require specific test environments or third-party service mocking避免场景因外部依赖而不可执行。九、上下游协同与 user-stories、dummy-dataset 等技能的完整测试链路test-scenarios在 pm-execution 插件中不是孤立的它与多条技能/命令构成完整的需求 → 测试 → 数据闭环上游需求定义。用户故事由 user-stories 技能 按 3 CsCard / Conversation / Confirmation与 INVEST 标准产出每条故事强制包含 4-6 条可测试的验收标准——这正是 test-scenarios 的输入源头。配套的 write-stories 命令 在生成 backlog 后会主动建议 Want me togenerate test scenariosfor these stories?两个技能因此被设计为天然衔接。此外pm-execution还提供wwasWhy-What-Acceptance、job-stories等故事格式它们同样以验收标准为公共接口均可作为 test-scenarios 的输入。下游测试数据。场景中的 Starting Conditions 往往需要真实感测试数据支撑这正是 dummy-dataset 技能 的职责——它可按列定义、行数、约束与业务规则生成 CSV/JSON/SQL/Python 脚本四种格式的仿真数据集对应的 /generate-data 命令 在完成后同样会反问 Want me towrite test scenariosthat use this data?。由此形成故事 → 场景 → 数据的完整交付链。横向执行验证与结果分析。若被测对象是 AI 构建的代码仓库pm-ai-shipping插件的 /derive-tests 命令 提供另一条思路——从系统文档中提取承重规则推导测试用例并将测试划分为 unit / integration / guarded live / manual 四类与 test-scenarios 的场景级视角互补前者是规则级、后者是故事级。场景执行后的结果评估则可衔接pm-data-analytics插件的 /analyze-test 命令面向 A/B 测试的统计显著性分析不过两者面向的测试类型不同使用时应按需选择。十、仓库实现事实从结构看技能如何被校验与分发从仓库源码结构可以确认test-scenarios的工程化落地方式依据 CLAUDE.md 与根 README目录与命名强制一致技能必须位于pm-execution/skills/test-scenarios/SKILL.md且 frontmatter 的name必须等于目录名test-scenarios否则无法通过仓库校验frontmatter 是触发元数据description字段会被 Cowork 技能列表与 Claude 自动加载机制读取因此 SKILL.md 的 description 中嵌入了 writing QA test cases, creating test plans, defining acceptance tests, validating user story implementations 等触发短语确保在相关话题出现时技能能被正确唤起可被校验器验证仓库根目录的 validate_plugins.py 会检查技能 frontmatternamedescription与name 匹配目录名等规则运行方式为仓库根目录执行python3 validate_plugins.py随插件整体分发test-scenarios随pm-execution插件安装插件级清单位于pm-execution/.claude-plugin/plugin.json9 个插件由根marketplace.json聚合——安装方式参见根 READMEClaude Cowork 通过 Add marketplace from GitHub 一键安装全部插件Claude Code / Codex CLI 通过plugin install/add命令按需安装如claude plugin install pm-executionpm-skills。十一、最佳实践小结综合技能与命令将test-scenarios落地到团队测试流程时的关键实践可归纳为以验收标准为锚每个测试场景明确标注其验证的故事/需求与验收标准条目保证可追溯先快乐路径再边界与错误分阶段叠层避免基础流程未验证就深入边界正向 负向成对设计每类核心行为同时准备能工作与优雅失败两个方向前置条件必须可复现系统状态、数据、权限三者缺一不可否则场景无法被稳定执行善用$CONTEXT把环境约束、mock 策略、性能 SLA 写进上下文让 Agent 生成的场景更贴合真实执行环境用覆盖矩阵做体检任何需求 × 场景类型交叉处的空格就是测试计划中的已知风险点。这套方法论的最终价值正如 命令文件 所述把用户故事或功能描述变成 QA 可以立即执行的测试场景——快乐路径、边界、错误处理乃至跨浏览器/设备考量全部就位让验证功能实现从口头约定变为可执行、可归档、可追溯的工程资产。【免费下载链接】pm-skillsPM Skills Marketplace: 100 agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考