vibeflow-feature-st

name	vibeflow-feature-st
description	质量门禁通过后使用 — 独立管理测试环境生命周期，执行黑盒验收测试，生成 ISO/IEC/IEEE 29119 合规测试用例文档

功能级黑盒验收测试

在 TDD 实现和质量门禁通过后，为已完成的功能执行黑盒验收测试。此技能独立管理自己的环境生命周期（启动 -> 测试 -> 清理），并生成 ISO/IEC/IEEE 29119 合规的测试用例文档。

启动宣告： "正在使用 vibeflow-feature-st 运行黑盒验收测试。"

黑盒测试哲学

TDD（vibeflow-tdd）已从内部验证了实现。此技能从外部验证 — 如用户或外部系统般：

• 通过真实接口输入（HTTP 端点、UI、CLI 参数）
• 通过真实接口观察输出（HTTP 响应、渲染 UI、stdout）
• 测试设计或执行期间不参考内部实现代码

规则： 如果一个测试用例需要阅读源代码才能确定预期结果，它不是黑盒测试 — 仅使用 SRS 规格重写。

服务生命周期（通过 .vibeflow/guides/services.md）

启动（首个测试用例前）

1. 读取 .vibeflow/guides/services.md — 定位"启动所有服务"章节
2. 检查服务是否已运行：运行健康检查
3. 如未运行：执行启动命令，捕获输出，提取 PID 和端口，记录到 .vibeflow/logs/session-log.md
4. 启动失败则诊断根因，修正后更新 .vibeflow/guides/services.md

清理（所有测试用例完成后）— 强制

1. 停止服务：按 PID 杀进程（优先）或按端口杀（备选）
2. 验证已停止：端口不再响应
3. 记录清理状态

为什么强制：留下运行的服务会在后续 ST 循环中造成端口冲突。

重启协议（修复-重测循环间）

1. Kill -> 2. 验证死亡 -> 3. 启动（含输出捕获）-> 4. 验证存活

检查清单

1. 加载上下文

读取目标功能的所有输入工件：

• 功能对象 — feature-list.json 中的 ID、标题、描述、verification_steps、ui 标志、依赖、优先级
• SRS 章节 — 通过文档查找协议读取完整 FR-xxx
• 设计章节 — 完整 §4.N
• 任务文档 — docs/changes/<change-id>/tasks.md
• UCD 章节（仅 "ui": true）
• 接口契约 — API 端点、CLI 命令、UI 入口点
• 测试结果摘要 — 来自 TDD 和质量门禁

2. 推导测试用例

对每个 verification_step，生成一个或多个测试用例。

类别分配规则：

类别	缩写	何时生成
功能	FUNC	始终 — 每个功能的正常路径 + 错误路径
边界	BNDRY	始终 — 极端情况、限制、空/最大/零值
UI	UI	仅当 "ui": true — Chrome DevTools 交互 + 视觉验证
安全	SEC	当功能处理用户输入、认证或外部数据
无障碍	A11Y	仅当 "ui": true — WCAG 2.1 AA 检查
性能	PERF	仅当追溯到有性能指标的 NFR-xxx

最低覆盖：

• 每个功能必须至少有一个 FUNC 和一个 BNDRY 测试用例
• 每个 verification_step 必须映射到至少一个测试用例
• UI 功能必须至少有一个 UI 和一个 A11Y 测试用例

用例 ID 格式：

ST-{类别}-{功能ID(3位)}-{序号(3位)}

示例：ST-FUNC-005-001、ST-UI-005-002、ST-SEC-012-001

测试用例内容规则：

• 测试步骤必须具体可执行（不含模糊的"验证它能工作"）
• 预期结果必须具体可断言（不含"应该看起来正确"）
• 前置条件必须列出真实、可验证的状态
• UI 测试用例必须包含三层检测：
  • Layer 1：evaluate_script() 自动错误检测
  • Layer 2：EXPECT/REJECT 格式
  • Layer 3：list_console_messages 控制台错误门禁

3. 编写测试用例文档

输出文件：docs/test-cases/feature-{id}-{slug}.md

文档结构：

1. 头部 — 功能 ID、关联需求、日期、标准
2. 摘要表 — 按类别计数
3. 测试用例块 — 每个用例一块，所有必需章节
4. 追溯矩阵 — 用例 ID <-> 需求 <-> verification_step <-> 自动化测试 <-> 结果

追溯矩阵的"结果"列初始为 PENDING。步骤 4 执行后更新为 PASS/FAIL。

4. 执行测试用例

硬性要求：必须逐一执行 docs/test-cases/feature-{id}-{slug}.md 中定义的测试用例

• 每个测试用例必须单独执行并记录结果
• UI 测试用例不可因任何原因跳过
• 不得合并或简化测试用例执行过程

1. 按服务生命周期章节启动服务
2. 非 UI 用例：通过运行测试命令或对运行中系统的手动检查验证
3. UI 用例：通过 Chrome DevTools MCP 执行
4. 更新追溯矩阵"结果"列
5. 按服务生命周期章节停止服务

任何用例失败时：

• 通过 AskUserQuestion 报告用户：失败用例 ID、步骤详情、实际 vs 预期
• 选项：修复代码并重新执行 / 修改测试用例 / 终止循环
• 失败在此阻塞功能进入审查

执行规则（硬门禁）

失败不可绕过

• 任何测试用例执行失败都阻塞功能标记为 "passing"
• ST 测试中发现的所有 bug 必须修复 — 无论是前端、后端还是集成 bug
• 不可绕过任何原因：
  • "简单功能" — 仍需测试用例
  • "UI 测试太复杂" — UI 测试不可跳过
  • "环境暂时不可用" — 阻塞，不是跳过

集成

调用者： vibeflow-build-work（步骤 9） 依赖： 质量门禁通过 产出： docs/test-cases/feature-{id}-{slug}.md（含执行结果） 链接到： vibeflow-spec-review（通过 Work 步骤 10）