test-speclisted

# 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 或