name: test-plan-generator description: 根据 PRD、需求说明、用户故事、接口说明或发布范围，生成结构化测试计划、测试策略、范围、排期、风险、准入准出和评审清单。适用于测试计划、测试方案、回归计划、验收测试、QA plan、test strategy 等场景。

测试计划生成 Skill

触发场景

当用户提出以下需求时使用本 Skill： - “帮我写测试计划 / 测试方案 / QA plan / test plan” - “根据 PRD 生成测试计划” - “这个版本怎么测 / 回归怎么安排 / 验收测试怎么做” - “给接口/功能/小程序/App/后台系统做测试策略” - “上线前测试范围、风险、准入准出怎么定”

能力定位

擅长做

• 将 PRD、用户故事、接口说明、迭代范围转成可执行测试计划。
• 输出测试目标、范围、非范围、策略、环境、数据、资源排期、风险、准入准出、待确认项。
• 按风险优先级安排冒烟、功能、回归、兼容、性能、安全、验收测试。
• 在信息不完整时生成假设、待确认问题和降级版计划。

谨慎做

• 对缺少需求、排期、人员、环境的数据，不强行给确定结论，必须标注假设。
• 对金融、医疗、支付、安全等高风险系统，必须提示需要专业测试负责人复核。
• 对性能、安全、合规测试，只给计划和检查方向，不替代专项测试报告。

不能做

• 不能承诺“零缺陷”“一定可上线”。
• 不能凭空编造已评审、已通过、已修复等事实。
• 不能输出含真实账号、手机号、身份证、密钥、生产数据的测试数据。

输入路由

工作流程

1. 澄清背景：识别项目、版本、目标用户、上线时间、输入材料和关键约束。
2. 拆解范围：列出测试范围、非测试范围、优先级和影响面。
3. 选择策略：按风险选择冒烟、功能、回归、接口、兼容、性能、安全、验收等策略。
4. 设计资源排期：列阶段、起止时间、人天/工时、角色、负责人、依赖、交付物和缓冲。
5. 识别风险：输出风险等级、触发信号、缓解措施、应急/回滚方案、负责人和是否阻塞上线。
6. 定义准入准出：给出可验证、量化的进入测试与退出测试标准。
7. 生成待确认项：按优先级、阻塞属性、默认假设和未确认处理策略列问题。
8. 自检交付：用评审清单检查覆盖范围、风险、排期、资源、准入准出和隐私合规。

标准输出结构

1. 背景与目标

• 项目/版本：
• 输入依据：PRD / 用户故事 / 接口说明 / 发布清单 / 口述需求
• 测试目标：
• 关键约束：上线时间、人员、环境、依赖系统
• 重要假设：

2. 测试范围

3. 非测试范围

4. 测试策略

5. 环境、数据与依赖

6. 资源与排期

资源不足时优先级裁剪：P0 核心链路 > 上线阻塞风险 > 高频路径 > 历史高发缺陷 > 低频扩展场景。

7. 风险与应对

8. 准入与准出标准

准入示例 - 需求评审完成，核心验收标准明确。 - 测试环境可用，关键依赖联调完成。 - 主流程冒烟通过率 100%。 - 测试账号、测试数据、权限和配置准备完成且已脱敏。

准出示例 - P0 缺陷为 0。 - P1 缺陷全部关闭，或有书面豁免和风险接受人。 - 核心用例通过率 100%，整体用例通过率达到约定阈值。 - 性能/安全/兼容等发布要求达标，或风险已被业务/技术负责人接受。 - 上线验证项、监控项和回滚预案完成。

9. 缺失信息与待确认项

10. 交付物清单

11. 评审检查表

• 范围与非范围是否明确。
• 高风险、高价值、高频路径是否覆盖。
• 资源排期是否含人天、依赖、缓冲和完成标准。
• 风险是否含触发信号、应急方案、负责人和上线阻塞判断。
• 准入准出是否量化、可验证。
• 测试数据是否脱敏，是否避免生产敏感信息。
• 待确认项是否有优先级、阻塞属性和截止时间。

降级与错误处理

• 输入不足：先输出“基于当前信息的轻量测试计划”，并列出至少 5 个待确认问题。
• 范围冲突：分别列出用户给定范围、推断范围和需确认范围。
• 时间不足：说明裁剪原则，优先保障核心链路、阻塞风险和高频回归。
• 缺少人员：给出最低可执行方案和风险提示。
• 存在敏感数据：先脱敏再引用，如 {用户手机号}、{生产账号}。

质量验收标准

交付的测试计划必须满足： - 至少包含目标、范围、策略、环境数据、资源排期、风险、准入准出、待确认项。 - 每个核心模块至少有测试点、优先级和验收依据。 - 风险表至少包含风险等级、缓解措施、负责人、是否阻塞上线。 - 排期表至少包含起止时间、人天/工时、角色、依赖、输出、完成标准。 - 准入准出至少有 3 条可量化或可验证标准。 - 明确标注假设，不编造未提供的信息。

FAQ

1. 没有 PRD 能生成吗？ 可以，但必须输出轻量版计划和待确认问题。
2. 能直接写测试用例吗？ 可以先生成测试计划，再按模块继续生成测试用例。

   来源于7w4.net。

3. 能用于敏捷迭代吗？ 可以，按 Sprint 目标、用户故事和 DoD 生成迭代测试计划。
4. 能用于接口测试吗？ 可以，重点覆盖字段、鉴权、异常、幂等、限流和性能。
5. 能用于上线前回归吗？ 可以，按变更影响面、核心链路、历史缺陷和冒烟路径组织。
6. 能保证没有缺陷吗？ 不能，只能通过风险策略提升覆盖质量。

反模式

• 只列测试点，不给范围、风险、排期和准入准出。
• 未标注假设，直接把不确定信息写成事实。
• 用“全部测试通过”替代量化标准。
• 忽略环境、数据、依赖和人员约束。
• 使用真实生产敏感数据作为测试数据。

references

• references/test-plan-template.md：完整测试计划模板。
• references/risk-strategy.md：风险识别方法与风险表字段规范。
• references/risk-and-strategy.md：常见风险库与测试策略选择示例。
• references/review-checklist.md：评审检查清单。
• references/faq.md：常见问题。
• references/anti-patterns.md：反模式。
• references/trace-self-check.md：TRACE 自检记录。

这个 Skill 质量较好，结构规范、逻辑清晰。最大的优点是覆盖场景全面，从需求文档到一句话需求都能处理；输出模板标准化，包含范围、风险、排期、准入准出等完整要素；降级机制合理，信息不足时也能给出有价值的结果。不足之处是缺少使用示例，新手难以快速判断效果；另外部分指导内容可以更详细。总体而言，这是一个成熟度较高、可以直接用于实际工作的 Skill。