test-spec

name	test-spec
description	Convert a PRD, bug report, or task description into structured test points and targeted validation commands.

test-spec

把 PRD、bug 描述或任务条目转成可执行、可验收的测试点，帮助 QA/Engineer 在实现前明确正常路径、失败路径和回归范围。

用法

/test-spec <PRD、bug 或任务描述>

目标

• 从输入中提取验收标准和风险点
• 生成分层测试点，覆盖正常路径、异常路径和边界条件
• 给出适合小步验证的命令或检查模板
• 明确哪些测试需要人工检查、哪些可以自动化

适用场景

• PRD 或任务需要转成 QA 测试点
• bugfix 需要补充回归测试范围
• 实现前需要确认验收路径和边界条件
• 已有验收标准需要拆成可执行检查项

不适用场景

• 直接修复代码缺陷
• 替代 QA 验收结论
• 在需求不清时擅自扩大测试范围
• 执行长时间、全量或高风险命令

测试维度模板

每次输出至少覆盖以下维度，并为每类给出测试目标、输入/前置条件、检查方式和通过标准：

1. 正常路径：验证用户或系统按预期完成主流程；说明关键输入、期望输出和最小验证命令。
2. 失败路径：验证错误输入、外部依赖失败或前置条件不满足时的行为；说明错误提示、回退路径或不变式。
3. 边界条件：覆盖空值、最小/最大值、缺失字段、旧数据结构或兼容输入；说明边界为何相关。
4. 回归风险：列出可能受影响的既有能力、关联测试文件和需要复查的历史行为。
5. 验证命令模板：给出优先级最高的定向命令、文档检查或手工检查路径，避免默认全量测试。
6. 测试数据与环境：说明 fixture、临时目录、环境变量或人工准备项；没有特殊要求时写“无”。

执行规则

1. 先定位输入类型：PRD、bug、任务条目或验收标准。
2. 测试点必须对应可观察行为或可检查产物。
3. 缺少预期行为时先标记待澄清，不得猜测业务目标。
4. 优先推荐定向测试、文档检查或最小复现命令。
5. 输出必须区分自动验证和人工检查。

示例

• /test-spec docs/plan/vision.md 中登录流程 PRD，生成正常路径、失败路径和边界测试点
• /test-spec bug: opc runs cost 在旧 run_metrics.json 缺 cost 字段时报错，生成回归测试点

输出骨架

[示例用例]
- 从需求生成测试点：输入 PRD/任务 → 输出正常路径、失败路径、边界条件和验收映射
- 从 bug 生成回归测试：输入缺陷现象/复现路径 → 输出复现检查、修复验证和回归风险
[测试目标] ...
[测试点]
- 正常路径：目标 / 输入 / 检查方式 / 通过标准
- 失败路径：触发条件 / 期望失败行为 / 检查方式 / 通过标准
- 边界条件：边界值 / 相关原因 / 检查方式 / 通过标准
- 回归风险：受影响能力 / 关联文件 / 复查方式
- 测试数据与环境：fixture / 临时目录 / 环境变量 / 人工准备项
[验证命令模板]
- ...
[人工检查项]
- ...
[回归风险] ...

验收标准

• 至少包含“从需求生成测试点”和“从 bug 生成回归测试”两类示例
• 输出骨架包含测试目标、测试点、验证命令、人工检查和回归风险
• 每个测试维度都有检查方式和通过标准
• 缺少输入或预期行为时能标记待澄清，不输出伪确定结论

验收

• 说明该 skill 把 PRD、bug 或任务描述转成测试点
• 明确 QA/Engineer 责任边界
• 输出测试点可关联到验收标准或缺陷复现路径
• 验证建议优先定向、可复现、低成本